Herramientas Case Para Modelamiento De Datos

   EMBED

Share

Preview only show first 6 pages with water mark for full document please download

Transcript

HERRAMIENTAS CASE  PARA  MODELAMIENTO DE DATOS ORIENTADO A OBJETOS 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 1 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 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…) 2 Interfase de PowerDesigner 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 3 Á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 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 4 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 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 5 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 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 6 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ú 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 7 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 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 8 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 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 9 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 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 10 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 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 11 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 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” 12 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 <> – Ejemplo: El caso de uso “Colocar una Orden” puede incluir las etapas del caso de uso “Descuento para Cliente Frecuente” 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 13 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…) 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 14 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 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 15 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 … 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 … 16 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” 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” 17 Apariencias en la clasificación Estudiante Paciente Empleado Cliente 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 18 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 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 19 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 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 …) 20 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 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 21 Ejemplos de interfases de usuario • Ejemplos de interfase de estereotipo: – Contenedor – Vista – Control – Ventana MDI – Ventana principal – Botón de acción, menú 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 22 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 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 23 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 Crear clases en PowerDesigner • Seleccionar Model  Classes o usar la paleta de herramientas 24 Modificar clases en PowerDesigner • Dar doble clic en la clase sobre el diagrama o dar clic derecho y seleccionar una opción Propiedades de las clases en PowerDesigner – – – – – – – – – – – Nombre Código Comentarios Estereotipo Tipo Visibilidad Cardinalidad Persistencia Abstracta Final Generar 25 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 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 26 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 Paleta del diagrama de casos de uso • • • • • Actores Casos de uso Generalización Asociación Dependencia 27 Propiedades del objeto casos de uso • • • • Nombre Código Comentario Estereotipo Documentar casos de uso • Pestaña de especificaciones – – – – – Pasos de acción Puntos de extensión Excepciones Pre-condiciones Post condiciones 28 Editar con opciones del menú 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 29 Documentar otros casos de uso • Diagramas relacionados – Encadenan clases, actores, casos de uso, a diferentes diagramas • Herramienta para abrir diagramas • Propiedades del diagrama Dependencias • Muestra dependencias de casos de uso: – Generalizaciones y asociaciones 30 Propiedades de los actores 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 31 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 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) 32 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 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 33 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 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 34 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 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 35 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 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 36 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 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 37 Operaciones de una clase 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 38 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 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) 39 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…) 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 40 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 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 41 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 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 42 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 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 43 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) 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 44 Operaciones de constructores y destructores • Constructores – 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 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 45 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 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 46 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 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 47 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 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 …) 48 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 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 49 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 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 50 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 Propiedades de las asociaciones en PowerDesigner – – – – – – – – Name Code Comment Stereotype Roles Classes Association Class Aggregation/ composition • Container • Indicator – – – – Multiplicity Ordering Navigable Visibility 51 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 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 52 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) 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 53 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 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 …) 54 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 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 55 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 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 56