Lengiii 008

Lenguaje de
programación III
Facilitador: Marcos Espinoza M.
marcos@ecuaportales.com
mespinoza@uagraria.edu.ec
5/11/2016 1UNIVERSIDAD AGRARIA DEL ECUADOR

Casos de Uso

UML: Casos de uso
• UML soporta el análisis y diseño
orientados a objetos
proporcionándole una manera de
captar los resultados del análisis y
el diseño. En general, iniciamos con
la comprensión de nuestro
problema; es decir, el análisis. Un
tipo excelente de modelo para
captar el análisis es el diagrama de
casos de uso.

UML: Casos de uso
• La finalidad de un caso de uso es
describir la manera en que se usará
un sistema: describir sus finalidades
esenciales. La finalidad de los
diagramas de casos de uso es
captar en forma visual las
finalidades esenciales.

Diagramas de casos de uso
• Constan de figuras de línea, líneas y óvalos. La
figura de palillos se llama actor y representa a
alguien o algo que actúa sobre el sistema. En
el desarrollo de software, los actores son
personas u otro software que actúa sobre el
sistema. Las líneas son punteadas o continuas,
con varias flechas o sin ellas, que indican la
relación entre el actor y los óvalos. Estos
últimos son los casos de uso y, en el diagrama
de casos de uso, los óvalos tienen algún texto
que proporciona una descripción básica.

Diagrama de casos de uso

• Hallar los casos de uso correctos
y describirlos de manera
adecuada es el proceso crítico
que impide que los listos
ingenieros de software pasen por
alto necesidades críticas y que
inventen de manera innecesaria.

• Los casos de uso por su sencillez los hace
un medio fácil de transmisión para
comunicarse con los usuarios o clientes y
proporcionar retroalimentación. También
las personas que constituyen el puente
entre los clientes y los programadores,
como los administradores, pueden
determinar si las características que en
realidad se estructuraron reflejan con
exactitud los deseos de los usuarios.

Uso de los símbolos
en los Casos de Uso

Símbolos básicos de los casos de uso

Símbolos: El actor
• La figura de palillos, mencionada como
actor, representa participantes en los
casos de uso. Los actores pueden ser
personas o cosas. Si un actor es una
persona, entonces, en realidad, nunca se
puede representar por medio de un
código. Si un actor es otro subsistema,
entonces se le puede observar como una
clase o subprograma, pero todavía puede
representarse usando el símbolo de actor
en los diagramas de casos de uso.

Símbolos: Caso de uso
• El símbolo del caso de uso se utiliza para
representar capacidades. Al caso de uso
se le da un nombre y una descripción
mediante un texto. Este último debe
describir cómo inicia y finaliza el caso de
uso, e incluye una descripción de la
capacidad descrita por el nombre de la
misma, así como escenarios de apoyo y
requisitos no funcionales.

Símbolos: Conectores
• Dado que los diagramas de casos de uso
tienen múltiples actores y en virtud de que
los casos de uso pueden estar asociados
con los actores y con otros casos de uso,
se utilizan los conectores para indicar la
manera en que ambos están asociados.
Además, los estilos de conectores pueden
cambiar para transmitir más información
acerca de la relación entre los actores y
los casos de uso. Por último, los conectores
pueden tener adornos y anotaciones que
suministran incluso más información.

Estilos de líneas para Conectores
Existen tres estilos básicos de líneas para los
conectores.
1. Un conector de línea simple se llama
asociación y se usa para mostrar cuáles
actores están relacionados con cuáles
casos de uso.

2. Una línea punteada con una flecha
direccional. Este estilo de conector se
conoce como dependencia. La flecha
apunta hacia el caso de uso del que
depende.

3. Una línea dirigida con un triángulo hueco,
al cual se le conoce como
generalización. La palabra generalización
en el UML significa “herencia”. Cuando
mostramos una relación de
generalización entre dos actores o dos
casos de uso, estamos indicando que el
actor o el caso de uso “hijos” son un caso
del actor o uso básico y algo más.

Los siguientes enunciados describen las relaciones de
generalización que se mostraron en la figura anterior:
o El usuario es el objetivo y el patrón es la
fuente.
o El patrón es un usuario.
o El usuario es el subtipo y el patrón es el
supertipo.
o El patrón se hereda del usuario.
o El usuario es el tipo padre y el patrón es el
tipo hijo.
o El patrón generaliza al usuario.

