4. Об’єктно-орієнтоване моделювання та проектування систем електронної комерції (2017 р.)

ОБ’ЄКТНО-ОРІЄНТОВАНЕ МОДЕЛЮВАННЯ ТА ПРОЕКТУВАННЯ СИСТЕМ ЕЛЕКТРОННОЇ КОМЕРЦІЇ

МЕТОДИЧНІ ВКАЗІВКИ

до лабораторної роботи № 4

з дисципліни

«Технології електронної комерції та Інтернет-маркетингу»

для студентів з галузі знань 12 спеціальностей 122 «Комп’ютерні науки та інформаційні технології» та 124 «Системний аналіз»

Затверджено

на засіданні кафедри інформаційних систем та мереж

Протокол №__ від _____.2017 р.

Львів-2017

Об’єктно-орієнтоване моделювання та проектування систем електронної комерції: Методичні вказівки до лабораторної роботи № 4 / Укл.: В.А. Висоцька. – Львів: Видавництво Національного університету ”Львівська політехніка”, 2017. – 113 с.

Укладачі

                                      Висоцька В.А., к.т.н., доцент

Відповідальний за випуск Литвин В.В., д.т.н., професор

Рецензенти     Верес О.М., к.т.н., доцент

                          Чирун Л.В., к.т.н., доцент

                          Берко А.Ю., д.т.н., професор

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

1. Теоретичні відомості
   1. CASE-система

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

1. Основні етапи розвитку методологій розробки ПЗ.

Будь-яка CASE-система реалізує деяку методологію розробки ПЗ, що охоплює весь життєвий цикл програмного забезпечення (ЖЦ ПЗ). Життєвий цикл – це той шлях, який проходить ПЗ від зародження ідеї його створення до вилучення з експлуатації. ЖЦ, таким чином – це модель процесу розобки та супроводу ПЗ. Одною з перших таких моделей стала модель, згідно з якою процеси кодування й розробки ПЗ починаються майже одночасно. В основі такого підходу лежить уявлення про те, що написання програми, її відлагодження та наступну апроксимацію до фактичних вимог користувача необхідно здійснювати на якомога більш ранній стадії. В результаті відсутності попередніх етапів аналізу й проектування ПЗ як продукт має низькі характеристики якості, а наступна його модифікація надто ускладнена. Оптимальним варіантом є розробка подібних програм силами одного спеціаліста, оскільки проблеми управління програмним проектом фактично не піддаються розв’язанню. Управління перш за все розуміє контроль. А що, власне, можна контролювати? Процес написання оператора умовного переходу або підрахунок кількості begin та end? Розробка ПЗ для нас, в основному, це деякий вид мистецтва, а програміс- ти – вільні художники. Керувати такими “художниками” – справа майже безнадійна. Дуже складно щось сказати про строки й вартість розробки й практично нічого – про якість. Такий підхід тепер часто називають кустарним, іноді – традиційним. На жаль, саме він переважає у вітчизняних розробках.

В кінці 60-х з’явилась так звана каскадна мрдель ЖЦ (рис. 1). Вона припускає наявність послідовних етапів: аналізу, проектування й реалізації (значно пізніше був доданий ще один етап – стратегічного планування). Згодом і вона зазнала змін. Ідея, закладена в цій моделі, була добра,  але ще не сформувались методології підтримки окремих етапів і процесів розробки ПЗ в цілому. Це був час, коли дисципліна, що лежала в основі всіх аспектів розробки, – інженерія програмних засобів (software engineering) – тільки отримала свою назву. Сталась ця подія у 1968 р. на конференції поід егідою Наукового Комітету НАТО. Термін був винесен у назву конференції і, по задуму її організаторів, мав би навести на думку, що розробка ПЗ – це вже не мистецтво, а інженерна діяльність. Однак для формування самої дисципліни, частиною якої є методології розробки ПЗ та аспекти її автоматизації (тобто CASE-системи), знадобилося ще дуже багато часу. Історію формування сучасних методологій розробки ПЗ краще всього можна проілюструвати на структурних методологіях. Застосовувані повсюди й сьогодні, саме вони перетворили процес розробки ПЗ в інженерну дисципліну й були основою для виникнення популярних нині об’єктно-орієнтованих методологій. Незважаючи на їх різницю, всі наступні міркування однаково можна застосувати до обидвох методологій.

Рис. 1. Життєвий цикл програмного забезпечення

Все починалось зі структурного програмування. Це поняття з’явилось на початку 70-х років і концентрувало увагу насамперед на формі програмних модулів, приводячи їх до деякого стандартного вигляду. Завдяки цьому, вдалося покращити такі характеристики програм, як:

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

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

Структурне проектування сконцентрувало увагу на розв’язанні задач більш високого рівня – міжмодульної взаємодії. Окремі програмні модулі при цьому розглядаються як “чорні ящики” й слугують будівельними блоками для конструювання програм. Була підсилена стандартизація структури програм, введені обмеження на міжмодульну взаємодію та метрики (числові характеристики) якості програми. Таким чином, була запропонована дисципліна конструювання програми й, отже, втілення поставлених вимог  у деяку програмну конструкцію. Однак все ще залишалось не зовсім ясним, як формулювати та аналізувати вимоги. Крім того, байка про те, що сто програмістів напишуть за одними й тими самими вимогами сто різних програм, перейшла на проектування. Найсправді, структурне проектування не пов’язувало безпосередньо вимоги й структуру ПЗ, даючи спеціалістам достатньо більшу свободу дій, як у свій час програмістам. Саме це питання й було вирішене методологією структурного аналізу в кінці 70-х років.

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

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

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

1. Розробка ПЗ в межах сучасних методологій

