<chapter id="uml-basics">
<title
>&UML;i põhitõed</title>
<sect1 id="about-uml">
<title
>&UML;ist</title>
<para
>See peatükk annab sulle kiire ülevaate &UML;i põhitõdedest. Ära unusta, et see pole põhjalik &UML;i õpik vaid pigem lühike sissejuhatus &UML;i, mida on võimalik lugeda õpikuna. Kui soovid &UML;i või üldse tarkvara analüüsi ja disaini kohta rohkem teada saada, siis kasuta mõnda paljudest samal teemal saadavalolevatest raamatutest. Lisaks on paljud alustuseks sobivad õpikud saadaval Internetist. </para>

<para
>&UML; on skeemide loomise keel või täpsemalt öeldes ülesmärkimise keel objektorienteeritud tarkvarasüsteemide kirjeldamiseks, visualiseerimiseks ja dokumenteerimiseks. &UML; ei ole arendusmeetod, mis tähendab, et see ei ütle sulle, mida teha esimesena ja mida järgmisena või kuidas süsteemi disainida, kuid aitab disaini visualiseerida ja teistega edukalt suhelda. &UML; on Object Management Group'i (<acronym
>OMG</acronym
>) kontrolli all olev tarkvara graafiliseks kirjeldamiseks mõeldud tööstusstandard. </para>
<para
>&UML; on mõeldud objekt-orienteeritud tarkvara disainiks ja omab seepärast teiste programmeerimisparadigmade toetust piiratult. </para>
<para
>&UML; koosneb paljudest mudeli elementidest, mis esindavad tarkvarasüsteemi erinevaid osi. &UML;i elementide abil luuakse skeeme, mis esindavad kindlaid süsteemi osi või vaatepunkte. Umbrello toetab järgmisi skeemitüüpe: </para>

<itemizedlist>

<listitem
><para
><emphasis
><link linkend="use-case-diagram"
>kasutusklassiskeemid</link
></emphasis
> kujutavad tegijaid (inimesed või teised süsteemi kasutajad), kasutusklasse (süsteemi kasutamise võimalused) ja nendevahelisi relatsioone</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="class-diagram"
>klassiskeemid</link
></emphasis
> kujutavad klasse ja  nendevahelisi relatsioone</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="sequence-diagram"
>järgnevusskeemid</link
></emphasis
> kujutavad objekte ja nende poolt sooritatavate meetodite väljakutsete järgnevusi</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="collaboration-diagram"
>koostööskeemid</link
></emphasis
> kujutavad objekte ja nendevahelisi relatsioone, pannes rõhu objektidele, mis osalevad sõnumite vahetamises</para>
</listitem>

<listitem
><para
><emphasis
><link linkend="state-diagram"
>olekuskeemid</link
></emphasis
> kujutavad olekuid, olekute muutusi ja sündmusi objektis või süsteemi osas</para
> </listitem>

<listitem
><para
><emphasis
><link linkend="activity-diagram"
>tegevusskeemid</link
></emphasis
> kujutavad tegevusi ja muutusi ühest tegevusest teise seoses mõnes süsteemi osas toimuvate sündmustega</para
></listitem>

<listitem
><para
><emphasis
><link linkend="component-diagram"
>komponentskeemid</link
></emphasis
> kujutavad kõrgetasemelisi programmeerimiskomponente (nt KParts või JavaBeans)</para
></listitem>

<listitem
><para
><emphasis
><link linkend="deployment-diagram"
>Evitusskeemid</link
></emphasis
> kujutavad komponentide eksemplare ja nendevahelisi relatsioone</para
></listitem
> 

</itemizedlist>

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

