\section{K�ytt�tapausmalli}

Ohjelmisto tarjoaa k�ytt�jilleen palveluita, jotka perustuvat j�rjestelm�n tietosis�lt��n. Ohjelmiston toiminta voidaan kuvata m��rittelem�ll� millaisia palveluita ohjelmisto tarjoaa. {\em K�ytt�tapausmalli} (engl. use case model) kuvaa ohjelmiston toimintaa k�ytt�j�n kannalta tarkasteltuna. 

K�ytt�j� voi olla henkil�, toinen j�rjestelm�, laite, yms. taho, joka on j�rjestelm�n ulkopuolella, mutta kuitenkin tekemisiss� sen kanssa. T�llainen taho voi toimia

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item tiedon tuottajana j�rjestelm��n tai
\item tiedon hy�dynt�j�
\end{itemize}

K�ytt�j�n asemasta k�ytet��n joskus termi� {\em sidosryhm�} (engl. stake holder). K�ytt�j� voi olla j�rjestelm�n kanssa tekemisiss� suoraan tai ep�suorasti. 

K�ytt�jien tunnistaminen on ensimm�inen teht�v� j�rjestelm�n palveluja m��ritelt�ess�. K�ytt�jien l�yt�miseksi voidaan esitt�� kysymykset:
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item kuka / mik� saa tulosteita j�rjestelm�st�?
\item kuka / mik� toimittaa tietoa j�rjestelm��n?
\item kuka k�ytt�� j�rjestelm��?
\item mihin muihin j�rjestelmiin kehitett�v� j�rjestelm� on yhteydess�?
\end{itemize}
N�iden kysymysten perusteella tunnistetaan {\em roolit}, joissa eri tahot toimivat suhteessa j�rjestelm��n. N�m� roolit m��ritell��n k�ytt�jiksi.

Esimerkiksi tietojenk�sittelytieteen laitoksen ilmoittautumisj�rjestelm�n k�ytt�j�rooleja ovat 
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item opiskelija
\item opettaja
\item opetushallinto
\item suunnittelija
\item laitoksen johtoryhm�
\item tilahallintoj�rjestelm�
\item henkil�st�hallintoj�rjestelm�
\end{itemize}

Yll� olevista k�ytt�j�rooleista laitoksen johtoryhm� ei ole suorassa yhteydess� j�rjestelm��n. Tilahallintoj�rjestelm� ja henkil�st�hallintaj�rjestelm� ovat erillisi� j�rjestelmi�, joiden palveluita laitoksen opetustietoj�rjestelm� hy�dynt��. 

{\em K�ytt�tapauksella} (engl. use case) mallinnetaan k�ytt�j�n ohjelmiston avulla suorittamaa teht�v�� eli {\em tapaa k�ytt�� ohjelmistoa}. Luonteva tapa henkil�k�ytt�jien yhteydess� on kytke� k�ytt�tapaukset k�ytt�j�n ty�teht�viin. T�ll�in ohjelmiston tarjoama palvelu tukee k�ytt�j�� h�nen ty�teht�v�ss��n. K�ytt�tapauksen laajuus on keskeinen tekij� mallin ymm�rrett�vyyden ja hallittavuuden kannalta. K�ytt�tapaukset eiv�t saisi m��ritell� liian laajoja eiv�tk� my�sk��n liian suppeita teht�v�kokonaisuuksia.  Keskikokoisissa ohjelmistohankkeissa k�ytt�tapauksia on tyypillisesti muutamia kymmeni� ja isommissa hankkeissa jopa satoja.

P��periaatteena k�ytt�tapauksia m��ritelt�ess� on, ett� yhden k�ytt�tapauksen tulisi muodostaa looginen  kokonaisuus,  jolla on sek� selv� {\em l�ht�kohta} ett� {\em merkityksen omaava lopputulos}. L�ht�kohtana eli her�tteen� on tapahtuma tai tarve, joka k�ynnist�� k�ytt�tapauksen. Tapahtuma voi olla joko k�ytt�j�n itsens�, jonkin ulkopuolisen tekij�n tai j�rjestelm�n aiheuttama. Se voi olla my�s ajan kulumisesta aiheutuva.
 
Kuvassa \ref{fig:usecase1} on hahmoteltu opetukseen ilmoittautumisista vastaavan j�rjestelm�n k�ytt�tapauksia. Opiskelijan k�ytt�tapauksia ovat {\em ilmoittautuminen, peruutus} ja {\em tarjonnan selvitys}.  Tarjonnan selvitys k�ytt�tapauksen l�ht�kohtana on opiskelijan tarve saada tietoa tarjottavasta opetuksesta luennoista ja harjoituksista. Lopputuloksena opiskelija saa tarvitsemansa tiedot.  Ilmoittautuminen k�ytt�tapauksen l�ht�kohtana on opiskelijan tarve saada opiskelupaikka kurssilta. Lopputuloksena opiskelija kirjataan kurssin osallistujaksi. Peruutus k�ytt�tapauksen l�ht�kohtana on tarve p��st� pois kurssilta. Lopputuloksena on tilanne, jossa opiskelija ei ole en�� kirjattu kurssin osallistujaksi. 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=120mm]{usecase1}
    \caption{Ilmoittautumisj�rjestelm�n k�ytt�tapauksia}
    \label{fig:usecase1} 
\end{figure}

On huomionarvoista ett� tietty taho voi toimia j�rjestelm�n suhteen useammassa erilaisessa k�ytt�j�roolissa. Esim. laitoksella laskareita pit�v� viel� itsekin opiskeleva sivutoiminen opettaja voi toimia 
ilmoittautumisj�rjestelm�� k�ytt�ess��n v�lill� opettajan roolissa ja v�lill� taas opiskelijan roolissa. 

Termi� k�ytt�tapaus k�ytet��n yleisesti sek� tyyppitason k�sitteen� ett� ilmentym�tason k�sitteen�. T�ss� yhteydess� noudatetaan UML:n k�yt�nt�� ja k�ytt�tapaus n�hd��n teht�v�tyyppin�. Tietyll� tyypill� on yleens� useita ilmentymi� eli esimerkkiskenarioita. K�ytt�tapauksen ilmoittautuminen esimerkkiskenariona voisi olla tapaus {\em Kalle Kenkkunen ilmoittautuu kurssin Ohjelmistojen mallintaminen harjoitusryhm��n 2 syksylle 2009}.

K�ytt�tapauksella on {\em k�ytt�j�} (engl. actor), joka k�ytt�tapauksessa toimii vuorovaikutteisesti j�rjestelm�n (ohjelmiston) kanssa toteuttaakseen tavoitteensa. K�ytt�j�n toiminta on sy�tteiden antamista ja palautteen saamista. Usein k�ytt�j� on ihminen, mutta k�ytt�j� voi olla my�s ulkoinen j�rjestelm�. K�ytt�tapaukseen liittyy aina {\em tavoite eli asia, jonka k�ytt�j� haluaa saada aikaan k�ytt�tapauksen avulla.}  Kuvan \ref{fig:usecase1} opiskelijan k�ytt�tapausten tavoitteena on kussakin tapauksessa saada l�ht�kohtana mainittu tarve tyydytetty�. Yhdell� k�ytt�tapauksella voi olla my�s useita k�ytt�ji�.

K�ytt�tapausta kuvattaessa kuvataan k�ytt�j�n ja j�rjestelm�n v�linen vuoropuhelu. Kun k�ytt�tapausmallia k�ytet��n m��rittelyvaiheessa ja vaatimusanalyysin apuv�lineen� kuvauksessa tulisi esitt�� vain vuoropuhelun {\em sis�lt�}, mit� k�ytt�tapauksessa tapahtuu ja mist� asioista k�ytt�j� ja j�rjestelm� vaihtavat tietoa. K�ytt�liittym�� {\em ei t�ss� vaiheessa viel� kiinnitet�}, joskin joitain periaatteita saattaa olla tarpeen hahmotella, jotta k�ytt�j�t ymm�rt�isiv�t, mist� on kyse. Miten vuorovaikutus k�yt�nn�ss� tapahtuu, tulisi kiinnitt�� vasta suunnitteluvaiheessa. K�ytt�tapauksesta voidaan t�ll�in laatia yksityiskohtaisempi suunnittelutason kuvaus. 

K�ytt�tapaus kuvataan esitt�m�ll� vuoropuhelun {\em peruskulku}. Mahdolliset k�ytt�tapauksen kulkua muuttavat poikkeustilanteet voidaan m��ritell� erillisin� poikkeavina kulkuina tai k�ytt�tapausta t�ydent�vin� k�ytt�tapauksina. K�ytt�tapaukseen voi liitty� vaatimuksia koskien suojausta, vasteaikoja, yms.

K�ytt�tapauksen kuvaamiseen ei ole mit��n formaalia tekniikkaa, vaan tapaukset kuvataan luonnollisen kielen tekstin�. Vaikka mit��n standardoitua tapaa kuvata k�ytt�tapauksia ei ole olemassa, jokaisessa ohjelmistoprojektissa kannattaa kuitenkin sopia yhteinen tapa, miten k�ytt�tapaukset kuvataan.
%Vuorovaikutuksen kuvauksen lis�ksi k�ytt�tapauksen kuvaukseen voidaan liitt�� s��nt�j�, ajoitus- ja lukum��r�tietoa.

\subsection{Esimerkkej�}

Seuraavassa esimerkkej� ilmoittautumisj�rjestelm��n liittyen. \\

{\bf Kurssille Ilmoittautuminen}

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item {\em K�ytt�j�:} opiskelija
\item {\em Tavoite:} saada kurssipaikka
\item {\em Laukaisija:} opiskelijan tarve
\item {\em K�ytt�tapauksen kulku:}
Opiskelija tutkii kurssitarjontaa ja valitsee ohjelmiston esitt�m�st� tarjonnasta kurssin ja ryhm�n, tunnistautuu ja aktivoi ilmoittautumistoiminnon. Opiskelija saa kuittauksen ilmoittautumisen onnistumisesta.
\item {\em Poikkeuksellinen toiminta:} Opiskelija ei voi ilmoittautua t�ynn� olevaan ryhm��n. Opiskelija ei voi ilmoittautua, jos h�nelle on kirjattu osallistumiseste.
\item {\em Lis�huomioita: } 4 ruuhkahuippua vuodessa, noin 400 ilmoittautumista ensimm�isen 10 minuutin aikana ilmoittautumisen alkamisesta. Muulloin tapahtumia on v�h�n 
\item {\em Esimerkkitapaus:} NN ilmoittautuu kurssin XML-metakieli / kev�t 2010  harjoitusryhm��n 3.
\end{itemize}


\newpage
{\bf Ilmoittautumisen peruminen}

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item {\em K�ytt�j�:} opiskelija
\item {\em Tavoite:} perua ilmoittautuminen, v�ltt�� sanktiot
\item {\em K�ytt�tapauksen kulku:} Opiskelija tunnistautuu  ja valitsee j�rjestelm�n n�ytt�mist� omista ilmoittautumisistaan peruttavan kohteen sek� aktivoi peruutustoiminnon. J�rjestelm� ilmoittaa operaation onnistumisesta.
\item  {\em Esimerkkitapaus:} NN peruu ilmoittautumisensa kurssin XML-metakieli / kev�t 2010  harjoitusryhm��n 3.
\end{itemize}

Edellisiss� esimerkeiss� k�ytt�tapauksen kulku on kuvattu melko abstraktilla tasolla, kiinnitt�m�tt� k�ytt�j�n ja j�rjestelm�n v�list� interaktiota tarkemmin. N�in toimitaan usein j�rjestelm�n m��rittelyn alkuvaiheissa, jotta haluttua toiminnallisuutta ei tule kiinnitetty� liian tarkasti turhain aikaisessa vaiheessa.

%Kun toimintaa kuvataan, niin kuvaus laittaa tapahtumat johonkin j�rjestykseen. T�m� saattaa muodostua ongelmaksi, jos k�ytt�tapauksen kuvauksen katsotaan olevan vaatimus siit�, miten toiminnan pit�isi edet�. J�rjestelm�n pit�� t�ll�in toteuttaa k�ytt�tapauskuvauksen mukaisessa j�rjestyksess�, vaikka jokin toinen j�rjestys olisi parempi. Abstrakti kuvaus, joka j�tt�� suunnittelijoille liikkumatilaa, onkin joissain tapauksissa parempi suunnittelun l�ht�kohta. %Konkreettinen tapahtumien j�rjestyksen huomioiva kuvaus taas sopii esimerkiksi k�ytt�ohjeeseen tai kuvaamaan valmista ratkaisua.

Edetess� j�rjestelm�n vaatimuksien kartoittamisesta kohti suunnitteluvaihetta, halutaan k�ytt�tapauksessa usein tuoda esiin tapahtumien kulku tarkemmalla tasolla. T�ll�in tapahtumien kulku on tapana esitt�� numeroituna dialogina k�ytt�j�n ja j�rjestelm�n v�lill�. Joskus k�ytt�tapauksille on my�s tapana m��ritell� {\em esiehto} (engl. precondition) ja {\em j�lkiehto} (engl. postcondition).
Esiehto kuvaa asioiden tilan, jonka oletetaan olevan voimassa k�ytt�tapauksen alussa. J�lkiehto taas kuvaa asioiden tilan, mink� oletetaan olevan voimassa k�ytt�tapauksen onnistuneen l�pik�ymisen j�lkeen.

Seuraavassa  {\em Kurssille ilmoittautuminen} -k�yt\-t�\-ta\-paus, jossa tapahtumien kulku ja j�rjestys on tuotu tarkemmin esiin. T�ll� kertaa my�s k�ytt�tapauksen esi- ja j�lkiehdot on ilmaistu. 

{\bf Kurssille Ilmoittautuminen, tarkennus}

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item {\em K�ytt�j�:} opiskelija
\item {\em Tavoite:} saada kurssipaikka
\item {\em Laukaisija:} opiskelijan tarve
\item {\em Esiehto:} opiskelija on ilmoittautunut kuluvalla lukukaudella l�sn�olevaksi
\item {\em J�lkiehto:} opiskelija on lis�tty haluamansa ryhm�n ilmoittautujien listalle
\item {\em K�ytt�tapauksen kulku:}
\begin{enumerate} %\addtolength{\itemsep}{-0.5\baselineskip}
\item
Opiskelija aloittaa kurssi-ilmoittautumistoiminnon
\item
J�rjestelm� n�ytt�� kurssitarjonnan
\item
Opiskelija tutkii kurssitarjontaa 
\item
Opiskeljia valitsee ohjelmiston esitt�m�st� tarjonnasta kurssin ja ryhm�n
\item
J�rjestelm� pyyt�� opiskelijaa tunnistautumaan
\item
Opiskelija tunnistautuu ja aktivoi ilmoittautumistoiminnon
\item
J�rjestelm� ilmoittaa opiskelijalle ilmoittautumisen onnistumisesta.
\end{enumerate}
\item {\em Poikkeuksellinen toiminta:} Opiskelija ei voi ilmoittautua t�ynn� olevaan ryhm��n. Opiskelija ei voi ilmoittautua, jos h�nelle on kirjattu osallistumiseste.
\end{itemize}

N�in dokumentoituna k�ytt�tapaus kiinnitt�� jo useita asioita esim. k�ytt�liittym�n suhteen. Kyseess� onkin aiempaa versiota konkreettisempi k�ytt�tapaus. 

\subsection{Yleistykset, sis�llytykset ja laajennokset}

Laajoissa j�rjestelmiss� voidaan l�hte� liikkeelle k�ytt�jien ty�teht�viin perustuvista k�ytt�tapauksista. K�ytt�tapauksia analysoitaessa niist� saatetaan l�yt�� yhteisi� osia, jotka voidaan erottaa omiksi k�ytt�tapauksiksi. My�s erilaiset virhe- ja poikkeustilanteet sek� vaihtoehtoiset kulut k�ytt�tapauksessa voidaan erottaa omiksi erillisiksi k�ytt�tapauksiksi. N�in syntyy riippuvuuksia k�ytt�tapausten v�lille. K�ytt�tapauksia voi l�yty� my�s suuria m��ri�. T�ll�in voi yleiskuvan saamiseksi ohjelmiston toiminnosta olla paikallaan koota yhteen k�ytt�tapauksia ja esitt�� ne yhten� {\em yleistettyn�} (eng. generalized) tapauksena. 

