DISEO ORIENTADO A

OBJETOS
F E L I P E A LVA R E Z O RT I Z
 ORIENTACIN A OBJETOS

La Orientacin a objetos ve a los datos y las

funciones juntas (abstraccin de datos como
base).
El propsito de la orientacin a objetos es el de
definir las clases del sistema a construir y las
relaciones entre stas.
 ANLISIS Y DISEO ORIENTADO A
OBJETOS (ADOO)
La ADOO es un enfoque que modela un sistema
como un grupo de objetos que interactan entre
si.
Los objetos son abstracciones del mundo real o
entidades del sistema que se administran entre
ellas mismas.
La funcionalidad del sistema se expresa en
trminos de servicios de los objetos.
Los objetos son independientes y encapsulan el
estado.
 ANLISIS Y DISEO ORIENTADO A
OBJETOS (ADOO)
Pero AOO ( Anlisis) modela el problema y DOO(Diseo)
modela la solucin.
ADOO sostiene que la representacin creada por el AOO
generalmente se subsume en la representacin del dominio
de la solucin creada por el DOO.
 ANLISIS Y DISEO ORIENTADO A
OBJETOS (ADOO)
La AOO y DOO se diferencian en el tipo de
Objetos que manipulan:
Los objetos del AOO representan un concepto del
problema: Objetos Semnticos, atributos y servicios.
Adems de refinar los objetos semnticos, el DOO
producen otros tipos de objetos:
Objetos de Interfaces.
Objetos de aplicaciones.
Objetos de utilidad.
 ANLISIS Y DISEO ORIENTADO A
OBJETOS (ADOO)
Objetos de Interfaces: Se encargan de la interfaz
del usuario.
Objetos de Aplicaciones: Especifican los
mecanismos de control para la solucin
propuesta.
Objetos de utilidad: Son los necesarios para
soportar los servicios de los objetos semnticos
(ej: pilas, rboles, diccionarios, etc.).
 MTODOS DE DISEO ORIENTADO A
OBJETOS
Algunos mtodos que fueron originalmente
basados en funciones (mtodo de Yourdon) han
sido adaptadas al diseo orientado a objetos.
Otros mtodos como el mtodo de Booch han
sido especficamente desarrolladas
especficamente para el Diseo Orientado a
Objetos.
El Diseo Orientado a Objetos es un mtodo de
diseo desarrollado para soportar la
programacin en Ada (lenguaje de programacin
orientado a objetos diseado por Jean Ichbiah).
 METODOLOGA DE BOOCH

Desarrollada por Rational Booch.

Es un lenguaje de modelado de objetos y una
metodologa ampliamente usada en el diseo de
software orientado a objetos.
Los aspectos notables de la metodologa de
Booch han sido superados por el Lenguaje
Unificado de Modelado(UML).
Los aspectos metodolgicos de la metodologa de
Booch fueron incorporados en varias
metodologas y procesos, siendo la principal de
ellas el Proceso Racional Unificado (RUP).
 MTODO DE BOOCH

Este mtodo considera que las etapas del proceso

en un desarrollo a objetos son:
1. Identificar las clases y objetos en un nivel dado
de abstraccin
2. Identificar la semntica de estas clases y
objetos
3. Identificar las relaciones entre clases y objetos
4. Especificar la interfaz y la implementacin de
estas clases y objetos
 MTODO DE BOOCH

Booch contempla el siguiente Diseo en pirmide.

 MTODO DE BOOCH

La capa del subsistema: Contiene una

representacin de cada uno de los subsistemas
que le permiten al software conseguir los
requisitos definidos por el cliente e implementar
la infraestructura tcnica que los soporta.
La capa de clases y Objetos: Contiene las
jerarquas de clase que permiten crear el sistema
usando generalizaciones y especializaciones
mejor definidas. Esta capa tambin contiene
representaciones de diseo para cada objeto.
 MTODO DE BOOCH

La capa de mensajes.- Contiene los detalles que

le permiten a cada objeto comunicarse con sus
colaboradores. Esta capa establece las interfaces
externas e internas para el sistema.
La capa de responsabilidades.- Contiene las
estructuras de datos y el diseo algortmico para
todo los atributos y operaciones de cada objeto.
METODOLOGA OMT (RUMBAUGH)

La metodologa OMT es una tcnica de modelado

de objetos, desarrollada por James Rumbaugh,
que es uno de los precursores del Lenguaje
Unificado de Modelado (UML).
El significado de las siglas de esta metodologa es
Tcnica de Modelado en Objetos (Object Modeling
Technique).
La fase de anlisis comienza con la declaracin
del problema que incluye, una lista de de
objetivos (metas) y conceptos claves definitivos
definidos para el dominio del problema a resolver.
METODOLOGIA OMT (RUMBAUGH)