<sect1 id="uml-elements"
>  
<title
>&UML;i elemendid</title>
<sect2 id="use-case-diagram">
<title
>Kasutusklassiskeem</title>
<para
>Kasutusklassiskeemid kirjeldavad protsessis osalevate <emphasis
>kasutusklasside</emphasis
> ja <emphasis
>tegijate</emphasis
> vahelisi relatsioone ja sõltuvusi.</para>
<para
>Tähtis on tähele panna, et kasutusklassiskeemid pole mõeldud disaini kujutamiseks ja süsteemi sisestruktuuride kirjeldamiseks. Kasutusklassiskeemid on mõeldud kergendama suhtlemist kliendi ja süsteemi tulevaste kasutajate ning on eriti kasulikud süsteemi funktsionaalsuse väljaselgitamisel. Kasutusklassiskeemid peaksid ütlema, <emphasis
>mida</emphasis
> süsteem peaks tegema, mitte aga &mdash; ja ei tohigi öelda &mdash;, <emphasis
>kuidas</emphasis
> tehtu saavutatakse.</para>
<para>
<screenshot>
<screeninfo
>Kasutusklassiskeemi näidis</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/use-case-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Kasutusklassiskeem Umbrellos</phrase>
	  </textobject>
	  <caption>
	    <para
>Kasutusklassiskeem Umbrellos </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="use-case">
<title
>Kasutusklass</title>
<para
>Kasutusklass kirjeldab süsteemi tegevuste gruppi, mis tagastab konkreetse ja käegakatsutava tulemuse, tegijate vaatenurgast.</para>
<para
>Kasutusklassid on tüüpilised süsteemi kasutajate ja süsteemi enda vaheliste interaktsioonide kirjeldused. Nad esindavad süsteemi välist liidest ja määravad nõuete kogu selle kohta, mida süsteem peab tegema (ära unusta: ainult mida, mitte kuidas). </para>
<para
>Kasutusklassidega töötades on tähtis meeles pidada mõned lihtsad reeglid: <itemizedlist>
 <listitem
><para
>iga kasutusklass on seotud vähemalt ühe tegijaga</para
></listitem>
 <listitem
><para
>igal kasutusklassil on olemas algataja (st tegija)</para
></listitem>
 <listitem
><para
>Iga kasutusklass juhatab kindla tulemuseni (<quote
>ärilise väärtusega</quote
> tulemuseni)</para>
 </listitem>
 </itemizedlist>
</para>
<para
>Ka kasutusklassidel võivad teiste kasutusklassidega relatsioonid olla. Kolm tüüpilisemat kasutusklasside vaheliste relatsioonide tüüpi on:</para>
<itemizedlist>
<listitem
><para
><emphasis
>&lt;&lt;include&gt;&gt;</emphasis
> määrab, kas kasutusklass leiab aset teise kasutusklassi <emphasis
>sees</emphasis
></para
></listitem>
<listitem
><para
><emphasis
>&lt;&lt;extends&gt;&gt;</emphasis
> määrab, et kindlates situatsioonides või mingis punktis (mida kutsutakse laienduspunktiks) laiendab üks kasutusklass teist</para
></listitem>
<listitem
><para
><emphasis
>üldistus</emphasis
> määrab, et kasutusklass pärib eellasest kasutusklassi omadused ja võib mõnesid omadusi üle kirjeldada või lisada uusi sarnaselt klassidevahelise pärilusega </para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="actor">
<title
>Tegija</title>
<para
>Tegija on väline olem (süsteemiväline), mis suhtleb süsteemiga, võttes osa (ja sageli algatades) kasutusklassist. Tegijad võivad olla reaalsed inimesed (näiteks infosüsteemi kasutajad), teised arvutisüsteemid või välised sündmused. </para>
<para
>Tegijad ei esinda mitte <emphasis
>füüsilisi</emphasis
> isikuid või süsteeme vaid nende <emphasis
>rolle</emphasis
>. See tähendab, et kui isik suhtleb süsteemiga erinevatel viisidel (eeldades erinevaid rolle), siis kujutatakse teda erinevate tegijatena. Näiteks isikut, kes tegeleb telefoni kaudu kasutajatoeteenuse jagamisega ja võtab klientidelt ka süsteemi kasutamiseks tellimusi, peaks kujutama tegijatena <quote
>Kasutajatugi</quote
> ja <quote
>Müügimees</quote
>. </para>
</sect3>
<sect3 id="use-case-description">
<title
>Kasutusklassi kirjeldus</title>
<para
>Kasutusklassi kirjeldused on kasutusklassi tekstilised narratiivid. Kujutatakse tavaliselt märkustena või dokumentidena, mis on kuidagi lingitud kasutusklassi külge ja selgitavad kasutusklassis toimuvaid protsesse või tegevusi. </para>
</sect3>
</sect2
> <!-- use-case-diagram -->

