Ut5. introduccion a uml. casos de uso

UT5. Introducción a UML.
Casos de Uso
“Entornos de Desarrollo”
Ciclo DAW- IES Clara del Rey
Curso 2011 – 2012

Indice
• Modelado de Sofwtare
• Claves en el desarrollo del Software
• Enfoques del modelo de análisis
– Análisis Estructurado
– Metodologías Orientadas a Objetos
• UML
• Diagramas de Casos de Uso

IES Clara del Rey UT5. Introducción a UML. Casos de Uso 2

¿Qué es un Modelo?

Un Modelo es una simplificación de la realidad

Un modelo es resultado de un proceso de
abstracción y ayuda a comprender y
razonar sobre una realidad

Un modelo software es una descripción de
un aspecto del sistema, expresada en un
lenguaje bien definido.


Modelado de Software
• El modelado es el análisis y diseño de aplicaciones
software antes de escribir el código.
• Se crean un conjunto de modelos (“planos del software”)
que permiten especificar aspectos del sistema como los
requisitos, la estructura y el comportamiento.
• “Una empresa software con éxito es aquella que
produce de manera consistente software de calidad
que satisface las necesidades de los usuarios”
• “El modelado es la parte esencial de todas las
actividades que conducen a la producción de software
de calidad”


Modelado Visual
• Beneficios del Modelado Visual


Utilidad del Modelado
• Hay estructuras que no son visibles en los programas.
• Ayuda a razonar sobre el cómo se implementa.
• Se facilita la comunicación entre el equipo al existir un lenguaje
común.
• Se dispone de documentación que trasciende al proyecto.
• Generación de código a partir de modelos
– Ha surgido un nuevo paradigma de desarrollo de software a
partir de modelos (p.e. MDA de OMG)
• Los modelos:
– visualizan cómo es o queremos que sea el sistema
– especifican la estructura y comportamiento del sistema.
– guían la construcción del sistema.
– documentan las decisiones.


Claves en el desarrollo del Software


Enfoques del modelo de Análisis
• Análisis Estructurado
– Separación datos y procesos
– Modelado de Datos (E/R)
• Atributos y relaciones
– Modelado de Procesos (DFD)
• Transformación de datos
• Análisis Orientado a Objetos
– Definición de clases
– Colaboración entre las clases


Análisis Estructurado – Ciclo de Vida
• Herramientas de documentación del Análisis Estructurado
– �Diagramas de Flujo de Datos (DFDs)
– �Diccionario de Datos (DD)
– �Diagramas de Entidad-Relación (ER)
– Diagramas de Estructura
– �Diagramas de Transición de Estado (DTEs)
– �Especificaciones de procesos


Metodologías Orientado a Objetos
• La esencia del desarrollo orientado a objetos es la
identificación y organización de conceptos del dominio
de la aplicación y no tanto de su representación final en
un lenguaje de programación.
• Se eliminan fronteras entre fases debido a la naturaleza
iterativa del desarrollo orientado al objeto.
• Aparece una nueva forma de concebir los lenguajes de
programación y su uso al incorporarse bibliotecas de
clases y otros componentes reutilizables.
• Las metodologías OO
– Son interactivas e incrementales.
– Fácil de dividir el sistema en varios subsistemas
independientes.
– Se fomenta la reutilización de componentes


Metodologías orientadas a objetos
• Ejercicio
– Identificar las tareas a realizar en Métrica 3 cuando se
trata de realizar el desarrollo de un sistema siguiendo una
metodología orientada a objetos
– Identificar los objetivos de las tareas anteriores


UML. Introducción
• UML o el Unified Modeling Language
• UML es una especificación de notación orientada a objetos
• La notación UML se deriva y unifica las tres metodologías de análisis y diseño OO
más extendidas:
– Metodología de Grady Booch para la descripción de conjuntos de objetos y sus
relaciones.
– Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-
Modeling Technique).
– Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering)
mediante la metodología de casos de uso (use case).
• Los “Tres Amigos” son socios en la compañía Rational Software.
• Object Constraint Language Specification (OCL):
– El UML incorpora el lenguaje de restricción de objetos a fin de superar las
deficiencias que poseen los elementos UML para definirse a sí mismos.
• El UML es un lenguaje para construir modelos; no guía al desarrollador en la forma
de realizar el análisis y diseño orientados a objetos ni le indica cuál proceso de
desarrollo adoptar.
• UML permite describir un sistema en diferentes niveles de abstracción, simplificando
la complejidad sin perder información, para que tanto usuarios, líderes y
desarrolladores puedan comprender claramente las características de la aplicación.