La declaracin del problema se expande

despus en tres modelos:
Modelo de objetos: representa los objetos del sistema.
Modelo dinmico: representa la interaccin entre esos
objetos representados como eventos, estados y
transiciones.
Modelo funcional: representa los mtodos del sistema
desde la perspectiva de flujo de datos.
La fase de anlisis genera diagramas del modelo
de objetos , diagramas de estado, diagramas de
eventos de flujo y diagramas de flujos de datos.
METODOLOGA OMT (RUMBAUGH)

Despus de la fase de anlisis, se sigue con la fase

de diseo de sistema. Aqu se define la arquitectura
completa del sistema.
Primero el sistema se organiza en subsistemas que
estn asignados a ciertos procesos y tareas, tomando
en cuenta la colaboracin y concurrencia entre ellos.
Luego, el almacenamiento persistente de datos se
establece por medio de una estrategia de manejo de
informacin global compartida.
Despus, se examinan las situaciones limite para
ayudar a establecer las prioridades de negociacin.
METODOLOGA OMT (RUMBAUGH)

La fase de diseo de objetos viene despus de la

fase de diseo del sistema. Aqu se establece el
plan de implementacin.
Se definen las clases de objetos, as como sus
algoritmos, poniendo especial atencin con la
optimizacin y persistencia de datos. Se definen
cuestiones de herencia, asociaciones,
agregaciones y valores por omisin.
La metodologa OMT es secuencial en el sentido
de que la primera fase es la de anlisis, seguida
por el diseo.
METODOLOGA OMT (RUMBAUGH)

La metodologa OMT es muy similar a la

metodologa Booch, cuyo principal criterio es
hacer nfasis en las fases de diseo y anlisis
para una primera entrega del producto.
OMT pone especial atencin en el modelo y uso
de modelos para lograr una abstraccin, en el
cual el anlisis est enfocado en el mundo real a
nivel de diseo.
 IDENTIFICACIN DE OBJETOS

Existen varios enfoques en cuanto a las tcnicas

a aplicar para identificar cuales son las
abstracciones que mejor representan o recogen la
semntica del problema que se desea resolver.
Las mas difundidas son:
Anlisis Textual.
Las tarjetas CRC.
Las formas de utilizacin.
IDENTIFICACIN DE OBJETOS ANLISIS
TEXTUAL

Es el ms simple e intuitivo de las tcnicas que

aqu se van explicar. Parte de una descripcin del
problema en lenguaje natural y consistira en
extraer los objetos, los atributos, los servicios y las
relaciones entre los objetos mediante un anlisis
lingstico del enunciado del problema.
TABLA DE REFERENCIA
IDENTIFICACIN DE OBJETOS TARJETAS
CRC
Las tarjetas CRC (Class, Responsability and
Collaboration- Clases, Responsabilidades, y
Colaboraciones), tambin denominadas tarjetas
de clase, constituyen una forma simple y efectiva
de analizar escenarios.
Esta tcnica consiste en elaborar una ficha o
tarjeta por cada clase en la que se anotan los
siguientes datos: el nombre de la clase, la lista de
sus superclases, la lista de sus subclases, sus
responsabilidades y sus colaboraciones.
IDENTIFICACIN DE OBJETOS TARJETAS
CRC
IDENTIFICACIN DE OBJETOS TARJETAS
CRC
Las responsabilidades de una clase son todos los
servicios que proporciona la clase a sus clientes
potenciales. Por su parte, las colaboraciones de
una clase representan las peticiones que hace
una clase a ciertos servidores para poder cumplir
sus responsabilidades.
La forma de trabajo con las tarjetas de clase
consiste en identificar las primeras clases
semnticas
IDENTIFICACIN DE OBJETOS FORMAS
DE UTILIZACIN
Las formas de utilizacin o casos de uso se deben
a Ivar Jacobson y fueron presentadas en el
OOPSLA 1987. Un caso de uso es una forma,
patrn o ejemplo concreto de utilizacin, un
escenario que comienza con algn usuario del
sistema que inicia alguna transaccin o secuencia
de eventos interrelacionados.
Las formas de utilizacin se introducen en la
etapa de anlisis para representar escenarios
concretos que ayudan a identificar los objetos
que intervienen en dichos escenarios.
IDENTIFICACIN DE OBJETOS FORMAS
DE UTILIZACIN
Una forma de utilizacin consta de dos elementos
principales, los actores y las formas de utilizacin.
Un actor representa cualquier elemento que
intercambia informacin con el sistema, por lo
que est fuera del sistema, y se representan por
el tpico monigote.
Una forma de utilizacin representa una
secuencia de transacciones en un dilogo con el
sistema que se encuentran relacionadas por su
comportamiento, las formas de utilizacin se
representan por elipses
 MODELADO DE OBJETOS