<sect2 id="class-diagram">
<title
>Klassiskeem</title>
<para
>Klassiskeemid kujutavad süsteemi moodustavaid klasse ja nendevahelisi suhteid. Öeldakse, et klassiskeemid on <quote
>staatilised</quote
> skeemid, sest nad kujutavad klasse, nende meetodeid ja atribuute ning nendevahelisi suhteid: millised klassid <quote
>teavad</quote
> millistest klassidest või millised klassid <quote
>on teiste klasside osadeks</quote
>, kuid ei kujuta meetodite väljakutseid nende vahel. </para>
<para>
<screenshot>
<screeninfo
>Klassiskeemi näidis</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/class-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Klassiskeemi kuvamine Umbrellos</phrase>
	  </textobject>
	  <caption>
	    <para
>Umbrello kuvab klassiskeemi </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="class">
<title
>Klass</title>
<para
>Klass defineerib objektide hulga atribuudid ja meetodid. Kõik klassi objektid (klassi eksemplarid) jagavad ühist käitumist ja omavad samasugust hulka atribuute (igal objektil on isiklikud atribuudid). Vahel kasutatakse klassi asemel terminit <quote
>tüüp</quote
>, kuid tähtis on märkida, et need kaks ei ole samad ja tüüp on üldisem termin. </para>
<para
>&UML;is kujutatakse klasse nelinurkadena, millel klassi nimi ja mis võivad sisaldada ka klassi atribuutide ja operatsioonide nimesid nelinurga kahes eraldi osas. </para>
<para>
<screenshot>
<screeninfo
>Klass &UML;is</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/class.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Klassi visuaalne esitus &UML;is</phrase>
	  </textobject>
	  <caption>
	    <para
>Klassi visuaalne esitus &UML;is </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect4 id="attribute">
<title
>Atribuudid</title>
<para
>&UML;is kuvatakse vähemalt atribuudi nimi ja võibolla ka selle tüüp, algväärtus ja muud omadused. Lisaks on võimalik kuvada atribuudi nähtavust: </para>
<itemizedlist>
<listitem
><para
><literal
>+</literal
> tähistab <emphasis
>public</emphasis
> atribuuti</para
></listitem>
<listitem
><para
><literal
>#</literal
> tähistab <emphasis
>protected</emphasis
> atribuuti</para
></listitem>
<listitem
><para
><literal
>-</literal
> tähistab <emphasis
>private</emphasis
> atribuuti</para
></listitem>
</itemizedlist>
</sect4>
<sect4 id="operation">
<title
>Operatsioonid</title>
<para
>Operatsioonide (meetodite) puhul kuvatakse samuti vähemalt nime ja võibolla ka parameetreid ja tagastustüüpi. Nagu atribuutide puhulgi, saab ka operatsioonide juures näidata nende nähtavust: <itemizedlist>
<listitem
><para
><literal
>+</literal
> tähistab <emphasis
>public</emphasis
> operatsiooni</para
></listitem>
<listitem
><para
><literal
>#</literal
> tähistab <emphasis
>protected</emphasis
> operatsiooni</para
></listitem>
<listitem
><para
><literal
>-</literal
> tähistab <emphasis
>private</emphasis
> operatsiooni</para
></listitem>
</itemizedlist>
</para>
</sect4>

<sect4 id="templates">
<title
>Mallid</title>
<para
>Klassid võivad omada malle, väärtusi, mida kasutatakse määramata klasside või tüüpide asemel. Malli tüüp määratakse alles siis, kui klass algväärtustatakse (st luuakse objekt). Mallid on olemas kaasaegses C++'s ja need hakkavad olema ka Java 1.5's, kus neid kutsutakse geneerikuteks. </para>
</sect4>
</sect3>

