Розробка моделі програмної системи засобами UML

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Зміст

Введення

1. Змістовий огляд предметної області. Основні та вимоги до системи

2. Уніфікована мова моделювання UML

3. Розробка моделі програмної системи засобами UML

3.1 Вид з погляду прецедентів

3.2 Вид з погляду проектування

3.3 Вид з погляду реалізації

Висновок

Список використаних джерел

Введення

моделювання програмний прецедент

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

Модель -- образ або прообраз якого-небудь об'єкту або системи об'єктів, використовуваний за певних умов в якості їх «заступника» або «представника».

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

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

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

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

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

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

Імітаційне моделювання - моделювання поведінки системи в різних аспектах і в різних зовнішніх і внутрішніх умовах з аналізом динамічних характеристик бізнес-процесів і з аналізом розподілі ресурсів (наприклад, з використанням ділових ігор).

CASE - засоби

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

За останнє десятиліття сформувався новий напрям в програмотехніки - CASE (Computer - Aided Software/System Engineering). Нині не існує загальноприйнятого визначення CASE. Зміст цього поняття зазвичай визначається переліком завдань, що вирішуються за допомогою CASE, а також сукупністю вживаних методів і засобів. Дуже грубо, CASE - технологія є сукупністю методологій аналізу, проектування, розробки і супроводу складних систем програмного забезпечення (ПО), підтриманою комплексом взаємопов'язаних засобів автоматизації. CASE - це інструментарій для системних аналітиків, розробників і програмістів, замінюючи їм папір і олівець на комп'ютер для автоматизації процесу проектування і розробки ПО.

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

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

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

1. Змістовий огляд предметної області. Основні вимоги до системи

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

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

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

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

Тому від вибирання інструментальних засобів моделювання істотно залежать об'єм і терміни виконання робіт, глибина і якість аналізу при створенні проекту ІСУП.

Стартові умови

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

Інформація про об'єкт проектування - ІС підприємства ("чорний ящик").

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

Знання про еталонні процедури виконання ключових процесів відповідно до міжнародних або національних стандартів.

Знання про методи і засоби моделювання і аналізу систем.

Програмні засоби (інструменти) для моделювання і аналізу.

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

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

В процесі розробки ІСУП виконуються три рівні аналізу, кожен з яких відповідає трьом основним стадіям створення ІСУП :

§ визначення вимог;

§ формування специфікацій;

§ впровадження.

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

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

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

Третій рівень аналізу - впровадження - пов'язаний з конкретною реалізацією проекту ІСУП на підприємстві.

При виконанні робіт по моделюванню на кожному з трьох представлених вище рівнів можуть бути використані різні інструментальні засоби. В той же час необхідність комплексного аналізу при створенні ІСУП робить істотний вплив на вибір інструментів моделювання.

Залежно від класу створюваної ІСУП для вирішення завдання вибору інструменту моделювання доцільно класифікувати існуючі інструментальні засоби відповідно до наявної класифікації ІСУП.

2. Уніфікована мова моделювання UML

Призначення мови UML

Мова UML призначена для вирішення наступних завдань :

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

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

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

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

2. Забезпечити початкові поняття мови UML можливістю розширення і спеціалізації для точнішого представлення моделей систем в конкретній предметній області.

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

В той же час розробники з OMG вважають украй небажаним перевизначення базових понять мови з якої б то не було причини. Це може привести до неоднозначної інтерпретації їх семантики і можливої плутанини. Базові поняття мови UML не слід змінювати більше, ніж це необхідно для їх розширення. Усі користувачі мають бути здатні будувати моделі систем для більшості звичайних застосувань з використанням тільки базових конструкцій мови UML без застосування механізму розширення. При цьому нові поняття і нотації доцільно застосовувати тільки в тих ситуаціях, коли наявних базових понять явно недостатньо для побудови моделей системи.

Мова UML допускає також спеціалізацію базових понять. Йдеться про те, що в конкретных7 застосуваннях користувачі повинні уміти доповнювати наявні базові поняття новими характеристиками або властивостями, які не суперечать семантиці цих понять в мові UML.

3. Опис мови UML повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних мов програмування і інструментальних засобів проектування програмних систем.

Йдеться про те, що жодна з конструкцій мови UML не повинна залежати від особливостей її реалізації у відомих мовах програмування. Тобто, хоча окремі поняття мови UML і пов'язані з останніми дуже тісно, їх жорстка інтерпретація у формі яких би то не було конструкцій програмування не може бути визнана коректною. Іншими словами, розробники з OMG вважають необхідною властивістю мови UML його контекстно-програмну незалежність.

З іншого боку, мова UML повинна мати потенційну можливість реалізації своїх конструкцій на тій або іншій мові програмування. Звичайно, в першу чергу маються на увазі мови, що підтримують концепцію ТОП, такі як C++, Java, Object Pascal. Саме ця властивість мови UML робить його сучасним засобом рішення завдань моделювання складних систем. В той же час, передбачається, що для програмної підтримки конструкцій мови UML можуть бути розроблені спеціальні інструментальні CASE - засоби. Наявність останніх має принципове значення для широкого поширення і використання мови UML.

4. Опис мови UML повинен включати семантичний базис для розуміння загальних особливостей ООАП.

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

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

5. Заохочувати розвиток ринку об'єктних інструментальних засобів.

Більше 800 провідних виробників програмних і апаратних засобів, зусилля яких зосереджені у рамках OMG, бачать перспективи розвитку сучасних інформаційних технологій і основу свого комерційного успіху в широкому просуванні на ринок інструментальних засобів, що підтримують об'єктні технології. Говорячи ж про об'єктні технології, розробники з OMG мають на увазі, передусім, сукупність технологічних рішень CORBA і UML. З цієї точки зору мові UML відводиться роль базового засобу для опису і документування різних об'єктних компонентів CORBA.

