Дослідження динамічного моделювання програмного забезпечення інформаційних систем на прикладі діаграм мови UML

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

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

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

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

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

При графічному зображенні діаграм варто дотримувати наступних основних рекомендацій:

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

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

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

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

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

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

7. Будь-яка модель системи повинна містити тільки ті елементи, що визначені в нотації мови UML. Мається на увазі вимога починати разробку проекту, використовуючи тільки ті конструкції, що уже визначені в метамоделі UML. Як показує практика, цих конструкцій цілком достатньо для представлення більшості типових проектів програмних систем. І тільки при відсутності необхідних базових елементів мови UML варто використовувати механізми їхнього розширення для адекватного представлення конкретної моделі системи. Не допускається перевизначення семантики тих елементів, що віднесені до базової нотації метамоделі мови UML.

3.5 Елементи графічної нотації діаграми варіантів використання

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

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

Діаграма варіантів використання (use case dіagram) - діаграма, на якій зображуються відносини між акторами і варіантами використання.

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

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

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

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

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

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

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

Базовими елементами діаграми варіантів використання є варіант використання й актор.

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

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

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

Рис. 3.8. Графічне позначення варіанта використання

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

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

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

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

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



Рис. 3.9. Графічне позначення актора

У деяких випадках актор може позначатися у виді прямокутника класу зі стереотипом <<actor>> і звичайними складовими елементами класу. Імена акторів повинні починатися з заголовної букви і додержуватися рекомендацій використання імен для типів і класів моделі. При цьому символ окремого актора зв'язує відповідний опис актора з конкретним ім'ям.

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

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

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

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

Відношення (relatіonshіp) - семантичний зв'язок між окремими елементами моделі. Між елементами діаграми варіантів використання можуть існувати різні відносини, що описують взаємодію екземплярів одних акторів і варіантів використання з екземплярами інших акторів і варіантів. Один актор може взаємодіяти з декількома варіантами використання. У цьому випадку цей актор звертається до декількох сервісам даної системи. У свою чергу один варіант використання може взаємодіяти з декількома акторами, надаючи для усіх них свій сервіс.

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

У мові UML мається кілька стандартних видів відносин між акторами і варіантами використання:

· асоціації (assocіatіon relatіonshіp)

· включення (іnclude relatіonshіp)

· розширення (extend relatіonshіp)

· узагальнення (generalіzatіon relatіonshіp)

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

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

Рис. 3.10. Приклад графічного представлення відносини асоціації

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

Включення (іnclude) у мові UML - це різновид відносини між базовим варіантом використання і його спеціальним випадком. При цьому відношенням залежності (dependency) є таке відношення між двома елементами моделі, при якому зміна одного елемента (незалежного) приводить до зміни іншого елемента (залежного).

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

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

Рис. 3.11. Приклад графічного зображення відносини включення між варіантами використання

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

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

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

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

Рис. 3.12. Приклад графічного зображення відносини розширення між варіантами використання

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

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

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

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

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

Рис. 3.13. Приклад графічного зображення відносини узагальнення між варіантами використання

У даному прикладі відношення узагальнення вказує на те, що варіант використання «Надання кредиту корпоративним клієнтам» - спеціальний випадок варіанта використання «Надання кредиту клієнтам банку». Іншими словами, перший варіант використання є спеціалізацією другого варіанта використання. При цьому варіант використання «Надання кредиту клієнтам банку» ще називають предком або батьком стосовно варіанта використання «Надання кредиту корпоративним клієнтам», а останній варіант називають нащадком стосовно першого варіанта використання. Варто підкреслити, що нащадок успадковує усі властивості поводження свого батька, а також може мати додаткові особливості поводження.

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

3.6 Додаткові позначення мови UML для бізнесу-моделювання

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

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

Графічне зображення бізнесу-актора приводиться на рис. 3.14, а. Прикладами бізнес-акторів є клієнти, покупці, постачальники, партнери. Загальна властивість акторів полягає в тому, що вони є ініціаторами або клієнтами процесів системи.

Співробітник (busіness worker) - індивідуум, що діє усередині бізнесу-системи, взаємодіє з іншими співробітниками і є учасником процесу системи.

Графічне зображення співробітника приводиться на рис. 3.14, б. Прикладами співробітників є менеджери, адміністратори, касири, інженери. Загальна властивість співробітників полягає в тім те, що вони є суб'єктами і входять до складу системи.

Бізнес-варіант використання (busіness use case) - варіант використання, що визначає послідовність дій моделируемой системи, спрямованих на виконання окремого бізнесу-процесу.

Графічне зображення бізнесу-варіанта використання приводиться на рис. 3.14, в. Загальна властивість бізнес-варіантів використання полягає в тому, що вони є концептуальною моделлю окремих бізнес-процесів системи.



Рис. 3.14. Графічні зображення бізнес-актора (а), бізнес-співробітника (б) і бізнес-варіанта використання (в)

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

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

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

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

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

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

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

4. Моделювання інформаційної системи поліклініки в середі Rational Rose

4.1 Опис предметної області

Районна поліклініка створена для лікування фізичних осіб. Коли людина захворіє, то звертається в поліклініку, прикріплену до свого району. Спочатку вона звертається безпосередньо в реєстратуру.

Роботу реєстратури можна розбити на наступні процеси:

1. Заведення особистої амбулаторної карти пацієнта.

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

2. Формування розкладу роботи лікарів.

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

3. Видача пацієнту талону на прийом до лікаря.

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

4. Видача пацієнту листка непрацездатності (лікарняний лист).

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

5. Повернення особистої картки пацієнта в реєстратуру.

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

4.2 Концепція предметної області

Основні поняття інформаційної системи

Пацієнт - громадянин, що звернувся до лікаря;

Реєстратор - службовець поліклініки, що здійснює реєстрацію пацієнтів в реєстратурі;

Лікар - службовець поліклініки, що здійснює професійну діяльність відповідно до здобутої освіти;

Амбулаторна карта - документ, в якому зберігатися історія хвороби пацієнта;

Талон - документ, що дає право на відвідини лікаря у встановлений час.

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

Мати доступний інтерфейс для користувача ІС (реєстратора), так само мати в наявності швидку пошукову систему амбулаторних карт.

Нефункціональні вимоги

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

4.3 Побудова концептуальної моделі предметної області на основі діаграми варіантів використання

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

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

Сформуємо концептуальну модель предметної області на основі основних понять предметної області, складемо її у вигляді use case діаграми, яка представлена на рис. 4.1.

Базовими елементами діаграми варіантів використання є актори і прецеденти. Актор є будь-якою зовнішньою по відношенню до модельованої системи суттю, яка взаємодіє з системою і використовує її функціональні можливості для досягнення певної мети. Прецедент (use-case) - опис окремого аспекту поведінки системи з погляду користувача.



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

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

Рис. 4.2. Діаграма активності «Звернення пацієнта в реєстратуру»

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

Рис. 4.3. Діаграма активності «Формування амбулаторної картки пацієнта»

4.4 Побудова моделі поведінки на основі діаграми послідовностей

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

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

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

Рис. 4.4. Модель поведінки ІС

4.5 Концептуальна модель інформаційної системи на основі діаграми класів

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

Реєстратор:

- одержати всі необхідні дані від пацієнта;

- ввести дані про пацієнта у випадки первинної реєстрації пацієнта;

- знайти в ІС номер амбулаторної карти пацієнта;

- видати талон до лікаря.

Інформаційна система:

- прийняти всі необхідні дані об пацієнта, у випадки якщо він реєструється вперше;

- забезпечити результат пошуку амбулаторної карти пацієнта ІС по декількох параметрах пошуку;

- видати талон відповідно до розкладу лікаря і наявної черги до нього.

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

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

Рис. 4.5. Концептуальна модель ІС. Діаграма класів

Цільова модель класів містить атрибути і операції, одержані в ході розробки моделі поведінки.

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



Рис. 4.7 Завдання атрибутів класу

Зі всіх графічних елементів середовища IBM Rational Rose 2003 клас володіє максимальним набором властивостей, головними з яких є його атрибути і операції.

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

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



Рис. 4.8. Цільова модель класів

Висновки

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

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

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

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

Список літератури

1. Амриш К.И., Ахмед Х.З. Разработка корпоративных Java-приложений с использованием J2EE и UML. Пер. с англ. - М.: «Вильямс», 2002. - 272 с.

2. Боггс У., Боггс М. UML и Rational Rose - М.: «ЛОРИ», 2000. - 582 с.

3. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя - М.: ДМК, 2000. - 432 с.

4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем - М: «Финансы и статистика», 2000

5. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования - СПб: «Питер», 2001. - 368 с.

6. Гома Х. UML. Проектирование систем реального времени, параллельных и распределенных приложений - М.: «ДМК Пресс», 2002. - 704 с.

7. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. Интернет-университет информационных технологий - ИНТУИТ.ру, 2008

8. Грехем И. Объектно-ориентированные методы. Принципы и практика - М.: «Вильямс», 2004. - 880 с.

9. Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление - М.: ИНФРА-М, 2004

10. Калянов Г.Н. Структурный системный анализ - М.: Лори, 1997

11. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов - М.: СИНТЕГ, 2000

12. Ларман К. Применение UML и шаблонов проектирования - М.: «Вильямс», 2001. - 496 с.

13. Леоненков А.В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose. БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2006

14. Леоненков А.В. Самоучитель UML. 2-е издание - СПб.: «БХВ-Петербург», 2004. - 432 с.

15. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход - М.: «Вильямс», 2002. - 448 с.

16. Нейбург Э.Дж., Максимчук Р.А. Проектирование баз данных с помощью UML - М.: «Вильямс», 2002. - 288 с.

17. Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник - СПб: «Питер», 2001. - 656 с.

18. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов - М.: «ДМК Пресс», 2002. - 160 с.

19. Санблэд С., Санблэд С. Разработка масштабируемых приложений для Microsoft Windows. Мастер-класс - М.: ИТД «Русская редакция», 2002. - 416 с.

20. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник - М.: «Финансы и статистика», 2002

21. Фаулер М., Скотт К. UML. Основы - СПб: «Символ-Плюс», 2002. - 192 с.

22. Шаллоуей А., Тротт Дж.Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию - М.: «Вильямс», 2002. - 288 с.

23. Шмуллер Д. Освой самостоятельно UML за 24 часа - М.: «Вильямс», 2002. - 352 с.

24. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения - СПб: «Питер», 2002. - 496 с.

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