Розглянемо докладніше питання про те, як власне працювати з сучасними мето-дологіями розробки ПЗ (в тому числі й з CASE-системами, що їх реалізують).Як вже було відмічено, все починається з етапа стратегічного планування (в деяких методологіях цей етап відсутній, і у CASE, відповідно). Розробляється узагальнена модель даної організації, яка описує або її інформаційні потреби, або процеси, що в ній протікають. Є прибічники обидвох підходів: наприклад, в методології Інформаційної інженерії (Information Engineering – IE) Джеймса Мартіна (James Martin) на перше місце ставляться інформаційні потреби, а в методології STRADIS фірми McDonnell Douglas – процеси. Розроблена модель стає основою, на котрій проводиться процес автоматизації даної організації, й джерелом планування цього процеса. Планується розподіл всіх видів ресурсів, визначаються послідовності робіт та їх пріорітети. Термін “стратегічний” свідчить про те, що мова йде про стратегію автоматизації, а не про розробку якогось ПЗ. Необхідність даного етапа зумовлена наступною ідеєю. В кінці кінців, стверджують прибічники такого підходу, ви прийдете до глобальної автоматизації вашої організації, отже чи не краще з цього починати, щоб уникнути складнощі, з якими стикнетесь у протилежному випадку. А складнощі можуть стати й неподоланними, якщо цей етап проегнорувати.

Історично процес автоматизації починався з розробки невеликих програм для окремих видів робіт та підрозділів. З часом з’явилась необхідність в об’єднанні окремих програм та систем в межах єдиної системи. Такий процес інтеграції породив проблему, схожу на ту, що у свій час була у програмах мови Фортран з печально відомою спільною (common) областю цієї мови. Безконтрольне векористання цієї можливості Фортрана та операції безумовного переходу (go to) привели до того, що програми стали нагадувати блюдо спагетті: багато програмних модулів якимось чином пов’язані між собою, але практично неможливо відслідкувати ці зв’язки. В результаті, неможливо було передбачити, до яких наслідків для всієї програми приведуть зміни в одному програмному модулі. До того ж й поведінка самої програми було, взагалі-то, непередба-ченою. Тепер все це повторюється вже на рівні інтегрованої системи. Окремі програми взаємопов’язані, адже вони функціонують в одній організації, але неймовірно складно визначити ці зв’язки. Процес інтеграції окремих програм в єдину систему може, таким чином, привести до необхідності повторної розробки вже наявного ПЗ. Далі розглянемо розв’язок цієї проблеми засобами реінжинірінга (reengineering). Отже, в результаті робіт на цьому етапі ми отримуєм концептуальну модель і план розробки. Концептуальна модель буде основою для наступного етапа – аналіза.

Етап аналіза починається з деталізації концептуальної моделі. Ми вже казали, що на цьому етапі визначається, що власне підлягаж розробці. В сучасних методологіях аналіза для цього передбачена розробка сукупності моделей, що відображають різні аспекти проблеми. Процеси і потоки інформації, що протікають між ними, відобража-ються діаграмами потоків даних (Data Flow Diagram – DFD), інвормаційні потреби розроблюваної системи – діаграмами сутність-зв’язок (Entity-Relationship Diagram – ERD), часові аспекти функціонування – діаграмами станів-переходів (State Transition Diagram – STD) (рис. 2). Всі три типи діаграм застосовуються і на етапі стратегічного планування, але на більш узагальненому рівні.

Рис. 2 Графічне представлення моделей та архітектури ПЗ

На DFD відображаються потоки даних, процеси, що перетворюють вхідні потоки  у вихідні, сховища інформації, джерела і споживачі інформації, зовнішні по відношенню до системи. Кожен з процесів може бути представлений діаграмою більш низького рівня. В подальшому ці діаграми служать основою для формування структури (що частіше називається архітектурою) розроблюваного ПЗ. На ERD зображаються так звані сутності (інформація, що представляє інтерес з точки зору наступного зберігання) та зв’язки між сутностями (з відображенням характера зв’язків). Ця діаграма є основою для проек-тування баз даних. На STD відображаються стани, в яких може знаходитись система, а також і можливі переходи з одного стану в другий. На основі діаграм потім будується інтерфейс користувача. Даний етап закінчується добуванням попередньої архітектури системи з сукупності моделей, і ця інформація передається на наступний етап. Формується так званий словник даних (Data Dictionary) – перелік описів всіх можливих елементів моделей. В результаті ми отримуєм:

• модель ПЗ, що являє собою сукупність моделей DFD, ERD та STD;
• словник даних з описом всіх елементів моделей: потоків даних, сховищ даних, процесів (у вигляді так званих міні-специфікацій), сутностей та їх атрибутів, а також зв’язків між сутностями (з описом характера цих зв’язків), станів та переходів;
• план тестування;
• попередню архітектуру системи,

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

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

• архітектуру системи у вигляді так званої структурної схеми (Structure Chart – SC), на якій відображені програмні модулі та зв’язки між ними, а також дані, що передаються від одного модуля до іншого;
• проект БД та інтерфейсу користувача;
• словник даних, що містить опис цих даних та їх структури;
• специфікації модулів з описом їх призначення та особливостей;
• проект архітектурних тестів (при яких модулі розглядаються як “чорні ящики” без врахування їх внутрішньої структури).

