HERRAMIENTAS CASE PARA MODELAMIENTO DE DATOS ORIENTADO A OBJETOS

Presentación del tema: "HERRAMIENTAS CASE PARA MODELAMIENTO DE DATOS ORIENTADO A OBJETOS"— Transcripción de la presentación:

1 HERRAMIENTAS CASE PARA MODELAMIENTO DE DATOS ORIENTADO A OBJETOS

2 PowerDesigner y los OOM
PowerDesigner OOM es una poderosa herramienta de diseño para modelamiento orientado a objetos Brinda todas las ventajas de implementación de una herramienta gráfica para diseño por objetos Con PowerDesigner, se puede: Construir un OOM siguiendo la notación de diagramas UML Generar archivos fuentes de clases en Java (.java) Generar objetos PowerBuilder Hacer re-ingeniería de archivos Java (.class, .java o .jar) Hacer re-ingeniería de objetos PowerBuilder Generar y/o reversar a/de otros lenguajes

3 Facilidades con PowerDesigner
OOM es uno de los tres tipos de modelos que maneja PowerDesigner Los otros modelos son: modelo conceptual y modelo físico En PowerDesigner, se puede: Importar un modelo conceptual (CDM) Importar un modelo físico (PDM) Generar un CDM o PDM Ajustar un OOM a las condiciones físicas y consideraciones de rendimiento Ajustar e imprimir modelos

4 Interfase de PowerDesigner
La ventana inicial de PowerDesigner permite escoger el modelo a trabajar La ventana principal está subdividida en páneles que se usan para ver diferentes aspectos relacionados con el área de trabajo (workspace) Los páneles se pueden manipular para colocarlos en un determinado sitio en un determinado tamaño Por omisión, la ventana principal muestra tres páneles: Explorador de objetos Área de edición Área de estado (continúa…)

5 Interfase de PowerDesigner

6 Explorador de objetos El explorador permite manipular simultáneamente múltiples modelos en el área de trabajo El navegador se puede usar para añadir o quitar modelos del área de trabajo

7 Área de edición El área de edición es el área donde se edita el modelo actual La paleta se puede usar para añadir objetos al modelo y dibujar relaciones

8 Ventanas de salida y lista de resultados
Las ventanas de salida y lista de resultados sirven para dar una realimentación de los procesos que se llevan a cabo, por ejemplo, cuando se chequea un modelo o se genera código Esas ventanas se pueden dejar flotantes o en determinado lugar como páneles

9 Barra de herramientas Con la barra de heramientas se puede manipular el área de trabajo, modelos en el área de trabajo y reportes Se puede fijar y ajustar la barra a las necesidades del usuarios

10 Manipulando modelos Para crear modelos, seleccionar File  New del menú, o usar la barra estándar de herramientas Los modelos se pueden abrir desde el explorador, desde el menú File o utilizando la barra estándar de herramientas Se presentan opciones para grabar, cerrar o desligar modelos del área de trabajo

11 Uso de la paleta La paleta aparece después de crear o abrir un modelo
la paleta se usar para ejecutar tareas comunes, tales como añadir clases, asociaciones o generalizaciones Cada tipo de modelo tienen una paleta específica La paleta puede ser flotante o anclada en un determinado sitio

12 Fijar las propiedades del modelo
Para fijar las propiedades del modelo se debe usar la ventana Model Properties Para editar la ventana de propiedades seleccionar Model  Model Properties del menú o dar clic derecho en el diagrama y seleccionar Properties

13 Fijar las opciones generales del espacio de trabajo
Se pueden fijar las opciones generales Aplican a todos los modelos en el área de trabajo Seleccionar Tools  General del menú

14 Fases del análisis y diseño OO
La fase de análisis típicamente enfocada al qué: Proceso en el cual se pueden identificar clases que juegan un rol para alcanzar los requerimientos y objetivos del sistema Usualmente no se necesitar tomar decisiones acerca de los lenguajes que se van a utilizar en la implementación La fase de diseño típicamente enfocada al cómo: Los resultados del análisis se elaboran y preparan para aproximarse a una implementación particular para un marco dado Se identifican y definen objetos adicionales que se necesitan para soportar la implementación Típicamente durante el diseño se necesitan decisiones acerca de los lenguajes para implementación y ambientes de desarrollo

15 UML y OOM en PowerDesigner
PowerDesigner maneja los siguientes tipos de diagramas UML: Diagrama de clases Diagrama de casos de uso Diagramas de secuencia Adicionalmente maneja: Diagrama de actividades Diagrama de componentes

