Page 1

CFGS.DAW.M5: Entorns de desenvolupament

UF3. Introducció al disseny orientat a objectes

Introducció al Disseny Orientat a Objectes Casos d'ús 1 Introducció El model de cas d'ús descriu el sistema en termes de les seves diferents formes d'utilització, cadascuna de les quals es coneix com un cas d'ús. Cada cas d'ús o flux es composa d'una seqüència d'events iniciada per l'usuari. Per exemple, un cas d'ús per a conduir un cotxe seria la seqüència d'events des que el conductor entra al cotxe i engega el cotxe fins arribar al seu destí final. Per tant, per a comprendre els casos d'ús d'un sistema primer és necessari conèixer quins són els seus usuaris. En l'exemple, conduir un cotxe és diferent d'arreglar-lo, ja que els usuaris són diferents, el conductor i el mecànic. Per això es defineix el concepte d'actor, que és el tipus d'usuari involucrat en la utilització del sistema, i que a més és una entitat externa al propi sistema. Junts, l'actor i el cas d'ús són els dos elements bàsics del model.

1 de 7

Olga Schlüter


CFGS.DAW.M5: Entorns de desenvolupament

UF3. Introducció al disseny orientat a objectes

2 Actors En la terminologia orientada a objectes, es considera a l'actor una classe d'usuari, mentre que els usuaris serien els objectes o instàncies d'aquesta classe. Un mateix usuari pot aparèixer com a diferents instàncies de diferents actors. Els actors modelen qualsevol entitat externa que necessiti intercanviar informació amb el sistema. Per tant, no estan restringits a ser persones físiques. Abans d'identificar els casos d'ús, s'identifiquen els actors del sistema, per a què ens siguin útils per a trobar després els casos d'ús. Un cop tenim actors i casos d'ús definits, es passa a establir la funcionalitat del sistema. Per a especificar els actors d'un sistema, es dibuixa un diagrama corresponent a la delimitació del sistema. Per exemple, un sistema de computació pot tenir diferents tipus d'usuaris: programadors, operadors, administradors o usuaris generals.

No es descriuen els actors amb massa detall per ser externs al sistema. A més a més, les seves accions no són deterministes: en cada moment pot escollir entre diferents opcions. Però el sistema i els casos d'ús corresponents sí que ho hauran de ser. Aquells actors que són la raó principal del sistema s'anomenen actors primaris. Són els que regeixen la seqüència d'execució del sistema. Els actors que supervisen i mantenen el sistema s'anomenen actors secundaris i existeixen primordialment com a complement als primaris. Tendeixen a respondre a seqüències lògiques del sistema i en general corresponen a màquines o sistemes externs, mentre que els actors primaris normalment són persones físiques. Sempre existeix el dubte si el SSOO o una BD serien actors. La decisió depèn de la funció que desenvolupi respecte al sistema. Si realitzen una funció activa, llavors s'hauran de modelar com a actors.

2 de 7

Olga Schlüter


CFGS.DAW.M5: Entorns de desenvolupament

UF3. Introducció al disseny orientat a objectes

Quan diferents actors realitzen rols similars, poden heretar d'un actor abstracte comú. La resta d'actors s'anomenen actors concrets.

3 Casos d'ús Després d'haver definit als actors del sistema, s'estableix la funcionalitat pròpia del sistema mitjançant els casos d'ús. Cada cas d'ús defineix una classe o forma particular d'utilitzar el sistema. Cada cas d'ús constitueix un flux complet d'events que especifiquen la interacció que hi ha entre actor i sistema. L'actor primari és el que inicia aquesta interacció, i els casos d'ús s'instancien com a resposta a l'event iniciat. Les diferents instàncies dels casos d'ús es coneixen com a escenaris. Per a identificar els casos d'ús, s'hauran de discutir amb els actors les respostes a les següents preguntes: a) Quines són les tasques de cada actor? b) L'actor haurà de consultar i modificar informació del sistema? c) L'actor haurà d'informar sobre canvis externs? d) Vol l'actor ser informat de canvis inesperats?

3 de 7

Olga Schlüter


CFGS.DAW.M5: Entorns de desenvolupament

UF3. Introducció al disseny orientat a objectes

