2012_Посібник_з_дисципліни_ТКП
.pdf41
Концептуальні класи без атрибутів цілком припустимі, як припустимі і концептуальні класи, що грають «поведінкову», а не інформаційну роль в предметної області.
Стратегії ідентифікації концептуальних класів
Два способи виявлення концептуальних класів:
1.З використанням списку категорій концептуальних класів.
2.На основі виділення іменників.
Для моделювання предметної області застосовується і інший чудовий прийом - шаблони аналізу. Шаблони - це готові моделі предметної області, створені фахівцями.
Таблиця 2.3 - Використання списку категорій концептуальних класів
Категорія |
Приклади |
|
концептуальних класів |
|
|
|
|
|
Фізичні і матеріальні |
Register(Реєстр), Airplane(Літак) |
|
об’єкти |
|
|
|
|
|
Специфікації, елементи |
ProducSpecification(Специфікація товару ) |
|
проектних рішень чи |
FilightDescription(Опис польоту) |
|
опису об’єктів |
||
|
||
|
|
|
Місця |
Store(Магазин) |
|
|
Airport(Аеропорт) |
|
|
|
|
Транзакції |
Sale(Продаж), Payment(Платіж), |
|
|
Reservation(Резервування) |
|
|
|
|
Елементи транзакції |
SaleLineItem(Елементи продаж) |
|
|
|
|
Ролі людей |
Cashier(Касир), |
|
|
Pilot(Пілот) |
|
|
|
|
Контейнери інших |
Store(Магазин), Bin(Бункер), Airplane(Літак) |
|
об’єктів |
|
|
|
|
|
Вміст контейнерів |
Item(Елемент), Passenger(Пасажир) |
|
|
|
|
Інші комп’ютери чи |
CreditPaymentautorizationSystem(Система авторизації |
|
електромеханічні |
кредитних платежів) |
|
системи, зовнішні по |
AirTrafficControl(Система управління рухом) |
|
відношенню до даної |
||
|
||
системи |
|
|
|
|
Визначення концептуальних класів за допомогою виявлення іменників
Основний успішний сценарій (або основний процес):
1.Покупець підходить до касового апарату POS-системи з вибраними товарами.
2.Касир відкриває нову продаж,
3.Касир вводить ідентифікатор товару.
4.Система записує найменування товару і видає його опис, ціну та загальну вартість.
5.Ціна обчислюється на основі набору правил, Касир повторює дії, описані в пп. 3-4 для кожного найменування товару.
6.Система обчислює загальну вартість покупки з податком.
7.Касир повідомляє покупцеві загальну вартість і пропонує сплатити покупку.
42
8.Покупець оплачує покупку, система обробляє платіж.
9.Система реєструє продаж, відправляє інформацію про неї зовнішньої бухгалтерської системі.
Модель предметної області - це візуалізація важливих понять зі словника предметної області.
П: Звідки брати необхідні терміни? В: З опису прецедентів.
Ці описи - багате джерело для ідентифікації іменників.
Одні з цих іменників можуть бути представлені у вигляді концептуальних класів, інші можуть представляти концептуальні класи, не мають відношення до даної ітерації (наприклад, «бухгалтерська система» або «комісійні» ), а треті - у вигляді атрибутів цих концептуальних класів.
Принципи створення моделі предметної області
1.Складіть список кандидатів на роль концептуальних класів на основі списку категорій і методу, аналізу текстового опису для поточної ітерації розробляння.
2.Відображення їх в моделі предметної області.
3.Додайте необхідні асоціації, що відображають зв'язку, для яких потрібно виділення пам'яті.
4.Додайте атрибути, необхідні для виконання інформаційних вимог (обговорюється в наступному розділі).
5.Імена і моделі: стратегія побудови карт.
6.Використовувати застосовуються на даній території назви.
7.Виключати несуттєві деталі.
8.Не додавати об'єкти, які існують на цій території.
Розглянемо деякі терміни, пов'язані з уніфікованим процесом розробляння і використовувані в UML.
Концептуальний клас - поняття з реального світу. Розглядається в концептуальному ракурсі. В рамках UP модель предметної області містить концептуальні класи.
Програмний клас - клас, що представляє специфікацію або реалізацію програмного компонента, незалежно від процесу або методу.
Клас проектування - елемент моделі проектування UP. Це синонім програмного класу, однак з певних причин автору хотілося акцентувати увагу на тому, що даний клас має відношення до моделі проектування. В контексті UP класи проектування відносять або до ракурсу специфікації або до реалізації.
Клас реалізації - клас, реалізований на об'єктно-орієнтованій мові, наприклад на
Java.
Клас - у мові UML - це загальний клас, що представляє або поняття реального світу (концептуальний клас), або програмну сутність (програмний клас).
43
Рисунок 2.11 - Приклади артефактів
Питання для самоперевірки
1.Що таке модель предметної області?
2.З якою метою створюють модель предметної області ?
3.Які основні принципи створення моделі предметної області ?
4.Що таке концептуальний клас ?
5.Яка різниця між концептуальним класом, програмним класом та класом проектування ?
44
Література: [2, с.147-188]; Завдання на СРС: [9, с. 120-130].
45
2.4 Шаблони проектування
Структура теми :
–Шаблоны GRASP
–Шаблон Information Expert
–Шаблон Creator
–Шаблон High Cohesion
–Шаблон Low Coupling
Шаблоны GRASP
Шаблони GRASP (General Responsibility Assignment Software Patterns) дозволяють зрозуміти принципи об'єктного проектування. Такі шаблони ще називають шаблонами розподілу обов'язків
В UML зобов'язання позначається як resposibility. Описують поведінку об'єктів.
2основних типи:
1.Знання (knowing)
2.Дія (doing)
Обов’язки типу doing
–виконання дій самим об'єктом (наприклад: створення екземпляра, виконання розрахунку);
–ініціювання дій інших об'єктів (наприклад: отримати стан рахунку);
–управління діями інших об'єктів і їх координація.
Обов’язки типу knowing
–наявність інформації про закриті інкапсульовані дані;
–наявність інформації про зв’язані об'єкти;
–наявність інформації про наслідки і обчислювані величини.
Досвід розробників об'єктно-орієнтованих систем сформулювали загальні принципи і рішення в розробці ПЗ. Принципи структурували і структурували, далі розділили на шаблони з іменами. Шаблон повинен містити інформацію про застосування в різних ситуаціях.
Шаблон – це - а. Іменування пара «проблема / рішення».
б. Шаблон одного розробника - будівельний блок іншого розробника в. Шаблони не містять нових ідей
Шаблон Information Expert
Проблема: який найбільш загальний принцип розподілу обов'язків в об'єктноорієнтованому проектуванні?
Рішення: призначити обов'язок акумуляції інформаційному експерту - класу у якого є інформація, необхідна для виконання обов'язків.
Рекомендації: Інформаційним експертом може бути не один клас, а кілька.
Приклад
Необхідно розрахувати загальну суму продажі. Існують класи проектування "Продаж", "ТоварПродажа" (продаж окремого виду товару в рамках продажу в цілому), "ТоварСпеціфікація" (опис конкретного виду товару).
Необхідно розподілити обов'язки з надання інформації і розрахунку між цими класами.
46
Рисунок 2.12 – Діаграма класів
Рисунок 2.13 – Результат застосування патерну Information Expert
При призначенні обов'язків застосовується принцип: обов'язки зв'язуються з тим об'єктом, який має інформацію необхідну для виконання.
Обов'язки:
Клас Продаж: знання загальної суми продажу Клас ТоварПродажа: знання проміжної суми для даного товару Клас ТоварСпеціфікація: Знання ціни товару
Шаблон Creator
Проблема: хто має відповідати за створення нового екземпляра деякого класу? Рішення: Призначити класу В обов'язок створювати об'єкти іншого класу А
Рекомендації: Логічно використовувати шаблон якщо клас В містить, агрегує, активно використовує і т.п. об'єкти класу А.
Необхідно визначити, який об'єкт повинен відповідати за створення екземпляра «ТоварПродаж».
Логічно, щоб це був об'єкт «Продаж», оскільки він містить (агрегує) кілька об’єктів «ТоварПродаж»
47
Рисунок 2.14Результат застосування патерну Creator
Шаблон High Cohesion
Проблема: Забезпечити низьку зв'язаність при створенні екземпляра класу і зв'язуванні його з іншим класом.
Рішення: Розподілити обов'язки між об'єктами так, щоб ступінь пов'язаності залишалася низькою.
Ступінь зв'язності: міра, визначальна наскільки жорстко один елемент пов'язаний з іншими. Низька зв'язність, коли залежить не від великої кількості інших об'єктів.
Необхідно створити екземпляр класу «Платіж». У предметної області реєстрація об'єкта «Платіж» виконується об'єктом «Реєстрація» (ведеться реєстр).
Способи створення екземпляра класу «Платіж».
Верхній малюнок - з використанням патерну «Creator», нижній - з використанням «Low Coupling». Останній спосіб забезпечує більш низьку ступінь зв'язування.
48
Рисунок 2.15 – Результат застосування патернів «Creator» та «Low Coupling».
Шаблон Low Coupling
Проблема: Необхідно забезпечити виконання об'єктами різнорідних функцій. Рішення: Забезпечити розподіл обов'язків з високим зачепленням.
Рішення: елемент з високим ступенем зачеплення - якщо його обов'язки тісно пов'язані між собою і він не виконує непомірних обсягів робіт.
На клас «Реєстрація» покладати все нові і нові системні функції, пов'язані з системними операціями. Даний клас буде занадто перевантажений і буде володіти низьким ступенем зачеплення.
Нижній малюнок має більш високим рівнем зачеплення і низьким рівнем зв'язування (він є кращим) (див. рис.2.5).
Питання для самоперевірки
1.Що таке шаблон проектування?
2.Для чого потрібні шаблони проектування?
3.Яке призначення шаблонів розподілу обов’язків ?
4.Призначення шаблонів Information Expert, Creator?
5.Назвіть основні відмінності між шаблонами Creator та «Low Coupling».
Література: [2, с.223-252];
Завдання на СРС: [14, с. 25-44].
49
3Структурний підхід в ТП
3.1Огляд методологій та технологій структурного аналізу
Структура теми :
–Технологія структурного аналізу та проектування SADT.
–Огляд методологій та технологій IDEF.
Технологія структурного аналізу та проектування SADT.
SADT( Structured Analysis and Design Technique) методологія структурного аналізу і проектування, у майбутньому використовується сімейство методологій IDEF.
Огляд методологій та технологій IDEF.
IDEF - Скорочення від Integration Definition Methodology (Об'єднання Методологічних Понять), методології сімейства ICAM (Integrated Computer-Aided Manufacturing) для вирішення завдань моделювання складних систем, дозволяють відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.
Історія виникнення методології IDEF
Для опису процесів у світі розроблено велику кількість різних підходів і методів. На початку 70-х років Д. Росс в США запропонував метод структурного проектування та аналізу систем SADT (Structured Analysis and Design Techniques). В основі цього підходу лежить графічна мова опису (моделювання) систем. Перше її маштабне застосування було в 1973 р. при розробці великого аерокосмічного проекту. До 1981 р. SADT вже використали більш ніж в 50 компаніях при роботі більш ніж над 200 проектами, що включали понад 2000 людей і охоплювали дюжину проблемних областей, в тому числі телефонні мережі, аерокосмічне виробництво, управління і контроль, облік матеріальнотехнічних ресурсів та обробку даних.
У середині 70-х ВПС США реалізували програму інтегрованої комп'ютеризації виробництва ICAM (Integrated Computer Aided Manufacturing). В рамках цієї програми були розроблені методи проектування та аналізу складних виробничих систем, а також способи обміну інформацією між фахівцями, що займаються такими проблемами. Для задоволення цих потреб в рамках програми ICAM була розроблена методологія IDEF (ICAM Definitions), що дозволяє представити і дослідити структуру, параметри та характеристики виробничо-технічних і організаційно-економічних систем. Процеси, що описують діяльність організації, відносяться саме до цього класу систем.
IDEF-технологія використовується, починаючи з кінця 1980-х років. Міністерство оборони США є основним користувачем даної технології. Їй, також, користуються деякі крупні корпорації в США.
IDEF0
DEF0 - методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 представляє досліджувану систему у вигляді набору взаємопов'язаних функцій («функціональних блоків»).
Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи.
IDEF1, IDEF1X
IDEF1 - методологія моделювання інформаційних потоків усередині системи. Дозволяє відображати та аналізувати їх структуру і взаємозв'язок;
IDEF1X (IDEF1 Extended) - методологія побудови реляційних структур.
50
IDEF1X відноситься до типу методологій «Сутність-взаємозв'язок» (ER - EntityRelationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до даної системи.
IDEF2
IDEF2 - методологія динамічного моделювання розвитку систем. Через серйозні труднощі, пов'язані з аналізом динамічних систем, від цього стандарту зараз практично відмовилися, і його розвиток призупинився на самому початковому етапі.
Існуючі алгоритми та їх комп'ютерні реалізації дозволяють перетворювати набір статичних діаграм IDEF0 у динамічні моделі, побудовані на базі «розфарбованих мереж Петрі» (CPN - Color Petri Nets).
IDEF3
IDEF3 - методологія документування процесів, що відбуваються в системі.
За допомогою IDEF3 описуються сценарій та послідовність операцій для кожного процесу. IDEF3 безпосередньо пов'язана з методологією IDEF0: кожна функція (функціональний блок) може бути представлена засобами IDEF3 у вигляді окремого процесу.
IDEF4
IDEF4 - методологія побудови об'єктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів та принципи їх взаємодії, дозволяючи аналізувати й оптимізувати складні об'єктно-орієнтовані системи.
Рисунок 3.1 - Представлення IDEF4
IDEF5
IDEF5 - методологія онтологічного дослідження складних систем. За допомогою словника термінів і правил дозволяє описати онтологію системи. У результаті можуть бути сформовані достовірні твердження про стан системи в певний момент часу, на основі яких робляться висновки про подальший розвиток системи і провадиться її оптимізація.
IDEF6
IDEF6 (Design Rational Capture Method) - даний метод дозволяє використовувати раціональний досвід проектування, що сприяє запобіганню структурних помилок.
Призначення IDEF6 полягає в полегшенні отримання «знань про спосіб» моделювання, їх представлення і використання при розробці систем управління підприємствами. Метод IDEF6 акцентує увагу саме на процесі створення моделі;