Визначення вимог до системи. варіанти використання
Визначення вимог до ПО є складовою частиною процесу управління вимогами. Специфікація вимог до ПО є основним документом, що визначає план розробки ПО. Всі вимоги, визначені в специфікації, діляться на функціональні і нефункціональні. Функціональні вимоги визначають дії, які повинна виконувати система, без врахування обмежень, пов'язаних з її реалізацією. Нефункціональні вимоги не визначають поведінку системи, але описують її атрибути або атрибути системного оточення (якість призначеного для користувача інтерфейсу, продуктивність, засоби реалізації, надійність, безпеку).
Вимоги до ПО оформляються у вигляді ряду документів і моделей. Словник предметної області (глосарій) визначає загальну термінологію для всіх моделей і описів вимог до системи. Технічні вимоги містять опис нефункціональних вимог. Функціональні вимоги до системи моделюються і документацію у вигляді варіантів використання.
Аналіз та проектування програмного забезпечення
Архітектурний аналіз. Аналіз варіантів використання
Метою об'єктно-орієнтованого аналізу є трансформація функціональних вимог до ПЗ в попередній системний проект і створення стабільної основи архітектури системи.
Об'єктно-орієнтований аналіз включає два види діяльності:
· архітектурний аналіз;
· аналіз варіантів використання.
архітектурний аналіз виконується архітектором системи і включає в себе:
|
|
|
· затвердження загальних стандартів (угод) моделювання і документування системи;
· попереднє виявлення архітектурних механізмів (механізмів аналізу);
· формування набору основних абстракцій предметної області (класів аналізу);
· формування початкового уявлення архітектурних рівнів.
Угоди моделювання визначають:
· використовувані діаграми і елементи моделі;
· правила їх застосування;
· угоди по іменування елементів моделі;
· організацію моделі (пакети).
Архітектурні механізми відображають нефункціональні вимоги до системи (надійність, безпеку, зберігання даних в конкретному середовищі, інтерфейси із зовнішніми системами і т.д.) і їх реалізацію в архітектурі системи. Архітектурні механізми являють собою набір типових рішень, або зразків, прийнятих в якості стандарту даного проекту.
Ідентифікація основних абстракцій полягає у визначенні набору класів системи (класів аналізу) на основі опису предметної області та специфікації вимог до системи (зокрема, глосарію проекту).
Архітектурні рівні утворюють ієрархію рівнів подання будь-якої великої системи. Майже в будь-якій системі можна виділити такі рівні:
· прикладної, що містить набір компонентів, що реалізують основну функціональність системи;
|
|
|
· бізнес-рівень, що включає набір компонентів, специфічних для конкретної предметної області;
· проміжний (middleware), куди входять від платформи незалежні сервіси;
· системний, який містить компоненти обчислювальної та мережевої інфраструктури.
Аналіз варіантів використання виконується проектувальниками і включає в себе:
· ідентифікацію класів, що беруть участь в реалізації потоків подій;
· визначення обов'язків класів;
· визначення атрибутів і асоціацій класів;
· уніфікацію класів аналізу.
В потоках подій варіанту використання виявляються класи трьох типів:
· граничні класи, які є посередниками при взаємодії з зовнішніми об'єктами;
· класи-сутності, що представляють собою основні абстракції (поняття), що розробляється;
· керуючі класи, що забезпечують координацію поведінки об'єктів в системі.
Класи аналізу відображають функціональні вимоги до системи і моделюють об'єкти предметної області. Сукупність класів аналізу являє собою початкову концептуальну модель системи.
У процесі аналізу конкретного варіанту використання в першу чергу будується діаграма послідовності, що описує основний потік подій і його підлеглі потоки. Для кожного альтернативного потоку подій будується окрема діаграма послідовності.
|
|
|
Обов'язки кожного класу визначаються, виходячи з повідомлень на діаграмах взаємодії, і документуються в класах у вигляді «операцій аналізу». В процесі проектування кожна «операція аналізу» перетвориться в одну або більше операцій класу, які в подальшому будуть реалізовані в коді системи.
При побудові діаграм взаємодії виникають проблеми правильного розподілу обов'язків між класами. Для їх вирішення існує ряд зразків: Information Expert, Creator, Low Coupling, High Cohesion.
Атрибути класів аналізу визначаються, виходячи зі знань про предметну область, вимог до системи, глосарію і бізнес-моделі. У процесі аналізу атрибути визначаються тільки для класів-сутностей. Зв'язки між класами визначаються в два етапи. Початковий набір зв'язків визначається на основі аналізу кооперативних діаграм. Якщо два об'єкти обмінюються повідомленнями, між ними повинна бути асоціація. На другому етапі виходячи з знань про предметну область створюються асоціації між класами-сутностями.
Уніфікація класів аналізу полягає в перевірці виконання наступних умов:
· ім'я та опис кожного класу аналізу має відображати сутність його ролі в системі;
· класи з однаковим поведінкою, або представляють одне й те саме явище, повинні об'єднуватися;
· класи-сутності з однаковими атрибутами повинні об'єднуватися (навіть якщо їх поведінка відрізняється).
За результатами уніфікації класів повинні бути модифіковані опису варіантів використання.
Дата добавления: 2018-08-06; просмотров: 268; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!