<sect3 id="class-associations">
<title
>Klassi sidemed</title>
<para
>Klassid võivad olla omavahel seotud mitmel moel:</para>
<sect4 id="generalization">
<title
>Üldistus</title>
<para
>Pärilus on üks objektorienteeritud programmeerimise baaskontseptsioone, kus klass <quote
>saab</quote
> kõik atribuudid ja operatsioonid kaasa sellelt eellasklassilt, millest pärineb ning tohib neid üle kirjeldada ja muuta, aga ka lisada uusi atribuute ja operatsioone juurde.</para>
<para
>In &UML;, a <emphasis
>Generalization</emphasis
> association between two classes puts them in a hierarchy representing the concept of inheritance of a derived class from a base class. In &UML;, Generalizations are represented by a line connecting the two classes, with an arrow on the side of the base class. <screenshot>
<screeninfo
>Üldistus</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/generalization.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visual representation of a generalization in &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Visual representation of a generalization in &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="uml-associations">
<title
>Sidemed</title>
<para
>An association represents a relationship between classes, and gives the common semantics and structure for many types of <quote
>connections</quote
> between objects.</para>
<para
>Associations are the mechanism that allows objects to communicate to each other. It describes the connection between different classes (the connection between the actual objects is called object connection, or <emphasis
>link</emphasis
>. </para>
<para
>Associations can have a role that specifies the purpose of the association and can be uni- or bidirectional (indicates if the two objects participating in the relationship can send messages to the other, of if only one of them knows about the other). Each end of the association also has a multiplicity value, which dictates how many objects on this side of the association can relate to one object on the other side. </para>
<para
>In &UML;, associations are represented as lines connecting the classes participating in the relationship, and can also show the role and the multiplicity of each of the participants. Multiplicity is displayed as a range [min..max] of non-negative values, with a star (<literal
>*</literal
>) on the maximum side representing infinite. <screenshot>
<screeninfo
>&UML; side</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/association.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visual representation of an Association in &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Visual representation of an Association in &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>

<sect4 id="aggregation">
<title
>Agregatsioon</title>
<para
>Aggregations are a special type of associations in which the two participating classes don't have an equal status, but make a <quote
>whole-part</quote
> relationship. An Aggregation describes how the class that takes the role of the whole, is composed (has) of other classes, which take the role of the parts. For Aggregations, the class acting as the whole always has a multiplicity of one. </para>
<para
>In &UML;, Aggregations are represented by an association that shows a rhomb on the side of the whole. <screenshot>
<screeninfo
>Agregatsioon</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/aggregation.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visual representation of an Aggregation relationship in &UML;</phrase>
	  </textobject>
	  <caption>
	    <para
>Visual representation of an Aggregation relationship in &UML; </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
</sect4>
<sect4 id="composition">
<title
>Kompositsioon</title>
<para
>Compositions are associations that represent <emphasis
>very strong</emphasis
> aggregations. This means, Compositions form whole-part relationships as well, but the relationship is so strong that the parts cannot exist on its own. They exist only inside the whole, and if the whole is destroyed the parts die too.</para>
<para
>In &UML;, Compositions are represented by a solid rhomb on the side of the whole. </para>
<para
><screenshot>
<screeninfo
>Kompositsioon</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/composition.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>Visual representation of a Composition relationship in &UML;</phrase>
	  </textobject>
	</mediaobject>
</screenshot
></para>
</sect4>
</sect3
> <!--class-associations-->

<sect3 id="other-class-diagram-items">
<title
>Teised klassiskeemi elemendid</title>
<para
>Class diagrams can contain several other items besides classes.</para>
<sect4 id="interfaces">
<title
>Liidesed (interfaces)</title>
<para
>Interfaces are abstract classes which means instances can not be directly created of them. They can contain operations but no attributes. Classes can inherit from interfaces (through a realisation association) and instances can then be made of these diagrams.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="datatype">
<title
>Andmetüübid (datatypes)</title>
<para
>Datatypes are primitives which are typically built into a programming language. Common examples include integers and booleans. They can not have relationships to classes but classes can have relationships to them.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="enum">
<title
>Väärtustikud (enums)</title>
<para
>Enums are a simple list of values. A typical example is an enum for days of the week. Like datatypes they can not have relationships to classes but classes can have relationships to them.</para>
<!-- FIXME screenshot -->
</sect4>
<sect4 id="package">
<title
>Paketid (packages)</title>
<para
>Packages represent a namespace in a programming language. In a diagram they are used to represent parts of a system which contain more than one class, maybe hundereds of classes.</para>
<!-- FIXME screenshot -->
</sect4>
</sect3>

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

<sect2 id="sequence-diagram">
<title
>Järgnevusskeemid</title>

<para
>Sequence Diagrams show the message exchange (&ie; method call) between several Objects in a specific time-delimited situation. Objects are instances of classes. Sequence Diagrams put special emphasis in the order and the times in which the messages to the objects are sent.</para>

<para
>In Sequence Diagrams objects are represented through vertical dashed lines, with the name of the Object on the top. The time axis is also vertical, increasing downwards, so that messages are sent from one Object to another in the form of arrows with the operation and parameters name. </para>

<!-- FIXME update screenshot to show synchronous messages -->
<screenshot>
<screeninfo
>Järgnevusskeem</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/sequence-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; showing a Sequence Diagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; showing a Sequence Diagram </para>
	  </caption>
	</mediaobject>
</screenshot>

<para
>Messages can be either synchronous, the normal type of message call where control is passed to the called object until that method has finished running, or asynchronous where control is passed back directly to the calling object. Synchronous messages have a vertical box on the side of the called object to show the flow of program control.</para>
</sect2
> <!-- sequence diagrams -->

<sect2 id="collaboration-diagram">
<title
>Koostööskeemid</title>

<para
>Collaboration Diagrams show the interactions occurring between the objects participating in a specific situation. This is more or less the same information shown by Sequence Diagrams but there the emphasis is put on how the interactions occur in time while the Collaboration Diagrams put the relationships between the objects and their topology in the foreground.</para>

<para
>In Collaboration Diagrams messages sent from one object to another are represented by arrows, showing the message name, parameters, and the sequence of the message. Collaboration Diagrams are specially well suited to showing a specific program flow or situation and are one of the best diagram types to quickly demonstrate or explain one process in the program logic. </para>

<screenshot>
<screeninfo
>Koostöö</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/collaboration-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; showing a Collaboration Diagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; showing a Collaboration Diagram </para>
	  </caption>
	</mediaobject>
</screenshot>

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

<sect2 id="state-diagram">
<title
>Olekuskeem</title>
<para
>State Diagrams show the different states of an Object during its life, and the stimuli that cause the Object to change its state. </para
>                              
<para
>State Diagrams view Objects as <emphasis
>state machines</emphasis
> or finite automates that can be in one of a set of finite states and that can change its state via one of a finite set of stimuli. For example an Object of type <emphasis
>NetServer</emphasis
> can be in one of following states during its life: </para>
<itemizedlist>
<listitem
><para
>valmis</para
></listitem>
<listitem
><para
>kuulamine</para
></listitem>
<listitem
><para
>töötamine</para
></listitem>
<listitem
><para
>peatatud</para
></listitem>
</itemizedlist>
<para
>and the events that can cause the Object to change states are</para>
<itemizedlist>
<listitem
><para
>Object is created</para
></listitem>
<listitem
><para
>Object receives message listen</para
></listitem>
<listitem
><para
>A Client requests a connection over the network</para
></listitem>
<listitem
><para
>A Client terminates a request</para
></listitem>
<listitem
><para
>The request is executed and terminated</para
></listitem>
<listitem
><para
>Object receives message stop</para
></listitem>
<listitem
><para
>jne</para
></listitem>
</itemizedlist>
<para>
<screenshot>
<screeninfo
>Olekuskeem</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/state-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; showing a State Diagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; showing a State Diagram </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<sect3 id="state">
<title
>Olek</title>
<para
>States are the building block of State Diagrams. A State belongs to exactly one class and represents a summary of the values the attributes of a class can take. A &UML; State describes the internal state of an object of one particular class </para
>                       
<para
>Note that not every change in one of the attributes of an object should be represented by a State but only those changes that can significantly affect the workings of the object</para>
<para
>There are two special types of States: Start and End. They are special in that there is no event that can cause an Object to return to its Start state, in the same way as there is no event that can possible take an Object out of its End state once it has reached it. </para>
</sect3>

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

<sect2 id="activity-diagram">
<title
>Tegevusskeem</title>
<para
>Activity Diagrams describe the sequence of activities in a system with the help of Activities. Activity Diagrams are a special form of State Diagrams, that only (or mostly) contains Activities. </para>
<para>
<screenshot>
<screeninfo
>Tegevusskeemi näidis.</screeninfo>
	<mediaobject>
	  <imageobject>
	    <imagedata fileref="pics/activity-diagram.png" format="PNG"/>
	  </imageobject>
	  <textobject>
	    <phrase
>&umbrello; showing an Activity Diagram</phrase>
	  </textobject>
	  <caption>
	    <para
>&umbrello; showing an Activity Diagram </para>
	  </caption>
	</mediaobject>
</screenshot>
</para>
<para
>Activity Diagrams are similar to procedural Flux Diagrams, with the difference that all Activities are clearly attached to Objects.</para>

<para
>Activity Diagrams are always associated to a <emphasis
>Class</emphasis
>, an <emphasis
>Operation</emphasis
> or a <emphasis
>Use Case</emphasis
>.</para>

<para
>Activity Diagrams support sequential as well as parallel Activities. Parallel execution is represented via Fork/Wait icons, and for the Activities running in parallel, it is not important the order in which they are carried out (they can be executed at the same time or one after the other)</para>
<sect3 id="activity">
<title
>Tegevus</title>
<para
>An Activity is a single step in a process. One Activity is one state in the system with internal activity and, at least, one outgoing transition. Activities can also have more than one outgoing transition if they have different conditions. </para
> 
<para
>Activities can form hierarchies, this means that an Activity can be composed of several <quote
>detail</quote
> Activities, in which case the incoming and outgoing transitions should match the incoming and outgoing transitions of the detail diagram. </para>

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

<sect2 id="helper-elements">
<title
>Abielemendid</title>
<para
>There are a few elements in &UML; that have no real semantic value for the model, but help to clarify parts of the diagram. These elements are </para>
<itemizedlist>
<listitem
><para
>Text lines</para
></listitem>
<listitem
><para
>Text Notes and anchors</para
></listitem>
<listitem
><para
>Kastid</para
></listitem>
</itemizedlist
>   
<para
>Text lines are useful to add short text information to a diagram. It is free-standing text and has no meaning to the Model itself. </para
>           
<para
>Notes are useful to add more detailed information about an object or a specific situation. They have the great advantage that notes can be anchored to &UML; Elements to show that the note <quote
>belongs</quote
> to a specific object or situation </para
>    
<para
>Boxes are free-standing rectangles which can be used to group items together to make diagrams more readable. They have no logical meaning in the model.</para>

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

<sect2 id="component-diagram">
<title
>Komponentskeemid</title>
<para
>Component Diagrams show the software components (either component technologies such as KParts, CORBA components or Java Beans or just sections of the system which are clearly distinguishable) and the artifacts they are made out of such as source code files, programming libraries or relational database tables.</para>

<para
>Components can have interfaces (&ie; abstract classes with operations) that allow associations between components.</para>
</sect2>

<sect2 id="deployment-diagram">
<title
>Evitusskeemid</title>

<para
>Deployment diagrams show the runtime component instances and their associations. They include Nodes which are physical resources, typically a single computer. They also show interfaces and objects (class instances).</para>

</sect2>

</sect1
> 
</chapter>