Вся ця інформація передається на етап подальшого проектування. Тут розробляються алгоритми програмних модулів на основі їх специфікацій, отриманих на попередньому етапі, а також проекти модульних тестів з врахуванням їх структури (часто говорять – по методу “білого ящика”), і все це потім переходить на етап реаліза-ції. На етапі реалізації програмні модулі кодуються на обраній мові програмування у відповідності до розроблених алгоритмів та відлагоджуються. Далі, виходячи з проектів тестів (архітектурних та модульних), кодуються тести, й за планом тестування прово-диться тестування програмної системи. Після цього розроблене ПЗ рередається на супровід. Життєвий цикл розробки на цьому закінчується та починається життєвий цикл ПЗ. Тепер підсумуєм все вищесказане. Відмітим, перед усім, найсуттєвішу відмінність сучасних методологій розробки. Вона полягає у тому, що роботи кожного наступного етапу не просто базуються на результатах пепереднього, а є безпосереднм їх наслідком. Насправді, сформульована проблема (описана явно чи неявно) наче транслюється у модель ПЗ, яка, в свою чергу, транслюється в архітектуру ПЗ, а остан-ня – у програмний код. Це надає можливість навігації по проекту згори вниз та знизу вгору. Можна визначити для деякої частини вимог (елементів моделей), який програмний код їм відповідає. І навпаки, взявши деяку частину кода, можна однозначно заключити, яку частину вимог він реалізує. Актуальне питання про те, чи дійсно дане ПЗ задовільняє висунутим вимогам, знімається з повістки дня.

Кожен етап містить свої критерії якості, за посередництвом яких оцінюються результати здійсненої роботи. Таким чином, можна оцінити як проміжні продукти розробки (моделі, архітектуру), так і кінцевий результат – ПЗ.

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

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

1. Склад та структура CASE-систем

Ми коротко розглянули історію формування сучасних методологій розробки ПЗ та їх практичне застосування. По мірі розвитку цих методологій відбувалась і їх автома-тизація. У промисловості вже існували такі системи, як CAD (Computer-Aided Design – автоматизація проектування) та CAM (Computer-Aided Manufacturing – автоматизація виробництва). У сфері розробки ПЗ аналогічні системи з’явились значно пізніше, та їм відповідали CASA (Computer-Aided Systems Analysis – автоматизація аналізу систем) та CAP (Computer-Aided Programming – автоматизація програмування). Їх об’єднання і породило CASE (Computer-Aided Software Engineering). Причому букву S в абревіатурі іноді трактують як слово “system” (система) – в цьому випадку говориться про розробку не тільки програмного, а програмно-апаратного забезпечення. Роком народження CASE вважається 1984 р., коли на ринку ПЗ з’явились перші графічні засоби аналізу. У вітчизняній літературі так досі й не прийшли до якогось одного варіанта перекладу цього терміну. Ви можете зустріти наступне: система автоматизації проектування програмного забезпечення (САПР ПЗ); автоматизація інженерії програмних засобів; автоматизація розробки ПЗ; автоматизація програмування. Перше і останнє визначення відображають лише частину можливостей CASE та відповідають CASA й CAP. Друге навряд чи правильне, оскільки інженерія програмних засобів – це лише дисципліна, яка включає і аспекти автоматизації (тобто власне CASE). Ближче за змістом, напевно, третє визначення, а більш точно його можна було б сформулювати наступним чином: автоматизація проектування та реалізації ПЗ, де під проектуванням розуміється все, що передує реалізації.

Отже, CASE забезпечили автоматизацію протягом всього ЖЦ ПЗ рівномірною підтримкою всіх його етпів. Це є головним аспектом CASE, але не єдиним. Сучасні розробки вимагають зусиль десятків та сотень спеціалістів. Отже, якимось чином має вирішуватись проблема координації їх робіт. Роль диригентів взяли на себе менеджери програмних проектів, діяльність яких також необхідно було автоматизувати. Іншою проблемою, що вимагає вирішення, стала якість ПЗ, від якого залежить функціонування всієї організації. Причому чим вище рівень її автоматизації, тим вище ризик від застосування ПЗ.Черговою задачею є виконання вимог на розробку ПЗ. Незважаючи на ефективні методології аналізу, по закінченні розробки виявляється маса неврахованих вимог (відповідно і нереалізованих). Виникла необхідність у макетуванні (прототипу-ванні) розроблюваного ПЗ з тим, щоб замовник міг якомога раніше отримати уявлення про те, що він буде мати в результаті. При цьому бажано максимально довести отриманий прототип до діючого ПЗ. І нарешті, проблема, що стосується впровадження CASE в організаціях, полягає у самому ПЗ, що вже знаходиться в експлуатації. Воно було розроблене задовго до того, як з’явились перші CASE, і не дуже й то вписується в них. Чи створювати ПЗ заново, але вже у відповідності до сучасних методологій на сучасних інструментальнич засобах – CASE? Але мова може йти про сотні тисяч і навіть мільйони рядків вихідного тексту. Не робити цього, але тоді як провести інтеграцію старого ПЗ з новим, якщо останнє розроблялось на CASE? Таким чином, знадобились способи препарування старого ПЗ з наступним приведенням його у відповідність до вимог сучасних методологій розробки й конкретної CASE-системи.

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

