Diseño de Software - Conceptos OO

Diseo Orientado a Objetos
Universidad Nacional Mayor de San Marcos

E.A.P. de Ingeniera de Software
Qu es mal diseo?
Rigidez: dificultad para introducir
cambios.
Fragilidad: efecto cascada.
Inmovilidad: reusabilidad dificultosa.

Agenda
Conceptos de Orientacin a Objetos
Principios de Diseo O-O

Orientacin a Objetos
Revisin de conceptos

Qu significa Orientado a
Objetos?
Un modelo es orientado a objetos cuando
est compuesto por un conjunto de
objetos que cooperan entre si envindose
mensajes. Dichos objetos pertenecen a
clases, las cuales pueden relacionarse
entre si por medio de la herencia.

Qu es un Objeto?
Un Objeto representa un tem o entidad
individual (ya sea conceptual o real) con
un rol bien definido en el dominio del
problema.

Objetos: algunos ejemplos

Dominio del Problema
Operaciones comerciales
Procesos industriales
Redes de Computadoras

Objetos
Artculos, Facturas,
Ventas, Compras, Clientes,
Contratos, Crditos, etc.
Orden de Fabricacin,
Productos y piezas,
Mtodos, Mquinas, etc.
Nodos, Enlaces,
Protocolos, Dispositivos,
Usuarios, Permisos, etc.
Caracterizacin de un Objeto
Estado
Comportamiento
Identidad

Clases: dos visiones

Plantilla (o template)
Una Clase es la especificacin o
descripcin genrica de un conjunto de
objetos
Conjunto de instancias
Una Clase es un conjunto de objetos que
comparten caractersticas y
comportamientos comunes
Clases vs. Objetos

Objeto
entidad individual
Clase
Especificacin abstracta
Todo Objeto es instancia de una Clase

Los Objetos colaboran entre si

Visin antropomrfica
objetos como entes vivos
Responsabilidades y Colaboraciones
Relaciones de uso
Relaciones estructurales
Agregacin o Composicin de Objetos

Mensajes
La nica forma de acceder a un objeto
es envindole un Mensaje.
Acceder
obtener informacin del objeto
solicitar la realizacin de una accin
El objeto est encapsulado

Encapsulamiento
Encapsular significa
esconder todos los
detalles de
implementacin de
un objeto,
revelando
solamente aquello
que es necesario
conocer para hacer
uso del mismo.

Enviando mensajes
Objeto
Emisor
Mensaje
Objeto
Receptor
Mtodo

Emisor y Receptor
(cliente y servidor)
Selector y
Parmetros
Mtodo
Agrupando mtodos
Contratos
Protocolo

Contratos
Un contrato (o interfaz) define un
conjunto cohesivo de requerimientos que

un cliente puede hacer a un server.

Contratos (cont.)
Un contrato es un conjunto cohesivo de
mtodos
Una clase puede implementar muchos
contratos
El mismo contrato puede ser implementado
por diferentes clases
Los contratos pueden especificarse
independientemente de las clases que los
implementan
Ejemplo
public interface Ordenable
{
public int comparar(Ordenable o);
}
class ClaseA implements Ordenable
{
// ... Otras declaraciones ...
public int comparar(Ordenable o)
{
// compara
}
}
class ClaseB implements Ordenable

{
public int comparar(Ordenable o)
{
// compara
}
}
class Sorter
{
public void shell_sort(Sortable[] a) {....}
public void quick_sort(Sortable[] a) {....}
public void bubble_sort(Sortable[] a)
}

Protocolo
El protocolo de una clase est formado
por el conjunto de aquellos mensajes que

puede responder

Polimorfismo
Desde el punto de vista del receptor:
Es la capacidad de diferentes objetos de
responder de diferente manera ante el mismo
mensaje.
Desde el punto de vista del emisor:

Es la capacidad para manipular objetos de
diferentes clases solo en base al conocimiento de
sus propiedades comunes, sin tener en cuenta la
clase exacta a la que pertenecen.
Herencia
Permite definir nuevas clases en base a
clases ya existentes
La subclase extiende la superclase,
redefiniendo y/o agregando
propiedades.

Principios de Diseo Orientado

a Objetos

Principio de Apertura y
Clausura
Las clases debieran estar abiertas para
su extensin pero cerradas para su

modificacin

Principio de Apertura y Clausura (cont.)
Apertura para la extensin

La clase puede extenderse para funcionar
de nuevas maneras
Clausura para la modificacin