16 Diagrama de clases Una clase es una categoría o grupo de cosas que tienen atributos similares (propiedades) y un comportamiento común (operaciones) Un objeto es una instancia de una clase Una cosa en particular que tiene valores específicos de los atributos El diagrama de clases describe los tipos de objetos en el sistema y las relaciones que existen entre ellos

17 Símbolos en los diagramas de clases
Rectángulo dividido en tres secciones: Nombre Atributos Operaciones Líneas que conectan rectángulos para mostrar relaciones

18 Casos de uso Los casos de uso registran el comportamiento del sistema deste el punto de vista de un usuario externo Ivar Jacobsen, es el padre de los casos de uso Un caso de uso es una secuencia de acciones que un actor ejecuta en un sistema para conseguir un objetivo particular No se presumen especificaciones de diseño o de implementación Indica qué requerimientos se están haciendo

19 Actores Rol que un usuario juega en el sistema
Los actores llevan a cabo los casos de uso Los actores no necesitan ser personas Puede ser un sistema externo que necesita información del sistema Ejemplo: Un sistema genera un archivo que es usado por el sistema contable cada noche. En este caso el sistema contable es el actor que necesita de ese archivo Un actor puede ejecutar muchos casos de uso o un caso de uso puede ser ejecutado por muchos actores

20 Diagramas de casos de uso
Ilustra actores y su intereacción con los casos de uso Los casos de uso aparecen como óvalos Los actores se representan por un muñeco Las líneas de asociación conectan un actor a un caso de uso y representan la comunicación entre ellos

21 Diagramas de casos de uso
También muestran relaciones entre casos de uso Se pueden usar para mostrar dependencias entre roles de actores Los actores que inician están a la izquierda de los casos de uso Los actores receptores están a la derecha El rectángulo representa los límites del sistema Encierra los casos de uso, los actores deben estar fuera del sistema

22 Documentación de los casos de uso
La documentación de un caso de uso consiste de: Una breve descripción Identificación del actor que inicia el caso de uso Precondiciones para el caso de uso Flujo detallado de eventos Detalle del manejo de excepciones y errores Post-condiciones cuando se ha terminado el caso de uso Actor que se beneficia del caso de uso También se puede listar los requisitos particulares para un determinado escenario o camino del caso de uso Debe utilizar los términos del dominio – se pueden usar nombres de clases como nombres en los textos de los casos de uso

23 Documentación de los casos de uso
El flujo de los eventos debe describir: Cómo y cuándo inician y terminan los casos de uso Cuándo los casos de uso interactúan con actores Qué información se intercambia entre el actor y el caso de uso

24 Relaciones de los casos de uso
Inclusión – utiliza un paso de un caso de uso en otro caso de uso Ejemplo: El caso de uso “Cancelar una Orden” incluye el caso de uso “Localizar una Orden”

25 Relaciones de los casos de uso
Extensión – crea un nuevo caso de uso añadiéndole pasos al caso de uso existente. Es una alternativa para el flujo de eventos Representada por una línea de dependencia con el estereotipo <<extend>> Ejemplo: El caso de uso “Colocar una Orden” puede incluir las etapas del caso de uso “Descuento para Cliente Frecuente”

26 Diagramas de secuencia
Un sistema en funcionamiento tiene objetos que interactúan entre sí a través del tiempo Los diagramas de secuencia muestran la interacción dinámica entre objetos a través del tiempo

27 Aproximación general al análisis y diseño OO
Desarrollar un modelo de clases basado en un problema propuesto y/o entrevistas con clientes Una vez conocida la terminología, comenzar a hablar con los usuarios para identificar actores y casos de uso Escribir una descripción básica de los casos de uso para describir los requerimientos funcionales en términos generales Para cada caso de uso: Identificar los objetos que participan en el escenario establecido Actualizar el diagrama de clases (continúa…)

28 Aproximación general al análisis y diseño OO
Hacer entrevistar adicionales para detallar el curso básico de la acción Describir el camino común más frecuente, el menos transitado y los caminos alternos en casos de condiciones de error Continuar la actualización de los diagramas de clases, con los atributos y operaciones que se vayan encontrando Dibujar un diagrama de secuencia para mostrar las iteraciones basadas en tiempo entre objetos y el intercambio de mensajes entre ellos Finalizar el modelo estático añadiendole información detallada de diseño

29 Crear un modelo para análisis a nivel de clases
Primero pensar acerca del “qué” El “cómo” vendrá más tarde Etapas para preparar el modelo de objetos a nivel de análisis 1. Identificar objetos en el dominio del problema 2. Identificar clases y grupos de objetos en ellos 3. Describir relaciones entre las clases Los pasos 1 y 2 de este proceso no son totalmente distintos A medida que explore el dominio del problema: Cualquier cosa que encuentre es un objeto Los grupos de cosas son clases

