Diseo Orientado a Objetos

TEMA
Universidad Agraria del Ecuador
Escuela de Computacion e Informatica
GRUPO : 9

CAMPOZANO ALVARADO CARLOS
CEPEDA ANDRADE ERICK
SANCHEZ ROMERO VICTOR
Diseo Orientado a Objetos
El diseo de software Orientado a objetos requiere la definicin de una arquitectura
de software multicapa, la especificacin de subsistemas que realizan funciones
necesarias y proven soporte de infraestructura,
Qu es el diseo orientado a objetos?
Un sistema orientado a objetos utiliza las definiciones de las clases derivadas del
modelo de anlisis.El DO0 permite al ingeniero de software definir la arquitectura
OO(orientada a objetos),en forma que maximize la reutilizacin; de esta manera, se
mejora la velocidad del desarrollo y lacalidad del producto terminado.
Por qu es importante?
Cules son los pasos?
El DOO se divide en dos grandes actividades: diseo de sistema y diseo de objetos.
El diseo de sistema crea la arquitectura del producto en una serie de capas, que
cumplen funciones especficas del sistema.
El diseo de objetos se centra en los detalles internos de cada clase, definicin de
atributos.
NOTA: conceptos importantes del diseo
del software:
-Abstraccin -Ocultamiento de la informacin,
-independencia -Funcional y modularidad.

Diseo para sistemas orientados
a objetos
La capa de mensajes.- Contiene detalles de diseo,que permite a cada
objeto comunicarse con sus colaboradores.
Esta capa establece interfaces externas e internaspara el sistema.
La capa de responsabilidades. Contiene estructuras de datos y diseos
algortmicos, para todos los atributos y operaciones de cada objeto.
La capa subsistema. Contiene una representacinde cada uno de los
subsistemas, para permitir al software conseguir sus requisitos definidos
por el cliente
La capa de clases y objetos.- Contiene las jerarqua de las clases
que permiten crear el sistema, tambin contiene representaciones de cada
uno de los objetos.
Los enfoques convencionales
para el diseo aplican
anotaciones y un conjunto de
normas heursticas para
establecer para establecer
correspondencia entre el modelo
de anlisis y el diseo.
El DOO aplica el diseo de
datos(cuando se representan
atributos), diseo arquitectnico(
cuando se desarrolla un modelo de
intercambio de mensajes), y el
diseo procedimental(en el diseo
de operaciones).
El enfoque convencional
VS
El enfoque OO
Es importante notar que la
arquitectura de un diseo O0
tiene ms que ver
con la colaboracin entre
objetos que con el control de
flujo entre componentes del
sistema.
Enfoque convencional vs Enfoque OO

El modelo de diseo
Transformacin de un modelo de
anlisis O0 a un modelo de
diseo OO.
A
B
c
D
A
C B
D
El diseo del subsistema se deriva considerando requisitos
generales del cliente (representados en casos de uso).

Componentes que pueden usarse para comparar diversos mtodos
de diseo:
1.Representacin de jerarquas de modulo.
2.Especificacin de definiciones de datos
3. Especificacin de la lgica procedimental
4.Indicacin de secuencias de proceso
5.Representaciones de estado de objetos y transacciones

6.Definicin de clases y jerarquas
7.Asignacin de operaciones a clase
8.Definicin detallada de la operaciones.
9.especificacin de conexiones de mensajes.
10.Identificacin de servicios exclusivos.
Como existen muchos enfoques es difcil realizar una comparacin
generalizada entre dos mtodos.

Asuntos del diseo

Bertrand Meyer sugiere 5 criterios para juzgar la capacidad que
posee un mtodo de diseo en lograr la modularidad y los
relaciona con el modelo orientado a objeto:

Descomponibilidad
La facilidad con la cual un
mtodo de diseo ayuda al
diseador para descomponer un
gran problema en subproblemas.
Comprensibilidad:
Facilidad de comprensin de un
componente
Sin referencia a otro informacin o
modulo
Continuidad:
la facilidad de hacer pequeos
cambios en un programa y hacer
que estos se manifiesten por si
mismos en cambios
correspondiente en un modulo o
en unos pocos.
Proteccin:
Una caracterstica arquitectnica
que reducir la propagacin de
efectos colaterales si ocurre un
error en un modulo dado
Componibilidad:
El grado con el cual el mtodo de
diseo asegura que los componentes
del programa una vez diseados y
construidos puedan usarse para crear
otro sistema
Los mdulos
Se definen como unidades lingsticas modulares, cuando
corresponden a unidades sintcticas en el lenguaje usado
[MEY90]. Es decir, el lenguaje de programacin que se usar
debe ser capaz de definir directamente la modularidad.
El Panorama de DO0
En el panorama de DOO encontramos una gran variedad, de
mtodosde anlisis y diseo orientados a objetos fue propuesta y
utilizada durante los ochenta y los noventa. A continuacin, haremos
una breve revisin global de los primeros mtodos de DOO:
El mtodo de Booch.[B0094]
Abarca un proceso de micro desarrollo y un <<proceso de macro desarrollo. En el contexto del
diseo, el macro desarrollo engloba una actividad de planificacin arquitectnica, que agrupa
objetos similares en particiones arquitectnicas separadas.
El mtodo de Rumbaugh.[RUM91]
Engloba una actividad de diseo que alienta al diseo a ser conducido a dos diferentes niveles de
abstraccin.El modelo de anlisis se divide en subsistemas, los cuales se asignan a procesadores y
tareas.
El mtodo de Jacobson.[JAC92]
El diseo para ISOO (Ingeniera del software orientada a objetos) [JAC92]es una versin
simplificada del mtodo propietario, El modelo de diseo enfatiza la planificacin para el
modelo de anlisis ISOO. En principio, el modelo idealizado de anlisis se adapta para
acoplarse al ambiente del mundo real.
El mtodo de Coad y Yourdon.
ste mtodo para DO0 [COA91], se desarroll estudiando cmo es que los diseadores
orientados a objetos efectivos hacen su trabajo.La aproximacin de diseo dirige no
slo la aplicacin, sino tambin la infraestructura de la aplicacin.
El mtodo de Wirfs-Brock.
Wirfs-Brock, Wilkerson y Weiner [WIR90] definen un conjunto de tareas
tcnicas, en la cual el anlisis conduce sin duda al diseo. Los
protocolos para cada clase se construyen refinando contratos entre
objetos.
Etapas genricas del DOO
1. Describir cada subsistema y asignar a procesadores y
tareas.
2. Elegir una estrategia para implementar la
administracin de datos, soporte de interfaz y
administracin de tareas.
3. Disear un mecanismo de control, para el sistema
apropiado.
4. Disear objetos creando una representacin procedural
para cada operacin, y estructuras de datos para los
atributos de clase.
5. Disear mensajes, usando la colaboracin entre
objetos y relaciones.
6. Crear el modelo de mensajera.
7. Revisar el modelo de diseo y renovarlo cada vez que
se requiera.
NOTA : El diseo de sistema se centra en arquitectura
de software y definicin de subsistemas.
El diseo de objetos describe objetos, hasta
un nivel en el cual puedan ser implementados,
en un lenguaje de programacin.
Enfoque unificado para el DOO
DISEO DE SISTEMA
DISEO DE OBJETO
Se centra en la arquitectura del
software y definicin de
subsistemas.
Describe objetos, hasta un nivel en
el cual puedan ser implementados
en un lenguaje de programacin.
1. Se extiende para considerar el diseo
de interfaces, administracin de
datos con el sistema que se va a
construir y administracin de tareas
para los subsistemas que se han
especificado.
1. Se centra en la descripcin de
objetos y sus interacciones con los
otros.
2. Una especificacin detallada de las
estructuras de datos de los atributos
y diseo procedural de todas las
operaciones, se crea durante el
diseo de objetos.
3. La visibilidad para los atributos de la
clase se definen, y las interfaces
entre objetos se elaboran para definir
los detalles de un modelo completo
de mensajes
Flujo de proceso para DOO