El cdigo fuente es inviolable: no puede
modificarse

Ejemplo
Figura
tipo
x
y
Circulo
radio
dibujarCirculo

Rectangulo
largo
ancho
dibujarrectangulo
enum TipoFigura {circulo, rectangulo};
class Figura
{
public:
TipoFigura tipo;
int
x, y;
};
class Circulo: public Figura

{
public:
float radio;
void DibujarCirculo();
};

class Rectangulo: public Figura

{
public:
float largo;
float ancho;
void DibujarRectangulo();
};
typedef Figura* PunteroFigura;

void Pantalla::DibujarFiguras(PunteroFigura lista[], int n)
{
int i;
for(i = 0; i < n; i++)
{
Figura* fig = lista[i];
switch(fig->tipo)
{
case circulo:
Circulo* C = (Circulo*)fig;
C->DibujarCirculo();
break;
case rectangulo:
Rectangulo* R = (Rectangulo*)fig;
R->DibujarRectangulo();
}
}
}
Figura
x
y
dibujar
Circulo
radio
dibujar

Rectangulo
largo
ancho
dibujar
class Figura
{
public:
int x, y;
virtual void Dibujar() = 0;
};
class Circulo: public Figura

{
public:
float radio;
virtual void Dibujar();
};

class Rectangulo: public Figura

{
public:
float largo;
float ancho;
virtual void Dibujar();
};
typedef Figura* PunteroFigura;

void Pantalla::DibujarFiguras(PunteroFigura lista[], int n)
{
int i;
for(i = 0; i < n; i++)
{
Figura* fig = lista[i];
fig->Dibujar();
}
}


ClaseCliente
usa
ClaseServidora
La abstraccin es la clave!
ClaseCliente
ServidorAbstracto
ServidorConcreto1
ServidorConcreto3
ServidorConcreto2

Clausura estratgica
Es imposible lograr la clausura absoluta
ante todo tipo de cambio
El diseador debe seleccionar los cambios
ante los que clausurar el diseo

En vez de considerar que cosas podran
forzar un rediseo, considere que cosas

quiere ser capaz de cambiar sin
redisear

Heursticas derivadas
Todas las variables de instancia deben ser
privadas
No utilizar variables globales
La comprobacin de tipos en tiempo de
ejecucin (ej: RTTI o tags) es peligrosa
Disear hacia la interfaz, no hacia la
implementacin
Principio del Ocultamiento de

la Informacin
Todos los detalles acerca de la
implementacin de una clase deben ser

invisibles e inaccesibles desde el exterior
de la misma

Para qu ocultar?
El problema del Acoplamiento
Dificultad para entender las dependencias
Rigidez, Fragilidad, Inmovilidad
Ventajas del Ocultamiento

Clara separacin de interfaz e implementacin
Mayor nivel de abstraccin
Acceso controlado a la parte privada
Libertar para modificar la implementacin

Dos principios derivados

Principio de las Mnimas Interfaces
Principio de las Interfaces Pequeas

Principio de las Mnimas

Interfaces
Cada clase debiera comunicarse con la
menor cantidad posible de otras clases

Ejemplo
void Agenda::AniversariosDeHoy(Personas lista[], int n)
{
int i;
for(i = 0; i < n; i++)
{
Persona* p = lista[i];
Fecha*
f = P->darFechaNacimiento()
if(f->esHoy())
{
AgregarPersonaQueCumpleHoy(p);
}
}
};

Agenda
Persona
1
Fecha
1

void Agenda::AniversariosDeHoy(Personas lista[], int n)

{
int i;
for(i = 0; i < n; i++)
{
Persona* p = lista[i];
if(p->CumpleHoy())
{
AgregarPersonaQueCumpleHoy(p);
}
}
};
bool Persona::CumpleHoy()
{
return fechaNacimiento->esHoy();
}

Agenda
Persona
1
Fecha
1

Principio de las Interfaces

Pequeas
Si dos clases se comunican, debieran
intercambiar la menor cantidad posible de

informacin

Ejemplo
void AlgunaClase::HacerAlgoConUnTiempo(Tiempo t)
{
long horas, minutos, segundos;
long horaEnSegundos;
Tiempo
horas
minutos
segundos
darHoras
darMinutos
darSegundos
horas
= t->DarHoras();
minutos = t->DarMinutos();
segundos = t->DarSegundos();
horaEnSegundos = horas * 3600 + minutos * 60 + segundos;
Procesar(horaEnSegundos);
}

