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

• Зміст
• Вступ
• 1. Постановка задачі
• 2. Діаграма варіантів використання
• 3. Діаграма кооперацій
• 4. Діаграма послідовності
• 5. Діаграма станів
• 6. Діаграма діяльності
• 7. Діаграма розгортання
• 8. Діаграма класів
• Висновок
• Список використаних джерел
• Додатки
• Вступ
• UML -- уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення.
• UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, що називається UML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем.

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

Переваги UML:

· UML об'єктно-орієнтована, в результаті чого методи опису результатів аналізу і проектування семантично близькі до методів програмування на сучасних об'єктно-орієнтованих мовах;

· UML дозволяє описати систему практично з усіх можливих точок зору і різні аспекти поведінки системи;

· Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;

· UML розширює і дозволяє вводити власні текстові та графічні стереотипи, це дозволяє застосовувати її не тільки в сфері програмної інженерії;

· UML отримала широке поширення і динамічно розвивається.

Мова UML призначена для вирішення наступних завдань:

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

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

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

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

5. Розвиток ринку об'єктних інструментальних засобів.

6. Поширення об'єктних технологій і відповідних понять об'єктно-оріентірованнного аналізу і проектування.

7. Інтеграція новітніх досягнення практики об'єктно-оріентірованнного аналізу і проектування.

У термінах мови UML визначені наступні види діаграм:

? Діаграма варіантів використання (use case diagram);

? Діаграма класів (class diagram);

? Діаграми поведінки (behavior diagrams);

? Діаграми реалізації (implementation diagrams);

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

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

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

* Діаграма станів;

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

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

* Діаграма кооперації;

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

* Діаграма розгортання.

1. Постановка задачі

моделювання програмний автомобільний діаграма

Тема мого курсового проекту: «Проектування інформаційної системи автоматизації автомобільного магазину».

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

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

Завданнями інформаційної системи є:

? реєстрація нових клієнтів;

? оформлення замовлень і відповідних документів;

? додавання\видалення запчастин.

Описувати систему я буду відкритим програмним забезпеченням ArgoUML. ArgoUML - засіб UML моделювання.

ArgoUML повністю написаний на Java і для роботи йому підходить будь-яка операційна система з встановленою Java 2 JRE або JDK версії 1.4 або вище.

Функціональність ArgoUML включає в себе:

? Підтримку специфікацій UML 1.3, 1.4, XMI 1.0, 1.1, 1.2;