UML. Evolución


UML. Diagramas
• Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema
modelado:
• Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema
modelado:
• Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que
enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
– Visión estática vs visión dinámica


Relación entre diagramas


UML. Ejercicio Teórico
• Localizar de entre los diagramas anteriores, aquéllos
que son usados en Metrica V3 y para qué sirven
• Material
– http://www.csae.map.es/csi/metrica3/index.html


Diagramas de Casos de Uso (I)
• Captura información de cómo un sistema o negocio trabaja.
• Objetivo: identificar los requisitos funcionales del sistema,
estructurados en torno a las diversas categorías de usuarios
• Un caso de uso es un “uso típico del sistema”
– Secuencia de acciones realizadas por el sistema, que producen
un resultado observable y valioso para un usuario en particular
– Tiene lugar bajo ciertas circunstancias
• Es iniciado por un actor
• Se puede describir como un conjunto de actividades
• Produce un resultado de valor observable para algún actor
• Se utiliza para representar la funcionalidad del sistema desde el
punto de vista de los usuarios.
– Presentan actores, casos de uso y relaciones
• El modelo de casos de uso se representa gráficamente mediante
uno o varios diagramas de casos de uso

Casos de uso (II)
• ¿Por qué utilizar Casos de Uso?
– Se utilizan para recoger los requisitos funcionales de un sistema
– Un caso de uso ayuda a responder a las siguientes preguntas
• ¿Quién hace qué?
• ¿Cuándo lo hace?
• ¿Qué actividades se realizan?
• ¿Qué elementos del sistema se utilizan?
• Alcance del caso de uso
– Determinar el alcance de un caso de uso consiste en identificar
qué elementos forman parte de dicho caso de uso
– Tan importante como identificar qué forma parte del caso de uso
es identificar lo que NO forma parte del caso de uso
• Si el diagrama ayuda visualmente a entender qué hace el sistema,
es más importante que la escritura del caso de uso sea adecuada


Ejemplo


Elementos del Diagrama de Casos de Uso
• Un actor representa el rol que adopta una entidad externa que interacciona
directamente con el sistema
• Los actores significan roles, no entidades concretas
ACTOR
•Un actor puede participar en varios casos de uso, desempeñando un rol diferente en
cada uno, por tanto un actor, más que un rol, es un conjunto coherente de roles
•Tipos de actores (Agentes externos, como concepto más amplio que usuario)
•Personas o cosas (otro sistema, un sensor, agua, fuego, tiempo…)
•Primarios o secundarios (realizan tareas administrativas o de mantenimiento)

• Un escenario es una secuencia de acciones que describen una interacción
usuario/sistema
Caso de
• Escenario básico: Todo va bien
Uso • Escenario alternativo: excepcionales (ej. La password en un cajero es
incorrecta)
Consultar
Informes • Un caso de uso describe un comportamiento del sistema:
•Especificación de secuencias de acciones , incluyendo variantes y secuencias
de error, que un sistema, subsistema o clase puede llevar a cabo
interaccionando con actores externos
•Representa una tarea, o unidad coherente de funcionalidad que el sistema
está obligado a proporcionar

Ejemplo : Feria de Subastas
• Se desea modelar un sistema informático para gestionar las transacciones en un
recinto ferial de subastas. Cualquier persona que haya logrado acceso al recinto de
la feria puede conectarse al sistema a través de alguno de los muchos terminales
disponibles, y participar en las subastas que tengan lugar, en alguna de las
modalidades ofrecidas por el sistema, es decir, como comprador, como vendedor, o
como simple observador
• Para subastar algún artículo es necesario darse de alta como vendedor. El vendedor
puede sacar artículos a subasta, rellenando una ficha por cada artículo, que sale así
inmediatamente a subasta.
• Análogamente para participar en una subasta es necesario darse de alta como
comprador. El comprador puede pujar por cualquiera de los artículos subastados en
la feria. Cuando no se produce ninguna nueva puja, el artículo queda definitivamente
adjudicado al comprador. Si un artículo no ha recibido ninguna puja, el vendedor
puede modificar alguno de sus datos
• Cualquier persona puede participar como observador en una subasta, es decir,
puede consultar la lista de artículos subastados y seleccionar uno de ellos par a
examinar la lista de pujas, pero necesita registrarse como vendedor o comprador
para participar activamente