Diseo
del
sistema
Diseo de
objetos
Diseo de
la interfaz
humana
Diseo de
la gestin
de datos
Diseo de
la gestin
de tareas
Anlisis
orientado
a objetos
Fases del proceso de diseo de sistema
Comunicacin entre subsistemas
Componente de gestin de recursos
Componente de administracin de datos
Componente de interfaz de usuario
Componente de administracin de tareas
Asignacin de concurrencia y subsistemas
Particionar el modelo de anlisis
Particionar el modelo de anlisis
Criterios a tener en cuenta al
momento de definir y disear los
subsistemas
1. El subsistema debe tener una interfaz
bien definida, a travs de la cual se
reduzcan todas las comunicaciones
con el resto del sistema.
2. Con la excepcin de un numero
pequeo de clases de
comunicaciones, las clases
incluidas dentro del subsistema
deben colaborar solo con otras reas
dentro del subsistema.
3. El nmero de subsistemas debe ser
bajo
4. Un subsistema puede ser
particionado internamente para
ayudar a reducir la complejidad.
Enfoque de diseo para estratificacin
por capas
1. Establecer los criterios de estratificacin
por capas.
2. Determinar el nmero de capas.
3. Nombrar las capas y asignar
susbsistemas a las capas.
4. Disear interfaces para cada capa
5. Refinar los subsistemas, para establecer
la estructura de clases de cada capa
6. Definir el modelo de mensajera para la
comunicacin entre capas.
7. Revisar el diseo de capas, para
asegurar que el acoplamiento sea
mnimo.
8. Iterar para refinar el diseo de capas.
Asignacin de concurrencia y subsistemas
1. El sistema dinmico del modelo objeto-comportamiento
provee una indicacin de concurrencia entre clases o
subsistemas.
2. Si las clases deben actuar en sucesos
asincronicamemte y al mismo tiempo, se vern como
concurrentes.
3. Cuando los subsistemas son concurrentes, existen dos
tipos de alojamiento:
Alojar cada subsistema en procesadores
independientes
Alojar los subsistemas en el mismo procesador y
proporcionar soporte de concurrencia, sobre las
caractersticas del sistema operativo.
Componente de administracin de tareas
Estrategias para el
diseo de objetos que
manipulan tareas
concurrentes.
1.Se determinan las
caractersticas de la tarea
2.Se define un coordinador
de tarea y objetos
asociados.
3.Se integra el coordinador
y otras tareas
Plantilla bsica de una
tarea

1. Nombre de la tarea
2. Descripcin
3. Prioridad
4. Servicios
5. Coordinado por...
6. Comunicados por ...
Componente de interfaz de usuario
1. Las mayora de las clases necesarias para crear una
interfaz moderada ya existen y estn disponibles, para
el diseador.
2. Una vez que el actor y su situacin de uso se definen
se identifica una jerarqua de comando.
3. La jerarqua de ordenes define la mayora de las
categoras del men de sistema (barra de mens o la
paleta de herramientas), y todas las sub-funciones, que
estarn disponibles en el contexto de una categora
importante de men de sistema (ventanas de men)
Componente de administracin de datos
La administracin o gestin de datos engloba
dos reas distintas de inters:
1. La administracin de datos crticos para la
propia aplicacin
2. La creacin de infraestructura para el
almacenamiento y recuperacin de objetos.
En general, la administracin de datos se
disea en forma de capas. La idea es aislar los
requisitos de bajo nivel que manipulan las
estructuras de datos, de los requisitos de alto
nivel para manejar los atributos del sistema.
Componente de gestin de recursos
1. Estn disponibles una variedad de recursos diferentes para
un sistema o producto OO; y, muchas veces, los
subsistemas compiten por estos recursos al mismo tiempo.
2. Los recursos globales del sistema pueden ser entidades
externas (unidad de disco, procesador) o abstracciones
(base de datos,un objeto).
3. Sin importar la naturaleza del recurso, el ingeniero de
software debe disear un mecanismo de control para ello.
Rumbaugh sugiere que cada recurso deba ser posedo por
un objeto guardin, quien controlara el acceso al recurso.
Comunicacin entre subsistemas
Una vez que cada subsistema ha sido especificado, es necesario
definir las colaboraciones que existen entre subsistemas.
Listar cada peticin que puede ser realizada por los colaboradores del
subsistema.
Para cada contrato, anotar las especificaciones (heredadas y privadas) que
se requieren para implementar las responsabilidades que implica el contrato.
Considerar un contrato a la vez, que incluya:
Tipo de contrato (cliente servidor , Peer to Peer)
Colaboradores (nombres de los subsistemas que son parte del contrato)
Clase (nombres de clases que proporcionan servicios denotados por el contrato)
Operaciones (nombre de operaciones que implementan los servicios)
Formato del mensaje (requerido para implementar la interaccin entre
colaboradores)
Descripcin de objetos
Una descripcin del diseo de un objeto (instancia de clase) puede
tomar una o dos formas:

