<chapter id="uml-basics">
<title
>Основи &UML;</title>
<sect1 id="about-uml">
<title
>Про &UML;</title>
<para
>Цю главу присвячено короткому огляду основ &UML;. Пам’ятайте, що це далеко не повний підручник з &UML;, а скоріше короткий вступ до підручника з &UML;. Якщо ви бажаєте дізнатися більше про універсальну мову моделювання (Unified Modelling Language або &UML;) або отримати загальні відомості щодо аналізу і розробки програмного забезпечення, зверніться до однієї з багатьох книжок, присвячений цим темам. Крім того, у мережі Інтернет ви знайдете багато навчальних посібників, якими можна скористатися для вивчення основних відомостей. </para>

<para
>Універсальна мова моделювання (Unified Modelling Language або &UML;) — це мова позначень або побудови діаграм, призначена для визначення, візуалізації і документування моделей зорієнтованих на об’єкти систем програмного забезпечення. &UML; не є методом розробки, іншими словами, у конструкціях цієї мови не повідомляється про те, що робити першим, а що останнім, і не надається інструкцій щодо побудови вашої системи, але ця мова допомагає вам наочно переглядати компонування системи і полегшує співпрацю з іншими її розробниками. Розробкою &UML; керує Object Management Group (<acronym
>OMG</acronym
>). Ця мова є загальноприйнятим стандартом графічного опису програмного забезпечення. </para>
<para
>&UML; розроблено для розробки структури зорієнтованого на об’єкти програмного забезпечення, ця мова має дуже обмежену користь для програмування на основі інших парадигм. </para>
<para
>Конструкції &UML; створюються з багатьох модельних елементів, які позначають різні частини системи програмного забезпечення. Елементи &UML; використовуються для побудови діаграм, які відповідають певній частині системи або точці зору на систему. У &umbrello; реалізовано підтримку таких типів діаграм: </para>

<itemizedlist>

<listitem
><para
><emphasis
><link linkend="use-case-diagram"
>Діаграма випадків використання</link
></emphasis
> показує дієвих осіб (людей або інших користувачів системи), випадки використання (сценарії використання системи) та їх взаємодію</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="class-diagram"
>Діаграми класів</link
></emphasis
>, на яких буде показано класи та зв’язки між ними</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="sequence-diagram"
>Діаграми послідовності</link
></emphasis
>, на яких показано об’єкти і послідовність методів, якими ці об’єкти викликають інші об’єкти.</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="collaboration-diagram"
>Діаграми співпраці</link
></emphasis
>, на яких буде показано об’єкти та їх взаємозв’язок з наголосом на об’єкти, які беруть участь у обміні повідомленнями</para>
</listitem>

<listitem
><para
><emphasis
><link linkend="state-diagram"
>Діаграми стану</link
></emphasis
>, на яких буде показано стани, зміну станів і події у об’єкті або частині системи</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="activity-diagram"
>Діаграми діяльності</link
></emphasis
>, на яких буде показано дії та зміни однієї дії іншою, які є наслідком подій, що сталися у певній частині системи</para
></listitem>

<listitem
><para
><emphasis
><link linkend="component-diagram"
>Діаграми компонентів</link
></emphasis
>, на яких буде показано програмні компоненти високого рівня (на зразок KParts або Java Beans).</para
></listitem>

<listitem
><para
><emphasis
><link linkend="deployment-diagram"
>Діаграми впровадження</link
></emphasis
>, на яких буде показано екземпляри компонентів та їх взаємодію.</para
></listitem
> 

<listitem
><para
><emphasis
><link linkend="entity-relationship-diagram"
>Діаграми взаємозв’язку сутностей</link
></emphasis
>, на яких буде показано дані, взаємозв’язки і умови обмеження зв’язків між даними.</para
></listitem
> 

</itemizedlist>

</sect1
>   <!-- about-uml -->

