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

ЗМІСТ Вступ

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

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

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

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

3. Теоретична частина. Визначення візуального моделювання програмного забезпечення

3.1 Аналіз та проектування

3.2 Візуальне моделювання. Історія мови UML

3.3 Структура мови UML

3.4 Навчальний приклад. Постановка завдання

3.5 Візуальний опис функціональної моделі засобами UML

3.6 Структура системи та її опис засобами UML

4. Практична частина

4.1 Використання UML в проектуванні ПЗ

4.2 Загальна характеристика CASE-засобів Visual Paradigm

4.3 Інтерфейс програми VP-UML

4.4 Принцип роботи в VP-UML

4.5 Лабораторний практикум

4.5.1 Лабораторна робота № 1 «Діаграма прецедентів»

4.5.2 Лабораторна робота № 2 «Діаграми класів»

4.5.3 Лабораторна робота № 3 «Діаграма послідовності»

4.5.4 Лабораторна робота № 4 «Діаграма комунікацій»

Висновок Література

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

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

Мова моделювання повинен включати:

* Елементи моделі - фундаментальні концепції моделювання та їх семантику

* Нотацію — візуальне представлення елементів моделі

* Керівництво — ідіоми використання при роботі

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

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

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

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

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

1. ЛІТЕРАТУРНИЙ ОГЛЯД. Сучасні технології об'єктно-орієнтованого аналізу та проектування інформаційних систем Концепції об'єктно-орієнтованого аналізу і проектування. Еволюція та коротка характеристика основних підходів до розробки інформаційних моделей бізнес-систем і бізнес-процесів. Особливості проектування, аналізу та формалізації корпоративних систем. Основні етапи розвитку мови UML і прийняті стандарти. Розробники графічної нотації і специфіка її використання в процесі створення масштабованих програмних систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об'єктно-орієнтований аналіз та проектування (ООАП, Object-Oriented Analysis / Design)-технологія розробки програмних систем, в основу яких покладена об'єктно-орієнтована методологія подання предметної області у вигляді об'єктів, що є екземплярами відповідних класів.

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

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

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

* діаграми «сутність-зв'язок» (Entity-Relationship Diagrams, ERD),

* діаграми функціонального моделювання (Structured Analysis and Design Technique, SADT),

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

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

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

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

Графічна модель даних будується таким чином, щоб зв’язки між окремими сутностями відображали не тільки семантичний характер відповідного ставлення, але й додаткові аспекти обов’язковості зв’язків, а також кратність що беруть участь в даних відносинах екземплярів сутностей. Нотація діаграм (ERD) реалізована в різних програмних засобах. Приклад діаграми ERD, розробленої за допомогою засобу моделювання бізнес-процесів ARIS ®, зображений на рис. 1.2.

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

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

* Нотація IDEF0 — для документування процесів виробництва і відображення інформації про використання ресурсів на кожному з етапів проектування систем

* Нотація IDEF1 — для документування інформації про виробничий оточенні систем

* Нотація IDEF2 — для документування поведінки системи в часі

Нотація IDEF2 ніколи не була повністю реалізована. Нотація IDEF1 в 1985 році була розширена і перейменована в IDEF1X. Методологія IDEF знайшла застосування в урядових і комерційних організаціях, оскільки в 1993 році з’явився стандарт FIPS уряду США для двох технологій IDEF0 і IDEF1X. Протягом наступних років цей стандарт продовжував активно розвиватися і послужив основою для реалізації в деяких CASE-засобах, найбільш відомим з яких є AllFusion Process Modeler ® (нова назва BPwin ®) компанії Computer Associates.

Процес моделювання IDEF являє собою сукупність методів, правил і процедур, призначених для побудови функціональної моделі системи будь-якої предметної області. Функціональна модель IDEF відображає структуру процесів функціонування системи та її окремих підсистем, тобто, виконувані ними дії і зв’язки між цими діями. Для цієї мети будуються спеціальні моделі, які дозволяють в наочній формі представити послідовність певних дій. Вихідними будівельними блоками будь-якої моделі нотації IDEF0 процесу є діяльність (activity) і стрілки (arrows).

