1 UML Necesidad modelado Diagramas de clase Diagramas de secuenciaCasos de uso Informatica II
2 UML Necesidad modelado Use cases Diagramas de claseDiagramas de secuencia Informatica II
3 Objetivos al desarrollar softwareSatisfacer 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 objetivosRealizar 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 estructuralesModelos 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 casaExtraí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 SINotació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ónMúltiples Sistemas Componentes Reutilizados Informatica II
12 MV para definir la Arquitectura del SWInterfaz 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 softwareAná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 OORumbaugh 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 seleccionadosDiagramas 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 claseDiagramas 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 usuariosOtros 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 ClienteSupervisor 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 UsoEjemplo: Caso de Uso A Actor A Caso de Uso B Actor B Informatica II
27 … Casos de Uso Identificación de casos de usosEventos ante los cuales se debe reaccionar Actores que intervienen Informatica II
28 … Casos de Uso Representación de escenarios alternativosInformatica II
29 … Ejemplos Venta Normal Ventas Venta en Rebajas Venta en OfertasVendedor 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: RelacionesUML 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: RelacionesIII. 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 <
34 … Casos de Uso: RelacionesExtensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino <
35 … Casos de Uso: RelacionesEjemplo: Identificación <
36 Casos de Uso: ConstrucciónUn 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ónPreguntas 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ónLa 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ónobjetivo 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 claseDiagramas de secuencia Informatica II
41 Implementación Clases: abstracciones del mundo real. Perspectiva más usada Informatica II
42 Clasificación Clasificación / InstanciaciónEl 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áficaCada 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áficaOtros 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 claseDiagramas 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ónVentana 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 SecuenciaInformatica II
58 Modelado de SI: Algunas ReflexionesModelar 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 ReflexionesSincronizació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