<sect1 id="uml-elements"
>  
<title
>Елементи &UML;</title>
<sect2 id="use-case-diagram">
<title
>Діаграма випадків використання</title>
<para
>Діаграми випадків використання описують взаємозв’язки і залежності між групою <emphasis
>випадків використання</emphasis
> і акторами, що беруть участь у процесі.</para>
<para
>Важливо зауважити, що діаграми випадків використання не призначено для показу компонування, вони не можуть описати внутрішню структуру системи. Діаграми випадків використання призначено для полегшення обміну інформацією між майбутніми користувачами системи і замовником, вони особливо корисні для визначення переліку можливостей, які повинна мати система. За діаграмами випадків використання можна сказати, <emphasis
>що</emphasis
> система має робити, але не те, <emphasis
>як</emphasis
> вона досягає потрібних результатів, для останнього ці діаграми просто не придатні.</para>
<para>
<screenshot>
<screeninfo
>Приклад діаграми випадків використання.</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="use-case-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Показ у &umbrello; діаграми випадків використання</phrase>
	  </textobject>
	  <caption>
	    <para
>Показ у &umbrello; діаграми випадків використання </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="use-case">
<title
>Випадок використання</title>
<para
><emphasis
>Випадок використання</emphasis
> визначає, з точки зору акторів (користувачів), групу дій у системі, які призводять до конкретного видимого результату.</para>
<para
>Випадки використання є описом типових елементів взаємодії користувачів системи з самою системою. Вони відповідають зовнішньому інтерфейсу системи і визначають форму вимог до того, що має робити система (зауважте, лише «що», а не «як»). </para>
<para
>Під час роботи з випадками використання важливо пам’ятати декілька простих правил: <itemizedlist>
 <listitem
><para
>Кожен випадок використання має бути пов’язано принаймні з одним актором</para
></listitem>
 <listitem
><para
>У кожного з випадків використання має бути ініціатор (тобто актор)</para
></listitem>
 <listitem
><para
>Кожен з випадків використання має призводити до відповідного результату (результату з <quote
>комерційним значенням</quote
>)</para>
 </listitem>
 </itemizedlist>
</para>
<para
>Випадки використання можуть мати зв’язки з іншими випадками використання. Ось три найпоширеніших зв’язки між випадками використання:</para>
<itemizedlist>
<listitem
><para
><emphasis
>&lt;&lt;включення&gt;&gt;</emphasis
>, яке вказує на те, що випадок використання відбувається <emphasis
>всередині</emphasis
> іншого випадку використання</para
></listitem>
<listitem
><para
><emphasis
>&lt;&lt;розширення&gt;&gt;</emphasis
>, яке означає, що у певних випадках або у певній точці (яку називають точкою розширення) випадок використання буде розширено іншим випадком використання.</para
></listitem>
<listitem
><para
><emphasis
>Узагальнення</emphasis
>, за якого випадок використання успадковує характеристики випадку використання <quote
>вищого рангу</quote
>, при цьому можливе перевизначення деяких з характеристик у спосіб, подібний до успадкування між класами. </para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="actor">
<title
>Актор</title>
<para
>Актор — це зовнішній чинник (поза межами системи), який взаємодіє з системою шляхом участі (і часто ініціювання) у випадку використання. Акторами, на практиці, можуть бути звичайні люди (наприклад, користувачі системи), інші комп’ютерні системи або зовнішні події. </para>
<para
>Акторам відповідають не <emphasis
>реальні</emphasis
> люди або системи, а лише їх <emphasis
>ролі</emphasis
>. Це означає, що коли особа у різний спосіб взаємодіє з системою (виконуючи різні ролі), їй відповідають декілька акторів. Наприклад, особа, яка виконує підтримку користувачів телефоном і приймає замовлення від користувачів до системи, може бути показано актором <quote
>Персонал служби підтримки</quote
> і актором <quote
>Відповідальний за продажі</quote
>. </para>
</sect3>
<sect3 id="use-case-description">
<title
>Опис випадків використання</title>
<para
>Описи випадків використання — це текстові примітки до випадків використання. Зазвичай, вони мають форму нотаток або документа, який певним чином пов’язано з випадком використання, і який пояснює процеси або дії, які відбуваються під час випадку використання. </para>
</sect3>
</sect2
> <!-- use-case-diagram -->