У далекі часи народження перших комп'ютерів єдиним засобом спілкування з ними була машинна мова.  Вона складалася з нулів та одиниць, за допомогою яких писалися програми.  Це було перше покоління мов програмування, робота на яких характеризувалася величезною трудомісткістю.  Тому написати щось більш-менш серйозне було практично нездійсненною задачею.  Єдиною їхньою перевагою була можливість писати дуже ефективні по пам'яті і швидкодії програми.  Частковим вирішенням проблеми високої трудомісткості стала поява мов асемблера.  Машинним командам були поставлені у відповідність більш придатні для сприйняття символьні аналоги.  Крім того, у таких мовах були введені узагальнені команди, так звані макрокоманди - сукупності команд, що виконують певні функції.  Продуктивність праці програмістів трохи підвищилася, але знизилася (за рахунок макрокоманд) ефективність програм.  Тепер мови асемблера прийнято називати мовами другого покоління.  Незважаючи на деяке просування вперед, вони були мовами все ще дуже низького рівня, і не дозволяли значного збільшення обсягів і складності програм.  Наступний крок у цьому напрямку був зроблений мовами третього покоління, такими як Фортран, Кобол та ін.  Тривало узагальнення конструкцій мов більш низького рівня, з'явилося таке поняття, як «підпрограми».  Стала можливою розробка відносно серйозних програм.  До того ж, почали формуватися сучасні методології розробки.  Особливістю всіх трьох поколінь мов програмування є їхній процедурний характер, який полягав у тому, що необхідно було точно описати, як має працювати комп'ютер для виконання необхідної задачі.  Різниця між цими мовами полягала у ступені деталізації такого опису.  Подальший розвиток мов програмування, з одного боку, пішов по старому шляху узагальнення конструкцій мов попередніх поколінь, з іншого боку - відзначився переходом від процедурного характеру опису до декларативного, тобто описується не те, як треба щось робити, а те, що, власне, треба робити.  Так з'явилися мови четвертого покоління - 4GL (4 Generation Language).  Вони побудовані на принципі таких узагальнених функцій, як створення екранних форм, баз даних і документів.  За описом таких функцій генерується програма або на одній із відомих мов програмування, або на специфичній для цього 4GL мові третього покоління.  Як правило, в інтерактивному режимі ви можете описати потрібні екранні форми - меню і підменю, поля вводу/виводу, контекстно-залежні підказкии.  Так само можна описати структури ваших баз даних, ключові і не-ключові поля, паролі доступу різного рівня. Аналогічно в інтерактивному режимі можна визначити структуру вихідних документів, призначених для друку.  Подальшим розвитком таких 4GL стали генератори програм (аплікацій), частиною яких вони тепер є.  Справа в тому, що 4GL частіше усього не реалізують складної програмної логіки й обчислень.  Крім того, вони не завжди (або обмежено) дозволяють підключати програмні модулі, написані на традиційних мовах програмування третього покоління.  Генератори компенсують ці недоліки. Принцип їхньої дії такий: що можна, те генерується (засобами 4GL).  Для фрагментів програми, що не піддаються генерації, підключаються вже готові до використання програмні модулі (off-the self) або генерується деякий шаблон, у котрий треба вписати програмний код вручну.  Як правило, фірми-постачальники СУБД здебільшого довели свої продукти до рівня 4GL.  Якийсь час 4GL пропонувалися як альтернатива CASE.  Справді, навіщо «городити город» із моделей, загального і детального проектування, коли можна взяти таку мову і зробити все, що потрібно. Проте практика показала, що такий підхід спрацьовує до певного рівня складності ПЗ, після перевищення якого програми починають поводитись у самий непередбачений спосіб. І отже, як і раніше необхідно старанно проектувати ПЗ, а вже потім переходити до його реалізації, навіть якщо воно цілком базується на 4GL. Таким чином, 4GL стали складовою частиною сучасних CASE.  Інформація, отримана на етапах аналізу і проектування, подається на 4GL, яка і генерує усе або частину (як правило, основну) ПЗ. Після етапу аналізу можна швидко розробити прототип, що демонструє основні функції і зовнішнє представлення розроблювального ПЗ, на його основі уточнити остаточні вимоги і далі довести його до діючого ПЗ. При необхідності можна дописати вручну окремі його частини.

Проблема приведення вже наявного ПЗ у відповідність з обраною методологією розробки (відповідно, із CASE, що її реалізує) вирішується в рамках так званого реінжинірінга ПЗ. Як правило, у ньому виділяють три аспекти: передокументування (redocumentation), переструктурування (restructuring) і зворотний інжинірінг (inverse, іноді - reverse, engineering).  Інструментальні засоби передокументування беруть на вхід існуючий вихідний текст програми і проводять його аналіз із метою одержання перехресних посилань і потоків керування в програмі.  При цьому генеруються блок-схеми (або інша графічна форма представлення) програми, опис даних і місця їх використання, а також інші особливості.  Функції засобів переструктурування програми передбачають аналіз вихідного тексту на предмет приведення коду до деякого стандартного вигляду й усунення надмірності.  Крім того, частина коду може бути створена наново.  Найважливішою частиною реінжинірінга є засоби зворотнього інжинірінга.  Коли ми говорили про методології розробки ПЗ, мався на увазі прямий інжинірінг: ми йшли від вимог через проектування (загальне і детальне) до вихідного тексту програм.  Тепер весь шлях проходиться в оберненому порядку.  На вхід засобів зворотного інжиніринга подається вихідний текст програми.  Після відповідного аналізу створюються алгоритми (наприклад, у вигляді блок-схем).  Далі реконструюється архітектура програми (у вигляді структурних схем).  І нарешті. створюється сукупність моделей ПЗ, що розглядається (діаграмами DFD, ERD, STD).  Потрібно врахувати, що на цьому шляху є певні складності, що вимагають втручання експертів.  Справа в тому, що буль-яке ПЗ, як відомо, має «два боки медалі» - дані і процедури їхньої обробки.  Існуючі методології розробки надають однозначну відповідність за даними: ERD - проект БД (наприклад. реляційні таблиці) - програмний код.  Все це можна проробити й у зворотному порядку при реінжинірінгу.  Інша справа з процедурами обробки.  Тут такої однозначності немає.  З однієї сукупності DFD можна створити декілька архітектур ПЗ, і всі вони будуть відповідати сформульованим вимогам.  Крім того, для отриманого алгоритму необхідний словесний опис.  Проте, при певних зусиллях проведення зворотного інжинірінга є можливе.  Вартість цих зусиль, за даними закордонної преси, може складати від 20 тисяч до кількох сотень тисяч доларів.  Але,  судячи з розширення ринку послуг та інструментальних засобів реінжинірінга, ці витрати себе окупають.  Після всіх робіт наступає самий відповідальний этап. заради чого все це і робиться, як-от аналіз на предмет поліпшення і розвитку ПЗ, що розглядається (рис. 3).  Але це вже аспекти прямого інжинірінга, який ми розглядали.  До найважливіших результатів даного процесу варто віднести можливість узгодження старого і знову розроблювального ПЗ.  Після проведення цієї роботи з'являється можливість використання CASE як інструмента супроводу ПЗ,  що пройшло реінжинірінг. Про деякі інші суттєві можливості розглянутих засобів згадаємо пізніше.  Головне, що засоби реінжинірінга стали складовою частиною CASE.