? 9 видів діаграм UML (діаграми класів, станів, кооперації, послідовності, діяльності, прецедентів, об'єктів, компонентів, розгортання);

? Підтримку OCL для класів;

? Генерацію вихідного коду Java, C ++, C # і PHP;

? Зворотний інжиніринг з вихідного коду і байткода Java;

? Автоматичну верифікацію моделі UML (design critics).

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

Діаграма прецедентів -- в UML, діаграма, на якій зображено відношення між акторами та прецедентами в системі. Також, перекладається як діаграма варіантів використання.

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

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

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

У мові UML визначено такі типи відносин: залежність, асоціація, узагальнення і реалізація. Ці відносини є основними єднальними конструкціями UML і також як сутності застосовуються для побудови моделей.

Залежність (Dependency) - це семантичне відношення між двома сутностями, при якому зміна однієї з них, незалежної, може вплинути на семантику іншої, залежної.

Асоціація (Association) - структурне ставлення, що описує сукупність смислових або логічних зв'язків між об'єктами.

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

Реалізація (Realization) є семантичним відношенням між класифікаторами, при якому один класифікатор визначає зобов'язання, а інший гарантує його виконання.

Ставлення реалізації зустрічаються у двох випадках:

? між інтерфейсами і реалізують їх класами чи компонентами;

? між прецедентами і реалізують їх кооперації.

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

Як Клієнту так і Працівнику відносяться такі варіанти використання, як «Консультація», «Оформити замовлення», «Отримати запчастину», «Перевірити оплату» та «Видати запчастину».

Прецедент «Отримати запчастину» має 2 відношення розширення: «Запросити зі складу» та «Замовити запчастину».

Прецедент «Перевірити оплату» має також 2 розширення: «Оплата готівкою», «Оплата за безготівковим розрахунком».

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

3. Діаграма кооперацій

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

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

Діаграма кооперації насамперед відображає структуру взаємодії та містить такі елементи:

? Екземпляри акторів і класів, що беруть участь в реалізації варіанту використання;

? Асоціацію між екземплярами акторів і класів;

? Повідомлення, що передаються між екземплярами акторів і класів.

Кооперація може бути представлена на двох рівнях:

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

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

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

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

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

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

Нижче наведено діаграму кооперації для нашої системи.

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

Рис. 3.1. Діаграма кооперацій

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

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

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

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

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

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

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

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

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

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

5. Діаграма станів

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

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

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

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

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

Рис. 5.1. Діаграма станів

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

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

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

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



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

7. Діаграма розгортання

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

Діаграма розгортання в UML моделює фізичне розгортання артефактів на вузлах.

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

Існує два типи вузлів:

? Вузол пристрою;

? Вузол середовища виконання.

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

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

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

Рис. 7.1. Діаграма розгортання

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

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

Діаграма класів є граф, вершинами якого є елементи типу «класифікатор», пов'язані різними типами структурних відносин.

Є два основних види статичних зв'язків:

* асоціації;

* підтипи.

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

На даній діаграмі не вказується інформація про тимчасові аспекти функціонування системи. З цієї точки зору діаграма класів є подальшим розвитком концептуальної моделі проектованої системи.

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

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

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

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

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

Інформація з діаграми класів безпосередньо відображається у вихідний код програми - у більшості існуючих інструментів UML-моделювання можлива кодогенераціі для певної мови програмування (зазвичай Java або C++). Таким чином, діаграма класів - кінцевий результат проектування і відправна точка процесу розробки.

Для прикладу генерації коду я обрала мову програмування Java та згенерувала усі класи, описані в системі. Результат генерації наведений в Додатках.

Рис. 8.1. Діаграма класів

Висновок

UML -- мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення.

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

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

Призначення UML:

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

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

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

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

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

? однаково розуміються всіма розробниками, залученими в проект;

? є засобом комунікації в рамках проекту.

Уніфікована мова моделювання (UML):

? не залежить від ОО мов програмування,

? не залежить від використовуваної методології розробки проекту,

? може підтримувати будь-яку ОО мову програмування.

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

У процесі виконання даного курсового проекту була розроблена модель системи «Автомобільного магазину». В ході її розробки я навчився створювати діаграми, що входять до мови моделювання UML. Відповідно, вивчив основи мови моделювання UML.

Список використаних джерел

1. Буч Г., Рамбо Д., Джекобсон А. Мова UML: керівництво користувача. М., ДМК, 2000.

2. Виролайнен А.М., Пугач Д.В. - Унифицированный язык моделирования (UML) 2007.;

3. Джозеф Шмуллер. Освой самостоятельно UML 2 за 24 часа. Практическое руководство -- М.: Вильямс, 2005. -- 416 с.

4. Дубенецкий, Б.Я. Проектирование информационных систем. / Б.Я. Дубенецкий. - Л.: ЛЭТИ, 2008 г. - 675 с.

5. Крэг Ларман. Применение UML 2.0 и шаблонов проектирования -- 3-е изд. -- М.: Вильямс, 2006. -- 736 с. .

6. Леоненков А. Самоучитель UML. Эффективный инструмент моделирования информационных систем. - BHV-Санкт-Петербург, 2001.- 304с.

7. Лешек А. Мацяшек. Разработка информационных систем с использованием UML, М.: Издательский дом ''Вильямс'', 2002.- 432с.

8. Терри Кватрани. Rational Rose 2000 и UML. Визуальное моделирование. - ДМК, 2001.- 176с.

9. Фаулер, М. UML в кратком изложении. / М. Фаулер. - М.: Мир, 2009 г. - 204 с.

10. Хассан Гома. UML. Проектирование систем реального времени, распределенных и параллельных приложений - М.: ДМК Пресс, 2002.- 704с.

Додаток

1. Клас Client

import java.util.Vector;

public class Client

public Integer client_id;

public String name;

public Vector myWorker;

public Vector 1 .. *;

public Vector 1 .. *;

public String order_spare_part

return null;

}

private String signature_document

return null;

}

public String pay

return null;

}

2. Клас Document

public class Document

public Integer doc_id;

public Integer date;

}

3. Клас Individual

public class Individual extends Client

public Integer card_number;

}

4. Клас Legal_entity

public class Legal_entity extends Client

public String legal_address;

public String contact_name;

}

5. Клас Manufacturer

import java.util.Vector;

public class Manufacturer

private String name;

public String country;

public Vector 1 .. 1;

}

6. Клас Order

import java.util.Vector;

public class Order {

public Integer client_id;

public Integer date;

public Integer number;

public String price;

public Vector myWorker;

public Vector myClient;

public Vector mySpare_part;

public Vector myDocument;

public Vector 1

}

7. Клас Spare_part

import java.util.Vector;

public class Spare_part

public String name;

public String appointment;

public Vector 1 .. *;

public Vector 1 .. 1;

}

8. Клас Worker

public class Worker

public String name;

public String consultation

return null;

}

public Boolean addClient(String name)

return null;

}

public void design order

}

public Boolean addSpare_part(String name, String appointment)

return null;

}

public Boolean removeSpare_part(String name, String appointment)

return null;

}

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