CLASE 3: UML DIAGRAMAS CASOS DE USO - …martinez/cursos/ci3715/clase3_AJ2010.pdf · Vistas y diagramas de UML ... • Para particionar un caso de uso complejo en los casos de usos

CLASE 3: UML DIAGRAMAS CASOS DE USO

Universidad Simón Bolívar. Ingeniería de Software. Prof. Ivette Martínez

UML

  UML es un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas de software [OMG].   Artefacto: Modelo o pieza de información producido en el proceso

de desarrollo de software.

  UML representa un conjunto de las mejores prácticas que han probado ser exitosas en el modelado de sistemas grandes y complejos.

Motivación

  Por qué modelamos?   Desarrollar un modelo para software de mediana a gran

envergadura antes de construirlo o modificarlo es escencial.   Comunicación entre los equipos del proyecto   Asegurar la solidez de la arquitectura   Porque no podemos comprender un sistema complejo ¨entero¨.   A medida que la complejidad de los sistemas se incrementa, se hace

más necesario modelar.

Objetivos de UML

  Proporcionar a los usuarios un lenguaje de modelado visual, expresivo y listo para usar, para desarrollar e intercambiar modelos significativos

  Proporcionar mecanismos de extensión y especialización de sus conceptos básicos

  Ser independiente de los procesos de desarrollo y de los lenguajes de programación.

  Soportar el desarrollo de conceptos de alto nivel como colaboraciones, marcos de trabajo (frameworks), patrones y componentes.

Artefactos

  La escogencia de los modelos y diagramas a crear influye sobre como se ataca el problema y la forma de su solución.

  La abstracción es la clave para aprender y comunicar.

  Debido a esto:  La mejor forma de abordar un sistema complejo es a

través de vistas independientes del modelo.  Cada modelo puede expresarse con diferentes niveles

de fidelidad.

Lenguaje de Modelado

  Lenguaje para expresar mediante diagramas gráfico diferentes vistas o perspectivas de un sistema en análisis o en desarrollo

Sistema

Lenguaje de Modelado

  Lenguaje para expresar mediante diagramas gráficos diferentes vistas o perspectivas de un sistema en análisis o en desarrollo

Sistema

Vistas en UML

  Presentan el sistema desde diferentes perspectivas.

  Para la descripción de un sistema se seleccionan los diagramas más apropiados (depende de la aplicación).

  Son válidas para diferentes enfoques (No necesariamente OO).

Vistas y diagramas de UML

  Una vista es una descripción completa de un sistema desde una perspectiva particular

Vistas y diagramas de UML

  Área estructural   Vista estática (lógica) --> Diagrama de Clase. Modela los conceptos del dominio de la aplicación y las relaciones

entre ellos.   Vista de componentes (física) --> Diagrama de Componentes. Modela los componentes de un sistema y sus dependencias   Vista de componentes (lógica) --> Diagrama de Casos de Uso. Modela la funcionalidad del sistema como lo perciben los usuarios

externos.   Vista de despliegue(física) --> Diagrama de despliegue. Representa la disposición de las instancias de los componentes de

ejecución en instancias de nodos.

Vistas y diagramas de UML

  Area dinámica   Vista de máquina de estados (lógica) --> Diagrama de estados. Modela los comportamientos posibles de un objeto de una clase usando estados   Vista de actividad (física) --> Diagrama de actividad. Muestra las actividades, su secuenciamiento y coordinación   Vista de interacción (lógica) --> Diagramas de secuencia --> Diagrama de colaboración Describe las secuencias de intercambios de mensajes entre los roles que implementan el comportamiento del sistema

Diagrama de Casos de Uso

  Especifica las funcionalidades de un sistema. Para ello muestra Actores, Casos de Uso y sus relaciones.

  Describe las acciones que dan un resultado observable de valor a un actor

  Identifica las funcionalidades visibles al usuario

  Captura las funcionalidades del sistema (el qué), omitiendo la implementación de las mismas (el cómo)‏

Actores

Un actor define un conjunto coherente de roles que los usuarios de una entidad pueden jugar cuando interactúan con la entidad.

Notación:

Nombre

<<actor>>

Nombre

