Розділ 3. Науково – дослідна робота Постановка завдання

Основне завдання, яке я мав виконати було розробка ПЗ для підприємства. Після дослідження потреб підприємства я вирішив створити програму обліку замовлень. Оскільки це є одним з найважливіших процесів які відбуваються на підприємстві. На даному етапі отримуються базова інформація про проект, яка є дуже важливою і від обробки якої залежить успішність і вчасність виконання завдання.

Послідовність розробки

Спочатку я розробляю специфікацію вимог для пропонованого мною ПЗ. У ньому я детально описую особливості ПЗ і його функціональні можливості. Для опису вимог ПЗ я дотримувався рекомендацій стандарту ISO/IEEE 830-1998. Переглянувши всі можливі варіанти написання специфікації я обрав варіант із режимами роботи програми. Його змісти виглядає наступним чином

1. Вступ

1.1. Призначення

1.2. Область дії

1.3. Визначення, акроніми і скорочення

1.4. Публікації

1.5. Короткий огляд

2. Повний опис

2.1. Перспектива виробу

2.1.1. Інтерфейси користувача.

2.1.2. Інтерфейси зв’язку

2.1.3. Обмеження пам’яті

2.2. Функції виробу

2.3. Характеристики користувача

2.4. Обмеження

2.5. Допущення і залежності

2.6. Розподілення вимог

3. Специфічні вимоги

3.1. Вимоги до зовнішніх інтерфейсів

3.1.1. Інтерфейси користувача

3.1.4. Інтерфейси зв’язку

3.2. Функціональні вимоги

3.2.1. Режим редагування

3.2.2. Режим Перегляду

3.3. Вимоги до робочих характеристик

3.4. Проектні обмеження

3.5. Атрибути системи програмного забезпечення

3.5.1. Надійність

3.5.2. Захист

3.5.3. Зручність супроводу

3.5.4. Мобільність

3.5.5. Специфічні умови

Саме його я буду використовувати для опису свого ПЗ . Загалом специфікація складається з 3 основних частин у яких я описав всі вимоги і функції у даному ПЗ.

Описавши вимоги до ПЗ я приступаю до розробки моделей програми. Моделі в даному випадку потрібні для того аби відобразити Бізнес процеси, які оброблятимуться даним програмним забезпеченням. Розробку моделей я виконував мовою UML.

UML – це графічна мова опису архітектури системи. Програма на UML не кодується, а описується за допомогою діаграм, дуже нагадують шкільний алгоритмічну мову. Діаграми UML складаються з об'єктів і зв'язків між ними.

UML має чотирьохрівневу архітектуру:

• Мета-метамодель;

• Метамодель;

• Модель;

• Призначені для користувача об'єкти.

Призначені для користувача об'єкти визначають об'єкти конкретної предметної області, наприклад: телевізор, монітор.

Модель є певним поглядом на предметну область

У UML існують наступні моделі:

• Модель випадків використання (use case model). Призначена для опису вимог до системи і підсистем;

• Модель класів (class model). Служить для опису статичної структури системи : ієрархії класів і стосунків між ними;

• Модель взаємодій - об'єкти (collaboration model) і сценарії (sequence model). Служить для опису механізмів взаємодії об'єктів системи, що реалізовують ту або іншу функцію;

• Поведінкова модель діаграми переходів і станів (behaviour model). Призначені для опису алгоритмів поведінки об'єктів системи.

• Модель процесів - фізична архітектура системи (deployment model). Описують розподіл процесів по процесорах у фізичному проекті системи;

• Модель програмних модулів (component model). Описують розподіл класів і об'єктів системи по модулях у фізичному проекті системи.

• Модель дій (activity model). Предназдначена для опису алгоритмом системи (для методів класів, для декількох класів) і є варіантом поведінкової моделі без повідомлень.

Метамодель визначає мову опису моделей. У UML метамодель описується за допомогою діаграм класів UML.

Мета-метамодель є описом різних метамоделей.

На рівні мета - мета моделі розглядається класифікація підходів розробки програмного забезпечення (ПЗ).

Найпоширенішими є два сімейства методів : структурні методи проектування програмних систем і об'єктно-орієнтовані, набуваючі все більшої популярності останніми роками.

Розробка моделі включає декілька етапів:

1. Побудувати діаграми прецедентів. Привести і описати діаграми варіантів використання .

2. Побудувати діаграми послідовності. Привести і описати діаграми послідовності для одного з прецедентів .

3. Створити діаграми співпраці, привести і описати діаграму співпраці для одного з прецедентів .

4. Побудувати діаграми класів, привести і описати діаграму класів для одного з прецедентів .

5. Додати деталі до описів операцій і визначити атрибути класів. Додати зв'язку між класами.

6. Створити діаграму станів для одного з класів і діаграму компонентів.

Створення діаграми Варіантів використання

Для створення діаграми варіантів використання необхідно вибрати дійових осіб, які матимуть безпосереднє відношення до роботи підсистеми. Для програми ПИСАР дійовою особою буде користувач.

Додамо дійову особу на діаграму, для цього необхідно вибрати на панелі інструментів інструмент «Actor» і додати його на діаграму. Вигляд піктограми показано на рисунку 3.1

рис 3.1. Дійова особа

У ролі дійових осіб у моїй діаграмі я використав у якості акторів користувача і систему. Користувач виконує роль головної особи, яка виконує основні процеси в даній системі. Система це особа над якою виконуються дії. Він також виконує свої функції. Цих два дійових актори утворюють дії, які є взаємопов’язані між собою.

Далі необхідно з'єднати варіанти використання і дійових осіб зв'язками. У своїй діаграмі я використав використав два види зв’ язків: dependency or instantiates і undirectional association. Завдяки цим зв’язкам я виконав створення зв'язок між прецедентами і акторами.

Після розміщення на діаграмі прецедентів всіх об'єктів, необхідно додати до варіантів використання їх специфікації.

Для додавання специфікації до варіанту використання необхідно відкрити його специфікацію (Open specification) і на вкладці Files додати текстовою файл – опис специфікації варіанту використання. Для цього необхідно виконати команду «Insert File» контекстного меню, і вибрати відповідний файл. Специфікація варіанту використання «додати замовлення» представлена на малюнку 3.2.

рис 3.2. Додання специфікації

Створення діаграми станів

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

На діаграмі є|наявний| два спеціальні стани|достатки| - початкове (start|) і кінцеве|скінченне| (stop|). Початковий стан|достаток| виділений чорною крапкою|точкою|, воно відповідає стану|достатку| об'єкту, коли він тільки що був створений. Кінцевий|скінченний| стан|достаток| позначається|значить| чорною крапкою|точкою| в білому кружку|гуртку|, воно відповідає стану|достатку| об'єкту безпосередньо перед його знищенням. На діаграмі станів|достатків| може бути один і лише один початковий стан|достаток|.

Додамо|добавлятимемо| на діаграму точку старту і перший стан|достаток| класу. Для додавання|добавляти| точки початку необхідно на панелі інструментів вибрати інструмент «Start| State|» і додати|добавляти| її на діаграму станів|достатків|. Додавання|добавляти| відбувається|походить| за допомогою інструменту «State|»

Наступним|таким| кроком є|з'являється| додавання|добавляти| зв'язків між станами|достатками|. Додавання|добавляти| зв'язків між станами|достатками| аналогічно додаванню|добавляти| зв'язків між класами, тільки|лише| виконується інструментами «State| Transition|» і «Transition| To| Self|».

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