<sect2 id="class-diagram">
<title
>Діаграма класів</title>
<para
>На діаграмах класів буде показано різноманітні класи, які утворюють систему і їх взаємозв’язки. Діаграми класів називають <quote
>статичними діаграмами</quote
>, оскільки на них показано класи разом з методами і атрибутами, а також статичний взаємозв’язок між ними: те, яким класам <quote
>відомо</quote
> про існування яких класів, і те, які класи <quote
>є частиною</quote
> інших класів, — але не показано методи, які при цьому викликаються. </para>
<para>
<screenshot>
<screeninfo
>Приклад діаграми класів</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="class-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Показ &umbrello; діаграми класів</phrase>
	  </textobject>
	  <caption>
	    <para
>Показ &umbrello; діаграми класів </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="class">
<title
>Клас</title>
<para
>Клас визначає атрибути і методи набору об’єктів. Всі об’єкти цього класу (екземпляри цього класу) мають спільну поведінку і однаковий набір атрибутів (кожен з об’єктів має свій власний набір значень). Іноді замість назви «клас» використовують назву <quote
>тип</quote
>, але, слід зауважити, що ці назви описують різні речі: тип є загальнішим визначенням. </para>
<para
>У &UML; класи позначаються прямокутниками з назвою класу, у цих прямокутниках у вигляді двох <quote
>відсіків</quote
> може бути показано атрибути і операції класу. </para>
<para>
<screenshot>
<screeninfo
>Клас у &UML;</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="class.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочне представлення класу у &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочне представлення класу у &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect4 id="attribute">
<title
>Атрибути</title>
<para
>У &UML; атрибути показуються щонайменше назвою, також може бути показано їх тип, початкове значення і інші властивості. Крім того, атрибути може бути показано з областю видимості атрибута: </para>
<itemizedlist>
<listitem
><para
><literal
>+</literal
> відповідає <emphasis
>публічним (public)</emphasis
> атрибутам</para
></listitem>
<listitem
><para
><literal
>#</literal
> відповідає <emphasis
>захищеним (protected)</emphasis
> атрибутам</para
></listitem>
<listitem
><para
><literal
>-</literal
> відповідає <emphasis
>приватним (private)</emphasis
> атрибутам</para
></listitem>
</itemizedlist>
</sect4>
<sect4 id="operation">
<title
>Операції</title>
<para
>Операції (методи) також показуються принаймні назвою, крім того, може бути показано їх параметри і типи значень, які буде повернуто. Операції, як і атрибути, може бути показано з областю видимості: <itemizedlist>
<listitem
><para
><literal
>+</literal
> відповідає <emphasis
>публічним (public)</emphasis
> операціям</para
></listitem>
<listitem
><para
><literal
>#</literal
> відповідає <emphasis
>захищеним (protected)</emphasis
> операціям</para
></listitem>
<listitem
><para
><literal
>-</literal
> відповідає <emphasis
>приватним (private)</emphasis
> операціям</para
></listitem>
</itemizedlist>
</para>
</sect4>

<sect4 id="templates">
<title
>Шаблони</title>
<para
>Серед класів можуть бути шаблони, значення, які використовуються для невизначеного класу або типу. Тип шаблону визначається під час ініціалізації класу (тобто, під час створення об’єкта). Шаблони існують у сучасній мові програмування C++, їх буде введено у Java 1.5, де вони матимуть назву Generic. </para>
</sect4>
</sect3>