30 Paso 1: Identificar objetos
El término objeto se utilizó formalmente en el lenguaje Simula en los años 60 para simular algunos aspectos de la realidad ¿Qué es un objeto? Un objeto es cualquier cosa, real o abstracta, del cual podemos almacenar datos y métodos que manipulen esos datos Un objeto es una entidad Tiene propiedades (tiene atributos) Hace cosas (da servicios o tiene métodos) En un sistema orientado a objetos, cualquier cosa es un objeto Ejemplos: Usuarios, ventanas, registros, archivos, clientes, formas, facturas

31 Atributos de los objetos
Los atributos describen un objeto en una forma que es relevante en el dominio del problema Los atributos pueden ser objetos anidados o ser simplemente tipos de datos Atributos típicos para un empleado: Nombre Apellidos Direccion Salario …

32 Operaciones de los objetos
Una operación es algo que el objeto puede hacer o que uno le puede hacer al objeto Operaciones típicas de un empleado: Consultar el número del Seguro Social Consultar el nombre Colocar el nombre Consultar la dirección Calcular el salario …

33 Rol de las clases: agrupar objetos
El rol de una clase es definir los atributos y métodos (estado y comportamiento) de sus instancias Una instancia de una clase es un objeto La clase Empleado, por ejemplo, debe definir la propiedad Dirección Cada empleado (objeto) tendrá sus propios valores para esta propiedad, como “Cra 30 # 45-05”

34 Clasificación de objetos
“La clasificación inteligente es un trabajo intelectual duro y generalmente viene a través de un proceso incremental e iterativo” (Booch) Martin y Odell han observado que en el análisis y diseño orientado a objetos, “de hecho, un objeto puede ser categorizado de más de una manera” No hay un caso tal que podamos decir “ese es el único conjunto correcto de clases”

35 Apariencias en la clasificación
Estudiante Empleado Paciente Cliente

36 Paso 2: Identificar clases
La identificación de clases es iterativo e incremental Pueden ocurrir múltiples iteraciones entre el desarrollo del modelo y la identificación y análisis de los casos de uso El modelo estático se refina incrementalmente en iteraciones sucesivas a través del modelo dinámico Para identificar clases se necesitan varias aproximaciones a través del tiempo Técnica del sujeto-verbo-complemento_directo (también llamada el sustantivo de una frase) Aproximación a categorías comunes de clases (estereotipos) Casos de uso

37 Aproximación al sustantivo de una frase
Técnica de la “inspección gramatical” Mirar los sustantivos en las frases de los documentos, entrevistas y en las especificaciones requeridas Típicamente: Sustantivos y frases con sustantivos tienen objetos y atributos Verbos y frases con verbos tienen operaciones y asociaciones Los posesivos de una frase indican los atributos del sustantivo mas que los objetos Una forma útil de comenzar a trabajar en el dominio de un modelo No hay que demorarse mucho usando esta técnica porque generalmente se detiene el análisis

38 Uso del sustantivo de una frase
1. Comenzar resaltando todos los sustantivos y sustantivos que se encuentren en las frases 2. Hacer una lista de las palabras resaltadas 3. Eliminar duplicados 4. Dejar todos los sustantivos en singular 5. Eliminar las clases irrelevantes Clases que no son pertinentes al dominio del problema 6. Eliminar las clases que son confusas (a las que en una frase no se les encuentra un propósito) Clases que son difíciles de definir y que no tienen un propósito claro 7. Seleccionar las clases relevantes y las confusas para las cuales se puede identificar un propósito Si es necesario, identificar múltiples atributos

39 Nombres de las clases Los nombres de las clases deben ser sustantivos en singular Usar nombres que acepten los usuarios Evitar sinónimos y nombres ambiguos Asegurar que el nombre de la clase refleja su naturaleza intrínseca Por convención, el nombre de la clase debe comenzar en mayúscula En palabras compuestas, usar mayúscula al comienzo de cada palabra Ejemplo: VentanaDelCliente

40 Refinando las clases Identificar clases redundantes:
No guarde dos clases que tengan la misma información o signifiquen lo mismo en diferente contexto Identificar adjetivos para las clases: Un objeto representado por un nombre se comporta de manera diferente cuando se le aplica un adjetivo? Si el uso de un adjetivo hace que el comportamiento del objeto sea diferente, entonces crear una nueva clase Ejemplo, si Empleado y Vendedor se comportan de manera diferente, entonces se deben clasificar en clases diferentes (continúa …)

