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
- 5.2 Переваги автоматизації проектування буровибухових робіт
- Послідовність проектування інформаційної системи
- 3 Послідовність розробки інформаційної web-системи
- Київський національний університет технологій та дизайну
- 3.2. Трудомісткість стадій створення інформаційної системи
- 11.1. Рівні управління проектування інформаційної системи
- Заняття 2. Технологія індивідуального проектування інформаційної системи
- 4. Методика проектування облікової інформаційної системи.
- 1.2. Процес проектування інформаційної системи.
- 21. Задачі та принципи автоматизації проектування інформаційної системи.