Мова моделювання uml.
Більшість моделей об'єктно-орієнтованого проектування близькі за можливостями, але мають відмінності в основному у формі представлення. Популярність об'єктно-орієнтованих технологій привела до зближення більшості відомих моделей. Різноманіття моделей породжує труднощі проектувальників щодо вибору моделі і з обміну інформацією при роботі над різними проектами. В зв'язку з цим відомі фахівці Г.Буч, Д.Рамбо і І.Джекобсон за підтримки фірми Rational Software Corporation провели роботу над уніфікованою моделлю і методом, що отримав назву UML (Unified Modeling Language – уніфікована мова моделювання).
UML є єдиною мовою моделювання, призначеною для специфікації, візуалізації, конструювання і документування матеріалів програмних систем, а також для моделювання бізнесу і інших не програмних систем. У основу створення UML покладені три найбільш поширені моделі:
Booch, що отримала назву по прізвищу автора Граді Буч (Grady Booch);
ОМТ (Object Modeling Technique – метод моделювання об'єктів);
OOSE (Object-Oriented Software Engineering – об'єктно-орієнтоване проектування програмного забезпечення).
На завершальній стадії розробки, уніфікації і прийняття UML в якості стандарту великий внесок вніс консорціум OMG (Object Management Group – група управління об'єктом). UML можна визначити також як промисловий об'єктно-орієнтований стандарт моделювання. Він включає в уніфікованому вигляді кращі методи візуального (графічного) моделювання. В даний час є цілий ряд інструментальних засобів, виробники яких заявляють про підтримку UML, серед них можна виділити: Rational Rose, Select Enterprise, Platinum і Visual Modeler.
Типи діаграм UML
Проект інформаційної системи, що створюється за допомогою UML може включати наступні 8 видів діаграм (diagrams):
умов використання (use case)
класів (class)
станів (statechart)
активності (activity)
послідовності (sequence)
співпраці (collaboration)
компонент (component)
розміщення (deployment).
Діаграми станів, активності, послідовності і співпраці утворюють набір діаграм, що використовуються для опису поведінки інформаційної системи, яка розробляється. Причому, останні дві забезпечують опис взаємодії об'єктів інформаційної системи.
Діаграми компонент і розміщення описують фізичну реалізацію інформаційної системи.
Кожна з діаграм може містити елементи певного типу. Типи допустимих елементів і відношень між ними залежать від виду діаграми. Охарактеризуємо вказані види діаграм детальніше.
Діаграми умов використання
Діаграми умов використання описують функціональність ІС, видиму користувачами системи. Кожна функціональність зображується у вигляді умов використання.
Прецедент - це типова взаємодія користувача з системою, яка:
описує видиму користувачем функцію;
представляє різні рівні деталізації;
забезпечує досягнення конкретної мети.
Прецедент зображується як овал, зв'язаний з типовими користувачами, які називаються «акторами» (actors). Актором є будь-яка сутність, що взаємодіє з системою ззовні, наприклад людина, устаткування, інша система. Прецедент описує те, що система надає акторові – визначає набір транзакцій, що виконується актором при діалозі з інформаційною системою. На діаграмі зображається один актор, але користувачів, які виступають в ролі актора, може бути багато. Діаграма умов використання має високий рівень абстракції і дозволяє визначити функціональні вимоги ІС.
Приклад діаграми
Розглянемо приклад діаграми умов використання для інформаційної системи бібліотеки, а саме опис роботи бібліотеки, яка отримує запити від клієнтів на різні видання і реєструє інформацію про їх повернення до фондів бібліотеки.
Приклад діаграми умов використання приведений на рисунку 1. На діаграмі наведений ряд виділених при аналізі функцій, що реалізуються інформаційною системою:
адміністрування користувачів (Administrative Client);
облік книг (Administrative Books);
складання звітів (Report)
пошук видання (Find Book).
Рис. 1 - Діаграма умов використання.
Опис поведінки інформаційної системи
Діаграми станів
Діаграми станів описують поведінку об'єкту в часі, моделюють всі можливі зміни в стані об'єкту, викликані зовнішніми діями з боку інших об'єктів або ззовні. Діаграми станів застосовуються для опису поведінки об'єктів і для опису операцій класів. Цей тип діаграм описує зміна стану одного класу або об'єкту. Кожен стан об'єкту представляється у вигляді прямокутника із закругленими кутами, що містить ім'я стану і, можливо, значення атрибутів об'єкту в даний момент часу. Перехід здійснюється при настанні деякої події (наприклад, отримання об'єктом повідомлення або прийому сигналу) і зображується у вигляді стрілки, що сполучає два сусідні стани. Ім'я події указується на переході. На переході можуть указуватися також дії, що виконуються об'єктом у відповідь на зовнішні події.
Діаграми активності
Діаграми активності представляють окремий випадок діаграм станів. Кожен стан є виконанням деякої операції, і перехід в наступний стан відбувається при завершенні операції в початковому стані. Тим самим реалізується процедурне, синхронне керування, обумовлене завершенням внутрішніх дій. Стан, що описується не має внутрішніх переходів і переходів у відповідь на зовнішні події.
Для діаграм активності використовуються аналогічні діаграмам станів позначення, але на переходах відсутня сигнатура події і доданий символ «синхронізації» переходів для реалізації паралельних алгоритмів. Діаграми активності використовуються в основному для опису операцій класів.
Діаграма послідовності
Діаграма послідовності визначає часову послідовність (динаміку взаємодії) повідомлень, що передаються, порядок, вигляд і ім'я повідомлення. На діаграмі зображуються об'єкти, які безпосередньо беруть участь у взаємодії, і не показуються статичні асоціації з іншими об'єктами.
Діаграма послідовності має два вимірювання. Перше – зліва направо, у вигляді вертикальних ліній, що зображають об'єкти, які беруть участь у взаємодії. Верхня частина ліній доповнюється прямокутником, що містить ім'я класу об'єкту або ім'я екземпляра об'єкту. Друге вимірювання – вертикальна часова вісь. Повідомлення, які посилаються, зображуються у вигляді стрілок з іменем повідомлення і впорядковуються за часом виникнення.
Приклад діаграми послідовності приведений на рисунку 2. Наведена діаграма описує поведінку об'єктів в часі. Вона показує об'єкти і послідовність повідомлень, що посилаються об'єктами.
Рис. 2 - Діаграма послідовності.
Діаграми співпраці
Діаграми співпраці описують взаємодію об'єктів системи, яка виконується ними для отримання деякого результату. Під отриманням результату розуміють виконання закінченої дії, наприклад, опис в термінах об'єктів, що взаємодіють, змодельованої раніше умови використання інформаційної системи або деякого сервісу, оголошеного як операція класу на відповідній діаграмі.
Діаграма співпраці зображує об'єкти, які беруть участь у взаємодії, у вигляді прямокутників, що містять ім'я об'єкту, його клас і, можливо, значення атрибутів. Асоціації між об'єктами зображуються у вигляді з’єднувальних ліній. Можлива вказівка імені асоціації і ролей об'єктів в даній асоціації. Динамічні зв'язки (потоки повідомлень) представляються у вигляді з’єднувальних ліній між об'єктами, зверху яких розташовується стрілка з вказівкою напряму і імені повідомлення.
Діаграми класів
Діаграми класів описують статичну структуру класів. До складу діаграм класів входять наступні елементи: класи, об'єкти і відношення між ними. Клас представляється прямокутником, що включає три розділи: ім'я класу, атрибути і операції. Аналогічне позначення застосовується і для об'єктів, з тією різницею, що до імені класу додається ім'я об'єкту і весь напис підкреслюється.
Допускається відображення додаткової інформації (абстрактні операції і класи, стереотипи, загальні і приватні методи, інтерфейси, і т. д.).
Асоціації, або статичні зв'язки, між класами зображуються у вигляді лінії зв'язку, на якій може вказуватися потужність асоціації, напрямок, назва, і можливе обмеження.
Можна відобразити властивості асоціації, наприклад відношення агрегації, коли складовими частинами класу є інші класи. Відношення агрегації зображується у вигляді ромба, розташованого поряд з класом, що агрегує.
Відношення узагальнення зображується у вигляді трикутника і лінії зв'язку. Це дозволяє представити ієрархію успадкування класів.
Переведення діаграм класів у програмний код.
Рис.4 - Діаграма класу Group.
Етапи переведення:
Призначити класу ім’я на основі вмісту верхнього прямокутника діаграми класів. Включити у клас конструктори та деструктор.
Включити у клас атрибути, наведені в середньому прямокутнику діаграми класів, у якості закритих членів даних.
Включити у клас операції, наведені в нижньому прямокутнику діаграми класів, у якості функцій-елементів класу.
Зразок опису класу:
class Group
{
private:
int number;
public:
Group ();
~ Group);
void SetNumber (int value);
int GetNumber ();
};
Діаграма компонент
Діаграма компонент призначена для визначення архітектури системи, що розробляється, шляхом встановлення залежності між програмними компонентами: початковим, бінарним і/або виконуваним кодом. У багатьох середовищах розробки модуль, або компонента, відповідає файлу. Пунктирні стрілки, що сполучають модулі, показують відношення взаємозалежності (як при компіляції).
Діаграми розміщення
Діаграми розміщення використовуються для визначення конфігурації компонент, процесів і об'єктів, що діють в системі на етапі виконання. Крім того, вони показують фізичну залежність апаратних пристроїв, що беруть участь в реалізації системи, і з'єднань між ними – маршрутів передачі інформації.
Відзначимо, що побудова моделі ІС до її програмної розробки є необхідним етапом проектування. Хороші моделі дозволяють налагодити конструктивну взаємодію між замовниками, користувачами і розробниками. Діаграми UML забезпечують ясне представлення архітектурних рішень для системи, що розробляється. Складність інформаційних систем росте і як наслідок зростає актуальність застосування ефективних мов моделювання, таких як UML.