41 Refinando clases Tener cuidado con las clases que tienen atributos pero no identifican operaciones Atributos de clases son objetos tentativos que solo se usan como valores Redefinir esas clases como atributos y no como clases Ejemplo: las estadísticas asociadas con un afiliado, no son clases, sino atributos de la clase Afiliado

42 Identificando clases: Estereotipos
Los estereotipos representan un mecanismo extendido del UML Las extensiones UML definidas por los usuarios se capacitan a través del uso de estereotipos Los estereotipos comunes, incluyen: Dominio del problema (a menudo llamado Entidad) Interfase de usuario (a menudo llamado Límite) Administración del sistema (a menudo llamado Utilidad) Dedicarse al análisis de un estereotipo a la vez, puede causar confusión en las clases del estereotipo

43 Ejemplos de interfases de usuario
Ejemplos de interfase de estereotipo: Contenedor Vista Control Ventana MDI Ventana principal Botón de acción, menú

44 Ejemplos de dominios de problemas
Ejemplos de Entidad estereotipo Camión Sistema de nómina Juego de football Programador Matrimonio Autorización de crédito Especificación de un programa Departamento contable Vehículo

45 Ejemplos de un sistema administrador
Utilidad estereotipo Administración de datos Administración de tareas Manejo de excepciones Communicaciones Seguridad y autorización Agente/coordinador Ejemplo Bodega de datos Ordenador de tareas Error Mensaje Seguridad Transacción

46 Paso 3: Describir las relaciones entre clases
Durante el análisis, iniciar el en dominio del problema Después de identificar las clases y objetos en el dominio del problema, pasar a definir las relaciones entre ellos Las relaciones pueden ser de tres tipos principales: Asociación Agregación/composición Generalización (herencia) Detalles más adelante

47 Crear un diagrama de clases en PowerDesigner
Para crear un nuevo diagrama de clases, dar clic derecho en el nodo de modelo del explorador de objetos y seleccionar New  Class Diagram

48 Crear clases en PowerDesigner
Seleccionar Model  Classes o usar la paleta de herramientas

49 Modificar clases en PowerDesigner
Dar doble clic en la clase sobre el diagrama o dar clic derecho y seleccionar una opción

50 Propiedades de las clases en PowerDesigner
Nombre Código Comentarios Estereotipo Tipo Visibilidad Cardinalidad Persistencia Abstracta Final Generar

51 Desarrollar los casos de uso
Después de desarrollar el diagrama inicial de clases representando el dominio del problema, comenzar a hablar con los usuarios Hablar con los usuarios típicos y saber qué quieren ellos que haga el sistema Tomar cada cosa discreta que el usuario quiere que haga, darle un nombre y escribir una corta descripción Ideas: Lo más fácil es comenzar elaborando una lista de actores y las salidas de los casos de uso por cada actor Una buena fuente para identificar los casos de uso son los eventos externos – Identificar los eventos ante los cuales necesita reaccionar

52 Desarrollar los casos de uso
El resultado de las entrevistas iniciales deben ser los actores y los casos de uso de más alto nivel que describen los requerimientos funcionales en términos generales Esta información fija los límites y el alcance del sistema Las entrevistas posteriores con los usuarios se harán para desarrollar en detalle esos requerimientos Deben resultar nuevos casos de uso que satisfagan relaciones de inclusión y extensión

53 Crear diagramas de casos de uso en PowerDesigner
Dar clic derecho en el nodo modelo del explorador de objetos y seleccionar New  Use Case Diagram

54 Paleta del diagrama de casos de uso
Actores Casos de uso Generalización Asociación Dependencia

55 Propiedades del objeto casos de uso
Nombre Código Comentario Estereotipo

56 Documentar casos de uso
Pestaña de especificaciones Pasos de acción Puntos de extensión Excepciones Pre-condiciones Post condiciones

57 Editar con opciones del menú

58 Implementar clases de casos de uso
Las clases e interfases se usan para implementar casos de uso Propiedades de las clases Crear una nueva clase

59 Documentar otros casos de uso
Diagramas relacionados Encadenan clases, actores, casos de uso, a diferentes diagramas Herramienta para abrir diagramas Propiedades del diagrama

60 Dependencias Muestra dependencias de casos de uso:
Generalizaciones y asociaciones

61 Propiedades de los actores

62 Propiedades de la generalización
Una generalización es una relación entre el caso de uso más general (el padre) y un caso de uso más específico (el hijo) Visibilidad – privado, protegido, público

63 Propiedades de las asociaciones
Una asociación es una relación unidireccional que describe el encadenamiento entre objetos Muy similar a las asociaciones en un diagrama de clases No especifica roles, cardinalidad o navegabilidad La orientación se da de acuerdo a si el actor da o recibe resultados