<sect3 id="class-associations">
<title
>Асоціації класів</title>
<para
>Класи можна співвіднести (пов’язати) один з одним у декілька способів:</para>
<sect4 id="generalization">
<title
>Узагальнення</title>
<para
>Наслідування є однією з фундаментальних основ об’єктно-орієнтованого програмування, у якому клас <quote
>отримує</quote
> всі атрибути і операції класу, нащадком якого він є, і може перевизначати або змінювати деякі з них, а також додавати власні атрибути і операції.</para>
<para
>У &UML; пов’язування <emphasis
>Узагальнення</emphasis
> між двома класами розташовує їх у вузлах ієрархії, яка відповідає концепції успадкування класу-нащадка від базового класу. У &UML; узагальнення буде показано у вигляді лінії, яка поєднує два класи, зі стрілкою, яку спрямовано від базового класу. <screenshot>
<screeninfo
>Узагальнення</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="generalization.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ узагальнення у &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочний показ узагальнення у &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="uml-associations">
<title
>Асоціації</title>
<para
>Асоціація означає взаємозв’язок між класами, вона є базовим семантичним елементом і структурою для багатьох типів <quote
>з’єднань</quote
> між об’єктами.</para>
<para
>Асоціації є тим механізмом, який надає об’єктам змогу обмінюватися даними між собою. Асоціація описує з’єднання між різними класами (з’єднання між дійсними об’єктами називається об’єктним з’єднанням, або <emphasis
>зв’язком</emphasis
>). </para>
<para
>Асоціації можуть виконувати роль, яка визначає призначення асоціації і може бути одно- чи двосторонньою (другий варіант означає, що у межах зв’язку кожен з об’єктів може надсилати повідомлення іншому, перший же — варіанту, коли лише один з об’єктів знає про існування іншого). Крім того, кожен з кінців асоціації має значення численності, яке визначає кількість об’єктів на відповідному кінці асоціації, які можуть мати зв’язок з одним з об’єктів на іншому кінці асоціації. </para>
<para
>У &UML; асоціації позначаються лініями, що з’єднують класи, які беруть участь у зв’язку, крім того, може бути показано роль і численність кожного з учасників зв’язку. Численність буде показано у вигляді діапазону [мін..макс] невід’ємних чисел, зірочка (<literal
>*</literal
>) на боці максимального значення позначає нескінченність. <screenshot>
<screeninfo
>Асоціація &UML;</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="association.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ асоціації у &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочний показ асоціації у &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="aggregation">
<title
>Агрегація</title>
<para
>Агрегації є особливим типом асоціацій, за якого два класи, які беруть участь у зв’язку не є рівнозначними, вони мають зв’язок типу <quote
>ціле-частина</quote
>. За допомогою агрегації можна описати, яким чином клас, який грає роль цілого, складається з інших класів, які грають роль частин. У агрегаціях клас, який грає роль цілого, завжди має численність рівну одиниці. </para>
<para
>У &UML; агрегації буде показано асоціаціями, у яких з боку цілої частини буде намальовано ромб. <screenshot>
<screeninfo
>Агрегація</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="aggregation.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ зв’язку агрегації у &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочний показ зв’язку агрегації у &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>
<sect4 id="composition">
<title
>Композиція</title>
<para
>Композиції — це асоціації, які відповідають <emphasis
>дуже сильній</emphasis
> агрегації. Це означає, що у композиціях ми також маємо справу з співвідношеннями ціле-частина, але тут зв’язок є настільки сильним, що частини не можуть існувати без цілого. Вони існують лише у межах цілого, після знищення цілого буде знищено і його частини.</para>
<para
>У &UML; композиції буде показано як асоціації з зафарбованим ромбом з боку цілого. </para>
<para
><screenshot>
<screeninfo
>Композиція</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="composition.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ зв’язку композиції у &UML;</phrase>
	  </textobject>
	</mediaobject>
</screenshot
></para>
</sect4>
</sect3
> <!--class-associations-->

<sect3 id="other-class-diagram-items">
<title
>Інші елементи діаграми класів</title>
<para
>Окрім класів на діаграмах класів можуть міститися і деякі інші елементи.</para>
<sect4 id="interfaces">
<title
>Інтерфейси</title>
<para
>Інтерфейси — це абстрактні класи, тобто з них не можна напряму створювати екземпляри. У інтерфейсах можуть міститися операції, але не атрибути. Класи можуть бути нащадками інтерфейсів (за допомогою асоціації реалізації), а з цих діаграм можна потім створювати сутності.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="datatype">
<title
>Типи даних</title>
<para
>Типи даних — це базові елементи, з яких типово будується мова програмування. Типовими прикладами є цілі числа і булеві значення. Вони не можуть мати зв’язків з класами, але класи можуть мати зв’язки з ними.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="enum">
<title
>Переліки</title>
<para
>Переліки є простими списками значень. Типовим прикладом є перелік днів тижня. Пункти переліків називаються літералами переліків. Подібно до типів даних, переліки не можуть мати зв’язків з класами, але класи можуть мати зв’язки з переліками.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="package">
<title
>Пакунки</title>
<para
>Пакункам відповідають простори назв у мовах програмування. На діаграмі пакунки використовуються для позначення частин системи, у яких міститься декілька класів, може навіть сотні класів.</para>
<!-- FIXME screenshot -->
</sect4>
</sect3>