void AlgunaClase:: HacerAlgoConUnTiempo(Tiempo* t)

{
long horaEnSegundos = t->DarHoraEnSegundos();
Procesar(horaEnSegundos);
}
long Tiempo::DarHoraEnSegundos()
{
return horas * 3600 + minutos * 60 + segundos;
}

Tiempo
horas
minutos
segundos
darHoras
darMinutos
darSegundos
darHoraEnSegundos
Principio de Substitucin
Las funciones que usan referencias a
instancias de una clase determinada,

deben ser capaces de operar con objetos
pertenecientes a las subclases sin
saberlo

Principio de Substitucin (cont.)
Dicho de otra forma:

Las subclases de una clase deben
disearse de tal forma que sus instancias

puedan intercambiarse libremente con
instancias de la superclase

Ejemplo
Rectangulo
Cuadrado

class Rectangulo
{
private:
long alto, largo;
public:
virtual void AsignarAlto(float a) { alto = a; }
virtual float DarAlto()
{ return alto; }
virtual void AsignarLargo(float l) { largo = l; }
virtual float DarLargo()
{ return largo; }
};

class Cuadrado: public Rectangulo

{
public:
virtual void AsignarAlto(float a);
virtual void AsignarLargo(float l)
};
void AsignarAlto(float a)
{
Rectangulo::AsignarAlto(a);
Rectangulo::AsignarLargo(a);
}
void AsignarLargo(float l)
{
Rectangulo::AsignarAlto(l);
Rectangulo::AsignarLargo(l);
}
void test(Rectangulo* r)
{
r->AsignarAlto(5);
r->AsignarLargo(4);
float superficie = r->DarAlto() * r->DarLargo();
if(superficie != 20)
{
MostrarError();
}
}
void main()
{
Rectangulo* r = new Rectangulo;
Cuadrado*
c = new Cuadrado;
test(r);
test(c);
// aqu funciona bien

// AQU DA ERROR!!
}
Principio de Inversin de la
Dependencia
Las clases de alto nivel no debieran
depender de las clases de bajo nivel;

ambas debieran depender de
abstracciones.
Las abstracciones no debieran depender
de los detalles; los detalles debieran
depender de las abstracciones.
Ejemplo
Copiador
Teclado
Impresora
void Copiador::Copiar(Teclado* t, Impresora* i)

{
char c = t->LeerCaracter();
while(c != EOF)
{
i->EscribirCaracter(c);
c = t->LeerCaracter()
}
}

Copiador
Reader
Teclado
Scanner
Writer
Disco
Impresora
class Reader
{
public:
virtual char LeerCaracter() = 0;
}
class Writer
{
public:
virtual void EscribirCaracter(char c) = 0;
}
Pantalla
void Copiador::Copiar(Reader* r, Writer* w)

{
char c = r->LeerCaracter();
while(c != EOF)
{
w->EscribirCaracter(c);
c = w->LeerCaracter()
}
}

Estratificacin
PoliticasGlobales
Mecanismos intermedios
Utilidades de bajo nivel

Estratificacin + Abstraccin
PoliticasGlobales
Mecanismos abstractos
Mecanismos intermedios
Utilidades abstractas
Utilidades de bajo nivel

Principio de la Segregacin de
las Interfaces
Los clientes de una clase no debieran ser
forzados a depender de interfaces que no
utilizan

Principio de Segregacin de las Interfaces (cont.)
Fenmeno de las interfaces gordas

Clase A
Clase B

Clase C
Solucin:
Clase B
Contrato B
Contrato C
Clase A

Clase C
En sintesis:
Diferentes clientes implican interfaces
separadas

Ejemplo
Diagrama
InspectorPosicional

InspectorDeFiguras
InspectorPosicional
InformadorPosicional
InspectorDeFiguras
InformadorDeFiguras
Diagrama

Principio de la Dependencia
Acclica
La estructura de dependencias entre
mdulos debe ser un grafo acclico

dirigido

Principio de la Dependencia Acclica (cont.)
Modulo:
Conjunto de clases relacionadas, que se
puede tratar como una unidad.
Paquete A
Paquete B

Ejemplo
Aplicacion
Ventanas
de Mensajes
Ventanas
de Tareas
Tareas
Base de
Datos
Utilidades
Ventanas

