Проектування автоматизованої інформаційної системи виробництва сільськогосподарської продукції агропідприємством

 

У нашій системі ми виокремили чотори головних актори:

Головний агроном – це фізична особа, та вона є одним з головних акторів адже взаємодіє з автоматизованою системою самостійно. Основними прецедентами даного актора є підтримання роботи системи та виявлення зауважень.

Плановий відділ – це колектив, що розраховує планову собівартість виробництва видів продукції рослинництва, а саме, прямі витрати безпосередньо на технологічні операції по місяцях. Основними прецедентами даного актора є розрахунок планової собівартості.

Робітники – це фізичні особи, котрі відповідно до власної кваліфікації мають власні преценденти: виконання робіт, взаємодія з головним агрономом.

Актори знаходяться поза сферою дії того, що ми розробляємо, і, отже, не підлягають контролю з нашого боку. Між актором та елементами роботи проводяться зв’язки. Якщо стрілка суцільна то даний актор взаємодіє з прецедентом напряму. А якщо ми маємо пунктирну стрілку то це означає, що актор взаємодіє з прецедентом не напряму. Він взаємодіє з прецедентом через іншого актора або через інший прецедент. Напрямок стрілки показує, хто ініціює комунікацію.

Поведінка системи, що розробляється описується за допомогою функціональної моделі, яка відображає системні прецеденти (use case), системне оточення (actors) і зв'язки між прецедентами та акторами. Основне завдання моделі прецедентів – представляти собою єдиний засіб, що дає можливість замовнику, кінцевому користувачеві і розробнику спільно обговорювати функціональність і поведінку системи. Отже продемонструємо створену діаграму:

 

Мал. 1. 2 – діаграма прецедентів

 

 

Діаграма класів є основним логічним представленням моделі і містить детальну інформацію про внутрішню будову об'єктно-орієнтованої програмної системи або, використовуючи сучасну термінологію, про архітектуру програмної системи. Діаграми класів називають “статичними діаграмами”, оскільки на них показано класи разом з методами і атрибутами, а також статичний взаємозв’язок між ними: те, яким класам “відомо” про існування яких класів, і те, які класи “є частиною” інших класів, – але не показано методи, які при цьому викликаються.

В діаграмі класів повністю описуються класи, їх властивості – атрибути і операції. На підставі діаграми класів Rational Rose виконує такі функції: показати клас, описати його, показати опції, атрибути. Атрибути – це елементи з якими працює даний клас, чию інформацію він обробляє і над чим працює. У операціях класу вказуються дії для яких призначений даний клас, те що вини повинні виконувати.

У UML атрибути показуються щонайменше назвою, також може бути показано їх тип, початкове значення і інші властивості. Крім того, атрибути може бути показано з областю видимості атрибута:

+ відповідає публічним (public) атрибутам

# відповідає захищеним (protected) атрибутам

- відповідає приватним (private) атрибутам

Операції (методи) також показуються принаймні назвою, крім того, може бути показано їх параметри і типи значень, які буде повернуто. Операції, як і атрибути, може бути показано з областю видимості:

+ відповідає публічним (public) операціям

# відповідає захищеним (protected) операціям

- відповідає приватним (private) операціям

Для даної системи визначили три класи: Планування, Працівники та General Agronom Control.

Вони мають свої атрибути. Клас Технологічна карта працює з плановим відділом, Система GAC (General Agronom Control) – з технологічною картою та працівниками, а зі змінами по проекту системи. До операцій Планування було віднесено: перевірка зауважень, фіксація зауважень, виправлення зауважень, розрахунок планової собівартості продукції. До операцій класу Система GAC відносяться: Користування системою та виявлення зауважень, контроль працівників. До операцій класу Працівники відносяться: виконання робіт відповідно до технологічної карти. Отже продемонструємо створену діаграму класів.

 

Мал. 2. 1 – діаграма класів

 

 

Діаграма кооперації є різновидом діаграми взаємодії, і в контексті мови UML описує динамічний аспект взаємодії об'єктів при реалізації окремих варіантів використання. Подібно діаграм послідовності, кооперативні діаграми відображають потік подій через конкретний сценарій варіанту використання. Діаграми послідовності впорядковані за часом, а кооперативні діаграми загострюють увагу на зв'язках між об'єктами. Також на даних діаграмах показані почергово варіанти використання необхідних прецедентів, що також є немало важливим у розумінні діаграми. Адже за допомогою вказаних зв’язків ми можемо простежити почергово лінію роботи системи. Кооперативна діаграма включає акторів та їх прецеденти які ми вже визначали за допомогою діаграми варіантів використання.

З діаграми кооперацій легше зрозуміти зв'язки між об'єктами, однак важче усвідомити послідовність подій. З цієї причини часто для будь-якого сценарію створюють діаграми обох типів. Хоча вони служать для одній і тієї ж мети і містять одну й ту ж інформацію, але представляють її з різних точок зору.

За допомогою пункту меню Browse\Create collaboration diagram створимо діаграму кооперації для нашого прецеденту. Отже продемонструємо створену діаграму:

 

Мал. 3. 1 – діаграма кооперації

 

 

Діаграма послідовності відображає потік подій, що відбуваються в рамках варіанту використання. У цьому розділі буде розроблена діаграма послідовності, що описує роботу створеної системи. Діаграма послідовності – це впорядкована за часом діаграма Взаємодії і читати її слід зверху вниз. Діаграма послідовності є іншою формою діаграми взаємодії і оперує об’єктами і повідомленнями.

Побудова