6. Модель екстремального програмування (xp)

На початку XXI століття потреби в ПЗ досягли екстремальних значень.

Традиційно для створення проектів, компанії користуються моделями повного попереднього проектування («великовагові» процеси).

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

Найпоширенішим «полегшеним» процесом є ХР-процес. (автор Кент Бэк, 1999). Процес орієнтований на групи малого або середнього розміру, що створюють програму в умовах часто змінюваних вимог. У середньому це може бути до 10 людей, що перебувають в одному приміщенні. Основною метою такого процесу є – зниження вартості програми при частій зміні умов.

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

ХР-процес – базується на наступних основних принципах:

• постійний зв'язок із замовником;

• безперервне тестування й безперервна інтеграція (кожний розроблювач може впровадити в загальну системи свою частину налагодженого коду);

• простота (завжди вибирається оптимальний алгоритм, код якого зрозумілий іншим учасникам команди);

• принцип YAGNI (You Aren't Going to Need It – це тобі не знадобитися). Розроблювач займається написанням коду для поточної функції й не витрачає час і сили на написання коду для функції, яка буде розроблятися пізніше;

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

Для забезпечення ХР-процесу використовують наступні підходи:

• часта зміна версій (раз в 2 тижні);

• парне кодування – один код може писатися різними учасниками групи почергово;

• колективне володіння кодом – будь-який учасник групи може вносити зміни в програму;

• 40-годинний робочий тиждень;

• використання стандартів кодування (усі розроблювачі повинні дотримуватися стандартів у  програмуванні для забезпечення розуміння кодів усіма учасниками);

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

 

7. Модель msf (Microsoft Solutions Framework)

 

Дана модель використовується в компанії Microsoft. Основні характеристики моделі:

• кожний етап завершується віхою – подією, що супроводжується появою й фіксацією деякого матеріалу (документа, програми, протоколу);

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

• проектні (внутрішні, функціональні) специфікації містять у собі проектні документи, моделі, прототипи, програму, методику випробувань і сітковий графік робіт;

• стабілізація – тестування програми;

• випуск супроводжується підготовкою документації користувачів, готової для тиражування;

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

 

Питання для самоконтролю

1. Дайте характеристику водоспадної моделі розробки програм.

2. Приведіть переваги водоспадної моделі.

3. Приведіть недоліки водоспадної моделі.

4. Опишіть принцип макетування.

5. Опишіть спіральну модель розробки програм.

6. У чому переваги й недоліки спіральної моделі?

7. Що таке модель RAD? Дайте характеристику цієї моделі.

8. Що таке XP-процеси розробки програм? Дайте їхню характеристику.

9. Опишіть модель MSF.

Лекція №5

Тема: Універсальна мова моделювання програмних продуктів UML. Види діаграм та їх призначення. Аспекти, що визначаються на діаграмах.

Мета: Ознайомлення з базовими поняттями мови моделювання програмних продуктів. Визначення призначення базових діаграм.

Перелік питань, що розглядаються на лекції:

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

2. Призначення мови UML

3. Загальна структура мови UML

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

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

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

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

• Метод Джеймса Румбаха (James Rumbaugh), що одержав назву Object Modeling Technique - ОМТ (пізніше - ОМТ-2).

• Метод Айвара Джекобсона (Ivar Jacobson), що одержав назву Object-Oriented Software Engineering - OOSE.

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

Історія розвитку мови UML бере початок з жовтня 1994 року, коли Гради Буч і Джеймс Румбах з Rational Software Corporation почали роботу з уніфікації методів Booch і ОМТ. Хоча самі по собі ці методи були досить популярні, спільна робота була спрямована на вивчення всіх відомих об’єктно-ориентированих методів з метою об'єднання їхніх достоїнств. При цьому Г. Буч і Дж. Румбах зосередили зусилля на повній уніфікації результатів своєї роботи. Проект так званого уніфікованого методу (Unified Method) версії 0.8 був підготовлений і опублікований у жовтні 1995 року. Восени того ж року до них приєднався А. Джекоб-Сон, головний технолог з компанії Objectory AB (Швеція), з метою інтеграції свого методу OOSE із двома попередніми.

Спочатку автори методів Booch, ОМТ і OOSE припускали розробити уніфіковану мову моделювання тільки для цих трьох методик. З одного боку, кожний із цих методів був перевірений на практиці й показав свою конструктивність при рішенні окремих завдань ООАП. Це давало підставу для подальшої їхньої модифікації на основі усунення наявної невідповідності окремих понять і позначень. З іншого боку, уніфікація семантики й нотації повинна була забезпечити деяку стабільність на ринку об’єктно-орієнтованих CASE-Засобів, що необхідна для успішного просування відповідних програмних інструментів. Нарешті, спільна робота давала надію на істотне поліпшення всіх трьох методів.

Починаючи роботу з уніфікації своїх методів, Г. Буч, Дж. Румбах і А. Дже-Кобсон сформулювали наступні вимоги до мови моделювання. Він повинен:

• Дозволяти моделювати не тільки програмне забезпечення, але й більше широкі класи систем і бізнес-додатків, з використанням об’єктно-орієнтованих. понять.

• Явно забезпечувати взаємозв'язок між базовими поняттями для моделей концептуального й фізичного рівнів.

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

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

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

1. Чи належна дана нотація містити в собі специфікацію вимог?

2. Чи варто розширювати дану нотацію до рівня мови візуального програмування?

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

У цей період підтримка розробки мови UML стає однієї із цілей консорціуму OMG (Object Management Group). Хоча консорціум OMG був утворений ще в 1989 році з метою розробки пропозицій по стандартизації об'єктних і компонентних технологій CORBA, мова UML придбав статус другого стратегічного напрямку в роботі OMG. Саме в рамках OMG створюється команда розроблювачів під керівництвом Ричарда Солі, що буде забезпечувати подальшу роботу з уніфікації й стандартизації мови UML. У червні 1995 року OMG організувала нараду всіх великих фахівців і представників вхідним у консорціум компаній по методологіях ООП, на якому вперше в міжнародному масштабі була визнана доцільність пошуку індустріальних стандартів в області мов моделювання під егідою OMG.

Зусилля Г. Буча, Дж. Румбаха й А. Джекобсона привели до появи перших документів, що містять опис властиво мови UML версії 0.9 (червень 1996 р.) і версії 0.91 (жовтень 1996 р.). Що мають статус запиту пропозицій RTP (Request For Proposals), ці документи послужили своєрідним каталізатором для широкого обговорення мови UML різними категоріями фахівців. Перші відкликання й реакція на мову UML указували на необхідність його доповнення окремими поняттями й конструкціями.

У цей же час стало ясно, що деякі компанії й організації бачать у мові UML лінію стратегічних інтересів для свого бізнесу. Компанія Rational Software разом з декількома організаціями, що виявили бажання виділити ресурси для розробки строгого визначення версії 1.0 мови UML, заснувала консорціум партнерів UML, у який спочатку ввійшли такі компанії, як Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI і Unisys. Ці компанії забезпечили підтримку наступної роботи з більше точного й строгого визначення нотації, що привело до появи версії 1.0 мови UML. У січні 1997 року був опублікований документ із описом мови UML 1.0, як початковий варіант відповіді на запит пропозицій RTP. Ця версія мови моделювання була досить добре визначена, забезпечувала необхідну виразність і потужність і припускала рішення широкого класу завдань.

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

З більш ніж 800 компаній і організацій, що входять у цей час до складу консорціуму OMG, особливу роль продовжує грати Rational Software Corporation, що стояла в джерел розробки мови UML. Ця компанія розробила й випустила в продаж одне з перших інструментальних CASE-Засобів Rational Rose 98, у якому був реалізований мова UML.

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

У цей час всі питання подальшої розробки мови UML сконцентровані в рамках консорціуму OMG. Відповідна група фахівців забезпечує публікацію матеріалів, що містять опис наступних версій мови UML і запитів пропозицій RFP по його стандартизації. Черговий етап розвитку даної мови закінчився в березні 1999 року, коли консорціумом OMG був опублікований опис мови UML 1.3 (alpha R5). Останньою версією мови UML на момент написання книги є UML 1.3, що описана у відповідному документі - "OMG Unified Modeling Language Specification", опублікованому в червні 1999 року.

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

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

У цьому зв'язку слід зазначити увага гіганта комп'ютерної індустрії компанії Microsoft до технології UML. Ще в жовтні 1996 р. Microsoft і Rational Software Coiporation оголосили про своє стратегічне партнерство, що, по їхній загальній думці, здатно вплинути на ринок засобів об’єктно-орієнтованоїрозробки програм. При цьому Microsoft ліцензувала в Rational Software деякі технології візуального моделювання, у результаті чого був розроблений Microsoft Visual Modeler for Visual Basic. У свою чергу Rational Software ліцензувала в Microsoft Visual Basic і Microsoft Repositoiy, розроблювальні разом з Texas Instruments. При створенні мови UML Microsoft внесла свій внесок в інтеграцію UML зі своїми стандартами типу Active і СОМ і у використання мови UML зі своєю технологією Microsoft Repository.

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

Уже в цей час розроблені засоби візуального програмування на основі UML, що забезпечують інтеграцію, включаючи пряму й зворотну генерацію коду програм, з найпоширенішими мовами й середовищами програмування, такими як MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Оскільки при розробці мови UML були прийняті в увагу багато передових ідей і методи, очікується, що на чергові версії мови UML також вплинуть і інші перспективні технології й концепції. Крім того, на основі мови UML можуть бути визначені багато нових перспективних методів. Мова UML може бути розширений без перевизначення його ядра.

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

Призначення мови UML

Мова UML призначена для рішення наступних завдань:

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

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

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

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

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

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

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

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

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

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

З іншого боку, мова UML повинен мати потенційну можливість реалізації своїх конструкцій на тій або іншій мові програмування. Звичайно, у першу чергу маються на увазі мови, що підтримують концепцію ООП, такі як C++, Java, Object Pascal. Саме ця властивість мови UML робить його сучасним засобом рішення завдань моделювання складних систем. У той же час, передбачається, що для програмної підтримки конструкцій мови UML можуть бути розроблені спеціальні інструментальні CASE-Засоби. Наявність останніх має принципове значення для широкого поширення й використання мови UML.

4. Опис мови UML повинне містити в собі семантичний базис для розуміння загальних особливостей ООАП.

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

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

5. Заохочувати розвиток ринку об'єктних інструментальних засобів.

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

6. Сприяти поширенню об'єктних технологій і відповідних понять ООАП.

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

7. Інтегрувати в себе новітні й найкращі досягнення практики ООАП.

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

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

Загальна структура мови UML

Із самої загальної точки зору опис мови UML складається із двох взаємодіючих частин, таких як:

• Семантика мови UML. Являє собою деяку метамодель, що визначає абстрактний синтаксис і семантику понять об'єктного моделювання мовою UML.

• Нотація мови UML. Являє собою графічну нотацію для візуального подання семантики мови UML.

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

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

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

Формальний опис самої мови UML ґрунтується на деякій загальній ієрархічній структурі модельних подань, що складає із чотирьох рівнів: 

• Позначка-Метамодель 

• Метамодель 

• Модель 

• Об'єкти користувача

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

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

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

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

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

Конкретизація понять моделі відбувається на рівні об'єктів. У справжньому контексті об'єкт є екземпляром моделі, оскільки містить конкретну інформацію щодо того, чому в дійсності відповідають ті або інші поняття моделі. Прикладом об'єкта може служити наступний запис у проектованій базі даних: "Ілля Петров, 30 років, ілюзіоніст, вул. Невидима, 10-20, 100-0000".

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

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

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

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

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

Примітка

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

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

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

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

• Діаграма варіантів використання (use case diagram)

• Діаграма класів (class diagram)

• Діаграми поводження (behavior diagrams)

  • Діаграма станів (statechart diagram)

  • Діаграма діяльності (activity diagram)

  • Діаграми взаємодії (interaction diagrams) 

    • Діаграма послідовності (sequence diagram) 

    • Діаграма кооперації (collaboration diagram) 

• Діаграми реалізації (implementation diagrams)

  • Діаграма компонентів (component diagram)

  • Діаграма розгортання (deployment diagram)

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

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

2. Діаграма станів.

3. Діаграма класі .

4. Діаграма діяльності.

5. Діаграма послідовності.

6. Діаграма кооперації.

7. Діаграма компонентів.

8. Діаграма розгортання.

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

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

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

Лекція №6

Тема: Діаграма прецедентів (варіантів використання). Визначення вимог до програмного продукту. Постановка задачі.

Мета: Навчитися створювати діаграми використання та вимог до програмного продукту.

Перелік питань, що розглядаються на лекції:

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

2. Актори

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

4. Документ – постановка задачі.

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

Розробка діаграми варіантів використання переслідує мети:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Актори

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекція №7

Тема: Статичні діаграми. Об’єктно – орієнтовне конструювання програмного забезпечення, діаграми класів та об’єктів.

Мета: Навчитися створювати діаграми класів, виконувати об’єктно-орієнтовне проектування програмних продуктів.

Перелік питань, що розглядаються на лекції:

1. Призначення діаграми класів

2. Структурна сутність клас

3. Семантика сутності

4. Атрибути та синтаксис їх запису

5. Методи та синтаксис їх запису

Призначення діаграми класів

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

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

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

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

Структурна сутність клас

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

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

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

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

  Ім'я класу

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

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

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

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

У деяких випадках необхідно явно вказати, до якого пакета ставиться той або інший клас. Для цієї мети використовується спеціальний символ роздільник - подвійна двокрапка "::". Синтаксис рядка ім'я класу в цьому випадку буде наступний <Ім'я_пакета>::<Ім'я_класу>. Інакше кажучи, перед ім'ям класу повинне бути явно зазначене ім'я пакета, до якого його варто віднести. Наприклад, якщо визначено пакет з ім'ям "Банк", те клас "Рахунок" у цьому банку може бути записаний у вигляді: "Банк::Рахунок".

  Атрибути класу та їх синтаксис

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

<квантор видимості><ім'я атрибута>[кратність]:

<тип атрибута> = <вихідне значення>{ рядок-властивість}

Квантор видимості може приймати одне із трьох можливих значень і, відповідно, відображається за допомогою спеціальних символів:

• Символ "+" позначає атрибут з областю видимості типу загальнодоступний (public). Атрибут із цією областю видимості доступний або видний з будь-якого іншого класу пакета, у якому визначена діаграма.

• Символ "#" позначає атрибут з областю видимості типу захищений (protected). Атрибут із цією областю видимості недоступний або невидний для всіх класів, за винятком підкласів даного класу.

• І, нарешті, знак "-" позначає атрибут з областю видимості типу закритий (private). Атрибут із цією областю видимості недоступний або невидний для всіх класів без винятку.

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

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

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

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

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

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

Як приклад розглянемо наступні варіанти завдання кратності атрибутів.

• [0..1] означає, що кратність атрибута може приймати значення Про або 1. При цьому 0 означає відсутність значення для даного атрибута.

• [0..*] означає, що кратність атрибута може приймати будь-яке позитивне ціле значення більше або рівне 0. Ця кратність може бути записана коротше у вигляді простого символу - [*].

• [1.:*] означає, що кратність атрибута може приймати будь-яке позитивне ціле значення більше або рівне 1.

• [1..5] означає, що кратність атрибута може приймати будь-яке значення із чисел: 1, 2, 3, 4, 5.

• [1..3,5,7] означає, що кратність атрибута може приймати будь-яке значення із чисел: 1, 2, 3, 5, 7.

• [1..3,7.. 10] означає, що кратність атрибута може приймати будь-яке значення із чисел: 1, 2, 3, 7, 8, 9, 10.

• [1..3,7..*] означає, що кратність атрибута може приймати будь-яке значення із чисел: 1, 2, 3, а також будь-яке позитивне ціле значення більше або рівне 7.

Якщо кратність атрибута не зазначена, то за замовчуванням приймається її значення рівне 1..1, тобто в точності 1.

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

Можна привести наступні приклади завдання імен і типів атрибутів класів:

• колір: Соlоr - тут колір є ім'ям атрибута, Color - ім'ям типу даного атрибута. Зазначений запис може визначати традиційно використовувану RGB-Модель (червоний, зелений, синій) для подання кольору. У цьому випадку ім'я типу Color саме й характеризує семантичну конструкцію, що застосовується в більшості мов програмування для подання кольору.

• ім'я_співробітника [1..2] : String - тут ім'я_співробітника є ім'ям атрибута, що служить для подання інформації про ім'я, а можливо, і по батькові конкретного співробітника. Тип атрибута String (Рядок) саме й указує на той факт, що окреме значення ім'я являє собою рядок тексту з одного або двох слів (наприклад, "Кирило" або "Дмитро Іванович"). Оскільки в багатьох мовах програмування існує тип даних String, використання відповідного англомовного терміна не викликає непорозуміння в більшості програмістів. Однак, хоча в мові UML всі терміни даються в англомовному поданні, використання як тип атрибута Рядок у даній ситуації не виключається й визначається тільки міркуваннями зручності.

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

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

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

Як приклади вихідних значень атрибутів можна привести наступні доповнені вище варіанти завдання атрибутів:

• колір:Соlоr = (255, 0, 0) - в RGB-Моделі кольору це відповідає чистому червоному кольору як вихідне значення для даного атрибута.

• ім'я_співробітника[1..2]:String = Іван Іванович - можливо, це нетиповий випадок, що, скоріше, відповідає ситуації ім'я_керівника[2]:81пп§ = Іван Іванович.

• видимість:Вооlеаn = істина - може відповідати ситуації, коли в момент створення екземпляра класу створюється видиме на екрані монітора вікно, що відповідає даному об'єкту.

• форма:Багатокутник = прямокутник - навряд чи вимагає коментарів, оскільки тут мова йде про геометричну форму створюваного об'єкта.

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

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

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

Рядок-Властивість служить для вказівки значень атрибута, які не можуть бути змінені в програмі при роботі з даним типом об'єктів. Фігурні дужки саме й позначають фіксоване значення відповідного атрибута для класу в цілому, що повинні приймати всі знову створювані екземпляри класу без винятку. Це значення приймається за вихідне значення атрибута, що не може бути перевизначене надалі. Відсутність рядка-властивості за замовчуванням трактується так, що значення відповідного атрибута може бути змінене в програмі. Наприклад, рядок-властивість у записі атрибута заробітна_плата:Currency = = {$500} може служити для позначення фіксованої заробітної плати для кожного об'єкта класу "Співробітник" певної посади в деякій організації. З іншого боку, запис даного атрибута у вигляді зара-ботная_плата: Currency = $500 означає вже щось інше, а саме - при створенні нового екземпляра Співробітник (аналогія - прийом на роботу нового співробітника) для нього встановлюється за замовчуванням заробітна плата в $500. Однак для окремих співробітників можуть бути зроблені виключення як у більшу, так і в меншу сторону, про що необхідно подбати додатково в програмі.

  Операція та їх синтаксис

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

<квантор видимості><ім'я операції>(список параметрів):

<вираження типу значення, що повертається,>{ рядок-властивість}

Квантор видимості, як і у випадку атрибутів класу, може приймати одне із трьох можливих значень і, відповідно, відображається за допомогою спеціального символу. Символ "+" позначає операцію з областю видимості типу загальнодоступний (public). Символ "#" позначає операцію з областю видимості типу захищений (protected). І, нарешті, символ "-" використовується для позначення операції з областю видимості типу закритий (private).

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

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

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

Список параметрів є переліком розділених коми формальних параметрів, кожний з яких може бути представлений у наступному виді:

<вид параметра><ім'я параметра>:<вираження типу>=<значення параметра за замовчуванням>.

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

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

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

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

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

Для підвищення продуктивності системи одні операції можуть виконуватися паралельно або одночасно, а інші - тільки послідовно. У цьому випадку для вказівки паралельності виконання операції використовується рядок-властивість виду "{concurrency = ім'я}", де ім'я може приймати одне з наступних значень: послідовна (sequential), паралельна (concurrent), охоронювана (guarded). При цьому дотримуються наступної семантики для даних значень:

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

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

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

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

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

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

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

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

Як приклади запису операцій можна привести наступні позначення окремих операцій:

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

• +намалювати(форма: Багатокутник = прямокутник, колір_заливання: Color = (ПРО, ПРО, 255)) - може позначати операцію по зображенню на екрані монітора прямокутної області синього кольору, якщо не вказуються інші значення як аргументи даної операції.

• запросити_рахунок_клієнта(номер_рахунку:1п1е§ег):Сиггепсу - позначає операцію по встановленню наявності засобів на поточному рахунку клієнта банку. При цьому аргументом даної операції є номер рахунку клієнта, що записується у вигляді цілого числа (наприклад, "123456"). Результатом виконання цієї операції є деяке число, записане в прийнятому грошовому форматі (наприклад, $1,500.00).

• видати_повідомлення():{"Помилка розподілу на нуль"} - зміст даної операції не вимагає пояснення, оскільки втримується в рядку-властивості операції. Дане повідомлення може з'явитися на екрані монітора у випадку спроби розподілу деякого числа на нуль, що неприпустимо.

Лекція №8

Тема: Статичні діаграми. Відношення між класами. Діаграми класів.

Мета: Навчитися створювати діаграми класів, виконувати об’єктно-орієнтовне проектування програмних продуктів.

Перелік питань, що розглядаються на лекції:

1. Відношення між класами

2. Відношення залежності

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

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

5. Відношення реалізації

Відносини між класами

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

• Відношення залежності (dependency relationship)

• Відношення асоціації (association relationship)

• Відношення узагальнення (generalization relationship)

• Відношення реалізації (realization relationship)

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

  Відношення залежності

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

Відношення залежності графічно зображується пунктирною лінією між відповідними елементами зі стрілкою на одному з її кінців ("->" або "<-"). На діаграмі класів дане відношення зв'язує окремі класи між собою, при цьому стрілка спрямована від класу-клієнта залежності до незалежного класу або класу-джерелу (рис. 5.3). На даному малюнку зображені два класи: Клас_А и Кяасс_Б, при цьому Клас_Б є джерелом деякої залежності, а Клас_А - клієнтом цієї залежності.

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

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

• "access" - служить для позначення доступності відкритих атрибутів і операцій класу-джерела для класів-клієнтів;

• "bind" - клас-клієнт може використовувати деякий шаблон для своєї наступної параметризації;

• "derive" - атрибути класу-клієнта можуть бути обчислені по атрибутах класу-джерела;

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

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

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

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

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

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

Як простий приклад відносини бінарної асоціації розглянемо відношення між двома класами - класом "Компанія" і класом "Співробітник". Вони зв'язані між собою бінарною асоціацією Робота, ім'я якої зазначене на малюнку поруч із лінією асоціації. Для даного відношення визначений порядок проходження класів, першим з яких є клас "Співробітник", а другим - клас "Компанія". Окремим прикладом або екземпляром даного відношення може бути пари значень (Петров И. И., "Рогу&Копита"). Це означає, що співробітник Петров И. И. працює в компанії "Рогу&Копита".

Тернарная асоціація й асоціації більше високої арности в загальному випадку називаються N-Арной асоціацією (читається - "эн арная асоціація"). Така асоціація зв'язує деяким відношенням 3 і більше класів, при цьому один клас може брати участь в асоціації більш ніж один раз. Клас асоціації має певну роль у відповідному відношенні, що може бути явно зазначене на діаграмі. Кожний екземпляр N-Арной асоціації являє собою N-Арный кортеж значень об'єктів з відповідних класів. Бінарна асоціація є часткою случаємо N-Арной асоціації, коли значення N=2, і має своє власне позначення.

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

Порядок класів в N-Арной асоціації, на відміну від порядку безлічей у відношенні, на діаграмі не фіксується. Деякий клас може бути приєднаний до ромба пунктирною лінією. Це означає, що даний клас забезпечує підтримку властивостей відповідної N-Арной асоціації, а сама N-Арная асоціація має атрибути, операції й/або асоціації. Інакше кажучи, така асоціація, у свою чергу, є класом з відповідним позначенням у вигляді прямокутника і є самостійним елементом мови UML - асоціацією-класом (Association Class). N-Арная асоціація не може містити символ агрегації ні для якої зі своїх ролей.

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

Як уже згадувалося, окремий клас асоціації має власну роль у відношенні. Ця роль може бути зображена графічно на діаграмі класів. Із цією метою в мові UML уводиться в розгляд спеціальний елемент - кінець асоціації (Association End), що графічно відповідає крапці з'єднання лінії асоціації з окремим класом. Кінець асоціації є частиною асоціації, але не класу. Кожна асоціація має два або більше кінці асоціації. Найбільш важливі властивості асоціації вказуються на діаграмі поруч із цими елементами асоціації й повинні перемішатися разом з ними.

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

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

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

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

Часткою случаємо відносини асоціації є так звана асоціація, що виключає ( Xor-association). Семантика даної асоціації вказує на той факт, що з декількох потенційно можливих варіантів даної асоціації в кожний момент часу може використовуватися тільки один її екземпляр. На діаграмі класів асоціація, що виключає, зображується пунктирною лінією, що з'єднує дві й більше асоціації, поруч із якої записується рядок-обмеження "{хог}".

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

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

  Відношення агрегації

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

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

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

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

Як приклад відносини агрегації розглянемо взаємозв'язок типу " частина-ціле", що має місце між сутністю "Вантажний автомобіль" і такими компонентами, як "Двигун", "Шасі", "Кабіна", "Кузов". Не претендуючи на точну відповідність термінології даної предметної області, неважко уявити собі, що вантажний автомобіль складається із двигуна, шасі, кабіни й кузови. Саме це відношення між класом "Вантажний_автомобіль" і класами "Двигун", "Шасі", "Кабіна", "Кузов" описує відношення агрегації.

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

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

  Відношення композиції

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

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

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

Як додаткові позначення для відносин композиції й агрегації можуть використовуватися додаткові позначення, застосовувані для відношення асоціації. А саме, вказівка кратності класу асоціації й ім'я даної асоціації, які не є обов'язковими. Стосовно до описаного вище прикладу класу "Вікно_програми" його діаграма класів може мати такий вигляд (мал. 5.11).

Даний приклад може ілюструвати й інші особливості розроблювальної комп'ютерної програми, які не вказувалися в явному виді при описі цього приклада Так, зокрема, вказівку кратності 1 поруч із класом "Робоча_область" характерно для однодокументних додатків.

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

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

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

Як правило, на діаграмі може вказуватися кілька ліній для одного відношення узагальнення. У цьому випадку більше загальний клас розбивається на підкласи одним відношенням Узагальнення. Наприклад, клас Геометрична_фігура_на_площині (курсив позначає абстрактний клас) може виступати як суперклас для підкласів, що відповідають конкретним геометричним фігурам, таким як, Прямокутник, Окружність, Еліпс і ін. Даний факт може бути представлений графічно у формі діаграми класів наступного виду (мал. 5.13).

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

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

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

Як обмеження можуть бути використані наступні ключові слова мови UML:

• {complete} - означає, що в даному відношенні узагальнення специфіковані всі класи-нащадки, і інших класів-нащадків у даного класу-предка бути не може. Приклад - клас Клієнт_банку є предком для двох класів: Фізичне_особа й Компанія, і інших класів-нащадків він не має. На відповідній діаграмі класів це можна вказати явно, записавши поруч із лінією узагальнення даний рядок-обмеження;

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

• {incomplete} - означає випадок, протилежний першому. А саме, передбачається, що на діаграмі зазначені не всі класи-нащадки. Надалі можливо заповнити їхній перелік не змінюючи вже побудовану діаграму. Приклад - діаграма класу "Автомобіль", для якої вказівка всіх без винятку моделей автомобілів порівнянно зі створенням відповідного каталогу. З іншого боку, для окремого завдання, такий як розробка системи продажу автомобілів конкретних моделей, у цьому немає необхідності. Але вказати неповноту структури класів-нащадків все-таки треба;

• {overlapping} - означає, що окремі екземпляри класів-нащадків можуть належати одночасно декільком класам. Приклад - клас "Багатокутник" є класом-предком для класу "Прямокутник" і класу "Ромб". Однак існує окремий клас "Квадрат", екземпляри якого одночасно є об'єктами перших двох класів. Цілком природно таку ситуацію вказати явно за допомогою даною рядка-обмеження.

З урахуванням можливості використання рядків-обмежень діаграма класів (мал. 5.14) може бути зображена без втрати інформації.

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

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

Як вправа для закріплення розглянутого матеріалу можна спробувати побудувати діаграми класів або хоча б їхні фрагменти для бібліотек стандартних класів MFC (Microsoft) і VCL (Borland/Inprise) з використанням графічної нотації мови UML. Можна припустити, що в недалекому майбутньому довідкові посібника з відповідних середовищ програмування будуть містити саме такі діаграми класів, а можливо, і деякі інші.

Лекція №9

Тема: Проектування динамічних аспектів програмних продуктів. Діаграми дій та діяльності, станів.

Мета: Навчитися виконувати проектування динамічних аспектів програмних продуктів.

Перелік питань, що розглядаються на лекції:

1. Діяльність, дія, діаграма діяльності, доріжка та траєкторія об’єкта.

2. Діаграма станів.

Діяльність, дія, діаграма діяльності, доріжка об’єкта.

Діяльність (activity) - триваючий у часі неатомарний крок обчислень в автоматі.

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

Діаграма діяльності (activity diagram) - різновид діаграм, що показує потік переходів від однієї діяльності до іншої. На мал. 9 наведена найпростіша діаграма діяльності.

Початковий стан, стан діяльності й кінцевий стан

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

Розгалуження описує різні шляхи виконання залежно від значення деякого булевського вираження.

Логічний елемент діаграми діяльності

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

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

Доріжки й лінійки синхронізації

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

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

• для моделювання робочого процесу;

• для моделювання операції.

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

Діаграми діяльності можуть зображуватися в контексті окремого класу (для моделювання операції) і в контексті всієї системи. У цьому випадку доцільно використовувати доріжки (Swimlanes). Для моделювання траєкторії об'єкта доцільно додати відповідні піктограми в палітру за допомогою функції Customize контекстного меню.

Діаграма станів

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

Автомат (state machine) - це опис послідовності станів, через які проходить об'єкт протягом свого життєвого циклу.

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

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

Сигнал (signal) - це вид події, у якому стимул передається асинхронно від одного екземпляра до іншого.

Подія виклику призначена для опису виконання операції. Подія виклику звичайно синхронно.

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

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

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

• вихідний стан - стан, з якого відбувається перехід;

• подія-тригер - подія, при одержанні якого об'єктом, що перебуває у вихідному стані, може спрацювати перехід;

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

• дія - атомарне обчислення, що може безпосередньо впливати на об'єкт, що володіє автоматом;

• цільовий стан - стан стає активним після завершення переходу.

Найпростіша діаграма станів

На малюнку представлена найпростіша діаграма станів для об'єкта "рівняння".

Діаграми станів у середовищі Rational Rose ставляться до окремого класу. Для створення такої діаграми в браузері необхідно виділити певний клас і вибрати з контекстного меню New | Statechart Diagram. Щоб додати новий стан, на панелі інструментів необхідно нажати кнопку State або вибрати пункт меню Tools | Create | State.

Щоб додати діяльність, на закладці Detail (Докладно) специфікації необхідного стану за допомогою контекстного меню вікна Actions (Дії) вибирається пункт Insert (Вставити). Дія вводиться в поле Actions (Дії). У вікні When (коли) вказується Do (Виконувати до виходу зі стану), щоб зробити нова дія діяльністю. Щоб додати вхідна дія, у вікні When вказується On Entry (При вході). Щоб додати вихідна дія, у вікні When вказується On Exit (При виході).

Події додаються на закладці General специфікації переходу. Аргументи до події додаються на закладці General специфікації в поле Arguments (Аргументи). Щоб задати умова, що обгороджує, на закладці Detail (Докладно) специфікації переходу умова, що обгороджує, уводиться в поле Condition (умова).

У середовищі Rational Rose розробити діаграми взаємодії, діяльності й станів для проектування завдання рішення рівняння методом дихотомії.

Лекція №10

Тема: Проектування динамічних аспектів програмних продуктів. Взаємодії та послідовностей. Діаграма кооперацій.

Мета: Навчитися виконувати проектування динамічних аспектів програмних продуктів.

Перелік питань, що розглядаються на лекції:

1. Повідомлення

2. Формат запису повідомлень

3. Діаграма кооперації.

Повідомлення

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

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

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

2. Суцільна лінія з V-Образною стрілкою позначає простий потік керування. Кожна така стрілка зображує один етап у послідовності потоку керування. Звичайно всі такі повідомлення є асинхронними.

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

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

  Формат запису повідомлень

Кожне повідомлення може бути позначено рядком тексту, що має наступний формат:

< Попередні повідомлення> < [Сторожова умова] >

<Вираження послідовності>

<Повертається значение, що,- ім'я повідомлення> <Список аргументів>

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

• Попередні повідомлення - є розділені комами номера повідомлень, записані перед похилою рискою:

<Номер повідомлення ','>< Номер повідомлення,'> '/'

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

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

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

Приклад запису попередніх повідомлень: 

A3, В4/ З5: помилка запису (сектор).

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

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

• [(х>=0)&(х<=255)] 1.2: відобразити_на_екрані_колір(х)

• [кількість цифр номера = 7] 3.1: набрати_телефонний_номер()

• Вираження послідовності - є розділений крапками список окремих термов послідовностей, після якого записується двокрапка:

<Терм послідовності'.'><Терм послідовності'.'>':'

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

[Ціле число| Ім'я] [Символ рекуррентности].

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

Наприклад, повідомлення з номером "3.1.4" треба за повідомленням з номером "3.1.3" у процедурній послідовності "3.1".

• Ім'я використовується для специфікації паралельних ниток керування. Повідомлення, які відрізняються тільки ім'ям, є паралельними на цьому рівні вкладеності. На одному рівні вкладеності всі нитки керування еквівалентні в змісті пріоритету передачі повідомлень. З

Наприклад, повідомлення з вираженнями "Зла" і "3.16" є паралельними в процедурній послідовності "3.1".

• Символ рекуррентності використовується для вказівки умовного або ітеративного виконання. Семантика рекуррентності представляє нуль або більше повідомлень, які повинні бути виконані залежно від записаної умови. Можливі два випадки запису рекуррентності:

1.  '*' '[' Пропозиція-Ітерація ']' для запису ітеративного виконання відповідного вираження.

Ітерація представляє послідовність повідомлень одного рівня вкладеності. Пропозиція-Ітерація може бути опущено, якщо умови ітерації ніяк не специфікується. Найбільш часта пропозиція-ітерація записується на деякому псевдокоді або мові програмування. У мові UML формат запису цієї пропозиції не визначений. Наприклад, "*[/:=/..л]", що означає послідовну передачу повідомлення з параметром /, що змінюється від 1 до деякого цілого числа п із кроком 1.

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

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

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

Наприклад, повідомлення

1.2.3: р:= знайти_документ (специфікація_документа)

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

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

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

Так, у наведеному вище прикладі повідомлення

1.2.3: р:= знайти_документ (специфікація_документа)

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

Діаграма кооперації

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

 Приклад побудови діаграми кооперації

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

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

Надалі необхідно специфікувати всі зв'язки на цій діаграмі, указавши на їхніх кінцях необхідну інформацію у формі ролей зв'язків. Доповнений у такий спосіб варіант діаграми кооперації зображений нижче. Помітимо, що для об'єкта "Розмова" зазначене позначене значення {transient}, що означає, що цей об'єкт створюється в процесі виконання загального процесу й знищується до його завершення. Нагадаємо, що позначені значення (tagged values) є стандартними елементами мови UML.

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

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

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

Заключні рекомендації з побудови діаграм кооперації

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

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

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

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

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

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

Практичне заняття №11

Тема: Адміністративна контрольна робота.

Мета: Перевірка отриманих за семестр знань.

(див документ Адміністративна контрольна робота №1 )

Практичне заняття №12

Тема: Підсумкове заняття. Узагальнення вивченого матеріалу за семестр.

Мета: Узагальнення вивченого матеріалу за семестр. Аналіз контрольної роботи.

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

Приклади тестових питань:

1. До якого поняття відноситься твердження: послідовність команд комп'ютера для вирішення завдань

1) додаток

2) програма