Cajas de
Dialogo
Aplicacion
Ventanas
de Mensajes
Ventanas
de Tareas
Tareas
Base de
Datos
Utilidades
Ventanas

Cajas de
Dialogo
Cajas de Dialogo
Clase X
Cajas de Dialogo
Clase X
Clase Abstracta Y

Aplicacion
Clase Y
Aplicacion
Clase Y
DISEO ORIENTADO A OBJETOS

Un sistema orientado a objetos se disea considerando la
interaccin entre ellos, tales objetos mantienen su propio estado
local (localidades de memoria) y otorgan operaciones sobre tales
estados.
o1:C1
o3:C3
o4:C4
estado o1
estado o3
estado o4
ops1 ()
ops3 ()
ops4 ()
o2:C3
estado o2
ops3 ()
o6:C1
estado o6
ops1 ()
o5:C5
estado o5
ops5 ()
ESTRATEGIAS DEL DISEO

ORIENTADO A OBJETOS
El proceso de diseo orientado a objetos involucra disear clases de
objetos y las relaciones entre estas clases. Dichas clases definen a los
objetos en el sistema y sus interacciones.
Diseo Orientado 2
1
Anlisis Orientado
a Objetos.
Desarrollo de un modelo
Orientado a objetos del
dominio de la
aplicacin
3
Programacin Orientado
a Objetos.
Elaborar un diseo
de software usando un lenguaje
de programacin
Tal como: JAVA, C++ u otro

a Objetos.
Desarrollo de un modelo
Orientado a objetos de un
sistema de Software,
para implementar los
requerimientos
LAS ASOCIACIONES EN UML

La asociacin es una relacin muy simple y es utilizada de forma
regular en UML para indicar que ya sea un atributo de un objeto es un
objeto asociado o la implementacin de un mtodo del objeto recae en
un objeto asociado. Una de las asociaciones ms frecuentes es la de
agregacin.
es miembro
Empleado
Departamento
de
es supervisado
por
supervis
a
Supervisor
OBJETOS CONCURRENTES
Conceptualmente, un objeto requiere un servicio de otro pero enviando una peticin de
servicio o mensaje a ese objeto. Al no existir alguna forma de requerimiento para la
ejecucin serial el modelo general de la interaccin permite a los objetos ejecutarse
concurrentemente como procesos paralelos.
o1:C1
estado o1
ops1 ()
Objetos ejecutndose
en la misma mquina
u objetos distribuidos
ejecutndose
en
diferentes mquinas
o2:C2
estado o2
ops2 ()
on:Cn
estado on
opsn ()
CONCURRENCIA
ok:Ck
estado ok
opsk ()
OBJETOS CONCURRENTES
En la prctica, la mayora de los lenguajes de programacin tienen por omisin
un modelo de ejecucin serial de tal forma que las ejecuciones para los servicios
del objeto se implementan en la misma forma que las llamadas a las funciones.
Logrando con ello suspender la llamada a tal objeto.
Sin embargo, Java y C++ proporcionan un mecanismo llamado Thread (Hilos),
que permite la ejecucin de objetos de forma concurrente.
TIPOS DE
IMPLEMENTACIN
DE OBJETOS
CONCURRENTES
SERVIDORES. Donde el objeto es ejecutado como un

proceso en paralelo. Los mtodos inician en respuesta a un
mensaje externo y se pueden ejecutar en paralelo con
mtodos asociados con otros objetos. Cuando finaliza, el
objeto se suspende y espera por ms peticiones de servicio.
Aplicado en sistemas distribuidos.
OBJETOS ACTIVOS. El estado del objeto puede cambiar
por operaciones internas ejecutadas dentro del mismo
objeto. El objeto nunca se suspende por s mismo, como en
el caso anterior. Aplicado en sistemas de tiempo real.

UN PROCESO DE DISEO ORIENTADO A

OBJETOS
Se tomar un software que se encuentra inmerso en una estacin climatolgica
automatizada, como ejemplo de diseo. Las etapas del proceso se encuentran
estrechamente relacionadas y se listan a continuacin:
1. Entendimiento y definicin del contexto de las formas de uso del
sistema
2. Diseo de la arquitectura del sistema
3. Identificacin de los objetos principales del sistema
4. Desarrollo de los modelos de diseo
5. Especificacin de las interfaces de los objetos
A continuacin se describen las caractersticas que la planta climatolgica tiene,