64 Propiedades de las dependencias
Una dependencia es una relación entre dos elementos del modelo, en los cuales un cambio en un elemento del modelo (elemento influyente) afecta a otro elemento del modelo (elemento dependiente)

65 Atributos Un atributo es una información acerca de un objeto
Una definición de datos para una instancia de una clase Un atributo normalmente no tiene comportamiento (por ejemplo, número) Pero si el atributo es también un objeto, él tendrá comportamiento Ejemplo: Producto es una clase y también debe ser un atributo de la clase OrdenItem Cada atributo necesita una definición clara y concisa Los nombres de los atributos deben ser significativos Los nombres de atributos y códigos dentro de una clase deben ser únicos

66 Ejemplos de atributos Ejemplo de atributos para una clase Empleado:
PrimerNombre SegundoNombre PrimerApellido Ejemplo de un atributo no recomendado para la clase Empleado: Administrador Esto es una relación entre instancias de la clase empleado y no un atributo

67 Valores de los atributos
Un valor de un atributo es el valor del atributo para una instancia particular de la clase No se deben definir valores de un atributo durante el modelamiento de objetos Cada instancia tendrá un valor para cada atributo de la clase, a menos que contenga un valor nulo o no aplique

68 Dominio del problema y perspectiva del sistema
Los atributos de una clase dependen del dominio del problema Ejemplo, un sistema de nómina de una compañía y un registro de pacientes de un médico deben tener la clase Persona Algunos atributos de esta clase deben tener la misma perspectiva, otros pueden diferir : Sistema de Nómina Nombre Direccion FechaNacimiento CodigoEmpleado CodigoTrabajo Salario Sistema Información de pacientes Nombre Direccion FechaNacimiento TipoDeSangre CiaAseguradora FechaUltimaVisita

69 Descubrir atributos durante el análisis
Se descubren atributos durante la fase de análisis de un OOAD Durante el análisis, sustantivos, descripción de sustantivos y adjetivos en las especificaciones y en la documentación de casos de uso, se definen los atributos de una clase Durante el análisis no es crítico identificar los tipos de datos para los atributos Durante el diseño, se refinan las definiciones de los atributos y tal vez algunos atributos se muevan a una clase más relevante dentro de una jerarquía de clases

70 Definir atributos en PowerDesigner
Para añadir atributos a una clase ir a la ventana Class Properties de una clase, seleccionar la pestaña Attibutes Crear el nuevo atributo Reutilizar un atributo existente Para ver la lista de todos los atributos definidos en el modelos, seleccionar en el menú principal Model  Attributes En esta lista no se pueden añadir atributos

71 Atributos necesitan atributos
Los atributos en PowerDesigner tienen un conjunto completo de propiedades: En la página General: Parent Name Code Comment Stereotype Data Type Multiplicity Visibility Static Derived En la página Detail: Initial Value Changeability Domain Primary Identifier Indicator Migrated from Persistent Code Data Type Length Precision Class Generation

72 Identificador Un identificador es un atributo o una combinación de atributos que identifican de manera inequívoca cada instancia de una clase Este término en OOM es equivalente en un CDM, en un PDM, o a llave primaria o alterna en un DDL Ejemplo: Codigo de la clase Estudiante Cada clase debe tener al menos un identificador Si una clase tiene solamente uno, ese identificador por default es el identificador primario de la clase Se pueden tener atributos y reglas del negocio para un identificador

73 Crear identificadores en PowerDesigner
1. Dar doble clic en la clase de un modelo 2. Seleccionar la pestaña Identifiers 3. Dar un clic en la línea en blanco de la lista o Dar clic en Add a Row 4. Escribir el nombre y código del identificador 5. Clic en OK

74 Añadir atributos a un identificador
Para añadir atributos a un identificador: 1. En la ventana Identifier Properties, dar clic en la pestaña Attributes 2. Dar clic en Add Attributes 3. Colocar una marca en las cajas de selección para uno o más atributos de la clase que se quieran escoger como un identificador 4. Clic en OK

75 Operaciones de una clase

76 Operaciones Una operación es lo que algunas veces puede hacer una clase Cada clase tiene un conjunto de responsabilidades que definen el comportamiento de la clase Las responsabilidades de una clase son llevadas a cabo por sus operaciones Ejemplo, una responsabilidad de la clase Producto es dar el precio La operación para cumplir esta responsabilidad puede ser: Ver la información en la base de datos, o Calcular el precio Una operación debe ejecutar una función simple y cohesiva Una operación se puede invocar para afectar el comportamiento de una clase All instances of a class can use the operations defined for that class.

