Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Курсова робота

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

Вступ

автоматизація агропідприємство кооперативний інформаційний

В зв`язку з великими труднощами управління проектами розробки та впровадження великих інформаційних систем досить широку популярність отримали CASE-засоби автоматизації проектування і моделювання інформаційних систем.

Лідером серед CASE-засобів є система Rational Rose. Вона дозволяє створювати складні інформаційні комп'ютерні системи від задуму до створення програмного коду. Використання Rational Rose має багато переваг, оскільки моделювання майбутньої системи дозволяє скоротити час розробки системи, що проектується і дає можливість створення системи з потрібною якістю. Модель майбутньої системи допомагає на стадії проектування без вкладання великих коштів в пілотний проект отримати уявлення про поведінку системи і уникнути подальших помилок, коли в написання програмного коду уже вкладені значні сили.

Мета курсової роботи є закріплення теоретичного матеріалу дисципліни «Технології комп'ютерного проектування», а також створення автоматизованої інформаційної системи планування вирощування сільськогосподарської продукції агропідприємством. Придбання навичок практичного об'єктно-орієнтованого проектування інформаційних систем у середовищі Rational Rose.

Основним завданням цього курсового проекту є опис моделі, що

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

Курсовий проект передбачає поетапне виконання з демонстрацією

кожного з етапів і виходом на виконання наступного відповідно до плану.

1. Теоретичний розділ. Постановка задачі та аналіз предметної області

Що таке Rational Rose?

На запитання «а що ж таке Rational Rose?», Я б коротко відповів: програмний пакет для візуального об'єктно орієнтованого моделювання систем на основі класів та їх взаємодії, а якщо ще більш спрощено, це візуальний редактор, що дозволяє створювати програмні системи будь-якої складності на основі графічних діаграм мови UML (Unified Modeling Language).

Мова UML

Мова UML кардинально відрізняється від таких мов програмування як, наприклад. Visual С# або Visual Basic. Він призначений для опису моделей, причому для роботи з цією мовою використовується спеціальні редактори діаграм, такі як Rational Rose. Ця мова занадто складна, щоб оперувати нею вручну.

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

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

UML є відкритим і володіє засобами розширення базового ядра. На UML можна змістовно описувати класи, об'єкти і компоненти в різних предметних областях, часто сильно відрізняються один від одного. Однак пакет Rational Rose підтримує не тільки UML, але й інші нотації створення діаграм, такі як ОМТ або Booch.

Rational Rose - лідер серед CASE-засобів

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

Сьогодні Rational Rose лідирує серед інших CASE-засобів, і не випадково. Тому, що цей пакет дозволяє створювати складні програмні системи від задуму до створення вихідного коду, приваблює не тільки проектувальників систем, але й програмістів. За кордоном, унаслідок сильної конкуренції між фірмами-розробниками програм, ні один, навіть невеликий програмний проект, не обходиться без застосування CASE - коштів. Вже більше 50 тисяч великих і маленьких компаній по всьому світу використовують Rational Rose для розробки програмних систем. Це такі відомі компанії як NASA, Boeing, Lockheed Martin, Honey-well, NBC, Reuters, AT & T та інші.

Що може і чого не може зробити Rational Rose?

Інструменти компанії Rational Software якнайкраще підходять для об'єктно-орієнтованої розробки програм від задуму до реалізації в коді. Rational Rose в поєднанні з іншими програмними пакетами набуває свою неповторну міць. У поєднанні із засобами документування (Rational SoDA) він може давати повне уявлення про проект. Повністю інтегруючись з Microsoft Visual Studio, цей пакет дає можливість отримувати вихідний код взаємодіючих класів і будувати візуальні моделі по вже написаного вихідного коду. Можливість інтеграції із засобами управління вимогами (Requisite Pro), із засобами тестування (SQA Suite, Performance Studio), із засобами конфігураційного управління (ClearCase, PVCS) піднімає процес ведення програмного проекту па абсолютно новий рівень. Відкрита архітектура Rational Rose дозволяє включати в нього підтримку мов програмування, які не передбачені стандартною поставкою, наприклад, мови Assembler, для чого достатньо написати лише власний модуль. Головна відмінність Rational Rose від інших CASE-засобів в тому, що він корисний не тільки проектувальнику систем, але і розробнику програмного коду. Для проектувальника переваги використання CASE-засобу не викликають сумнівів, але для розробника коду використання Rational Rose дає такі ж переваги, як якщо б ви змінили велосипед на літак. На перший погляд управління здається складним, але поступово до нього звикаєш. Маючи такий інструмент, досягнення цілей стає простіше і швидше, а вся робота може бути окинути одним поглядом. Якщо в проект приходить нова людина, він, ознайомившись з діаграмами Rational Rose, без праці увійде в курс справи. З Rational Rose вам не потрібно буде створювати заново ті частини проекту, які вів звільнений співробітник, адже розібратися в графічних діаграмах набагато простіше, ніж продиратися крізь нетрі погано-документованого вихідного коду, коли простіше і швидше переписати код заново, ніж розбиратися в «тяжку спадщину» попередника.

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

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

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

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

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

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

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

Цілі системи

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

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

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

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

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

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

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

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

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

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

2. Практична частина. Створення системи Агропідприємства. Побудова діаграм

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

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

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

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

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

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

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

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

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

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

2.1 Cтворення діаграми прецедентів

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

Рис. 1.1. - відношення узагальнення прецедентів

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

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

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

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

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

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



Рис. 1.2 - діаграма прецедентів

2.2 Створення діаграми класів

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.1 - діаграма класів

2.3 Створення кооперативної діаграми

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

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

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



Рис. 3.1 - діаграма кооперації

2.4 Створення діаграми послідовності

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

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

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

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

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

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

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

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



Рис. 4.1 - діаграма послідовності

2.5 Створення діаграми діяльності

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

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

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

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

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

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

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

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

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

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

Рис. 5.1 - діаграма діяльності

2.6 Створення діаграми компонентів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6.1 - Діаграма компонентів

Висновок

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

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

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

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

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

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

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

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

Дане завдання було реалізовано за допомогою 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 г.

Размещено на Allbest.ru