Ejemplo:Feria de subastas.
Ejemplo gráfico ilustrativo incompleto


Relaciones entre Casos de Uso
• CU -Actor
– La relación entre una actor y un caso de uso es una
relación de comunicación que indica que el actor
interviene en el caso de uso y normalmente aporta
información o la recibe (unidireccional o bidireccional).
– La dirección refleja quién inicia la comunicación
– Asociación “comunica” (<<comunicates>>)
• CU – CU
– La relación entre casos de uso es normalmente
unidireccional y significa que un caso de uso “usa” o
“extiende” otro
– Relación <<include>> y <<extend>> o <<usa>> y
<<extiende>>


• Relación “usa” (<<include>>)
– Comportamiento común reutilizable
– Un CU puede ser incluido por uno
o más Casos de Uso
– Se reduce la duplicación de
funcionalidad al factorizar el
comportamiento común
– La relación “usa” se utiliza cuando
se quiere reflejar un
comportamiento común en varios
casos de uso. Es decir, si los casos
de uso A y B presentan una parte
común, ésta se puede sacar a un
tercer caso de uso C. Entonces,
habrá una relación “usa” del caso
de uso A al C y otra del B al C.


• Relación “extiende” <<extends>>
– Un caso de uso puede extender el comportamiento de otro caso de uso
– Un caso de uso extiende a otro cuando agrega tareas adicionales al
primero
– Por ejemplo, se tiene el caso de uso A que representa un comportamiento
habitual del sistema. Sin embargo, dependiendo de algún factor, este caso
de uso puede presentar un comportamiento adicional o ligeramente
diferente, que se podría reflejar en un caso de uso B. En este caso, habrá
una relación “extiende” del caso de uso B al A.
• Ej. Si antes de modificar un tipo particular de pedido de cliente, un usuario
necesita obtener una aprobación, entonces el caso de uso “obtener
aprobación” puede extender opcionalmente el caso de uso “Modificar pedido”


Ejercicio Caso de Uso
• Enunciado
– Modelar el diagrama de casos de uso de una máquina
expendedora de café
• Representar los Casos de Uso
• Representar los actores
• Representar las posibles relaciones


Relaciones entre casos de uso
• Generalización de casos de uso
– Un caso de uso puede tener
especializaciones con el fin de :
• Añadir asociaciones con actores que
requieran distintas variantes
• Añadir o sobreescribir
pre/postcondiciones
– El caso de uso hijo hereda la
especificación del caso de uso padre
– El hijo puede añadir o redefinir el
comportamiento del padre
– El hijo puede ser colocado en
cualquier lugar donde aparezca el
padre
– NO CONFUNDIR CON <<extends>>
• El caso de uso que extiende no puede
modificar el comportamiento del caso
de uso del cual se extiende. Solamente
puede agregar tareas nuevas en los
puntos de extensión
• El caso de uso derivado (heredado)
puede modificar alguna de las tareas
del caso de uso base


• Enunciado
– Se necesita realizar un sistema que permita el acceso al
personal del departamento de compras el hacer pedidos,
teniendo en cuenta que se quiere contemplar el que haya
pedidos urgentes.
– Una vez hecho el pedido se quiere poder realizar un
seguimiento del mismo
– Tanto para hacer el seguimiento como para poder realizar
pedidos hay que estar validado en el sistema, que se
puede hacer conociendo la clave o por reconocimiento de
la retina.
• Realizar el diagrama de casos de uso


Ejemplo Casos de uso
• Diagrama incompleto que no representa los actores


Generalización de actores
• Generalización de actores
– Un actor A puede requerir
el mismo servicio que otro
actor B
– Posibles soluciones
• Hay instancias de A que
también son instancias de
B (no generalización)
• El actor A es subtipo de
actor B (= todo A es un B)
• Los actores A y B son
subtipos del actor C
(posible actor abstracto)


Escritura básica de un caso de uso
• Plantilla de casos de uso
Plantilla de Casos
de Uso

Nombre Subastar artículo
Actores Vendedor
Objetivo Registrar los datos de una artículo para que salga a subasta
Precondiciones Usario registrado como Vendedor
Postcondiciones Artículo registrado
Escenario básico 1.-Insertar tarjeta magnética
2.-Abrir sesión como vendedor
3.-Introducir datos del artículo
4.-Confirmar
Escenario alternativo o 3.1.- Si artículo ya existe mostrar error
excepciones