Kuvassa \ref{fig:usecase1} esitetyist� k�ytt�tapauksista suunnittelijan k�ytt�tapaukset ovat yleistettyj� k�ytt�tapauksia. Esimerkiksi opetustarjonnan yll�pito jakautuu useaan erilliseen teht�v��n: uuden kurssin perustaminen, uuden harjoitusryhm�n perustaminen, kurssin poistaminen opetustarjonnasta ja harjoitusryhm�n peruutus. Ilmoittautumisj�rjestelm�ss� suunnittelijan k�ytt�tapaukset muodostavat oman osaj�rjestelm�ns� ja yksitt�iset k�ytt�tapaukset voitaisiin kuvata yksityiskohtaisemmin t�m�n yhteydess�. Osaj�rjestelm�n k�ytt�tapauskaavio on kuvassa \ref{fig:usecase2}. Kuvasta n�emme, ett� erikoistava k�ytt�tapaus, esim. {\em kurssin peruutus} on yhdistetty nuolella\footnote{Huomioi ett� nuolenp��n piirtotapa erikoistamissuhteessa on "avoin kolmio". Kuten kohta huomaamme, on nuolenp�iden piirtotapa m��ritelty UML:ss� tarkasti.} yleist�v��n k�ytt�tapaukseen {\em opetustarjonnan yll�pito}. Suunnittelijan osaj�rjestelm�n mallissa on otettu mukaan my�s muita j�rjestelmi� tilahallintoj�rjestelm� ja henkil�st�hallintoj�rjestelm�, joiden kanssa suunnittelijan k�ytt�m� osaj�rjestelm� toimii yhteisty�ss�.  

\begin{figure}[htbp]
    \centering
    \includegraphics[width=140mm]{usecase2}
    \caption{Suunnittelijan osaj�rjestelm�n k�ytt�tapauskaavio}
    \label{fig:usecase2} 
\end{figure}

Useat ty�teht�v�t muodostuvat sarjasta per�kk�isi� toimintoja. K�ytt�j�n tavoite liittyy t�ll�in usein koko toimintosarjaan eik� yksitt�iseen toimintoon vaikka toiminto toisikin tavoitetta jonkin verran l�hemm�s. K�ytt�tapauksena kannattaa t�ll�in tarkastella koko sarjaa eik� sen askelia. Kun k�ytt�tapauksia analysoidaan, voidaan l�yt�� usealle tapaukselle yhteisi� osia. T�ll�in n�m� voi kuvata omina apuk�ytt�tapauksinaan, vaikka ne olisivat toimintosarjan osan kaltaisia. Esimerkiksi opiskelijan ilmoittautumiseen ja ilmoittautumisen perumiseen liittyy molempiin opiskelijan tunnistautuminen. T�t� varten voidaan m��ritell� k�ytt�tapaukseksi {\em kirjautuminen}. Yhdenk��n opiskelijan ensisijaisena tavoitteena ei liene kirjautua j�rjestelm��n. T�st� syyst� kirjautumista ei voi pit�� p��k�ytt�tapauksena vaan t�ydent�v�n�, p��k�ytt�tapaukseen {\em sis�llytett�v�n�} (engl. include) aputapauksena. Kuvassa \ref{fig:usecase3} k�ytt�tapaukset {\em ilmoittautuminen} ja {\em peruutus} sis�llytt�v�t k�ytt�tapauksen {\em kirjautuminen} toiminnallisuuden. Sis�llytys on merkitty p��k�ytt�tapauksesta apuk�ytt�tapaukseen kohdistuvalla katkoviivalla johon on liitetty {\em stereotyyppi} eli tarkenne {\em <<include>>}. Huomaa taas miten nuolen p�� on piirretty. Se on nyt erilainen kun yleistyksen yhteydess�.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{usecase3}
    \caption{Kirjautuminen apuk�ytt�tapauksena ilmoittautumisen ja perumisen osana}
    \label{fig:usecase3} 
\end{figure}

Kuten aiemmin todettiin, kuvataan k�ytt�tapauksessa toiminnan peruskulku.  Peruskulkunsa mukaisesti esimerkiksi ilmoittautuminen onnistuu aina. K�yt�nn�ss� n�in ei kuitenkaan v�ltt�m�tt� ole. Ilmoittautumiseen liittyy s��nt�j�, jotka saattavat est�� kurssille p��syn. T�llaiset poikkeustapaukset voidaan kuvata k�ytt�tapauksen {\em laajennoksina} (engl. extend). Kuvassa \ref{fig:usecase4} on ilmoittautumisen laajennoksina esitetty poikkeustapaukset {\em ei-ole-tilaa} ja {\em esitietopuute}, jotka kumpikin est�v�t ilmoittautumisen. Laajennoksena {\em kysely} kuvataan tilanne, jossa kurssille p��semiseksi on vastattava kurssikohtaisiin hakukysymyksiin. Laajennos on merkitty laajentavasta k�ytt�tapauksesta p��k�ytt�tapaukseen kohdistuvalla katkoviivalla johon on liitetty stereotyyppi {\em <<extend>>}.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{usecase4}
    \caption{K�ytt�tapauksen poikkeuksia}
    \label{fig:usecase4} 
\end{figure}

Sis�llytyksen ja laajennoksen k�ytt� h�mment�� joskus kokeneitakin k�ytt�tapausten m��rittelij�it�. Ero n�iden k�yt�ss� on siin�, ett� k�ytett�ess� sis�llytyst� apuk�ytt�tapaus liitetaan {\em aina} p��k�ytt�tapaukseen. Eli esimerkiss�mme kirjautuminen suoritetaan aina peruutuksen ja ilmoittautumisen yhteydess�. Laajennos taas liittyy p��k�ytt�tapaukseen vain {\em tarvittaessa}, eli esim. {\em ei-ole-tilaa} -k�ytt�tapaus ilmenee ilmoittautumisen yhteydess� ainoastaan joskus. Huomaa kuvista, ett� nuoli sis�llytyksen ja laajennoksen yhteydess� kulkee eri suuntiin. Sis�llytyksess� nuoli kulkee apuk�ytt�tapaukseen p�in, kun taas laajennoksessa p��k�ytt�tapaukseen p�in.

Useat k�ytt�tapausasiantuntijat (mm. ehk� tunnetuimman k�ytt�tapausoppaan kirjoittaja Alistair Cockburn \cite{cock}) ovat sit� mielt�, ett� sekavuuksien v�ltt�miseksi k�ytt�tapausten laajennusta ei v�ltt�m�tt� kannata k�ytt��, vaan parempi tapa ilmaista esim. poikkeukset on dokumentoida ne k�ytt�tapauksen tekstuaalisen esityksen yhteydess�.

\subsection{Yhteenveto k�ytt�tapauskaavioiden merkinn�ist�}

UML m��rittelee k�ytt�tapausmallille graafisen esitysmuodon. T�t� muotoa on k�ytetty yll� esitetyiss� kuvissa. K�ytt�tapausmallin symbolit on esitetty kootusti kuvassa \ref{fig:usecase5}. Kuvassa on k�ytetty kommentteja sis�lt�vi� UML-elementtej�. Kommentit ovat k�ytett�viss� kaikissa UML:n kaaviotyypeiss�. Poikkeus on valinnainen t�ydent�v� tai muuntava osa jotain laajempaa kokonaisuutta. Itsen�iset tapaukset ovat itsen�isi� perusk�ytt�tapauksia. 

K�ytt�tapauskaavion informaatiosis�lt� on melko v�h�inen. L�hinn� kaavio tarjoaa yleiskuvan j�rjestelm�n k�ytt�jist� ja palveluista. 
%Samat asiat voidaan esitt�� esimerkiksi taulukkomuodossa tai ryhmiteltyn� luettelona. 
K�ytt�tapauskaaviosta on enemm�n hy�ty� l�hinn� silloin kun on esitett�v� k�ytt�tapausten v�lisi� riippuvuuksia (poikkeuksia ja osia). On kuitenkin t�rke� muistaa, ett� {\em k�ytt�tapausmallin merkitt�vin osa on kunkin k�ytt�tapauksen sis�ll�n m��rittelev� sanallinen kuvaus.}

\begin{figure}[htbp]
    \centering
    \includegraphics[width=130mm]{usecase5}
    \caption{UML:n k�ytt�tapausmallin graafisen esityksen symbolit}
    \label{fig:usecase5} 
\end{figure}

K�ytt�tapausmalli sopii hyvin vuorovaikutteisten ohjelmistojen kuvaamiseen. Tekstikuvauksen tarkkuustason valinta on usein hankalaa. Malli ei sovellu kovin hyvin j�rjestelmien v�lisen yhteisty�n kuvaamiseen. Ulkopuolinen j�rjestelm� n�hd��n k�ytt�j�n� ja yhteisty�t� pit�isi kuvata k�ytt�j�n kannalta vaikka luonnollisemmalta tuntuisi pit�� kehitett�v�� j�rjestelm�� t�llaisessa tilanteessa k�ytt�j�n�.  

K�yt�nn�ss� k�ytt�tapauksia kannattaa ryhmitell� joko k�ytt�m�ll� yleistettyj� k�ytt�tapauksia tai UML-tekniikkaan sis�ltyvi� pakkauksia, joita k�sitell��n luvussa \ref{sec:osa4}. Ryhmittely voi tapahtuen perustuen k�ytt�tapausten k�ytt�jiin (esim. opettajan ja opiskelijan k�ytt�tapaukset erikseen) tai j�rjestelm�n toiminnallisuuteen (esim. ilmoittautumiseen ja kurssien arvosteluun liittyv�t k�ytt�tapaukset erikseen).

\newpage


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%55
%
%
%
%
%
%
%

\section{Luokkakaaviot}

{\em Luokkakaaviolla} (engl. class diagram) kuvataan 
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item ohjelmiston tai j�rjestelm�n rakenne
\item ohjelmiston tietosis�lt�
\item palvelut, joita ohjelmisto ja sen osat kykenev�t suorittamaan sek�
\item ohjelmiston osien  v�liset yhteydet
\end{itemize}
{\em Oliokaaviolla} (engl. object diagram) havainnollistetaan luokkakaaviota, esimerkiksi olioiden v�lisi� yhteyksi�.

Oliopohjaisen l�hestymistavan mukaisesti ohjelmisto voidaan hahmottaa oliona, joka tarjoaa palveluja k�ytt�jille (ks. luku \ref{sec:mallintaminen}). J�rjestelm�tasoisten olioiden palvelut toteutuvat j�rjestelm�n sis�ll� toimivien pienempien olioiden yhteisty�n tuloksena. L�hestymistavan l�ht�kohtana ovat sosiaaliset organisaatiot. Esimerkiksi yrityksen tarjoamat palvelut toteutuvat ty�ntekij�iden palvelujen kautta.  

{\em Oliolla} (engl. object) tarkoitetaan tiedon ja sen k�sittelyyn liittyvien palveluiden muodostamaa kokonaisuutta. 
%Olio on erotettavissa muista olioista.  Sill� on identiteetti. 
Olio pit�� sis�ll��n tietoja, joita olion palvelut k�sittelev�t tai hy�dynt�v�t. Oliota voisi verrata henkil��n. Henkil�ll� on tiet�myksens�, jota ei ulkoap�in tarkastelemalla saa selville. Henkil�n tiet�myst� voi hy�dynt�� vain kysym�ll� tai hy�dynt�m�ll� palveluja, joita henkil� tiet�mykseens� perustuen tarjoaa.

Oliomallintaminen perustuu olioiden luokitteluun. Jokainen olio kuuluu johonkin luokkaan ja on toiminnaltaan ja sis�ll�lt��n luokkakuvauksessa m��ritellyn mallin mukainen. Olioluokka tai lyhyemmin pelkk� {\em luokka} (engl. object class) on siis samankaltaisten olioiden malli. Yksitt�isi� olioita tarkastellaan t�m�n mallin {\em ilmentymin�} (engl. instance).
Kuvassa \ref{fig:olio1} esimerkki luokasta, luokkakuvauksesta ja luokan ilmentym�t reaalimaailmassa. Ohjelmaoliot el�v�t lyhyen el�m�ns� tietokoneen uumenissa. Ne voivat simuloida jotain konkreettista reaalimaailman oliota esimerkiksi palkanlaskijaa, opettajaa, opiskelijaa, kirjaston kirjaa, puhelunv�litt�j��. Alun perin olio k�site esiteltiinkin simuloinnin yhteydess�. Ohjelmistoja tarkasteltaessa t�rm�t��n kuitenkin usein abstrakteihin olioihin, joille ei l�ydy reaalimaailman suoraa vastinetta.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{harriKuvat/olio1}
    \caption{Luokka, luokkakuvaus ja luokan ilmentym�t reaalimaailmassa}
    \label{fig:olio1} 
\end{figure}

Luokkakuvaus esitet��n jollakin kuvaustekniikalla joko graafisesti tai j�senneltyn� tekstiesityksen�. Olio-ohjelmoinnissa luokkakuvaus esitet��n ohjelmointikielell� (ks. kuva \ref{fig:olio2}). T�m� esitys on tarkoitettu tietokoneelle. Lis�ksi tarvitaan ihmisille tarkoitettu kuvaus. Kun j�rjestelmi� toteutettaessa edet��n m��rittelyst� ja suunnittelusta toteutukseen, on luonnollista, ett� ihmisille tarkoitetut kuvaukset eli suunnitelmat tuotetaan ensin ja vasta sitten koneelle tarkoitettu esitys.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{harriKuvat/olio2a}
    \caption{Luokkakuvaus ohjelmointikielell�}
    \label{fig:olio2} 
\end{figure}

\subsection{Luokkakuvaus}

Luokkakuvauksessa nimet��n luokka {\em kuvaavalla nimell�}. Tarvittaessa m��ritell��n tekstikuvauksena luokan merkitys, eli selvitet��n millaisia olioita luokkaan kuuluu. Luokkakuvauksessa m��ritell��n my�s luokan ilmentymiin sis�ltyv�t tiedot ja palvelut (eli operaatiot), joita luokan ilmentym�t kykenev�t suorittamaan tai tarjoamaan. \\

\subsubsection{Tietojen m��rittely}

Luokan ilmentymiin sis�ltyv�t tiedot kuvataan antamalla
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip} 
\item {\em attribuutti} (engl. attribute), joka on tietoa kuvaava nimi
\item {\em arvom��rittely} (engl. value specification), joka esitt�� millaisten arvojen avulla tieto esitet��n ja
\item sanallinen selvitys tiedon merkityksest� ja k�yt�st�.
\end{itemize}

Attribuutin arvona voi olla
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip} 
\item yksinkertainen arvo, esimerkiksi kokonaisluku tai merkkijono
\item rakenteinen arvo, esimerkiksi osoite, joka jakautuu postiosoitteeseen, postinumeroon ja l�hiosoitteeseen
\item kokoelma yksinkertaisia tai rakenteisia arvoja, esimerkiksi j�rjest�m�t�n joukko v�rej� tai j�rjestetty joukko koordinaattipareja 
\item kokoelmia voi olla rakenteeltaan erityyppisi� (taulukko, joukko, j�rjestetty joukko, lista, tiedosto \ldots)
\item Mit� laajempia ja korkeammalla abstraktiotasolla oliot ovat, sit� laajempia ovat my�s niiden tietosis�ll�t. T�ll�in attribuutin arvona voisi tulla kyseeseen tiedosto, tietovirta tai jokin muu laaja tietokokoelma. 
\end{itemize}

Attribuutin arvona voi olla my�s {\em viittaus olioon} tai kokoelma viittauksia olioihin. T�llaista attribuuttia kutsutaan {\em olioarvoiseksi}. Olioarvoisen attribuutin olemassaolo tarkoittaa sit�, ett� on olemassa {\em yhteys} attribuutin sis�lt�v�n olion ja attribuutin arvona olevan olion v�lill�. T�llaiset yhteydet ovat usein hyvin oleellisia j�rjestelm�n oliorakenteen ymm�rt�misen kannalta. Niinp� niiden esitt�miseen on olemassa my�s oma erillinen tekniikkansa, jota tarkastellaan my�hemmin. Sama asia pit�isi aina kuvata vain kertaalleen. Kaavion tavoitteista riippuu mit� tekniikkaa k�ytet��n. Jos yhteydet ovat merkitt�vi� ne esitet��n eksplisiittisesti. Olioarvoisia attribuutteja on kuitenkin syyt� k�ytt��, jos viitattu olio on perustietotyypin kaltainen. T�llaisia voisivat olla p�iv�ys, kellonaika, henkil�tunnus, v�ri, koordinaatti, jne.

Vaikka attribuuttinimen tulisi mahdollisimman hyvin kuvata sit� ilmi�t�, joka attribuuttiin liittyv�ll� arvolla halutaan esitt��, ei nimi yleens� riit� attribuutin m��rittelyksi vaan tarvitaan erillinen selvitys attribuutin merkityksest� ja k�yt�st�. Selvityksess� voidaan k�sitell� arvojen tulkintaa, arvojen tarkkuutta, arvojen mittaamista, yms. Arvojen k�ytt��n ja k�ytt�ytymiseen saattaa my�s liitty� erityispiirteit�, joilla on merkityst� kehitett�v�lle ohjelmistolle. Er�s t�llainen piirre on  {\em attribuutin k�ytt� olioiden ulkoiseen tunnistamiseen}. Olioilla on attribuuttien arvoista riippumaton identiteetti, mutta usein on tarve viitata olioon my�s jonkin siit� tiedetyn ja attribuuttien avulla esitetyn ominaisuuden perusteella, esimerkiksi henkil�-oliot voitaisiin ulkoisesti tunnistaa nimen ja syntym�ajan avulla. 

