% Tämä tex-tiedosto toimii ensimmäisen syklin syötetiedostona, joka kattaa ohma-luentomonisteen toisen luvun (muokattu tiedostosta osa2.tex).

\documentclass{article}
\usepackage{graphicx}
\graphicspath{{kuvat/}}	
\begin{document}

\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).

\bibliographystyle{plain}

\bibliography{lahteet}
\end{document}