Ejercicio

• Realizar estudio de los requisitos de una aplicación que gestiona los
préstamos y reservas de una biblioteca y representarlos mediante un
diagrama de casos de uso
• Escribir el caso de uso prestar libro


Solución posible a gestión biblioteca


Solución posible caso de uso préstamo
Mensaje: La escritura descriptiva siempre es libre, hay que ser lo más
esquemático y preciso posible


Documentación generada
Se tendrán los siguientes diagramas de casos de uso: (no obligatorio)

• Diagrama de contexto: presenta el general del sistema y los actores
que intervienen en él.

• Diagrama general del sistema: donde se persenten todos los casos
posibles del sistema y sus interacciones.

• Diagrama de casos de uso por cada escenario del sistema

• Descripción detallada de cada caso de uso.


Diagrama de Contexto
EJEMPLO
• Se representa el total del sistema y los actores que
intervienen en el mismo.

Usuario General Usuario Público

Sistema Control de Calidad

Administrador

Sist ema


Diagrama de Casos de uso del sistema
• Se puede representar un diagrama de casos de uso general del sistema.
Por ejemplo:
EJEMPLO
El actor Usuario Privad o acced e a d iver sos casos d e
uso q ue el actor Ad m inistrador no, p or eso se
relaciona este actor solamente con los casos d e uso
"Tratar Pr ocesos d e Muestr eo" y "Consultar Estad ís. ..

Tr atar Pr ocesos d e Muestreo
Usuario Privad o

< < uses> >
Consultar Estad ísticas

Existe una generaliz ación d el
Usuario Privad o y d el Administrad or
en Usuario Gener al, esto es d eb ido < < uses> >
a q ue com part en varios casos d e < < uses> >
uso, y la manera más clar a d e
rep resentar lo es ésta. Usuario General
Recup er ar Datos XML
Gestionar Lotes
< < uses> >

Gestionar Pr oveedor es

< < uses> > Autent ificar Usuar io
Sistem a

Enviar Mail Ad ministrad or
S ut iliza un usuario S
e istem a
Gestionar Emp resas < < uses> >
p or q ue para recup er ar Datos
Ad ministr ad or d e Pr ocesos d e Muestr eo es el
p r op io sistema el q ue realiz a la
p etición. En caso d e no existir
< < uses> > este usuar io y est e caso d e uso,
Usuario Púb lico no se p od ría tener inform ación
d e los Procesos d e Muestreo
Gestionar Ad ministrad or es existentes.
Consultar Pr ocesos De Muestr eo

El actor Ad ministr ad or acced e a d iver sos casos d e
uso q ue el actor Usuario Pr ivad o no, p or eso se Consultar Datos
r elaciona este actor solamente con los casos d e uso
"Gestionar Ad ministrad ores" y "Consultar Datos"


Diagrama de casos de uso para cada escenario

EJEMPLO

• En el ejemplo anterior el escenario GESTIONAR PROVEEDORES, tiene el
siguiente diagrama de casos de uso:

< < subsy st em> >
Gest ionar Pr oveedor es

Alt a Nuev o Pr oveedor

< < u ses> >

< < u ses> >
Baja Pr ov eedor

< < u ses> >

Usuar io Gener al Modif icar Dat os Pr ov eedor Aut ent if icar Usuar io
< < u ses> >

Enviar Mail Pr ov eedor


Ejemplo Caso De Uso: Acceso al sistema
• Suelen existir situaciones físicas que tiene en común una secuencia de
acciones previa a la ejecución de los demás casos de uso:
– Identificación o validación de usuarios
– Inicio de sesión
– Abrir un documento sobre el que se van a realizar diversas operaciones
– Etc
• Posibles soluciones
– Caso de uso aparte usado como <<include>> (no recomendable)
• Complica innecesariamente el diagrama de casos de uso
• Es parte de los demás casos de uso sólo la primera vez que se ejecutan
– Secuencia opcional de acciones en el diagrama de actividad del caso
de uso.
– Caso de uso aparte cuyo resultado es usado como precondición para
los demás


Ut5. introduccion a uml. casos de uso

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Ut5. introduccion a uml. casos de uso

Similaire à Ut5. introduccion a uml. casos de uso (20)

Ut5. introduccion a uml. casos de uso