</sect2
> <!-- class diagram -->

<sect2 id="sequence-diagram">
<title
>Діаграми послідовностей</title>

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

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

<!-- FIXME update screenshot to show synchronous messages -->
<screenshot>
<screeninfo
>Діаграма послідовностей</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="sequence-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Показ діаграми послідовностей у &umbrello;</phrase>
	  </textobject>
	  <caption>
	    <para
>Показ діаграми послідовностей у &umbrello; </para>
	  </caption>
	</mediaobject>
</screenshot>

<para
>Повідомлення можуть бути або синхронними, звичайного типу повідомленнями, за виклику яких керування передається викликаному об’єкту до завершення виконання методу, або асинхронними, за виклику яких керування передається назад напряму об’єкту, який здійснював виклик. За використання синхронного повідомлення збоку від викликаного об’єкта буде показано вертикальний блок, який показуватиме перебіг виконання програми.</para>
</sect2
> <!-- sequence diagrams -->

<sect2 id="collaboration-diagram">
<title
>Діаграми співпраці</title>

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

<para
>На діаграмах співпраці повідомлення надіслані від одного з об’єктів до іншого позначаються стрілочками, поряд з якими показано назву повідомлення, параметри і послідовність повідомлення. Діаграми співпраці найкраще пасують для показу специфічного перебігу виконання або ситуацій у програмі. Такі діаграми є найкращим засобом для швидкого показу і пояснення окремого процесу у програмній логіці. </para>

<screenshot>
<screeninfo
>Співпраця</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="collaboration-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Показ діаграми співпраці у &umbrello;</phrase>
	  </textobject>
	  <caption>
	    <para
>Показ діаграми співпраці у &umbrello; </para>
	  </caption>
	</mediaobject>
</screenshot>

</sect2
> <!-- collaboration diagrams -->

<sect2 id="state-diagram">
<title
>Діаграма станів</title>
<para
>На діаграмах станів зображають різні стани об’єкта під час його існування і стимули, які призводять до переходу об’єкта з одного стану у інший. </para
>                              
<para
>На діаграмах стану об’єкти розглядаються як <emphasis
>машини станів</emphasis
> або скінченні автомати, які можуть перебувати у одному зі станів скінченного набору станів, і які можуть змінювати цей стан через вплив одного зі стимулів зі скінченного набору стимулів. Наприклад, об’єкт типу <emphasis
>Сервер мережі</emphasis
> може перебувати у одному з таких станів протягом існування: </para>
<itemizedlist>
<listitem
><para
>Готовність</para
></listitem>
<listitem
><para
>Очікування</para
></listitem>
<listitem
><para
>Робота</para
></listitem>
<listitem
><para
>Зупинка</para
></listitem>
</itemizedlist>
<para
>а подіями, які можуть спричинити зміну стану об’єкта можуть бути</para>
<itemizedlist>
<listitem
><para
>Створення об’єкта</para
></listitem>
<listitem
><para
>Об’єкт отримує повідомлення «очікувати»</para
></listitem>
<listitem
><para
>Клієнт надсилає запит на з’єднання мережею</para
></listitem>
<listitem
><para
>Клієнт перериває запит</para
></listitem>
<listitem
><para
>Запит виконано і перервано</para
></listitem>
<listitem
><para
>Об’єкт отримує повідомлення «зупинка»</para
></listitem>
<listitem
><para
>тощо</para
></listitem>
</itemizedlist>
<para>
<screenshot>
<screeninfo
>Діаграма станів</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="state-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Показ діаграми станів у &umbrello;</phrase>
	  </textobject>
	  <caption>
	    <para