Els noms dels casos d'ús han de respondre a accions i no a substantius. La identificació dels casos d'ús és una tasca iterativa, on es faran múltiples revisions fins a arribar a la solució final estable. Tot i que la idea del model de casos d'ús és que els diagrames siguin el més senzills possible, sovint és necessari comptar amb mecanismes que permetin estendre els diagrames de manera més elaborada. El model de casos d'ús permet la subdivisió de parts del flux complet d'un cas d'ús en casos d'ús separats. Les raons són aprofitar diferents subfluxos que es repeteixen en múltiples casos d'ús, de manera anàloga al concepte d'herència . En general, no és obvi quins subfluxos haurien de definir-se com a casos d'ús separats. Existeixen 2 enfocs: a) Si les diferències entre els casos d'ús són petites, aquests es poden descriure com a variants d'un mateix cas d'ús, donant lloc al concepte de subluxos o ramificacions de fluxos dins d'un mateix cas d'ús. Per exemple, en el cas de Registrar usuari, la creació per primera vegada del registre i la seva actualització es poden considerar 2 seqüències d'events lògicament similars, per la qual cosa es tracten com a diferents subfluxes dins del mateix cas d'us que es descriuran a la seva fitxa. Primer es descriu el flux principal, el més important del cas d'ús i després els fluxos alterns. b) Si les diferències entre els casos d'ús són grans, s'han de descriure com a casos d'ús separats. Per a això, s'utilitzen les relacions d'extensió, inclusió i generalització.

Extensió S'especifica com un cas d'ús pot inserir-se en un altre per a estendre la funcionalitat de l'anterior. El cas d'ús on s'inserirà la nova funcionalitat ha de ser un cas complet, per tant ha de ser independent del nou cas ús inserit. En general, l'extensió s'utilitza per a modelar seqüències d'events opcionals de casos d'ús, que al gestionar-se de manera independent poden agregar-se o eliminar-se del sistema de manera modular. Es descriuen primer els casos d'ús bàsics, totalment independents de qualsevol extensió de funcionalitat i després els d'extensió. Per exemple, en un sistema de reserves (d'habitacions d'hotel, de vols, etc.), es veu que la notació per a l'extensió és l'etiqueta estén (“extend”) on el cas d'ús de Fer reserva s'estén mitjançant el cas d'ús Pagar reserva.

4 de 7

Olga Schlüter


CFGS.DAW.M5: Entorns de desenvolupament

UF3. Introducció al disseny orientat a objectes

Inclusió Una altra relació entre casos d'ús és la inclusió. A diferència del d'extensió, la inclusió es defineix com una secció d'un cas d'ús que és part obligatòria del cas d'ús bàsic. Aquesta relació s'etiqueta amb inclou (“include”). Per exemple, en un sistema de reserves, el cas d'ús Consultar informació inclou el cas d'ús Validar usuari.

Generalització La generalització recolza la reutilització de casos d'ús, és a dir que ens evita haver de descriure les parts similars una altra vegada. Apareixen els casos d'ús abstractes, que no serien instanciats independentment i que serviran només per a descriure les parts comuns a un altre cas d'ús. Els casos d'ús instanciats s'anomenen casos d'ús concrets. 5 de 7

Olga Schlüter


CFGS.DAW.M5: Entorns de desenvolupament

UF3. Introducció al disseny orientat a objectes

Una tècnica per a extraure casos d'ús abstractes és identificar actors abstractes. Per exemple, en el cas d'us Pagar Reserva es pot generalitzar en dos casos d'ús: Pagar amb targeta i Pagar amb transferència. Un d'aquests dos casos s'hauria d'instanciar, ja que el “super” cas d'ús Pagar Reserva seria abstracte perquè no es coneix encara la forma de pagament.

Les relacions d'extensió i inclusió entre casos d'ús s'implementen ambdues mitjançant associacions de classes, mentre que la generalització s'implementa amb herència de calsses. Cal recordar que a l'hora de dibuixar el diagrama complet de casos d'ús s'ha d'evitar que sigui una teranyina. Per a això, agruparem els casos d'ús amb els actors que els utilitzin. Tot i la importància del diagrama, la part fonamental del model de casos d'ús és la descripció textual detallada de cadascun dels actors i casos d'ús identificats. Aquests documents són crítics ja que a partir d'ells es desenvoluparà el sistema complet. El format de documentació per als actors és: Fitxa d'actor Actor

Nom de l'actor

Casos d'ús

Nom dels casos d'ús on participa

Tipus

Primari o Secundari

Descripció

Breu descripció de l'autor

i per als casos d'ús: Llista de casos d'ús Actor

6 de 7

Cas d'ús

Olga Schlüter


CFGS.DAW.M5: Entorns de desenvolupament

UF3. Introducció al disseny orientat a objectes

Fitxa de cas d’ús Cas d’ús

Nom del cas d'ús

Actors

Actors primaris i secundaris que interaccionen amb el cas d'ús

Propòsit

Raó de ser del cas d'ús

Resum

Resum descriptiu del cas d'ús, amb el flux d'events més important del cas d'ús. Depenent de les accions dels actors, es continuarà amb alguns dels subfluxos.

Precondicions

Condicions que s'han de complir per a executar el cas d'ús

Postcondicions

Condicions que s'han de complir per a dir que el cas d'ús s'ha executat amb èxit

Excepcions

Excepcions que poden ocórrer durant el cas d'ús numerats E1, E2, etc.

7 de 7

Olga Schlüter

Casos d us