Diagrama de casos d'ús del joc Sokoban

Introducció

Els diagrames de casos d'ús d'UML serveixen per mostrar les funcions d'un sistema de programari des del punt de vista de les seues interaccions amb l'exterior i sense entrar en la implementació detallada de les funcions en qüestió. Aquests diagrames s'utilitzen en la recollida de documentació i en la fase d'anàlisi.

Actors

La finalitat d'un programari és proporcionar informació a persones, màquines o dispositius externs en general. Un actor és un conjunt de rols d'una entitat exterior en relació amb el sistema de programari considerat. Per ser actor, una entitat exterior ha de complir dues condicions:

  • Ser autònom respecte al programari (Per exemple: un motor elèctric, però no una CPU).
  • Tenir una relació directa amb el programari o amb entitats exteriors que estiguen subordinades a aquest programari.

Un actor és un classificador però no és un estereotip. Si un conjunt d'entitats exteriors fan el mateix rol, les representarem amb un mateix actor. Els actors poden tenir relacions d'especialització o generalització mitjançant herència (un actor A és una especialització d'un actor B si fa almenys tots els rols de B).

El símbol d'actor a UML: un ninot amb l'etiqueta «Actor»

Jerarquia d'actors: Usuari, amb Administrador i Client a sota, i Manager sota Administrador

Un cas d'ús representa una interacció entre el programari i un actor o més. La interacció ha de ser una funció autònoma dins del programari. Els casos d'ús són un cas particular de classificadors, poden tenir atributs i operacions. Entre casos d'ús i actors hi ha associacions que representen el rol de l'actor en relació amb el cas d'ús, però no representen cap flux de dades. L'actor principal és el que demana la funció del programari. Hi ha tres tipus de relacions:

  • Relació d'extensió: Es diu que el cas d'ús A estén B si dins de B s'executa A quan es compleix una condició determinada.
  • Relació d'inclusió: Un cas d'ús A està dins dels casos d'ús de B, C..., si és una part del procés comú a tots aquests. El cas d'ús no és autònom, és a dir, no té actor primari, per tant, sempre s'activa des d'un altre cas d'ús. Permet la reutilització.
  • Relació de generalització i especialización: Un cas d'ús A és una especialització de B si A fa tot el que fa B més algun procés específic.

Representació bàsica:

Un cas d'ús a UML: un oval amb el text «Matricular Estudiant»

Representació d'una especialització/generalització:

Generalització entre casos d'ús: «Matricular Membre Familiar» hereta de «Matricular Estudiant»

Normalment no s'utilitzen els símbols de classificadors. Els estereotips extend i include s'utilitzen per a les relacions d'extensió i d'inclusió, respectivament:

Relacions include i extend entre els casos d'ús de matriculació

Podem crear les associacions convenients entre actors i casos d'ús.

El diagrama de matriculació complet, amb els actors Estudiant i Estudiant Internacional

Si ens convé, i en el cas que representem tots els casos d'ús d'un sistema, els podem emmarcar o bé amb un quadrat i un títol, o bé amb un òval, per al sistema contenidor dels casos d'ús, com es mostra a continuació:

Casos d'ús d'un sistema de comptabilitat, amb els actors Comptable i Cap de comptabilitat

Exemple de caixer automàtic:

Casos d'ús d'un caixer automàtic: sessió, transacció, dipòsit, transferència i consulta

  1. Aquest diagrama de casos d'ús representa la funcionalitat d'una aplicació de lloguer de pel·lícules d'un caixer automàtic.

Casos d'ús d'un videoclub, amb els actors Client i Responsable de la caixa

a) Del diagrama es pot deduir que una persona que siga responsable del caixer no pot llogar pel·lícules?

No, pot actuar amb el rol de client també.

b) Si es canvia el sistema de tal manera que la forma d'afegir els materials és diferent, això afectaria les persones amb rol de client?

No.

c) Millora el diagrama tenint en compte que els casos d'ús d'afegir DVD i afegir BR tenen parts en comú. Explica la teua decisió.

d) Suposem que es millora el sistema perquè els clients puguen recomanar els DVD que més els agraden. Aquesta tasca es pot dur a terme de manera autònoma, però també quan lloguen DVD. Representa en el diagrama aquests nous requisits. e) Es podria considerar el caixer automàtic com un actor?

Sí, és un sistema extern de l'aplicació.

  1. Tenint en compte les respostes a les preguntes següents del famós joc del cercamines, especifica el diagrama de casos d'ús:

Partida del Buscamines de Windows

Recorda que necessitarem preguntar-nos per realitzar el diagrama... En aquest cas podem suposar que aquests són tots els casos d'ús del joc. Preguntes habituals per especificar els casos d'ús d'un sistema serien: Quins casos d'ús identifiquem?

  • Iniciar una nova partida.
  • Descobrir una casella.
  • Marcar la casella.

Qui realitza aquests casos d'ús?

  • El jugador.

Diagrama de casos d'ús del Buscamines: iniciar partida, descobrir una casella i marcar-la

  1. A l'empresa on treballeu han encarregat un nou videojoc anomenat Sokoban. Com a analistes que sou, es demana que especifiqueu el diagrama de casos d'ús del joc, tenint en compte els requisits funcionals següents:
  • Sokoban és un joc de diversos nivells.
  • Cada nivell està compost per un jugador, caixes, prestatges i murs.
  • L'objectiu del jugador és empenyémer totes les caixes sobre els prestatges.
  • Quan això passa, el jugador passa al següent nivell.
  • Per moure una caixa, el jugador ha de situar-se al costat i empenyémer-la. Si la casella cap a la qual està empenyent està lliure, la caixa es mourà.
  • Si el jugador es queda bloquejat. És a dir, no pot acabar el nivell, pot reiniciar el nivell perdent una vida.
  • Quan el jugador perd totes les vides, la partida s'acaba.

Casos d'ús del Sokoban amb les relacions include i extend entre ells