Los objetos identificados en la etapa de anlisis

se plasman en diferentes modelos, combatiendo
de esta forma la complejidad inherente del
problema al que nos estamos enfrentando.
Para la construccin de modelos de objetos, y
modelos software en general, se debe contar con
un lenguaje de modelado, es decir, un lenguaje
para especificar, visualizar, construir y
documentar los componentes de los sistemas
software.
 MODELADO DE OBJETOS - UML

UML son las siglas de Unified Modeling Language o

Lenguaje Unificado de Modelado, comenzo en 1996 con
la versin 0.91 publicada por The Three Amigos
(Grady, Jacobson y Rumbaugh) se trata de un estndar
que se ha adoptado a nivel internacional por numerosas
empresas y organismos para crear esquemas, diagramas
y documentacin relativa a los desarrollos de software.
Tipos de Diagramas:
Estructurales: Muestra la estructura esttica de los objetos en un
sistema.
Comportamiento: Muestran el comportamiento dinmico de los
objetos en el sistema.
De interaccin.
 DIAGRAMAS ESTRUCTURALES

Diagrama de clases: Muestra las clases en un

sistema, atributos y operaciones de cada clase y
la relacin entre cada clase. En la mayora de las
herramientas de modelado, una clase tiene tres
partes, nombre en la parte superior, atributos en
el centro y operaciones o mtodos en la parte
inferior. En sistemas grandes con muchas clases
relacionadas, las clases se agrupan para crear
diagramas de clases.
 DIAGRAMAS ESTRUCTURALES

Diagrama de componentes: Un diagrama de

componentes muestra la relacin estructural de los
componentes de un sistema de software. Estos se
utilizan principalmente cuando se trabaja con sistemas
complejos que tienen muchos componentes. Los
componentes se comunican entre s mediante
interfaces.
Diagrama de despliegue: Un diagrama de despliegue
muestra el hardware de su sistema y el software de ese
hardware. Los diagramas de implementacin son tiles
cuando la solucin de software se despliega en varios
equipos, cada uno con una configuracin nica.
 DIAGRAMAS ESTRUCTURALES

Diagrama de objetosLos diagramas de objetos,

a veces denominados diagramas de instancia,
son muy similares a los diagramas de clases. Al
igual que los diagramas de clases, tambin
muestran la relacin entre los objetos, pero usan
ejemplos del mundo real. Se utilizan para mostrar
cmo se ver un sistema en un momento dado.
Diagrama de paquetesComo su nombre
indica, un diagrama de paquetes muestra las
dependencias entre diferentes paquetes de un
sistema.
 DIAGRAMAS ESTRUCTURALES

Diagrama de estructura compuesta Los

diagramas de estructura compuesta se utilizan
para mostrar la estructura interna de una clase.
DIAGRAMAS DE COMPORTAMIENTO

Diagrama de actividades Los diagramas de actividad

representan los flujos de trabajo de forma grfica.
Pueden utilizarse para describir el flujo de trabajo
empresarial o el flujo de trabajo operativo de cualquier
componente de un sistema.
Diagrama de casos de uso : los diagramas de casos
de uso ofrecen una visin general de los actores
involucrados en un sistema, las diferentes funciones que
necesitan esos actores y cmo interactan estas
diferentes funciones. Es un gran punto de partida para
cualquier discusin del proyecto, ya que se pueden
identificar fcilmente los principales actores involucrados
y los principales procesos del sistema.
DIAGRAMAS DE COMPORTAMIENTO

Diagrama de mquina de estados Los

diagramas de mquina de estado son similares a
los diagramas de actividad, aunque las
anotaciones y el uso cambian un poco. En algn
momento se conocen como diagramas de estados
o diagramas de diagramas de estado tambin.
Estos son muy tiles para describir el
comportamiento de los objetos que actan de
manera diferente de acuerdo con el estado en
que se encuentran en el momento.
 DIAGRAMAS DE INTERACCIN

Diagrama de secuencia Los diagramas de