Adornos a los Conectores
Los diagramas UML fomentan el uso de
menos texto porque las imágenes
transmiten una gran cantidad de
información a través de una conveniente
taquigrafía visual, pero los diagramas UML
no se abstienen por completo del texto; por
ejemplo, los conectores pueden incluir
texto que indique multiplicidad de los
puntos extremos y texto que estereotipa el
conector.

Adornos a los Conectores: Multiplicidad
Las notaciones de multiplicidad indican
el conteo posible de cada cosa. Por
ejemplo, un asterisco significa muchos;
un asterisco próximo a un actor significa
que puede haber muchos ejemplos de
ese actor. Aun cuando el UML permite
hacer anotaciones de esta manera en
los conectores de caso de uso, eso no es
muy común.

Adornos a los Conectores: Estereotipo
• Los estereotipos agregan detalles a la
relación entre los elementos en un diagrama
de caso de uso.
• Se puede usar un estereotipo para ampliar
el significado del conector de
dependencia.

Adornos a los Conectores: Estereotipo
• Un patrón puede crear una lista de trabajos, el
patrón debe obtener acceso.
• Cuando un caso de uso —“Crear lista de
trabajos”— necesita los servicios de otro caso de
uso —“Entrar”— entonces se dice que el caso de
uso dependiente incluye el caso de uso del que
depende. (En código, una relación incluir se
implementa como reutilización de código.)

Caso de uso de inclusión y de extensión
• Una relación de dependencia entre
dos casos de uso significa que, de
alguna manera, el caso dependiente
necesita al caso del que depende.
Dos estereotipos de uso común y
predefinidos que refinan las
dependencias en los casos de uso son
el incluir y el extender.

Estereotipo incluir
• El estereotipo incluir significa que,
finalmente, el caso de uso
dependiente es para volver a usar el
caso del que depende.
• El caso de uso dependiente necesitará
los servicios del caso del que depende
y saber algo acerca de la realización
de ésta, pero lo opuesto no es cierto.

Estereotipo incluir
• Requerimos que un patrón tenga
acceso para crear una lista de
trabajos, pero también pudimos
obtener acceso por otras razones.

Estereotipo extender
• Se usa para agregar más detalle a una
dependencia, lo cual significa que estamos
agregando más capacidades.

• El caso de uso ver lista no le importa que la estén
registrando; en otras palabras, la característica
registrar necesitará saber acerca de la
característica ver lista, pero no en sentido contrario.

• Al “Solicitante de trabajo” tal vez no le interese
cuántas veces se ha visto la lista, pero un patrón
previsor podría estar interesado en cuánto tráfico
está generando su lista.

Anotaciones en los diagramas de casos de uso
• Si se encuentra en el predicamento de que
sólo el texto parece resolver —o no está
seguro del uml—, entonces siga adelante y
agregue texto. Puede agregar texto
mediante la documentación de sus modelos
con características de la mayoría de las
herramientas de modelado, agregando
referencias url a los documentos más
verbosos o agregando notas directamente
en los propios diagramas.

Inserción de notas
• Use las notas con moderación, porque pueden
abarrotar un diagrama y hacerlo difícil de leer.

Ejemplo de diagrama
de casos de uso

Ejemplo de diagrama de casos de uso
• Motown-jobs.com es un sitio web para
poner en contacto personas que
buscan trabajo con quienes los
ofrecen.
• Los casos de uso puede iniciar con una
entrevista con su experto en el
dominio, o bien haciendo una lista.

• Los patrones o los agentes de los patrones
querrán publicar información acerca de los
trabajos que están ofreciendo.
• Quienes están buscando trabajo pueden
querer publicar un currículum vítae que
puedan ver los patrones potenciales.
• Los patrones o los agentes de los patrones
querrán buscar en forma activa en el sitio
web los currículum vítae que se ajusten a las
habilidades necesarias para llenar los sitios
vacantes en el trabajo.

• Quienes están buscando empleo querrán buscar en
los puestos que se encuentran en lista.
• Los patrones o los agentes de los patrones deberán
pagar por las listas y por buscar en los currículum
vítae, pero publicar currículum vítae o buscar en las
listas de trabajos será un servicio gratuito.
• Una fuente adicional de ingresos podría ser
publicidad y servicios de estructuración de
currículum vítae, de modo que el sitio web podrá
vender y tener espacio para publicidad, y ayudar a
los solicitantes de trabajo a crear su currículum
vítae.