3) програмне забезпечення

4) алгоритм

 

2. До якого поняття відноситься твердження:  програмна реалізації на комп'ютері рішення конкретного завдання

1) додаток

2) програма

3) алгоритм

4) програмне забезпечення

 

3. До якого поняття відноситься твердження:  сукупність програм і необхідної документації

1) блок-схема

2) програмне забезпечення

3) додаток

4) програма

 

4. Яка з характеристик не відноситься до промислового програмного продукту?

1) продається на ринку

2) має серійне виробництво

3) розробляється для власних потреб

4) має документацію

 

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

1) підвищення продуктивності праці програмістів

2) забезпечення захисту програм від злому

3) підвищення якості програмних продуктів

4) прискорення розробки програм

 

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

1) системні програмісти

2) системні програмісти

3) мережні адміністратори

4) прикладні програмісти

 

7. Про який вид користувачів програм йде мова: мають навички по використанню програм

1) адміністратори баз даних

2) прикладні програмісти

3) користувачі

4) оператори ПК

 

8. Про який вид користувачів програм йде мова: відповідають за роботу мережі

1) мережні програмісти

2) мережні адміністратори

3) мережні користувачі

4) адміністратори баз даних

 

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

1) адміністратори баз даних

2) мережні адміністратори

3) системні адміністратори