Attribuutti voi olla {\em kiinte�arvoinen} eli sellainen, jonka arvo s�ilyy samana koko olion elini�n, esimerkiksi henkil�n syntym�aika on t�llainen.  Attribuutti voi my�s olla {\em v�ltt�m�t�n} eli sellainen, jonka arvo ei voi olla tuntematon tai puuttuva. Esimerkiksi henkil�n nimi voisi olla v�ltt�m�t�n henkil�n attribuutti, mutta osoite ei.

UML-luokkakaaviotekniikassa luokka kuvataan suorakaiteena. Se voidaan esitt�� suppeassa muodossa, jolloin suorakaiteen sis��n kirjoitetaan vain luokan nimi, tai laveassa muodossa, jossa suorakaiteen sis�ll� n�kyv�t my�s luokan attribuutit sek� mahdollisesti my�s palvelut (ks. kuva \ref{fig:olio3}). 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{harriKuvat/olio3}
    \caption{Luokkasymboli erilaajuisena}
    \label{fig:olio3} 
\end{figure}

Attribuutista voidaan UML-luokkakaaviossa esitt��
\begin{itemize} %\addtolength{\itemsep}{-0.5\baselineskip} 
\item Nimi (v�ltt�m�t�n)
\item Tietotyyppi

Tietotyyppin� voi k�ytt�� jonkin ohjelmointikielen mukaisia perustietotyyppej� (int, char, double, boolean, string, jne). Tietotyypit voivat olla my�s sovellusalue- tai tapauskohtaisia (rahasumma, prosenttiosuus, nimi, jpg-kuva, mpeg-video, jne). Tyyppej� voi m��ritell� tarpeen mukaan. 
\item Moniarvoisuus (engl. multiplicity)

Kokoelma-arvoisten attribuuttien kohdalla kokoelman koko voidaan ilmoittaa arvojen v�himm�is- ja enimm�ism��rin� hakasulkeissa, esimerkiksi [0..5]  tarkoittaa, ett� kokoelmassa on 0-5 arvoa. T�htimerkki� (*) voidaan k�ytt�� tarkoittamaan {\em monta, mutta t�sm�llist� yl�rajaa ei voida antaa}). Valinnainen attribuutti voidaan kuvata moniarvoisuusm��reell� [0..1]. 
\item N�kyvyys (engl. visibility)

N�kyvyys on er�iss� olio-ohjelmointikieliss�, esimerkiksi Java ja C++, tarjolla oleva tekniikka rajoittaa attribuutin tai palvelun k�ytt��. N�kyvyydell� on merkityst� vain teknisiss� ohjelmointikielitasoisissa kuvauksissa. UML m��rittelee nelj� n�kyvyystasoa:
\begin{itemize}
\item {\em  julkinen} (public, UML:ss� +) attribuutti n�kyy ja on k�ytett�viss� vapaasti luokan ulkopuolelta. 
\item {\em  suojattu} (protected, UML:ss� \#) attribuutti n�kyy ja on k�ytett�viss� vain luokan ja sen aliluokkien ilmentymille.
\item {\em  pakkauksen sis�inen} (package, UML:ss�  $\sim$) attribuutti n�kyy ja on k�ytett�viss� kaikissa samaan pakkaukseen kuuluvissa luokissa, Pakkauksia k�sitell��n my�hemmin.
\item {\em yksityinen} (private, UML:ss� -) attribuutti n�kyy vain saman luokan ilmentymille. On syyt� huomata, ett� yksityinen n�kyvyys ei rajoita n�kyvyytt� olion sis�iseksi vaan pelk�st��n luokan sis�iseksi. 
\end{itemize}
N�kyvyyden m��rittely tulee kyseeseen {\em vain ohjelmointil�heisess� luokkakuvauksessa}. Puhdasoppisen oliol�hestymistavan mukaisesti attribuuttien n�kyvyyden tulisi olla aina v�hint��n tasoa suojattu. 

\item Oletusarvo
\item Muita m��reit�

UML:ss� attribuutin arvot ovat oletusarvoisesti muuttuvia. Ne voidaan kuitenkin m��ritell� kiinte�arvoiseksi m��reell� {\em readonly}. Kokoelma-arvoiseen attribuuttiin voidaan liitt�� m��re {\em ordered} kuvaamaan j�rjestetty� kokoelmaa. Kokoelmaan voidaan liitt�� my�s  m��re {\em unique} kuvaamaan sit�, ett� kokoelman alkiot ovat kesken��n erilaisia. 
\end{itemize}

UML:n attribuuttim��rittelyn rakenne on 
\begin{verse}
[<n�kyvyys>]~<nimi>~[<moniarvoisuus>]~[:<tietotyyppi>]\newline
~~~~[= <oletusarvo>]~[ \{ <muut m��reet> \} ]\footnote{Hakasulut ilmaisevat valinnaisen elementin eli [a] tarkoittaa,  ett� elementti a voi kuulua esitykseen tai puuttua siit�.  Kulmasulut (<>) rajaavat syntaksisen elementin. Attribuutille ainoa v�ltt�m�t�n kuvailutieto on t�ten nimi.}
\end{verse}

Esimerkkej�:
\begin{description}
\item{\bf hetu : Henkil�tunnus \{readonly\}} 

Attribuutin hetu arvo on tyyppi� Henkil�tunnus. Arvo on pysyv�.

\item{\bf suosikkiruoka [*] : String \{ordered\} }

Attribuutin suosikkiruoka arvona on j�rjestetty kokoelma merkkijonoja. ordered on UML:n perusm��re, joka voidaan liitt�� kokoelmiin ja yhteyksiin. Siit� ei n�e mill� perusteella arvot on j�rjestetty, mutta vapaamuotoisessa tekstikuvauksessa voidaan t�sment��, ett� ruoat ovat kokoelmassa suosituimmuusj�rjestyksess�. 
\end{description}

Kuvaesityksess� attribuuteista usein annetaan usein vain nimi. (ks. kuva \ref{fig:olio4}) T�ll�in tarvitaan kuvan t�ydennykseksi tekstimuotoinen m��rittely. Tietokoneavusteisissa suunnitteluv�lineiss� (CASE-v�lineiss�) on yleens� mahdollisuus valita miten paljon yksityiskohtia graafisessa luokkakuvauksessa n�ytet��n. 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=35mm]{harriKuvat/olio4}
    \caption{Asiakas-luokkaa kuvaava kaaviosymboli}
    \label{fig:olio4} 
\end{figure}

Er�iss� ohjelmointikieliss� (esim. Java, C++) on mahdollista m��ritell� luokan ilmentymiin sis�ltyvien tietojen lis�ksi luokkakohtaisia tietoja. UML:ss� luokkakohtaiset tiedot kuvataan alleviivaamalla attribuutin nimi. Kuvassa \ref{fig:olio5} {\em tarkmerkit} on luokkakohtainen kokoelma tarkistusmerkkej�.  \\

\begin{figure}[htbp]
    \centering
    \includegraphics[width=40mm]{harriKuvat/olio5}
    \caption{Luokka- ja ilmentym�kohtaiset attribuutit, luokkakohtainen alleviivattu}
    \label{fig:olio5} 
\end{figure}

\subsubsection{Palvelujen  m��rittely} 

Palvelun m��rittely on  UML:ss� muotoa
\begin{verse}
[<n�kyvyys>]~<nimi>~[(<parametrit>)]~[:<paluuarvon tyyppi>]\newline
[\{<muut m��reet>\}]
\end{verse}

M��rittelyn osat ovat:

\begin{itemize}
\item Nimi

Ainoastaan nimi on v�ltt�m�t�n. Korkean tason abstraktissa kuvauksessa riitt�� yleens� nimi ja palvelun tekstikuvaus.
\item Parametrit

Parametrit kuvaavat palvelupyynt��n liittyvi� sy�tt�- ja tulostietoja, eli palvelun rajapintaa. Ohjelmointikielitasoisessa kuvauksessa ne vastaavat palvelupyynn�n parametrilistaa eli signatuuria. Korkeamman abstraktiotason kuvauksessa parametrit v�litet��n palvelulle mahdollisesti muun mekanismin kautta, esimerkiksi sanomina tai tiedostoina. 

Parametrin m��rittely on muotoa:

[<suunta>] <nimi>: <tyyppi> [= <oletusarvo> ]

Suunta ilmaisee onko kyseess� 

\begin{itemize} %\addtolength{\itemsep}{-0.5\baselineskip} 
\item {\em sy�teparametri (in)}, joka v�litt�� tietoa palvelulle. Jos sy�teparametrina on olio, niin sen tila ei muutu.
\item {\em tulosparametri (out)}, joka v�litt�� tietoa palvelulta sen k�ytt�j�lle. Jos tulosparametrina on olio, sen tila voi muuttua.
\item {\em yhdistetty sy�te- ja tulosparametri (inout)}, joka v�litt�� tietoa kumpaankin suuntaan
\item On huomattava, ett� kaikki ohjelmointikielet eiv�t toteuta parametreja UML-m��reiden mukaisina. Esimerkiksi Javassa ei ole mahdollista m��ritell� olio-muotoista parametria, jonka tila ei voisi muuttua.
\end{itemize}

\item
N�kyvyys
 
Palvelujen n�kyvyys voidaan m��ritell� samoin kuin attribuuttien n�kyvyys. N�kyvyys on ohjelmointikielitason kuvauksen k�sitteit�. Ylemmill� abstraktiotasoilla ollaan tyypillisesti kiinnostuneita vain julkisista palveluista.

\begin{itemize} %\addtolength{\itemsep}{-0.5\baselineskip} 
\item {\em julkinen palvelu} (public, UML:ss� +) on muihin luokkiin kuuluvien olioidenkin pyydett�viss� 

\item {\em suojattu palvelu} (protected, UML:ss� \#) on k�ytett�viss� palveluissa, jotka on m��ritelty samassa luokkakuvauksessa kuin k�ytett�v� palvelu tai t�m�n luokkakuvauksen periviss� kuvauksissa
\item {\em pakkauksen sis�inen} (package, UML:ss� $\sim$) on k�ytett�viss� pakkauksen sis�isesti

\item {\em yksityinen} (private, UML:ss� -) sallii palvelun k�yt�n vain samassa luokkakuvauksessa m��ritellyiss� palveluissa, jossa palvelu on m��ritelty.
\end{itemize}
\item Paluuarvon tyyppi

Paluuarvon typpin� voi olla jokin perustietotyyppi. Paluuarvona voi olla my�s olio, jolloin tyyppin� on olion luokka. UML:n palvelu perustuu palvelun funktiomaiseen tulkintaan, jossa palvelulla voi olla enint��n yksi paluuarvo.  T�m� ei korkeamman tason palveluita tarkasteltaessa ole erityisen onnistunut ratkaisu.

\item 
Muut m��reet

Palveluun voidaan liitt�� muita m��reit�. UML m��rittely sis�lt�� valmiina muutaman samanaikaisuuden hallintaan liittyv�n m��reen.

\end{itemize}

Kuvaesityksess� palvelusta esitet��n usein vain nimi ja mahdollisesti n�kyvyys (ks. kuva \ref{fig:olio6}), muuten kuvasymbolit tulevat liian suuriksi. Joskus on hy�dyllist� ottaa kaavioon mukaan UML-kommentti eli muistilappu, jossa voi kuvata jonkin keskeisen palvelun toimintaperiaatteen (ks. kuva \ref{fig:olio7}). Palvelujen t�sm�lliseen kuvaukseen tarvitaan aina lis�ksi tekstimuotoinen selvitys siit�, mit� palvelussa tehd��n. \\

\begin{figure}[htbp]
    \centering
    \includegraphics[width=40mm]{harriKuvat/olio6}
    \caption{Luokka- ja ilmentym�kohtaiset attribuutit}
    \label{fig:olio6} 
\end{figure}

\begin{figure}[htbp]
    \centering
    \includegraphics[width=90mm]{harriKuvat/olio7}
    \caption{Palvelun t�smennys muistilapulla}
    \label{fig:olio7} 
\end{figure}

\subsubsection{Olioiden kuvaaminen} 

Luokan ilmentym�, olio,  kuvataan UML:ss� samanlaisella symbolilla kuin luokkakin. Erona on se, ett� ilmentym�kuvauksessa luokkanimen tilalla ylimm�ss� lokerossa on ilmentym�viite. T�m�n rakenne on seuraava
\begin{verse}
<tunnus> | [<tunnus>] : <luokkanimi>\footnote{ Pystyyviiva ( | ) erottaa vaihtoehdot.}
\end{verse}
Ilmentym�viite esitet��n alleviivattuna. Ilmentym�viite voisi olla esimerkiksi \underline{Kalle:Henkil�}, \underline{Kalle} tai \underline{:Henkil�}.   

Attribuuttiosassa voidaan antaa attribuutin nimen lis�ksi attribuutin arvo. Arvo annetaan vain niiden attribuuttien osalta, joihin lukijan halutaan kiinnitt�v�n huomiota. Ilmentym�symboleita k�ytet��n esimerkeiss� haluttaessa havainnollistaa luokkakaavion m��rittelem�� rakennetta (ks. kuva \ref{fig:olio8})

\begin{figure}[htbp]
    \centering
    \includegraphics[width=40mm]{harriKuvat/olio8}
    \caption{Asiakasluokan ilmentym�}
    \label{fig:olio8} 
\end{figure}

\subsection{Olioiden v�liset yhteydet}

Olioiden (ilmentymien) v�lisi� rakenteellisia kytkent�j� kutsutaan {\em yhteyksiksi} (engl. association). Yhteys kahden olion v�lill� on olemassa esimerkiksi silloin, kun olio on toisen olion osa. Reaalimaailmassa t�llaisia tilanteita olisivat esimerkiksi
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip} 
\item luku on kirjan osa
\item hytti on laivan osa
\end{itemize}

Olioiden v�lill� voi olla my�s muunlaisia yhteyksi�, esimerkiksi:

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip} 
\item henkil� ty�skentelee yrityksess�
\item opiskelija suorittaa kurssia
\item kirja kuuluu kurssin oppimateriaaliin
\end{itemize}

Yhteyden {\em Kirja kuuluu oppimateriaaliin}  ilmentym�n� voisi olla {\em Teos Koskimies\&Mikkonen: Ohjelmistoarkkitehtuurit kuuluu kurssin Ohjelmistoarkkitehtuurit oppimateriaaliin}. Rakenteellisella kytkenn�ll� tarkoitetaan tilannetta, jossa kytkent� olioiden v�lill� ei ole vain sattumanvaraista ja hetkellist�, kuten esimerkiksi {\em Pekka k�ytt�� Java Programming kirjaa n�yt�n p��ll� istuvan ampiaisen h�tistelyyn}.  T�ss� Pekan ja kirjan v�lill� on selke� kytkent� tuon h�tistelyn ajan. Sen sijaan kytkent� ei ole vallitseva tilanne, asiantila, joka saataisiin selville henkil�iden ty�huoneita tai ty�ymp�rist�� analysoimalla. Rakenteellinen kytkent� sensijaan voisi olla se, ett� {\em henkil�ll� on kirja lainassa}. Sen ilmentym� voisi yll�mainitussa tilanteessa olla vaikkapa {\em Tiinalla on Java Programming -kirja lainassa}.  Pekka sattui k�ytt�m��n h�tistelyyn Tiinan lainaamaa kirjaa.

Olio-ohjelmassa rakenteellinen yhteys ilmenee siten, ett� oliolla on olioarvoinen attribuutti, joka sis�lt�� viittauksen kytkettyyn olioon. Kytkent� voi olla toteutettuna my�s jonkin ep�suoran viittauksen, esimerkiksi asiakasnumeron avulla. 

Yhteyksien esitt�miseen on tarjolla my�s eksplisiittinen tekniikka, joka tuo yhteydet paremmin esiin. T�ss� tekniikassa yhteys piirret��n n�kyviin luokkakaavioon yhteyden omaavat luokat yhdist�v�n� viivana. Kuvassa \ref{fig:olio9} tilin omistus on kuvattu kummallakin tavalla, ylemp�n� olioarvoisen attribuutin avulla ja alempana eksplisiittisesti piirrettyn�. 

\begin{figure}[hbtp]
    \centering
    \includegraphics[width=100mm]{harriKuvat/olio9}
    \caption{Pankkitilin omistus olioarvoisen attribuutin ja yhteyden avulla kuvattuna}
    \label{fig:olio9} 
\end{figure}

Kuvassa \ref{fig:olio9} asiakkaan {\em roolille} yhteydess� on annettu nimi omistaja. Lukupari 1..3 yhteysviivan p��ss� kuvaa kytkent�rajoitteen. Mihin tahansa pankkitiliin voi omistaja-roolissa kytkeyty� enint��n kolme asiakasta, ts. tilill� voi olla enint��n 3 omistajaa. Edelleen jokaiseen pankkitiliin t�ytyy olla kytkettyn� ainakin yksi asiakas.. Ilmentym�tasolla tilanne voisi yhden pankkitilin kannalta tarkasteltuna olla kuvan \ref{fig:olio10} mukainen.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=60mm]{harriKuvat/olio10}
    \caption{Kahden omistajan yhteinen tili}
    \label{fig:olio10} 