1. Una descripcin de protocolo que establece a interfaz de un
objeto, definiendo cada mensaje que el objeto puede recibir y
las operaciones que lleva a cabo cuando recibe un mensaje.
2. Una descripcin de implementacin que muestra detalles de
implementacin para cada operacin implicada por un mensaje
pasado a un objeto.

La descripcin del protocolo no es nada mas que un conjunto de
mensajes y un comentario correspondiente para cada mensaje.
Diseo de algoritmos y estructura de datos
Una variedad de representaciones contenidas en el
modelo de anlisis y el diseo del sistema, proveen una
especificacin para todas las operaciones y atributos.

1. Se crea un algoritmo para implementar la especificacin para cada
operacin. En muchas ocasiones el algoritmo es una simple
secuencia computacional o procedural, que puede ser
implementada como un modulo de software.

2. Las estructuras de datos se disean al mismo tiempo que los
algoritmos. Ya que las operaciones manipulan los atributos de una
clase, el diseo de estructuras de datos, que reflejan mejor los
atributos, tendrn un fuerte sentido en el diseo algortmico de las
operaciones correspondientes.
Modelado de clases
No se muestran todos
los atributos y
operaciones
Nombre
Direccin
Estado
ObtenerCuentas():ConjuntoDeCuentas
EstablecerNombre(cadena Nombre)
ObtenerNombre():Cadena
Cliente
Generalizacin
No se muestran todos
los atributos y
operaciones
Deposito
Cuenta
CuentaCorriente
Producto Manufacturado
El diamante vaci
representa agregacin
Componente
Agregacin
Producto Manufacturado
Componente
ComponenteB ComponenteC
ComponenteA
Generalizacin y Agregacin
Cliente
ColecionCuentas
Composicin
Universidad
Estudiante
Documentando roles
1
1..*
Hospedar
estudiante miembro
Asociacin
Administrador
Iniciar proyecto
Emitir informe de estado
Seleccionar plantilla
Terminar proyecto
Casos de uso
Casos de uso utilizando otro caso de uso
Validar producto
Consultar producto
Consultar nivel de stock
Consultar detalles de orden
uses
uses
uses
Colaboraciones
ViejoCliente:
ClienteBanco
Administrador:
Empleado
Informe ventas Transaccin ventas
Actualizar informe
Crear transaccin
Cambiar detalles
Un diagrama de secuencias sencillo
Colaboraciones
ViejoCliente:
ClienteBanco
Cuenta
Informe balance
GenerarInformeBalance
Otro ejemplo de diagrama de secuencias
Comprobar CuentaValida
Consultar cuenta
Apreciacin Global
El DOO se divide en dos grandes actividades:
Diseo del sistema
Diseo de objetos.
El diseo de sistema crea la arquitectura del producto definiendo una serie de
capas, que cumplen funciones especificas del sistema e identifica las clases
que son encapsuladas por los subsistemas que residen en cada capa. Adems
incorpora la especificacin de tres componentes:
La interfaz de usuario
La gestin de datos
Mecanismos de administracin de tareas
El diseo de objetos se centra en los detalles internos de cada clase,
definicin de atributos, operaciones y detalles de los mensajes.
GRACIAS POR SU ATENCION