Transcript Caso de Uso

Aspectos Avanzados
de la
Tecnología de Objetos
2. Fundamentos del modelo de objetos
(2da parte: UML – Casos de Uso y Clases)
Dr. Juan José Aranda Aboy
Contenidos
•
•
•
•
Ingeniería del software con componentes.
Conceptos de objetos.
El proceso de desarrollo.
El lenguaje unificado de modelado (Unified Modeling
Language – UML):
–
–
–
–
–
–
Fundamentos de los modelos de casos de uso.
Fundamentos de los modelos de clases.
Fundamentos de los diagramas de interacción y colaboración.
Fundamentos de los diagramas de estado y de actividad.
Diagramas de implementación.
Paquetes, subsistemas, modelos.
Dr. Juan José Aranda Aboy
Objetivos específicos
• Definir los conceptos de objeto, clase y
componente.
• Caracterizar el proceso de desarrollo.
• Conocer y emplear adecuadamente el
lenguaje unificado de modelado (UML):
– Análisis de requerimientos: Casos de uso.
– Identificación de objetos y actores.
– Obtención de las Clases.
Dr. Juan José Aranda Aboy
¿Qué es UML?
• La especificación del OMG señala:
• "El Lenguaje de Modelado Unificado (UML) es un
lenguaje gráfico para visualizar, especificar,
construir y documentar los artefactos de un
sistema intensivo de software.
EL UML ofrece una forma estándar para escribir un
plano del sistema, incluyendo cosas conceptuales
tales como procesos de negocios y funciones del
sistema, así como también cosas concretas tales
como expresiones de lenguajes de programación,
esquemas de bases de datos y componentes de
software reutilizables"
Dr. Juan José Aranda Aboy
¿Qué es UML? (2)
• El punto importante para notar aquí es que UML es
un "lenguaje" para especificar y no un método o un
proceso.
• El UML se usa para definir un sistema de software:
para detallar los artefactos en el sistema, para
documentar y construir. Es el lenguaje en el que
está escrito el “plano” del sistema.
• El UML se puede usar en una gran variedad de
formas para soportar una metodología de
desarrollo de software, tal como el Proceso
Unificado de Rational, pero no especifica en sí
mismo qué metodología o proceso se utiliza.
Dr. Juan José Aranda Aboy
Dominios principales
•
•
Define la notación y las semánticas para los dominios principales:
1. El Modelo de Interacción del Usuario o Modelo de Casos de Uso:
Describe el límite y la interacción entre el sistema y los usuarios. Se
corresponde en cierta manera a un modelo de requisitos.
2. El Modelo de Interacción o de Colaboración: Describe cómo
interactuarán los objetos en el sistema entre sí para realizar el
trabajo.
3. El Modelo de Estado o Modelo Dinámico: Las cartas de estados
describen los estados o condiciones que las clases asumen a través
del tiempo. Los grafos de actividad describen los flujos de trabajo que
implementará el sistema.
4. El Modelo Lógico o de Clases: Describe las clases y los objetos que
conformarán el sistema.
5. El Modelo de Componentes Físico: Describe el software (y algunas
veces los componentes de hardware) que conforman el sistema.
6. El Modelo de Despliegue Físico: Describe la arquitectura física y el
despliegue de componentes en esa arquitectura de hardware.
También define mecanismos de extensión para cumplir con necesidades
específicas. Por ejemplo: extensiones de Modelado de Procesos de
Negocios).
Dr. Juan José Aranda Aboy
¿Cómo se debe usar UML?
• La naturaleza exacta del proceso depende de la
metodología del desarrollo usada.
• UML se usa normalmente como una parte de un proceso
de desarrollo de software, con el soporte de la herramienta
CASE apropiada, para definir los requisitos, las
interacciones y los elementos del sistema de software
propuesto.
• UML es una especificación de notación orientada a objetos
basada en las anteriores especificaciones de Booch,
Rumbaugh y la pareja Coad - Yourdon; y que divide cada
proyecto en un número de diagramas los cuales
representan las diferentes vistas del proyecto.
• Estos diagramas juntos son los que representan la
arquitectura del proyecto.
Dr. Juan José Aranda Aboy
Elementos fundamentales de UML
1. Bloques básicos de construcción
– Elementos
– Relaciones
– Diagramas
2. Reglas que dictan como se pueden combinar estos bloques
básicos. UML tiene reglas para:
–
–
–
–
–
Nombres
Alcance
Visibilidad
Integridad
Ejecución
3. Mecanismos comunes. Que se basen en algún patrón, al igual
que en arquitectura se puede hablar del barroco, románico, etc..
–
–
–
–
Especificaciones
Adornos
Divisiones comunes
Mecanismos de extensibilidad
Dr. Juan José Aranda Aboy
Diagramas en UML
• En todo proceso de software donde se utilice una metodología orientada
a objetos y la notación UML se emplearán diagramas para representar las
diferentes vistas del producto final.
• Los diagramas de UML se pueden dividir en
– Estáticos:
Se utilizan para representar tanto Modelos Conceptuales como Diagramas de
Clases de Diseño.
Ambos usos son distintos conceptualmente: mientras los primeros modelan
elementos del dominio, los segundos presentan los elementos de la solución
software.
Ambos tipos de diagramas comparten una parte de la notación para los
elementos que los forman: clases y objetos, así como las relaciones que
existen entre los mismos: asociaciones.
Sin embargo, hay otros elementos de notación que serán exclusivos de uno u
otro tipo de diagrama.
– Dinámicos:
Aportan una visión del comportamiento dinámico del sistema: secuencia de
estados por los que pasa un objeto a lo largo de su vida, eventos que hacen
que se pase de un estado a otro, respuestas y acciones que genera, patrón
de interacción entre objetos, flujo de actividades a través del tiempo.
Dr. Juan José Aranda Aboy
Diagramas estáticos
• Diagrama de casos de uso: Muestran los casos de uso, actores
y sus relaciones: quien puede hacer que y cuales relaciones
existen entre acciones (casos de uso). Son muy importantes
para modelar y organizar el comportamiento del sistema.
• Diagrama de clases: Muestra las clases, interfaces,
colaboraciones y sus relaciones. Son los más comunes y dan
una vista estática del proyecto.
• Diagrama de objetos: Es un diagrama de instancias de las
clases mostradas en el diagrama de clases. Muestra las
instancias y como se relacionan entre ellas. Se da una visión de
casos reales.
• Diagrama de componentes: Muestran la organización de los
componentes del sistema. Un componente se corresponde con
una o varias clases, interfaces o colaboraciones.
• Diagrama de despliegue: Muestra los nodos y sus relaciones.
Un nodo es un conjunto de componentes. Se utiliza para reducir
la complejidad de los diagramas de clases y componentes de un
gran sistema. Sirve como resumen e índice.
Dr. Juan José Aranda Aboy
Diagramas dinámicos
• Diagrama de estados: Muestra los estados, eventos,
transiciones y actividades de los diferentes objetos. Son
útiles en sistemas que reaccionan a eventos.
• Diagrama de actividades: Es un caso especial del
diagrama de estados. Muestra el flujo entre los objetos. Se
utilizan para modelar el funcionamiento del sistema y el
flujo de control entre objetos.
• Diagrama de secuencia, Diagrama de colaboración:
Muestran a los diferentes objetos y las relaciones que
pueden tener entre ellos, los mensajes que se envían entre
ellos. Son dos diagramas diferentes. Se puede pasar de
uno a otro sin perdida de información. Dan puntos de vista
diferentes del sistema. En resumen, cualquiera de los dos
es un Diagrama de Interacción.
Dr. Juan José Aranda Aboy
Comentarios sobre uso de diagramas
• En muchos proyectos no son necesarios todos los diagramas.
• Será la práctica y experiencia y el tipo de sistema a desarrollar lo
que nos ayudará a escoger los diagramas a utilizar. Ejemplo:
– Para aplicaciones cliente se suelen utilizar los diagramas de
casos de uso, de clases y de colaboración o de secuencia.
– Para aplicaciones donde sean importantes los eventos, se
agrega el diagrama de estados.
– Para aplicaciones cliente-servidor, aparte de los diagramas de
casos de uso, clases y objetos, también puede ser
conveniente utilizar los diagramas de despliegue y de
componentes.
– Para aplicaciones distribuidas ó complejas cliente-servidor,
será recomendable utilizar todos los diagramas, ya que darán
una visión más amplia de cómo será el sistema final.
• Como dijo Grady Booch: El 80 % de los problemas pueden
modelarse usando alrededor del 20 % de UML.
Dr. Juan José Aranda Aboy
Vistas en UML
• Vista casos de uso: Se forma con los diagramas de casos
de uso, colaboración, estados y actividades.
• Vista de diseño: Se forma con los diagramas de clases,
objetos, colaboración, estados y actividades.
• Vista de procesos: Se forma con los diagramas de la vista
de diseño. Recalcando las clases y objetos referentes a
procesos.
• Vista de implementación: Se forma con los diagramas de
componentes, colaboración, estados y actividades.
• Vista de despliegue: Se forma con los diagramas de
despliegue, interacción, estados y actividades.
Dr. Juan José Aranda Aboy
Examen de los requerimientos
• La primera fase comprende la planificación y
especificación de requisitos.
• Esta fase se corresponde con la Especificación de
Requisitos tradicional ampliada con un Borrador de
Modelo Conceptual y con una definición de Casos
de Uso de alto nivel.
• En esta fase se decidiría si se aborda la
construcción del sistema mediante desarrollo
orientado a objetos o no, por lo que, en principio,
es independiente del paradigma empleado
posteriormente.
Dr. Juan José Aranda Aboy
Actividades
1. Definir el Plan-Borrador.
2. Crear el Informe de Investigación Preliminar.
3. Definir los Requisitos.
4. Registrar Términos en el Glosario, que será
continuado en posteriores fases
5. Implementar un Prototipo. (opcional)
6. Definir Casos de Uso (de alto nivel y esenciales).
7. Definir el Modelo Conceptual-Borrador. (puede
retrasarse hasta una fase posterior)
8. Definir la Arquitectura del Sistema-Borrador.
(puede retrasarse hasta una fase posterior)
9. Refinar el Plan.
Dr. Juan José Aranda Aboy
Actividades (2)
• El orden no es estricto, lo normal es que las distintas
actividades se solapen en el tiempo.
• Esto sucede también en las actividades de las fases de
diseño, que se verán más adelante.
• De estas actividades no se va a entrar en las que
corresponden al campo de la planificación de proyectos
software, como las correspondientes a creación de planes
e informes preliminares.
• El formato del documento de Especificación de Requisitos
no está definido en UML, pero se ha incluido este punto
para resaltar que la actividad de definición de requisitos es
un paso clave en la creación de cualquier producto
software.
• Para entender y describir los requisitos la técnica de casos
de uso constituye una valiosa ayuda.
Dr. Juan José Aranda Aboy
Casos de uso
• Un Caso de Uso es un documento narrativo que describe a
los actores utilizando un sistema para satisfacer un objetivo.
Es una historia o una forma particular de usar un sistema.
• Los casos de uso son requisitos, en particular requisitos
funcionales.
• Un caso de uso individual no es un diagrama, es un
documento de texto.
• UML no define un formato para describir un caso de uso, sólo
define la manera de representar la relación entre actores y
casos de uso en un diagrama: El Diagrama de Casos de
Uso.
• Un escenario es un camino concreto a través del caso de
uso, una secuencia específica de acciones e interacciones
entre los actores y el sistema.
• Los escenarios correspondientes a un caso de uso se
representan mediante Diagramas de Secuencia.
Dr. Juan José Aranda Aboy
El Modelo de Caso de Uso
• Describe la funcionalidad propuesta del nuevo sistema.
• Como un caso de uso representa una unidad discreta de
interacción entre un usuario (humano o máquina) y el
sistema, el Caso de Uso es una unidad simple de trabajo
significativo; por ejemplo, "Validarse en el sistema",
"Registrarse en el sistema" y "Crear un pedido" son todos
casos de uso.
• Dado que expresan requisitos funcionales, cada caso de
uso tiene una descripción que describe la funcionalidad que
se construirá en el sistema propuesto. Un caso de uso
puede "incluir" la funcionalidad de otro caso de uso o
"extender" a otro caso de uso con su propio
comportamiento.
Dr. Juan José Aranda Aboy
Elementos de la descripción del Caso
de Uso
• Comentarios generales y notas describiendo el caso de uso.
• Requisitos: Cosas que el caso de uso debe permitir hacer al usuario, tales
como <capacidad para actualizar pedido>, <capacidad para modificar
pedido>, etc.
• Restricciones: Reglas acerca de qué se puede y qué no se puede hacer.
Incluye:
– Pre-condiciones que deben ser verdaderas antes de que el caso de uso se
ejecute, por ejemplo <crear pedido> debe preceder a <modificar pedido>
– Post-condiciones que deben ser verdaderas una vez que el caso de uso se
ejecutó, por ejemplo <el pedido está modificado y es consistente>
– invariantes: éstas son siempre verdaderas. Por ejemplo: un pedido debe tener
siempre un número de cliente.
• Escenarios: Descripciones secuenciales de los pasos que se toman para
llevar a cabo el caso de uso. Pueden incluir escenarios múltiples, para
satisfacer circunstancias excepcionales y caminos de proceso alternativos
• Diagramas de escenarios: Diagramas de secuencia para describir el flujo
de trabajo.
• Atributos adicionales como fase de implementación, número de versión,
rango de complejidad, estereotipo y estado.
Dr. Juan José Aranda Aboy
Ejemplo de Caso de Uso de alto nivel
• Describe el proceso de sacar dinero cuando se está
usando un cajero automático:
–
–
–
–
Caso de Uso: Realizar Reintegro.
Actores: Cliente
Tipo: Primario
Descripción:
• Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y
solicita realizar una operación de reintegro por una cantidad específica.
• El cajero automático le da el dinero solicitado tras comprobar que la
operación puede realizarse.
• El Cliente recoge el dinero y su tarjeta y se va.
• En un caso de uso descrito a alto nivel la descripción es
muy general, normalmente se condensa en dos o tres
frases.
• Es útil para comprender el ámbito y el grado de
complejidad del sistema.
Dr. Juan José Aranda Aboy
Casos de Uso expandidos
• Los casos de uso que se consideren más importantes y que se
estime que son los que más influencian al resto, se describen a un
nivel más detallado: en el formato expandido.
• La principal diferencia con un caso de uso de alto nivel está en
que incluye un apartado de Curso Típico de Eventos, pero también
incluye otros apartados como se ve en el siguiente ejemplo:
– Caso de Uso: Realizar Reintegro
– Actores: Cliente (iniciador)
– Propósito: Realizar una operación de reintegro de una cuenta del
banco
– Visión General: Un Cliente llega al cajero automático, introduce la
tarjeta, se identifica y solicita realizar una operación de reintegro por
una cantidad específica. El cajero le da el dinero solicitado tras
comprobar que la operación puede realizarse. El Cliente recoge el
dinero y la tarjeta y se va.
– Tipo: primario y esencial
– Referencias:
• Funciones: R1.3 (introducir clave) y R1.7 (introducir monto)
Dr. Juan José Aranda Aboy
Eventos del Actor
“Respuesta del Sistema”
Curso Típico:
1. Este caso de uso empieza cuando
un Cliente introduce una tarjeta en
el cajero.
2. Pide la clave de identificación.
3. Introduce la clave.
4. Presenta las opciones de
operaciones disponibles.
5. Selecciona la operación de
Reintegro.
6. Pide la cantidad a retirar.
7. Introduce la cantidad requerida.
8. Procesa la petición y da el dinero
solicitado. Devuelve la tarjeta y
genera un recibo.
9. Recoge la tarjeta.
10. Recoge el recibo.
11. Recoge el dinero y se va.
Cursos Alternativos:
• Línea 4: La clave es incorrecta.
– Se indica el error y se cancela la
operación.
• Línea 8: La cantidad solicitada
supera el saldo.
– Se indica el error y se cancela la
operación.
Dr. Juan José Aranda Aboy
Significado del formato
•
•
•
•
•
Caso de Uso: Nombre del Caso de Uso
Actores: Lista de actores (agentes externos), indicando quién inicia el caso de
uso. Los actores son normalmente roles que un ser humano desempeña, pero
puede ser cualquier tipo de sistema.
Propósito: Intención del caso de uso.
Visión General: Repetición del caso de uso de alto nivel, o un resumen similar.
Tipo:
1. primario, secundario u opcional.
2. esencial o real.
•
•
•
Referencias: Casos de uso relacionados y funciones del sistema que aparecen
en los requisitos.
Curso Típico de Eventos: Descripción de la interacción entre los actores y el
sistema mediante las acciones numeradas de cada uno. Describe la secuencia
más común de eventos, cuando todo va bien y el proceso se completa
satisfactoriamente. En caso de haber alternativas con grado similar de
probabilidad se pueden añadir secciones adicionales a la sección principal,
como se verá más adelante.
Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con
la descripción de la excepción.
Ver plantilla de Cockburn en formato Word para casos de uso (en inglés)
Dr. Juan José Aranda Aboy
Identificación de Casos de Uso
• La identificación de casos de uso requiere un conocimiento
medio acerca de los requisitos, y se basa en la revisión de
los documentos de requisitos existentes, y en el uso de la
técnica de brainstorming entre los miembros del equipo de
desarrollo.
• Como guía para la identificación inicial de casos de uso hay
dos métodos:
a) Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la
organización.
2. Para cada actor, identificar los procesos que inicia o en los
que participa.
b) Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a
tener que responder.
2. Relacionar los eventos con actores y casos de uso.
Dr. Juan José Aranda Aboy
Ejemplos de casos de uso
•
•
•
•
•
•
Sumar dos números con una calculadora.
Pedir un libro ó revista en una biblioteca.
Realizar la próxima jugada en ajedrez.
Matricularse en un curso de la facultad.
Pagar las compras del supermercado en la caja.
Comprobar la ortografía de un documento en un
procesador de textos.
• Comprar un libro en una tienda de libros en
Internet.
• etc...
Dr. Juan José Aranda Aboy
Identificación de los Límites del Sistema
• En la descripción de un caso de uso se hace referencia en
todo momento al “sistema”.
• Para que los casos de uso tengan un significado completo
es necesario que el sistema esté definido con precisión.
• Al definir los límites del sistema se establece una
diferenciación entre lo que es interno y lo que es externo al
sistema. El entorno exterior se representa mediante los
actores.
• Ejemplos de sistemas son:
– El hardware y software de un sistema informático.
– Un departamento de una organización.
– Una organización entera.
• Si no se está haciendo reingeniería del proceso de negocio,
lo común es escoger como sistema al primero de los
ejemplos: el hardware y el software del sistema que se
quiere construir.
Dr. Juan José Aranda Aboy
Tipos de Casos de Uso (a)
a) Según Importancia
• Para establecer una primera aproximación a la
prioridad de casos de uso que se identifiquen, se
distinguirá entre:
– Primarios: Representan los procesos principales, los
más comunes, como Realizar Reintegro en el caso del
cajero automático.
– Secundarios: Representan casos de uso menores, que
van a necesitarse raramente, tales como Añadir Nueva
Operación.
– Opcionales: Representan procesos que pueden no ser
abordados en el presente proyecto.
Dr. Juan José Aranda Aboy
Tipos de Casos de Uso (b)
b) Según el Grado de Compromiso con el Diseño
• En las descripciones anteriores no se han hecho
compromisos con la solución, se han descrito los casos de
uso a un nivel abstracto, independiente de la tecnología y
de la implementación.
• Un caso de uso definido a nivel abstracto se denomina
esencial. Los casos de uso definidos a alto nivel son
siempre esenciales por naturaleza, debido a su brevedad y
abstracción.
• Por el contrario, un caso de uso real describe
concretamente el proceso en términos del diseño real, de la
solución específica que se va a llevar a cabo. Se ajusta a
un tipo de interfaz específica y se baja a detalles como
pantallas y objetos en las mismas.
Dr. Juan José Aranda Aboy
Ejemplo de parte de Caso de Uso real
•
Para el caso del reintegro en un cajero automático tenemos la siguiente descripción
del Curso Típico de Eventos:
– Acción del Actor Respuesta del Sistema
1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura para
tarjetas.
2. Pide el PIN (Personal Identification Number).
3. Introduce el PIN a través del teclado numérico.
4. Presenta las opciones de operaciones disponibles.
5. etc.
6. etc.
•
•
•
En principio, los casos de uso reales deberían ser creados en la fase de Diseño de
Bajo Nivel y no antes.
Sin embargo, en algunos proyectos se plantea la definición de interfaces en fases
tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este
caso se pueden definir algunos o todos los casos de uso reales, a pesar de que
suponen tomar decisiones de diseño muy pronto en el ciclo de vida.
No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real. El grado
de compromiso con el diseño es un continuo, y una descripción específica de un
caso de uso estará situada en algún punto de la línea entre Casos de Uso
Esenciales y Reales, normalmente más cercano a un extremo que al otro, pero es
raro encontrar Casos de Uso Esenciales o Reales puros.
Dr. Juan José Aranda Aboy
Consejos relativos a Casos de Uso
• Nombre
El nombre de un Caso de Uso debería comenzar con un verbo,
para enfatizar que se trata de un proceso. Ejemplos: Comprar
Artículos o Realizar Pedido.
• Alternativas equiprobables:
Cuando se tiene una alternativa que ocurre de manera
relativamente ocasional, se indica en el apartado Cursos
Alternativos.
Pero cuando se tienen distintas opciones, todas ellas consideradas
normales se puede completar el Curso Típico de Eventos con
secciones adicionales.
Así, si en un determinado número de línea hay una bifurcación, se
pueden poner opciones que dirigen el caso de uso a una sección
que se detalla al final del Curso Típico de Eventos, en la siguiente
forma:
– Curso Típico de Eventos:
- Sección: Principal - Acción del Actor Respuesta del Sistema
– Cursos Alternativos
Dr. Juan José Aranda Aboy
Construcción del modelo de Casos de Uso
• Para construir el Modelo de Casos de Uso en la fase de Planificación y
Especificación de Requisitos se siguen los siguientes pasos:
1. Después de listar las funciones del sistema, se definen los límites del
sistema y se identifican los actores y los casos de uso.
2. Se escriben todos los casos de uso en el formato de alto nivel. Se
categorizan como primarios, secundarios u opcionales.
3. Se dibuja el Diagrama de Casos de Uso.
4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se
ilustran tales relaciones en el Diagrama de Casos de Uso.
5. Los casos de uso más críticos, importantes y que conllevan un mayor
riesgo, se describen en el formato expandido esencial. Se deja la definición
en formato expandido esencial del resto de casos de uso para cuando
sean tratados en posteriores ciclos de desarrollo, para no tratar toda la
complejidad del problema de una sola vez.
6. Se crean casos de uso reales sólo cuando:
• Descripciones más detalladas ayudan significativamente a incrementar la
comprensión del problema.
• El cliente pide que los procesos se describan de esta forma.
7. Ordenar según prioridad los casos de uso.
Dr. Juan José Aranda Aboy
Planificación de Casos de Uso según
ciclos de desarrollo
• La decisión de qué partes del sistema abordar en
cada ciclo de desarrollo se tomará basándose en
los casos de uso.
• Esto es: A cada ciclo de desarrollo se le va a
asignar la implementación de uno o más casos de
uso, o versiones simplificadas de casos de uso.
• Se asigna una versión simplificada cuando el caso
de uso completo es demasiado complejo para ser
tratado en un solo ciclo.
• Para tomar la decisión de qué casos de uso se van
a tratar primero es necesario ordenarlos según
prioridad.
Dr. Juan José Aranda Aboy
Características para prioridad
• Las características de un caso de uso específico que van a hacer que
tenga una prioridad alta son:
a. Impacto significativo en el diseño de la arquitectura. Por ejemplo, si
aporta muchas clases al modelo del dominio o requiere persistencia en
los datos.
b. Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo
relativamente bajo.
c. Incluye funciones complejas, críticas en el tiempo o de nivel elevado de
riesgo.
d. Implica bien un trabajo de investigación significante, o bien el uso de
una tecnología nueva o arriesgada.
e. Representa un proceso de gran importancia en la línea de negocio.
f. Supone directamente un aumento de beneficios o una disminución de
costes.
• Para realizar la clasificación se puede asignar a cada caso de uso una
valoración numérica de cada uno de estos puntos, y así conseguir una
puntuación total aplicando pesos a cada apartado.
Dr. Juan José Aranda Aboy
Caso de Uso “Inicialización”
• Prácticamente todos los sistemas van a tener un
caso de uso Inicialización.
• Aunque puede ser que no tenga una prioridad alta
en la clasificación realizada anteriormente,
normalmente va a interesar que sea desarrollado
desde el principio.
• Inicialmente se desarrolla una versión simplificada,
que se va completando en cada ciclo de desarrollo
para satisfacer las necesidades de inicialización de
los casos de uso que se tratan en dicho ciclo.
• Así se tiene un sistema en cada ciclo de desarrollo
que puede funcionar.
Dr. Juan José Aranda Aboy
Diagrama de Casos de Uso
• Muestra la relación entre los actores y los casos de uso del
sistema.
• Representa la funcionalidad que ofrece el sistema en lo que
se refiere a su interacción externa.
• 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.
• Cada actor está unido a los casos de uso en los que
participa mediante una línea.
• Pueden emplearse de dos formas diferentes:
– para modelar el contexto de un sistema, y
– para modelar los requisitos del sistema.
Dr. Juan José Aranda Aboy
Elementos del diagrama de Casos de Uso
Los elementos que pueden aparecer en un
Diagrama de Casos de Uso son: actores, casos de
uso y relaciones entre casos de uso.
Actores
• Un actor es algo con comportamiento, como una
persona (identificada por un rol), un sistema
informatizado u organización, y que realiza algún
tipo de interacción con el sistema.
• Se representa mediante una figura humana:
• Esta representación sirve tanto para actores que
son personas como para otro tipo de actores.
Dr. Juan José Aranda Aboy
Elementos … (2)
Casos de Uso
• Un caso de uso es una descripción de la secuencia de
interacciones que se producen entre un actor y el sistema,
cuando el actor usa el sistema para llevar a cabo una tarea
específica.
• Expresa una unidad coherente de funcionalidad, y se
representa en el Diagrama de Casos de Uso mediante una
elipse con el nombre del caso de uso en su interior.
• El nombre del caso de uso debe reflejar la tarea específica
que el actor desea llevar a cabo usando el sistema.
Dr. Juan José Aranda Aboy
Elementos … (3)
Relaciones entre Casos de Uso
• Un caso de uso, en principio, debería describir una tarea
que tiene un sentido completo para el usuario.
• Sin embargo, hay ocasiones en las que es útil describir una
interacción con un alcance menor como caso de uso.
• La razón para utilizar estos casos de uso no completos en
algunos casos, es mejorar la comunicación en el equipo de
desarrollo, el manejo de la documentación de casos de
uso.
• Para el caso de que queramos utilizar estos casos de uso
más pequeños, las relaciones entre ellos y los casos de
uso ordinarios pueden ser de tres tipos.
Dr. Juan José Aranda Aboy
Ejemplo en ArgoUML
Dr. Juan José Aranda Aboy
Relaciones
1. Asociación
• Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra
operación (caso de uso). Dicha relación se denota
con una flecha simple.
2. Dependencia o Instanciación
• Es una forma muy particular de relación entre
clases, en la cual una clase depende de otra, es
decir, se instancia (se crea). Dicha relación se
denota con una flecha punteada.
Dr. Juan José Aranda Aboy
Relaciones (2)
3. Generalización
• Este tipo de relación cumple una doble función
dependiendo de su estereotipo:
– de Uso (<<uses>>) o
– de Herencia (<<extends>>).
• Está orientado exclusivamente para casos de uso, y no
para actores.
– extends: Se recomienda utilizar cuando un caso de uso posee
características similares a otro.
– uses: Se recomienda cuando se tiene un conjunto de
características que son similares en más de un caso de uso y no se
desea mantener copiada la descripción de la característica.
• De lo anterior cabe mencionar que tiene el mismo
paradigma en diseño y modelamiento de clases, en donde
está la duda clásica de usar o heredar.
Dr. Juan José Aranda Aboy
Generalización
• Se emplea cuando un caso de uso definido de
forma abstracta se particulariza por medio de otro
caso de uso más específico.
• Como vemos, la generalización se representa por
una línea continua entre los dos casos de uso, con
el triángulo que simboliza generalización en UML,
pegado al extremo del caso de uso más general.
• Al igual que en la herencia entre clases, el caso de
uso hijo hereda las asociaciones y características
del caso de uso padre.
• El caso de uso padre se trata de un caso de uso
abstracto, que no está definido completamente.
Dr. Juan José Aranda Aboy
Relación <<include>>
• Un caso de uso base incorpora explícitamente a
otro caso de uso en un lugar especificado en dicho
caso base.
• Se suele utilizar para encapsular un
comportamiento parcial común a varios casos de
uso.
Dr. Juan José Aranda Aboy
Relación <<extend>>
• Cuando un caso de uso base tiene ciertos puntos
(llamados puntos de extensión) en los cuales,
dependiendo de ciertos criterios, se va a realizar
una interacción adicional.
• El caso de uso que extiende describe un
comportamiento opcional del sistema, a diferencia
de la relación incluye que se da siempre que se
realiza la interacción descrita.
Dr. Juan José Aranda Aboy
Ejemplo Simulación con NetBeans 5.5
Dr. Juan José Aranda Aboy
Modelado del contexto
• Se debe modelar la relación del sistema con
los elementos externos, ya que son estos
elementos los que forman el contexto del
sistema.
• Los pasos a seguir son:
– Identificar los actores que interactúan con el
sistema.
– Organizar a los actores.
– Especificar sus vías de comunicación con el
sistema.
Dr. Juan José Aranda Aboy
Modelado de requisitos
• La función principal, o la mas conocida, del
diagrama de casos de uso es documentar los
requisitos del sistema, o de una parte de él.
• Los requisitos establecen un contrato entre el
sistema y su exterior, definen lo que se espera que
realice el sistema, sin definir su funcionamiento
interno.
• Es el paso siguiente al modelado del contexto, no
indica relaciones entre autores, tan solo indica
cuales deben ser las funcionalidades (requisitos)
del sistema.
• Se incorporan los casos de uso necesarios que no
son visibles desde los usuarios del sistema.
Dr. Juan José Aranda Aboy
Recomendaciones para
modelado de requisitos
• Establecer su contexto, para lo que también
podemos usar un diagrama de casos de uso.
• Identificar las necesidades de los elementos del
contexto (Actores).
• Nombrar esas necesidades y darles forma de caso
de uso.
• Identificar que casos de uso pueden ser
especializaciones de otros, o buscar
especializaciones comunes para los casos de uso
ya encontrados.
Dr. Juan José Aranda Aboy
El Modelo Lógico
• Un modelo lógico es una vista estática de los
objetos y las clases que cubren el espacio de
análisis y diseño.
• Típicamente, un modelo de dominio es una vista
más pobre, de alto nivel de los objetos de negocio
y de las entidades, mientras que el modelo de
clases es un modelo más riguroso y enfocado al
diseño.
• La identificación de clases incluye conocer cuáles
elementos deberían existir en el sistema, parte
fundamental del diseño orientado a objetos.
Dr. Juan José Aranda Aboy
¿Qué son las clases?
• Una clase describe un conjunto de objetos
con un rol ó roles equivalentes en un
sistema.
• Los objetos, y su división en clases, derivan
de:
– Cosas tangibles, ó “del mundo real”: libro, curso.
– Roles: estudiante, pasajero.
– Eventos: llegada, salida, compra.
– Interacciones: encuentro, intersección.
Dr. Juan José Aranda Aboy
Identificación de clases
¿Qué hace que un modelo de clases sea bueno?
1. Cada comportamiento que requiera el sistema debe ser
proporcionado por los objetos de las clases que se elijan.
2. Un buen modelo de clases está formado, dentro de lo
posible, por clases que representan elementos
permanentes de los objetos del dominio,
independientemente de la funcionalidad requerida en un
momento dado.
•
El secreto de un buen diseño orientado a objetos está en
terminar con un modelo de clases que:
– no distorsione la realidad conceptual del dominio, y
que
– permita una implementación coherente de la
funcionalidad requerida.
Dr. Juan José Aranda Aboy
Como construir un modelo de clases
•
La colección de clases en un modelo de diseño
probablemente cambiará a lo largo de las
iteraciones del desarrollo.
• Primero se identifican las clases mas relevantes
de los objetos del dominio: pertenecientes al
problema obviamente; en vez de aquellas clases
introducidas para resolverlo.
• Existen dos tendencias principales que se
complementan:
1. Diseño dirigido por los datos.
2. Diseño dirigido por la responsabilidad.
Dr. Juan José Aranda Aboy
Datos versus Responsabilidad
• Las clases tienen tanto datos como
responsabilidades.
• Una imperfección del diseño dirigido a los datos es
que supone la identificación de todos los datos del
sistema, para dividirlos en clases antes de
considerar las responsabilidades de las clases.
– Una técnica: Identificación de nombres.
• Una imperfección del diseño dirigido a la
responsabilidad es que supone la identificación de
todas las responsabilidades en el sistema y su
división en clases antes de considerar los datos.
– Una técnica: Tarjetas Clase, Responsabilidades,
Colaboración – CRC.
Dr. Juan José Aranda Aboy
Identificación de nombres
Se procede en dos etapas:
1. Identificar las clases candidatas
seleccionando todos los nombres y
locuciones nominales de la especificación
de requisitos del sistema.
2. Descartar candidatas inapropiadas,
renombrando las clases restantes, si es
necesario.
Dr. Juan José Aranda Aboy
Razones para descartar una clase
• Redundante: A la misma clase se le ha dado mas de un
nombre. Deben distinguirse objetos parecidos que no poseen
diferencias suficientes para catalogarlos en clases distintas.
• Impreciso: No se puede especificar el significado de un
nombre. Hay que eliminar la ambigüedad previo a la decisión
si es clase.
• Evento u operación: Hace referencia a algo que se hace
para, por ó en el sistema.
• Metalenguaje: El nombre forma parte de la manera en que se
definen las cosas.
• Fuera del alcance del sistema: El nombre importa para
describir cómo funciona el sistema, no sus aspectos internos.
• Atributo: El nombre referencia algo simple, sin
comportamiento, que es atributo de otra clase.
Dr. Juan José Aranda Aboy
Tarjetas CRC
Se almacenan:
1. El nombre de la clase
2. Las responsabilidades
3. Los colaboradores
•
La responsabilidad de la clase describe su propósito a
alto nivel.
•
Una clase debe tener, como máximo, entre tres y cuatro
responsabilidades. Frecuentemente tienen una sola.
•
Demasiadas responsabilidades se corresponden con una
cohesión débil del modelo.
•
Muchos colaboradores indican un fuerte acoplamiento.
Dr. Juan José Aranda Aboy
Asociaciones
• Corresponden con verbos.
• Expresan las relaciones entre clases.
• Hay instancias de asociaciones: enlaces, al igual que
instancias de clases: objetos. Una instancia de
asociación relaciona un par de objetos.
• La clase A está asociada con la clase B si:
– Un objeto de la clase A envía un mensaje a un
objeto de la clase B.
– Un objeto de la clase A crea un objeto de la clase B.
– Un objeto de la clase A tiene un atributo cuyos
valores son objetos ó colecciones de objetos de la
clase B.
– Un objeto de la clase A recibe un mensaje con un
objeto de la clase B como parámetro.
Dr. Juan José Aranda Aboy
Operaciones de una clase
• Definen las maneras en que los objetos pueden
interactuar.
• Un objeto envía un mensaje a otro solicitándole que
realice una operación.
• El receptor invocará a uno de sus métodos para
realizar dicha operación.
• El emisor no sabe que método será invocado, ya que
puede haber muchos métodos implementando dicha
operación en diferentes niveles de la jerarquía.
• La firma (signature) de una operación da el selector,
los nombres y tipos de cualquier parámetro formal ó
argumento de la operación, así como el tipo del valor
de retorno.
Dr. Juan José Aranda Aboy
Atributos de una clase
• Describen los datos contenidos en un objeto
de la clase.
Representación de una clase en UML.
Dr. Juan José Aranda Aboy
Vistas de operaciones y atributos
• Se tiene una aproximación conceptual y
pragmática, que se intenta hacer consistente.
• Permite identificar:
– que datos están conceptualmente asociados con un
objeto de esa clase, y
– que mensajes parece razonables esperar que entienda
un objeto.
• Debe comprobarse que se han incluido los datos y
el comportamiento suficientes para los datos en
cuestión, por lo que deberá considerarse cómo
trabajan juntos los objetos de las diversas clases
para satisfacer los requerimientos del sistema.
• Las tarjetas CRC apoyan esta última observación.
Dr. Juan José Aranda Aboy
Ejemplo de diagrama de clases:
• Una Cuenta Corriente posee como
características:
– balance
• Puede realizar las operaciones de:
– depositar
– girar
– balance
• El diseño asociado es:
Dr. Juan José Aranda Aboy
Vista de la clase en el modelo
Dr. Juan José Aranda Aboy
Atributos y Métodos
Atributos:
• Los atributos o características de
una Clase pueden ser de tres tipos:
los que definen el grado de
comunicación y visibilidad de ellos
con el entorno, estos son:
• public (+): Indica que el atributo
será visible tanto dentro como fuera
de la clase, es decir, es accesible
desde todos lados.
• private (-): Indica que el atributo
sólo será accesible desde dentro de
la clase: sólo sus métodos lo
pueden acceder.
• protected (#): Indica que el atributo
no será accesible desde fuera de la
clase, pero si podrá ser accedido
por métodos de la clase además de
las subclases que se deriven.
Métodos:
• Los métodos u operaciones de una
clase son la forma en como ésta
interactúa con su entorno, éstos
pueden tener las características:
• public (+): Indica que el método
será visible tanto dentro como fuera
de la clase, es decir, es accesible
desde todos lados.
• private (-): Indica que el método
sólo será accesible desde dentro de
la clase: sólo otros métodos de la
propia clase lo pueden acceder.
• protected (#): Indica que el método
no será accesible desde fuera de la
clase, pero si podrá ser accedido
por métodos de la clase, además de
por métodos de las subclases que
se deriven.
Dr. Juan José Aranda Aboy
Relaciones entre clases
• Para describir como se pueden interrelacionar dos
o más clases, cada una con características y
objetivos diferentes, es necesario explicar el
concepto de cardinalidad de relaciones:
Multiplicidades.
• En UML, la cardinalidad de las relaciones indica el
grado y nivel de dependencia.
• Se anota en cada extremo de la relación y éstas
pueden ser:
– uno o muchos: 1..* (1..n)
– 0 o muchos: 0..* (0..n)
– número exacto ó fijo: m (m denota el número).
Dr. Juan José Aranda Aboy
Herencia
(Especialización / Generalización)
• Indica que una subclase hereda
los métodos y atributos
especificados por una Super
Clase.
• Por tanto, la Subclase, además
de poseer sus propios métodos
y atributos, poseerá las
características y atributos
visibles de la Super Clase
(public y protected).
• El ejemplo especifica que Auto
y Camión heredan de Vehículo.
Dr. Juan José Aranda Aboy
Agregación
•
Para modelar objetos complejos no bastan los tipos de datos básicos
que proveen los lenguajes: enteros, reales y secuencias de caracteres.
• Cuando se requiere componer objetos que son instancias de clases
definidas por el desarrollador de la aplicación, tenemos dos
posibilidades:
1. Por Valor: Es un tipo de relación estática, en donde el tiempo de vida
del objeto incluido esta condicionado por el tiempo de vida del que lo
incluye. Este tipo de relación es comúnmente llamada Composición:
el Objeto base se construye a partir del objeto incluido, es decir, es
"parte/todo".
2. Por Referencia: Es un tipo de relación dinámica, en donde el tiempo
de vida del objeto incluido es independiente del que lo incluye. Este
tipo de relación es comúnmente llamada Agregación: el objeto base
utiliza al incluido para su funcionamiento. Un Ejemplo es:
Dr. Juan José Aranda Aboy
Asociación
• Permite asociar objetos que colaboran entre
si.
• No es una relación fuerte, es decir, el tiempo
de vida de un objeto no depende del otro.
• Ejemplo:
Dr. Juan José Aranda Aboy
Dependencia o Instanciación (uso)
• Representa un tipo de relación muy particular, en
la que una clase es instanciada: su instanciación
es dependiente de otro objeto/clase.
• Se denota por una flecha punteada.
• El uso más particular de este tipo de relación es
para denotar la dependencia que tiene una clase
de otra, como por ejemplo una aplicación grafica
que instancia una ventana: la creación del Objeto
Ventana esta condicionado a la instanciación
proveniente desde el objeto Aplicación.
Dr. Juan José Aranda Aboy
Clase Abstracta
• Una clase abstracta se denota con el nombre de la
clase y de los métodos con letra "itálica".
• Esto indica que la clase definida no puede ser
instanciada pues posee métodos abstractos:
métodos que aún no han sido definidos, es decir,
sin implementación.
• La única forma de utilizarla es definiendo
subclases que implementen los métodos
abstractos definidos.
Dr. Juan José Aranda Aboy
Clase parametrizada
• Una clase parametrizada se denota con un subcuadro en el extremo
superior de la clase, en donde se especifican los parámetros que deben
ser pasados a la clase para que esta pueda ser instanciada.
• El ejemplo típico es el caso de un Diccionario, en donde una llave o
palabra tiene asociado un significado, pero en este caso las llaves y
elementos pueden ser genéricos.
• La genericidad puede venir dada de una plantilla (template), como en el
caso de C++, o bien de alguna estructura predefinida: especialización a
través de clases.
• En el ejemplo no se especificaron los atributos del Diccionario, pues
ellos dependerán exclusivamente de la implementación que se le
quiera dar.
Dr. Juan José Aranda Aboy
Referencias en Internet
•
•
•
•
•
•
•
Desarrollo Orientado a Objetos con UML
Tutorial de UML DCC UChile (versión ZIP)
Introducción a UML
UML con ArgoUML y Poseidon
UML® Resource Page
TOUR POR UML
Programación: Ingeniería de Software:
–
–
–
–
¿Qué es UML?
UML: Análisis y Diseño Orientado a Objetos
UML Guía Visual
Base de Datos y UML
Dr. Juan José Aranda Aboy
Referencias de UseCases
(en inglés)
Plantilla para escribir casos de uso:
• (en formato Word)
• (en formato plain text)
• [usecases/uctempla (en html)
Artículos:
• Structuring use cases with goals (Cockburn)
• Use case fundamentals (Peter)
• Pluggable use cases (Strysick)
• Use cases, ten years later (Cockburn)
• Sample system requirements document (Cockburn)
• An open letter to object technology newcomers(Cockburn)
Presentaciones:
• Use cases in theory and practice 180
• Agile Use Cases (Writing Effective Use Cases meets Agile Software
Development) 180 and
• Agile Use Cases
Dr. Juan José Aranda Aboy
Referencias sobre herramientas para UML
(en inglés) según
Objects by design: UML Products by Price
• ArgoUML Tutorial
– ArgoUML: Building a Use Case Diagram
• NetBeans 5.5 UML Modeling Documentation
• Umbrello (sólo para KDE y para los que usamos Linux y
OpenSource)
• EclipseUML Free Edition
– MyEclipse UML (comercial)
•
•
•
•
•
Poseidon for UML (comercial)
Rational software (comercial)
Visual Paradigm for UML (comercial)
MagicDraw UML (comercial)
Borland® Together® Visual Modeling for Software
Architecture Design (comercial)
• Enterprise Architect 6.5 - Modelado avanzado con UML 2.1
(comercial) (versión demostrativa) (Recursos)
Dr. Juan José Aranda Aboy
Adictos al trabajo
• Introducción al UML Este es el primer articulo sobre el diseño de
proyectos orientados a objeto con UML, donde se describe los
primeros diagramas a utilizar.
• Modelado UML con Visual Paradigm Muestra como instalar y
utilizar la versión gratuita de Visual Paradigm for UML, que
permite extraer elementos de diseño desde textos de análisis.
• Integración de Visual Paradigm en NetBeans Muestra como
integrar esta herramienta con Netbeans.
• Gestión de proyectos con Project Este tutorial enseña a crear un
plan, realizar seguimiento del proyecto, cerrarlo y comunicar los
resultados.
• Problemas al planificar un proyecto Este artículo presenta una
plantilla modelo básica para un proyecto software orientado a
aplicaciones Web/Java OOP.
• Todos los Tutoriales
Dr. Juan José Aranda Aboy