UML Necesidad modelado Diagramas de clase Diagramas de secuencia

Presentación del tema: "UML Necesidad modelado Diagramas de clase Diagramas de secuencia"— Transcripción de la presentación:

1 UML Necesidad modelado Diagramas de clase Diagramas de secuencia
Casos de uso Informatica II

2 UML Necesidad modelado Use cases Diagramas de clase
Diagramas de secuencia Informatica II

3 Objetivos al desarrollar software
Satisfacer las necesidades de los usuarios. Entregar el software en tiempo y con un costo predecible. Comprender mejor el sistema que se está construyendo. Informatica II

4 Acciones para alcanzar los objetivos
Realizar una buena elicitación de requerimientos. Desarrollar un modelo del sistema. Informatica II

5 ¿Que es un modelo? Simplificación de la realidad.
Incluir los elementos que son importantes y omitir los elementos que no son relevantes para ese nivel de abstracción. Informatica II

6 ¿Que es un modelo? Diferentes modelos Modelos estructurales
Modelos de comportamiento Informatica II

7 Construcción de una casa para “fido”
Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Informatica II

8 Construcción de una casa
Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas Informatica II

9 Claves en Desarrollo de SI
Notación Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Herramientas Proceso Informatica II

10 Abstracción - Modelado Visual (MV)
“El modelado captura las partes esenciales del sistema” Proceso de Negocios Orden Item envío Sistema Computacional Informatica II

11 MV promueve la reutilización
Múltiples Sistemas Componentes Reutilizados Informatica II

12 MV para definir la Arquitectura del SW
Interfaz de Usuario (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..) Servidor de BDs (C++ & SQL, ..) “Modelar el sistema independientemente del lenguaje de implementación” Informatica II

13 Etapas en la construcción de un proceso de software
¿Qué es lo que va a construir? ¿Cómo lo va a construir? ¿Qué tecnología usará? ¿Cómo lo documentará? Informatica II

14 Etapas en la construcción de un proceso de software
Análisis Diseño Refinamiento del diseño Implementación Documentación Informatica II

15 UML Es una notación gráfica para modelar. Es un lenguaje de modelado.
Informatica II

16 UML “aglutina” enfoques OO
Rumbaugh Booch Jacobson Odell Meyer Pre- and Post-conditions Shlaer-Mellor UML Object life cycles Harel State Charts Gamma et. al. Frameworks, patterns, notes Embly Wirfs-Brock Singleton classes Fusion Responsabilities Operation descriptions, Informatica II message numbering

17 II. Breve Tour por UML ... Diagramas de UML Los diagramas expresan gráficamente partes de un modelo State Diagrams Diagramas de Clases Use Case Diagrams Use Case Diagrams State Diagrams Use Case Diagrams Diagramas de Casos de Uso State Diagrams Use Case Diagrams Diagramas de Objetos Diagramas de Secuencia Scenario Diagrams State Diagrams Scenario Diagrams State Diagrams Diagramas de Colaboración Diagramas de Componentes Modelo Scenario Diagrams Component Diagrams Scenario Diagrams Component Diagrams Diagramas de Estados Diagramas de Distribución Diagramas de Actividad Informatica II

18 ... Diagramas seleccionados
Diagramas de Casos de Uso Diagramas de Secuencia Diagramas de Clases Informatica II

19 Modelos y Diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Informatica II

20 Modelos y Diagramas Diagrama: una representación gráfica de una colección de elementos de modelado. Informatica II

21 ... Modelos y Diagramas Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ... Informatica II

22 UML Necesidad modelado Casos de uso Diagramas de clase
Diagramas de secuencia Informatica II

23 Casos de Uso Un caso de uso es una interacción entre el usuario y el sistema para lograr cierto objetivo. Objetivo de los mismos. Son de tamaño variable. Se debe especificar todos los cursos alternativos. Informatica II

24 … Casos de Uso Actores: Roles de los usuarios
Otros sistemas: sistemas con los que el sistema interactúa (el otro sistema necesita algo del sistema que se desarrolla) Informatica II

