- •3. Аналіз вимог і визначення специфікацій програмного забезпечення
- •3.1. Визначення вимог до програмних продуктів
- •3.1.1. Функціональні вимоги
- •3.1.2. Експлуатаційні вимоги.
- •3.2. Вибір архітектури програмного забезпечення
- •3.3. Структура і формат даних. Статичні, напівстатичні і динамічні структури
- •3.3.1. Класифікація структур даних
- •3.3.2. Прості структури даних
- •3.3.3. Статичні структури даних
- •3.3.4. Напівстатичні структури даних
- •3.3.5. Динамічні структури даних
- •3.4. Модульне програмування
- •3.4.1. Поняття модуля
- •3.4.2. Основні характеристики програмного модуля
- •3.4.3. Модульна структура програмних модулів
- •3.4.4. Методи розробки при модульному програмуванні
- •Ціленаправлена конструктивна реалізація
- •3.5. Аналіз вимог і визначення специфікацій при структурному підході
- •3.5.1. Специфікації процесів
- •3.5.2. Словник термінів
- •3.5.4. Функціональні діаграми
- •3.5.5. Діаграми потоків даних (dfd)
- •3.5.6. Діаграма сутність-зв’язок
- •3.6. Аналіз вимог і визначення специфікацій при об’єктному підході
- •3.6.1. Деякі теоретичні відомості про uml
- •3.6.2. Визначення прецедентів (варіантів використання)
- •3.6.3. Побудова концептуальної моделі предметної області
3.6.3. Побудова концептуальної моделі предметної області
Діаграми класів
Провідне місце в об’єкто-орієнтованоу підході до проектування програмного забезпечення займає розробка логічної моделі системи у вигляді діаграми класів (class diagram) [1, 48].
UML пропонує використовувати три рівня діаграм класів у залежності від ступені їх деталізації:
концептуальний рівень, на якому діаграми класів відображають зв’язки між основними поняттями предметної області;
рівень специфікацій, на якому діаграми класів відображають зв’язки об’єктів цих класів;
рівень деталізації, на якому діаграми класів безпосередньо показують поля і операції конкретних класів.
Кожну з перерахованих моделей використовують на конкретному етапі розробки програмного забезпечення:
концептуальну модель – на етапі аналізу;
діаграми класів рівня специфікації – на етапі проектування;
діаграми класів рівня реалізації – на етапі реалізації.
Діаграма класів може показувати різні взаємозв’язки між окремими сутностями предметної області, такими як об’єкти і підсистеми, а також описує їх внутрішню структуру і типи відношень. Діаграми класів зазвичай містять наступні сутності:
класи;
інтерфейси;
кооперації;
відношення залежності, узагальнення і асоціації.
Коли говорять про дану діаграму, мають на увазі статичну структурну модель проектованої системи, тому діаграму класів прийнято вважати графічним представленням таких взаємозв’язків логічної моделі системи, які не залежать від часу [48].
Клас
Клас (class) у мові UML служить для позначення множини об’єктів, які мають однакову структуру, поведінку і відношення з об’єктами інших класів. На діаграмі клас зображують у вигляді прямокутника, який додатково може бути розділений горизонтальними лініями на дві чи три секції (рис. 3.40). В цих розділах можуть вказуватись ім’я класу, атрибути (змінні) і операції (методи). Інколи в графічному зображенні класу додається четверта секція, яка містить описання виключних ситуацій.
Обов’язковим елементом позначення класу є його ім’я. на початкових етапах розробки діаграми клас може позначатись простим прямокутником з вказуванням тільки його імені (рис. 3.40, а). В подальшому діаграми описання класів доповнюються атрибутами (рис. 3.40, б) і операціями (рис. 3.40, в).
Щоб відрізнити клас від інших елементів мови UML, секцію атрибутів і операцій виділяють горизонтальною лінією, навіть якщо вона є порожньою. На рис. 3.41 наведені приклади графічного зображення класів на діаграмі класів. В першому випадку для класа «Прямокутник» (рис. 3.41, а) вказані тільки його атрибути – точки на координатній площині, які визначають його місцеположення. Для класу «Вікно» (рис. 3.41, б) вказані тільки його операції (показати(), скрити()), секція атрибутів залишена порожньою. Для класу «Рахунок» (рис. 3.41, в), крім операції перевірки кредитної карточки зображена четверта секція, в якій вказано виключення – відмова від обслуговування простроченої кредитної карточки.
Ім’я класу
Ім’я класу повинно бути