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

Діаграми послідовності впорядковані за часом. Вони корисні для того, хто хоче зрозуміти логічну послідовність подій в сценарії. Хоча інформація про послідовність входить і в Кооперативні діаграми, вона краще сприймається на діаграмі Послідовності.

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

Основний потік – яку саме роботу виконує варіант використання. В припущенні, що умови ідеальні і все що відбувається розвивається в позитивному напрямку.

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

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

Отже покажемо продемонструємо створену діаграму.

 

Мал. 4. 1 – діаграма послідовності

 

 

Будівельними цеглинками діаграм діяльності є стани. Стан належить лише одному класу і відповідає переліку значень атрибутів, які може приймати клас. У UML стан описує внутрішній стан об’єкта одного з окремих класів. Зауважте, що не кожну зміну одного з атрибутів об’єкта має бути показано станом, станам відповідають лише ті зміни, які значно впливають на виконання об’єктом завдань.

Існує два особливих типи станів: початок і кінець. Їх особливість полягає у тому, що не існує жодної події, яка може спричинити повернення об’єкта до його початкового стану, так само, не існує жодної події, яка б могла повернути об’єкт зі стану кінця, тільки-но він його досягне.

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

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

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

Головний агроном – General Agr. ; виконує дії на рівні керівника системи – користування системою, виявлення зауважень, організація процесу роботи.

Прейскурант – містить в собі інформацію про оплату працівникам

Технологічна карта – містить в собі

Плановий відділ – розраховує собівартість і передає звітність GAC.

GAC – організовує робочий процес.

 

Мал. 5. 1 – діаграма діяльності

 

 

Метою нашої роботи – є надати користувачеві можливість замінювати компоненти під час роботи доданку. Підтримка заміни компоненту під час виконання вимагає динамічного компонування. Доданок, зібраний з компонентів, які треба статично перекомпоновувати кожен раз при заміні одного з них, еквівалентний доданку-моноліту.

Діаграма компонентів служить частиною фізичного представлення моделі, грає важливу роль в процесі ООАП і є необхідною для генерації програмного коду. Для розробки діаграм компонентів в браузері проекту призначено окреме представлення компонентів (Component View), в якому вже міститься діаграма компонентів з порожнім змістом і ім'ям за умовчанням Main (Головна).

Переваги використання діаграми компонентів:

Здатність доданку еволюціонувати з плином часу (можливість розвивати доданок у подальшому)

Адаптація доданку

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

Розподілення компонентів.

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

Хороший компонент наділений такими характеристиками:

- інкапсулює сервіс з добре окресленим інтерфейсом і межами;

- має внутрішню структуру, яка допускає можливість її опису;

- не комбінує непов'язаної функціональності в межах однієї одиниці;

- організовує зовнішню поведінку, використовуючи інтерфейси і порти в невеликій кількості;

- взаємодіє тільки через оголошені порти;

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

Вибравши в якості мови програмування С + +, для кожного класу створені відповідні цій мові компоненти. Отже продемонструємо створену діаграму.

 

Мал. 6.1 – діаграма компонентів

 

 

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

При проектуванні моделі Агропідприємства обробки були створені:

Діаграма варіантів використання

Діаграма класів

Кооперативна діаграма

Діаграма послідовності

Діаграма діяльності

Діаграма компонентів

Дане завдання було реалізовано за допомогою CASE – засобів Rational Rose. Розробка проектів систем у Rational Rose- це дуже зручно і актуально на сьогоднішній день. Одна з беззаперечних переваг Rational Rose – зворотне проектування, оскільки розробнику і проектувальнику важливо побачити перед змінами вже працюючу систему в нормальному графічному поданні. Як правило візуально-графічний ряд надає куди більший вплив ніж гортання технічних завдань і програмних текстів. Тим більше що, проект, що піддався зворотному проектуванню може бути доопрацьований і знову згенерований (а згодом і скомпільований). Rational Rose надає для цього всі необхідні засоби. На сьогоднішній день Rose унікальний продукт в плані відкритості архітектури. Отже, можна впевнено сказати, що ми справилися з поставленим завданням.

 

 

1. Норенков И. П., Кузьмик П. К. Информационная поддержка наукоемких изделий. CALS – технологии. – М. : Издательство МГТУ им. Н. Э. Баумана, 2002. – 320 с.

2. Г. К. Горанский, Л. В. Губич, В. И. Махнач и др. / Под ред. А. Г. Раковича. Автоматизация проектирования технологических процессов и средств оснащения. – Минск: Институт технической кибернетики НАНБ, 1997-275с.

3. Трофимов С. А. «CASE-технологии: практическая работа в Rational Rose»: 2008г.

4. Трофимов С. А. «UML диаграммы в Rational Rose»: 2011г.

5. Федоров Н. В. «Проектирование информационных систем на основе современных CASE – технологий «: 2008г.

6. Ипатова Э. Р. «Методологии и технологии системного проектирования информационных систем»: 2009г.