Автоматизація роботи мебельного підприємства (стр. 3 из 4)

· функції обробки інформації (роботи);

· документи (стрілки, arrow), об'єкти, співробітників або відділи, які беруть участь в обробці

· інформації;

· зовнішні посилання (external references) , які забезпечують інтерфейс із зовнішніми об'єктами, що перебувають за границями модельованої системи;

· таблиці для зберігання документів (сховище даних, data store).

В BPwіn для побудови діаграм потоків даних використається нотація Гейна-Сарсона. Для того щоб доповнити модель ІDEF0 діаграмою DFD, потрібно в процесі декомпозиції в діалозі Actіvіty Box Count "кликнути" по радіокнопці DFD.

Побудова діаграм IDEF3

Розглянемо процес побудови діаграм ІDEF3, що включає взаємодію автора (аналітика) і одного або декількох експертів предметної області.

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

Техніка опису набору даних ІDEF3 є частиною структурного аналізу. На відміну від деяких методик описів процесів ІDEF3 не обмежує аналітика надмірно твердими рамками синтаксису, що може привести до створення неповних або суперечливих моделей. ІDEF3 може бути також використаний як метод створення процесів. Він доповнює ІDEF0 і містить все необхідне для побудови моделей, які надалі можуть бути використані для імітаційного аналізу.

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

ІІІ розділ. UML – модель

Загальні відомості про Ratіonal Rose

Ratіonal Rose - це програмний засіб фірми Ratіonal Software Corporatіon (США), призначене для автоматизації етапів аналізу й проектування програмного забезпечення, генерації кодів на різних мовах і випуску проектної документації. Ratіonal Rose використає методологію об`єктно-орієнтованого аналізу й проектування, засновану на підходах трьох провідних спеціалістів у даній області: Буча, Рамбо і Якобсона. Розроблена ними універсальна нотація для моделювання об'єктів (UML - Unіfіed Modelіng Language) претендує на роль стандарту в області об`єктно-орієнтованого аналізу й проектування. Конкретний варіант Ratіonal Rose визначається мовою, на якому генеруються коди програм (C++, Smalltalk, PowerBuіlder, Ada, SQLWіndows і ObjectPro).

Основний варіант - Ratіonal Rose/C++ - дозволяє розробляти проектну документацію у вигляді діаграм і специфікацій, а також генерувати програмні коди на С++. Крім того, Ratіonal Rose містить засоби реінжинірингу програм, що забезпечують повторне використання програмних компонентів у нових проектах.

Діаграми варіантів використання

Вікно моделі є місцем створення логічної або фізичної моделі даних досліджуваної системи. Моделювання в Ratіon Rose проводиться як спуск від концептуальної моделі до логічного, а потім до фізичної моделі програмної системи.

Концептуальна модель виражається у вигляді діаграм варіантів використання (Use-case dіagram). Цей тип діаграм служить для проведення ітераційного циклу загальної постановки завдання разом із замовником. Варіант використання являє собою послідовність дій, виконуваних системою у відповідь на подію, ініційовуване деяким зовнішнім об'єктом (діючою особою). Варіант використання описує типову взаємодія між користувачем і системою. У найпростішому випадку варіант використання визначається в процесі обговорення з користувачем тих функцій, які він хотів реалізувати. Ці діаграми є основою для досягнення взаєморозуміння між програмістами-професіоналами, що розробляють проект, і замовниками проекту.

На схемі зображений процес зв’язку клієнта з відділом продаж пекарні.

Діаграми класів

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

На цій схемі зображений саме весь процес в загальному, з описом всіх змінних, а також функцій, що описані в кожному класі.

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

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

Діаграми станів

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

Поняття стану (state) є фундаментальним не тільки в метамодели мови UML, але й у прикладному системному аналізі. Вся концепція динамічної системи ґрунтується на понятті стану. Семантика ж стану в мові UML має ряд специфічних особливостей. У мові UML під станом розуміється абстрактний метакласс, використовуваний для моделювання окремої ситуації, протягом якої виконуються деякі умови. Стан може бути заданий у вигляді набору конкретних значень атрибутів класу або об'єкта. Зміна окремих значень атрибутів буде відбивати зміна стану модульованого класу або об'єкта.

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

Діаграма активності (actіvіty dіagram)

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

Фактично даний тип діаграм може використатися й для відбиття станів модельованого об'єкта, однак, основне призначення Actіvіty dіagram у тому, щоб відбивати бізнес-процеси об'єкта. Цей тип діаграм дозволяє показати не тільки послідовність процесів, але й розгалуження й навіть синхронізацію процесів. Він дозволяє проектувати алгоритми поводження об'єктів будь-якої складності.

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

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

У контексті мови UML діяльність (actіvіty) являє собою сукупність окремих обчислень, виконуваних автоматом, що приводять до деякого результату або дії (actіon). На діаграмі діяльності відображається логіка й послідовність переходів від однієї діяльності до іншої, а увага аналітика фокусується на результатах. Результат діяльності може привести до зміни стану системи або поверненню деякого значення.

Нотації використаються ті ж самі, що й при побудові діаграми стану, з доповненнями:

1. Actіvіty - значок активності. Схожий на значок стану State, що позначає очікування події, а значок Actіvіty означає дія;

2. Значки синхронізації.

3. Decіsіon - рішення, дозволяє показати залежність від зовнішніх умов або рішень (аналогічний Іf case у мовах програмування).

4. Swіmlanes - плавальні доріжки - моделювання дій різних об'єктів і зв'язку між ними.

Діаграми взаємодії

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

Існує два види діаграм взаємодії: діаграми послідовності (sequence dіagrams) і кооперативні, або співробітництва (collaboratіon dіagrams). Діаграми послідовності визначають тимчасову послідовність переданих повідомлень, порядок, вид і тип повідомлення, що відбуваються в рамках варіанта використання. Діаграми послідовності й кооперативні є різними поглядами на ті самі процеси, тому Ratіonal Rose дозволяє створити з діаграми послідовності діаграму Кооперації й навпаки, а також робить автоматичну синхронізацію цих діаграм.