as como tambin las necesidades que tiene. Tomando en consideracin y en gran
detalle el hecho de que cada una de ellas debern de ser tomadas para el diseo
correspondiente.
UN PROCESO DE DISEO
ORIENTADO A OBJETOS
Un sistema de registro del clima es necesario con el fin de generar mapas
climatolgicos haciendo uso de datos recabados de estaciones climatolgicas
lejanas y desatendidas, adems de otras fuentes de datos tales como:
observadores climatolgicos e informacin va satlite. Las estaciones
climatolgicas transmiten sus datos a la computadora en respuesta a las
peticiones de esa mquina.
Un sistema computacional dedicado valida los datos coleccionados y recaba la

Informacin de las diferentes fuentes. Tales datos son almacenados para
Posteriormente, son utilizados en conjunto con la informacin contenida dentro
De una base de datos de mapas digitalizados, para crear los mapas climatolgicos.
Dichos mapas, pueden ser impresos para su distribucin o pueden ser desplegados
En un nmero determinado de formatos

DISEO DE LA ARQUITECTURA
Subsistema
Desplegado de los datos
En donde los objetos se relacionan con la

forma en la que los datos puedan ser
presentados en forma adecuada a los seres
humanos
Subsistema
Almacenamiento de datos

forma en la que los datos puedan ser
almacenados para su uso posterior
Subsistema
Procesamiento de datos

verificacin e integracin de los datos
Subsistema
Coleccin de datos

adquisicin de los datos de las fuentes
remotas

PAQUETES DE UML
En la figura anterior se han mostrado las capas y se ha incluido el nombre de la capa en un
smbolo de paquete de UML que se ha denotado como un subsistema. Un paquete de UML
representa una coleccin de objetos y otros paquetes. Se verifica que cada capa incluye un
nmero determinado de otros componentes.
Subsistema de
Coleccin de datos
Subsistema de
desplegado de datos
Observador
Satlite
Interfaz de
usuario
Mapa de
desplegado
Comms
Estacin
climatolgica
Mapa de
impresin
Mapa
Ballon
Subsistema
Almacenamiento de datos
Subsistema de
Procesamiento de datos
Checar
datos
Almacenamiento
de datos
Integracin
de datos

Almacenamiento
de mapas
Almacenamiento
de datos

Diseño de Software - Conceptos OO

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diseño de Software - Conceptos OO

Cargado por

Copyright:

Formatos disponibles

Diseo Orientado a Objetos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Objetos: algunos ejemplos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Clases: dos visiones

Clases vs. Objetos

Todo Objeto es instancia de una Clase

Universidad Nacional Mayor de San Marcos

Los Objetos colaboran entre si

Universidad Nacional Mayor de San Marcos

El objeto est encapsulado

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

conjunto cohesivo de requerimientos que

Universidad Nacional Mayor de San Marcos

class ClaseB implements Ordenable

Universidad Nacional Mayor de San Marcos

por el conjunto de aquellos mensajes que

Universidad Nacional Mayor de San Marcos

Desde el punto de vista del emisor:

Universidad Nacional Mayor de San Marcos

Principios de Diseo Orientado

Universidad Nacional Mayor de San Marcos

su extensin pero cerradas para su

Universidad Nacional Mayor de San Marcos

Principio de Apertura y Clausura (cont.)

Apertura para la extensin

Clausura para la modificacin

Universidad Nacional Mayor de San Marcos

Universidad Nacional Mayor de San Marcos

enum TipoFigura {circulo, rectangulo};

class Circulo: public Figura

Universidad Nacional Mayor de San Marcos

class Rectangulo: public Figura

typedef Figura* PunteroFigura;

Universidad Nacional Mayor de San Marcos

class Circulo: public Figura

Universidad Nacional Mayor de San Marcos

class Rectangulo: public Figura

typedef Figura* PunteroFigura;

Universidad Nacional Mayor de San Marcos

Principio de Apertura y Clausura (cont.)

Universidad Nacional Mayor de San Marcos

Principio de Apertura y Clausura (cont.)

Universidad Nacional Mayor de San Marcos

Principio de Apertura y Clausura (cont.)

En vez de considerar que cosas podran

forzar un rediseo, considere que cosas

Universidad Nacional Mayor de San Marcos

Principio de Apertura y Clausura (cont.)

Principio del Ocultamiento de

implementacin de una clase deben ser

Universidad Nacional Mayor de San Marcos

Ventajas del Ocultamiento

Universidad Nacional Mayor de San Marcos

Dos principios derivados