Одна з найбільш важливих особливостей нотації IDEF0 — поступове введення все більш детальних уявлень моделі системи у міру розробки окремих діаграм. Побудова моделі IDEF0 починається з представлення всієї системи у вигляді найпростішої діаграми, що складається з одного блоку процесу і стрілок ICOM, що служать для зображення основних видів взаємодії з об'єктами поза системою. Оскільки вихідний процес представляє всю систему як єдине ціле, дане подання є найбільш загальним і підлягає подальшій декомпозиції. Приклад подання загальної моделі процесу оформлення кредиту в банку, розробленої за допомогою CASE-засобу AllFusion Process Modeler ®, зображений на рис. 1.3.

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

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

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

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

2. ПОСТАНОВКА ЗАВДАННЯ В даній дипломній роботі «Проектування програмного продукту із застосуванням систем візуального моделювання» необхідно виконати наступне:

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

Аналіз та проектування Візуальне моделювання. Історія мови UML

Структура мови UML

Візуальне опис функціональної моделі засобами UML

Структура системи та її опис засобами UML

У практичній частині розглянути:

· Використання UML в проектуванні ПЗ

· Характеристику CASE-засоби Visual Paradigm

· Інтерфейс програми VP-UML

· Принцип роботи в VP-UML

В лабораторному практикумі розробити методичні рекомендації щодо виконання лабораторних робіт Лабораторна робота № 1 «Діаграма прецедентів»

Лабораторна робота № 2 «Діаграми класів»

Лабораторна робота № 3 «Діаграма послідовності»

Лабораторна робота № 4 «Діаграма комунікацій»

3. ТЕОРЕТИЧНА ЧАСТИНА Визначення візуального моделювання програмного забезпечення

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

Принципово можна виділити 2 види розбиття предметної області на складові елементи:

— Алгоритмічна декомпозиція (основні елементи програми — будівельні блоки — алгоритми).

— Об'єктна декомпозиція (основні елементи програми — види абстракцій (класи) та представники цих класів (об'єкти)).

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

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

