Об'єктно-орієнтована програмна система для управління проектами

Помилка кількості  файлів

Такий проект вже існує

Варіант використання "Закрити проект"

Короткий  опис:

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

Варіант використання "Коментувати помилки"

Короткий  опис:

Даний варіант використання описує створення коментарів помилок тестувальником для учасника, який повинен вирішити помилки

Альтернативні потоки:

Не правильно  заповнені поля

Варіант використання "Почати задачу"

Короткий  опис:

Даний варіант використання описує змінення статусу задачи в проекті на статус Почато

Альтернативні потоки:

Задача вже  почата

Варіант використання "Закрити задачу"

Короткий  опис:

Даний варіант використання описує змінення статусу задачи в  проекті на статус Закрито

Альтернативні потоки:

Задача вже закрита

Варіант використання "Визначити час"

Короткий  опис:

Даний варіант використання описує змінення шкали прогресу задачі

Варіант використання "Перенаправити задачу"

Короткий  опис:

Даний варіант використання описує змінення виконуючого учасника задачі

Варіант використання "Настроїти проект"

Короткий  опис:

Даний варіант використання описує змінення даних про проект, його під проектів, задач, та інших налаштувань

Варіант використання "Назначити учасників на проект "

Короткий  опис:

Даний варіант використання описує додавання, змінення, видалення учасників проекту

Альтернативні потоки:

Учасник вже  додан

Учасник вже  видалений

Варіант використання "Створити версії проекту"

Короткий  опис:

Даний варіант використання описує створення версій проекту

Альтернативні потоки:

Не заповнені  поля

Варіант використання "Створити категорії задачі"

Короткий  опис:

Даний варіант використання описує створення категорій задач в проекті

Альтернативні потоки:

Не заповнені  поля

Варіант використання " Створити wiki сторінку"

Короткий опис:

Даний варіант використання описує створення wiki сторінки

Альтернативні потоки:

Не заповнені  поля

Така сторінка вже існує

 

Варіант використання "Створити форум"

Короткий  опис:

Даний варіант використання описує створення постів у форумі

Альтернативні потоки:

Не заповнені  поля

Така назва  поста вже існує

Варіант використання "Завантажити файли до проекту "

Короткий  опис:

Даний варіант використання описує завантаження файлів які стосуються проекту

Альтернативні потоки:

Не правильно  заповнені поля

Помилка розміру  файлу

Помилка кількості  файлів

Варіант використання "Створити новину для проекту "

Короткий  опис:

Даний варіант використання описує створення новин які стосуються проекту

Альтернативні потоки:

Не правильно  заповнені поля

Варіант використання "Переглянути календар"

Короткий  опис:

Даний варіант використання описує формування та перегляд календаря

Альтернативні потоки:

Календар відсутній

Варіант використання "Персоналізувати свою сторінку"

Короткий  опис:

Даний варіант використання описує налаштування своєї домашньої сторінки, список фільтрів, вигляд інтерфейсу.

Варіант використання "Переглянути діаграму Ганта"

Короткий  опис:

Даний варіант використання описує формування та перегляд діаграми Ганта

Альтернативні потоки:

Задач не існує

Варіант використання "Переглянути довідку"

Короткий  опис:

Даний варіант використання описує перегляд допоміжної документації, яка навчає користуванню системою.

Альтернативні потоки:

Довідка відсутня

Варіант використання "Переглянути головну сторінку"

Короткий  опис:

Даний варіант використання описує перегляд загальної інформації про систему на головній сторінці

 

2.4.  Виявлення класів

2.4.1. Ідентифікація класів 

У потоках подій варіанту використання виявляються класи  трьох типів:

1. Граничні класи (Boundary) — посередники при взаємодії зовнішніх об'єктів з системою. Як правило, для кожної пари "дійова особа — варіант використання" визначається один граничний клас. Типи граничних класів: призначений для користувача інтерфейс (обмін інформацією з користувачем без деталей інтерфейсу — кнопок, списків, вікон), системний інтерфейс і апаратний інтерфейс (використовувані протоколи без деталей їх реалізації).

2. Класи-суть (Entity)  — ключові абстракції (поняття) системи, що розробляється. Джерела виявлення класів - суті: ключові абстракції, створені в процесі архітектурного аналізу, глосарій, опис потоків подій варіантів використання.

3. Класи (Control), що управляють, — забезпечують координацію поведінки об'єктів в системі. Можуть бути відсутніми в деяких варіантах використання, що обмежуються простими маніпуляціями з даними, що зберігаються. Як правило, для кожного варіанту використання визначається один клас, що управляє. Приклади класів, що управляють: менеджер транзакцій, координатор ресурсів, обробник помилок.

Класи аналізу відображають функціональні вимоги до системи  і моделюють об'єкти наочної області. Сукупність класів аналізу є початковою концептуальною моделлю системи.

Ідентифікація основних абстракцій полягає в попередньому визначенні набору класів системи (класів аналізу) на основі опису наочної області і специфікації вимог до системи (зокрема, глосарію). Способи ідентифікації основних абстракцій аналогічні способам ідентифікації суті в моделі "суть-зв'язок". Основний (неформальний) спосіб ідентифікації суті - це пошук абстракцій, що описують фізичні або матеріальні об'єкти, процеси і події, ролі людей, організації і інші поняття. Єдиним формальним способом ідентифікації суті є аналіз текстових описів наочної області, виділення з описів імен іменників і вибір їх як "кандидати" на роль абстракцій. Кожна суть повинна мати найменування, виражене іменником в однині.

Слідуючи цим рекомендаціям, визначимо для системи наступні класи аналізу:

c_account_settings (Редагування  інформації акаунту, та перегляд інформації про інших користувачів)

c_mainpage (Перегляд головної  сторінки та довідки)