Рис. 3. Реінжинірінг ПЗ

Тепер обговоримо такі аспекти, як якість ПЗ і його зв'язок із CASE.  При традиційній розробці в результаті ми одержуєм вихідні тексти, документацію по експлуатації і неформальні (написані на природній мові) вимоги до ПЗ.  Якимось чином оцінити якість цієї інформації дуже складно.  У ті далекі часи, коли інформатика лише зароджувалась, такі спроби починалися і зводилися до визначення складності програм й окремих програмних модулів, ступеня їхньої коментованості і повноти реалізації вимог у розробленому ПЗ.  Про такі характеристики якості, як надійність, можливість розширення й адаптації ПЗ до середовища функціонування, що змінюється, мобільність та інші, можна було тільки ворожити.  Справді, складність і комнтованість не так вже й багато говорять про експлуатаційні властивості.  А відповідність ПЗ вимогам до нього взагалі не можна оцінити повною мірою.  Вимоги на розробку складалися на природній мові, що має багато масою неоднозначностей, унаслідок чого вони можуть інтепретуватися різними людьми найрізноманітнішим способом (аж до прямо протилежних).  Крім того, немає зв'язку цих вимог із кодом програм.  У сучасних методологіях такий зв'язок установлюється за допомогою етапів загального і детального проектування, що є ніби мостом між вимогами (сукупністю моделей етапу аналізу) і кодом.  Але головне навіть не в цьому.  При традиційній розробці ми одержуємо вже готову програму і є поставлені перед фактом її існування.  Припустимо, ми якимось чином прийшли до висновку про її низьку якість.  Що робити в цьому випадку?  Чи лишити усе як є і з примітками передати на експлуатацію?  Або спробувати відкоригувати і потім знову провести оцінку якості? Але програми, написані таким чином, подібні картковому будиночку - доторкнися їх, і вони розсипляться.  Ці проблеми і були вирішені (відносно повно) сучасною дисципліною якості ПЗ, заснованої на сучасних методологіях розробки.  Ця дисципліна складається із двох взаємозалежних частин: інженерії якості ПЗ (Software Quality Engineering - SQA) і забезпеченні якості ПP (Software Quality Assurance-SQA).  SQE займається питаннями оцінки якості як проміжних (етапів аналізу і проектування) продуктів програмного проекту, так і кінцевого (етапу реалізації), тобто власне ПЗ.  Вимоги на якість надходять на етап аналізу разом із функціональними вимогами на ПЗ.  Це усуває один із недоліків традиційної розробки, при якій вимоги на якість не пред'являлися.  Виконання цих вимог відслідковується протягом усього програмного проекту.  SQA займається організаційними питаннями оцінки і керування якістю протягом усього проекту для кожного етапу ЖЦ. Отже, ми розглянули ще одну складову частину сучасних CASE. Тепер, завершуючи обговорення складу сучасних CASE, перейдемо до інтеграції інформації й інструментальних засобів у цих системах, а також до пов'язаних з ними аспектами керування програмним проектом.

Як правило, виділяють наступні форми інтеграції:

• інтеграція даних; 
• інтеграція контролю;
• інтеграція представлення.

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

На жаль, немає якоїй-небудь узгодженої стратегії для побудови і використання інтегрованих CASE.  Найбільше серйозною спробою в цьому плані можна вважати стандарт на так званий каркас (framework) для інтеграції інструментальних засобів CASE.  Він розроблений у рамках Європейської асоціації виробників комп'ютерів (European Computer Manufacturers Assotiation - ECMA).  Зміст запропонованого підходу полягає в тому, що такий каркас для CASE повинен слугувати об'єднанню множини методологій і інструментальних засобів «під одним дахом» (рис. 4). Всі види інтеграції сприяють ефективності керування програмним проектом, що здійснюється засобами IPSE та ICASE. Треба відзначити,  що існує деяка плутанина в поняттях IPSE (Integrated Project Support Envirounment - інтегроване середовище підтримки проекту) та ICASE (Integrated CASE - інтегрована CASE).  Різниця між ними в тому, що ICASE розробляється, як правило, одним постачальником і є призначена для обслуговування одного програмного проекту.  При цьому ICASE орієнтована на конкретну методологію розробки, знову ж реализовану даним постачальником (винятками є спільні розробки кількох фірм, що є стратегічними партнерами на ринку CASE-засобів).  IPSE ж призначена для колективів, що працюють одночасно над різними проектами і навіть у різних методологіях розробки.  Причому конкретна IPSE не прив'язана до постачальника CASE-засобів.  Можливості роботи одночасно над різними проектами важливі не тільки самі по собі, але і як засіб запобігання дублюванню (навряд чи в рамках однієї організації буде занадто великий розкид розроблювального ПЗ).  Каркаси, подібні описаному, реальні завдяки високому рівню стандартизації як на національному рівні, так і в рамках європейського (стандарти ЕСМА) або міжнародного співтовариства (стандарти ISO - Міжнародної організації зі стандартів).