\end{figure}

Yll� on tarkasteltu yhteytt� pankkitilist� asiakkaaseen. Yhteytt� voidaan tarkastella my�s vastakkaiseen suuntaan asiakkaasta pankkitiliin. T�ll�in voitaisiin p��ty� kuvan \ref{fig:olio11} mukaisiin rajoitteisiin. 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{harriKuvat/olio11}
    \caption{Tilin omistus tarkasteltuna asiakkaasta pankkitiliin}
    \label{fig:olio11} 
\end{figure}

Kuvassa \ref{fig:olio11} on p��dytty rajoitteeseen, jonka mukaan asiakkaalla voi olla enint��n 10 pankkitili�. Asiakkaalla ei tarvitse olla yht��n pankkitili�. Kun ilmentym�tason kuvaan otetaan mukaan kaikki asiakkaan tilit, voisi tilanne olla kuvan \ref{fig:olio12} mukainen.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{harriKuvat/olio12}
    \caption{Ilmentym� tilinomistuksista. Ines omistaa yksin��n 2 tili� ja yhdess� Akun kanssa yhden tilin}
    \label{fig:olio12} 
\end{figure}


Java-ohjelmassa pankkitili� ja asiakasta vastaavat luokat voisi olla m��ritelty seuraavasti

\begin{verbatim}
public class Pankkitili {
    TiliNumero tilinumero;
    int [] omistaja;  // arvona asiakasnumero
    ...
}
public class Asiakas {
    int asiakasnumero;
    Pankkitili [] tili;
    ...
}
\end{verbatim}

T�ss� ratkaisussa asiakkaasta on suorat olioviitteet asiakkaan pankkitileihin. Pankkitilist� puolestaan on ep�suora asiakasnumeron avulla hoidettu viite omistaja-asiakkaisiin. T�ll�in asiakkaasta on {\em suora p��sy} (engl. direct access) pankkitiliin, mutta pankkitilist� ei ole suoraa p��sy� asiakkaaseen. UML:ss� t�m� voidaan esitt�� {\em navigointim��reen} avulla. Navigointim��re esitet��n liitt�m�ll� yhteysviivaan avoin nuolenk�rki, joka osoittaa siihen luokkaan, jonne toisesta osapuolesta on suora p��sy (ks. kuva \ref{fig:olio13}). Se yhteyden p��, jonka suuntaan ei kyet� ohjelmassa suoraan navigoimaan voidaan merkit� uusimmassa UML-standardissa viivan p��lle piirretyll� rastilla (x). Vanhemmissa UML-standardeissa ei t�h�n p��h�n tehty mit��n merkint�j�. Uudemmankin UML-standardin mukaisissa kaavioissa rastin merkitseminen on ��rimm�isen harvinaista.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{harriKuvat/olio13}
    \caption{Omistus-yhteyden toteutustapa siten, ett� asiakkaasta on suora p��sy pankkitiliin, mutta pankkitilist� ei asiakkaaseen}
    \label{fig:olio13} 
\end{figure}

Suora p��sy on mahdollista m��ritell� kumpaankin suuntaan. Yleens� se toteutetaan ainakin toiseen suuntaan. Navigointim��rittelyt kuuluvat matalan tason ohjelmointil�heiseen kuvaukseen. Korkeamman abstraktiotason kuvauksissa se j�tet��n teknisen toteutuksen yksityiskohtina kuvaamatta.
 
Kuvassa \ref{fig:olio13} on yhteyden kuvauksessa k�ytetty roolinimi� tili ja omistaja. Rooli kuvaa yhteyden osapuolen asemaa suhteessa toiseen osapuoleen, esimerkiksi asiakkaan asema suhteessa pankkitiliin on olla omistaja. Kuvassa roolinimet ovat samat kuin yll� olevassa Java-ohjelmassa yhteyden toteutukseen k�ytettyjen attribuuttien nimet. T�m� kuvastaakin varsin luontevaa tapaa edet� suunnitelmasta toteutukseen k�ytt�m�ll� ohjelmassa suoraan niit� nimi�, jotka esiintyv�t suunnitelmassa.

Olioiden v�liset yhteydet esitet��n luokkakaaviossa kytkem�ll� osapuolten luokat yhteen viivalla. Viivan p�iss� ilmoitetaan kytkent�rajoitteet ja roolinimet. Kytkent�rajoite esitet��n alaraja..yl�raja -parina. K�yt�nn�ss� eniten merkityst� on alarajoilla 0 ja 1. Alaraja 0 tarkoittaa, ett� osapuoliluokan olioiden ei tarvitse olla mukana yhdess�k��n yhteydess� eli yhteys on niille valinnainen (esim.. asiakkaalla ei tarvitse olla pankkitili�). Alaraja 1 puolestaan merkitsee pakollista yhteytt� (esim. tilill� on oltava v�hint��n yksi omistaja). Yl�rajoista eniten on merkityst� arvoilla 1 ja * (ep�m��r�isen monta). Yl�raja 1 m��rittelee yhteyden funktionaaliseksi.  Kullakin oliolla on enint��n yksi kumppani (esim. kurssilla on vain yksi vastuuhenkil�). Usein tiedet��n, ett� olio voi olla yhteydess� moneen olioon, mutta ei ole mahdollista antaa mit��n kiinte�� yl�rajaa kumppaneiden m��r�lle. T�ll�in k�ytet��n yl�rajaa * (monta),  esimerkiksi tilanteessa {\em kurssilla on monta opiskelijaa}.  Jos  ala- ja yl�raja ovat samat riitt�� antaa luku kertaalleen.

Yhteyksi� voi luokitella tyyppeihin  osapuolten kytkent�rajoitteiden yl�rajojen suhteen perusteella. N�in saadaan yhteystyypit:

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip} 
\item yhden suhde yhteen
\item yhden suhde moneen ja
\item monen suhde moneen
\end{itemize}
%N�iden tekninen toteutus vaatii erilaisia ja yhteyden tyypill� on erityisen suuri merkitys tietokannan rakenteita suunniteltaessa. 

UML:ssa roolinimien lis�ksi my�s koko yhteydelle voi antaa nimen. Yhteyden nimi merkit��n keskelle yhteytt�. Yhteyden nimi voi olla suunnattu tai suuntaamaton. Esimerkiksi {\em omistus} on suuntaamaton nimi ja {\em omistaa} on suunnattu. Jotta suunnattua nime� k�ytett�ess� ei syntyisi tulkintaongelmia siit�, miten yhteysnimi pit�isi tulkita, voidaan nimeen liitt�� lukusuunta (kuva \ref{fig:olio14}). Nimen antaminen yhteydelle ei ole v�ltt�m�t�nt�. Usein roolinimipari (esimerkiksi tili-omistaja)  riitt�� identifioimaan, mist� yhteydest� on kyse. Joskus taas yhteyteen liittyvien olioiden roolit ovat niin itsest��n selv�t, ett� roolinimille ei ole tarvetta.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{harriKuvat/olio14}
    \caption{Yhteysnimen lukusuunta: Asiakas omistaa pankkitilin}
    \label{fig:olio14} 
\end{figure}

Yhteydet molemmat osapuolet voivat kuulua samaan luokkaan. T�ll�in roolinimien k�ytt� on v�ltt�m�t�nt�. Kuvan \ref{fig:olio15} esimerkiss� kuvataan ty�njohtosuhdetta.  Ty�ntekij�ll� voi olla enint��n yksi esimies ja useita alaisia.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=40mm]{harriKuvat/olio15}
    \caption{Yhteys, jonka osapuolet kuuluvat samaan luokkaan}
    \label{fig:olio15} 
\end{figure}

Yhteyteen voidaan liitt�� j�rjestysm��re kuvaamaan sit�, ett� samaan olioon yhteydess� olevien olioiden joukko on jollain perusteella j�rjestetty. Kuvassa \ref{fig:olio16} on esimerkki t�llaisesta yhteysm��rittelyst� ja sen mukaisesta ilmentym�st�.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{harriKuvat/olio16}
    \caption{J�rjestetty kumppanijoukko}
    \label{fig:olio16} 
\end{figure}

Luokkakaavioita laadittaessa joudutaan usein kuvaamaan kokonaisuuden ja siihen kuuluvan osan v�lisi� yhteyksi�. T�llaiselle yhteydelle on oma nimityksens� {\em kooste} (engl. aggregate) ja UML:ss� oma merkint�tapansa, salmiakkisymboli kokonaisuuden puoleisessa p��ss�. Kuvan \ref{fig:olio16} esimerkiss� joukkueeseen voi kuulua monta pelaaja ja pelaaja voi kuulua useaan joukkueeseen. Pelaaja on osa joukkuetta mutta voi my�s vaihtaa joukkueesta toiseen.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{harriKuvat/olio17}
    \caption{Koosteyhteys}
    \label{fig:olio17} 
\end{figure}

Koosteen k�ytt� lis�� mallin luettavuutta. Muuta merkityst� sill� ei ole. Se ei vaikuta mill��n tavalla navigointiin eik� osallistumisrajoitteisiin. Koosteen tapauksessa osan ja kokonaisuuden v�linen kytkent� on l�yh�. Osa voidaan irrottaa kokonaisuudesta ja liitt�� toiseen. Esimerkiss� pelaaja voi vaihtaa joukkuetta ja kuulua moneen eri joukkueeseen. Joukkueen lopettaminen ei vaikuta mitenk��n pelaajiin. 

Koostetta merkitt�v�mpi rakenne mallintamisen kannalta on {\em kompositio} (engl. composition). Kompositioon liittyy tiukkoja rajoituksia:

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip} 
\item kompositiossa osa on olemassaoloriippuva kokonaisuudesta. Kokonaisuuden tuhoaminen h�vitt�� my�s sen osat.
\item osa voi kuulua vain yhteen samantyyppiseen kompositioon
\item osa on koko elinaikansa kytkettyn� samaan kokonaisuuteen.
\end{itemize}

Kompositio kuvataan UML:ss� mustalla salmiakkisymbolilla kokonaisuuden puolessa p��ss� yhteysviivaa (ks. kuva \ref{fig:olio18}). 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{harriKuvat/olio18}
    \caption{Kompositio}
    \label{fig:olio18} 
\end{figure}

Kuvan \ref{fig:olio18} esimerkiss� {\em Huoneisto} on koko olemassaolonsa ajan osa samaa rakennusta. Jos rakennus puretaan, h�vi�� my�s huoneisto. Olio-ohjelmassa komposition teht�v� on luoda ja tuhota osansa. Kompositiossa kokonaisuuteen liittyvien osien joukon ei tarvitse olla kiinte� (se voi toki olla sit�). Kompositioon voidaan lis�t� osia ja siit� voidaan poistaa niit�.  Kompositiota voidaan k�ytt�� hyv�ksi my�s sen osien ulkoisessa tunnistamisessa. Esimerkiksi huoneisto identifioidaan yleisesti identifioimalla rakennus, johon huoneisto kuuluu. Rakennuksen sis�ll� huoneiston identifiointiin riitt�� sis�inen huoneistonumero.  

Joskus on tarpeen liitt�� yhteyteen t�sment�v�� tietoa siit� millainen yhteys on kyseess�. Tarkastellaan esimerkkin� j�senyytt� yhdistyksess� (ks. kuva \ref{fig:olio19}). J�sen voi kuulua yhdistykseen erilaisissa rooleissa. Kuvassa ovat roolit puheenjohtaja, taloudenhoitaja ja rivij�sen. Kaikkia n�it� vastaten olisi mahdollista m��ritell� eri yhteystyypit, kuten on tehty kuvassa \ref{fig:olio19}. 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{harriKuvat/olio19}
    \caption{Erilaisia j�senyysrooleja, joista kukin mallinnettu omana yhteystyyppin��n.}
    \label{fig:olio19} 
\end{figure}

Jos vaihtoehtoja on runsaasti ja vaihtoehtokokoelma el��, tarvitaan jokin muu tapa mallintaa tilanne. UML:ss� t�llaisen rakenteen kuvaamiseen voi k�ytt�� {\em yhteysluokkaa} (engl. association class) ks. kuva \ref{fig:olio20}. Yhteysluokka mahdollistaa attribuuttien liitt�misen yhteyteen.  Yhteysluokka tulee yleens� kyseeseen ns. monen suhde moneen yhteyksien (kummallakin osapuolella voi olla monta kumppania) tapauksessa. Yhteysluokan k�ytt� esimerkin tilanteessa johtaa v�ljempiin rajoitteisiin kuin erillisten yhteystyyppien k�ytt�. T�t� rakennetta k�ytett�ess� ei ole mahdollista rajoittaa puheenjohtajien ja taloudenhoitajien m��r��. Kolmas mahdollinen tapa olisi m��ritell� erillinen luokka j�senyys ja kytke� se yhdistykseen ja henkil��n (ks. kuva \ref{fig:olio21}).

\begin{figure}[htbp]
    \centering
    \includegraphics[width=70mm]{harriKuvat/olio20}
    \caption{Yhteyden luonnehdinta yhteysluokan avulla}
    \label{fig:olio20} 
\end{figure}

\begin{figure}[htbp]
    \centering
    \includegraphics[width=70mm]{harriKuvat/olio21}
    \caption{Yhdist�v� luokka}
    \label{fig:olio21} 
\end{figure}

Kuvien  \ref{fig:olio20} ja \ref{fig:olio21} kuvaamien vaihtoehtojen ohjelmatoteutuksessa ei v�ltt�m�tt� ole mit��n eroa.

UML:ss� on tarjolla my�s useamman kuin kahden osapuolen v�linen yhteys. T�llaisesta on esimerkki kuvassa \ref{fig:olio22}. Siin� eri opettajat k�ytt�v�t samalla kurssilla eri oppikirjaa. T�m� voidaan muuntaa kahdenv�lisiin yhteyksiin perustuvaksi muuntamalla yhteys oppikirja luokaksi.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=70mm]{harriKuvat/olio22}
    \caption{Kolmenv�linen yhteys}
    \label{fig:olio22} 
\end{figure}

Luokkakaavioita voidaan laatia ohjelmal�heisin�, jolloin niill� pyrit��n mahdollisimman tarkoin kuvaamaan ohjelman oliorakenne. Korkeammalla abstraktiotasolla laaditut abstraktit mallit j�tt�v�t joitain yksityiskohtia esitt�m�tt�. Er�s tyypillinen ero korkeamman tason kaavion ja ohjelmal�heisen kaavion v�lill� liittyy olioiden v�lisiin yhteyksiin. Ohjelmal�heisess� kuvauksessa esitet��n, miten olioiden v�linen yhteys teknisesti toteutetaan. Korkeamman abstraktiotason kuvauksessa riitt�� kuvata keskeisten yhteyksien olemassaolo. Tarkastellaan esimerkkin� t�st� kurssin ja harjoitusryhm�n v�list� yhteytt� (ks. kuva \ref{fig:olio23}). 


\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{harriKuvat/olio23}
    \caption{Abstrakti yhteys ja sen kaksi  teknist� toteutusta}
    \label{fig:olio23} 
\end{figure}

Kuvan yl�laidassa on abstrakti kuvaus tilanteesta, keskell�  ja alhaalla on kaksi teknisen tason kuvausta rakenteen toteutuksesta, ylempi taulukkorakennetta ja alempi listarakennetta k�ytt�en. Taulukkorakenteen kuvauksesta pystyt��n viel� hahmottamaan alkuper�inen abstrakti rakenne, mutta listarakenteen kuvauksesta ei en�� n�y, ett� kurssiin liittyy useita harjoitusryhmi�. Sopivan abstraktiotason valinta onkin oleellista luokkakaavioiden k�ytt�kelpoisuuden kannalta.  Yll� olevassa kuvassa luokka {\em Ryhm�t} on m��ritelty taulukoksi k�ytt�m�ll� ns. {\em stereotyyppi}-k�sitett�. T�m� on UML:n mallik�sitteist�n laajennustekniikka, jolla metamallin k�sitteist�� voidaan laajentaa m��rittelem�ll� erikoistuneita tietyss� ymp�rist�ss� k�ytett�vi� mallinnusk�sitteit�. Karkeasti ottaen stereotyypin voidaan ajatella tarkoittavan kaavioon liitetty� m��r�muotoista kommenttia. Stereotyyppi-k�sitett� tarkastellaan laajemmin luvussa \ref{sec:stereo}.

\subsection{Luokkamallin laatiminen} \label{sec:laatiminen}

J�rjestelm�n olioperustaista toteutusta voidaan ajatella simulointimallin muodostamisena jostakin reaalimaailman ilmi�st�. T�ll�in ohjelmassa toimivat oliot vastaavat  pitk�lti reaalimaailman ilmi�ss� osallisena olevia olioita. Lis�ksi tarvitaan olioita, joiden kautta voidaan tarkastella simulointimallin tilaa ja v�litt�� siihen liittyv�� ohjaustietoa (eli k�ytt�liittym�). Keskeist� simulointimallin muodostamisessa on l�yt�� ne reaalimaailman kohteet, joita vastaavia luokkia ohjelmaan tulisi ottaa mukaan. N�iden luokkien etsimist� voidaan kutsua oliomallinnukseksi tai {\em k�siteanalyysiksi} (engl. conceptual modeling). Teht�v�n� on l�yt�� oleellinen rakenne simuloitavalle reaalimaailman ilmi�lle.

