- •1. Короткі теоретичні зведення
- •Типи вимог
- •Моделі предметної області і декомпозиція
- •Список стандартних асоціацій
- •Ім'я Типу - Дієслівна Фраза - ім'я типу
- •Моделювання атрибутів Кількість і одиниця виміру (Quantity і Unit).
- •Позначення класів і екземплярів об'єктів
- •Основні позначення діаграм кооперації
- •Завдання до курсової роботи
- •3. Порядок виконання курсової роботи
- •4 Зміст пояснювальної записки
- •Література
Список стандартних асоціацій
Табл. 2 Список стандартних асоціацій.
Категорія |
Приклади |
А является фізичною частиною В |
Крило - літак |
А являеться логічною частиною В |
Елемент продажу - продаж |
А фізично міститься в/на У |
Пасажир - літак |
А логічно міститься в В |
Опис товару - каталог |
А является описом В |
Опис товару - товар |
А є елементом транзакції або звіту В |
Елемент продажу - продаж |
А відомий /зареєстрований/ записаний/ включений в В |
Продаж - реєстр |
А являеться членом В |
Касир - магазин |
А являеться організаційною одиницею В |
Відділ - магазин |
А використовує або управляє В |
Пілот - літак |
А взаємодіє з В |
Покупець - касир |
А зв'язаний із транзакцфєю В |
Покупець - платіж |
А є транзакцією, що зв'язана з іншою транзакцією |
Платіж - продаж |
А випливає за В |
Найменування товару - наступне найменування товару |
А являеться власністю В |
Реєстр - магазин |
А є подією, зв'язаною з В |
Продаж - Покупець, Продаж - магазин |
У приведеній таблиці є категорії асоціацій із високим пріоритетом, що надзвичайно корисно включати в модель предметної області:
А є фізичною або логічною частиною В,
А фізично або логічно міститься в/на В,
А записаний у В.
Деякі рекомендації по призначенню асоціацій:
основну увагу потрібно приділити тим асоціаціям, знання про які потрібно зберегти протягом деякого періоду (важливим асоціаціям);
набагато важливіше визначити концептуальні класи, чим виділити асоціації;
занадто велика кількість асоціацій приводить до помилок у моделі предметної області;
уникайте відображення надлишкових або асоціацій, що не мають самостійного значення.
Кожний кінець асоціацій називається роллю (role). Роль додатково може мати наступні характеристики:
ім'я,
кратність,
напрямок зв'язку.
Кратність (multiplicity) визначає скільки екземплярів класу А може бути асоційоване з одним екземпляром класу В. Наприклад, один екземпляр класу Store (магазин) може бути асоційований із декількома екземплярами класу Item.
Мал.4. Значення кратності
Кратність визначається для деякого конкретного моменту, а не на всьому проміжку часу.
Імена асоціацій використовують формат.
Ім'я Типу - Дієслівна Фраза - ім'я типу
Між двома типами може бути заставлено декілька асоціацій.
Рис.5. Декілька асоціацій
На стадії створення моделі предметної області асоціація не є описом потоку даних, екземплярів змінних або взаємодії об'єктів програмної системи. Вона являє собою лише опис значимого відношення, що має чисто концептуальний зміст, почерпнутий із реального світу.
Після аналізу списку стандартних асоціацій складаємо модель предметної області.
Модель предметної області: додавання атрибутів
Атрибут (attribute) - це абстрактна властивість об'єкта.
У модель предметної області включаються ті атрибути, для яких визначені відповідні вимоги (наприклад, прецеденти) або для котрих необхідно берегти визначену інформацію. Наприклад, у товарному чеку звичайно вказується дата і час. Ця інформація необхідна менеджеру компанії.
У UML атрибути розміщаються в другому поділі умовного позначення класу. Додатково може бути також зазначений тип атрибута.
Рис.6. Клас і його атрибути
Атрибути повинні бути простими. Типи простих атрибутів у більшості випадків розглядаються як примітивні типи даних.
До стандартних типів атрибутів відносяться : Boolean, Date, Number, String (Text), Time.
Стандартними типами також можуть бути : Address, Color, Phone number, Social Security Number (номер страхового поліса)
Деякі сутності набагато зручніше представити не у виді атрибутів, а у формі асоціацій.
Вимога простих типів для атрибутів не поширюється на реалізацію, наприклад, класів у мовах С++ і Java. Модель предметної області не акцентує увагу на програмних сутностях. Надалі деякі асоціації можуть бути реалізовані даними-членами класів.
Атрибути не повинні використовуватися для зв'язку концептуальних класів у моделі предметної області. Найбільше поширеним різновидом порушення цього принципу є додавання деякого різновиду атрибута зовнішнього ключа, що звичайно робиться в реляційних базах даних.