25 Ejemplos Informatica II - 2002 Verificar Situación del Cliente
Supervisor En los D. de Casos de Uso no existe el concepto de “explosión” tal como se tiene en los DFDs (Diagramas de Flujo de Datos). La funcionalidad representada por un caso de uso es “atómica” (aunque en Rational Rose 98 a un caso de uso se le puede asociar un nuevo D. de Casos de Uso!!). En UML el concepto de paquete permite organizar de manera jerárquica un modelo, y en este caso, un paquete puede tener asociado un nuevo diagrama. Preparar Catálogo Administrativo Sistema Inventario Informatica II

26 III. El Paradigma OO: Diagrama de Casos de Uso
Ejemplo: Caso de Uso A Actor A Caso de Uso B Actor B Informatica II

27 … Casos de Uso Identificación de casos de usos
Eventos ante los cuales se debe reaccionar Actores que intervienen Informatica II

28 … Casos de Uso Representación de escenarios alternativos
Informatica II

29 … Ejemplos Venta Normal Ventas Venta en Rebajas Venta en Ofertas
Vendedor Informatica II

30 Casos de Uso Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación Algunas similitudes y diferencias entre DFDs y D. de Casos de Uso: Un caso de uso es una función (servicio o transacción) atómica ofrecida por el sistema al entorno (actores), mientras que un proceso de un DFD puede ser detallado en un DFD hijo. Así, el concepto de “explosión de proceso” sólo se aplica a los DFDs. Aunque en cierta forma con relaciones de inclusión entre casos de uso (que se explican más adelante) puede mostrarse la factorización de un caso de uso, esto no llega a ser equivalente a explosión de proceso. Aunque un caso de uso y un proceso modelan una pieza de funcionalidad del sistema su especificación es diferente. En un caso de uso interesa expresar la funcionalidad mediante la interacción (pasos de comunicación) actor(es) – sistema. En un proceso la funcionalidad se expresa mediante la transformación que se hace de los flujos de entrada para producir flujos de salida. Un caso de uso en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visión externa del sistema. La excepción a lo anterior podría producirse al factorizar funcionalmente un caso de uso para establecer una relación de inclusión (que se explica más adelante). Un DFD, según sea el nivel de detalle, puede mostrar descomposición funcional interna del sistema. La diferencia entre Captura de Requisitos y Análisis radica esencialmente en el grado de detalle que se obtiene respecto del particionamiento del problema (funcional y de datos). La Captura de Requisitos ofrece un particionamiento en el contexto del usuario y adecuado para su comprensión. El Análisis provee un particionamiento que pueda ser utilizado como entrada para el Diseño del Sistema. Así, se puede afirmar que los D. de Casos de Uso son una herramienta exclusivamente de Captura de Requisitos mientras que los DFD podrían utilizarse en ambas actividades. En captura de requisitos para un DFD una entidad externa equivale a un actor, un almacén único y global evita entrar en análisis de datos y los procesos establecidos sólo hasta el nivel de transacciones externas se corresponderían con casos de uso. Las relaciones de extensión y de generalización entre casos de uso no tienen correspondencias en los DFDs. ... Informatica II

31 … Casos de Uso Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario Un escenario es una instancia de un caso de uso Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso Una característica resaltada respecto de un proceso de desarrollo de software asociado a UML es su naturaleza “use case driven”, es decir, el proceso es dirigido por los casos de uso. Esto significa que en puntos determinado del desarrollo se valida y verifica el correspondiente modelo respecto del modelo de casos de uso. En sí la especificaciones de casos de uso (con los respectivos diagramas de interacción) constituyen una especificación de casos de prueba para el sistema (pruebas funcionales). Informatica II

32 Casos de Uso: Relaciones
UML define tres tipos de relación en los Diagramas de Casos de Uso: Comunicación Caso de Uso Actor Informatica II

