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

Характеристика предметної області. Формулювання задачі автоматизації

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

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

Для створення необхідної системи ми повинні визначити цілі та призначення системи. Дана система повинна виконувати такі дії:

Створення автоматизованої системи переліку технологічних операцій агропідприємства;

Вдосконалення системи роботи бази даних;

Пришвидшення процессу обробки нових запитів, щодо роботи агропідприємства.

Цілі системи

Створення системи, яка надає можливість ефективної роботи агропідприємства.

Підвищення рівня кваліфікації робітників та ефективності роботи.

Удосконалення роботи з базою даних.

Оптимізація роботи агропідприємства.

Для реалізації поставлених цілей система має вирішувати такі задачі:

Оперативно приймати нові запити щодо роботи агропідприємства;

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

Удосконалити якість роботи з БД;

Покращити взаємодію робітників;

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

 

 

Для створення програмної системи нашого класу будемо використовувати описаний нижче порядок роботи.

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

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

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

Можливо, саме апаратні засоби внесуть свої корективи, обмеження або додаткові вимоги до створюваного програмного забезпечення.

Потім визначимо список класів, які повинні бути присутніми в системі, поки без конкретної деталізації та докладного опису дій. Для цього будемо використовувати діаграму класів (Class diagram).

Після закладу в системі необхідних класів визначимо поведінку конкретних класів за допомогою діаграм State diagram (діаграми станів) і Activity diagram (діаграми активності).

Подальша деталізація взаємодії класів буде проводитися за допомогою Sequence diagram (діаграми послідовностей дій), Collaboration diagram (діаграми співробітництва).

На підставі вироблених класами дій створимо остаточну ієрархію класів системи за допомогою діаграми класів (Class diagram) і визначимо компоненти, в які ці класи необхідно включити за допомогою діаграми компонентів (Component diagram).

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

 

 

Починаємо роботу з створення діаграми варіантів використання. На ній відображаються усі головні актори та їх взаємодія з головними елементами системи та їх функціями. Прецедент (Варіант використання) – це опис на «високому рівні» фрагмента функціональності, яку забезпечує система. Інакше кажучи, варіант використання ілюструє, як можна використовувати систему. Узагальнення класу – це відношення, направлене від класу до його базового класу, тобто відношення, зворотнє успадкуванню. Узагальнення прецедентів (generalization) аналогічно узагальненню класів, тобто це відношення дочірнього прецеденту до його батьківського (базового) прецеденту. Позначення відношення узагальнення відображено на Мал. 1. 1

 

Мал. 1.