Рис. 4. Каркас для CASE

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

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

Як правило, забезпечується широка підтримка етапів життєвого циклу - етапів аналізу і загального проектування, рідше - етапів детального проектування і реалізації.  Таку позицію постачальники аргументують наявністю 4GL, коли необхідність кодування вручну нібито відсутня, що достатньо спірно.  Частіш за все більшість постачальників CASE комплектує їх 4GL або іншими варіантами генерації ПЗ, причому або власного виробництва, або інших фірм (можливі обидва варіанти).  Не часто даються можливості керування проектом, а якщо й так, то у самому обмеженому вигляді (ви можете, приміром, закріпити конкретних учасників проекту за певними видами робіт, але контроль їхньої діяльності не автоматизується).  Ще рідше користувач одержує засоби оцінки якості. Замість них - можливості збору статистики, що ви вільні інтепретувати тим або іншим способом. Останнім часом стали поставлятися засоби реінжинірінгу, але вони орієнтовані на продукти конкретної фірми.  Проте, намічається тенденція реалізації всіх перерахованих можливостей або конкретними постачальників CASE, або спільними зусиллями в рамках кооперації.

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

1. Впровадження CASE-систем

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

Підвищення продуктивності досягається двома шляхами.  Так, застосування мов четвертого покоління 4GL може збільшити цей показник у 10-20 разів.  Інший шлях - можливість повторного використання компонентів програмних проектів, як-от: моделей і архітектури (або їхніх частин), алгоритмів і вихідних текстів.  У силу того, що для розробки всіх програмних проектів застосовується одна методологія, спрощуються створення і пошук таких компонентів.  Засоби CASE-систем дозволяють зробити вирізку по необхідних компонентах. Оскільки існує повна навігація по проекту згори донизу, можна, відмітивши, яка частина старої моделі необхідна, «витягнути» усе, що з нею пов'язано, відповідні їй частини архітектури, алгоритми і вихідні тексти - і потім вставити все це в новий проект.

Передбачуваність розробки ПЗ по термінам і вартості забезпечується можливістю збору інформації про всі її аспекти: ресурси (людські, тимчасові, фінансові), критичні ситуації і засоби виходу з них, особливості проходження окремих етапів ЖЦ.  Оскільки будь-який колектив розробників, швидш за все, працює в деякій одній предметній області, з'являється можливість акумуляції спеціальних знань.  Саме це і дозволяє достатньо точно прогнозувати розробку конкретного ПЗ. Про якість уже йшла мова.  В даний час розроблені як засоби керування якістю, так і засоби її оцінки.  Додаткові можливості з підвищення якості такі самі, що і для підвищення продуктивності.  Так, якість підвищується за рахунок застосування 4GL у силу того, що ви оперуєте конструкціями більш узагальненими, і відповідно, не можете зробити помилок на детальному рівні мов попереднього покоління.  Якість підвищується також по таким характеристикам, як супровід і можливість розвитку ПЗ за рахунок більш простої маніпуляції цими мовами. Застосовуючи ж повторно використовувані компоненти, ви маєте справу вже з перевіреними на предмет якості фрагментами старих проектів.

Будучи продуктом виробничої діяльності, ПЗ тепер, як і будь-який інший продукт, має таку цінну якість, як максимальна відчуженість від виробника. Це питання може стати для вітчизняних користувачів ПЗ дуже актуальним і зараз практично ніяк не вирішується. Відомо, що ПЗ, побудоване традиційним способом, може змінити тільки той програміст, що його розробляв (та й то не завжди).  Запропонуєте будь-якому програмісту модифікувати чужу програму, і він вам резонно замітить, що йому простіше і швидше розробити її наново. У рамках CASE всі спеціалісти протягом ЖЦ ПЗ працюють з одними і тими ж інструментальними засобами відповідно до одної і тієї ж методології і по одних стандартах. Тому проблем маніпуляцій із ПЗ на етапі супроводу не виникає, оскільки є повна й узгоджена інформація про конкретне ПЗ, що не допускає різноманітних інтепретацій. Незалежність програмного продукту від розробника - виробника цього продукту важлива і по іншій причині. Приводяться у відповідність ролі людей і їхня значимість у даній організації.  Ролі визначаються штатним розкладом.  Значимість залежить, звичайно, від конкретного індивідуума, але залишається в рамках відведеної йому ролі.  Таке становище характеризує розумно побудовані організаційні структури.  А тепер подивимося, що відбувається в нас. Роль програміста, по ідеї, дуже невисока - найнижчий виконавчий рівень організаційної структури. А ось значимість може переростити навіть таку керівника організації, у якій він працює. Це відбудеться, якщо розроблене їм ПЗ є критичне стосовно функціонування даної організації.  Адже лише він є єдиновладним «хазяїном» цього ПЗ. Те, що наших керівників це поки-що не хвилює, пояснюється дуже просто - украй низьким ступенем автоматизації організацій.  Це не «дикий Захід», де розробляються і впроваджуються так називані стратегічні інформаційні системи.  Такі системи покликані слугувати головною стратегічною зброєю в конкурентній боротьбі й охоплюють діяльність всієї організації. Наші успіхи в цьому напрямку обмежуються, як правило, невеличкими, мало пов'язаними між собою острівцями автоматизації, безладно розкиданими по організації.  В силу цього залежність від ПЗ, відповідно і від програмістів, що його розробили, поки не суттєві.  Але це вже скоріше культурні, ніж технічні аспекти. І ще один аргумент на користь необхідності впровадження CASE.  По суті, ви впроваджуєте не просто нові технічні прийоми, а іншу, більш високу культуру розробки ПЗ. Апологети сучасних методологій розробки ПЗ люблять наводити наступний довід: «Якщо єдиним інструментом у руках людини є молоток, то весь світ, у всьому його різноманітті, природно, представляється їй місцем для забивання цвяха». Іншими словами, примітивні знаряддя праці неминучо формують примітивність мислення і відповідні уявлення про суть автоматизації. Наші розроблювачі традиційно мали в руках саме молоток-компілятор, а якщо повезе, те гарне зубило-відлагоджувач.  Таким чином, із упровадженням CASE-систем з'являється можливість змінити теперішню ситуацію в кращий бік.