• En el diagrama de casos de uso se tiene los
actores “Patrón” y “Agente del patrón”; no
obstante, para todas las intenciones y
finalidades, estos dos actores hacen las
mismas cosas en relación con el sistema y lo
hacen de la misma manera; por
consiguiente, se puede eliminar el “Agente
del patrón” y renombrar al “Patrón” como
“Propietario de la tarea”; con una
descripción sencilla.

División de los casos de uso en
diagramas múltiples
• Puede elegir tener un diagrama maestro de
casos de uso y varios diagramas menores de
casos de uso o sólo varios diagramas
menores. Usted decide. Los diagramas más
sencillos son más fáciles de manejar y seguir,
pero puede ser que no muestren cómo
están relacionados los casos de uso.

División de los casos de uso en
diagramas múltiples
• En Motown-jobs.com, se tiene cuatro
facetas significativas; casos de uso
relacionados con el solicitante de empleo,
casos de uso relacionados con el propietario
del trabajo, casos de uso para los
anunciantes y el sistema de facturación.
Para examinar cada una de estas facetas
del sistema, se puede separar estos casos de
uso y los actores que les incumben en
diagramas separados y agregar detalles.

División: Mantener la información sobre facturación

División: Mantener la información
sobre facturación
• Se entiende que el sistema de facturación
se interese sólo en lo que es susceptible de
facturación y que un actor llamado “Usuario
registrado” pueda mantener elementos
susceptibles de facturación. Advierta que se
agregó el caso de uso “Entrar”. Dado que se
necesita saber cuáles usuarios están para
ser facturados, se necesitará un medio de
registrar y autenticar.

División: Solicitante de empleo

• Se introduce la idea de que un
solicitante de empleo también se
considera como usuario registrado. Se
elije requerir registro sólo si el usuario
quiere publicar un currículum. Se
necesita saber cuáles personas están
proporcionando información al
sistema, pero no se lo requiere de los
navegadores casuales.

• Una vez más, para publicar algo en el
sistema, se requerirá que al usuario se le dé
acceso y, de lo contrario, sólo ofrecer al
usuario casual la oportunidad de registrarse.
El concepto de usuario registrado sugiere
que se necesita otro caso de uso “Mantener
información de registros”. Esto puede
implementarse como un sencillo diagrama
de casos de uso, con el actor “Usuario
registrado” y una asociación al nuevo caso
de uso.

División: Anunciante

División: Anunciante
• Se muestra que un anunciante es un usuario
registrado y también se incluye que
“Mantener el anuncio” generaliza “Mantener
elementos susceptibles de facturación”.
Dado que “Mantener elementos susceptibles
de facturación” también está en el otros
diagramas se sabe que esto significa que
esta ligado con los casos de uso de
facturación, registro y autenticación (o
concesión de acceso), pero de manera
intencional se quitó esos elementos del
diagrama para no abarrotarlo.

División: Propietario del trabajo

IMPORTANTE:
• El objetivo de crear diagramas de casos de
uso es documentar los aspectos importantes
del sistema, para proporcionar a los usuarios
una manera de baja tecnología para
evaluar en forma visual sus comprensiones
mutuas y, a continuación, seguir adelante. El
resultado que deseamos es un juego de
casos de uso “suficientemente bueno”, no
perfecto.

Otro ejemplo y mayores detalles

Otro ejemplo y mayores detalles
• Entre dos casos de uso puede haber las
siguientes relaciones:
o Extiende: Cuando un caso de uso especializa a
otro extendiendo su funcionalidad.
o Usa: Cuando un caso de uso utiliza a otro.
• En el diagrama de casos de uso se
representa también el sistema como una
caja rectangular con el nombre en su
interior. Los casos de uso están en el interior
de la caja del sistema, y los actores fuera, y
cada actor está unido a los casos de uso en
los que participa mediante una línea.

Otros ejemplos:

Taller 10
Desarrollar un diagrama de caso de uso para
el siguiente desarrollo:
• La empresa SinMiedo tiene planes para
instalar una nueva máquina de venta
expendedora “inteligente” en la facultad.
Inteligente porque cuando detecte que un
cliente intenta comprar un producto
agotado, se conectará automáticamente a
la central de abastecimiento y dará aviso
para realizar la reposición. Además debe dar
vuelto y no dejar que paguen menos del
precio de lo que está vendiendo.

Lenguaje de
programación III
Facilitador: Marcos Espinoza M.
marcos@ecuaportales.com
mespinoza@uagraria.edu.ec

Lengiii 008

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (16)

Similar a Lengiii 008

Similar a Lengiii 008 (20)

Último

Último (10)

Lengiii 008