Usar las palabras claves “es un” y “tiene un” para encontrar la relación correcta Herencia vs Agregación Herencia y agregación a menudo se confunden herencia representa una relación “es-un” o “tipo-de” Agregación representa una relación “tiene-un” Ejemplos: Vendedor es un empleado; Una orden tiene un Ítem
(Gp:) VehiculoMotor (Gp:) Tractomula (Gp:) Carro (Gp:) Bus (Gp:) UtilidadVehiculo
Herencia múltiple En sistemas orientados a objetos a una clase se le permite heredar de más de una superclase Esta clase de herencia se conoce como herencia múltiple Ejemplo, UtilidadVehiculo hereda de las clases Tractomula y Carro
Problemas con herencia múltiple Hay varios problemas con la herencia múltiple, entre otros: Las subclases pueden heredar el mismo atributo de dos superclases diferentes Las subclases pueden heredar la misma operación de dos superclases diferentes La mayoría de los lenguajes orientados a objetos no soportan bien la herencia múltiple PowerBuilder y Java manejan herencia simple Trabajo adicional: Delegar ciertos atributos u operaciones en clases asociadas, usar agregación, o usar interfases en Java (se ven más adelante)
Interfase Una interfase es un conjunto de operaciones usadas para especificar el comportamiento externo de una clase, objeto u otra entidad En el caso de una clase u objeto, la interfase incluye la firma de las operaciones La interfase es un concepto UML que también está en Java No suportado en PowerBuilder Se puede ver como un “contrato” para un conjunto de clases
Uso de interfases Una interfase es similar a una clase abstracta, tiene atributos y operaciones como una clase, pero las operaciones son virtuales, no hay implementación de las operaciones Para crear una interfase: En la paleta, dar clic en la herramienta “Interface” o Seleccionar “Mode Interfaces” del menú principal para definir interfase (continúa …)
Uso de interfases Para vincular una clase a una interfase, asociar la interfase con la clase que “realiza” la interfase Para establecer este vínculo, en la paleta dar clic en “Realization Drawing”, y dibujar la realización de la clase a la interfase
Propiedades de “Interface” Name Code Comment Stereotype Visibility Generate Inner to
Propiedades de “Realization” Name Code Comment Interface clase Stereotype
Implementación de interfases Las interfases son como entidades de clases que tienen operaciones (generalmente abstractas) y atributos “To Be Implemented” es una facilidad que muestra qué operaciones de la interfase que su clase implementa se tienen que implementar Al hacer clic en “Implement”, copia la firma de la operación a su clase para implementación
Uso de interfases Evita herencia múltiple Las interfases ayudan a evitar la herencia múltiple teniendo una clase que soporta múltiples interfases Forza polimorfismo Las interfases ayudan a usar polimorfismo forzando a las clases a soportar todos los atributos y operaciones de una interfases Asegura un método consistente de nombre y llamado a través de múltiples clases
UML y Java soportan “final clases” Clases que no se pueden heredar Esto ayuda a asegurar que las clases no van a ser mal utilizadas por otros desarrolladores Ejemplos: Clases para seguridad Clases con formas de trabajo Final
Paquete (package) Paquete es un mecanismo de propósito general para organizar elementos en grupos Típicamente un modelo orientado a objetos se organiza en paquetes Se puede pensar que un modelo completo es un paquete de alto nivel que contiene cualquier otro paquete dentro de él Se usan paquetes para focalizar la funcionalidad en el sistema Cada paquete tienen al menos un diagrama Puede tener más de un diagrama
Paquetes en PowerDesigner <> Mi sistema
Paquetes El concepto de paquetes en PowerDesigner corresponde al concepto de paquetes de Java, es decir, un conjunto de grupos de clases que ejecutan funciones relacionadas Ejemplos: El paquete AWT, parte del API, incluye clases para crear un sistema gráfico de ventanas El paquete IO, usado por el sistema de E/S, streams, persistencia, y archivos Se pueden usar paquetes para referirse a agrupamientos tanto físicos como lógicos de los elementos de un modelo Se usan para particionar o para desarrollar
Paquetes El uso de paquetes ayuda a garantizar la jerarquía del sistema Un paquete puede contener otros paquetes Se pueden anidar paquetes para formar una jerarquía Esta capacidad de anidamiento ayuda a agrupar las clases, tal como una jerarquía de directorios puede ayudar a organizar los archivos Cuando se genera código Java, un paquete se genera como un directorio en el sistema de archivos de destino
Jerarquía de paquetes En PowerDesigner, los paquetes se muestran en el navegador como niveles separados
Propiedades de los paquetes Name Code Comment Stereotype Namespace Default diagram
Estereotipos de paquetes Estereotipos comunes de paquetes: Facade Framework Metamodel Model Stub Subsystem System SystemModel TopLevel
Espacio de nombres Un espacio de nombres define el alcance en el cual un nombre y el código de un objeto de cualquier tipo dado debe ser único Entonces, el nombre de un objeto de un modelo se puede forzar a que sea único a nivel de un modelo, paquete o subpaquete En UML y Java,por default, los nombres de las clases deben ser únicos a nivel de paquete Java resuelve esto en el momento de ejecución utilizando la variable CLASSPATH PowerBuilder resuelve esto en el momento de ejecución utilizando la lista de la librería En un modelo orientado a objetos, el paquete es el valor por omisión para el espacio de nombres
Dependencia de paquetes Un paquete es un concepto de desarrollo de software Uno de los objetivos principales es minimizar la dependencia de paquetes Ejemplo: Mi Paquete1 depende de Mi Paquete2, significa que uno o más elementos en el Paquete1 dependen de uno o más elementos en el Paquete2 Un cambio en un Paquete puede requerir de uno o más cambios en los elementos fuente del paquete dependiente
Relaciones de Paquetes El único tipo de relación entre paquetes es la relación de dependencia Si una clase en un paquete se refiere a una clase en otro paquete, se debe añadir una dependencia de relación a nivel de paquete Evaluar clases y diagramas de clases para determinar relaciones entre paquetes
Dependencia de paquetes – Implicaciones Ejemplo: Siempre que se haga un cambio en “Service package”, “Client package” se debe volver a compilar y a probar “Client package” no se puede reutilizar independientemente porque él depende de “Service package”
Interfase pública de un paquete Cada clase en un paquete tiene un parámetro de visibilidad que se puede colocar en público, paquete, privado, o protegido Solamente las clases públicas pueden ser utilizadas por clases en otros paquetes Evaluar las partes públicas y privadas de un paquete No todas las clases en un paquete deben hacer parte de la interfase pública del paquete
Evitar dependencias circulares Una jerarquía de paquetes debe ser asimétrica Tratar de evitar el siguiente escenario: El paquete A usa el Paquete B y el Paquete B usa el Paquete A La dependencia circular entre los paquetes A y B es un indicativo para tratarlos como un único paquete Evitar este tipo de círculo entre más de dos paquetes Ejemplo: El paquete A usa el Paquete B, el Paquete B usa el Paquete C y el Paquete C usa el Paquete A Estas dependencias circulares se deben romper reestructurando uno o más paquetes
Reestructuración de paquetes Se debe pensar en la reestructuración de paquetes en un modelo si: Hay un acoplamiento fuerte entre los paquetes, lo que significa que los paquetes se deben combinar Hay dependencia en doble vía entre los paquetes, lo que significa que las clases se deben reorganizar La interfase de un paquete debe encapsular su implementación en una interfase pública tal como lo hace una clase Evaluar las consideraciones de reutilización Para que sea reutilizable, un paquete debe tener pocas dependencias Ejemplo: mirar los paquetes de Java
Reglas del negocio Una “Regla del negocio” es algo que se debe cumplir Ejemplo de Reglas de negocio: Las leyes gubernamentales Requerimientos del cliente Guía de cumplimiento interno Las reglas del negocio a menudo comienzan como simples observaciones Ejemplo: “Los clientes llaman por los número gratis para colocar sus pedidos” Durante el diseño hay que desarrollar esas observaciones en expresiones más detalladas
Reglas del negocio Ejemplos: Lo que puede comprar un cliente de acuerdo a la línea de crédito Información que debe proporcionar un cliente cuando hace un pedido Las reglas del negocio complementan los modelos gráficos con información que no se puede representar fácilmente en forma gráfica Ejemplos: La regla “un empleado pertenece a uno y solo un departamento”, indica el tipo de relación entre un empleado y un departamento Fórmulas algebraicas, restricciones, reglas de validación
Reglas del negocio – Propiedades Name Code Comment Type Expression Notes
Tipos de reglas del negocio Restricciones – Condición a chequear sobre un valor Definición – características o propiedades de un objeto en el sistema Hechos – cosas ciertas o existentes en el sistema Fórmulas – calculos empleados en el sistema Requerimientos – especificación funcional en el sistema Validación – restricción sobre un valor en el sistema
Domains Classes Interfaces Attributes Identifiers Operations Associations Generalizations Realizations Dependencies Use Cases Actors Objects Messages Reglas del negocio y modelado con objetos Las reglas del negocio se pueden ligar a los siguientes objetos en un modelo orientado a objetos:
Dominio Un dominio es el conjunto de valores válidos para un data ítem En el caso de PowerDesigner, existen con el mismo significado en los tres modelo OOM, CDM y PDM Los dominios se usan para forzar manejo consistente de datos en el sistema
Name Code Comment Stereotype Data type Multiplicity Standard checks Additional checks Rules Dependencies Dominio – Propiedades
Selección del tipo de datos Seleccionar un clasificador Una Clase o Interfase se puede usar como un tipo de dato Usar la herramienta seleccionadora de clasificación para mostrar la lista
Propiedades de dominio – “Detail” “Detail” sirve para mejorar la generación de código y tipos de datos en la generación de un CDM o PDM Aquí los tipos de datos son internos de PowerDesigner “Persistent” se ve más adelante
Dominios y divergencia Si se forza “non-divergence”, un data ítem no puede tener un tipo de dato diferente del dominio Se dice que se tiene un modelo “honest” Ventana Model Options – Se puede forzar “non-divergence” entre un dominio y los data ítem que usan el dominio
Diagrama de Secuencia En un sistema en funcionamiento los objetos interactúan entre sí Las interacciones suceden a través del tiempo Los objetos interactúan mandándose mensajes Un mensaje hace que un objeto haga algo El diagrama de clases representa la parte estática El diagrama de secuencia muestra la parte dinámica de las interacciones Representa un trabajo producto del proceso de diseño
Modelamiento de interacciones Durante el análisis se puede hacer el modelamiento de las interacciones, si es necesario, pero típicamente es una técnica de modelamiento durante el diseño y la construcción Se pasa del “qué” al “cómo” Objetivos del modelado de interacciones: Ver el comportamiento entre objetos Mostrar de forma detallada las interacciones que ocurren entre objetos a través del tiempo Detallar la distribución de operaciones entre clases
Diagrama de Secuencia Con el diagrama de clases y analizando los casos de uso se puede conceptualizar las partes del sistema pero queda pendiente la interacción entre ellas Esta información hace más sencillo el trabajo de los programadores Les da una visión de cómo codificar las clases y ponerlas a trabajar juntas Un diagrama de secuencia se puede usar para refinar la descripción de un caso de uso y ayuda a encontrar objetos adicionales Típicamente se tiene un diagrama de secuencia para el flujo principal de eventos y uno por cada sub-flujo independiente del caso de uso
Diagramas de Secuenciay sistemas multicapa Los diagramas de secuencia son indispensables para el desarrollo de sistemas multicapa (multi-tier systems) Generalmente la interacción y coordinación entre objetos de diferentes capas es compleja Ejemplo: Interacción que ocurre entre objetos lógicos del negocio en una capa, los objetos de base de datos en otra capa y los múltiples tipos de objetos de la interfase (browser, PDA o Windows) Los diagramas de secuencia pueden gráficamente representar esas interacciones haciendo que sea más fácil entenderlas
Componentes de un diagrama de secuencia Objetos Representados como rectángulos en la parte superior del diagrama Actores se pueden representar de forma opcional Mensajes Representados como flechas Tiempo Representado en la dirección vertical La línea de vida de un objeto es la línea punteada que baja desde el objeto La duración de la ejecución de una operación (activación) se puede representar como un rectángulo a lo largo de la línea de vida del objeto (opcional)
| Página siguiente |