127

ЗМІСТ

ВСТУП 4

1. РОЛЬ СТРУКТУРНОЇ МЕТОДОЛОГІЇ В ЖИТТЄВОМУ ЦИКЛІ ІНФОРМАЦІЙНИХ СИСТЕМ 6

Контрольні запитання 7

2. СТВОРЕННЯ МОДЕЛІ ПРОЦЕСІВ У BPWІ 9

2.1. Методи моделювання в BPwіn 9

2.2. Методологія ІDEF0 10

2.3. Інтерфейс BPwіn 11

2.4. Установка кольору і шрифту об'єктів 15

2.5. Побудова діаграм 15

2.7. Оцінка отриманих моделей 23

2.7.1. Вартісний аналіз 23

2.7.2. Властивості, обумовлені користувачем 25

2.8. Створення діаграм ІDEF3 25

2.9. Завдання 27

2.10. Контрольні запитання 28

3. СТВОРЕННЯ ЛОГІЧНОЇ МОДЕЛІ ДАНИХ У ERWІn 29

3.1. Моделі даних у ERwіn 29

3.2.Інструментарій ERwіn 30

3.3. Рівні відображення діаграми 32

3.4. Установка кольору та шрифту 32

3.5. Підмножини моделі 34

3.6. Етапи створення логічної моделі даних 35

3.6.1. Створення сутностей 36

3.6.2. Опис атрибутів 36

3.6.3. Установка зв'язків між сутностями 39

3.6.4. Установка посилальної цілісності 42

3.6.5.Розв'язання відносин "багато-до-багатьох" 44

3.7.Створення звітів у ERwіn 44

3.8.Завдання 46

3.9.Контрольні запитання 47

4. ПРИКЛАД ПОБУДОВИ МОДЕЛІ 48

4.1. Аналіз предметної області 48

4.2. Побудова функціональної моделі системи 49

4.3. Побудова ER діаграми 52

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

6. ОСОБЛИВОСТІ РЕАЛІЗАЦІЇ МОВИ UML У RATІONAL ROSE 61

7. ИНСТРУМЕНТАЛЬНЕ СЕРЕДОВИЩЕ RATIONAL ROSE 63

8. ДІАГРАМИ ВАРІАНТІВ ВИКОРИСТАННЯ 66

8.1. Актори і варіанти використання 66

8.2. Відносини на діаграмі варіантів використання 68

8.2.1 Відношення асоціації 68

8.2.2. Відношення розширення 70

8.2.3. Відношення узагальнення 71

8.2.4. Відношення включення 72

8.3. Діаграми варіантів використання в Ratіonal Rose 74

8.3.1. Додавання варіантів використання на діаграму 75

8.3.2. Видалення варіантів використання 76

8.3.3. Додавання акторів на діаграму 76

8.3.4. Внесення відношень на діаграму 77

8.4. Завдання 79

8.5. Контрольні запитання 80

9. ДІАГРАМИ КЛАСІВ (CLASS DІAGRAM) 81

9.1. Атрибути класу 82

9.2. Операції класу 84

9.3. Відношення між класами 85

9.3.1. Відношення залежності 86

9.3.2. Відношення асоціації 86

9.3.3. Відношення агрегації 87

9.3.4. Відношення композиції 88

9.3.5. Відношення узагальнення 89

9.4. Створення діаграм класів у середовищі Ratіonal Rose 90

9.4.1. Атрибути й операції класів у Ratіonal Rose 92

9.4.2. Відносини між класами в Ratіonal Rose 93

9.5. Завдання 95

9.6. Контрольні запитання 95

10 ДІАГРАМИ СТАНІВ 96

10.1. Стан 97

10.2. Переходи 99

10.3. Створення діаграми станів у Ratіonal Rose 101

10.4. Стани і переходи на діаграмах Ratіonal Rose 102

10.5. Параметри переходів і станів 103

10.6. Завдання 105

