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

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. Діаграма діяльності