Identificació de casos d’ús
Posted: Febrero 5th, 2009 | Author: Jose Raya | Filed under: agilogy | Comentarios desactivadosLa major part del material d’aquest article està basada en les idees del llibre Writing Effective Use Cases d’ Alistair Cockburn. La meva intenció amb aquest document és donar una visió general de les idees que allà es detallen amb exemples i explicacions més exhaustives.
¿Què és un cas d’ús?
Un cas d’ús captura un contracte entre algú que fa servir un sistema i el propi sistema. Descriu el comportament del sistema indicant com ha de reaccionar a les accions de l’usuari. Per tant, els casos d’ús del sistema formen part del recull de requisits del mateix però no són tots els requisits (no inclouen la interfície gràfica d’usuari, regles de negoci, formats de dades, requisits tecnològics, requisits legals, etc.).
Un cas d’ús contempla diversos escenaris possibles. Alguns acaben bé i d’altres no, però tots els escenaris formen part del cas d’ús. Hi ha un escenari principal: aquell en el qual l’entitat qui ha engegat el cas d’ús aconsegueix satisfer l’objectiu pel qual l’havia engegat (hauria de ser el més “habitual”). Ex: En el cas d’ús “Comprar accions via web”, l’escenari principal és aquell en què el comprador aconsegueix comprar les accions.
¿A qui li afecta el cas d’ús?
Un cas d’ús descriu un contracte entre un “stakeholder” i el sistema. Un stakeholder és qualsevol entitat amb algun interés sobre el sistema, independentment de si interactua amb ell o no. Ex: El director general d’una empresa pot estar interessat en el sistema de facturació encara que no hi interactui directament.
Un actor, en canvi, és una entitat (una persona o un sistema informàtic) que interactua amb el nostre sistema. L’actor principal d’un cas d’ús és l’entitat que inicia la interacció amb el sistema.
¿Com es poden identificar ?
L’actor principal, quan decideix interactuar amb el sistema, ho fa amb un objectiu: aprofitarem aquest fet per descriure els casos d’ús en termes d’actors i objectius i per descobrir els casos d’ús:
- Primer identifiquem els actors principals
- Després identifiquem els casos d’ús per cada actor
Com que no només els actors tenen interessos respecte al sistema, podem generalitzar aquest enfocament a tots els stakeholders. Un cop identificat el cas d’ús, hem de tenir en compte que quan un actor engega un cas d’ús amb un objectiu el sistema té la responsabilitat de satisfer aquest objectiu. Per a dur a terme aquesta responsabilitat haurà d’identificar subobjectius, recolzar-se en altres actors de suport, establir mecanismes per a recuperar-se en cas de no poder satisfer aquest objectiu, etc.
Aquesta descomposició ens porta a plantejar-nos la següent qüestió:
Fins a quin punt descomposem els casos d’ús?
Normalment en tindrem prou amb tres nivells de detall (tot i que, al seu llibre, en Cockburn identifica alguns més).
- Objectius generals (summary) (”sky-level”)
- Objectius d’usuari (user) (”sea-level”)
- Subobjectius (subfunctions) (”fish-level”)
Objectius generals
Son el nivell més alt i ténen com a propòsit i mostren el context en el què operen els objectius d’usuari. Mostren la seqüència relativa i el cicle de vida dels objectius relacionats. A més, serveixen com a “resum” del contingut dels casos d’ús que té per sota.
Objectius d’usuari
Son els més importants ja que són aquells per causa dels quals els usuaris (de manera més general, els actors principals) interactuen amb el nostre sistema. Idealment, un cas d’ús d’aquest nivell ha de proporcionar un cert valor per a l’actor que l’inicia; com a heurístic per identificar aquest valor podem fer qualsevol d’aquestes dues proves:
- Test del café: Quan hagi acabat el cas d’ús, me’n puc anar a fer un café?
- Test del sou: Si faig això 10 vegades en un dia, està justificat dir que m’he guanyat el sou?
Subobjectius
Son aquelles tasques que es requereixen per a dur a terme els objectius dels usuaris com ara cercar un producte, guardar un fitxer, etc. Normalment, només s’han de descriure en aquells casos en què la interacció sigui rellevant per algún motiu i que no hagi quedat clara en el cas d’ús d’usuari què l’inclou.
Errors habituals
Finalment, un petit recull d’errors habituals en el procés d’identificació i descripció dels casos d’ús:
- Massa dependència respecte a la interfície d’usuari
- No parlar sobre el sistema
- Objectius de molt baix nivell
Els casos d’ús formen part del recull de requisits, no del manual d’usuari. Per tant, el cas d’ús hauria de parlar d’intencions i objectius, no de pantalles.
Si només indiquem què fa l’actor però no indiquem què fa el sistema, no estem describint el comportament del sistema. Per tant, sempre hem d’intentar posar qui fa què
La descomposició de casos d’ús generals en casos d’ús detallats és semblant a la descomposició funcional, però els casos d’ús són requisits, no disseny i, per tant, l’estructura dels casos d’ús no s’hauria de reflectir al codi. La descomposició funcional no funciona bé per als sistemes OO ja que dificulta la reusabilitat dels objectes