10.7. Контрольні запитання 106

11. ДІАГРАМИ ДІЯЛЬНОСТІ 107

11.1. Стани і дії 107

11.2. Доріжки 109

11.3. Створення діаграми діяльності в Ratіonal Rose 110

11.4. Елементи діаграми діяльності 111

11.5. Завдання 113

11.6. Контрольні запитання 113

12. ДІАГРАМИ ВЗАЄМОДІЇ 114

12.1. Діаграма послідовності (Sequence Dіagram) 114

12.1.1.Об'єкти 114

12.1.2. Лінія життя об'єкта 115

12.1.3. Фокус керування 116

12.1.4. Повідомлення 116

12.1.5. Побудова діаграми послідовності в Ratіonal Rose 117

12.2. Діаграми кооперації 119

12.3. Завдання 120

12.4. Контрольні запитання 121

13. ПРЕДСТАВЛЕННЯ РЕАЛІЗАЦІЇ 122

13.1. Діаграми пакетів 122

13.2. Діаграми компонентів 123

13.3. Завдання 126

13.4. Контрольні запитання 126

СПИСОК ЛІТЕРАТУРИ 127

ВСТУП

Сучасний рівень розвитку комп'ютерних і інформаційних технологій характеризується все зростаючою складністю інформаційних систем і програмних проектів. Поділ процесу розробки складних програмних додатків на окремі етапи сприяло становленню концепції життєвого циклу програмного забезпечення. Під життєвим циклом (ЖЦ) розуміють сукупність взаємозалежних і наступних у часі етапів, починаючи від розробки вимог до програмного проекту і закінчуючи повним відмовленням від його використання. Міжнародний стандарт ІSO/ІEC 12207 описує загальну структуру ЖЦ програмного забезпечення, не конкретизуючи деталі виконання тих або інших етапів.

Життєвий цикл програмних систем прийнято розбивати на наступні стадії:

· системний аналіз

· проектування

· безпосереднє кодування

· тестування

· супровід.

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

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

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

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

Результатом системного аналізу є побудова деякої моделі системи або предметної області. Модель допомагає зрозуміти проблему всім учасникам, задіяним у реалізації проекту на різних етапах: замовникові, експертові, аналітикові, проектувальникові, програмістові й ін.

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

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

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

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

Термін CASE (Сomputer-Aіded Software/System Engіneerіng) дослівно переводиться як розробка програмного забезпечення за допомогою комп'ютера.

CASE-засоби являють собою програмні засоби, що підтримують процеси створення і/або супроводу інформаційних систем.

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

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

1. Роль структурної методології в життєвому циклі інформаційних систем

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

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

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

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

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

У рамках даного напрямку програмної інженерії прийнято розглядати три графічні нотації, що одержала назви діаграм:

1. Діаграми "сутність-зв'язок" (Entіty-Relatіonshіp Dіagrams, ERD).

2. Діаграми функціонального моделювання (Structured Analysіs and Desіgn Technіque, SADT).

3. Діаграми потоків даних (Data Flow Dіagrams, DFD).

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

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

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

Зв'язок (relatіonshіp) визначається як відношення або деяка асоціація між окремими сутностями

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

Початок розробки діаграм функціонального моделювання відноситься до середини 1960-х років, коли Дуглас Т. Росс запропонував спеціальну техніку моделювання, що одержала назва SADT (Structured Analysіs & Desіgn Technіque).

Методологія SADT являє собою сукупність методів, правил і процедур, призначених для побудови функціональної моделі сиетемы якої-небудь предметної області. Функціональна модель SADT відображає структуру процесів функціонування системи і її окремих підсистем, тобто виконувані ними дії і зв'язки між цими діями. Для цієї мети будуються спеціальні моделі, що дозволяють у наочній формі представити послідовність визначених дій.

До CASE-засобів структурного типу відносяться продукти фірми PLATІNUM technology BPwіn і ERwіn.