450

Розробка об'єктної моделі конкретної системи збору даних -

Курсовая

Информатика, кибернетика и программирование

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

Украинкский

2013-01-06

815 KB

86 чел.

Завдання

Метою курсової роботи є розробка об'єктної моделі конкретної системи «Система збору даних - метеорологічна станція» з використанням мови UML і CASE-засоби Rational Rose.

Об'єктна модель системи включає в себе комплекс діаграм:

  •   варіантів використання (Use Case Diagram);
  •   класів (Class Diagram);
  •   станів (Statechart Diagram);
  •   діяльності (Activity Diagram);
  •   послідовності (Sequence Diagram);
  •   кооперації (Collaboration Diagram);
  •   компонентів (Component Diagram);
  •   розгортання (Deploument Diagram).

Варіант №5

Відображення максимальних і мінімальних значень вибраних параметрів.


Зміст

Вступ

РОЗРОБКА ДІАГРАМИ ВАРІАНТІВ ВИКОРИСТАННЯ (USE CASE DIAGRAM)

РОЗРОБКА ДІАГРАМИ  КЛАСІВ (CLASS DIAGRAM)

РОЗРОБКА ДІАГРАМИ  СТАНІВ (STATECHART DIAGRAM);

РОЗРОБКА ДІАГРАМИ  ДІЯЛЬНОСТІ (ACTIVITY DIAGRAM);

РОЗРОБКА ДІАГРАМИ  ПОСЛІДОВНОСТЕЙ (SEQUENCE DIAGRAM);

РОЗРОБКА ДІАГРАМИ  СПІВРОБІТНИЦТВА (COLLABORATION DIAGRAM)

РОЗРОБКА ДІАГРАМИ  КОМПОНЕНТІВ (COMPONENT DIAGRAM)

РОЗРОБКА ДІАГРАМИ  РОЗГОРТАННЯ (DEPLOYMENT DIAGRAM).

ВИСНОВОК

Список використаної літератури


Вступ

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

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

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

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

РОЗРОБКА ДІАГРАМИ ВАРІАНТІВ ВИКОРИСТАННЯ (USE CASE DIAGRAM)

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

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

РОЗРОБКА ДІАГРАМИ  КЛАСІВ (CLASS DIAGRAM)

Центральне місце в ООАП займає розробка логічної моделі системи у вигляді діаграми класів. Нотація класів в мові UМL проста і інтуїтивно зрозуміла всім, хто коли-небудь мав досвід роботи з САSЕ-інструментаріями. Схожа нотація застосовується і для об'єктів - екземплярів класу, з тим відмінністю, що до імені класу додається ім'я об'єкта і вся напис підкреслюється.

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

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

РОЗРОБКА ДІАГРАМИ  СТАНІВ (STATECHART DIAGRAM);

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

Діаграми станів конструюються аж ніяк не для всіх класів

системи - інтерес представляють звичайно тільки такі класи, об'єкти яких відрізняються "підвищеними" динамічними характеристиками.

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

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

РОЗРОБКА ДІАГРАМИ  ДІЯЛЬНОСТІ (ACTIVITY DIAGRAM);

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

Елементами діаграми дій служать власне дії (activities), переходи (transitions) від однієї дії до іншого, точки прийняття рішень (decision points) і смуги синхронізації (synchronization bars).

РОЗРОБКА ДІАГРАМИ  ПОСЛІДОВНОСТЕЙ (SEQUENCE DIAGRAM)

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

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

РОЗРОБКА ДІАГРАМИ  СПІВРОБІТНИЦТВА (COLLABORATION DIAGRAM)

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

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

- На рівні специфікації - показує ролі класифікаторів та ролі

асоціацій в розглянутому взаємодії.

- На рівні прикладів - вказує екземпляри і зв'язку, що утворюють окремі ролі в кооперації.

РОЗРОБКА ДІАГРАМИ  КОМПОНЕНТІВ (COMPONENT DIAGRAM)

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

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

На рівні Component View моделі Rational Rose компонент вихідного коду представляє файл програмного забезпечення, що міститься в деякому пакеті. Тип файлу залежить від вибраної мови програмування (наприклад, в С + + компоненти відповідають файлів. H і. Cpp). Кожен компонент відповідає певній мові програмування. Для мови С + + подібний зв'язок зазвичай відрізняється однозначним характером, тобто одному класу відповідає один компонент. У деяких випадках, однак, компонент здатний представляти декілька класів - така ситуація виникає, якщо класи здійснюють взаємно обумовлені.

РОЗРОБКА ДІАГРАМИ  РОЗГОРТАННЯ (DEPLOYMENT DIAGRAM).

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

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

ВИСНОВОК

У процесі виконання даного курсового проекту було використано мову UML і CASE-засіб Rational Rose, за допомогою яких розроблено модель програмної системи для заданої у варіанті предметної області. Система розроблялася в порівневому порядку від концептуальної моделі - до логічної і далі до фізичної моделі. Таким чином, було побудовано вісім діаграм, які характеризують проектовану модель з різних сторін.


Список використаної літератури

1. Буч Г., Якобсон А., Рамбо Дж. UML. Классика компьютерных технологий: Пер. с англ.- СПб.: Питер, 2006. – 736с.