33 … Casos de Uso: Relaciones
III. El Paradigma OO: Diagrama de Casos de Uso … Casos de Uso: Relaciones Inclusión(uses) : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino <<include>> reemplazó al denominado <<uses>> <<include>> Para la explicación de las relaciones entre casos de uso se han identificado como “caso de uso origen” y “caso de uso destino” sólo para indicar el sentido del símbolo (flecha de generalización). Caso de Uso Origen Caso de Uso Destino Informatica II

34 … Casos de Uso: Relaciones
Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino <<extend>> Las relaciones <<include>> y <<extend>> corresponden ambas a factorizaciones del comportamiento de un caso de uso, es decir, el caso de uso incluido y el caso de uso que extiende representan un fragmento de interacción de otro caso de uso. Sin embargo, la intensión es diferente; la relación <<include>> pretende evitar duplicación de interacciones en distintos casos de uso, la relación <<extends>> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso. Caso de Uso Origen Caso de Uso Destino Informatica II

35 … Casos de Uso: Relaciones
Ejemplo: Identificación <<include>> ¿Podría en este ejemplo haberse modelado el caso de uso “Transferencia por Internet” con una relación de generalización hacia el caso de uso “Transferencia”?. Si la idea de extensión (vista como especialización) forma parte esencial del concepto de generalización/especialización, ¿para qué tener dos tipos de relaciones? ... estos son algunos de lo muchos aspectos de UML que están en discusión. Transferencia Cliente <<extend>> Transferencia en Internet Informatica II

36 Casos de Uso: Construcción
Un caso de uso debe ser simple, inteligible, claro y conciso Generalmente hay pocos actores asociados a cada Caso de Uso Informatica II

37 Casos de Uso: Construcción
Preguntas clave: ¿cuáles son las tareas del actor? ¿qué información crea, guarda, modifica, destruye o lee el actor? ¿debe el actor notificar al sistema los cambios externos? ¿debe el sistema informar al actor de los cambios internos? Informatica II

38 … Casos de Uso: Construcción
La descripción del Caso de Uso comprende: el inicio: cuándo y qué actor lo produce? el fin: cuándo se produce y qué valor devuelve? la interacción actor-caso de uso: qué mensajes intercambian ambos? Informatica II

39 … Casos de Uso: Construcción
objetivo del caso de uso: ¿qué lleva a cabo o intenta? cronología y origen de las interacciones repeticiones de comportamiento: ¿qué operaciones son iteradas? situaciones opcionales: ¿qué escenarios alternativos se presentan en el caso de uso? Informatica II

40 UML Necesidad modelado Casos de uso Diagramas de clase
Diagramas de secuencia Informatica II

41 Implementación Clases: abstracciones del mundo real. Perspectiva más usada Informatica II

42 Clasificación Clasificación / Instanciación
El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstracción: Clasificación / Instanciación Composición / Descomposición Agrupación / Individualización Especialización / Generalización Informatica II

43 Clases: Notación Gráfica
Cada clase se representa en un rectángulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase cuenta titular saldo depositar - Un atributo es semánticamente equivalente a una composición (composite aggreation). La sintaxis por defecto para los atributos es: visibilidad nombre [multiplicidad] : tipo = valor-inicial {propiedades} - tipo es una especificación dependiente del lenguaje de implementación - Para indicar que un atributo es constante se puede poner la propiedad frozen - Ejemplos usando multiplicidad: colores [3]: Color puntos [2..*]: Punto nombre [0..1]: String - Un atributo de clase (del ámbito de clase y no de objeto) se indica subrayándolo extraer transferir Informatica II

44 Clases: Notación Gráfica
Otros ejemplos: lista conjunto primero ultimo intersecar - Una operación es un servicio que una instancia de la clase puede realizar. La sintaxis por defecto es: visibilidad nombre (parámetros) : tipo-devuelto {propiedades} Una operación que no modifica el estado del objeto es especificada con la propiedad query. La propiedad abstract se usa para indicar que el método de la operación es implementado en una subclase. Una operación de clase (del ámbito de clase y no de objeto) puede indicarse subrayando dicha operación - Los parámetros se especifican usando la siguiente sintaxis: io nombre : tipo = valor_por_defecto donde io puede ser in, out o inout añadir unir quitar cardinalidad cardinalidad Informatica II