>Показ діаграми станів у &umbrello; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="state">
<title
>Стан</title>
<para
>Будівельними цеглинками діаграм станів є стани. Стан належить лише одному класу і відповідає переліку значень атрибутів, які може приймати клас. У &UML; стан описує внутрішній стан об’єкта одного з окремих класів </para
>                       
<para
>Зауважте, що не кожну зміну одного з атрибутів об’єкта має бути показано станом, станам відповідають лише ті зміни, які значно впливають на виконання об’єктом завдань.</para>
<para
>Існує два особливих типи станів: початок і кінець. Їх особливість полягає у тому, що не існує жодної події, яка може спричинити повернення об’єкта до його початкового стану, так само, не існує жодної події, яка б могла повернути об’єкт зі стану кінця, тільки-но він його досягне. </para>
</sect3>

</sect2
> <!-- state diagrams -->

<sect2 id="activity-diagram">
<title
>Діаграма діяльності</title>
<para
>На діаграмі діяльності буде показано послідовність актів дій системи на основі Діяльностей. Діаграми діяльності є особливою формою діаграм стану, на яких містяться лише (або головним чином) діяльності. </para>
<para>
<screenshot>
<screeninfo
>Приклад діаграми діяльності.</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="activity-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Показ діаграми діяльності у &umbrello;</phrase>
	  </textobject>
	  <caption>
	    <para
>Показ діаграми діяльності у &umbrello; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<para
>Діаграми діяльності подібні до процедурних діаграм потоку, але відрізняються від них тим, що діяльності точно прив’язано до об’єктів.</para>

<para
>Діаграми діяльності завжди пов’язано з <emphasis
>класом</emphasis
>, <emphasis
>операцією</emphasis
> або <emphasis
>випадком використання</emphasis
>.</para>

<para
>На діаграмах діяльності може бути показано як послідовні, так і паралельні діяльності. Паралельне виконання буде показано за допомогою піктограм Розділити/Чекати, для діяльностей, які виконуються паралельно, неважливим є порядок їх обробки (їх може бути виконано одночасно або одну за одною).</para>
<sect3 id="activity">
<title
>Діяльність</title>
<para
>Діяльність є окремим кроком у процесі. Одній діяльності відповідає окремий стан у системі з внутрішньою діяльністю і, принаймні, одна вихідна транзакція. Крім того, діяльності можуть мати декілька вихідних транзакцій, якщо умови цих транзакцій є різними. </para
> 
<para
>Діяльності можуть формувати ієрархічні структури, це означає, що діяльність може бути складено з декількох <quote
>менших</quote
> діяльностей, у цьому випадку вхідні і вихідні транзакції мають відповідати вхідним і вихідним транзакціям докладної діаграми. </para>

</sect3>
</sect2
> <!-- activity diagram -->

<sect2 id="helper-elements">
<title
>Допоміжні елементи</title>
<para
>У &UML; є декілька елементів, які не мають реального семантичного змісту для моделі, але допомагають прояснити частини діаграми. Цими елементами є </para>
<itemizedlist>
<listitem
><para
>Рядки тексту</para
></listitem>
<listitem
><para
>Текстові нотатки і якорі</para
></listitem>
<listitem
><para
>Блоки</para
></listitem>
</itemizedlist
>   
<para
>Рядки тексту можуть знадобитися, якщо до діаграми слід додати коротку текстову інформацію. Вони є довільно розташованим тестом і не мають значення для самої моделі. </para
>           

<para
>Нотатками можна скористатися для додавання докладніших відомостей щодо об’єкта або певної ситуації. У них є велика перевага у тому, що нотатки можна пов’язати з елементами &UML;, щоб було видно, що нотатка <quote
>стосується</quote
> певного об’єкта або ситуації. </para>

<para
>Блоки є довільно розташованими прямокутниками, які можна використовувати для групування об’єктів діаграми, яке зробить діаграму зрозумілішою. Вони не мають логічного навантаження у межах моделі.</para>

<!-- FIXME, screenshot -->
</sect2
> <!-- helper elements -->

