2012_Посібник_з_дисципліни_ТКП
.pdf
21
2.Опишіть ЖЦ будь-якої системи.
3.Які існують стадії життєвого циклу систем?
4.Яке призначення кожної із стадії ?
5.Опишіть основні групи процесів ЖЦ систем.
6.Які основні етапу процесу розробляння ?
7.Які основні цілі процесу розробляння ?
Література: [1]; [3, c. 46-55];
Завдання на СРС: [2, c. 43-56].
1.3 Моделі життєвого циклу
Структура теми :
–Різновиди моделей життєвого циклу.
–Рекомендації вибору моделі життєвого циклу на основі характеристик вимог.
Різновиди моделей життєвого циклу
Каскадна модель – послідовний перехід на наступний етап після завершення попереднього
Рисунок 1.5 – Каскадна модель ЖЦ
Ітераційна модель – передбачає ітераційні повернення для перегляду раніше сформованих вимог, проектних рішень та реалізацій.
Рисунок 1.6 - Ітераційна модель ЖЦ
22
Спіральна модель – передбачає створення та розширення програмних прототипів, повторюючи шлях від деталізації вимог до деталізації програмного коду.
Рисунок 1.7 - Спіральна модель ЖЦ
V- подібна модель допомагає команді планувати із забезпеченням подальшої можливості тестування системи. У цій моделі особливе значення надається діям, спрямованим на верифікацію та атестацію продукту.
Рисунок 1.8 - V-подібна модель
Інші моделі життєвого циклу:
Еволюційна модель прототипування. Rapid Application Development.
Інкрементна модель
23
Рекомендації вибору моделі життєвого циклу на основі характеристик вимог.
Таблиця 1.1 - Рекомендації вибору моделі життєвого циклу
Вимоги |
Каскадна |
V- |
Прототи |
Спіраль |
RA |
Інкреме |
|
|
подібна |
пування |
на |
D |
нтна |
|
|
|
|
|
|
|
Чи є вимоги легко визначених |
Так |
Так |
Ні |
Ні |
Так |
Ні |
та /або добре відомими? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Чи можуть вимоги заздалегідь |
Так |
Так |
Ні |
Ні |
Так |
Так |
визначатися в циклі? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Чи часто будуть змінюватися |
Ні |
Ні |
Так |
Так |
Ні |
Ні |
вимоги в циклі? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Чи потрібно демонструвати |
Ні |
Ні |
Так |
Так |
Так |
Ні |
вимоги з метою визначення? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Чи потрібні для демонстрації |
Ні |
Ні |
Так |
Так |
Так |
Ні |
можливостей перевірка |
|
|
|
|
|
|
концепції? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Чи будуть вимоги |
Ні |
Ні |
Так |
Так |
Ні |
Так |
відображати складність |
|
|
|
|
|
|
системи? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Чи володіє вимога |
Ні |
Ні |
Так |
Так |
Так |
Так |
функціональними |
|
|
|
|
|
|
властивостями на ранньому |
|
|
|
|
|
|
етапі? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Питання для самоперевірки
1.Для яких системи краще використовувати каскадну модель життєвого циклу ЖЦ ? Наведіть приклад.
2.Для яких системи краще використовувати ітераційну модель життєвого циклу ЖЦ ? Наведіть приклад.
3.Для яких системи краще використовувати спіральну модель життєвого циклу ЖЦ ? Наведіть приклад.
4.Назвіть переваги та недоліки кожної із моделей ЖЦ.
5.Назвіть відмінності між ітераційною та спіральною моделлю ЖЦ.
24
Література: [2, с.33-41]; [5, c. 16-25];
Завдання на СРС: [9, c. 17-26]; [6, глава 1];
25
1.4 Основні підходи проектування
Структура теми :
–Методології проектування.
–Основи методології структурного аналізу та проектування (SADT).
–Основи об’єктно-орієнтованого проектування.
–Підходи проектування:
Методології структурного проектування.
Об’єктно-орієнтований підхід. В якості основної мови моделювання використовується UML.
Методологія SADT. Методологія, розроблена спеціально для того, щоб полегшити опис і розуміння штучних систем, що потрапляють у розряд середньої складності.
SADT була створена і випробувана на практиці в період з 1969 по 1973 р. Опис системи за допомогою SADT називається SADT-моделлю.
Мета моделювання (Purpose)
Модель не може бути побудована без чітко сформульованої мети. Мета повинна відповідати на такі запитання:
1.Чому цей процес повинен бути змодельований ?
2.Що повинна показувати модель?
3.Що може отримати читач?
Суб'єкт моделі - сама система. Обмежуючи суб'єкт, SADT-модель допомагає сконцентрувати увагу саме на описуваної системі і дозволяє уникнути включення сторонніх суб'єктів.
SADT вимагає, щоб модель розглядалася весь час з однієї і тієї ж позиції (точки
зору).
Модель SADT об'єднує і організує діаграми в ієрархічні деревоподібні структури, при цьому чим вище рівень діаграми, тим вона менш деталізована.
Функціональна модель представляє з необхідною ступенем деталізації систему функцій, які в свою чергу відображають свої взаємини через об'єкти системи.
Основи об’єктно-орієнтованого проектування
Об'єкти і класи:
Клас - дескриптор множини об'єктів, що володіють однаковим набором атрибутів і операцій. Він служить як шаблон (template) для створення об'єктів. Кожен об'єкт, створений за шаблоном, містить значення атрибута, що відповідають типу атрибута,
n EA 9.0 UnregisteredвизначенимTrialв класіVersion, і може викликати операції, визначені в класі
class System
n EA 9.0 Unregistered Trial Version
-Атрибути
n EA 9.0 Unregistered Trial Version
n EA 9.0 Unregistered Trial Version
Атрибути
n EA 9.0 UnregisteredЗначенняTrial, щоVersionхарактеризує об'єкт в його класі. n EA 9.0 Unregistered Trial Version
n EA 9.0 Unregistered Trial Version
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistered Trial Version |
||||
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistere |
|||
EA 9.0 Unregistered Trial Version |
26 |
|
|
||
EA 9.0 Unregistered Trial Version |
|||||
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistere |
|||
class System |
|
|
|
|
|
EA 9.0 Unregistered Trial Version |
class System |
|
|||
EA 9.0 Unregistered Trial Version |
|||||
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistere |
|||
|
Предмет |
|
|
|
|
- |
НомерКурсу :=17 |
|
|
Замовлення |
|
EA 9.0- |
НазваКурсу=Проектування ІС |
|
EA 9.0 Unregistered Trial Version |
||
Unregistered Trial Version |
|||||
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistere |
|||
- |
Викладач :Identity=F0145 |
|
- |
НомерЗамовлення :int |
|
|
- |
ДатаЗамовлення :Date |
|||
|
|
|
|||
+ |
Встановити назву предмета() :st ing |
|
- |
СумаЗамовлення :Currency |
|
|
EA 9.0 Unregistered Trial Version |
||||
EA 9.0 Unregistered Trial Version |
|||||
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistered Trial Version |
EA 9.0 Unregistere |
|||
|
|
Рисунок 1.10 - Приклад класу |
|
|
|
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere
Види відносин між класами:
Асоціація встановлює зв'язок між об'єктами даних класів
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere
Рисунок 1.11 - Приклад асоціації між класами
Порядок асоціації визначає кількість класів, сполучених за допомогою асоціації.
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere
Рисунок 1.12 - Порядок асоціацій
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere
Кратність асоціації визначає кількість об'єктів, що можуть займати позицію,
вказану ролевим ім'ям.
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionEA 9.0 Unregistere
EA 9EA.0 Unregistered9.0 UnregisteredTrialTrialVersionVersionРисунокEA 9EA.10.13Unregistered9-.0КратністьUnregisteredасоціаційTrialTrialVersionVersionEA 9.0 Unregistere
Агрегація і композиція
Агрегація - це відношення типу «частина» - «ціле» між класом, який представляє збори компонент (клас-супермножина (superset class)), і класами, що представляють компоненти (класи-підмножини (subset class)).
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
27 |
|
|
|
|
|
||||||||||||||
|
|
|
|
|
|
|||||||||||||||
|
|
class System |
|
|||||||||||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Книга |
|
|
|
|
||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
+складається з |
|
n |
|
|
|
|
|
||||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+є частиною |
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Частина |
|
|
|
|
|||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
n |
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Розділ |
|
|
|
|
||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
класів |
||
|
|
|
|
|
Рисунок 1.14 - Композиція |
|||||||||||||||
|
|
|
|
|
class System |
|
||||||||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ящик |
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
tered Trial Version |
|
|
|
|
|
|
Бутилка пива |
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рисунок 1.15 - Агрегація класів |
|||||||||||||||||
|
|
|
|
|||||||||||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Узагальнення |
|||||||||||||||||||
tered Trial Version |
Узагальненням (generalization) є видове відношення між більш загальним класом |
|||||||||||||||||||
|
||||||||||||||||||||
(суперклас або батьківський клас) і більш специфічним видом класу (підклас або дочірній |
||||||||||||||||||||
tered Trial Versionклас). Підклас є видом суперкласу. |
||||||||||||||||||||
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tered Trial Version |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рисунок 1.16 - Відношення узагальнення
28
Питання для самоперевірки
1.Які основні відмінності між методологією структурного та об’єктноорієнтованого проектування.
2.Яка головна мета структурного проектування ?
3.Яка головна мета об’єктно-орієнтованого проектування ?
4.Які основні переваги та недоліки структурного підходу ?
5.Які основні переваги та недоліки об’єктно-орієнтованого підходу?
Література: [2, с.33-41]; [5, c. 16-25];
Завдання на СРС: [9, c. 17-26]; [6, глава 1];
29
2Використання UML у процесі об’єктно-орієнтованого проектування
2.1Опис прецедентів
Структура теми :
–Прецеденти типу «Чорний ящик» та «Білий ящик».
–Ступінь формалізації прецедентів.
–Передумови та постумови.
–Успішний сценарій та альтернативні потоки.
–Місце прецедентів при проектуванні
Рисунок 2.1 - Схема бізнес моделювання
30
Прецеденти типу «чорний ящик»
Системі ставляться обов'язки (responsibilities), програмні елементи мають обов'язки
івзаємодіють з іншими елементами через обов'язки.
Упроцесі аналізу вимог потрібно уникати ухвалення рішень «як», а описувати лише зовнішню поведінку системи як чорного ящика (відповісти на питання «що»).
Software Engineering Body of Knowledge (SWEBOK)