Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Cap14j CasoUtilizandoHerramienta PDF
Cap14j CasoUtilizandoHerramienta PDF
MODELAMIENTO DE DATOS
ORIENTADO A OBJETOS
1
Facilidades con PowerDesigner
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
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
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
5
Uso de la paleta
6
Fijar las opciones generales del espacio de trabajo
7
UML y OOM en PowerDesigner
Diagrama de clases
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
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
• 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
11
Documentación de los casos de uso
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 <<extend>>
– 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…)
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
15
Atributos de los objetos
16
Rol de las clases: agrupar objetos
Clasificación de objetos
17
Apariencias en la clasificación
Estudiante Empleado
Paciente Cliente
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
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
(continúa …)
20
Refinando clases
21
Ejemplos de interfases de usuario
• Ejemplos de interfase de
estereotipo:
– Contenedor – Ventana MDI
– Vista – Ventana principal
– Control – Botón de acción, menú
• Ejemplos de Entidad
estereotipo
– Camión – Autorización de crédito
– Sistema de nómina – Especificación de un
– Juego de football programa
– Programador – Departamento contable
– Matrimonio – Vehículo
22
Ejemplos de un sistema administrador
23
Crear un diagrama de clases en PowerDesigner
• Seleccionar
Model Classes
o usar la paleta de
herramientas
24
Modificar 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
26
Crear diagramas de casos de uso en
PowerDesigner
• Actores
• Casos de uso
• Generalización
• Asociación
• Dependencia
27
Propiedades del objeto casos de uso
• Nombre
• Código
• Comentario
• Estereotipo
• Pestaña de
especificaciones
– Pasos de acción
– Puntos de extensión
– Excepciones
– Pre-condiciones
– Post condiciones
28
Editar con opciones del menú
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
31
Propiedades de las asociaciones
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
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
34
Descubrir atributos durante el análisis
35
Atributos necesitan atributos
• Los atributos en PowerDesigner tienen un conjunto
completo de propiedades:
– En la página General: – En la página Detail:
• Parent • Initial Value
• Name • Changeability
• Code • Domain
• Comment • Primary Identifier Indicator
• Stereotype • Migrated from
• Data Type • Persistent
• Multiplicity – Code
• Visibility – Data Type
– Length
• Static
– Precision
• Derived
– 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
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
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:
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…)
40
Añadir operaciones en PowerDesigner
Parent Visibility
Name Event
Code Static
Comment Array
Stereotype Abstract
Return Type 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
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)
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
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
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
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
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
51
Descubrir relaciones adicionales
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
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
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
56