4) системні програмісти

 

10. До якого з показників якості програм відноситься твердження: дружній інтерфейс, розвинена довідка й документація

1) мобільність

2) врахування людського фактору

3) модифікуємість

4) ефективність

 

11. До якого з показників якості програм відноситься твердження: незалежність від платформи, операційної системи й т.і.

1) ефективність

2) надійність

3) мобільність

4) комунікативність

 

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

1) комунікативність

2) ефективність

3) надійність

4) мобільність

 

13. До якого з показників якості програм відноситься твердження:  стійкість, точність виконання функцій

1) ефективність

2) мобільність

3) облік людського фактору

4) надійність

 

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

1) freeware

2) demo

3) shareware

4) opensource

 

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

1) freeware

2) license

3) alfa

4) OEM

 

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

1) opensource

2) demo

3) OЕM

4) freeware

 

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

1) freeware

2) demo

3) opensource

4) beta

 

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

1) opensource

2) freeware

3) license

4) demo

 

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

1) beta

2) freeware

3) demo

4) alfa

20. Якщо прийняти увесь час розробки ПЗ за 100 %, скільки відсотків часу йде на проектування

1) 30%

2) 40%

3) 50%

4) 60%

 

21. Якщо прийняти увесь час розробки ПЗ за 100 %, скільки відсотків часу йде на аналіз вимог до системи

