HERRAMIENTAS CASE PARA MODELAMIENTO DE DATOS ORIENTADO A OBJETOS

1
HERRAMIENTAS CASE PARA MODELAMIENTO DE
DATOSORIENTADO 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
• SeleccionarTools ? 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 ltltextendgtgt
• 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
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ósitoSi 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 FechaU
ltimaVisita
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

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 EnviarInfor
me ProducirCheque AsignarAdministrador
Sistema Información de pacientes TomarFechaNacimie
nto 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

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

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

• 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

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

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

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?