2. Леоненков А.В. Самоучитель UML. – СПб.: БХВ-Петербург, 2006.- 432с.

3. Боггс У., Боггс М. UML и Rational Rose 2002: Пер с англ. – М.: Лори, 2004. - 509с.

4. Трофимов С.А. CASE-технологии: Практическая работа в Rational Rose. – М.: Бином-Пресс, 2002.- 288с


 

А также другие работы, которые могут Вас заинтересовать

24602. Аудит дебіторської заборгованості та зобов’язань 28 KB
  Раціональна організація внутрішнього контролю за станом розрахунків сприяє зміцненню договірної та розрахункової дисципліни підвищенню відповідальності за дотримання платіжної дисципліни скороченню дебіторської і кредиторської заборгованості покращанню фінансового стану суб'єкта господарювання. Оцінка надійності внутрішнього контролю Наступним важливим кроком аудитора є оцінка надійності системи внутрішньо го контролю дебіторської заборгованості та зобов'язань. Правильна оцінка системи внутрішнього контролю підприємстваклієнта дає...
24603. Мета і завдаяння безготівкових розрахунків 33 KB
  Стан поточних зобов'язань і розрахунків найбільш точно відображає рівень організації у суб'єкта господарювання виробничої і торговельної діяльності а також бухгалтерського обліку. Раціональна організація контролю за станом розрахунків сприяє покращанню договірної і розрахункової дисципліни виконанню зобов'язань перед кредиторами підвищенню відповідальності за дотримання платіжної дисципліни скороченню дебіторської і кредиторської заборгованості прискоренню обігу коштів а в цілому покращанню фінансового стану суб'єкта господарювання....
24604. Аудит готівкових операцій 35.5 KB
  Завдання При здійсненні аудиту готівковорозрахункових операцій аудитору необхідно: 1 дати оцінку стану внутрішнього контролю за рухом і збереженням грошових коштів та інших цінностей у касі підприємства; 2 у залежності від оцінки стану внутрішнього контролю встановити метод організації аудиту: суцільний вибірковий чи комбінований та визначити необхідність проведення фактичного контролю. 3 перевірити за обраним методом: ♦ забезпечення умов зберігання готівки та інших цінностей у касі при надходженні їх із банку і при здаванні їх у банк; ♦...
24605. Мета і завдання аудиту установчих документів і власного капіталу 37 KB
  На нашу думку бажано таку перевірку розпочинати з аудиту установчих документів і власного капіталу. Аудит установчих документів і аудит власного капіталу не можуть досліджуватись окремо один від одного тому що такий елемент власного капіталу як статутний капітал є основою будьякого підприємства і фіксується в його установчих документах. В установчих документах можуть міститися дані Й про інші елементи власного капіталу.
24606. Внутрішній аудит суть, об’єкти і суб’єкти 36.5 KB
  Мета внутрішнього аудиту допомогти членам суб'єкта господарювання ефективно виконувати свої функції. Завдання внутрішнього аудиту: ♦ перевірка системи економічних регламентів і регуляторів на предмет достатності та відповідності чинним правовим актам і статуту; ♦ перевірка правильності складання та умов виконання господарських договорів; ♦ перевірка: наявності стану правильності оцінки майна; ефективності використання матеріальних фінансових і трудових ресурсів; дотримання чинного порядку встановлення та застосування цін тарифів;...
24607. Облік витрат виробництва 52 KB
  Облік витрат виробництва Витратами звітного періоду визнають або зменшення активів або збільшення зобов’язань що призводять до зменшення власного капіталу за умови що ці витрати можна достовірно оцінити. Згідно з ПсБО №16 Витрати€ – витрати визнають витратами певного періоду одночасно з визнанням доходу для отримання якого їх здійснено. Якщо витрати неможливо прямо пов’язати з доходом певного періоду їх відображають у складі витрат того звітного періоду у якому вони були здійснені. Економічна класифікація витрат: за способами...
24608. Облік готової продукції та її реалізації 27.5 KB
  Облік готової продукції та її реалізації До готової продукції належить продя обробка якої закінчена та яка пройшла випробування приймання укомплектування згідно з умовами договорів відповідає затвердженим стандартам пройшла технічний контроль та здана на склад або замовнику. продя має вартісну характеристику у гривневому еквіваленті. Супутня продя продя отримана в одному технологічному циклі одночасно з основною. Побічна продя – яка утворюється паралельно з основною і не потребує додаткових витрат.
24609. Облік фінансових інвестицій 36 KB
  Фінансова інвестиції – активи які утримуються підприємством з метою збільшення прибутку зростання вартості капіталу. первісно оцінюються за собівартістю з:ціни придбання комісійних винагород мита податків зборів та ін. за Дт придбання Кт зменшення їх вартості та вибуття.35 за варт.
24610. Облік власного капіталу 44.5 KB
  Облік власного капіталу В момент створення підпрва його страховий капітал втілюється в активах інвестованих засновниками і представляє собою варт. Власний капітал ВК – частина в активах підпрва яка залишається після вирахування всіх його зобов’язань К=АЗ. Складові: статутний капітал рах. капіт.