secuencia en UML muestran cmo los objetos
interactan entre s y el orden en que se producen
esas interacciones. Es importante tener en cuenta
que muestran las interacciones para un escenario en
particular. Los procesos se representan
verticalmente y las interacciones se muestran como
flechas.
Diagrama de comunicacin El diagrama de
comunicacin se llam diagrama de colaboracin en
UML 1. Es similar a los diagramas de secuencia, pero
el foco est en los mensajes pasados entre objetos.
 DIAGRAMA DE INTERACCIN

Diagrama de tiempos Los diagramas de

sincronizacin son muy similares a los diagramas
de secuencia. Representan el comportamiento de
los objetos en un marco de tiempo dado. Si es
solo un objeto, el diagrama es directo, pero si hay
ms de un objeto involucrado, tambin se pueden
usar para mostrar interacciones de objetos
durante ese perodo de tiempo.
 DISEO

Bertrand Meyer sugiere los siguientes criterios

para poder juzgar la capacidad que posee un
mtodo de diseo en poder lograr ciertos
elementos importantes tales como la
modularidad:
Descomponibilidad.
Componibilidad.
Comprensibilidad.
Continuidad.
Proteccin.
 DISEO

Descomponibilidad.- Facilidad con la cual un

mtodo de diseo ayuda al diseador a
descomponer un gran problema en subproblemas
ms sencillos de resolver.
Componibilidad.- Grado con el cual un mtodo de
diseo asegura que los componentes de un
programa (mdulos), una vez diseados y
construidos, pueden reusarse para crear otros
sistemas.
 DISEO

Comprensibilidad.- Facilidad de comprensin de

un componente de programa sin referencia a otra
informacin o mdulos.
Continuidad.- Facilidad de hacer pequeos
cambios en un programa y hacer que estos se
manifiesten por s mismos en cambios
correspondientes solamente en no o unos pocos
mdulos ms.
Proteccin.- Caracterstica arquitectnica que
reducir la propagacin de efectos colaterales si
ocurre un error en un mdulo dado
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS CLASES Y OBJETOS
Las clases y los objetos son diferentes: las clases
definen un tipo, los objetos son sus instancias.
La propiedad bsica de los objetos es el
encapsulado.
Encapsula datos e informacin (i.e. el estado) y Provee
interfaces para accederlos y modificarlos.
Brinda abstraccin y ocultado de informacin.
Los Objetos tienen estado persistente.
Los objetos tienen identidad:
Cada objeto puede ser identificado y tratado como una
entidad distinta.
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS CLASES Y OBJETOS
Una clase es una plantilla del cual se crean los
objetos, esta define la estructura y los servicios.
Una clase tiene:
Una interfaz que define cuales partes de un objeto pueden
accederse desde el exterior.
Un cuerpo que implementa las operaciones.
Variables de instancias para retener el estado del objeto.
Las operaciones de una clase pueden ser:
Pblicas: accesibles del exterior.
Privadas: accesibles slo desde dentro de la clase,
Protegidas: accesibles desde dentro de la clase y desde sus
subclases.
Existen operaciones constructoras y destructoras.
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS CLASES Y OBJETOS
Si un objeto usa servicios de otro hay una asociacin entre
ellos.
Un objeto interacta con otro envindole un mensaje
solicitando un servicio.
Tras la recepcin del mensaje, el objeto receptor invoca al
mtodo que implementa tal servicio.
Si un objeto est compuesto por otros se dice que hay una
agregacin.
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS HERENCIA Y POLIMORFISMO
La herencia es un concepto nico en OO.
La herencia es una relacin entre clases que
permite la definicin e implementacin de una
clase basada en la definicin de una clase
existente.
Cuando una clase Y hereda de una clase X, Y
toma implcitamente todos los atributos y
operaciones de X.
Y se denomina la subclase o clase derivada.
X se denomina la superclase o clase base.
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS HERENCIA Y POLIMORFISMO
La subclase Y tiene un parte derivada (heredada
de X) y una parte incremental (nueva).
La parte incremental es la nica que necesita
definirse en Y.
La herencia crea una relacin es-un: un objeto
de clase Y tambin es un objeto de clase X
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS HERENCIA Y POLIMORFISMO
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS HERENCIA Y POLIMORFISMO
 CONCEPTOS DE LA ORIENTACIN A
OBJETOS HERENCIA Y POLIMORFISMO
Herencia estricta: una subclase toma todas las
caractersticas de su superclase.
Slo agrega caractersticas para especializarla
Herencia no estricta: la subclase redefine alguna de
las caractersticas.
La herencia estricta representa limpiamente la
relacin es-un.
La herencia induce polimorfismo: un objeto puede
ser de distintos tipos (pertenecer a distintas clases).
Un objeto de tipo Y es tambin un objeto de tipo X
(si Y es subclase de X).
 CONCEPTOS DE DISEO

