Ingeniería de Software Tema: Conceptos Básicos de UML 2 Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Agenda Conceptos básicos a revisar Los 4 principios de modelamiento Propósito del Diagrama de Clases Propósito del Diagrama de Casos de Uso Modelo conceptual Diagramas de Paquetes Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones Asociación Objeto de una clase SE RELACIONA con un objeto de otra clase Objeto de una clase CONTIENE un objeto de otra clase Agregación agregación asociación Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Modelamiento de Software Un Modelo de Software es una Simplificación de la Realidad Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Modelamiento de Software Un Modelo (según Grady Booch): Provee el plano (Blueprint) del sistema a construir Puede representar un plan detallado o dar una vista de muy alto nivel Si es bueno, incluye los aspectos realmente importantes para cierto punto de vista. Estructurales (Estáticos) Destacan la estructura y la organización del sistema De Comportamiento (Dinámicos) Destacan los aspectos dinámicos del sistema. Tipos de Modelos: Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

4 Principios de modelamiento La Selección del Modelo Importa Los Modelos Pueden Tener Diferentes Niveles de Precisión Los Mejores Modelos Tienen la Relación Clara Con la Realidad Para Entender el Sistema se Necesitan Varios Modelos Complementarios Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Principio 1 de Modelamiento La Selección del Modelo Importa Los modelos bien elegidos reflejan los aspectos relevantes del sistema y permiten su implementación óptima Los modelos mal elegidos destacan los aspectos de poca relevancia y llevan hacia la implementación equivocada. Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Principio 2 de Modelamiento Los Modelos Tienen Diferentes Niveles de Precisión Dependiendo del próposito del sistema ¿Quién va a usar el modelo? Cliente, Usuario, Implementador, Testeador, etc. ¿Para qué se construye el modelo? Prototipo, base de datos, conceptual, etc. Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Principio 3 de Modelamiento Los Mejores Modelos Tienen la Relación Clara con la Realidad La idea principal de la orientación a objetos – acercarse a la realidad. Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Principio 4 de Modelamiento Para Entender el Sistema Se Necesitan Varios Modelos Complementarios Un sistema tiene varios aspectos importantes Estructura, escenarios típicos, interfaz usuaria, etc. No todos los sistemas necesitan todos los modelos Sistemas distribuidos   sistemas monólitos Alta concurrencia   un solo usuario Usan base de datos   los sistemas embedded Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Vista Conceptual Un conjunto de las abstracciones relacionadas con el dominio del problema Ayuda el ENTENDER el problema y no su resolución protege contiene ahorra posee usa Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Propósito del Diagrama de Clases Usados Para Demostrar la Estructura Estática de un Sistema Computacional o una Parte Relevante de Mundo Real Los Diagramas Más Frecuente y Ampliamente Usados, con Tres Perspectivas Posibles Conceptual – demuestra las entidades del mundo real con sus relaciones Especificación – demuestra la estructura del sistema o su parte, destacando las interfaces Implementación – el “blueprint” del código fuente Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Diagrama de Clases: Ejemplo Cliente Bebida Barmen Pedido Venta - valor: Doble + ImprimirBoleta() Bodega Jugo Natural Gaseosa 1 1..* realiza 0..* tiene almacena Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de Clases asociación Representa la relación genérica entre dos clases El significado de una asociación depende de la perspectiva del diagrama Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de Clases agregación, composición Representan una asociación “fuerte” entre dos clase No existe una separación estricta entre asociación y agregación o composición Asociación representa una relación en el sentido más general Agregación puede significar que una clase está compartida Composición indica un vínculo exclusivo y permanente Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de Clases herencia La clase heredera es una especialización de su súper clase Herencia Múltiple Una clase puede ser heredada de varias súper clases Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de Clases Persona Auto Compra - fecha: Date monto: Double Mario : Persona Renault : Auto Jorge : 1234 : Compra 2222 : Clase asociativa Es una clase creada de una asociación Enlace entre dos objetos corresponden al objeto asociado Se usa cuando la asociación no es suficiente para describir la relación Habitualmente se le agregarán atributos o aún métodos Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Diagrama de Clases: Ejemplo Cliente Bebida Barmen Pedido Venta - valor: Doble + ImprimirBoleta() Bodega Jugo Natural Gaseosa 1 1..* realiza 0..* tiene almacena asociación multiplicidad atributo operación herencia Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Propósito de Casos de Uso Usados Para Comunicarse con el Usuario Final y el Experto de Dominio Proporciona credibilidad en una etapa inicial del desarrollo del sistema Asegura una comprensión mutua de los requisitos Quién interactuará con el sistema y qué deberá hacer el sistema Qué interfaz deberá tener el sistema Que se hayan capturado todos los requerimientos Que los desarrolladores hayan entendido los requerimientos Usados Para Identificar Usados Para Verificar Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Diagrama de CU: Ejemplo Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Elementos de Diagrama de CU Un Actor representa cualquier entidad que interactúe con el sistema Un Caso de Uso es una secuencia de acciones que un sistema realiza, que produce un resultado observable y de valor para un Actor Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Actor Los Actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempeñar Un Actor puede intercambiar activamente la información con el sistema Un Actor puede ser un receptor pasivo de la información Un Actor puede representar a un humano, una máquina u otro sistema Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Caso de Uso Un caso de uso modela un diálogo entre el actor y el sistema, una interacción Un caso de uso es iniciado por un actor para invocar una cierta funcionalidad en el sistema Un caso de uso es un flujo de eventos completos y significativos Tomados al mismo tiempo, todos los casos de uso constituyen todas las formas posibles de ocupar el sistema Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Alcance del Sistema límite del sistema sistema mundo ¿Hasta Donde Llega el Sistema a Construir? Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de CU Entre un Actor y un Caso de Uso asociación incluye extiende herencia Entre Dos Casos de Uso Entre Dos Actores Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de CU Usuario Navegar Lista de Mensajes Realizar log in Sistema Web Pay Realizar el Pago asociación El Actor interactúa con el sistema mediante un diálogo El Actor típicamente inicia el diálogo (Actor Activo) A veces el caso de uso toma la primera acción (Actor Pasivo) Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de CU incluye El diálogo incluído es una parte obligatoria del diálogo incluyente y va a resultar ejecutado cada vez que este se ejecute Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de CU extiende El diálogo extendiente es una parte OPCIONAL del diálogo extendido y va a resultar ejecutado en CIERTAS EJECUCIONES del primer escenario Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de CU herencia (de casos de uso) Un Caso de Uso es especificación del otro Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Relaciones en Diagramas de CU herencia (de Actores) Un Actor es especificación del otro Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Diagrama de CU: Ejemplo incluye caso de uso actor extiende Límite Sistema de Pub Barman Vender Bebida Informar Bodega Registrar Venta Sistema de Bodega «extend» «include» Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Práctica: Modelo Conceptual Notación Usada Declaración del Problema Consultas Identificación de las Clases Especificación de las CRC Estructuración del Modelo de Clases Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Notación Usada Modelo CRC (Tarjetas de Responsabilidad-Colaborador) Método popular de análisis Identificar los conceptos, sus responsabilidades y las colaboraciones con otros conceptos Diagrama de Clases Elemento estándar de UML Identificar las clases y sus relaciones Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Modelo CRC Identificar los Conceptos Identificar las Responsabilidades ¿Qué “sabe” el concepto? (Datos, Atributos) ¿Qué “hace” el concepto? (Operaciones, Métodos) Identificar los Colaboradores Otros conceptos <Nombre del Concepto> Responsabilidad 1 Responsabilidad 2 ... Responsabilidad N Colaborador 1 Colaborador 2 Colaborador N Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Profesor Gerardo Cerda Neumann gcerda@ucinf.cl Diagrama de Clases Diagramas de Clases de UML Simplificado Clase - atributo1: atributo2: ...: atributoN: + método1() método2() ...() métodoN() : void Otra Clase Heredada Compuesta Una Clase más 1 +base 0..1 1..* 0..* Clase Composición Herencia Multiplicidad Navegabilidad Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Propósito de Diagrama de Paquetes Una de las preguntas más antiguas en desarrollo de software: “Como dividir un sistema en varios subsistemas?” Usados para simplificar el modelo agrupando sus elementos relacionados Aplicables en todos otros diagramas UML (caso de uso, clases, componentes) “Oficializados” desde el UML 2.0 Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Diagrama de Paquetes: Ejemplo Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Elementos de Diagrama de Paquetes Un Paquete representa un grupo de elementos (casos de uso, clases, componentes, otros paquetes) relacionados según algún criterio Una Interfaz representa la parte pública del paquete, visible y accesible desde afuera del mismo paquete Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Relaciones en Diagrama de Paquetes Entre Dos Paquetes Dependencia Anidación Especialización Entre un Paquete y una Interfaz Dependencia Realización Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Relaciones en Diagramas de Paquetes Dependencia Dependencia Por lo menos un elemento de un paquete depende de un elemento del otro (ejemplo: una clase de un paquete llama a una clase del otro) Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Relaciones en Diagramas de Paquetes Anidación Anidación Un paquete contiene el otro Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Relaciones en Diagramas de Paquetes Realización Realización Por lo menos un elemento del paquete realiza la interfaz La interfaz es la parte visible y accesible del paquete Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Relaciones en Diagramas de Paquetes Dependencia Dependencia Por lo menos un elemento de un paquete hace uso de la interfaz (es decir, un elemento del otro) Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Diagrama de Paquetes: Ejemplo Profesor Gerardo Cerda Neumann gcerda@ucinf.cl

Ingeniería de Software Tema: Conceptos Básicos de UML 2 Profesor Gerardo Cerda Neumann gcerda@ucinf.cl