Mallin laatiminen voisi tapahtua seuraavien vaiheiden mukaisesti:

\begin{enumerate}
\item Kartoita luokkaehdokkaita 

Laadi luettelo tarkasteltavan ilmi�n kannalta keskeisist� kohteista tai ilmi�ist�, jotka voisivat tulla kyseeseen luokkina tai olioina. T�llaisia voisivat olla toimintaan osallistujat, toiminnan kohteet, toimintaan liittyv�t tapahtumat, materiaalit, tuotteet ja v�lituotteet, toiminnalle edellytyksi� luovat asiat.

Kartoituksen pohjana voi k�ytt�� vapaamuotoista tekstikuvausta tarkasteltavasta ilmi�st�, kutsutaan sit� jatkossa {\em kohdealueeksi} (engl. problem domain). T�st� kuvauksesta alleviivataan luokkaehdokkaita ja ker�t��n ne luetteloon. Luokkaehdokkaat esiintyv�t kuvauksessa usein substantiiveina. Verbit ilmaisevat joskus yhteyksi�. Alustavaa karsintaa voi tehd� sen perusteella, onko asia lainkaan oleellinen mallinnettavan ilmi�n kannalta.

\item Karsi ehdokkaita  
 
Luetteloon saadut ehdokkaat k�yd��n l�pi ja arvioidaan voisiko ehdokas tulla kyseeseen luokkana. Arvioinnissa tulisi tarkastella

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip} 
\item Liittyyk� ilmi��n  tietosis�lt��, joka on v�ltt�m�t�nt� j�rjestelm�n kannalta
\item Onko asia riitt�v�n t�rke� kohdealueen kannalta.
\end{itemize}
Karsintaa ja ehdokkaiden kartoitusta joudutaan usein tekem��n iteratiivisesti. Ensimm�inen karsintakierros ei v�ltt�m�tt� tuota lopullista tulosta.

\item Tunnista olioiden v�liset yhteydet

Yhteyksi� voi etsi� vapaamuotoisesta kuvauksesta (verbit, genetiivit, muut ilmaukset jotka kuvaavat kytkent��). Yhteyksienkin suhteen tulisi mietti� onko yhteys oleellinen tarkasteltavan ilmi�n kannalta sek� onko se rakenteellinen.

\item T�smenn� luokkakuvauksia m��rittelem�ll� attribuutit

Attribuutteja saattaa l�yty� vapaamuotoisesta kuvauksesta, mutta yleens� niiden l�yt�minen edellytt�� lis�selvityksi� kohdealueesta, esimerkiksi toiminnan osapuolten haastatteluja. Attribuuttien kohdalla pit�isi my�s selvitt�� mihin niit� tarvitaan.

\item M��rittele yhteyksiin liittyv�t osallistumisrajoitteet

Osallistumisrajoitteiden avulla ilmaistaan rakenteellisia s��nt�j�. Ne eiv�t v�ltt�m�tt� tule esiin vapaamuotoisessa kuvauksessa vaan edellytt�v�t tarkempaa kohdealueen analysointia.

\item Liit� luokkiin palvelut ja varmista palvelujen ja tietosis�ll�n yhteensopivuus

Palveluja ei yleens� m��ritell�, kun tehd��n kohdealueen luokkamallia. Palvelujen m��ritt�minen tapahtuu vasta ohjelman suunnitteluvaiheessa. Aiheeseen palataan luvussa \ref{sec:osa4}.
\end{enumerate}

\subsubsection{Esimerkki}

Tarkasteltavana ilmi�n� on elokuvalipun varaaminen. Lippu oikeuttaa paikkaan tietyss� n�yt�ksess�. N�yt�ksell� tarkoitetaan elokuvan esitt�mist� tietyss� teatterissa tiettyyn aikaan. Samaa elokuvaa voidaan esitt�� useissa teattereissa useina aikoina. Asiakas voi samassa varauksessa varata useita lippuja yhteen elokuvaan.

Edellist� kappaletta voidaan pit�� ilmi�n vapaamuotoisena kuvauksena. Otetaan se jatkok�sittelyyn ja alleviivataan luokkaehdokkaita.

\begin{quote}
Tarkasteltavana ilmi�n� on \underline{elokuvalipun} varaaminen. \underline{Lippu} oikeuttaa \underline{paikkaan} tietyss� \underline{n�yt�ksess�}. N�yt�ksell� tarkoitetaan \underline{elokuvan} esitt�mist� tietyss� \underline{teatterissa} tiettyyn aikaan. Samaa elokuvaa voidaan esitt�� useissa teattereissa useina aikoina. \underline{Asiakas} voi samassa \underline{varauksessa} varata useita lippuja yhteen elokuvaan.
\end{quote}

Saatiin luettelo:

\begin{itemize}
\item {\em elokuvalippu}
\item lippu
\item paikka
\item n�yt�s
\item elokuva
\item teatteri
\item asiakas
\item varaus
\end{itemize}

P��tet��n j�tt�� muut ehdokkaat paitsi elokuvalippu, joka on selv�sti termin lippu synonyymi. Kuvassa \ref{fig:elokuva1} on ensimm�inen luonnos luokkakaaviosta. Yhteyksi� on luonnosteltu, mutta niihin ei viel� liity rajoitteita eik� edes nimi�.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{elokuva1}
    \caption{Luokkakaavion ensimm�inen luonnos}
    \label{fig:elokuva1} 
\end{figure}

Seuraavassa versiossa on tunnistettu kompositiot ja koosteet (ks. kuva \ref{fig:elokuva2}) ja m��ritelty yhteyksien osallistumisrajoituksia. Koska varauksen ja paikan v�linen yhteys on p��telt�viss� varauksen ja lipun sek� lipun ja paikan v�lisist� yhteyksist�, se karsitaan redundanttina (toisteisena)  pois.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{elokuva2}
    \caption{Luokkakaavion seuraava versio}
    \label{fig:elokuva2} 
\end{figure}

Seuraavaksi kaaviota t�ydennet��n keskeisill� attribuuteilla  (ks. kuva \ref{fig:elokuva3}). My�s yhteyksi� on nimetty vaikka t�ss� tapauksessa nimet eiv�t tuo juurikaan lis�informaatiota. 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=90mm]{elokuva3}
    \caption{Luokkakaavion seuraava versio}
    \label{fig:elokuva3} 
\end{figure}

Yhteyksi� ja attribuutteja voidaan viel� joutua m��rittelem��n uudelleen kun luokkiin liitet��n palvelut eli ohjelmiston suunnitteluvaiheessa.

\subsubsection{K�ytt�tapauskohtainen ja iteratiivinen luokkamallin laatiminen}

K�ytt�tapaukset voivat toimia my�s perustana j�rjestelm�n luokkamallin m��rittelyss�. T�h�n perustuu ns. {\em k�ytt�tapauspohjainen}  m��rittely. T�ss� l�hestymistavassa laaditaan aluksi k�ytt�tapauskohtaisia osamalleja, jotka sitten yhdistet��n kokonaisvaltaiseksi malliksi (ks. kuva \ref{fig:elokuva4}). 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{elokuva4}
    \caption{K�ytt�tapauspohjainen tietosis�ll�n m��ritys}
    \label{fig:elokuva4} 
\end{figure}

Kukin k�ytt�tapauskohtainen osamalli m��rittelee sis�lt�luokat vain k�ytt�tapauksen edellytt�m�ss� laajuudessa. Syntyv�t mallit ovat siten kokonaismallia suppeampia ja n�in helpommin aikaansaatavissa.  L�ht�kohdaksi mallinnukseen voidaan ottaa k�ytt�tapauksen kuvaus, mahdollinen k�ytt�tapaukseen liitetty luonnos k�ytt�liittym�st�, raporttimalli tai lomake, joka liittyy k�ytt�tapaukseen. Jos l�ht�kohtana on tekstikuvaus, mallinnus voi l�hte� liikkeelle siten, ett� aluksi alleviivataan tekstist� luokkaehdokkaat ja edet��n sitten kuten edell� esitettiin. 

Jos ohjelmiston kehitt�minen tapahtuu ketterien menetelmien suosittamalla iteratiivisella l�hestymistavalla (ks. luku \ref{sec:agile}), kannattaa my�s ohjelman luokkamallia rakentaa iteratiivisesti. Eli jos ensimm�isess� iteraatiossa toteutetaan esim. ainoastaan k�ytt�tapausten 1 ja 2 mukainen toiminnallisuus, esitet��n iteraation luokkamallissa vain ne luokat, jotka ovat merkityksellisi� tarkastelun alla olevan toiminnallisuuden kannalta. Luokkamallia t�ydennet��n my�hempien iteraatioden aikana tarpeellisilta osin.

Tarkastelemme UML:n soveltamista iteratiiviseen ohjelmistokehitykseen tarkemmin luvuissa  \ref{sec:osa3} ja  \ref{sec:osa4}.

\subsection{Mallinnusk�sitteist�n erikoistaminen} \label{sec:stereo}

Ohjelmistojen kehitt�mismenetelmien ja ohjelmistotutkimuksen yhteydess� esitet��n erilaisia k�sitteist�j�, joiden avulla ohjelmistot olisivat ainakin k�sitteist�n kehitt�jien mielest� aiempaa paremmin hahmotettavissa. K�sitteist�t voivat olla yleisi� tai sovellusaluekohtaisia. UML kuvauskielen pohjalla on abstrakti, joskin monin paikoin hyvin ohjelmointil�heinen k�sitteist�. UML:n pohjana oleva k�sitteist� ei olekaan tarkoitettu sin�ll��n suoraan k�ytett�v�ksi vaan  perusk�sitteist�ksi, jonka p��lle voi rakentaa uusia mallinnusk�sitteist�j�. UML kuvaustekniikka on kehitetty yleisk�ytt�iseksi kehykseksi, jota voi laajentaa ja erikoistaa omien tarpeiden mukaiseksi. Erikoistaminen tapahtuu m��rittelem�ll� uusia mallinnusk�sitteit�, kiinnitt�m�ll� mallinnusk�sitteisiin liittyvi� ominaisuuksia tai m��rittelem�ll� mallinnukseen liittyvi� s��nt�j�. N�it� laajennustekniikkoja k�ytt�v�t yleens� menetelm�kehitt�j�t. Seuraavassa n�ist� rakenteista tarkastellaan t�rkeint� uusien k�sitteiden m��rittelytapaa.

UML:n perusk�site voidaan erikoistaa m��rittelem�ll� perusk�sitteeseen pohjautuva erikoisk�site. UML k�ytt�� n�ist� nimityst� {\em stereotyyppi} (engl. stereotype). Esimerkiksi luokkakaavion k�site {\em luokka} voitaisiin erikoistaa k�sitteiksi sis�lt�luokka eli tietokohde (entity), ohjausluokka (control) ja liittym�luokka (interface), kuten on tehty Jacobsonin esitt�m�ss� suunnittelumenetelm�ss� \cite{Objectory} (ks. my�s luku \ref{sec:MVC}). T�ll�in luokkakaavion laatija k�ytt�isi luokkakaaviotekniikkaa, mutta erikoistetuin k�sittein. Luokkien lis�ksi voi stereotyyppej� m��rittelem�ll� erikoistaa my�s yhteyksi�, attribuutteja ja palveluita. UML-kuvauskieli tarjoaa oletusarvoisen tavan esitt�� erikoistettu k�site graafisesti liitt�m�ll� kohteen yhteyteen erikoistavan k�sitteen nimi v�k�siin suljettuna. Kuvassa \ref{fig:laa1} esiintyy erikoistettuina luokkina tietokohde (entity) ja ohjausluokka (control) sek� erikoistettuja riippuvuuksia kuvaamassa tietokohteiden k�ytt��.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=70mm]{harriKuvat/laa1}
    \caption{Erikoistettuihin k�sitteisiin perustuva luokkakaavio}
    \label{fig:laa1} 
\end{figure} 

UML-tekniikassa on mahdollista my�s m��ritell� erikoistetuille k�sitteille oma graafinen esitys. Kuvassa \ref{fig:laa2} on kuvan \ref{fig:laa1} kaavio esitetty Jacobsonin kuvaustekniikan symboleita k�ytt�en.  UML-malliin perustuvat suunnitteluohjelmistot tukevat ainakin kuvan \ref{fig:laa1} esitysmuotoa. Osa ty�kaluista, kuten t�m�n monisteen joidenkin kaavioiden laadinnassa k�ytetty Visual Paradigm, tukevat my�s erikoistettuja, kuvassa \ref{fig:laa2}) k�ytettyj� symboleja.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=65mm]{harriKuvat/laa2}
    \caption{Erikoistetuin k�sittein ja symbolein esitetty luokkakaavio}
    \label{fig:laa2} 
\end{figure} 

Erikoistettu k�site on luonteeltaan erikoistapaus UML:n tarjoamasta yleisk�sitteest�. Kaikki UML:n perusk�sitteist�n yhteydess� m��ritellyt s��nn�t ja rajoitukset periytyv�t erikoistetuille k�sitteille, ellei niiden m��rittelyn yhteydess� anneta uusia korvaavia s��nt�j�. Periytymist� yleisesti tarkastellaan t�m�n luvun lopussa. Erikoistamismahdollisuus ei rajoitu pelk�st��n luokkakaavioihin, vaan sit� voidaan k�ytt�� kaikissa UML:n tekniikoissa. Itse asiassa osa UML:n tekniikoista, esimerkiksi komponenttikaavio ja k�ytt�tapauskaavio ovatkin pohjimmiltaan erikoistettuihin k�sitteisiin perustuvia luokkakaavioita. 

\subsection{Riippuvuudet}

Yll� olevassa esimerkiss� (kuvat \ref{fig:laa1} ja \ref{fig:laa2}) esiintyi luokkien v�lisi� {\em riippuvuuksia} (engl. dependency). Luokka riippuu toisesta, jos muutos toisen luokan m��rittelyss� voi aiheuttaa tarpeen muuttaa luokan m��rittely�. Esimerkiss� esiintyi erikoistettu lukuriippuvuus (read). Ohjelma lukee tietokohteen tietoja. Jos tietokohteen m��rittely muuttuu, voidaan joutua muuttamaan lukevaa ohjelmaa. UML:ss� on valmiiksi m��riteltyn� joitain riippuvuuksia sek� yleinen riippuvuus, joka soveltuu erikoistettavaksi. Valmiiksi m��riteltyj� riippuvuustyyppej� ovat esimerkiksi

\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item {\em call}  palvelujen v�linen kutsuriippuvuus 
\item {\em create} luokan oliot luovat toisen luokan olioita 
\item {\em derive} atrribuutin arvo on laskettavissa toisen arvosta tai yhteys p��telt�viss� 
\item {\em instantiate} luokan oliot luovat toisen luokan olioita 
\item {\em realize} luokka toteuttaa rajapinnan 
\item {\em refine} kohteet tarkentavat abstraktimpaa kuvausta 
\item {\em use} kohteiden v�linen  k�ytt�sidos
\end{itemize}

Riippuvuudet ovat mallitason k�sitteiden v�lisi� toisin kuin yhteydet, jotka ovat ilmentymien v�lisi�. Riippuvuus esitet��n kaaviossa katkoviivalla, jonka p��ss� oleva nuolenk�rki osoittaa siihen luokkaan, josta toinen luokka on riippuva.  %Yhteyksien v�listen riippuvuuksien tapauksessa viiva yhdist�� yhteysviivat.

Usein esiintyv� riippuvuus luokkien v�lill� on palvelun parametrin aiheuttama riippuvuus, jossa palvelun tarjoava luokka tulee riippuvaksi parametrin luokasta. Alla oleva ohjelmakoodi aiheuttaisi t�ll�in kuvan \ref{fig:laa3} mukaisen riippuvuuden. Riippuvuuden tyyppi on t�ll�in {\em use}.

{\small
\begin{verbatim}
class K�ytt�j� {
     public omaPalvelu(K�ytett�v� k) {
        k.vierasPalvelu();
   }
}
\end{verbatim}
}

\begin{figure}[htbp]
    \centering
    \includegraphics[width=70mm]{harriKuvat/laa3}
    \caption{Luokkien v�linen riippuvuus  K�ytt�j� on riippuvainen K�ytett�v�st�.}
    \label{fig:laa3} 
\end{figure} 