Durante el diseo la actividad clave es la

especificacin de clases del sistema a construir.
La correccin del diseo es fundamental. Pero el
diseo tambin debe ser bueno: eficiente,
modificable, estable, ...
El diseo se puede evaluar usando:
Acoplamiento
Cohesin
Principio abierto-cerrado
 CONCEPTOS DE DISEO -
ACOPLAMIENTO
El acoplamiento es un concepto inter-modular,
captura la fuerza de interconexin entre mdulos.
Objetivo: bajo acoplamiento.
Tres tipos de acoplamiento:
Acoplamiento por interaccin
Acoplamiento de componentes
Acoplamiento de herencia
 CONCEPTOS DE DISEO -
ACOPLAMIENTO
Acoplamiento por interaccin:
Ocurre debido a mtodos de una clase que invocan a
mtodos de otra clase.
Mayor acoplamiento si:
Los mtodos acceden partes internas de otros mtodos.
Los mtodos manipulan directamente variables de otras
clases.
La informacin se pasa a travs de variables temporales.
Menor acoplamiento si los mtodos se comunican
directamente a travs de los parmetros:
Con el menor nmero de parmetros posible.
Pasando la menor cantidad de informacin posible.
Pasando slo datos.
 CONCEPTOS DE DISEO -
ACOPLAMIENTO
Acoplamiento de componentes:
Ocurre cuando una clase A tiene variables de otra clase
C, en particular,
Si A tiene variables de instancia de tipo C
Si A tiene parmetros de tipo C o
Si A tiene un mtodo con variables locales de tipo C.
Cuando A est acoplado con C, tambin est acoplado
con todas sus subclases.
Menor acoplamiento si las variables de clase C en A son,
o bien atributos, o bien parmetros en un mtodo.
 CONCEPTOS DE DISEO -
ACOPLAMIENTO
Acoplamiento de herencia:
Dos clases estn acopladas si una es subclase de otra.
Peor forma de acoplamiento si las subclases modifican la
signatura de un mtodo o eliminan un mtodo.
Tambin es malo si, a pesar de mantener la signatura de
un mtodo se modifica el comportamiento de ste
(debera preservar la pre y postcondicin para que no sea
malo).
Menor acoplamiento si la subclase slo agrega variables
de instancia y mtodos pero no modifica los existentes
en la superclase.
CONCEPTOS DE DISEO - COHESIN

La cohesin es un concepto intra-modular;

captura cuan relacionado estn los elementos de
un mdulo.
Objetivo: alta cohesin.
Tres tipos de cohesin:
Cohesin de mtodo.
Cohesin de clase.
Cohesin de la herencia.
CONCEPTOS DE DISEO - COHESIN

Cohesin de mtodo:
Por qu los elementos estn juntos en el mismo
mtodo?
La cohesin es mayor si cada mtodo implementa una
nica funcin claramente definida con todos sus
elementos contribuyendo a implementar esta funcin.
Se debera poder describir con una oracin simple que es
lo que el mtodo hace.
CONCEPTOS DE DISEO - COHESIN

Cohesin de clase:
Por qu distintos atributos y mtodos estn en la misma
clase?
Una clase debera representar un nico concepto con
todos sus elementos contribuyendo a este concepto.
Si una clase encapsula mltiples conceptos, la clase
pierde cohesin.
Un sntoma de mltiples conceptos se produce cuando
los mtodos se pueden separar en diversos grupos, cada
grupo accediendo a distintos subconjuntos de atributos.
CONCEPTOS DE DISEO - COHESIN

Cohesin de la herencia:
Por qu distintas clases estn juntas en la misma
jerarqua?
Hay dos razones para definir subclases:
Generalizacin-especializacin, y
Reutilizacin.
La cohesin es ms alta si la jerarqua se produce como
consecuencia de la generalizacin - especializacin.
 CONCEPTOS DE DISEO PRINCIPIO
ABIERTO-CERRADO
Las entidades de software deben ser abiertas
para extenderlas y cerradas para modificarlas.
El comportamiento puede extenderse para
adaptar el sistema a nuevos requerimientos, pero
el cdigo existente no debera modificarse.
Minimiza el riesgo de daar la funcionalidad
existente al ingresar cambios (lo cual es una
consideracin muy importante al modificar
cdigo).
 CONCEPTOS DE DISEO PRINCIPIO
ABIERTO-CERRADO
En OO este principio es satisfecho si se usa
apropiadamente la herencia y el polimorfismo.
La herencia permite crear una nueva (sub)clase
para extender el comportamiento sin modificar la
clase original.