Моделі предметної області і декомпозиція

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

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

Ідентифікація концептуальних класів

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

Концептуальні класи без атрибутів цілком припустимі, як припустими і концептуальні класи, що грають «поведінкову», а не інформаційну роль у предметній області.

Для виділення концептуальних класів можна застосовувати різні прийоми:

- використання списку категорій концептуальних класів,

- на основі виділення іменників,

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

Розглянемо використання списку категорій. Приклади дані з області торгівлі і резервування авіаквитків.

Табл. 1 Список категорій концептуальних класів

Категорія концептуальних класів	Приклади
Фізичні або матеріальні об'єкти	Register (реєстр) Airplane (літак)
Специфікації, елементи проектних рішень або описи об'єктів	Product specification (специфікація товару) Flight Description (опис польоту)
Місця	Store (магазин) Airport (аеропорт)
Транзакції	Sale (продаж), Payment (платіж) Reservation (резервування)
Елементи транзакції	SaleslineItem (елемент продажу)
Ролі людей	Cashier (касир) Pilot (пілот)
Контейнери інших об'єктів	Store (магазин) Airplane (літак)
Вміст контейнерів	Item (елемент) Passenger (пасажир)
Інші комп'ютери або система, зовнішні стосовно даної системи	CreditPaymentAuthorizationSystem (система авторизації платежів) AirTrafficControl (система керування рухами)
Абстрактні поняття	Hunger (голод)
Організації	SalesDepartament (відділ продажів) Object Airline (авіалінії)
Події	Sale (продаж), Payment (платіж) Flight (поле), Landing (приземлення)
Процеси (найчастіше не представляються у виді понять)	SallingAproduct (продаж продукту) BookingASeat (бронування місця)
Правила і політика	RefundPolicy (правила повернення товару) CancellationPolicy (політика анулювання замовлення)
Каталоги	ProductCatalog (каталог товарів) Partscatalog (каталог частин)
Записки фінансової, трудової, юридичної й іншої діяльності	Receipt (чек), Lenger (гросбух) MainFenanceLog (журнал обслуговування)
Фінансові інструменти і служби	LineofCredit (кредитна лінія) Stock (акція)
Керівництва, документи, статті, книги	DailyPriceChangeList (бюлетень щоденної зміни цін) RepaireManual (посібник із відновлення)

Приклад міркувань про вмикання деякого документа в модель (на прикладі товарного чеки - Receipt).

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

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

3. Товарний чек виконує конкретну роль при реалізації бізнес-правил: звичайно він забезпечує право на повернення товару. Цей чинник говорить про користь умикання його в модель предметної області.

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

Типова помилка при виділенні концептуальних класів

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

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

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

Необхідність специфікацій при описі концептуальних класів

Нехай термін Item (товар) представляє концептуальний клас і має атрибути: ідентифікатор, ціну й опис. Тоді, якщо весь товар якогось типу буде проданий, то неможливо буде відновити його ціну.

Проблема вирішується шляхом уведення концептуального класу «Специфікація товару» (Product specification), що містить інформацію про товар. Тепер навіть при продажі всіх товарів і видалення з пам'яті всіх програмних елементів Item, поняття Product specification залишається в пам'яті ЕОМ. У моделі предметної області зв'язок між специфікацією поняттям, що описується, позначається таким чином:

Product specification описує Item.

Рис. 2. Специфікація

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

У концептуальний клас специфікації вводиться в таких випадках:

• існує необхідність опису елементів або служб незалежно від існування конкретних екземплярів цих об'єктів.

• Якщо видалення екземплярів понять, що їм описуються (наприклад, Item), приводить до утрати важливої інформації в зв'язку з некоректною асоціацією цієї інформації з екземпляром, щовидаляється.

• Якщо при наявності поняття усувається дублювання інформації.

Узгодження термінології, прийнятої в різних методах і UML.

Мова UML описує типи діаграм, наприклад, діаграми класів або послідовностей. Вона не прив'язана ні до якого методу моделювання.

Розглянемо деякі терміни, зв'язані з уніфікованим процесом розробки і використовувані в UML.

• Концептуальний клас - поняття з реального світу. Розглядається в концептуальному ракурсі. У рамках UР модель предметної області містить концептуальні класи.

• Програмний клас - клас, що представляє специфікацію або реалізацію програмного компонента, незалежно від процесу або методу.

• Клас проектування - елемент моделі проектування UР. Це синонім програмного класу.

• Клас - у мові UML - це загальний клас, що представляє або поняття реального світу, або програмну сутність.

Модель предметної області: додавання асоціацій

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

Асоціація (association) - це зв'язок між типами, що відбиває деяке значиме і корисне відношення між ними.

У мові UML асоціації описуються як «семантичні взаємозв'язки між двома або декількома класифікаторами їхніми екземплярами».

Асоціація позначається проведеної між класами лінією, із яким зв'язане визначене ім'я.

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

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

Рис. 3. Позначення асоціацій у мові UML