1. Проблеми впровадження CASE-систем

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

Від упровадження таких систем часто чекають миттєвих результатів.  Грішать цим, як правило, керівники різноманітного рівня.  Не дочекавшись їх, починають ставитися до всіх нововведень із неабиякої долею скепсису.  Нерідко в опозицію стають і провідні програмісти.  Свідомо або ні, але вони розуміють, що їхній статус згодом різко зміниться.  У даний момент вони «надія й опора» в області автоматизації своїх організацій.  З переходом до CASE-систем їм, можливо, доведеться задовольнятися скромною роллю «гвинтиків» у великому і складному механізмі.  Адже в даний момент це найбільш авторитетні і впливові групи - і вони стають в опозицію стосовно CASE-систем.  Як результат - сильно гальмується процес їх упровадження.  Навіть будучи купленими (і такі випадки є), ці системи складаються в ящик і прибираються подалі.  Біда тут у тому, що дискредитується сама ідея, повернутися до неї пізніше буде набагато складніше. Припустимо, проте, що CASE-система обрана, придбана і встановлена.  Усе перейнялося важливістю історичного моменту, відведено достатньо часу на освоєння, створені необхідні умови.  Але хто на ній буде працювати?  Типовий підрозділ з розробки ПЗ складається з програмістів і одного-двох адміністраторів.  Але вже говорилося, що доведеться освоювати нові професії.  А професія - це не тільки сума знань і досвід практичної роботи, але і схильність до того або іншого виду діяльнсті.  Як таку схильність визначити, та ще й не схибити?  Тут доречно приділити трохи уваги проблемам освоєння методологій окремих етапів ЖЦ ПЗ.

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

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

1. Системний аналіз об’єкту дослідження та предметної області

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

Проблеми розрізняються за ступенем їх структурованості:

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

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

Людську діяльність умовно можна поділити на дві області:

• рутинна діяльність, розв’язання регулярних, щоденних завдань;
• розв’язання нових задач, які виникають вперше.

1. Мова описів UML

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

Перша версія (1.0) UML вийшла 13 січня 1997, вона була створена за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних. Після обговорення, у вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG. Розробку UML підтримали і вже тоді використовували як стандарт такі гранди ринку інформаційних технологій, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Sybase, Logic Works й інші.

Поточна версія — 2.0.

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

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

Основною причиною використання мови UML є спілкування розробників між собою.[1]

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

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

