Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекція 4-2 - Діаграми.doc
Скачиваний:
16
Добавлен:
19.02.2016
Размер:
124.93 Кб
Скачать

Типові прийоми моделювання

Різноманітні представлення системи. Моделювання системи із використанням різних представлень здійснюються наступним чином:

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

  2. У відношенні кожного з обраних виглядів визначіть, які артефакти необхідно створити для відображення його найбільш істотних деталей. Ці артефакти у своїй більшості будуть складатись із різних діаграм UML.

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

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

  • Вигляд з точки зору варіантів використання – діаграми прецедентів;

  • Вигляд з точки зору проектування – діаграмикласів (для структурного моделювання) та діаграми взаємодії (для моделювання поведінки);

  • Вигляд з точки зору процесів – не потрібний;

  • Вигляд з точки зору реалізації не потрібний;

  • Вигляд з точки зору розгортання – також не потрібний.

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

Якщо систему побудовано на архітектурі “клієнт/сервер”, то слід включити у роботу діаграми компонентів та розгортання для моделювання конкретних фізичних деталей реалізації.

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

  • Вигляд з точки зору прецедентів – діаграми прецедентів та діаграми діяльності (для моделювання поведінки);

  • Вигляд з точки зору проектування – діаграми класів (структурне моделювання), діаграми взаємодії (моделювання поведінки);

  • Вигляд з точки зору процесів – знову діаграми класів (структурне моделювання) та діаграми взаємодії (моделювання поведінки);

  • Вигляд з точки зору реалізації – діаграми компонентів;

  • Вигляд з точки зору розгортання – діаграми розгортання.

Різні рівні абстракції

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

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

  1. Вивчіть потреби ваших користувачів та переходьте до створення моделі.

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

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

  • Будівні блоки та відношення. Приховайте ті з них, які не відповідають передбачуваному рівню діаграми або запитам розробників;

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

  • Потік управління.В діаграмах поведінки розкривайте тільки ті повідомлення або переходи, які мають значення для розуміння ваших намірів;

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

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

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

  2. Моделі, що знаходяться на більш високому рівні, повинні містити по можливості прості абстракції, а найбільш низькому- деталізовані. Встановіть відношення трасування (Trace dependence) між зв’язаними елементами різних моделей.

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

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

Обидві діаграми відносяться до однієї й тієї ж моделі, але демонструють різні рівні деталізації

Рис. 3. діаграма взаємодії на високому рівні абстракції

Рис. 4. Взаємодія на більш низькому рівні абстракції.