1) 5%

2) 10%

3) 15%

4) 30%

 

22. Якщо прийняти увесь час розробки ПЗ за 100 %, скільки відсотків часу йде на повне тестування продукту

1) 30%

2) 40%

3) 50%

4) 60%

 

23. Яке з наведених визначень підходить під визначення такого етапу життєвого циклу розробки ПЗ як аналіз вимог

1) визначення функцій ПЗ 

2) уточнення й деталізація функцій ПЗ. Проектування плану-графіка виконання робіт

3) створення структур баз даних  і зовнішнього вигляду інтерфейсу

4) проектування систем допомоги й документації

 

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

1) аналіз вимог

2) супровід

3) аналіз ризиків

4) проектування

 

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

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

2) не можна переходити до наступного етапу доти, поки не буде повністю закінчений попередній

3) неможливо точно передбачити час закінчення проекту

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

 

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

1) чим раніше допущена помилка в проекті, тем пізніше вона буде виявлена й тим дорожче її усунення

2) розроблювач може упустити деякі елементи програми

3) розробляти проектну документацію нудно

4) дана стратегія підходить тільки до невеликих, в основному прикладних проектів

 

27. Серед наведених недоліків виберіть той, яке не відноситься до спіральної моделі розробки ПЗ

1) відсутність статистики по ефективності стратегії