77 Identificar operaciones
Durante la fase de análisis, encontrar verbos y frases con verbos en la documentación de los requerimientos Las operaciones que necesitan las clases dependen del dominio del problema Ejemplo, para la clase Persona: Sistema de Nómina TomarFechaNacimiento EnviarInforme ProducirCheque AsignarAdministrador Sistema Información de pacientes TomarFechaNacimiento RecibirPago ProducirFórmula AsignarCita

78 Identificar operaciones
Las operaciones por lo general corresponden a consultas sobre los atributos de los objetos (a veces a las asociaciones) Las operaciones son responsables del manejo de los valores de los atributos tanto para consultas, actualización, lectura y escritura de instancias Ejemplo: preguntas acerca de la clase Producto: ¿Qué servicios provee la clase Producto? y ¿Qué información de la clase Producto se debe almacenar? (de un dominio conocido)

79 Nombres de las operaciones
Las operaciones deben tener un nombre que indique su resultado, no pasos dentro de la operación Ejemplo de nombre poco aconsejable: CalcularTotal( ) Indica que se debe calcular el total – esto es una decisión de implementación/optimización Ejemplo de un nombre aceptable: TomarTotal( ) Solamente indica la salida (continúa…)

80 Nombres de las operaciones
Los nombres de las operaciones se deben tomar desde la perspectiva del proveedor no del consumidor Ejemplo, en una aplicación el ingreso de una orden es recibida desde un cliente Para el cliente una operación tiene esta responsabilidad - ¿cómo se debe llamar? Aconsejable – FijarOrden( ), DarOrden( ) No aconsejable – TomarOrden( ) El cliente da la orden, el no toma la orden Usar la notación con punto (Cliente.FijarOrden( )) para clarificar su uso MODSIM is an object-oriented simulation language. The actual syntax of the language for message passing is: ASK object TO operation. This really helps with naming operations. ASK customer TO give rather than ASK customer TO receive Order.

81 Añadir operaciones en PowerDesigner
Para añadir operaciones a una clase: Clic derecho y seleccionar Operations o Doble clic en clases para abrir la ventana de propiedades Para ver una lista de todas las operaciones, seleccionar Model  Operations

82 Propiedades de las operaciones en PowerDesigner
Las operaciones tienen las siguientes propiedades: Parent Name Code Comment Stereotype Return Type Visibility Event Static Array Abstract Final

83 Polimorfismo Los siguientes mensajes todos son para guardar cambios, pero usan diferentes nombres de métodos: Cliente.GabarCliente( ) Factura.GrabarFactura( ) Orden.GrabarOrden( ) Usando los mismos nombres podemos dar mas consistencia: Cliente.Grabar( ) Factura.Grabar( ) Orden.Grabar( ) El mismo método registrado (nombre, argumentos, y tipos de argumentos) definidos en diferente clase se llama polimorfismo

84 Categorías de polimorfismo
Operacional – Métodos polimorficos para clases no relacionadas Estrictamente es una selección de diseño del diseñador OO Debe definir métodos apropiados para cada clase Se puede obviar la construcción compleja de casos o los mensajes dinámicos Inclusional – Métodos polimorficos implementados en una jeraquía de clases usando herencia

85 Operaciones registradas
Una operación de registro de una operación consiste de: Lista opcional de argumentos Retorno de la clase o tipo de dato Durante el análisis no se necesita llenar el registro de una operación Se hace en la etapa de diseño Although the signature is not mandatory, it may be filled in if you know it. Adding signatures often leads to additional classes and/or relationships in the model.

86 Descubrir clases adicionales
Si se especifica una operación registrada, se deben descubrir clases o atributos adicionales Argumentos para la operación Retorno de la clase Ejemplo: TomarItemDeOrden( ) – ItemDeOrden AñadirCliente(Empresa XYZ) – Cliente Añadir esas clases y atributos adicionales al modelo Se muestran en los diagramas de clases según necesidad

87 Operaciones Abstractas
Algunas veces, los diseñadores colocan operaciones en clases abstractas que no están totalmente implementadas, por ejemplo, no tienen definida la lógica Las operaciones deben retornar el tipo de dato definido por la operación registrada Esas operaciones se conocen como operaciones abstractas Las operaciones abstractas son muy comunes en interfases, un concepto de UML soportado por PowerDesigner y encontrado en Java (se ve más adelante)

88 Ver operaciones heredadas
Para ver operaciones de superclases abstractas (ancestros), dar clic en el botón Inherited bajo la pestaña Operations Dar clic en el botón Override para copiar la operación registrada a su clase de tal manera que a esa subclase se debe añadir la lógica específica

