PROFILPELAJAR.COM

El diagrama de casos d'ús és la representació gràfica més simple de les interaccions entre un usuari i un sistema, aquestes relacions es representen amb les normes bàsiques del Llenguatge unificat de modelat (UML).En un diagrama de casos d'ús no es mostren els casos d'ús detalladament, només es mostra el nombre d'usuaris, el seu tipus i la manera com interactua amb el sistema. En concret, en el diagrama no ens mostra l'ordre en el qual es duen a terme els passos per aconseguir els objectius de cada cas d'ús. Aquests detalls poden descriure's en altres diagrames i documents, que es vinculen a cada cas d'ús.

Aplicació

A causa de la seva naturalesa simplista els diagrames de casos d'ús ens mostren el disseny a un alt nivell, amb un cop d'ull al diagrama de casos d'ús d'un sistema podem saber les seves funcionalitats principals independentment del que un sigui des de programadors fins a comercials.

El diagrama de casos d'ús en si no aporta un coneixement molt detallat però aporta una visió general del sistema resultant a més de permetre un canal de comunicació entre totes les parts implicades. Amb el diagrama de casos d'ús trobarem informació del caire; nombre d'usuaris, herència de casos d'ús entre usuaris, accions/rutines que el sistema haurà de fer (casos d'ús),casos d'ús que obliguen l'execució d'altres casos d'ús (<include>), i casos d'ús que poden invocar a altres casos(<exclude>).Per assegurar el coneixement complet del sistema i les seves funcionalitats calen més especificacions a més d'altres diagrames més tècnics i concrets.

Elements Principals

Actor:
- És un tipus de rol que duu a terme una entitat externa al sistema (usuaris, dispositius de hardware, altres sistemes, etc.) que interactua amb ell intercanviant senyals i dades.
- Un actor no té per què interactuar amb totes les entitats.
Cas d'ús:
- Representa una funcionalitat que ha de dur a terme l'aplicació.
Relació:
- Serveix per representar les comunicacions que tenen els diferents actors i cas d'ús.
- Els casos d'ús poden estar comunicats entre ells.
- Associació
  - Es produeix entre actors i casos d'ús per a indicar quines accions pot fer l'actor.
- Relacions de dependència
  - Es produeixen entre casos d'ús per a representar que un cas d'ús concret utilitza o depèn d'un altre
  - Relació d'inclusió
    - Un cas pot utilitzar-ne (incloure'n) un altre, permet extreure comportaments que són usuals des de més d'un cas d'ús. Aquest ús s'assembla a una macro, ja que no se li solen passar paràmetres i no sol haver-hi valors de tornada
    - Se senyalitza amb una línia contínua amb l'etiqueta <<include>> o, simplement, <<i>>, des del cas d'ús que es vol incloure fins al cas d'ús que l'inclou.
  - Relació d'extensió
    - Forma d'interacció en la qual un cas d'ús pot estendre'n un altre. Aquesta relació indica que l'extensió podria ser inserida en el cas d'ús estès, això ens indica que l'extensió és, probablement, un cas especial del cas d'ús estès.
    - Se senyalitza amb una fletxa discontínua amb l'etiqueta <<extend>> o, simplement, <<e>>, des del cas que s'estén fins a l'estès.
- Generalització/especialització
  - Es dona quan un cas d'ús o actor és una forma especialitzada d'un altre d'existent.
  - Se senyalitza amb una línia acabada amb un triangle, començant des del cas d'ús especialitzat fins al cas d'ús general.

Estructura dels casos d'ús

Per a la vàlida construcció d'un sistema necessitem saber de manera concreta les seves funcionalitats, aquestes marcaran el nombre de casos d'ús. Els casos d'ús seran l'esquelet de les rutines que es programaran a posteriori, per tant el detall excessiu del cas d'ús no és necessari en el diagrama. Cada usuari del sistema podrà executar funcionalitats segons marqui el diagrama de casos d'ús: com comprar un producte o des del punt de vista del proveïdor, oferir productes per a la seva venda.

Una vegada fet el cas d'ús es pot dividir en diversos casos d'ús més senzills que ajudaran a dividir la rutina del cas d'ús original, que mitjançant <i> i <e> enllaçaran diverses rutines que faran possible la correcte realització del cas d'ús original.

Avantatges

La tècnica de cas d'ús té èxit, ja que expressa la intenció que té l'actor (el seu usuari) en fer ús del sistema. Com a tècnica d'extracció de requeriment permet que l'analista se centri en les necessitats de l'usuari, qui utilitzar el sistema, evitant que la gent especialitzada en informàtica dirigeixi la funcionalitat del nou sistema basant-se solament en criteris tecnològics.

A la vegada, durant l'extracció, l'analista es concentra en les tasques centrals de l'usuari descrivint per tant els casos d'ús. Això facilita després la priorització del requeriment. Encara que comunament s'associen a la fase de Test d'una aplicació, aquesta idea és errònia, i el seu ús s'estén majorment a les primeres fases d'un desenvolupament.

Limitacions

Els casos d'ús han de complementar-se amb informació addicional com a regles de negoci, requisits no funcionals, diccionari de dades que complementin els requeriments del sistema. No obstant això l'enginyeria del funcionament especifica que cada cas crític de l'ús ha de tenir un requisit no funcional centrat en el funcionament associat.

Bibliografia

Gemino, A., Parker, D.(2009) "Use case diagrams in support of use case modeling: Deriving understanding from the picture", Journal of Database Management, 20(1), 1-24.
Jacobson, I., Christerson M., Jonsson P., Övergaard G., (1992). Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley.
Kawabata, R., Kasah, K. (2007). "Systems Analysis for Collaborative System by Use Case Diagram", Journal of Integrated Design & Process Science, 11(1), 13-27.
McLaughlin, B., Pollice, G., West, D. (2006). Head First Object Oriented Analysis and Design, O'Reilly Media, Inc.
Siau, K., Lee, L. (2004). "Are use case and class diagrams complementary in requirements analysis? An experimental study on use case and class diagrams in UML", Requirements Engineering, 9(4), 229-237.
Vidgen, R. (2003). "Requirements Analysis and UML: Use Cases and Class Diagrams", Computing & Control Engineering, 14(2), 12.