Tarkemmin luvussa \ref{sec:pakkaus} k�sitelt�v� {\em pakkaus} (engl. package) on tapa j�sent�� ohjelmistoa esimerkiksi kokoamalla yhteenkuuluvia luokkia osaj�rjestelm�ksi. Pakkauksia voi k�ytt�� my�s siten, ett� pakkauksessa m��ritell��n alemman abstraktiotason tarkennus ylemm�ll� abstraktiotasolla kuvatulle k�sitteelle. T�ll�ist� tilannetta voidaan havainnollistaa kuvan \ref{fig:yleistys1} tapaan, eli k�ytt�en luokan ja sen tarkentavan pakkauksen v�lill� tarkennusriippuvuutta.


\begin{figure}[htbp]
    \centering
    \includegraphics[width=40mm]{yleistys1}
    \caption{Pakkaus, jonka sis�lt� tarkentaa korkeammalla abstraktiotasolla esitetty� luokkaa}
    \label{fig:yleistys1} 
\end{figure} 

\subsection{Yleistyshierarkia ja periytyminen}

Luokkakaavion laatiminen on kohdealueen j�sent�mist�. Sit� teht�ess� luodaan tai kirjataan luokitusj�rjestelm� kohdealueen ilmi�ille. Luokitusj�rjestelm�lle voidaan asettaa erilaisia vaatimuksia. Joissakin menetelmiss� edellytet��n, ett� ilmi�t on luokiteltava siten, ett� kaikki luokat ovat erillisi�, ts. niill� ei ole yhteisi� ilmentymi�. Toiset menetelm�t puolestaan sallivat ainakin jonkinasteisen luokkien p��llekk�isyyden.

Luonnollisessa kieless� luokittelu on vapaata. K�sitteet ja niit� vastaavat luokat ovat limitt�isi� tai p��llekk�isi�. Kun tarkastellaan, miten luokan ilmentymien joukko suhtautuu toisen luokan ilmentymien joukkoon, voidaan erottaa tapaukset:
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item ilmentym�joukot ovat aina pistevieraat  (esim. auto ja henkil�)
\item ilmentym�joukot voivat sis�lt�� yhteisi� ilmentymi� (esim. nainen ja johtaja)
\item ilmentym�joukko sis�ltyy aina toisen luokan ilmentym�joukkoon (esim. nainen ja henkil�).
\end{itemize}

Jos luokan A ilmentym�joukko sis�lt�� aina luokan B ilmentym�joukon on luokkien v�lill� {\em yleistys-erikoistus} (engl. generalization-specialization) suhde. K�site B on erikoistapaus k�sitteest� A (nainen on henkil�n erikoistapaus) tai p�invastoin k�site A on yleistys k�sitteest� B (henkil� on yleisk�site, johon nainen sis�ltyy).  Kun luokkien suhdetta tarkastellaan yleistys-erikoistus-suhteeseen perustuen, kutsutaan yleisemp�� luokkaa {\em yl�luokaksi} (engl. super class) ja erikoistuneempaa {\em alaluokaksi} (engl. subclass). Yl�luokka on yleistyshierarkiassa (luokkahierarkiassa) ylemm�ll� tasolla, siis yleisempi, kuin alaluokka. 

Esimerkiksi voitaisiin m��ritell�
\begin{itemize} \addtolength{\itemsep}{-0.5\baselineskip}
\item luokka nainen on luokan henkil� alaluokka
\item luokka johtaja on luokan henkil� alaluokka
\item luokat auto, laiva ja lentokone ovat luokan kulkuv�line alaluokkia
\end{itemize}

Siit�, ett� luokka B on luokan A alaluokka seuraa, ett� jokainen B:n ilmentym� on my�s A:n ilmentym�, eli jokainen johtaja on my�s henkil�. T�st� taas seuraa, ett� kaikki yhteydet ja attribuutit, jotka ovat mahdollisia luokan A ilmentymille, ovat mahdollisia my�s B:n ilmentymille. Jos siis henkil�lle on m��ritelty attribuutti Nimi ja johtaja on henkil�n alaluokka, niin my�s johtajalla on automaattisesti Nimi-attribuutti. Jos henkil� on m��ritelty osapuoleksi ty�suhde-yhteyteen, my�s johtajan ilmentym� voi olla osapuolena ty�suhde yhteydess�. T�t� ilmi�t� kutsutaan {\em periytymiseksi} (engl. inheritance).

Periytymisess� yl�luokkaan liitetyt attribuutit, palvelut ja yhteydet periytyv�t alaluokalle, eli ovat voimassa my�s alaluokan ilmentymille. On syyt� pit�� mieless�, ett� periytyminen on luokkien v�list� m��rittelyjen periytymist� - ilmentym�t eiv�t peri mit��n toisilta ilmentymilt�. Luokkakaavion laatimisen kannalta periytyminen tarkoittaa sit�, ett� piirrett�, joka on liitetty yl�luokkaan, ei tarvitse erikseen liitt�� alaluokkaan, vaan se liittyy sinne automaattisesti.

Alaluokan ja yl�luokan v�linen riippuvuus kuvataan luokkakaaviossa alaluokasta yl�luokkaan osoittavalla nuolella, jossa on iso kolmionmuotoinen k�rki (ks. kuva  \ref{fig:laa4}). 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=60mm]{harriKuvat/laa4}
    \caption{Yleistyshierarkian esitt�minen}
    \label{fig:laa4} 
\end{figure} 

Alaluokkaan voidaan liitt�� yl�luokalta perittyjen attribuuttien, palvelujen ja yhteyksien lis�ksi omia attribuutteja, yhteyksi� ja palveluja. Esimerkiksi johtajalle voitaisiin lis�t� attribuutit {\em vastuualue} ja {\em alaisten m��r�}, joita ei henkil�ill� yleisesti ole. Johtaja voitaisiin m��ritell� my�s rooliin k�ytt�j� {\em edustustilin k�ytt�oikeus} -yhteyteen ja rooliin esimies {\em ty�njohto}-yhteydess�  (ks. kuva \ref{fig:laa5}).


\begin{figure}[htbp]
    \centering
    \includegraphics[width=65mm]{harriKuvat/laa5}
    \caption{Johtajan lis�attribuutit ja -yhteydet}
    \label{fig:laa5} 
\end{figure} 

Alaluokkaan johtaja voidaan liitt�� my�s sellaisia palveluita, joita henkil�ll� ei yleisesti ole. T�llaisia voisivat olla esimerkiksi {\em maksa edustustililt�}, {\em laadi luettelo alaisista}.  Alaluokassa voidaan my�s {\em syrj�ytt��} (engl. override) yl�luokassa m��ritelty palvelu. Syrj�ytt�misell� tarkoitetaan palvelun sis�ll�n tai toteutustavan uudelleenm��rittely�, nimen s�ilyess� kuitenkin ennallaan. Esimerkiksi Henkil�-luokalle voisi olla m��ritelty palvelu {\em Viikkoraportti}, jonka sis�lt�n� olisi

\begin{quote}
   {\em	kerro ajank�ytt� ty�teht�viin.}
\end{quote}

T�m� voitaisiin syrj�ytt�� Johtaja-luokassa siten, ett� johtajan {\em Viikkoraportti}-palvelun sis�lt� olisikin

\begin{quote}
	{\em kerro ajank�ytt� ty�teht�viin, \\
	laadi yhteenveto alaisten viikkoraporteista \\
	raportoi edustustilin k�ytt�.}
\end{quote}

Olio-ohjelmoinnissa olio tiet�� oman luokkansa ja suorittaa palvelunsa oman luokkansa mukaisina. Niinp� olio-ohjelmassa milt� tahansa luokan henkil� tai sen alaluokan oliolta voidaan pyyt�� Viikkoraportti-palvelua. Jos olio ei ole johtaja, vaan tavallinen henkil�, h�n kertoo oman ajank�ytt�ns�, mutta jos olio onkin johtaja, h�n toimii johtajan Viikkoraportti-palvelun mukaisesti ja laatii lis�ksi yhteenvedon alaisten viikkoraporteista ja raportoi edustustilin k�ytt�ns�. 

Mahdollisuus syrj�ytt�� palvelum��rityksi� on olio-ohjelmoinnin t�rkeimpi� etuja perinteisiin ohjelmointikieliin verrattuna. Se lis�� joustavuutta ohjelmakirjastojen k�yt�ss�, edist�� ohjelmistokomponenttien uudelleenk�ytett�vyytt� ja muodostaa perustan erilaisten ohjelmistokehysten rakentamiselle (kehykset ovat er��nlaisia sovellusrunkoja, joissa toiminnan yksityiskohdat on j�tetty esimerkiksi syrj�ytt�misen avulla t�smennett�v�ksi). Syrj�ytt�mismahdollisuus onkin olio-ohjelmoinnin kannalta merkitt�vin syy yleistyshierarkian k�ytt��n.  Sen hyv�ksik�ytt�mahdollisuudet tulevat kuitenkin usein esiin vasta laadittaessa teknisen tason suunnitelmaa ohjelmiston luokkarakenteesta.  Luokkakaaviossa syrj�ytetty palvelu kuvataan toistamalla palvelun nimi alaluokassa.  Kuvassa \ref{fig:laa6} on henkil�-luokan palvelu {\em viikkoraportti} syrj�ytetty luokassa johtaja. Sen sijaan palvelu {\em kerro\_palkka} periytyy samansis�lt�isen� luokalta henkil� luokalle johtaja.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=65mm]{harriKuvat/laa6}
    \caption{Syrj�ytetty palvelu viikkoraportti}
    \label{fig:laa6} 
\end{figure} 

Kohdealuetta mallinnettaessa yleistyshierarkian t�rkein k�ytt�tilanne on kuvausvaivan s��st�minen ja erilaisten s��nt�jen t�sm�llinen ilmaiseminen. Jos usealla luokalla on samoja attribuutteja ja luokille voidaan m��ritell� yhteinen yl�luokka, voidaan yhteiset attribuutit liitt�� yl�luokkaan ja m��ritell� n�in vain kertaalleen.  

Tilannetta, jossa luokka on useamman kuin yhden luokan v�lit�n alaluokka kutsutaan {\em moniperiytymiseksi} (engl. multiple inheritance) (ks. kuva \ref{fig:laa7}).

\begin{figure}[htbp]
    \centering
    \includegraphics[width=48mm]{harriKuvat/laa7}
    \caption{Moniperiytyminen}
    \label{fig:laa7} 
\end{figure} 

Moniperiytyminen voi olla k�tev� tapa kohdealueen mallinnuksessa. Kaikki olio-oh\-jel\-moin\-ti\-kie\-let, esimerkiksi Java, eiv�t kuitenkaan tue moniperint��.  Java ohjelmoinnissa hieman t�t� vastaava rakenne on {\em rajapinnan periminen} (engl. interface realization). Rajapinnat ovat tavallaan abstrakteja luokkia, joilla ei ole m��ritelty� tietosis�lt�� ja palveluista on annettu vain niiden m��rittely. T�ll�in rajapinnan periv�ss� (toteuttavassa)  luokassa on syrj�ytett�v� kaikki rajapinnassa m��ritellyt palvelut (ks. kuva \ref{fig:laa8}).

\begin{figure}[htbp]
    \centering
    \includegraphics[width=70mm]{harriKuvat/laa8}
    \caption{Rajapintojen toteutus (palvelujen m��rittelyt periytyv�t)}
    \label{fig:laa8} 
\end{figure} 

\subsection{V��r�- ja oikeaoppinen tapa soveltaa periytymist�}

Tarkastellaan tilannetta, jossa mallinnetaan ohjelmistoyrityksen ty�ntekij�it�. Ohjelmistoyrityksess� ty�skentelee henkil�it� eri ty�teht�viss�, {\em m��rittelij�in�}, {\em suunnittelijoina}, {\em ohjelmoijina} ja {\em testaajina}. Nopeasti ajatellen kuvan \ref{fig:yleistys2} malli vaikuttaa hyv�lt� tavalta mallintaa tilanne.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{yleistys2}
    \caption{Huono tapa mallintaa ohjelmistoyrityksen ty�ntekij�it�}
    \label{fig:yleistys2} 
\end{figure} 

Malli vaikuttaa loogiselta, sill� kaikki ty�ntekij�th�n ovat Henkil�it�. T�m� on ainakin kuitenkin kahdella tapaa huono tapa tilanteen mallintamiseksi. 

Ensimm�inen ongelma liittyy tilanteeseen, jossa on tarvetta mallintaa   tilanne, jossa henkil� toimii useissa ty�teht�viss�, esim. sek� ohjelmoijana ett� testaajana. Kaksi huonoa tapaa yritt�� ratkaista t�m� ongelma on esitetty kuvassa \ref{fig:yleistys3}.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{yleistys3}
    \caption{Kaksi huonoa ratkaisuyrityst� mallintaa kaksi ty�teht�v�� omaava henkil�}
    \label{fig:yleistys3} 
\end{figure} 

Kuvan ylempi malli yritt�� ratkaista ongelman moniperinn�n avulla, eli uutta ty�teht�v�� kuvaava luokkaa {\em OhjelmoijaTestaaja} perii luokat {\em Ohjelmoija} ja {\em Testaaja}. Kuten edellisess� luvussa todettiin, useat ohjelmointikielet, kuten Java eiv�t tue moniperint��, joten idea on huono. 

Kuvan alemman mallin ratkaisu on uusi luokka {\em OhjelmoijaTestaaja} luokkahierarkiaan suoraan {\em Hen\-ki\-l�}-luokan alle. Nyt kierret��n moniperint�, mutta ratkaisu on silti huono, sill� uusi luokka ei hy�dynn� luokkien {\em Ohjelmoija} ja {\em Testaaja} m��rittelyj� mill��n tavalla. Ongelmallista on my�s se, jos yhdistelm�ty�teht�vien m��r� kasvaa. Jokaisesta mahdollista kombinaatiosta tulisi uusi luokka henkil�n alle.

Toisen ongelman muodostaa tilanne, jossa henkil� vaihtaa ty�teht�v��. Useimmissa ohjelmointikieliss� luokan tyyppi s�ilyy koko ohjelman suoritusajan samana, eli jos jostain on luotu {\em Ohjelmoija}, ei sama olio voi mill��n muuttua {Testaaja}-olioksi. 

N�iss� mallinnusyrityksiss� on syyllistytty siihen, ett� henkil�n {\em roolia} yrityksess� on yritetty mallintaa periytymishierarkian avulla. Monien kokeneiden oliomallintajien, esim. Peter Coadin mukaan t�m� on huono, mutta valitettavan yleinen tapa soveltaa periytymist� (ks. esim. \cite{Coad}).

Parempi tapa mallintaa tilannetta on pit�� luokka {\em Henkil�} kokonaan erillisen� ja liitt�� ty�teht�v�t, eli henkil�n rooli, siihen erillisin� luokkina. Luokka {\em Henkil�} kuvaa siis henkil�� itse��n ja sis�lt�� ainoastaan henkil��n liittyv�t tiedot kuten nimen ja osoitteen. Henkil��n liittyy yksi tai useampi {\em Ty�teht�v�} eli ty�ntekij�rooli. Ty�ntekij�roolit on mallinnettu periytymishierarkian avulla, eli jokainen henkil��n liittyv� rooli on jokin konkreettinen ty�ntekij�rooli, esim. {\em Ohjelmoija} tai  {\em Testaaja}. 

Tilanne on esitetty luokkakaaviona kuvassa \ref{fig:yleistys4}. Koska {\em Ty�teht�v�} on nyt ainoastaan k�site, jonka merkitys tarkentuu vasta sen periviss� luokissa, on se m��ritelty abstraktina luokkana, eli luokkana josta ei voi luoda ilmentymi�. UML:ssa abstraktien luokkien nimet kirjoitetaan kursiivilla.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=85mm]{yleistys4}
    \caption{Parempi tapa mallintaa ohjelmistoyrityksen ty�ntekij�t}
    \label{fig:yleistys4} 
\end{figure} 

Oikea tapa siis on kuvata mahdolliset roolit periytymishierarkian avulla ja liitt�� sopivia rooleja tarpeen mukaan henkil��n. N�in ei ole ongelmaa sille, ett� henkil�ll� on useita rooleja ja roolit vaihtuvat henkil�-olion olemassaolon aikana. 

Peter Coadin ohje onkin, ett� olion roolit tulee kuvata yhteyksien, ei periytymisen avulla. Roolityypit voidaan sitten kuvata periytymishierarkialla \cite{Coad}.

\subsection{Esimerkki monimutkaisemman rakenteen mallintamisesta}

Dokumentti koostuu tekstielementeist� ja kuvioista. Kuvio voi olla joko piste, viiva, ympyr� tai joku n�ist� koostuva monimutkaisempi kuvio. Miten tilanne kannattaisi mallintaa?

Ensimm�inen versio mallista on kuvassa \ref{fig:yleistys6}, eli dokumentti sis�lt�� useita tekstej� ja kuvioita. Teksti ja kuviot on mallinnettu omina luokkinaan joihin dokumentista on yhteys. Luokan Dokumentti operaatio {\em tulosta} aiheuttaa jokaisen kuvan sek� tekstin piirt�misen n�yt�lle:

{\small
\begin{verbatim}
class Dokumentti{
   void tulosta(){
      for each k in kuvat  k.piirra();
      for each t in tekstit t.piirra(); 
   }
}
\end{verbatim}
}