89 Operaciones de constructores y destructores
Operación llamada durante la instanciación de un objeto que crea ina instancia de una clase Destructores Operación llamada durante la destrucción del objeto

90 Crear constructores y destructores default
Para crear constructores / destructores default: 1. En la ventana Class Properties seleccionar la pestaña Operations 2. Abrir Add y seleccionar Default Constructor/Destructor De acuerdo con el lenguaje a utilizar, se tiene diferente comportamiento

91 Encapsulamiento – Información oculta
El encapsulamiento previene el acceso directo a a los atributos de una clase (datos) Como a las propiedades solo se llega vía las operaciones (métodos), un objeto controla el acceso a sus datos El encapsulamiento resulta en una interfase funcional “pública” que hace uso del comportamiento del objeto Los atributos se implementan como variables instanciadas declaradas privadas o protegidas por el objeto Todas las comunicaciones con el objeto se hacen vía las operaciones públicas Las operaciones se pueden implementar como eventos definidos por el usuario o como funciones This slide lists details of protecting the implementation of the behavior (and properties).

92 Visibilidad Visibilidad – Indica cómo un objeto es visto y usado por otros objetos Privado La operación es visible y puede ser usada sólo por el mismo objeto Protegido La operación es visible al objeto mismo o a cualquier objeto descenciente (heredado de la misma clase) Paquete La operación es visible a todos los objetos del mismo paquete Público La operación es visible a todos los objetos

93 Atributos de encapsulamiento – Implementación
Define los atributos como variables instanciadas Encapsula las variables instanciadas definiendo su visibilidad como privadas o protegidas Declara las functions get y set como públicas para acceder a cada atributo Para atributos de sólo lectura, solamente declara la función pública get Beneficios: Previene cambios inesperados o no deseados de fuentes externas Cambios en la implementación interna no hacen impacto en objetos externos The “outside” world can’t get at private (or protected) variables, forcing the use of methods to gain access to the variables’ values. This way, the object has absolute control over how the variable values get transformed.

94 Crear Accessors y Mutators
Accessors son operaciones que retornan el valor de una instancia de un atributo Mutators son operaciones que cambian el valor de una instancia de un atributo Para crear accessors y mutators: En la ventana ClassProperties seleccionar la pestaña Attributes dar clic en Add y seleccionar Get/Set Operations

95 Relaciones entre objetos
Los sistemas abarcan muchas clases y objetos Los objetos contribuyen al comportamiento de un sistema en colaboración con otros La colaboración se lleva a cabo a través de relaciones entre los objetos Vamos a ver dos tipos importantes de relaciones entre clases y objetos: Asociación Agregación/composición Super/sub clases (conocidas como generalización o herencia) se ven más adelante

96 Asociación Una referencia de una clase a otra es una asociación
Las asociaciones se dibujan como líneas continuas entre un par de clases Implica que hay una conexión entre los objetos en las clases asociadas Ejemplo: Juan trabaja para la IBM Una asociación representa una relación estructural entre objetos de diferente clase Implementada como una variable en la clase referenciada Ejemplo: un empleado trabaja en un departamento; el identificador del departamento se coloca como una variable en el objeto empleado (continúa …)

97 Asociación Algunas asociaciones son implícitas o son de conocimiento general Las asociaciones generalmente aparecen como verbos en las frases que enuncian el problema y representan relaciones entre las clases Ejemplo: un Cliente puede ordenar artículos

98 Guía para identificar asociaciones
Ver asociaciones mirando los verbos y proposiciones en las frases Ejemplos: parte de, siguiente a, trabaja para, contenido en Los patrones comunes de asociación incluyen: Asociación de localización – siguiente a, contenido en Asociación de comunicación – hablar a, ordenar a Ejemplo: A Cliente hace un pedido a un Vendedor Tres clases: Cliente, Pedido, Vendedor El hecho de que un cliente haga un pedido implica que necesita una asociación entre dos o más de esas clases El Pedido no es parte de Cliente ni de Vendedor

99 Nombres de asociaciones y roles
Por claridad se le puede colocar un nombre a una asociación El nombre se muestra a lo largo de la línea de asoción, entre los iconos de las clases El nombre de la asociación generalmente es un verbo o una frase con un verbo Un rol es un nombre que se coloca al final de una asociación El nombre del rol se coloca sobre la línea de asociación cerca de la clase que él modifica Uno o ambas terminaciones de las asociaciones pueden tener nombres de roles

100 Multiplicidad de las asociaciones
Multiplicidad es el número de instancias de una clase relacionado con las instancias de otra clase Hay que tomar dos decisiones acerca de la multiplicidad, una a cada lado del final de la asociación Ejemplo: En la asociación entre Cliente y Orden Para cada instancia de Cliente, se pueden colocar 0 ó más Ordenes Cada Orden es colocada por exactamente un Cliente

