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

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

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

Вступ

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

1.6 Джерела розробки

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

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

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

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

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

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

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), кожне з яких адекватно відбиває аспект поводження або структури системи. При цьому найбільш загальними представленнями складної системи прийнято вважати статичні і динамічне, котрі у свою чергу можуть підрозділятися на інші більш частки.

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

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

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

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

Рис. 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 може бути представлена у виді сукупності зазначених вище діаграм.

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

Рис. 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 узагальнюють поняття дуг і ребер з теорії графів, але мають менш формальний характер і більш розвиту семантику.