На сьогоднішній день об'єктний підхід і його основи — об'єктна модель і об'єктна декомпозиція — підтримуються сучасними об'єктно-орієнтованими мовами програмування (Object Pascal, C + +, Java, C # …).

Як було сказано раніше, основами об'єктного підходу є об'єктна модель і об'єктна декомпозиція. Розглянемо коротко складові частини об'єктного підходу, грамотне виконання яких, як правило, призводить до створення якісного програмного продукту.

Об'єктний підхід:

— OOA (object oriented analysis) — об'єктно-орієнтований аналіз.

— OOD (object oriented design) — об'єктно-орієнтоване проектування.

— OOP (object oriented programming) — об'єктно-орієнтоване програмування.

Розглянемо коротко ці ключові поняття (визначення Г. Буча):

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

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

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

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

Розглянемо найбільш важливі принципи об'єктного підходу.

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

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

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

Повторне використання — застосування вже існуючих напрацювань в розробляється ПО.

Повторне використання — важливий елемент проектування. Необхідно проектувати нові елементи системи з тим, щоб їх надалі можна було застосовувати при розробці інших систем. Крім того, при проектуванні системи необхідно розглядати можливість використання того, що вже є і працює. Переваги повторного використання (по Соммервіль, [1]):

— Підвищення надійності.

— Зменшення проектних ризиків.

— Ефективне використання фахівців.

— Дотримання стандартів (приклад: користувальницький інтерфейс).

— Прискорення розробки.

Повторне використання досягається за рахунок наступних прийомів (видів використання):

— Компонентна розробка. Частина компонентів вже розроблені раніше, мають чітко описаний інтерфейс. Вони використовуються в якості «цеглинок» у новій системі.

Використання патернів (шаблонів) проектування. Застосовуються відомі підходи до вирішення деяких зустрічалися раніше проблем.

Використання стандартних прикладних (MKL, MFC …) і системних (API) бібліотек.

3.2 Візуальне моделювання. Історія мови UML

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

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

Відповімо на запитання, навіщо будують моделі? Моделі будують для того, щоб краще зрозуміти досліджувану систему.

Класики проклассифицировать завдання і принципи моделювання. Наведемо тут цю, поза сумнівом, важливу, класифікацію.

Завдання моделювання [3]:

— Візуалізація системи в її деякому стані.

— Визначення структури і поведінки системи.

— Отримання шаблону для створення системи.

— Документування прийнятих рішень.

Принципи моделювання [3]:

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

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

— Кращі моделі - ті, що ближче до реальності.

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

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

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

Це і означає необхідність візуального моделювання.

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

— Візуалізація спрощує розуміння проекту в цілому.

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

— Візуалізація робить обговорення конструктивним і зрозумілим.

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

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

Розглянемо коротко історію мови UML. До 1994 року існувало кілька нотацій для візуального відображення прийнятих проектних рішень і кілька методів аналізу і проектування. У 1994 році відбулася знакова подія — Grady Booch і James Rumbaugh, співробітники фірми Rational Software, об'єднали свої методи проектування та аналізу, створивши так званий Unified method. З цього моменту процес стандартизації домовленостей увійшов в робочий ритм. Наведемо важливі віхи цього шляху:

— 1994: Grady Booch & James Rumbaugh (Rational Software) об'єднали методи Booch (проектування) і OMT (аналіз) -> Unified method.

— 1995: приєднався Ivar Jacobson (автор методу OOSE). Згодом група авторів Booch, Rumbaugh і Jacobson разом випустила не одну книгу, що стала бестселером (наприклад, див список літератури). Цю трійцю жартівливо називали «three amigos», натякаючи на те, як жарко вони сперечалися з приводу прийнятих рішень.

— 1996 — Ідея про Unified Modeling Language (three amigos).

— 1996 — створено консорціум UML Partners під керівництвом three amigos.

— Червень, Жовтень 1996 — UML 0.9 & UML 0.91.

— Січень 1997 — специфікації UML 1.0 запропоновані OMG (Object Management Group).

— Серпень 1997 — специфікації UML 1.1 запропоновані OMG.

— Листопад 1997 — UML 1.2 — результат адаптації OMG.

— Червень 1999 — UML 1.3.

— Вересень 2001 — UML 1.4.

— Березень 2003 — UML 1.5.

Прийнятий стандарт:

— ISO / IEC 19 501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2.

— Жовтень 2004 — UML 2.0.

3.3 Структура мови UML

UML дозволяє описувати систему наступними моделями:

— Модель функціонування (показує, як описується функціональність системи з точки зору користувача).

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

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

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

UML 2.0 містить 13 типів діаграм. У тому числі:

— Структурні діаграми (6).

— Діаграми поведінки (3).

— Діаграми взаємодії (4).

Розглянемо кожну з груп детальніше:

Структурні діаграми:

— Діаграма класів — показує класи, їх атрибути та зв’язки між класами.

— Діаграма компонентів — показує компоненти і зв’язки між ними.

— Структурна діаграма — показує внутрішню структуру класів і зв’язки з зовнішнім світом.

— Діаграма розгортання — показує, як ПО розміщується на апаратурі (серверах, робочих станціях …).

— Діаграма об'єктів — показує структуру системи в конкретний момент часу, об'єкти, їх атрибути …

— Діаграма пакетів — показує, як система розкладається на великі складові частини та зв’язки між цими частинами Діаграми поведінки:

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

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

— Діаграма варіантів використання — показує роботу системи з точки зору користувачів.

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

— Діаграма кооперації - показує структурну організацію беруть участь у взаємодії об'єктів.

— Діаграма взаємодії (новація UML 2.0).

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

— Тимчасова діаграма — діаграма пов’язана з тимчасовими рамками проекту.

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

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

— Завдання є математичною. Система повинна вміти вирішувати однокрітеріальним завдання пошуку найкоротших шляхів на графах. Критерій — ціна.

— Система розподілена: оскільки в кожному аеропорту своя база напрямків польотів літаків, то знають про рейс тільки аеропорти-сусіди по рейсам.

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

— Розподілене сховище рейсів: назва рейсів, номера та ціни на квитки.

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

Серед причин:

— Відсутність рейсів в бажаному напрямі навіть з урахуванням пересадок.

— Брак грошей.

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

— Менеджер рейсів: повинен мати такі можливості:

· створення та видалення аеропортів в системі.

· створення та видалення рейсів в аеропортах.

3.5 Візуальний опис функціональної моделі засобами UML

Програмна система не функціонує сама по собі. Програмна система функціонує під впливом акторів (Actor) — користувачів, машин та інших програм. При цьому актор очікує, що система поводиться строго певним чином. Актор впливає - система видає очікуваний результат. У випадку, якщо очікуваного результату немає, вимоги користувача не задоволені з усіма витікаючими звідси результатами. Таким чином, актор в UML — людина, машина чи програма, впливає на систему, є зовнішнім по відношенню до неї. Модель того, як вплив призводить до результату, називається Варіантом використання (Use case). Актори і варіанти використання мають спеціальні позначення в UML:

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

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

Перелік Варіантів використання для нашої задачі може бути, наприклад, таким:

— Забронювати квиток.

— Підібрати рейс.

— Працювати з даними.

— Керувати рейсами.

— Працювати з БД аеропорту.

Для візуального представлення акторів, варіантів використання і відносин між ними в UML передбачена спеціальна діаграма — діаграма варіантів використання. Нижче приведена діаграма для розглянутого прикладу:

Наведемо деякі додаткові міркування [3]:

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

— Хороша модель описує основну поведінку системи, не будучи надто детальним.

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

— Система середніх розмірів може бути описана великою кількістю варіантів використання.

— Варіанти використання можуть описуватися різними сценаріями.

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

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

Наведемо приклад відповідної діаграми для варіанту використання Бронювання квитків в системі SRS.

3.6 Структура системи та її опис засобами UML

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

Позначення модифікаторів доступа:

Шаблони класів

Об'єкти

Інтерфейси

Визначимося з тим, що ми в даному випадку розуміємо під Інтерфейсом.

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

Інтерфейс — це набір операцій, які використовуються для специфицирования послуг, що надаються класом або компонентом.

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

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

Пакети

Пакет — структурна одиниця для групування елементів моделі, зокрема, класів.

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

Підсистеми

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

Компоненти

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

Види компонентів:

— Вихідні файли (. cpp,. h,. java …).

— Бінарні файли (. dll,. ocx …).

— Виконувані файли (. exe).

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

Коментарі

UML передбачає можливість написання коментарів (нотаток). Робиться це в такий спосіб:

Відносини між елементами моделі

UML підтримує наступні види відносин між елементами моделі:

— Залежність.

— Асоціація.

— Узагальнення (успадкування).

— Реалізація (для Інтерфейсу).

Відносини показують наявність зв’язків між елементами моделі та семантику цих зв’язків.

Розглянемо кожен з цих типів відносин.

Залежність

Залежність — зв’язок між сутностями (класами, об'єктами). Залежність показує, що зміни в одній сутності можуть вплинути на іншу сутність. Залежність — не структурна зв’язок. Виникає через локальну, глобальну змінні або параметр методу.

TFirst зависит от TSecond

Асоціація

Асоціація — зв’язок між сутностями (класами, об'єктами). Асоціація показує наявність структурної зв’язку між екземплярами (об'єктами). Структурна зв’язок реалізується через поле класу. У позначеннях UML напрямок може бути не вказано (двосторонній зв’язок).

TFirst содержит поле, связанное с TSecond

Напрямок та навігація

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

Кратність

Кратність — спосіб конкретизації характеру відносини. Показує тип відносини 1:1, 1: M, N:1, N: M.

Кожному контейнеру відповідає M елементів. Кожному елементу відповідає 1 контейнер.

Окремі випадки асоціацій: агрегація і композиція

Агрегація припускає, що 0 або більше об'єктів одного типу включені в 1 або більше об'єктів іншого типу.

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

Узагальнення (успадкування)

TFirst и TSecond выведены из TSomeClass

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

4. ПРАКТИЧНА ЧАСТИНА

4.1 Використання UML в проектуванні ПЗ

UML 2.0 включає набір діаграм (рисунок 4.1), що використовуються для розробки різних моделей програмних і бізнес систем. Як видно з малюнка 1.1 діаграми поділяються на дві групи: структурні діаграми і процесні діаграми.

До структурних діаграм належать:

* діаграма класів;

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

* діаграма композитної структури;

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

* діаграма розміщення;

* діаграма пакетів.

До процесних діаграм належать:

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

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

* діаграми функцій;

* діаграми станів.

У свою чергу діаграми взаємодії поділяються на:

* діаграми послідовностей;

* оглядові діаграми потоків управління;

* комунікаційні діаграми;

* тимчасові діаграми.

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

Рисунок 4.1 — Діаграми UML 2.0

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

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

* Use case diagram (діаграма прецедентів) — діаграма, на якій відображені відносини, що існують між акторами і прецедентами;

* Class diagram (діаграма класів) — статична структурна діаграма, що описує структуру системи, що демонструє класи системи, їх атрибути і залежності між класами;

* Sequence diagram (діаграма послідовності дій) — діаграма, на якій зображено впорядковане в часі взаємодія об'єктів. Зокрема, на ній зображуються беруть участь у взаємодії об'єкти і послідовність повідомлень, якими вони обмінюються;

* Communication diagram (діаграма комунікації) — діаграма, на якій зображуються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються відносини між елементами (об'єктами), а час як окремий вимір не використовується (застосовуються порядкові номери викликів);