Практично усі CASE-засоби (програми автоматизації процесу аналізу і проектування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.

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

UML необхідний:

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

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

Рис. 5. Колаж з різних діаграм UML

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

Протягом 1994-96 років творці трьох найпоширеніших методологій — Граді Буч (BOOCH), Джим Рамбо (OMT — Object Modeling Technique) і Айвар Якобсон (OOSE — Object Oriented Software Engineering) об'єднали свої зусилля під егідою Rational Software Corporation для створення єдиної мови моделювання, яка б об'єднала всі істотні й успішні розробки в даній галузі і стала би стандартом мови об'єктного моделювання. Грандіозна робота, у якій поряд з Rational брали участь представники багатьох компаній, таких, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology і кількох сотень інших завершилася створенням у січні 1997 року UML 1.0, яка після бурхливого обговорення протягом 1997 року у вересні під версією 1.1 і була передана в OMG для прийняття як галузевий стандарт мови об'єктного моделювання.

В UML використовується 13 видів діаграм (для уникнення непорозумінь, також наведено англомовні назви):

Попри те, що UML є широко визнаним стандартом мови моделювання, вона часто підпадає під критику через такі причини:

• Надмірність мови
• Неточна семантика
• Проблеми у вивченні та застосуванні
• Візуальна неоднорідність
• Намагається подобатись усім

Нам необхідно провести аналіз та реалізувати розв’язання проблеми видачі путівок для студентів на оздоровлення. Для опису системного аналізу ми використаємо мову UML.

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

Почавши уніфікацію, автори поставили перед собою три головні цілі:

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

Словник мови UML включає три види будівельних блоків:

В UML є чотири типи сутностей:

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

1. Системний опис спроектованої системи

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

Рис. 6. Основні користувачі даної системи та основні події

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

Рис. 7.  Зв'язки між об'єктами

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

Рис. 8. Організація сукупності компонентів і існуючі між ними залежності.

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

Рис. 9.  Діаграмами класів

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

На діаграмі розгортання представлена конфігурація вузлів системи й розміщених у них компонентів:

Отже проведений системний аналіз об’єкту дослідження та проблемної області, відповідає основним принципам:

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

Рис. 11. Діаграма розгортання

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

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

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

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

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

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

1. Варіант використання

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

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

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

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

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

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

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

Примітка

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

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

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

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

1. Актори

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

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

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

Примітка

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

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

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

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

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

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

1. Інтерфейси

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

На діаграмі варіантів використання інтерфейс зображається у вигляді маленького круга, поряд з яким записується його ім'я (рис. 4.3, а). Іменем може бути іменник, який характеризує відповідну інформацію або сервіс (наприклад, "сенсор", "сирена", "відеокамера"), але частіше рядок тексту (наприклад, "запит до бази даних", "форма введення", "пристрій подання звукового сигналу"). Якщо ім'я записується англійською мовою, то воно має починатися з великої літери I, наприклад, ISecurelnformation, ISensor (рис. 18.3, б).

Рис. 18.3. Графічне зображення інтерфейсів на діаграмах варіантів використання.

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

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

Рис. 18.4. Графічне зображення взаємозв'язків інтерфейсів з варіантами використання.

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

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

1. Примітки

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

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

Рис. 18.5. Приклади приміток у мові UML.

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

1. Відношення на діаграмі варіантів використання

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

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

¨    відношення асоціації (association relationship);

¨    відношення розширення (extend relationship);

¨    відношення узагальнення (generalization relationship);

¨    відношення включення (include relationship).

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

1.14.1. Відношення асоціації

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

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

Кратність (multiplicity) асоціації вказується поряд із позначенням компонента діаграми, який є учасником такої асоціації. Кратність характеризує загальна кількість конкретних екземплярів певного компонента, які можуть виступати як елементи цієї асоціації. Стосовно діаграм варіантів використання кратність має спеціальне позначення у формі однієї або декількох цифр і, можливо, спеціального символа "*" (зірочка).

Примітка

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

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

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

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

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

{перше_число, перше_число+1, перше_число+2 ..., друге_число]. Очевидно, що перше число має бути строго менше від другого числа в арифметичному сенсі, при цьому перше число може дорівнювати 0.

Приклад такої форми запису кратності асоціації – "1..5". Цей запис означає, що кількість окремих екземплярів певного компонента, які можуть виступати як елементи певної асоціації, дорівнює деякому заздалегідь невідомому числу із множини цілих чисел {1, 2, 3, 4, 5}. Ця ситуація може мати місце, наприклад, коли актор – клієнт банку, а варіант використання – процедура відкриття рахунку в банку. При цьому кількість окремих рахунків кожного клієнта в цьому банку, виходячи з деяких додаткових міркувань, може бути не більше як 5. Ці додаткові міркування якраз і є зовнішніми вимогами по відношенню до проектованої системи і визначаються її замовником на початкових етапах ООАП.

3. Два символи, розділені двома крапками. При цьому перший з них є цілим невід’ємним числом або 0, а другий – спеціальний символ "*". Цей символ "*" означає довільне кінцеве ціле невід’ємне число, значення якого невідоме на момент задання відповідного відношення асоціації.

Приклад такої форми запису кратності асоціації – "2..*". Запис означає, що кількість окремих екземплярів такого компонента, які можуть виступати як елементи певної асоціації, дорівнює деякому заздалегідь невідомому числу з підмножини натуральних чисел: {2, 3, 4}.

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

Як приклад цього запису можна навести кратність відношення асоціації для варіанту використання "Оформити кредит для клієнта банку" (рис. 13.6). Тут кратність "*" означає, що кожний окремий клієнт банку може оформити для себе декілька кредитів, при цьому їх загальна кількість заздалегідь невідома й нічим не обмежується. При цьому деякі клієнти можуть зовсім не мати оформлених на своє ім'я кредитів (варіант значення 0).

Якщо кратність відношення асоціації не вказана, то за замовчуванням вона дорівнює 1.

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

1.14.2. Відношення розширення

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

Відношення розширення між варіантами використання позначається пунктирною лінією зі стрілкою (варіант відношення залежності), напрямленою від того варіанту використання, який є розширенням для початкового варіанту використання. Така лінія зі стрілкою позначається ключовим словом "extend" ("розширює"), як показано на рис. 18.7.

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

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

Один з варіантів використання може бути розширенням для декількох базових варіантів, а також мати як власні розширення кілька інших варіантів. Базовий варіант використання може додатково ніяк не залежати від своїх розширень.

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

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

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

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

1.14.3. Відношення узагальнення

Відношення узагальнення служить для вказання на той факт, що деякий варіант використання А може бути узагальнений до варіанту використання В. У цьому випадку варіант А буде спеціалізацією варіанту В. При цьому В називається предком або батьком по відношенню до А, а варіант А – нащадком по відношенню до варіанту використання В. Отже, нащадок успадковує всі властивості і поведінку свого батька, а також може бути доповнений новими властивостями й особливостями поведінки. Графічно таке відношення позначається суцільною лінією зі стрілкою, яка вказує на батьківський варіант використання (рис. 18.9). Ця лінія зі стрілкою має спеціальну назву – стрілка "узагальнення".

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

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

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

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

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

1.14.4. Відношення включення

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

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

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

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

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

1.14.5. Приклад побудови діаграми варіантів використання

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

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

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

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

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

Отримана в результаті подальшої деталізації уточнена діаграма варіантів використання міститиме 5 варіантів використання ів 2 актори (рис. 18.13), між якими встановлені відношення включення і розширення.

Рис. 18.13. Уточнена діаграма варіантів використання для прикладу системи продажу товарів за каталогом.

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

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

Рис. 18.14. Один з варіантів подальшого уточнення діаграми варіантів використання для прикладу системи продажу.

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

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

Рис. 18.15. Фраґмент діаграми варіантів використання, який у неявному вигляді присутній на уточненій діаграмі з відношенням асоціації між окремими компонентами.

Примітка

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

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

Побудова діаграми варіантів використання є найпершим етапом процесу об'єктно-орієнтованого аналізу і проектування, мета якого – відображати сукупність вимог до поведінки проектованої системи. Специфікація вимог до проектованої системи у формі діаграми варіантів використання є самостійною моделлю, яка в мові UML отримала назву моделі варіантів використання і має своє спеціальне стандартне ім'я або стереотип "useCaseModel".

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

1.14.6. Рекомендації з розроблення діаграм варіантів використання

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

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

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

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

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

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

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

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

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

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

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

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

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

(Для ознайомлення з повним текстом статті необхідно залогінитись)