Read without ads and support Scribd by becoming a Scribd Premium Reader.
See Premium Plans
Introducci\u00f3n

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en
desarrollo, adem\u00e1s de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de
uso).

Un diagrama de casos de uso consta de los siguientes elementos:
\u2022
Actor .
\u2022
Casos de Uso .
\u2022
Relaciones de Uso, Herencia y Comunicaci\u00f3n .
Elementos
\u2022
Actor:

Una definici\u00f3n previa, es que unActor es un rol que un usuario juega con respecto al sistema. Es
importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no
necesariamente representa a una persona en particular, sino m\u00e1s bien la labor que realiza frente
al sistema.

Como ejemplo a la definici\u00f3n anterior, tenemos el caso de un sistema de ventas en que el rol de
Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de
Local.

\u2022
Caso de Uso:
Es una operaci\u00f3n/tarea espec\u00edfica que se realiza tras una orden de alg\u00fan agente externo, sea
desde una petici\u00f3n de un actor o bien desde la invocaci\u00f3n desde otro caso de uso.
\u2022
Relaciones:
o
Asociaci\u00f3n
Es el tipo de relaci\u00f3n m\u00e1s b\u00e1sica que indica la invocaci\u00f3n desde un actor o caso de uso a
otra operaci\u00f3n (caso de uso). Dicha relaci\u00f3n se denota con una flecha simple.
o
Dependencia o Instanciaci\u00f3n
Es una forma muy particular de relaci\u00f3n entre clases, en la cual una clase depende de
otra, es decir, se instancia (se crea). Dicha relaci\u00f3n se denota con una flecha punteada.
o
Generalizaci\u00f3n

Este tipo de relaci\u00f3n es uno de los m\u00e1s utilizados, cumple una doble funci\u00f3n
dependiendo de su estereotipo, que puede ser deUso (<<uses>>) o deHerenci a
(<<extends>>).

Este tipo de relaci\u00f3n esta orientado exclusivamente para casos de uso (y no para
actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(caracter\u00edsticas).
uses: Se recomienda utilizar cuando se tiene un conjunto de caracter\u00edsticas que son
similares en m\u00e1s de un caso de uso y no se desea mantener copiada la descripci\u00f3n de la
caracter\u00edstica.
De lo anterior cabe mencionar que tiene el mismo paradigma en dise\u00f1o y modelamiento
de clases, en donde esta la duda cl\u00e1sica deus ar oheredar.
Ejemplo:
Como ejemplo esta el caso de una M\u00e1quina Recicladora:
Sistema que controla una m\u00e1quina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar
y/o aceptar:
\u2022
Registrar el n\u00famero de \u00edtemes ingresados.
\u2022
Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total
\u2022
El usuario/cliente presiona el bot\u00f3n de comienzo
\u2022
Existe un operador que desea saber lo siguiente:
a. Cuantos \u00edtemes han sido retornados en el d\u00eda.
b. Al final de cada d\u00eda el operador solicita un resumen de todo lo depositado en el d\u00eda.
\u2022
El operador debe adem\u00e1s poder cambiar:
a. Informaci\u00f3n asociada a \u00edtemes.
b. Dar una alarma en el caso de que:
i.
Item se atora.
ii.
No hay m\u00e1s papel.
Como una primera aproximaci\u00f3n identificamos a los actores que interactuan con el sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la informaci\u00f3n de
un Item o bien puede Imprimir un informe:
Adem\u00e1s podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresi\u00f3n de comprobantes, que puede ser realizada despu\u00e9s de depositar alg\u00fan item
por un cliente o bien puede ser realizada a petici\u00f3n de un operador.
Entonces, el dise\u00f1o completo del diagrama Use Case es:
Search
Search History:
Searching...
Result 00 of 00
00 results for result for
  • p.
    • Notes
    Load more