Casos de Uso

  Los Casos de Uso representan funcionalidades de un sistema, un subsistema o una clase

  Estas funcionalidades se manifiestan a través de secuencias de mensajes intercambiados entre el sistema y uno o más actores junto con las acciones realizadas por el sistema.

Notación:

Nombre

Relaciones

Relaciones entre actores y casos de uso •  Asociación

Relaciones entre casos de uso:

  Extensión (<<Extend>>)   Generalización

  Inclusión (<<Include>>) Relaciones entre actores:

  Generalización

Relaciones entre Actores y Casos de Uso

  Asociación Relaciona la participación

de un actor

en un caso de uso

Ir al cine

Persona

Sistema

Ir al cine

Persona

Relaciones entre Actores y Casos de Uso

 En la relación de Asociación puede indicarse la cardinalidad

Ir al cine

Actor Caso de uso

1 *

Persona

Ir al cine Ir al cine

Relaciones entre Casos de Uso

  Extensión (<<Extend>>)

  Generalización   Inclusión (<<Include>>)

Relación que define una extensión

de la funcionalidad de otro caso de uso

Relación de extensión: <<extend>>

Ir al cine

<<extend>> {tengo dinero}

Comprar cotufas

Persona

Sistema

Relación de extensión: <<extend>> (extension points)

Comprar cotufas

<<extend>> {tengo dinero}

  Extension points: el caso de uso podrá

ejecutarse una vez alcanzado el (los) extension point(s) indicado(s)

Ir al cine Extension points

requerimientos adicionales: despues de entrar al cine

Persona

Relación de extensión: <<extend>>

  Es una asociación que describe una extensión de otro caso de uso (base).

  ¿Cuándo usarla? •  En partes opcionales de un caso de uso •  Cursos separados que son ejecutados sólo bajo ciertas

condiciones •  En funcionalidades que pueden ser invocadas

directamente por algún actor

Relación de extensión: <<extend>>

  Es una asociación que describe una extensión de otro caso de uso (base).

  ¿Cuándo usarla? •  En partes opcionales de un caso de uso •  Cursos separados que son ejecutados sólo bajo

ciertas condiciones •  En funcionalidades que pueden ser invocadas

directamente por algún actor

  Extensión (<<Extend>>)

  Generalización

  Inclusión (<<Include>>)

Relaciones entre Casos de Uso

Relación que define un caso de uso

como una generalización de otro caso de uso

Generalización

 Relación Generalización: el caso de uso divertirse es una generalización

del caso de uso ir al cine

Ir al cine divertirse

  Extensión (<<Extend>>)

  Generalización

  Inclusión (<<Include>>)

Relaciones entre Casos de Uso

Relación que define una instancia de un

caso de uso como un curso obligatorio en otro

caso de uso

Relación de Inclusión: <<include>>

 Relación include: el caso de uso Ir al cine incluye el comportamiento especificado en el caso de uso Comprar entrada

<<include>> Comprar entrada

Comprar cotufas

<<extend>> {tengo dinero}

Ir al cine Extension points

requerimientos adicionales: despues de entrar al cine

1 *

Persona

Relación de Inclusión: <<include>>

  Es una asociación que relaciona cursos fuertemente acoplados que conforman el curso completo del caso de uso base

  ¿Cuándo usarla? •  Para particionar un caso de uso complejo en los

casos de usos mas simples •  Cuando se quiere separar una funcionalidad en un

caso de uso, sin que ésta pueda ser iniciada directamente por un actor

Relaciones entre actores

  Generalización

Un actor es una instancia de otro actor

Generalización

Estudiante Persona

Relación de Generalización: Una Persona es una generalización de un Estudiante

Resumen: Diagramas de Casos de Uso

 Un Diagrama de Casos de uso muestra gráficamente las funcionalidades de un sistema, subsistema o clase.

 En un Diagrama de Casos de Uso se visualizan los actores, los casos de uso y las relaciones entre ellos, pudiéndose colocar la cardinalidad.

Resumen: Diagrama de Casos de Uso

  En un Diagrama de Casos de Uso se muestran las relaciones entre Casos de Uso; éstas son de tres tipos: inclusión, generalización y extensión.

 Cuando se trabaja con relaciones de extensión es conveniente representar los “entry points”.

  También es posible visualizar relaciones de generalización entre actores.