2) підвищені вимоги до замовника програмного продукту

3) труднощі по визначенню часу закінчення проекту

4) замовник може побачити результат розробки тільки наприкінці, коли що-небудь змінити вже неможливо

 

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

1) водоспадна модель

2) макетування

3) модель швидкої розробки

4) спіральна модель

 

29. Яка з характеристик не відноситься до моделі RAD?

1) невелика команда виконавців

2) короткий пророблений графік

3) чим раніше буде допущена помилка, тим пізніше її виявлять

4) ітераційний підхід до розробки

 

30. Який з етапів життєвого циклу не відноситься до моделі RAD?

1) тестування

2) реалізація

3) аналіз і планування

4) впровадження

 

31. Яке із тверджень не відноситься до моделі RAD?

1) застосування CASE засобів

2) неповне завершення робіт на етапах життєвого циклу

3) відмова від етапу проектування

4) участь користувачів у розробці

 

32. Яка основна особливість XP-процесів?

1) простота реалізації системи

2) легкість тестування

3) швидка розробка

4) відсутність стадії проектування

 

33. З наведених тверджень приведіть ту, яка не відноситься до принципів XP-процесів

1) безперервне тестування й інтеграція

2) проста при написанні коду

3) детальне проектування

4) постійний зв'язок із замовником

 

34. Який із принципів не відноситься до ХР-процесів?

1) використання стандартів кодування

2) докладне документування

3) колективне володіння кодом

4) парне кодування

 

ІІ семестр

Лекція №1,2

Тема: Поняття тестування та налагодження програмного продукту. Види тестування. Етапи тестування. Створення тестових даних. Проведення тестування. Визначення кількості тестових проходів. Модульне тестування.

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

Перелік питань, що розглядаються на лекції:

1. Поняття налагодження та тестування програмного продукту.

2. Принципи та види налагодження.

3. Аксіоми налагождення.

4. Автономне налагоодження модуля.

5. Комплексне налагождення програмного продукту.

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

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

Налагодження = Тестування + Пошук помилок + Редагування.