Metodología UMLMiguel Almeyda MVP Client App Dev CEO Integration and Development Solutions Agenda Introducción al UML Los Casos de Uso Los Diagramas de Interacción Fundamentos en la Tecnología Orientada a Objetos Principios del Software Orientado a Objetos: Diagramas de Clases Introducción al UML UML combina notaciones provenientes desde: – – – – Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows) .¿Qué es UML? UML = Unified Modeling Language Un lenguaje de propósito general para el modelado orientado a objetos. Historia de UML Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. Se presentó en el OOPSLA’95 El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software: Herramienta CASE Rational Rose. Historia de UML 2001 2000 1999 1998 Nov ‘97 UML aprobado por el OMG UML 2.0 UML 1.4 UML 1.3 Revisiones menores UML 1.2 Participantes en UML 1.0 Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson) Digital Equipment Hewlett-Packard i-Logix (David Harel) IBM ICON Computing (Desmond D’Souza) Intellicorp and James Martin & co. (James Odell) MCI Systemhouse Microsoft ObjecTime Oracle Platinium Technology Sterling Software Taskon Texas Instruments Unisys Perspectivas para el UML • UML es el lenguaje de modelización de objetos estándar. predominante para los próximos años • Razones: Participación de metodólogos influyentes Participación de importantes empresas Aceptación del OMG como notación estándar Herramientas que provee la notación UML . Perspectivas para el UML • El objetivo de UML es describir cualquier tipo de sistema en términos de diagramas orientados a objetos. • Algunas categorías de Sistemas que puede diagramar el UML: • • • • • • Sistemas de Información Sistemas de Tiempo Real Sistemas Embebidos Sistemas Distribuidos Software de Sistemas Sistemas de Negocios . cada una mostrando un aspecto particular del sistema. puede ser construida como una imagen completa del sistema.Diagramas del UML • La finalidad de los diagramas es presentar diversas perspectivas de un sistema a las cuales se les conoce como modelo. • Muestran diferentes aspectos de los sistemas que son modelados. • Definiendo una serie de vistas. • Las vistas también enlazan el lenguaje de modelaje al método o proceso escogido para el desarrollo. . Tipos de Diagramas en UML • Diagrama de Casos de Uso • Diagrama de Clase (incluyendo Diagrama de Objetos) • Diagramas de Comportamiento – Diagrama de Estados – Diagrama de Actividad – Diagramas de Interacción • Diagrama de Secuencia • Diagrama de Colaboración • Diagramas de implementación – Diagrama de Componentes – Diagrama de Despliegue . desde una perspectiva concreta” Use Case Use Case Diagrams de Diagramas Diagrams Uso Casos de State State Diagrams de Diagramas Diagrams Clases Use Case Use Case Diagrams de Diagramas Diagrams Secuencia State State Diagrams de Diagramas Diagrams Objetos Scenario Scenario Diagrams de Diagramas Diagrams Colaboración Scenario Scenario Diagrams de Diagramas Diagrams Estados Modelo State State Diagrams de Diagramas Diagrams Componentes Component Component Diagrams Diagramas de Diagrams Diagramas de Actividad Distribución .Modelado con UML “Un modelo es una descripción completa de un sistema. Relación entre diagramas Diagramas de Distribución Diagramas de Clases Diagramas de Componentes Casos de Uso Diagramas de Secuencia Diagramas de Colaboración Diagramas de Estados C Ó D I G O Diagramas de Actividad . ¿Por qué es necesario el UML? • Conforme aumenta la complejidad en los sistemas informaticos será mas necesario organizar el proceso de diseño • De tal forma que los analistas. los proyectos ya desarrollados o en desarrollo que han sido bien diseñado. • Hay otro aspecto de la vida moderna que demanda un diseño sólido. clientes y desarrolladores y otras personas lo comprendan. si el diseño es sólido los cambios se implementarán sin problemas. las adquisiciones corporativas. y el UML proporciona tal organización. facilitará la conversión. cuando una empresa adquiere a otra. . Los Casos de Uso . . • El comportamiento del sistema es capturado en los casos de uso mediante un proceso de recopilación de requerimientos del sistema.Definir el Comportamiento del Sistema • El comportamiento de un sistema es cómo un sistema actúa y reacciona • La actividad exterior visible y “testeable” de un sistema. . • La forma en que los usuarios utilicen un sistema le da la pauta para lo que diseñará y creará.Caso de Uso y los Usuarios • Este tipo de análisis es particularmente crucial para la fase de análisis del desarrollo de un sistema. • El caso de usos es una estructura que ayuda a los analistas a trabajar con los usuarios para determinar la forma en que se usará un sistema. • Con una colección de casos de uso se puede hacer el bosquejo de un sistema en términos de lo que los usuarios intenten hacer con él. Abstraerse • Imagínese al caso de uso como una colección de situaciones respecto al uso de un sistema. . otro sistema. • A las entidades que inician secuencias se les conoce como actores. una parte del hardware o por el paso del tiempo. • El resultado de la secuencia debe ser algo utilizable ya sea por el actor que la inició o por otro actor. • Cada secuencia se inicia por una persona. • Cada escenario describe una secuencia de eventos. • Ellos describen la conducta de un sistema desde el punto de vista del usuario por que generan acciones y reacciones. .Representación • Los casos de uso fueron inventadas por Ivar Jacobson. • Un Caso de Uso es representado por una elipse y describe una situación de uso del sistema interactuando con actores. El Propósito de los Casos de Uso El propósito primario del modelo caso de uso es comunicar las funciones y el comportamiento del sistema al cliente o al usuario final . de un sistema. • Puesto que el desarrollo tradicional de los sistemas era.Beneficios del Modelado con Casos de Uso • El caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen. con muy poca información para los usuarios. algo así como una ciencia oculta. . con frecuencia. desde sus propios puntos de vista. a aquellos que osaban preguntar se les daba información muy poco explícita o ciertamente confusa respecto a lo que utilizarían. • No siempre es fácil para los usuarios explicar como pretenden utilizar un sistema. • Es usado para identificar: – Quién interactuará con el sistema y qué deberá hacer el sistema – Qué interfaz deberá tener el sistema • Es usado para verificar que: – Se capturan todos los requisitos – Que los desarrolladores hayan entendido los requisitos . • Proporciona credibilidad en una etapa inicial del desarrollo del sistema. • Asegura una comprensión mutua de los requisitos.Los Casos de Uso son: • Usados para comunicarse con el usuario final y el experto del dominio. alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo.Los Actores • Un actor es un agente. Actor 23 . • Un actor puede ser un recipiente pasivo de la información . una máquina u otro sistema.Los Actores • 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 representar a un humano. . .Los Actores y los Casos de Uso • El modelo de los Casos de Uso comprende los actores. • El conjunto de funcionalidades de un sistema se determina examinando las necesidades funcionales de cada actor. expresadas en forma de interacciones. el sistema y los propios casos de uso. Identificando Actores • Los actores se determinan observando: – Usuarios directos del sistema – Responsables del uso o mantenimiento del sistema – Otros sistemas que interactúan con el sistema en cuestión . soportará y mantendrá el sistema? • ¿El sistema usa un recurso externo? • ¿Alguna persona juega varios roles diferentes? • ¿El sistema interactúa con otro sistema? .Preguntas usadas para ayudar a identificar actores • ¿Quién usará la funcionalidad principal del sistema? • ¿Quién esta interesado en cierto requerimiento? • ¿Donde en la organización será usado el sistema? • ¿Quién se beneficiará con el uso del sistema? • ¿Quién administrará. .Tip: Actores • Los actores se determinan observando: – Usuarios directos del sistema – Responsables del uso o mantenimiento del sistema – Otros sistemas que interactúan con el sistema en cuestión • Un actor puede: – Solamente introducir información al sistema – Solamente recibir información del sistema – Introducir y recibir información hacia y del sistema. • Otros sistemas: sistemas con los que el sistema interactúa. .Categorías de Actores • Principales: personas que usan el sistema • Secundarios: personas que mantienen o administran el sistema material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados. procede a describirlos. tras localizar los actores. Documentación de los Actores • Una breve descripción de cada actor debe ser añadida al modelo. . • La descripción debería identificar al rol que el actor juega en su interacción con el sistema. • Por ejemplo si se identifico un actor que se llama Cliente. • Una descripción de tal actor sería: – Un cliente es aquella persona que adquiere un producto en la compañía. Los Casos de Uso Caso de Uso 31 . • Tomados al mismo tiempo. . • Un caso de uso es un flujo de eventos completos y significativos. • Un caso de uso es iniciado por un actor para invocar una cierta funcionalidad en el sistema. todos los casos de uso constituyen todas las formas posibles de ocupar el sistema.Los Casos de Uso • Un caso de uso modela un diálogo entre los actores y el sistema. eliminará o leerá esta información? • ¿Necesitará el actor informar al sistema sobre cambios externos e imprevistos? 33 . eliminará o leerá la información en el sistema? • ¿Cuál caso de uso creará. guardará. cambiará. guardará.Encontrando Casos de Uso: Preguntas Útiles • ¿Cuáles son las tareas de este actor? • ¿El actor. creará. cambiará. Encontrando Casos de Uso: Preguntas Útiles • ¿Es necesario que el actor esté informado sobre ciertas ocurrencias en el sistema? • ¿Le proporciona una correcta secuencia el sistema a las tareas? • ¿Cuáles casos de uso le darán soporte y mantenimiento al sistema? • ¿Pueden todos los requerimientos funcionales ser realizados por los casos de uso? 34 . • Un actor es un agente. 35 . alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo.Diagramas de Caso de Uso • Cada Caso de Uso puede estar definido por: – Texto que lo describe – Secuencia de pasos ejecutados dentro del escenario – Condiciones pre – post para que el escenario comience o termine – Mezclando las anteriores • Un Caso de Uso es representado por una elipse y describe una situación de uso del sistema interactuando con actores. El propósito del caso de uso en unas pocas líneas Flujo de eventos detallados Descripción del flujo de eventos primario y alternativos que ocurren cuando el caso de uso es iniciado • La documentación debe leerse como un diálogo entre el actor y el caso de uso • Ambos documentos están escritos en términos que el cliente entenderá. 36 .Documentación de Casos de Uso • • • • • Los casos de uso están documentados en: Una breve descripción. ¿Quién lee la documentación de los Casos de Uso? • Clientes: aprueban lo que debe hacer el sistema • Usuarios: obtienen comprensión del sistema • Desarrolladores del Sistema: documentan el comportamiento del sistema • Revisores: examinan el flujo de eventos • Analistas del Sistema (Diseñadores): proveen la base para un análisis y diseño • “Probador” del Sistema: usado como base para casos de prueba • Líder de Proyecto: provee entradas para el planeamiento de proyectos • Escritor Técnico: base para escribir la guía del usuario 37 . Diagramas de Interacción . Definición • Modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento, captando el comportamiento de un Caso de Uso. ¿Qué muestran? • El diagrama se compone de distintos objetos y mensajes que actúan en un proceso de un Caso de Uso. • Muestra cierto número de ejemplos de objetos y mensajes que se pasan entre estos objetos dentro del caso de uso. Dos tipos de diagramas • Existen dos tipos de diagramas de interacción: – Diagramas de secuencia – Diagramas de colaboración • Cada uno entrega un punto de vista distinto de la misma interacción – Los diagramas de secuencia son ordenados en el tiempo – Los diagramas de colaboración pueden incluir flujo de datos le permite expandir su campo de visión y le muestra la forma en que un objeto interacciona con otros. incluirá una importante dimensión: el tiempo. • En este campo de visión expandido.Diagramas de Secuencia • El UML. . • Al momento de crear un sistema tendrá que especificar la secuencia. . y para ello.Diagramas de Secuencia • La idea primordial es que las interacciones entre los objetos se realizan en una secuencia establecida y que la secuencia se toma su tiempo en ir del principio a fin. utilizará al diagrama correspondiente. • Los Diagramas de Secuencia están bien adaptados para representar interacciones .Representación • El diagrama de secuencias consta de objetos que se representan del modo usual: rectángulos con nombre (subrayado). • Un diagrama de secuencia muestra las interacciones de objetos arregladas en una secuencia de tiempo. mensajes representados por líneas continuas con una punta de flecha y el tiempo representado como una progresión vertical. 45 . Representación • 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. • El diagrama muestra: – Los objetos participando en la interacción – La secuencia de mensajes intercambiados . – La longitud del rectángulo se interpreta como la duración de la activación. – La figura muestra un objeto. línea de vida y su activación.Objetos • Un diagrama de secuencia contiene: – Objetos con sus “líneas de vida” – Mensajes intercambiados entre objetos en una secuencia ordenada. . • Un objeto puede enviarse un mensaje a sí mismo (es decir. asincrónico. . desde su línea de vida hacia su propia línea de vida). • Un mensaje puede ser simple. • Un mensaje simple es la transferencia del control de un objeto a otro. sincrónico.Mensajes • Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto a la de otro. esperará la respuesta a tal mensaje antes de continuar con su trabajo. . no esperará una respuesta antes de continuar. • Si un objeto envía un mensaje asincrónico.Tipos de Mensajes • Un mensaje simple es la transferencia del control de un objeto a otro. • Si un objeto envía un mensaje sincrónico. los símbolos del mensaje varían: – La punta de flecha de un mensaje simple está formada por dos líneas – La punta de la flecha de un mensaje sincrónico está rellena y la de un asincrónico tiene una sola línea.Tipos de Mensajes • En el diagrama de secuencias. . . – Un mensaje que esté más cerca de la parte superior ocurrirá antes que uno que esté cerca de la parte inferior. – El tiempo se inicia en la parte superior y avanza hacia la parte inferior.El tiempo • El diagrama representa al tiempo en dirección vertical. el diagrama de secuencias tiene dos dimensiones: – La dimensión horizontal es la disposición de los objetos. • Con ello. y la dimensión vertical muestra el paso del tiempo. Una Ventana de Entrada Un Pedido Una Línea de Pedido Un Artículo de Inventario Prepara() *{por cada L.} Prepara() Revisar() [existe] Descuenta() Actualizar() [reordenar] Nuevo() Un Artículo de Reorden .P. 53 . 54 . • Cuando teclea en un procesador de texto. en ocasiones no ve aparecer en la pantalla el carácter correspondiente a la tecla que haya oprimido sino hasta después de haber oprimido algunas mas.Asincrónico • La figura representa el diagrama de secuencias de la GUI. • Como ve. . particularmente en una máquina lenta. • Al trabajar con algunas aplicaciones de Windows. tal vez haya sentido algunos de los efectos de la comunicación asincrónica. los mensajes son asincrónicos: ninguno de los componentes aguarda nada antes de continuar. 56 . Fundamentos en la Tecnología Orientada a Objetos . concretos como abstractos • Objeto – Cumple un ROL dentro de los sistemas de la organización • Objeto – Conoce como hacer su trabajo y recuerda su propia información .Objetos • Objeto – Todo lo que nos rodea. ¿Qué es un Objeto? • Informalmente. física. un objeto representa una entidad. ENTIDAD FÍSICA ENTIDAD CONCEPTUAL ENTIDAD PROGRAMA . conceptual o programa. .Concepto de Objeto • El termino Objeto representa una “unidad de software” con las siguientes características: – Identidad – Estado (Información) – Comportamiento • Esta unidad de software es la representación computacional de una entidad “Preexistente o No” de la realidad que deseamos modelar. además de las conexiones que deben tener con otros objetos .Un Objeto tiene Estado • El estado de un objeto es una de las posibles condiciones para que el objeto pueda existir • El estado normalmente cambia en el transcurso del tiempo • El estado de un objeto es implementado por un conjunto de propiedades (llamadas atributos). con los valores de las propiedades. Un Objeto tiene Estado Profesora Clark Nombre: Nº Empleado: Fecha de Contrato: Estado: Joyce Clark 567138 21 de marzo 1987 Adjunto . Un Objeto tiene Comportamiento • El comportamiento de un objeto determina cómo éste actúa y reacciona frente a las peticiones de otros objetos • El comportamiento de un objeto es modelado por un conjunto de mensajes a los que puede responder (las operaciones que el objeto puede realizar) . Un Objeto tiene Comportamiento Asignación del profesor Clark Registro del Sistema Curso Algebra 101 . incluso si su estado es idéntico al de otro objeto Profesor “J Clark” enseña Algebra Profesor “J Clark” enseña Algebra Profesor “J Clark” enseña Algebra .Un Objeto tiene Identidad • Cada objeto tiene una identidad única. – Las responsabilidades de un objeto se “realizan” por medio de sus “métodos”. las hacemos al momento del diseño OO. – Esa asignación de tareas = responsabilidades.Objeto – Comportamiento • Comportamiento (Responsabilidades) – La totalidad de las tareas que el sistema debe realizar son llevadas a cabo por una enorme cantidad de objetos cooperantes. • (método = código ejecutable) . – Es asignado en forma automática por el mismo sistema .Objeto .Identidad • Identidad (identificador interno no accesible al programador/usuario) – Único mientras el objeto este activo = “viva” para el resto del sistema. representada en forma de: otros objetos. .. o bien..Objeto – Estado • Estado (Información que el objeto conoce) • Un objeto contiene una fracción de la información total del sistema.. .. “tipos básicos o complejos” del lenguaje de implementación. Mensaje • Objeto . • Dicho mensaje se resuelve por la ejecución de un método del objeto receptor.Objeto .Mensaje . EMISOR >>> mensaje > RECEPTOR ENCAPSULAMIENTO Comunicación exitosa = Conocimiento previo del lenguaje del receptor .Objeto • La única forma de alterar el estado interno de un objeto es por medio del envío de un mensaje. Principios del Software Orientado a Objetos: Diagramas de Clases . para su modelamiento en mundo real se basa en los siguientes principios: Abstracción Encapsulamiento Principio de Información oculta Principio cliente-servidor Jerarquías .Principios del Software Orientado a Objetos • La orientación a objetos. Abstracción • Es la representación de las características esenciales de un objeto. • Definir una abstracción significa describir una entidad del mundo real. representando sus características y comportamiento. así como de su comportamiento. no importando lo compleja que pueda ser. . .Encapsulamiento • Mecanismo que permite unir. todas las propiedades (características) y funcionalidades (comportamiento) de una entidad. en una única abstracción. consiste en un “nombre” . definen una jerarquía de inclusión – Mensaje. encerrándola en el objeto. a los que nombraremos “atributos” del objeto contenedor – Atributos. • Un Objeto se compone de – Otros objetos.Encapsulamiento • Encapsulamiento = Información + Operaciones • Trata la complejidad inherente al mundo real. Principio de la Información Oculta • Consiste en la capacidad de proveer la posibilidad de ocultar los detalles de la representación interna de un objeto y exponer solo aquellos detalles necesarios para el resto del sistema. . • Los otros objetos dependerán de un comportamiento especifico y no de la implementación interna de un objeto. Principio de la Información Oculta 76 . son Clases u Objetos. . • En el enfoque Orientado a Objetos ambos.Principio Cliente – Servidor • Se basa en la interacción de entre dos Entidades: el Cliente y el Servidor. • Un Cliente hace solicitudes al Servidor para que éste realice servicios. Cliente y Servidor. • De si misma. • De Objetos de otras Clases – (Usa exclusivamente sus métodos).¿De quién es Cliente una Clase? • De sus Ancestros – (Usa exclusivamente sus métodos). . – Generalmente conocida como Herencia.Jerarquías • Una jerarquía es la que nos permite ordenar y relacionar las abstracciones o clases. . la cual define una relación entre clases en donde una comparte la estructura y comportamiento de una o mas clases. • Generalización/Especialización. comportamiento similar (operaciones). la misma manera de relacionarse entre objetos (asociaciones y agregados) y una semántica en común.Clases • Una clase es una descripción de un grupo de objetos con propiedades en común (atributos). . Ejemplo de una Clase Clase Curso Estructura •Nombre •Ubicación •Días ofrecidos •Horas Créditos •Horario de inicio •Horario de término a + b = 10 Comportamiento Agregar un alumno Borrar un alumno Dar una lista del curso Determinar si está lleno . Clases de Objetos • ¿Cuántas clases de objetos ves? 82 . Encontrando Clases • Una clase debe capturar una y solo una abstracción clave • Mala abstracción: La clase estudiante que conoce la información del estudiante y el programa del actual semestre del estudiante • Buena abstracción: Clases separadas para estudiantes y programas del estudiante Algebra 101 Historia Arte Química Español 101 . • La dificultad al nombrar la clase revela una pobre definición de la abstracción. • Los nombres deben provenir directamente del vocabulario del dominio.Nombramiento de Clases • El nombre de la clase debe ser el sustantivo singular que mejor caracterice la abstracción. . SistemaDePago 85 .Guía de Estilo en el nombramiento de Clases • Una guía de estilo debe dictar convenciones para el nombramiento de clases • Ejemplo de guía de estilo: – Las clases son nombradas usando sustantivos singulares – Los nombres de las clases comienzan con letra mayúscula – No se usa el subrayado • Los nombres compuestos por múltiples palabras se ponen juntos y la primera letra de cada palabra se escribe con mayúscula – Ejemplo: Estudiante. Profesor. debe hacerse un informe descriptivo conciso – Concentrarse en el propósito de la clase. no en su implementación • El nombre y la descripción de la clase sirven como base para un modelo de diccionario Fijarse en los “QUE” e ignorar los “COMO” .Definiendo la Semántica de las Clases • Después de nombrar las clases. Muestra de las Entradas de un Modelo de Diccionario • Nombre: InformaciónDelEstudiante – Definición de Trabajo: Información de una persona registrada para asistir a clases en la universidad • Nombre: Curso – Definición de Trabajo: Una clase ofrecida por la universidad Mientras más se descubre del problema. se refina la definición de la clase y se agregan nuevas clases al modelo de diccionario . La Relación entre Clases y Objetos • Una clase es una definición abstracta de un objeto – Define la estructura y el comportamiento de cada objeto en la clase – Sirve como modelo para la creación de objetos • Los objetos pueden ser agrupados en clases Profesor Objetos Profesor Smith Profesor Jones Profesor Mellon Clase . cada uno a su conveniencia. deberíamos administrar un diccionario demasiado extenso. • Si cada uno posee un lenguaje distinto para comunicarse. • Hay que reducir el lenguaje: objetos parecidos tienen que responder a los mismos mensajes. • Es la cualidad que poseen los objetos de “distintas especies” de “implementar” un mismo “mensaje”. .Objetos: Polimorfismo • Un sistema típico construido con “Objetos” puede llegar a estar constituido por una gran cantidad de ellos . la subclase hereda desde más de una superclase • La herencia es una relación “es un” o “tipo de” 90 .Herencia • La herencia define una relación entre clases donde una clase comparte la estructura y/o comportamiento con una o más clases • La herencia define una jerarquía de abstracciones en que una subclase herede desde una o más superclases – Con la herencia unitaria. la subclase hereda desde una única superclase – Con la herencia múltiple. Dibujando una Herencia Jerárquica RegistroInformaciónUsuario Superclase Relación de Herencia InformaciónEstudiante Subclase . ¿Qué es heredado? • Una clase hereda de sus padres: – Atributos – Operaciones – Relaciones • Una subclase puede: – Agregar atributos. operaciones y relaciones adicionales – Redefinir las operaciones heredadas (¡tenga cuidado!) La herencia apalanca las similaridades entre las clases . Heredando atributos • Los atributos se definen en el nivel más alto en la jerarquía de herencia en la que son aplicados • Las subclases de una clase heredan todos los atributos • Cada subclase puede añadir atributos adicionales VehículoTerrestre Peso númeroLicencia Un camión tiene tres atributos: númeroLicencia peso tonelaje Auto Camión tonelaje . • Las subclases heredan todas las operaciones de una clase • Cada subclase puede aumentar o redefinir las operaciones heredadas VehículoTerrestre peso númeroLicencia registrar( ) Un camión tiene tres atributos: númeroLicencia peso tonelaje y dos operaciones: registrar() obtenerImpuestos() Auto Camión tonelaje obtenerImpuestos( ) .Heredando Operaciones • Las operaciones son definidas en el más alto nivel en la jerarquía de herencia en que son aplicables. Herencia • Generalización / Especialización • Agregación • Asociación . .Heredando Relaciones • Las relaciones también son heredados y deben ser definidas en el más alto nivel de la jerarquía de herencia en la cual son aplicables • Las subclases de una clase heredan todas las relaciones • Cada subclase puede participar en relaciones adicionales VehículoTerrestre peso númeroLicencia 0.* registrar( ) dueño 1 Persona Un auto es relacionado con un propietario Un camión es relacionado con un propietario Un camión también tiene un trailer Auto Trailer Camión tonelaje obtenerImpuestos( ) . Herencia vs Agregación Herencia Palabra clave “es un” Agregación Palabra clave “tiene un” Un objeto Relaciona objetos de distintas clases Representado por una flecha Representado por un diamante . Windows y ScrollBar Window Scrollbar WindowWithScrollbar Un WindowWithScrollbar “tiene un” Window Un WindowWithScrollbar “tiene un” Scrollbar ¿Qué relación debería ser usada? . Windows y ScrollBar Window Window Scrollbar WindowWithScrollbar 1 1 Scrollbar WindowWithScrollbar Un WindowWithScrollbar “es un” Window Un WindowWithScrollbar “tiene un” Scrollbar .