<sect2 id="component-diagram">
<title
>Діаграми компонентів</title>
<para
>На діаграмах компонентів буде показано компоненти програмного забезпечення (або технології компонентів, такі як KParts, компоненти CORBA або Java Beans, або просто розділи системи, які чітко відрізняються один від одного), а також елементи, з яких вони складаються, такі як файли з початковими кодами, програмні бібліотеки або таблиці реляційних баз даних.</para>

<para
>Компоненти можуть мати інтерфейси (тобто абстрактні класи з операціями), які надають змогу створювати асоціації між компонентами.</para>
</sect2>

<sect2 id="deployment-diagram">
<title
>Діаграми впровадження</title>

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

</sect2>

<sect2 id="entity-relationship-diagram">
<title
>Діаграми взаємозв’язків сутностей</title>

<para
>На діаграмах взаємозв’язку сутностей (діаграмах ВС (ER)) показують концептуальний дизайн програм для роботи з базами даних. На них показують різноманітні сутності (концепти) у інформаційній системі і існуючі взаємозв’язки і обмеження між ними. Розширення діаграм взаємозв’язку сутностей називають «Розширеними діаграмами взаємозв’язку сутностей» або «Покращеними діаграмами взаємозв’язку сутностей» (EER), їх використовують для інтеграції методик компонування орієнтованих на об’єкти у діаграми ВС. </para
> 
<para>
<screenshot>
<screeninfo
>Приклад діаграми взаємозв’язків сутностей</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="entity-relationship-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Показ діаграми взаємозв’язків сутностей у &umbrello;</phrase>
	  </textobject>
	  <caption>
	    <para
>Показ діаграми взаємозв’язків сутностей у &umbrello; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="entity">
<title
>Сутність</title>
<para
><emphasis
>Сутністю</emphasis
> є будь-яке з понять реального світу, яке має окреме існування. Нею може бути об’єкт фізичної природи (наприклад, комп’ютер або робот), нею може бути і об’єкт зі концептуальним існуванням (університетський курс). Кожна з сутностей має набір атрибутів, які описують властивості сутності.</para>
<para
><emphasis
>Зауваження:</emphasis
> не існує стандартів позначень діаграм ВС (ER). У різних працях з цього питання використовують різні позначення. Поняття і позначення для діаграм у &umbrello; запозичено з книги: <emphasis
>Elmasri R. and Navathe S. (2004). Fundamentals of Database Systems 4th edn. Addison Wesley</emphasis
> </para>
<para
>На діаграмі ВС(ER) сутності позначаються прямокутниками з назвою у верхній частині, на них також може бути показано атрибути сутності у іншому <quote
>відсіку</quote
> прямокутника. </para>
<para>
<screenshot>
<screeninfo
>Сутність на діаграмі взаємозв’язку сутностей;</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="entity.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ сутності на діаграмі взаємозв’язку сутностей</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочний показ сутності на діаграмі взаємозв’язку сутностей </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect4 id="entity-attribute">
<title
>Атрибути сутності</title>
<para
>На діаграмах взаємозв’язку сутностей атрибути сутностей показуються назвами у окремій ділянці сутності, якій вони належать. </para>
</sect4>
<sect4 id="constraint">
<title
>Обмеження</title>
<para
>Обмеження на діаграмах взаємозв’язку сутностей визначають обмеження на дані у інформаційній схемі. </para>
<para
>У &umbrello; підтримуються чотири типи обмежень: <itemizedlist>
 <listitem>
    <para
><emphasis
>Головний ключ:</emphasis
> Набір атрибутів, оголошених як <emphasis
>головний ключ</emphasis
> є унікальним для сутності. У сутності має існувати лише один головний ключ, а жоден з складових атрибутів цього ключа не повинен дорівнювати NULL. </para>
</listitem>
 <listitem>
    <para
><emphasis
>Унікальний ключ:</emphasis
> Набір атрибутів, оголошених як <emphasis
>унікальний ключ</emphasis
> є унікальним для сутності. У сутності може бути декілька унікальних обмежень. Складові атрибути ключа можуть приймати значення NULL. Унікальні ключі і головні ключі однозначно визначають рядок у таблиці (сутність).</para>
 </listitem>
 <listitem>
    <para
