І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 23

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

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

концептуальні елементи: системні функції і бізнес-процеси;

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

Система об'єктно-орієнтованих моделей відповідно до нотацій UML включає наступні діаграми:

1)     діаграму варіантів використання (Use-case diagram), що
відображає функціональність ІС у вигляді сукупності послідовностей, що
виконуються, транзакцій;

2)   діаграму класів об'єктів (Class diagram), що відображає структуру сукупності взаємозалежних класів об'єктів аналогічно до ER-діаграми функціонально-орієнтованого підходу;

3)   діаграми станів (State chart diagrams), кожна з яких відображає динаміку станів об'єктів одного класу і пов'язаних з ними подій;

4)   діаграми взаємодії об'єктів (Interaction diagrams), кожна з яких відображає динамічну взаємодію об'єктів у рамках одного прецеденту використання;

5)   діаграми діяльності (Activity diagrams), що відображають потоки робіт у взаємозалежних прецедентах використання (можуть декомпозуватися на більш детальні діаграми);

6)   діаграми пакетів (Package diagrams), що відображають розподіл об'єктів за функціональними чи забезпечувальними підсистемами (можуть декомпозуватися на більш детальні діаграми);

7)         діаграму компонентів (Component diagram), що відображає фізичнімодулі програмного коду;

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

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


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

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

У реалізації варіанта використання можливе виділення декількох потоків

подій:

основний потік подій, який приводить до необхідного результату найбільш коротким шляхом;

альтернативні потоки подій.

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

Діаграми класів об'єктів

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

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

Діаграми станів

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


які дії об'єкт виконує, коли він отримує повідомлення про зміну стану; як об'єкти створюються і знищуються (вхідні і вихідні точки діаграми).У табл. 21 наведені використовувані в діаграмі станів поняття і їх графічні позначення.

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

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


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

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

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

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

Діаграма взаємодії об'єктів

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

формою діаграми послідовностей (sequence diagram), що показує послідовність взаємодій на графі;

формою кооперативної діаграми (collaboration diagram), що показує взаємодію об'єктів у табличній формі.

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

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

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

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

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

Діаграма діяльностей

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

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

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

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

Діаграми пакетів


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

Пакетна технологія групування класів об'єктів дозволяє спростити: розробку й експлуатацію ІС;

гнучку адаптацію типових компонентів з позиції їх повторного використання;

оптимізацію клієнт-серверної архітектури ІС.Зазвичай ІС розбивається на функціональні й забезпечувальні пакети. Функціональні пакети, відповідні вирішуваним проблемам (завданням), об'єднуються в один спільний пакет "Предметна область". Кожен пакет, у свою чергу, може бути розбитий на підпакети відповідно до семантичної близькості й щільності взаємодії класів об'єктів. Зазвичай пакети предметної області містять ієрархії узагальнення й агрегації. Класи об'єктів, потрібні в декількох підсистемах, виділяються в самостійні пакети. В одному пакеті визначається не більше 20 компонентів, зазвичай 5 - 15.

Із точки зору забезпечувальних пакетів ІС розбивають на п'ять основних пакетів:

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

база даних, об'єкти якої виконують доступ до даних у зовнішній пам'яті;

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

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

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

Діаграми компонентів і розміщення

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

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

11.3.3. Технологія об'єктно-орієнтованого проектування

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

1.   Аналіз системних вимог.

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

2.   Логічне проектування.

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

3.   Фізичне проектування.

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


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

D2 - діаграма варіантів використання;


D3 - діаграма класів об'єктів; D4 - діаграма станів об'єктів; D5 - діаграма пакетів.

Умовні позначення:

D2, D2* - діаграма варіантів використання;

D3, D3* - діаграма класів об'єктів;

D4, D4* - діаграма станів об'єктів;

D5, D5* - діаграма пакетів;

D6 - діаграма взаємодії;

D7 - діаграма діяльностей.
Умовні позначення:

D3*, D3** - діаграма класів об'єктів;

D5* D5**- діаграма пакетів;

D8 - діаграма компонентів;

D9 - діаграма розміщення компонентів.

 

U1

D6

D7


 

 

 

Генерація процедур методів

 

 

1

D4**

 

 

 

 

Умовні позначення:

D3* - діаграма класів об'єктів; D4*- діаграма станів об'єктів; D6 - діаграма взаємодії; D7 - діаграма діяльностей;

U1 - універсум об'єктно-орієнтованих мов програмування;G1 - класи об'єктів;

G2 - шаблони процедур методів класу об'єктів; G3 - процедури методів.

Контрольні запитання

1.     Охарактеризуйте архітектуру CASE-систем.

2.     Розкрийте поняття предметної області, моделі предметної області.

3.     Чому потрібно проводити попереднє моделювання предметної області?

4.     Які вимоги висуваються до моделей предметної області?

5.     Які моделі відбивають структурні аспекти предметної області?

6.     Охарактеризуйте оцінні аспекти моделювання предметної області.

7.     На яких рівнях будуються моделі предметної області?

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

І О Ушакова - Соціальні мережі як засіб впливу на взаємовідносини з клієнтами

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки