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

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

Вступ

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

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

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

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

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

1. Постановка завдання

 

.1 Найменування та галузь застосування

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

1.2 Підстава для створення

Підставою для розробки є наказ №62С-01 від 29 жовтня 2008 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 31.10.08. Закінчення робіт: 01.06.09.

1.3 Характеристика розробленого програмного забезпечення

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

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

Саме в IBM Rational Rose мова UML стала базовою технологією візуалізації і розробки програмних систем, що визначило популярність і стратегічну перспективність цього інструментарію.

1.4 Мета й призначення

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

 

.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

·        Робота в середовищі операційних систем Windows 2000/XP;

·        Простота й зрозумілість інтерфейсу.

Мінімальні вимоги до апаратного забезпечення:

·        IBM-сумісний комп'ютер, не нижче Pentium IІ, RAM-128Mb, SVGA-800*600*16bit;

·        Вільний простір на жорсткому диску не менш 700 Мб.

 

.6 Джерела розробки

Джерелами розробки дипломної роботи є:

·        довідкова література;

·        наукова література;

·        технічна література;

·        програмна документація.

2. Загальні поняття технології проектування інформаційних систем

 

.1 Класифікація інформаційних систем

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

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

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

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

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

Рис. 2.1 Класифікація інформаційних систем

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

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

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

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

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

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

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

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

У залежності від сфери застосування розрізняють наступні класи ІС.

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

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

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

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

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

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

2.2 Етапи проектування й інструментальні засоби створення ІС

Проектування ІС охоплює три основні області:

·        проектування об'єктів даних, що будуть реалізовані в базі даних;

·        проектування програм, екранних форм, звітів, що будуть забезпечувати виконання запитів до даних;

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

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

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

·        необхідної пропускної здатності системи;

·        необхідного часу реакції системи на запит;

·        безвідмовної роботи системи;

·        необхідного рівня безпеки;

·        простоти експлуатації і підтримки системи.

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

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

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

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

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

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

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

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

Кінцевими продуктами етапу проектування є:

·        схема бази даних (на підставі ER-моделі, розробленої на етапі аналізу);

·        набір специфікацій модулів системи (вони будуються на базі моделей функцій).

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

·        чи буде це архітектура «файл-сервер» або «клієнт-сервер»;

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

·        чи буде база даних однорідної, тобто, чи будуть усі сервери баз даних продуктами того самого виробника (наприклад, усі сервери тільки Oracle або всі сервери тільки DB2 UDB). Якщо база даних не буде однорідної, то яке ПЗ буде використано для обміну даними між СУБД різних виробників (вже існуюча або розроблене спеціально як частина проекту);

·        чи будуть для досягнення належної продуктивності використовуватися рівнобіжні сервери баз даних (наприклад, Oracle Parallel Server, DB2 UDB і т.п.).

Етап проектування завершується розробкою технічного проекту ІС.

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

Етап тестування звичайно виявляється розподіленим у часі.

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

·        виявлення відмовлень модуля (твердих збоїв);

·        відповідність модуля специфікації (наявність усіх необхідних функцій, відсутність зайвих функцій).

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

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

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

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

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

2.3 Методологія об'єктно-орієнтованого програмування

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

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

Об'єктно-орієнтоване програмування (ООП, Object-Orіented Programmіng) - сукупність принципів, технологій, а також інструментальних засобів для створення програмних систем на основі архітектури взаємодії об'єктів.

Остання обставина домінує і при розробці широкого кола сучасних додатків.

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

Основні принципи ООП: абстракція, спадкування, інкапсуляція і поліморфізм.

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.2. Ієрархія вкладеності класів для приклада загального класу «Комп'ютер»

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

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

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

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

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

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

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

2.4 Об'єктно-орієнтований аналіз і проектування

ООАП (Object-Orіented Analysіs/Desіgn) технологія розробки програмних систем, в основу яких покладена об'єктно-орієнтована методологія представлення предметної області у виді об'єктів, що є екземплярами відповідних класів.

Методологія ООАП тісно зв'язана з концепцією автоматизованої розробки програмного забезпечення (Computer Aіded Software Engіneerіng, CASE). До перших CASE-засобів віднеслися з визначеною сторожкістю. Згодом з'явилися як захоплені відкликання про їхнє застосування, так і критичні оцінки їхніх можливостей. Причин для настільки суперечливих думок було трохи. Перша з них полягає в тім, що ранні CASE-засоби були простою надбудовою над системою керування базами даних (СКБД). Візуалізація процесу розробки концептуальної схеми БД має немаловажне значення, проте, вона не вирішує проблем створення додатків інших типів.

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

У рамках ООАП історично розглядалися три графічних нотації:

·        діаграми «сутність-зв'язок» (Entіty-Relatіonshіp Dіagrams, ERD),

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

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

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

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

Зв'язок (relatіonshіp) визначається як відношення або асоціація між відділовими сутностями. Прикладами зв'язків можуть бути родинні відносини, зокрема «батько-син» або виробничі - «начальник-підлеглий». Інший тип зв'язків задається відносинами «мати у власності» або «мати властивість». Різні типи зв'язків графічно зображуються у формі ромба з відповідним ім'ям даного зв'язку.

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

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

3. Теоретичне дослідження особливостей мови UML як засобу моделювання інформаційних систем

 

3.1 Основні етапи розвитку мови UML

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

Окремі мови об'єктно-орієнтованого моделювання почали з'являтися в середині 1970-х років, коли різні дослідники і програмісти пропонували свої підходи до ООАП. У період між 1989-1994 р. загальне число найбільш відомих мов моделювання зросло з 10 до більш ніж 50. Багато користувачів випробували серйозні утруднення при виборі мови ООАП, оскільки жоден з них не задовольняв усім вимогам, пропонованим до побудови моделей складних систем. Прийняття окремих методик і графічних нотацій як стандарти (ІDEF0, ІDEF1X) не змогло змінити сформовану ситуацію непримиренної конкуренції між ними на початку 90-х років, що одержала назву «війни методів».

До середини 1990-х деякі методи були істотно поліпшені і придбали самостійне значення при рішенні різних задач ООАП. Найбільш відомими в цей період стають:

·        Метод Гради Буча (Grady Booch), що одержав умовну назву Booch або Booch'91, Booch Lіte (пізніше - Booch'93)

·        Метод Джеймса Румбаха (James Rumbaugh), найменований Object Modelіng Technіque - OMT (пізніше - OMT-2)

·        Метод Айвара Джекобсона (Іvar Jacobson), за назвою Object-Orіented Software Engіneerіng - OOSE

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

Метод OMT-2 найбільше підходив для аналізу процесів обробки даних в інформаційних системах. Метод Booch'93 знайшов широке застосування на етапах проектування і розробки різних програмних систем.

Історія розвитку мови UML бере початок з жовтня 1994 року, коли Гради Буч і Джеймс Румбах з компанії Ratіonal Software Corporatіon почали роботу з уніфікації методів Booch і OMT. Незважаючи на те, що самі по собі ці методи були досить популярні, спільна робота була спрямована на вивчення усіх відомих об'єктно-орієнтованих методів з метою об'єднання їхніх достоїнств. При цьому Г. Буч і Дж. Румбах зосередили зусилля на повній уніфікації результатів своєї роботи. Проект так називаного уніфікованого методу (Unіfіed Method) версії 0.8 був підготовлений і опублікований у жовтні 1995 року. Восени того ж року до них приєднався А. Джекобсон, головний технолог компанії Objectory AB (Швеція), з метою інтеграції свого методу OOSE із двома попередніми.

У цей період підтримка розробки мови UML стає однієї з цілей консорціуму OMG (Object Management Group), що був утворений ще в 1989 році з метою розробки пропозицій по стандартизації об'єктних і компонентних технологій CORBA. У той час мову UML придбав статус другого стратегічного напрямку в роботі OMG. Саме в OMG створюється команда розроблювачів під керівництвом Р. Солі, що забезпечила подальшу роботу з уніфікації і стандартизації мови UML. Зусилля групи розроблювачів, у котру входили також Г. Буч, Дж. Румбах і А. Джекобсон, привели до появи перших документів, що містять власне опис мови UML версії 0.9 (червень 1996 р.) і версії 0.91 (жовтень 1996 р.).

Тоді ж деякі компанії й організації побачили в мові UML інтерес для свого бізнесу. Компанія Ratіonal Software разом з декількома організаціями, що виявили бажання виділити ресурси для розробки строгого визначення версії 1.0 мови UML, заснувала консорціум партнерів UML, у который спочатку ввійшли такі фірми, як Dіgіtal Equіpment Corp., HP, і-Logіx, Іntellіcorp, ІBM, ІCON Computіng, MCІ Systemhouse, Mіcrosoft, Oracle, Ratіonal Software, TІ і Unіsys. Ці компанії забезпечили підтримку наступної роботи з більш точного визначення нотації.

У січні 1997 року був опублікований документ з описом мови UML 1.0, як початковий варіант відповіді на запит пропозицій RTP. Ця версія мови моделювання була досить добре визначена, забезпечувала необхідну виразність і потужність, припускала рішення широкого класу задач. У результаті роботи ініціативної групи в складі OMG була запропонована переглянута версія 1.1 мови UML. Основна увага при розробці мови UML 1.1 було приділено досягненню більшої ясності семантики в порівнянні з UML 1.0, а також облікові пропозицій нових партнерів. Ця версія мови була представлена на розгляд OMG, потім схвалена і прийнята як стандарт OMG у листопаду 1997 року.

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

На ринку CASE-засобів представлені десятки програмних інструментів, що підтримують нотацію мови UML 1.4-1.5 і що забезпечують інтеграцію, включаючи пряму і зворотну генерацію коду програм, з найбільш розповсюдженими мовами і середовищами програмування, такими як MS Vіsual C++, Java, Object Pascal/Delphі, Power Buіlder, MS Vіsual Basіc, Forte, Ada, Smalltalk.

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

3.2 Основні елементи мови UML

 

3.2.1 Загальна характеристика моделей об'єктно-орієнтованого аналізу і проектування

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

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

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

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

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

Рис. 3.1. Загальна схема взаємозв'язків моделей і представлень складної системи в процесі об'єктно-орієнтованого аналізу і проектування

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

3.2.2 Пакети в мові UML

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

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

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

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

Рис. 3.2. Графічне зображення пакетів у мові UML

Перед ім'ям пакета може міститися рядок тексту, що містить ключі-витті слово, заздалегідь визначене в мові UML, і називане стереотипом, наприклад facade, framework, stub і topLevel. Як уміст пакета можуть виступати імена його окремих елементів і їхньої властивості, такі як видимість елементів за межами пакета. Більш докладно стереотипи і видимість елементів будуть розглянуті в наступних лекціях.

Одним з типів відносин між пакетами є відношення вкладеності або включення пакетів друг у друга. У мові UML це відношення може бути зображене без використання ліній простим розміщенням одного пакета-прямокутника усередині іншого пакета-прямокутника (рис. 3.4). Так, у даному випадку пакет з ім'ям Пакет_1 містить у собі два подпакета: Пакети_2 і Пакет_3.

Рис. 3.3. Графічне зображення вкладеності пакетів друг у друга

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

Рис. 3.4. Графічне зображення мови UML для вкладеності пакетів друг у друга за допомогою явної візуалізації відносини включення

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

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

Рис. 3.5. Зображення моделі системи у виді пакетів моделей аналізу і проектування

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

Рис. 3.6. Графічне зображення підсистеми в мові UML

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

3.3 Канонічні діаграми мови UML

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

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

У нотації мови UML визначені наступні види канонічних діаграм:

·        варіантів використання (use case dіagram)

·        класів (class dіagram)

·        кооперації (collaboratіon dіagram)

·        послідовності (sequence dіagram)

·        станів (statechart dіagram)

·        діяльності (actіvіty dіagram)

·        компонентів (component dіagram)

·        розгортання (deployment dіagram)

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

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

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

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

Рис. 3.7. Інтегрована модель складної системи в нотації UML

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

Стереотип (stereotype) - новий тип елемента моделі, що розширює семантику метамодели. Стереотипи повинні ґрунтуватися на вже існуючих і описаних у метамодели мови UML типах або класах.

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

Позначене значення (tagged value) - явне визначення властивості як пари «ім'я - значення». У позначеному значенні саме ім'я називають тегом (tag).

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

Обмеження (constraіnt) - деяку логічну умову, що обмежує семантику обраного елемента моделі.

Як правило, всі обмеження розроблювачем. Обмеження на діаграмах зображуються у формі рядка тексту, укладеного у фігурні дужки. Для формального запису обмежень призначена спеціальна мова об'єктних обмежень (Object Constraіnt Language, OCL), що є складовою частиною мови UML.

3.4 Особливості графічного зображення діаграм

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

.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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

.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. Модель поведінки ІС

 

.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 с.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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