\begin{figure}[htbp]
    \centering
    \includegraphics[width=70mm]{yleistys6}
    \caption{Dokumentti koostuu tekstist� ja kuvioista}
    \label{fig:yleistys6} 
\end{figure} 

Tarkennetaan mallia luokan Kuvio osalta. Kuvio siis voi olla joko piste, viiva, ympyr� tai joku n�ist� koostuva monimutkaisempi kuvioiden kokoelma. Kuvio on siis yleisk�site, jota konkreettiset k�sitteet kuten piste, viiva ja ympyr�  tarkentavat. Onkin luonnollista mallintaa kuvio periytymishierarkiana.

Kuvio voi olla my�s kokoelma kuvioita. Termin kuvio m��ritelm� siis viittaa itseens�, eli on rekursiivinen. T�m� hiukan hankalalta vaikuttava tilanne kannattaa mallintaa kuvan \ref{fig:yleistys5} tapaan. 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=123mm]{yleistys5}
    \caption{Dokumentti koostuu teksteist� ja kuvioista. Kuvio voi olla yksinkertainen kuvio tai kokoelma kuvioita.}
    \label{fig:yleistys5} 
\end{figure} 

Kuviosta on nyt tehty abstrakti luokka, samoin kuvion operaatio {\em piirr�} on merkitty abstraktiksi, eli se on kirjoitettu kursiivilla. Operaation abstraktius tarkoittaa, ett� on operaatiosta on kiinnitetty ainoastaan nimi ja parametrit, mutta toteutusta sille ei ole annettu. Luokan erikoistavat aliluokat m��rittelev�t miten operaatio kussakin aliluokassa toteutetaan.

Jos kuvio on kokoelma, se {\em koostuu} useasta kuviosta, jotka voivat olla yksinkertaisia kuvioita (kuten viivoja) tai kokoelmia! Kuvan \ref{fig:yleistys7} oliokaavio ehk� helpottaa tilanteen ymm�rt�mist�. Kuvassa on dokumentti, joka koostuu kahdesta tekstist� sek� kolmesta kuviosta. Kuvioista kaksi ovat yksinkertaisia ({\em viiva} ja {\em ympyr�}) ja kolmas on kokoelma. Kokoelma taas koostuu kahdesta yksinkertaisesta kuviosta ({\em piste1} ja {\em piste2}) ja yhdest� kokokelmasta, joka taas koostuu kahdesta yksinkertaisesta kuviosta ({\em viiva2} ja {\em ympyr�2}).

\begin{figure}[htbp]
    \centering
    \includegraphics[width=105mm]{yleistys7}
    \caption{Oliokaavio dokumentista, joka koostuu kahdesta tekstist� ja kolmesta kuviosta}
    \label{fig:yleistys7} 
\end{figure} 

Operaation {\em piirr�} toteutuksesta kannattaa mainita muutama sana. Aliluokissa {\em piste}, {\em viiva} ja {\em ympyra} operaatio toteutetaan todenn�k�isesti suoraan alla olevan ohjelmointiymp�rist�n piirtokomennolla. Aliluokan {\em Kokoelma} piirto-operaatio sensijaan ainoastaan delegoi piirtovastuun kaikille sis�lt�milleen {\em Kuvio}-olioille.  Eli kokoelmakuvio piirt�� itsens� pyyt�m�ll� kaikkien sis�lt�miens� kuvioiden pirt�m��n itsens�: \\

{\small
\begin{verbatim}
class Kokoelma extends Kuvio {
   void piirra(){
      for each k in kuviot  k.piirra(); 
   }
}
\end{verbatim}
}

Mallia voitaisiin viel� yleist�� hiukan. Dokumentissa voisi olla muunkinlaisia rakenne-elementtej� kuin teksti� ja kuvioita, esim. taulukoita. Voitaisiinkin ajatella, ett� dokumentti koostuu elementeist�. Elementti voi olla joko taulukko, teksti tai kuvio. Jotta dokumentin aikaansaamassa kokonaisuudessa olisi j�rke�, ovat elementit dokumentissa tietyss� j�rjestyksess�. Kuvassa \ref{fig:yleistys8} on malli, miss� n�m� ajatukset on huomioitu. Elementtien j�rjestys merkit��n yhteyteen liitetyll� m��reell� {\em ordered}. 

\begin{figure}[htbp]
    \centering
    \includegraphics[width=110mm]{yleistys8}
    \caption{Dokumentti koostuu erilaisista elementeist�. Elementit voivat olla taulukoita, teksti� tai kuvioita ja elementeill� on j�rjestys.}
    \label{fig:yleistys8} 
\end{figure} 

Luokan Dokumentti operaatio {\em tulosta} n�ytt�� nyt seuraavanlaiselta:

{\small
\begin{verbatim}
class Dokumentti {
   Elementti[] elementit;

   void tulosta(){
      for ( i=0 ; i < elementit.length; i++  )
        elementit[i].piirra(); 
   }
}
\end{verbatim}
}

Dokumentti siis tuntee joukon elementtej�, jotka se tallettaa taulukkoon {\em elementit}. Taulukossa voi siis olla mit� elementtej� tahansa: teksti�, taulukoita tai kuvioita. Dokumentin ei tarvitse edes tiet�� kunkin elementin oikeaa tyyppi�. Tulostusoperaatiossa kutsutaan kullekin elementille operaatiota {\em piirr�}. Elementit piirret��n taulukon m��rittelem�ss� j�rjestyksess�. Kunkin elementin piirtyminen siis m��rittyy elementin oikean tyypin mukaan. 

T�ss� luvussa esitetty tapa koosteisen tiedon esitt�miseen on hyvin yleisesti tunnettu. Englanniksi tavasta k�ytet��n nimityst� {\em composite pattern} \cite{GOF}.














\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%55
%
%
%
%
%
%
%

\section{Olioiden yhteisty�n mallintaminen}

%{\em Sekvenssikaavioiden} (engl. sequence diagram) avulla voidaan kuvata ohjelman olioiden vuorovaikutusta yksitt�isiss� toimintaskenaarioissa. Sekvenssikaavio siis n�ytt�� miten oliot kommunikoivat tietyss� tilanteessa. Koko j�rjestelm�n toiminnallisuuden kuvaamiseen tarvitaan siis useita sekvenssikaavioita. Tyypillisesti yksi sekvenssikaavio kuvaa esim. k�ytt�tapauksen mukaisen toiminnallisuuden tai jonkin osan siit�.

Olioj�rjestelm�n toiminta perustuu olioiden yhteisty�h�n. Yhteisty� ei tule esiin luokka- tai oliokaavioissa. Luokkakaaviossa esitet��n ohjelman {\em staattinen rakenne}, eli luokkien attribuutit, operaatiot ja luokkien v�liset suhteet. Vaikka luokkakaavioihin voidaan merkit� luokkien operaatiot, eli niiden tarjoamat palvelut, ei luokkakaaviosta kuitenkaan n�y miten palvelun suoritus hy�dynt�� muita palveluita tai muita olioita. Yhteisty�n selvitt�minen on kiinte�sti sidoksissa olioiden palveluiden m��rittelyyn, sill� yhteisty� toteutuu palvelujen kautta. Samalla kun m��rittelemme oliolle palveluja meid�n tulisi ottaa kantaa siihen, millaista yhteisty�t� olioiden v�lill� palvelun suorittamiseen liittyy. Palvelujen ja olioyhteisty�n m��rittely on ohjelmiston teknisen suunnittelun teht�vi�. N�m� tehd��n siis my�hemmin kuin sovellusalueen kannalta keskeisten luokkien m��rittely, joka tapahtuu jo ohjelmiston m��rittelyvaiheessa. 

UML tarjoaa kaksi tekniikkaa olioiden yhteisty�n kuvaamiseen: sekvenssikaavion ja kommunikaatiokaavion. {\em Sekvenssikaaviossa} (engl. sequence diagram) keskityt��n kuvaamaan operaatioiden suoritusj�rjestyst� ja kontrollin etenemist� oliolta toiselle. {\em Kommunikaatiokaavioissa} (engl. communication diagram) kuvataan erityisesti sit�, miten yhteisty� perustuu olioiden v�lisiin yhteyksiin. Suoritusj�rjestys ja kontrollin eteneminen kuvataan my�s, mutta ei yht� helppolukuisesti kuin sekvenssikaavioissa.  

Sekvenssikaaviot ja kommunikaatiokaaviot siis kummatkin ovat tarkoitettu ohjelman olioiden vuorovaikutuksen, eli ohjelman {\em dynaamisen toiminnan} mallintamiseen. On l�hinn� makuasia kumpaa kaaviotyyppi� miss�kin tilanteessa k�ytt��. Kannattaakin valita mallinnustilanteen kannalta luontevammalta tuntuva kaaviotyyppi. Sekvenssikaavio lienee kaavioityypeist� suositumpi. 

\subsection{Sekvenssikaavio}

%{\em Sekvenssikaavioiden} (engl. sequence diagram) avulla voidaan kuvata ohjelman olioiden vuorovaikutusta yksitt�isiss� toimintaskenaarioissa. Sekvenssikaavio siis n�ytt�� miten oliot kommunikoivat tietyss� tilanteessa. Koko j�rjestelm�n toiminnallisuuden kuvaamiseen tarvitaan siis useita sekvenssikaavioita. Tyypillisesti yksi sekvenssikaavio kuvaa esim. k�ytt�tapauksen mukaisen toiminnallisuuden tai jonkin osan siit�.

Sekvenssikaavio kuvaa tietyn palvelun suorittamiseen liittyv�n olioiden yhteisty�n tai osan siit�. Kuvattava palvelu voi olla j�rjestelm�n palvelu (k�ytt�tapaus) tai johonkin luokkaan liittyv� palvelu.  Sekvenssikaaviossa esitet��n, mit� avustavia olioita palvelun suoritukseen osallistuu ja mit� n�iden palveluita k�ytet��n. Kaavio kuvaa my�s miss� j�rjestyksess� avustavien olioiden palveluja k�ytet��n. Kuva \ref{fig:sekv1} esittelee kaaviotekniikassa k�ytett�vi� symboleja.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{sekv1}
    \caption{Esimerkki sekvenssikaaviosta}%
    \label{fig:sekv1} % Huomaa \label-komennon paikka!
\end{figure}

Sekvenssikaaviossa olio kuvataan suorakaiteena, jonka sis�ll� on olion tunnus. Tunnus kirjoitetaan samassa muodossa kuten oliokaavioissa, eli alleviivattuna muodossa {\em olioNimi:Luokka}, joista olion nimen tai luokan voi halutessaan j�tt�� pois. 

Suorakaiteesta alasp�in l�htev� katkoviiva kuvaa olion elinkaarta. Viivalla olevalla laatikolla eli {\em aktivaatiopalkilla} merkit��n, ett� olio on aktiivisena eli olion jonkin operaation suoritus on menossa. Aika usein aktivaatiopalkki j�tet��n merkitsem�tt�, varsinkin jos sekvenssikaavioita piirret��n paperille.

Olio pyyt�� avustavalta oliolta palvelua l�hett�m�ll� t�lle viestin. Olio-oh\-jel\-mas\-sa viestin l�hett�minen tarkoittaa yleens� metodikutsua (esim. Javassa). Jatkossa k�ytet��n olioille tapahtuvasta palvelupyynn�st� my�s nimityst� operaatiokutsu. Kaaviossa viestin l�hett�minen kuvataan l�hett�j�lt� vastaanottajalle menev�n� nuolena. Nuoleen liitet��n tekstin� l�hetett�v� viesti. Yleens� t�m� muodostuu pyydett�v�n palvelun nimest� ja pyynn�n yhteydess� v�litett�vist� parametreista. Olioiden metodit voivat tuottaa paluuarvon. Paluuarvon palautus merkit��n kaavioon tarpeen vaatiessa katkoviivallisena nuolena. Vaihtoehtoinen tapa merkit� paluuarvon vastaanotto on k�ytt�� merkint�� $vast := oper(param)$, joka tarkoittaa, ett� kutsuttavan metodin paluuarvo otetaan vastaan muuttujaan $vast$. 

Kuva \ref{fig:sekv1} alkaa tilanteesta, miss� {\em olioA}:n palvelua {\em oper1} kutsutaan. Aika kuluu sekvenssikaaviossa alasp�in, eli mit� ylemp�n� viesti on, sit� aiemmin se on l�hetty. {\em OlioA} kutsuu {\em olioB}:n palvelua {\em oper2}. Palvelukutsuun liittyy parametri. {\em OlioB} kutsuu ensin omaa palveluaan {\em oper3}, jonka j�lkeen se kutsuu {\em olioC}:n palvelua {\em oper4} ottaen palvelun palauttaman vastauksen muuttujaan x. {\em OlioB} palauttaa lopussa paluuarvon {\em olioA}:lle. Huomaa, ett� {\em OlioB}:n paluuarvon palautus {\em OlioA}:lle on merkitty kuvaan katkoviivalla. Paluuarvon merkitseminen on siis vapaaehtoista.

Sekvenssikaaviossa aika siis etenee alasp�in. Sekvenssikaavion perusteella ei kuitenkaan voi tehd� johtop��t�ksi� operaatiokutsujen kestoajoista. Kuvan \ref{fig:sekv1} perusteella tiedet��n esim. ett� $olioB$:n palvelun $oper2$ suoritus kest�� varmuudella kauemmin kuin $olioC$:n palvelun $oper4$ suoritus. Vaikka kuvan perusteella n�ytt��, ett� $oper2$:n suoritusaika on noin kaksinkertainen $oper4$:n suoritusaikaan verrattuna, ei operaatioiden suoritusaikojen pituutta ei kuitenkaan voida p��tell� suoritusten aktivaatiopalkkien pituudesta.\footnote{UML mahdollistaa operaatioiden kestoaikojen ym. aikainformaation merkitsemisen sekvenssikaavioihin. T�ll� kurssilla aikainformaatiota ei kuitenkaan k�sitell�.} 

K�ytimme kuvassa "t�ytetty�"~eli suljettua nuolenp��t� palvelukutsujen yhteydess�. Sekvenssikaavioissa k�ytet��n joskus my�s avointa nuolenp��t� $\rightarrow$. Suljetulla nuolenp��ll� merkitty palvelukutsu tarkoittaa {\em synkronista} kutsua, eli kutsuja odottaa ja jatkaa vasta kun kutsu on suoritettu. Avoimella nuolenp��ll� merkitty kutsu taas tarkoittaa {\em asynkronista} kutsua, eli kutsuja ei j�� odottamaan operaation suoritusta vaan jatkaa v�litt�m�sti. Javalla ohjelmoinnissa kaikki metodikutsut ovat synkronisia operaatioita, eli kutsuja jatkaa vasta kun kutsuttu metodi on suoritettu.\footnote{Jos ohjelma koostuu useista s�ikeist�, voivat jotkut metodikutsut olla asynkronisia.} Esim. tekstiviestin l�hett�minen on asynkroninen toimenpide, eli l�hett�j� jatkaa heti muihin toimiin kun tekstiviesti on l�hetetty. Viesti menee perille l�hett�j�lle ennemmin tai my�hemmin. Erityisesti paperille piirrett�viss� luonnosmaisissa sekvenssikaavioissa nuolenp�iden laatuun ei ole aina kiinnitetty huomiota, eli avoimesta nuolenp��st� huolimatta mallintaja saattaa joskus tarkoittaa synkronista palvelukutsua.

Tarkastellaan toisena esimerkkin� j�rjestelm��, joka pit�� kirjaa yrityksen ty�ntekij�ist�. Osa j�rjestelm�n luokkakaaviosta on kuvassa \ref{fig:sekv1d}.
Jokaisen ty�ntekij�n tiedot on koottu luokkaan {\em Henkil�}. Luokka {\em Ty�ntekij�t} sis�lt�� kokoelman Henkil�-olioita ja j�rjestelm�� k�ytet��n {\em k�ytt�liittym�}-olion kautta.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{sekv1d}
    \caption{Osa ty�ntekij�iden hallintaj�rjestelm�n luokkakaaviosta}
    \label{fig:sekv1d} 
\end{figure}

Kuvassa \ref{fig:sekv1c} on esitetty sekvenssikaaviona tilanne, jossa asetetaan parametrina annetulle henkil�lle henkil�lle palkka. K�ytt�liittym�olio kutsuu ensin Ty�ntekij�t-luokan olion operaatiota, joka palauttaa viitteen nimell� haettuun Henkil�-olioon. Sek\-venssikaaviossa paluuarvo $h$ viittaa etsittyyn Henkilo-olioon. Saatuaan viitteen, kutsuu k�ytt�liittym� l�ydetyn Henkil�-olion operaatiota, joka asettaa uuden palkan.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{sekv1c}
    \caption{Palkkatiedon p�ivitys}
    \label{fig:sekv1c} 
\end{figure}

Luokan {\em K�ytt�liittym�} metodin {\em asetaPalkka} ohjelmakoodi voisi n�ytt�� tilanteessa seuraavanlaiselta:

{\small
\begin{verbatim}
Class Kayttoliittyma{
   Tyontekijat tyontek;   // viite luokan Tyontekijat olioon

   void asetaPalkka(String nimi, int euroa){
      Henkilo h = tyontek.haeHenkilo();   
      h.asetaPalkka(euroa);
   }
}
\end{verbatim}
}

\subsection{J�rjestelm�tason sekvenssikaaviot} \label{sec:ssd}

Sekvenssikaavioita siis k�ytet��n usein ohjelmiston teknisess� suunnittelussa hahmoteltaessa olioiden yhteisty�t�. Sekvenssikaavioita voidaan k�ytt�� my�s vaatimusm��rittelyn yhteydess� kuvaamaan k�ytt�tapauksiin liittyv�� k�ytt�j�n interaktiota j�rjestelm�n kanssa. T�ll�in vuorovaikutus siis tapahtuu k�ytt�tapauksen k�ytt�jien ja j�rjestelm�n kesken, eli koko j�rjestelm� n�hd��n yhten� oliona tai "mustana laatikkona".

Tarkastellaan esimerkkin� yksinkertaista lippupalveluj�rjestelm�� ja sen k�ytt�tapausta {\em Lipun varaus, tilanne miss� lippuja l�ytyy}. K�ytt�tapauksen kulku:

\begin{enumerate} \addtolength{\itemsep}{-0.5\baselineskip}
\item K�ytt�j� kertoo esiintyj�n ja esitysp�iv�n 
\item J�rjestelm� kertoo, mink� hintainen lippu on mahdollista ostaa
\item K�ytt�j� hyv�ksyy lipun
\item K�ytt�j�lle annetaan tulostettu lippu
\end{enumerate}

K�ytt�tapauksen kulku on esitetty kuvan \ref{fig:sekv2} sekvenssikaaviossa. Huomaa, ett� suorituksen kontrollia ilmaisevia aktivaatiopalkkeja ei ole merkitty kuvaan.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=60mm]{sekv2}
    \caption{J�rjestelm�tason sekvenssikaavio}
    \label{fig:sekv2} 
\end{figure}

Normaalisti sekvenssikaavio kuvaa ainoastaan yhden suoraviivaisesti etenev�n tapahtumaketjun. Jos halutaan kuvata vaihtoehtoisia tapahtumaketjuja, tarvitaan useita sekvenssikaavioita. 

Lipunvarausj�rjestelm�n toisen k�ytt�tapaksen {\em Lipun varaus, tilanne miss� lippuja l�ytyy, mutta k�ytt�j� peruu ostoksen} kulku on seuraava:

\begin{enumerate} \addtolength{\itemsep}{-0.5\baselineskip}
\item K�ytt�j� kertoo esiintyj�n ja esitysp�iv�n 
\item J�rjestelm� kertoo, mink� hintainen lippu on mahdollista ostaa
\item K�ytt�j� peruu ostoksen
\end{enumerate}

Kuvassa \ref{fig:sekv3} k�ytt�tapausta vastaava sekvenssikaavio. Hetken p��st� tutustumme menetelm��n, joka mahdollistaa valinnaisuuden kuvaamisen sekvenssikaaviossa. Valinnaisuutta hyv�ksik�ytt�en esimerkkimme molemmat k�ytt�tapaukset olisi voitu kuvata yhden sekvenssikaavion avulla.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=60mm]{sekv3}
    \caption{J�rjestelm�tason sekvenssikaavio, vaihtoehtoinen skenaario}
    \label{fig:sekv3}
\end{figure}

Vaatimusm��rittelyss� teht�v�t j�rjestelm�tason sekvenssikaaviot tarkentuvat ohjelman teknisess� suunnittelussa. Kuvassa \ref{fig:sekv4} hahmotelma lippupalveluj�rjestelm�n suunnitteluvaiheen sekvenssikaaviosta. Edellisten kuvien j�rjestelm� on nyt tarkentunut kolmeksi olioiksi, eli k�ytt�liittym�ksi, tietokannaksi ja tulostimeksi. Huomaa, miten parametreja v�litet��n eri olioiden kesken. Oliden tekniseen suunnitteluun palaamme tarkemmin monisteen luvussa \ref{sec:osa4}.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=130mm]{sekv4}
    \caption{Suunnittelutason sekvenssikaavio}%
    \label{fig:sekv4} 
\end{figure}

\subsection{Toisto ja valinnaisuus sekvenssikaavioissa}

Sekvenssikaavioihin voidaan tarvittaessa sis�llytt�� valinnaisuutta. Kuvassa \ref{fig:sekv5} termostaatti selvitt�� ensin l�mp�mittarilta l�mp�tilan. Jos l�mp�tila on liian alhainen laitetaan l�mmitin isommalle, jos taas l�mp�tila on liian korkea, laitetaan l�mmitin pienemm�lle. Valinnaisuutta kuvaa erillinen lohko, jonka nurkassa on tunniste {\em alt} (lyhenne sanasta alternative). Lohko on jaettu vaihtoehtoisiin osiin, ja se osa suoritetaan, jota vastaava ehto on tosi. Ehto esitet��n hakasulkeissa. Jos mik��n muu ehdon haara ei ole tosi, suoritetaan else-osa. Eli kuvassa l�mmittimelle ei tehd� mit��n jos on l�mp�tila v�lill� 20-25.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{sekv5}
    \caption{Valinta sekvenssikaaviossa}
    \label{fig:sekv5} 
\end{figure}
 
My�s toiston kuvaaminen on mahdollista. Toisto esitet��n lohkolla, jonka yl�laidassa on tunniste {\em loop}. Toistoehto kirjoitetaan hakasulkeisiin.
Kuvassa \ref{fig:sekv6} editori l�hett�� tiedostoa tulostimelle rivi rivilt�. Tulostusehdoksi on kirjoitettu {\em for each sivu in tiedosto} ja toistettava viesti on {\em print(sivu)}, eli jokainen tiedoston sivu l�hetet��n tulostimelle yksitellen print-operaation parametrina.

Ehdoissa k�ytett�v�t merkint�tavat ovat mallintajan vapaasti valittavissa. P��periaate on tehd� ehdoista mahdollisimman selke�t. T�ss� esimerkiss� ehdoksi olisi voitu kirjoittaa yht� hyvin esim. {\em [tulostetaan tiedoston kaikki sivut]}.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=80mm]{sekv6}
    \caption{Toisto sekvenssikaaviossa}
    \label{fig:sekv6}
\end{figure}

\subsection{Uudet ja tuhoutuvat oliot sekvenssikaaviossa}

Kuva \ref{fig:sekv7} tarkentaa edellist� esimerkki�. Nyt my�s editoitava tiedosto esitet��n omana oliona. Editorin saadessa tiedoston avauskomennon, luo se tiedostoa edustavan olion. Tietosto-olio lataa tiedoston sis�ll�n levylt� kutsumalla luokassa itsess��n m��riteltyn� olevaa lataa-operaatiota.
Kuvasta n�emme, miten sekvenssikaavioon merkit��n uuden olioiden luominen. Skenaarion aikana syntyvi� olioita ei siis merkit� yl�laitaan, vaan uusi olio tulee kaavioon sille korkeudelle, miss� olion synnytt�v� viesti on. Olion luovan operaation voi nimet� kostruktorikutsun tapaan.

T�m�n j�lkeen toistorakenne kuvaa, ett� k�ytt�j� editoi tiedostoa niin kauan kuin haluaa. Muutokset p�ivittyv�t muistissa olevaan tiedosto-olioon.

Editoinnin j�lkeen tiedosto tulostetaan. Editori v�litt�� tulostuskomennon tiedosto-oliolle, joka tulostaa itsens� pyyt�m�ll� tulostinta tulostamaan jokaisen sivun.

Kun k�ytt�j� pyyt�� tiedoston tallennusta, vie tie\-dos\-to-olio sis�lt�ns� levylle siin� tapauksessa, ett� sis�lt� on muuttunut.  Kuten kuvasta \ref{fig:sekv7} n�hd��n, tallennuksen ehdollisuus esitet��n lohkolla, jonka tunnisteena on {\em opt}, eli jos ehto toteutuu, suoritetaan lohkon sis�lt�, muuten hyp�t��n sen yli.

Lopussa k�ytt�j� sulkee tiedoston. Editori tuhoaa tiedosto-olion muistista. Olion tuhoutuminen merkit��n olion elinviivan p��tt�v�n� rastina.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{sekv7}
    \caption{Toistoa ja valinnaisuus}
    \label{fig:sekv7} 
\end{figure}


\subsection{Takaisinmallinnus}

Yksi UML:n hy�dyllisimpi� k�ytt�tarkoituksista on {\em takaisinmallinnus} (engl. reverse engineering) eli kaavioiden laatiminen valmiista ohjelmakoodista l�htien. T�m� on tarpeen esim. opeteltaessa ymm�rt�m��n huonosti dokumentoitua ohjelmaa, jota on tarve yll�pit��. 

Seuraavassa esimerkki Javalla ohjelmoidusta kellosta. Kello koostuu viisareista. Seuraavassa viisarin koodi:

{\small 
\begin{verbatim}
class Viisari{
  int max;      // arvo, jonka saavutettuaan viisari py�r�ht�� nollaan
  int arvo;

  Viisari( int m ){ arvo = 0;  max = m; }

  void etene(){
    arvo++;
    if ( arvo==max ) arvo = 0; 
  }   

  int aika(){ return arvo; }
}

\end{verbatim}
}

Kello luo konstruktorissaan kolme viisaria. Kellon metodi {\em etene} vie aikaa yhden sekunnin eteenp�in. Riippuen ajasta t�m� saattaa vaatia useamman viisarin edist�misen. Eli normaalisti vain sekuntiviisari etenee. Jos sekuntiviisari py�r�ht�� nollaan etenemisen yhteydess�, my�s minuuttiviisari etenee, jne \ldots. Kutsuttaessa metodia {\em nayta} kello kysyy kunkin viisarin arvon ja tulostaa ajan ruudulle. 

{\small
\begin{verbatim}
class Kello {
  Viisari tunti;
  Viisari minuutti;
  Viisari sekunti;

  Kello(){
    sekunti  = new Viisari(60);    
    minuutti = new Viisari(60);
    tunti    = new Viisari(24);
  }

  void etene(){
    sekunti->etene();
    if ( sekunti->aika()==0 ) {
      minuutti->etene();
      if ( minuutti->aika()==0 ) 
        tunti->etene();
    }
  }

  void nayta(){
    System.out.print( tunti->aika() );   System.out.print(":");
    System.out.prin( minuutti->aika() ); System.out.print(":");
    System.out.print( sekunti->aika() );  
  }
}
\end{verbatim}
}

Kuvassa \ref{fig:kello1} Kellon luokkakaavio. Luokkakaavio ei kerro juuri mit��n ohjelman toiminnan logiikasta ja sekvenssikaavioiden merkitys on luokkakaaviota t�rke�mpi ohjelman toiminnan ymm�rt�misen kannalta.

\begin{figure}[htbp]
    \centering
    \includegraphics[height=27mm]{kello1}
    \caption{Kellon luokkakaavio}
    \label{fig:kello1}
\end{figure}

Kuvassa \ref{fig:kello2} sekvenssikaavio, jossa on n�ytetty kellon ja viisareiden luonti, eteneminen sekunnilla ja kellon arvon tulostus. 
Sekvenssikaavioon on merkitty ainoastaan ohjelman sovellusolioiden keskin�iset metodikutsut. Kello-luokan oliohan kutsuu my�s Javan standardikirjaston System.out-olion metodia print, mutta kutsu on j�tetty merkitsem�tt� koska se on t�ss� yhteydess� ep�oleellinen.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=120mm]{kello2}
    \caption{Kellon eteneminen ja ajan n�ytt�minen sekvenssikaaviona}
    \label{fig:kello2}
\end{figure}

Kuvassa \ref{fig:kello3} viel� tilanne, jossa kello etenee siten, ett� sek� sekuntti, minuutti ett� tuntiviisari py�r�ht�v�t nollaan. Huomaa, ett� kuvaan ei ole merkitty viisareiden aika-metodien kutsuja. Sekvenssikaavioon kannataakin aina merkit� vain sen verran tietoa, mik� on luettavuuden ja ymm�rrett�vyyden kannalta tarpeen.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=100mm]{kello3}
    \caption{Kellon etenemist� tasatunnilla kuvaava sekvenssikaavio}
    \label{fig:kello3}
\end{figure}

Takaisinmallinnuksessa kannattaa edet� yleens� siten, ett� luokkamallia ja sek\-venssikaavioita piirret��n rinnakkain esim. suorittamalla ohjelmaa askel askeleelta debuggerilla ja samalla piirt�en sekvenssikaavioon ohjelman etenemist� ja t�ydent�en luokkamalliin suorituksessa k�ytett�vi� luokkia.
%K�ym�ll� useita skenaarioita l�pi ja koodia tutkimalla, alkaa ohjelman rakenne hahmottumaan ja tarpeen vaatiessa luokkamallia voi t�ydent��.

Useinkaan ei ole t�rke��, ett� esim. takaisinmallinnettu luokkamalli sis�lt�� ohjelman kaikki luokat ja niiden v�liset suhteet. T�rkeint� takaisinmallinnuksessa on p��st� selville ohjelman toteutuksen logiikasta ja havaita mitk� luokat ja metodit ovat kulloisenkin k�ytt�tarpeen kannalta oleellisia.

Jotkut sovelluskehittimet pystyv�t luomaan ainakin luokkamalleja annetusta koodista automaattisesti.

\subsection{Kommunikaatiokaavio}

Vaihtoehtoinen tapa esitt�� olioiden yhteistoimintaa on {\em kommunikaatiokaavioiden} (engl. communication diagram) k�ytt�.\footnote{Kommunikaavioiden nimi oli vanhan UML-standardin mukaan yhteistoimintakaavio (engl. collaboration diagram).} Sekvenssikaavioiden tapaan kommunikaatiokaaviot kuvaavat yksitt�isen tapahtumaskenaarion aikaisen olioiden yhteistoiminnan.

Kuvassa \ref{fig:kom1} on esitetty kommunikaation avulla sivun 
\pageref{fig:sekv1c} ty�ntekij�hallintaj�rjestelm�esimerkin tilanne, jossa 
asetetaan parametrina annetulle henkil�lle henkil�lle palkka.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=85mm]{kom1}
    \caption{Palkkatiedon p�ivitys kommunikaatiokaaviona}
    \label{fig:kom1}
\end{figure}

Kommunikaatiokaaviossa keskityt��n kuvaamaan miten olioiden yhteisty� hy�dynt�� olioiden v�lisi� yhteyksi�. Kaavio esittelee tiettyyn suoritukseen liittyv�t oliot ja niiden yhteydet sek� suoritukseen liittyv�t operaatiokutsut. Operaatiokutsujen ajallinen j�rjestys selvi�� numeroinnista. 

Kuvassa \ref{fig:kom2} kellon toimintaa esittelev� kommunikaatiokaavio
(vastaava sekvenssikaavio kuvassa \ref{fig:kello2}). Esimerkiss� on k�ytetty operaatioille vaihtoehtoista numerointitapaa, eli hierarkista numerointia. Skenaario alkaa operaatiolla $etene$, joka aiheuttaa sekuntiviisarin kasvatuksen, eli viisari suorittaa operaatiot $etene$ ja $aika$. Kelloon kohdistuva operaatio on numeroltaan 1 ja sen aiheuttamat kellon suorittamat operaatiokutsut on numeroitu 1.1 ja 1.2. Seuraavaksi suoritetaan kellon operaatio $nayta$, joka aiheuttaa jokaiselle viisarille operaation $aika$. N�m� on numeroitu $2, 2.1, 2.2$ ja $2.3$

K�ytett�ess� kommunikaatiokaaviossa hierarkista operaationumerointia, suoritusj�rjestys siis on $1, 1.1, 1.2, \ldots, 2, 2.1, 2.2, \ldots, 3., 3.1, 3.2, \ldots$. Ideana on, ett� ylemm�n tason operaation aiheuttamat olioiden vuorovaikutukset numeroidaan yl�tason numeron alle tulevana numerointina.

\begin{figure}[htbp]
    \centering
    \includegraphics[width=90mm]{kom2}
    \caption{Kellon toimintaa kuvaava kommunikaatiokaavio}
    \label{fig:kom2}
\end{figure}

Kommunikaatiokaavio on sekvenssikaaviota parempi valinta yhteistoiminnan kuvaamiselle niiss� tapauksissa, miss� halutaan korostaa olioiden v�lisi� yhteyksi�. Vaikka kommunikaatiokaaviokin sis�lt�� tiedon operaatioiden suoritusj�rjestyksest�, tulee asia selke�mmin esille sek\-venssikaaviossa.
Jos viestej� on paljon, saattaa kommunikaatiokaavio olla kompaktimpi esitysmuoto kuin sekvenssikaavio. %Itse suosin sekvenssikaavioita ja kommunikaatiokaavioita esiintyy monisteessa ainoastaan muutamia.