c_mypage (Налаштування домашньої  сторінки)

c_project (Створення, перегляд  проектів )

c_project_manage (Створення задач, редагування  інформації про проект)

c_signup (Реєстраці, авторизація, оновлення паролю)

m_poject (Запити проектів)

m_signup (Запити авторизації)

m_account_settings (Запити налаштування акаунту)

m_construct (Загальні запити)

v_layout (Шаблон)

Класи аналізу відображають функціональні  вимоги до системи і моделюють об'єкти наочної області. Сукупність класів аналізу є початковою концептуальною моделлю системи. Приклад набору класів, що беруть участь в реалізації варіанту використання "Створення проекту":

«boundary» v_create_project - граничний клас (Boundary) – форма створення проекту,

«control» create_project – клас, що управляє (Control) - координатор створення проекту,

«entity» projects - клас-сутність (Entity) – проекти,

«entity» users - клас-сутність (Entity) - користувачі,

«entity» projects-users- клас-сутність (Entity) – користувачі-проекти,

«entity» roles - клас-сутність (Entity) – ролі у проекті.

Рис. 3. Діаграма класів

 

2.4.2. Розподіл обов'язків між класами

Виходячи з призначення  трьох виділених типів класів, можна стисло охарактеризувати розподіл обов'язків між ними:

• граничні класи відповідають за взаємодію із зовнішнім середовищем системи (дійовими особами);

• класи-суть відповідають за зберігання даних і маніпулювання  ними;

• класи, що управляють, координують потоки подій варіанту використання.

Деталізація проектних  класів

Кожен граничний клас перетвориться в якийсь набір  класів залежно від свого призначення. Це може бути набір елементів призначеного для користувача інтерфейсу, залежний від можливостей середовища розробки, або набір класів, що реалізовує системний або апаратний інтерфейс.

Класи-сутності з урахуванням  міркувань продуктивності і захисту  даних можуть розбиватися на ряд  класів. Підставою для розбиття є  наявність в класі атрибутів  з різною частотою використання або  видимістю. Такі атрибути, як правило, виділяються в окремі класи.

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

Зберігаються класи, що виконують істотну роботу по управлінню потоками подій (управління транзакціями, розподілена обробка і т.д.).

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

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

Створюються діаграми послідовності  для основного потоку подій кожного варіанту використання.

 

Рис. 4. Діаграма послідовності 
Діаграма послідовності основного варіанту використання "Створення проекту"

2.4.3. Визначення операцій, атрибутів і асоціацій класів

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

Уточнення операцій і  атрибутів

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

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

• визначається повна  сигнатура операції (відповідно до нотації, прийнятої в мові UML);

• створюється короткий опис операції, включаючи сенс всіх її параметрів;

• задається видимість  операції: public, private або protected;

• визначається область  дії операції: екземпляр (операція об'єкту) або класифікатор (операція класу);

• може бути складений опис алгоритму виконання операції (з використанням діаграм діяльності у вигляді блок-схем, а також діаграм взаємодії різних об'єктів при виконанні операції).

Уточнення атрибутів  класів полягає в наступному:

• окрім імені атрибуту задаються його тип і значення за умовчанням (необов'язкове);

• враховуються угоди  по іменуванню атрибутів, прийняті у  проекті і мові реалізації;

• задається видимість атрибутів: public, private або protected;

• при необхідності визначаються похідні (обчислювані) атрибути.

Уточнення зв'язків між класами

В процесі проектування зв'язку між класами (асоціації, агрегації і узагальнення) підлягають уточненню:

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

• якщо для деяких асоціацій немає  необхідності в двонаправленій зв'язки, то вводяться напрями навігації;

• агрегації, композиції, що володіють властивостями, перетворяться  у зв'язку композиції.

Діаграма класів з  повністтю визначеними операціями, атрибутами та зв’язками :

Рис. 5. Діаграма класів з повністтю визначеними операціями, атрибутами та зв’язками

 

РОЗДІЛ 3. РЕАЛІЗАЦІЯ СИСТЕМИ МОВОЮ ОБ’ЄКТНО-ОРІЄНТОВАНОГО ПРОГРАМУВАННЯ

3.1 Аналіз системи

Метою об'єктно-орієнтованого  аналізу є трансформація функціональних вимог до програмної системи в  попередній системний проект і створення  стабільної основи архітектури системи. В процесі проектувань системний проект "занурюється" в середу реалізації з урахуванням всіх не функціональних вимог.

Об'єктно-орієнтований аналіз включає два види діяльності —  архітектурний аналіз і аналіз варіантів  використання.

3.1.1 Архітектурний аналіз

Архітектурний аналіз виконується  архітектором системи і включає:

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

Угоди моделювання визначають:

• використовувані діаграми і елементи моделі;
• правила їх застосування;
• угоди по іменуванню елементів моделі;
• організацію моделі (пакети).

Набір угод моделювання:

• імена варіантів використання повинні бути короткими дієслівними фразами;
• імена класів повинні бути іменниками, відповідними по можливості поняттям наочної області;
• імена класів повинні писатися з прописної букви;
• імена атрибутів і операцій повинні писатися з рядкової букви;
• складені імена повинні бути суцільними, без підкреслень, кожне окреме слово повинне писатися з прописної букви;
• всі класи і діаграми, що описують попередній системний проект,   поміщаються в пакет з ім'ям Analysis Model;
• діаграми класів, що реалізовують варіант використання, і діаграми  взаємодії, що відображають взаємодію об'єктів в процесі реалізації сценаріїв варіанту використання, поміщаються в кооперацію з  ім'ям даного варіанту використання і стереотипом <<use case realization>>. Всі кооперації поміщаються в пакет з ім'ям Use Case Realizations.