- •1.1. Методологія процедурно‑ орієнтованого програмування
- •1.2. Методологія об'єктно-орієнтованого програмування
- •1.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •1.4. Методологія системного аналізу і системного моделювання
- •Розділ 2
- •2.1. Передісторія. Математичні основи
- •Мал. 2.4. Приклади неорієнтованого (а) і орієнтованого (б) графів
- •Мал. 2.5. Приклади неорієнтованого (а) і орієнтованого (б) дерев
- •Мал. 2.6. Ієрархічні схеми неорієнтованого дерева (а) і орієнтованого дерева (б)
- •2.2. Діаграми структурного системного аналізу
- •I (Input) – вхід, т. Е. Все, що поступає в процес або споживається процесом.
- •2.3. Основні етапи розвитку uml
- •2. Забезпечити початкові поняття язика uml можливістю розширення і спеціалізації для більш точного представлення моделей систем в конкретній наочній області.
- •3. Опис язика uml повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних язиків програмування і інструментальних засобів проектування програмних систем.
- •4. Опис язика uml повинен включати семантичний базис для розуміння загальних особливостей ооап.
- •7. Інтегрувати в себе новітні і якнайкращі досягнення практики ооап.
- •3.2. Загальна структура язика uml
- •3.3. Пакети в язиці uml
- •3.4. Основні пакети метамоделі язика uml
- •3.5. Специфіка опису метамоделі язика uml
- •3.6. Особливості зображення діаграм язика uml
- •4.1. Варіант використовування
- •4.2. Актори
- •4.3. Інтерфейси
- •4.4. Примітки
- •4.5. Відносини на діаграмі варіантів використовування
- •4.6. Приклад побудови діаграми варіантів використовування
- •4.7. Рекомендації по розробці діаграм варіантів використовування
- •5.1. Клас
- •5.2. Відносини між класами
- •5.5. Шаблони або класи, що параметризуються
- •5.6. Рекомендації по побудові діаграм класів
- •6.1. Автомати
- •Include – ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
- •6.3. Перехід
- •6.4. Складовий стан і підстан
- •6.5. Історичний стан
- •Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану
- •6.6. Складні переходи
- •Мал. 6.11. Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)
- •6.7. Заключні рекомендації по побудові діаграм станів
- •7.1. Стан дії
- •7.2. Переходи
- •7.5. Рекомендації по побудові діаграм діяльності
- •8.2. Повідомлення
- •Мал. 8.7. Діаграма послідовності із стереотипними значеннями повідомлень
- •8.3. Приклад побудови діаграми послідовності
- •8.4. Заключні рекомендації по побудові діаграм послідовності
- •9.1. Кооперація
- •9.3. Зв'язки
- •9.4. Повідомлення
- •9.6. Заключні рекомендації по побудові діаграм кооперації
- •10.1. Компоненти
- •10.2. Інтерфейси
- •10.3. Залежність
- •10.4. Рекомендації по побудові діаграми компонентів
- •11.1. Вузол
- •11.2. З'єднання
- •Мал. 11.4. Фрагмент діаграми розгортання із з'єднаннями меходу вузлами
- •11.3. Рекомендації по побудові діаграми розгортання
- •12.1. Загальна характеристика case‑ засобу Rational Rose 98/2000
- •12.2. Особливості робочого інтерфейсу Rational Rose
- •12.3. Початок роботи над проектом в середовищі Rational Rose
- •12.4. Розробка діаграми варіантів використовування в середовищі Rational Rose
- •12.5. Розробка діаграми класів в середовищі Rational Rose
- •12.6. Розробка діаграми станів в середовищі Rational Rose
- •12.7. Розробка діаграми послідовності в середовищі Rational Rose
- •12.8. Розробка діаграми кооперації в середовищі Rational Rose
- •12.9. Розробка діаграми компонентів в середовищі Rational Rose
- •12.10. Розробка діаграми розгортання в середовищі Rational Rose
I (Input) – вхід, т. Е. Все, що поступає в процес або споживається процесом.
З (Control) – управління або обмеження на виконання операцій процесу.
Про (Output) – вихід або результат процесу.
М (Mechanism) – механізм, який використовується для виконання процесу.
Методологія IDEFO однозначно визначає, яким чином зображаються на діаграмах стрілки кожного вигляду ICOM. Стрільця Вход (Input) виходить з лівої сторони рамки робочого поля і входить зліва в прямокутник процесу. Стрільця Управленіє (Control) входить і виходить зверху. Стрільця Виход (Output) виходить з правої сторони процесу і входить в праву сторону рамки. Стрільця Механізм (Mechanism) входить в прямокутник процесу знизу. Таким чином, базове представлення процесу на діаграмах IDEFO має наступний вигляд (мал. 2.13).
Техніка побудови діаграм є головною особливістю методології IDEF‑ SADT. Місце з'єднання стрілки з блоком визначає тип інтерфейсу. При цьому всі функції модельованої системи і інтерфейси на діаграмах представляються у вигляді відповідних блоків процесів і стрілець ICOM. Управляюча інформація входить в блок зверху, тоді як інформація, яка піддається обробці, зображається з лівого боку блоку. Результати процесу представляються як виходи процесу і показуються з правої сторони блоку. Як механізм може виступати людина або автоматизована система, які реалізують дану операцію. Відповідний механізм на діаграмі представляється стрілкою, яка входить в блок процесу знизу.
Мал. 2.13. Позначення процесу і стрілець ICOM на діаграмах IDEF0
Однією з найважливіших особливостей методології IDEF‑ SADT є поступове введення все більш детальних представлень моделі системи у міру розробки окремих діаграм. Побудова моделі IDEF‑ SADT починається з представлення всієї системи у вигляді найпростішої діаграми, що складається з одного блоку процесу і стрілець ICOM, службовців для зображення основних видів взаємодії з об'єктами поза системою. Оскільки початковий процес представляє всю систему як єдине ціле, дане уявлення є самим загальним і підлягає подальшій декомпозиції.
Для ілюстрації основних ідей методології IDEF‑ SADT розглянемо наступний простий приклад. Як процес представлятимемо діяльність по оформленню кредиту в банку. Входом даного процесу є заявка від клієнта на отримання кредиту, а виходом – відповідний результат, т. е. безпосередньо кредит. При цьому управляючими чинниками є правила оформлення кредиту, які регламентують умови отримання відповідних фінансових коштів в кредит. Механізмом даного процесу є службовець банку, який уповноважений виконати всі операції по оформленню кредиту. Приклад початкового представлення процесу оформлення кредиту в банку зображений на мал. 2.14.
Мал. 2.14. Приклад початкової діаграми IDEF‑ SADT для процесу оформлення кредиту в банку
Зрештою модель IDEF‑ SADT є серією ієрархічно взаємозв'язаних діаграм з супровідною документацією, яка розбиває початкове представлення складної системи на окремі складові частини. Деталі кожного з основних процесів представляються у вигляді більш детальних процесів на інших діаграмах. В цьому випадку кожна діаграма нижнього рівня є декомпозицією деякого процесу з більш загальної діаграми. Тому на кожному кроці декомпозиції більш загальна діаграма конкретизується на ряд більш детальних діаграм.
В даний час діаграми структурного системного аналізу IDEF‑ SADT продовжують використовуватися цілим рядом організацій для побудови і детального аналізу функціональної моделі існуючих на підприємстві бізнес‑ процесів, а також для розробки нових бізнес‑ процесів. Основний недолік даної методології пов'язаний з відсутністю явних засобів для об'єктно-орієнтованого представлення моделей складних систем. Хоча деякі аналітики відзначають важливість знання і вживання нотації IDEF‑ SADT, обмежені можливості цієї методології стосовно реалізації відповідних графічних моделей в об'єктно-орієнтованому програмному коді істотно звужують діапазон вирішуваних з її допомогою задач.
Діаграми потоків даних
Основою даної методології графічного моделювання інформаційних систем є спеціальна технологія побудови діаграм потоків даних DFD. В розробці методології DFD взяли участь багато аналітиків, серед яких слід зазначити Э. Йордона (Е. Yourdon). Він є автором однієї з перших графічних нотацій DFD [10]. В даний час найпоширенішою є так звана нотація Гейна‑ Сарсона (Gene‑ Sarson), основні елементи якої будуть розглянуті в цьому розділі.
Модель системи в контексті DFD представляється у вигляді деякої інформаційної моделі, основними компонентами якої є різні потоки даних, які переносять інформацію від однієї підсистеми до іншої. Кожна з підсистем виконує певні перетворення вхідного потоку даних і передає результати обробки інформації у вигляді потоків даних для інших підсистем.
Основними компонентами діаграм потоків даних є:
зовнішні єства
накопичувачі даних або сховища
процеси
потоки даних
системи/підсистеми
Зовнішнє єство є матеріальним об'єктом або фізичною особою, які можуть виступати як джерело або приймач інформації. Визначення деякого об'єкту або системи як зовнішнє єство не є строго фіксованим. Хоча зовнішнє єство знаходиться за межами меж даної системи, в процесі подальшого аналізу деякі зовнішні єства можуть бути перенесені всередину діаграми моделі системи. З другого боку, окремі процеси можуть бути винесені за межі діаграми і представлені як зовнішні єства. Прикладами зовнішніх єств можуть служити: клієнти організації, замовники, персонал, постачальники.
Зовнішнє єство позначається прямокутником з тінню (мал. 2.15), усередині якого указується її ім'я. При цьому як ім'я рекомендується використовувати іменник в називному відмінку. Іноді зовнішнє єство називають також терминатором.
Мал. 2.15. Зображення зовнішнього єства на діаграмі потоків даних
Процес є сукупністю операцій по перетворенню вхідних потоків даних у вихідні відповідно до певного алгоритму або правила. Хоча фізично процес може бути реалізований різними способами, найбільш часто мається на увазі програмна реалізація процесу. Процес на діаграмі потоків даних зображається прямокутником із закруглюючими вершинами (мал. 2.16), розділеним на три секції або поля горизонтальними лініями. Поле номера процесу служить для ідентифікації останнього. В середньому полі указується ім'я процесу. Як ім'я рекомендовано використовувати дієслово в невизначеній формі з необхідними доповненнями. Нижнє поле містить вказівку на спосіб фізичної реалізації процесу.
Мал. 2.16. Зображення процесу на діаграмі потоків даних
Мал. 2.17. Зображення підсистеми на діаграмі потоків даних
Інформаційна модель системи будується як деяка ієрархічна схема у вигляді так званої контекстної діаграми, на якій початкова модель послідовно представляється у вигляді моделі підсистем відповідних процесів перетворення даних. При цьому підсистема або система на контекстній діаграмі DFD зображається так само, як і процес – прямокутником із закруглюючими вершинами (мал. 2.17).
Накопичувач даних або сховище є абстрактним пристроєм або способом зберігання інформації, переміщуваної між процесами. Передбачається, що дані можна у будь-який момент помістити в накопичувач і через деякий час витягнути, причому фізичні способи приміщення і витягання даних можуть бути довільними. Накопичувач даних може бути фізично реалізований різними способами, але найбільш часто передбачається його реалізація в електронному вигляді на магнітних носіях. Накопичувач даних на діаграмі потоків даних зображається прямокутником з двома полями (мал. 2.18). Перше поле служить для вказівки номера або ідентифікатора накопичувача, який починається з букви «D». Друге поле служить для вказівки імені. При цьому як ім'я накопичувача рекомендується використовувати іменник, який характеризує спосіб зберігання відповідної інформації.
Мал. 2.18. Зображення накопичувача на діаграмі потоків даних
Нарешті, потік даних визначає якісний характер інформації, передаваної через деяке з'єднання від джерела до приймача. Реальний потік даних може передаватися по мережі між двома комп'ютерами або будь-яким іншим способом, допускаючим витягання даних і їх відновлення в необхідному форматі. Потік даних на діаграмі DFD зображається лінією із стрілкою на одному з її кінців, при цьому стрілка показує напрям потоку даних. Кожний потік даних має своє власне ім'я, що відображає його зміст.
Таким чином, інформаційна модель системи в нотації DFD будується у вигляді діаграм потоків даних, які графічно представляються з використанням відповідної системи позначень. Як приклад розглянемо спрощену модель процесу отримання деякої суми готівкою по кредитній картці клієнтом банку. Зовнішніми єствами даного прикладу є клієнт банку і, можливо, службовець банку, який контролює процес обслуговування клієнтів. Накопичувачем даних може бути база даних про стан рахунків окремих клієнтів банку. Окремі потоки даних відображають характер передаваної інформації, необхідної для обслуговування клієнта банку. Відповідна модель для даного прикладу може бути представлена у вигляді діаграми потоків даних (мал. 2.19).
В даний час діаграми потоків даних використовуються в деяких CASE‑ засобах для побудови інформаційних моделей систем обробки даних. Основний недолік цієї методології також пов'язаний з відсутністю явних засобів для об'єктно-орієнтованого представлення моделей складних систем, а також для представлення складних алгоритмів обробки
даних. Оскільки на діаграмах DFD не указуються характеристики часу виконання окремих процесів і передачі даних між процесами, то моделі систем, що реалізовують синхронну обробку даних, не можуть бути адекватно представлені в нотації DFD. Всі ці особливості методології структурного системного аналізу обмежили можливості її широкого вживання і послужили основою для включення відповідних засобів в уніфікований язик моделювання.
Мал. 2.19. Приклад діаграми DFD для процесу отримання деякої суми готівкою по кредитній картці