><emphasis
>Сторонній ключ:</emphasis
> Сторонній ключ є довідковим обмеженням між двома таблицями. За стороннім ключем визначається стовпчик або набір стовпчиків у одній (тій, для якої потрібна довідка) таблиці), яка стосується стовпчика або набору стовпчиків у іншій (еталонній) таблиці. Стовпчики у еталонній таблиці повинні мати форму головного ключа і унікального ключа. </para>
 </listitem>
 <listitem>
     <para
><emphasis
>Обмеження перевірки:</emphasis
> Обмеження перевірки (також відоме як обмеження перевірки таблиці) є умовою, яка визначає коректність даних під час додавання або оновлення запису у таблиці реляційної бази даних. Обмеження перевірки застосовується до кожного з рядків таблиці. Обмеження має бути предикативним. Воно може стосуватися одного або декількох стовпчиків таблиці. </para>
     <para
>Приклад: вартість 
>= 0 </para>
 </listitem>
 </itemizedlist>
</para>
</sect4>
</sect3>
</sect2>
<sect2 id="extended-entity-relationship-concepts">
<title
>Концепції розширеної діаграми взаємозв’язку сутностей</title>
<sect3 id="specialization">
<title
>Спеціалізація</title>
<para
>Спеціалізація — це один зі способів формування нових сутностей за допомогою сутностей, які вже було визначено. Нові сутності, відомі як сутності-нащадки, успадковують атрибути сутностей, які вже існували, і які називають базовими. Спеціалізація призначена для спрощення повторного використання даних з невеликою модифікацією або взагалі без модифікації.</para>
<para
>У &umbrello; можна задавати несумісну і перекриту спеціалізацію</para>
 <sect4 id="disjoint-specialization">
   <title
>Несумісна спеціалізація</title>
   <para
>Несумісна спеціалізація вказує, що підкласи спеціалізації не повинні перетинатися. Це означає, що сутність може бути членом не більше ніж однієї з сутностей-нащадків спеціалізації.</para>
   <para>
   <screenshot>
    <screeninfo
>Сутності, які належать до несумісної спеціалізації</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="disjoint-specialization.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ несумісної спеціалізації на діаграмі EER</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочний показ несумісної спеціалізації на діаграмі EER </para>
	  </caption>
	</mediaobject>
   </screenshot>
    </para>
 </sect4>
 <sect4 id="overlapping-specialization">
   <title
>Перекрита спеціалізація</title>
   <para
>Якщо сутності-нащадки не обмежено вимогою відсутності перетинів, такий набір сутностей належить до перекритої спеціалізації. Це означає, що однакові сутності реального світу можуть бути членами декількох сутностей-нащадків спеціалізації/</para>
   <para>
   <screenshot>
    <screeninfo
>Сутності, які належать до перекритої спеціалізації</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="overlapping-specialization.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ перекритої спеціалізації на діаграмі EER</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочний показ перекритої спеціалізації на діаграмі EER </para>
	  </caption>
	</mediaobject>
   </screenshot>
  </para>
 </sect4>
 <sect4 id="category">

 <title
>Категорія</title>
 <para
>Говорять, що сутність-нащадок є <emphasis
>Категорією</emphasis
>, якщо їй відповідає збірка об’єктів, яка є підмножиною об’єднання різних типів сутностей. Категорії беруть участь у моделюванні, якщо виникає потреба у окремому співвідношенні суперкласі/підкласі з декількома суперкласами, де суперкласу відповідають різні типи сутностей. (Дуже схоже на кратне успадкування у об’єктно-орієнтованому програмуванні). </para>
   <para>
   <screenshot>
    <screeninfo
>Сутності, що беруть участь у співвідношенні категорії</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="category.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Наочний показ категорії на діаграмі EER</phrase>
	  </textobject>
	  <caption>
	    <para
>Наочний показ категорії на діаграмі EER</para>
	  </caption>
	</mediaobject>
   </screenshot>
  </para>
 </sect4>

</sect3>
</sect2>

</sect1
> 
</chapter>