45 II. Breve Tour por UML Diagrama de Clases El Diagrama de Clases es el diagrama principal para el análisis y diseño Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia La definición de clase incluye definiciones para atributos y operaciones Informatica II

46 Diagrama de Clases El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones Informatica II

47 … Ejemplos (Generalización)
II. Breve Tour por UML … Ejemplos (Generalización) Trabajador { disjunta, completa } Directivo Administrativo Obrero Informatica II

48 … Ejemplos (Clase Asociación)
II. Breve Tour por UML … Ejemplos (Clase Asociación) empleador trabajadores Empresa Empleado * * 1..* 1..* Cargo superior nombre sueldo 0..1 0..1 subordinado 1..* 1..* Informatica II

49 Ejemplos (Clase y Visibilidad)
Alumno DNI : char[10] número_exp : int nombre : char[50] alta() poner_nota(asignatura : char , año : int, nota : float) matricular(cursos : asignatura, año : int) listar_expediente() Informatica II

50 … Ejemplos (Asociación)
dirige director Departamento Profesor 0..1 0..1 1 1 Informatica II

51 UML Necesidad modelado Casos de uso Diagramas de clase
Diagramas de secuencia Informatica II

52 Diagrama de Secuencia Muestra la secuencia de mensajes entre objetos durante un escenario concreto. Cada objeto viene dado por una barra vertical. Se llama línea de vida. El tiempo transcurre de arriba abajo. Informatica II

53 Diagrama de Secuencia Cada mensaje se representa mediante una flecha entre las líneas de vida. Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua. Cada mensaje se etiqueta con el nombre del mensaje y pueden incluirse los argumentos. Informatica II

54 Diagrama de Secuencia Los rectángulos en las líneas de vida indican el tiempo en el cual un método está activo. Informatica II

55 Diagrama de Secuencia Informatica II - 2002 :WInPréstamos :Socio
:Video :Préstamo : Encargado prestar(video, socio) verificar situación socio verificar situación video registrar préstamo Los Diagramas de Secuencia y de Colaboración son usados para describir gráficamente un caso de uso o un escenario Un Diagrama de Secuencia muestra los objetos de un escenario mediante líneas verticales y los mensajes entre objetos como flechas conectando objetos Los mensajes son dibujados cronológicamente desde arriba hacia abajo Los rectángulos en las líneas verticales representan los periodos de actividad de los objetos. entregar recibo Informatica II

56 Diagrama de Secuencia Condición Objeto Mensaje Autodelegación
Ventana de entrada de pedidos Un Pedido una Línea de pedido un artículo de inventario prepara( ) *[para cada línea de pedido] prepara( ) Condición hayExistencia:=revisa( ) Objeto Mensaje [hayExistencia] descuenta( ) necesitaReorden: =necesitaReordenar ( ) Los Diagramas de Secuencia y de Colaboración son usados para describir gráficamente un caso de uso o un escenario Un Diagrama de Secuencia muestra los objetos de un escenario mediante líneas verticales y los mensajes entre objetos como flechas conectando objetos Los mensajes son dibujados cronológicamente desde arriba hacia abajo Los rectángulos en las líneas verticales representan los periodos de actividad de los objetos. Autodelegación Informatica II

57 … Diagrama de Secuencia
Informatica II

58 Modelado de SI: Algunas Reflexiones
Modelar para la comprensión del sistema y/o para el mantenimiento y la documentación. Pragmatismo, los modelos deben ser útiles. Sencillez y Elegancia. Distintos nivel de abstracción, diferentes modelos. Seguimiento de transformaciones durante el proceso (Traceability). Informatica II

59 Modelado de SI: Algunas Reflexiones
Sincronización de modelos. Dificultades para la introducción de técnicas y herramientas de modelado. Informatica II

60 Resumen UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML-- Grady Booch Informatica II