101 Crear Asociaciones en PowerDesigner
Para crear asociaciones en PowerDesigner, utilizar la herramienta de asociación de la paleta Para dibujar una asociación hacer clic en una clase, sostener y soltar en la otra clase Se pueden dar nombres a las asociaciones o definir roles para la asociación con el fin de dar claridad a la asociación entre las clases relacionadas Usualmente se omite el nombre de la asociación cuando se tienen roles

102 Propiedades de las asociaciones en PowerDesigner
Name Code Comment Stereotype Roles Classes Association Class Aggregation/ composition Container Indicator Multiplicity Ordering Navigable Visibility

103 Descubrir relaciones adicionales
Los argumentos de las operaciones y el retorno de las clase denotan relaciones entre la clase, el argumento de la clase y/o el retorno de la clase Ejemplo: La clase Orden tiene la operación AñadirItem (item) Implica una relación entre Orden y OrdenarItem Se debe añadir cualquier relación que se descubra en el modelo y mostrarlo en el diagrama de clases

104 Agregación y composición
Agregación y composición son dos formas especiales de asociación Agregación Es una asociación entre dos clases donde una de ellas está contenida en la otra Una instancia de la clase agregada puede ser sostenida por más de una instancia de la clase contenedora a través del tiempo Ejemplo: Un Empleado puede ser parte de un Departamento, pero puede pasar de un Departamento a otro a través del tiempo Composición Una forma de agregación en la cual las partes están fuertemente ligadas y se ven como una sola cosa a través del tiempo. Si el objeto compuesto se destruye, también sus partes Ejemplo: ItemOrdenado es parte de unaOrden. Si la Orden se cancela/borra, ItemOrdenado también

105 Representación de agregaciones y composiciones
Contenedor (clase al lado del diamante): Especifica cual de las dos clase es la clase agregada o compuesta Indicador (diamante): Indica que la asociación es una agregación (diamante vacio) o una composición (diamante lleno)

106 Agregaciones vs composiciones
Si en cualquier momento una clase es parte de otra, se tiene una agregación La siguiente prueba ayuda a determinar qué tipo de relación es: La clase agregada puede sobrevivir al contenedor (agregación) o Una clase vive dentro de otra o es poseida por otra y no sobrevive al contenedor (composición) La clase compuesta crea dentro clases componentes Cuando el contenedor se detruye, el componente también

107 Guía para identificar composiciones
¿Para describir la relación se utiliza la frase “es parte de”? Una puerta es parte de un camión ¿Algunas operaciones sobre el conjunto aplican automáticamente a sus partes? Al mover el camión, se mueve la puerta ¿Algunos valores de atributos se propagan del conjunto a todas o algunas de sus partes? El camión es azul, la puerta es azul Hay una relación asimétrica donde una clase es subordinada de la otra? Una puerta es parte de un camión, un camión no es parte de una puerta

108 Identificar clases internas
Una clase interna (inner class) es una clase definida y usada con otra clase definida (externa) En Java son comunes las clases internas Forma fuerte de composición porque solamente el todo conoce que la parte existe; esencialmente un objeto privado dentro de otro Se pueden usar clases internas para agrupar clases que lógicamente van juntas o que adicionalmente forzan encapsulamiento Cuando se hace reingeniería de una clase Java que contiene una o más clases internas, se crea una clase externa y se crea una clase por cada una de las clases internas (continúa …)

109 Identificar clases internas
Se crea un enlace de dependencia entre cada clase interna y la clase externa a la que está atada El nombre de cada clase interna tiene como prefijo el nombre de la clase externa

110 Añadir dependencias Una dependencia es una relación lógica entre dos elementos del modelo en el cual un cambio de un elemento del modelo afecta al otro elemento del modelo La relación de dependencia indica que una clase o interfase en un diagrama de componentes usa el servicio o facilidades de otra clase o interfase Más útil cuando es una dependencia de una clase en otra, aun cuando no haya una asociación explícita entre ellas

111 Propiedades de las dependencias
Una dependencia tiene las siguientes propiedades: Name: nombre de la dependencia Code: referencia al nombre de la dependencia Comment: comentarios Influent: el objeto independiente Dependent: el objeto dependiente Stereotype: estereotipo de la dependencia

112 Guardar pistas de dependencias
Guardar pistas de todas las dependencias entre las clases asociadas puede ser muy difícil Para este propósito, en la ventana Class Properties seleccionar la pestaña Dependencies

113 ¿Preguntas?