6. Сприяти поширенню об'єктних технологій і відповідних понять ООАП.

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

7. Інтегрувати в себе новітні і найкращі досягнення практики ООАП.

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

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

Примітка

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

3. Розробка моделі програмної системи засобами UML

UML включає дев'ять видів діаграм:

ь діаграми класів;

ь діаграми об'єктів;

ь діаграми Use Case (діаграми прецедентів);

ь діаграми послідовності;

ь діаграми співпраці (кооперації);

ь діаграми схем станів;

ь діаграми діяльності;

ь компонентні діаграми;

ь діаграми розміщення (розгортання).

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

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

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

Діаграми послідовності і діаграми співпраці - це різновиди діаграм взаємодії.

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

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

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

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

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

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

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

Розглянемо деякі з перелічених вище видів діаграм детальніше.

3.1 Вид з погляду прецедентів

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

Діаграма прецедентів

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

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

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

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

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

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

Суть цієї діаграми полягає в наступному: проектована система представляється у вигляді безлічі сутностей або акторів, що взаємодіють з системою за допомогою так званих варіантів використання. При цьому актором (actor) або дійовою особою називається будь-яка суть, що взаємодіє з системою ззовні. Це може бути людина, технічний пристрій, програма або будь-яка інша система, яка може служити джерелом дії на модельовану систему так, як визначить сам розробник. У свою чергу, варіант використання (use case) служить для опису сервісів, які система надає акторові. Іншими словами, кожен варіант використання визначає деякий набір дій, що здійснюється системою при діалозі з актором. При цьому нічого не говориться про те, яким чином буде реалізовано взаємодію акторів з системою.

На рисунку 3.1 відображена діаграма Use Case, яка описує функціональне призначення системи для керування роботою івент-агенції «Свято! Свято!».

Рисунок 3.1 - Діаграма прецедентів для моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»

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

Діаграма діяльності

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

Розробка діаграми діяльності переслідує цілі:

ь деталізувати особливості алгоритмічної і логічної реалізації прецедентів;

ь виділити послідовні і паралельні потоки управління;

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

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

На рисунку 3.2 відображена діаграма діяльності по предметній області: «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»». Стани розподілені між об'єктами: Менеджером, ІС та БД.



Рисунок 3.2 - Діаграма діяльності «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»»

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

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

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

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

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

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

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

На рисунку 3.3 відображена діаграма станів по предметній області: «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»». Діаграма показує стани системи в процесі виконання запиту на пошук та вибірку даних про виконавців замовлення клієнта на обслуговування свята.

Рисунок 3.3 - Діаграма станів «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

3.2 Вид з погляду проектування

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

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

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

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

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

На рисунку 3.4 відображена діаграма класів по предметній області: «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

Рисунок 3.4 - Діаграма класів «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

Діаграма послідовності

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

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

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

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

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

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

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

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

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

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

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

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

На рисунку 3.5 відображена діаграма послідовності по предметній області: «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

Рисунок 3.5 - Діаграма послідовності «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

Діаграма кооперацій

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

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

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

На рисунку 3.6 відображена діаграма кооперацій по предметній області: «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».



Рисунок 3.6 - Діаграма кооперацій «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

3.3 Вид з погляду реалізації

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

На рисунку 3.7 відображена діаграма компонентів програми автоматизації процесу керівництва івент-агенцією.



Рисунок 3.7 - Діаграма компонентів з предметної області «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

Висновок

В процесі виконання курсової роботи були розглянуті такі теоретичні питання:

§ існуючі програмні засоби моделювання інформаційних систем : Rational Rose, Oracle Designer, AllFusion Process Modeler, AllFusion ERwin Data Modeler, ARIS, Sybase PowerDesigner;

§ засоби мови моделювання UML;

§ типи діаграм UML;

§ переваги UML;

§ недоліки UML;

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

Пояснювальна записка так само включає опис наступних видів діаграм:

§ прецедентів;

§ діяльності;

§ станів;

§ класів;

§ послідовності;

§ кооперацій ;

§ компонентів.

Перелічені вище види діаграм, були побудовані в середовищі Rational Rose 2003 Enterprice по предметній області «Моделювання роботи ІС для керування роботою івент-агенції «Свято! Свято!»».

Виконання курсової роботи закріпили і розширили теоретичні знання і практичні навички, отримані на курсі "Технологія створення програмних продуктів".

Список використаних джерел

1. І. О. Чмир та ін., Моделювання систем в середовищі UML: посібник для ВНЗ. Черкаси, 2004

2. М. Фаулер, К. Скотт, Основи. Посібник з уніфікованої мови UML. М: Біном, 2000

3. А. Асоненков, Самовчитель з UML. БХВ-Пітер, 2002

4. Орлов З. А., Технології розробки програмного забезпечення: Підручник для вузів. - Спб.: Пітер, 2004г.

5. І. О. Чмир, А. Ф. Верлань, Об'єктно-орієнтоване моделювання. Посібник. , О:НАДУ, 2005

6. Ambler, S. W. The Object Primer. 2^nd ed. Cambrige University Press, 2001. 541 pp;

Кьоу Дж., Джеанини М.

7. Кьоу Дж., Джеанини М., Объектно-ориентированное программирование. Учебный курс - СПб: "Питер", 2005.- 238 с.

8.http://www.infoystem.ru/designing/methodology/uml/theory/collaboration_diagram_theory

9. http://khpi-iip.mipk.kharkiv.edu/library/case/leon/gl8/gl8.html

10. http://ru.wikipedia.org/wiki/UML

Размещено на Allbest.ru

...