Diseño de Software - Conceptos OO

8/16/2019 Diseño de Software - Conceptos OO

1/77

Universidad Nacional Mayor de San Marcos

E.A.P. de Ingeniería de Software

Diseño Orientado a Objetos


2/77

¿Qué es “mal diseño”?

• Rigidez : dificultad para introducircambios.

• Fragilidad : efecto cascada.

• Inmovilidad : reusabilidad dificultosa.




3/77

Agenda

• Conceptos de Orientación a Objetos

• Principios de Diseño O-O




4/77

Orientación a Objetos

Revisión de conceptos




5/77

¿Qué significa “Orientado a

Objetos”?Un modelo es orientado a objetos cuandoestá compuesto por un conjunto de

objetos que cooperan entre si enviándosemensajes . Dichos objetos pertenecen aclases , las cuales pueden relacionarse

entre si por medio de la herencia .




6/77

¿Qué es un Objeto?

Un Objeto representa un ítem o entidadindividual (ya sea conceptual o real) con

un rol bien definido en el dominio delproblema.




7/77

Objetos: algunos ejemplos

Dominio del Problema Objetos

Operaciones comerciales

Artículos, Facturas,

Ventas, Compras, Clientes,

Contratos, Créditos, etc.

Procesos industriales

Orden de Fabricación,

Productos y piezas,

Métodos, Máquinas, etc.

Redes de Computadoras Nodos, Enlaces,Protocolos, Dispositivos,

Usuarios, Permisos, etc.




8/77

Caracterización de un Objeto

• Estado

• Comportamiento

• Identidad




9/77

Clases: dos visiones

• Plantilla (o template )

Una Clase es la especificación o

descripción genérica de un conjunto deobjetos

• Conjunto de instancias

Una Clase es un conjunto de objetos quecomparten características ycomportamientos comunes




10/77

Clases vs. Objetos

• Objeto

entidad individual

• ClaseEspecificación abstracta

• Todo Objeto es instancia de una Clase




11/77

Los Objetos colaboran entre si

• Visión antropomórfica

objetos como “entes vivos”

• Responsabilidades y ColaboracionesRelaciones de uso

• Relaciones estructurales

Agregación o Composición de Objetos




12/77

Mensajes

• La única forma de acceder a un objetoes enviándole un Mensaje.

• “Acceder” obtener información del objeto

solicitar la realización de una acción

• El objeto está encapsulado




13/77

Encapsulamiento

• Encapsular significaesconder todos losdetalles de

implementación deun objeto,revelandosolamente aquello

que es necesarioconocer para haceruso del mismo.




14/77

Enviando mensajes

• Emisor y Receptor(cliente y servidor )

• Selector yParámetros

• Método

Mensaje

Método

ObjetoReceptor

ObjetoEmisor




15/77

Agrupando métodos

• Contratos

• Protocolo




16/77

Contratos

“Un contrato (o interfaz) define unconjunto cohesivo de requerimientos que

un cliente puede hacer a un server.”




17/77

Contratos (cont.)

• Un contrato es un conjunto cohesivo demétodos

• Una clase puede implementar muchoscontratos

• El mismo contrato puede ser implementadopor diferentes clases

• Los contratos pueden especificarseindependientemente de las clases que losimplementan




18/77

Ejemplopublic interface Ordenable{

public int comparar(Ordenable o);}

class ClaseA implements Ordenable{// ... Otras declaraciones ...public int comparar(Ordenable o){

// compara}

}

class ClaseB implements Ordenable{// ... Otras declaraciones ...public int comparar(Ordenable o){

// compara}

}

class Sorter{// ... Otras declaraciones ...public void shell_sort(Sortable[] a) {....}public void quick_sort(Sortable[] a) {....}public void bubble_sort(Sortable[] a)

}




19/77

Protocolo

“ El protocolo de una clase está formadopor el conjunto de aquellos mensajes que

puede responder”




20/77

Polimorfismo

• Desde el punto de vista del receptor:Es la capacidad de diferentes objetos de

responder de diferente manera ante el mismomensaje.

• Desde el punto de vista del emisor:Es la capacidad para manipular objetos de

diferentes clases solo en base al conocimiento desus propiedades comunes, sin tener en cuenta laclase exacta a la que pertenecen.




21/77

Herencia

• Permite definir nuevas clases en base aclases ya existentes

• La subclase extiende la superclase,redefiniendo y/o agregandopropiedades.




22/77

Principios de Diseño Orientado

a Objetos




23/77

Principio de Apertura y

Clausura “Las clases debieran estar abiertas parasu extensión pero cerradas para su

modificación”




24/77

Principio de Apertura y Clausura (cont.)

• Apertura para la extensión

La clase puede extenderse para funcionar

de nuevas maneras• Clausura para la modificación

El código fuente es inviolable: no puede

modificarse




25/77

Circulo

radiodibujarCirculo

Figura

tipo

x

y

Rectangulo

largoancho

dibujarrectangulo

Ejemplo




26/77

class Circulo: public Figura

{

public:

float radio;

void DibujarCirculo();

};

enum TipoFigura {circulo, rectangulo};

class Figura{

public:TipoFigura tipo;int x, y;

};

class Rectangulo: public Figura{

public:float largo;

float ancho;

void DibujarRectangulo();};




27/77

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();

}

}

}




28/77

Rectangulo

largo

ancho

dibujar

Circulo

radio

dibujar

Figura

x

y

dibujar




29/77

class Circulo: public Figura

{

public:

float radio;

virtual void Dibujar();

};

class Figura

{public:

int x, y;virtual void Dibujar() = 0;

};

class Rectangulo: public Figura{

public:float largo;

float ancho;

virtual void Dibujar();};




30/77

typedef Figura* PunteroFigura;

void Pantalla::DibujarFiguras(PunteroFigura lista[], int n)

{

int i;

for(i = 0; i < n; i++){

Figura* fig = lista[i];

fig->Dibujar();

}

}




31/77


La abstracción es la clave!

ClaseCliente ClaseServidorausa

ClaseCliente ServidorAbstracto

ServidorConcreto1 ServidorConcreto3

ServidorConcreto2




32/77


• Clausura estratégica

Es imposible lograr la clausura absoluta

ante todo tipo de cambioEl diseñador debe seleccionar los cambios

ante los que clausurar el diseño




33/77


“En vez de considerar que cosas podríanforzar un rediseño, considere que cosas

quiere ser capaz de cambiar sinrediseñar”




34/77


• Heurísticas derivadas

Todas las variables de instancia deben ser

privadasNo utilizar variables globales

La comprobación de tipos en tiempo de

ejecución (ej: RTTI o tags) es peligrosaDiseñar hacia la interfaz, no hacia la

implementación




35/77

Principio del Ocultamiento de

la Información “Todos los detalles acerca de la

implementación de una clase deben serinvisibles e inaccesibles desde el exteriorde la misma”




36/77

¿Para qué ocultar?

• El problema del AcoplamientoDificultad para entender las dependencias

Rigidez, Fragilidad, Inmovilidad• Ventajas del OcultamientoClara separación de interfaz e implementación

Mayor nivel de abstracción

Acceso controlado a la parte privada

Libertar para modificar la implementación




37/77

Dos principios derivados

• Principio de las Mínimas Interfaces

• Principio de las Interfaces Pequeñas




38/77

Principio de las Mínimas

Interfaces

“Cada clase debiera comunicarse con lamenor cantidad posible de otras clases”




39/77

Ejemplovoid 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);

}

}};




40/77

Persona Agenda

Fecha

1

1




41/77

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();

}




42/77

Persona Agenda

Fecha

1

1




43/77

Principio de las Interfaces

Pequeñas “Si dos clases se comunican, debieranintercambiar la menor cantidad posible de

información”




44/77

Ejemplo

void AlgunaClase::HacerAlgoConUnTiempo(Tiempo t){

long horas, minutos, segundos;long horaEnSegundos;

horas = t->DarHoras();minutos = t->DarMinutos();segundos = t->DarSegundos();

horaEnSegundos = horas * 3600 + minutos * 60 + segundos;

Procesar(horaEnSegundos);}

Tiempo

horas

minutos

segundos

darHoras

darMinutos

darSegundos




45/77

void AlgunaClase:: HacerAlgoConUnTiempo(Tiempo* t){long horaEnSegundos = t->DarHoraEnSegundos();

Procesar(horaEnSegundos);}

long Tiempo::DarHoraEnSegundos(){return horas * 3600 + minutos * 60 + segundos;

}

Tiempo

horasminutossegundos

darHorasdarMinutosdarSegundosdarHoraEnSegundos




46/77

Principio de Substitución

“Las funciones que usan referencias ainstancias de una clase determinada,

deben ser capaces de operar con objetospertenecientes a las subclases sinsaberlo”




47/77

Principio de Substitución (cont.)

• Dicho de otra forma:

Las subclases de una clase deben

diseñarse de tal forma que sus instanciaspuedan intercambiarse libremente coninstancias de la superclase




48/77

Ejemplo

Rectangulo

Cuadrado




49/77

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; }

};




50/77

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);

}




51/77

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); // aquí funciona bientest(c); // AQUÍ DA ERROR!!

}




52/77

Principio de Inversión de la

Dependencia• Las clases de alto nivel no debieran

depender de las clases de bajo nivel;ambas debieran depender deabstracciones .

• Las abstracciones no debieran dependerde los detalles; los detalles debierandepender de las abstracciones.




53/77

Ejemplo

void Copiador::Copiar(Teclado* t, Impresora* i){

char c = t->LeerCaracter();while(c != EOF)

{i->EscribirCaracter(c);c = t->LeerCaracter()

}}

Copiador

Teclado Impresora




54/77

class Reader{public:virtual char LeerCaracter() = 0;

}

class Writer{public:virtual void EscribirCaracter(char c) = 0;

}

DiscoScanner Impresora Pantalla

Copiador

Teclado

Reader Writer




55/77

void Copiador::Copiar(Reader* r, Writer* w){

char c = r->LeerCaracter();while(c != EOF)

{w->EscribirCaracter(c);c = w->LeerCaracter()

}}




56/77

Estratificación

PoliticasGlobales

Utilidades de bajo nivel

Mecanismos intermedios




57/77

Estratificación + Abstracción

PoliticasGlobales Mecanismos abstractos

Utilidades abstractas

Utilidades de bajo nivel

Mecanismos intermedios




58/77

Principio de la Segregación de

las Interfaces“Los clientes de una clase no debieran serforzados a depender de interfaces que no

utilizan”




59/77

Principio de Segregación de las Interfaces (cont.)

• Fenómeno de las interfaces “gordas ”

Clase C

Clase B

Clase A




60/77


• Solución:

Clase B Contrato C Clase C

Clase A

Contrato B

Universidad Nacional Mayor de San MarcosE.A.P. de Ingeniería de Software


61/77


• En sintesis:

Diferentes clientes implican interfaces

separadas



62/77

Ejemplo

InspectorPosicional InspectorDeFiguras

Diagrama



63/77

Diagrama

InspectorPosicional InspectorDeFiguras

InformadorDeFigurasInformadorPosicional



64/77

Principio de la Dependencia

Acíclica “La estructura de dependencias entre

módulos debe ser un grafo acíclicodirigido”



65/77

Principio de la Dependencia Acíclica (cont.)

• Modulo:

Conjunto de clases relacionadas, que se

puede tratar como una unidad.

Paquete B

Paquete A



66/77

Ejemplo

Aplicacion

Ventanas

de Tareas

Utilidades

Tareas

Base de

Datos

Cajas de

Dialogo

Ventanas

de Mensajes

Ventanas



67/77

Ventanasde Tareas

Utilidades

Tareas

Base de

Datos

Ventanas

de Mensajes

Ventanas

Cajas de

Dialogo

Aplicacion



68/77

Clase X Clase Y

AplicacionCajas de Dialogo

Clase X

Clase Abstracta Y

Clase Y

AplicacionCajas de Dialogo


DISEÑO ORIENTADO A OBJETOS


69/77


DISEÑO ORIENTADO A OBJETOSUn sistema orientado a objetos se diseña considerando la

interacción entre ellos, tales objetos mantienen su propio estado

local (localidades de memoria) y otorgan operaciones sobre tales

estados.

o1:C1

estado o1

ops1 ()

o3:C3

estado o3

ops3 ()

o4:C4

estado o4

ops4 ()

o2:C3estado o2

ops3 ()

o6:C1estado o6

ops1 ()

o5:C5estado o5

ops5 ()

ESTRATEGIAS DEL DISEÑO


70/77


ESTRATEGIAS DEL DISEÑOORIENTADO A OBJETOS

El proceso de diseño orientado a objetos involucra diseñar clases deobjetos y las relaciones entre estas clases. Dichas clases definen a los

objetos en el sistema y sus interacciones.

Análisis Orientado

a Objetos.Desarrollo de un modelo

Orientado a objetos del

dominio de la

aplicación

1Diseño Orientado

a Objetos.Desarrollo de un modelo

Orientado a objetos de un

sistema de Software,

para implementar los

requerimientos

2

Programación Orientadoa Objetos.

Elaborar un diseñode software usando un lenguaje

de programación

Tal como: JAVA, C++ u otro

3

LAS ASOCIACIONES EN UML


71/77


LAS ASOCIACIONES EN UMLLa asociación es una relación muy simple y es utilizada de forma

regular en UML para indicar que ya sea un atributo de un objeto es unobjeto asociado o la implementación de un método del objeto recae en

un objeto asociado. Una de las asociaciones más frecuentes es la de

agregación.

Empleado

Supervisor

Departamento

supervis

a

es miembro

de

es supervisado

por

OBJETOS CONCURRENTES


72/77


OBJETOS CONCURRENTESConceptualmente, un objeto requiere un servicio de otro pero enviando una “petición de

servicio” o mensaje a ese objeto. Al no existir alguna forma de requerimiento para la

ejecución serial el modelo general de la interacción permite a los objetos ejecutarseconcurrentemente como procesos paralelos.

o1:C1

estado o1

ops1 ()

o2:C2

estado o2

ops2 ()

on:Cn

estado on

opsn ()

ok :Ck

estado ok

opsk ()

CONCURRENCIA

Objetos ejecutándose

en la misma máquina

u objetos distribuidos

ejecutándose en

diferentes máquinas

OBJETOS CONCURRENTES


73/77


OBJETOS CONCURRENTESEn la práctica, la mayoría de los lenguajes de programación tienen por omisión

un modelo de ejecución 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 ejecución de objetos de forma concurrente.

TIPOS DEIMPLEMENTACIÓNDE OBJETOSCONCURRENTES

SERVIDORES. Donde el objeto es ejecutado como un proceso en paralelo. Los métodos inician en respuesta a un

mensaje externo y se pueden ejecutar en paralelo con

métodos asociados con otros objetos. Cuando finaliza, el

objeto se suspende y espera por más 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 DISEÑO ORIENTADO A


74/77


UN PROCESO DE DISEÑO ORIENTADO AOBJETOS

Se tomará un software que se encuentra inmerso en una estación climatológicaautomatizada, como ejemplo de diseño. Las etapas del proceso se encuentran

estrechamente relacionadas y se listan a continuación:

1. Entendimiento y definición del contexto de las formas de uso del

sistema

2. Diseño de la arquitectura del sistema

3. Identificación de los objetos principales del sistema

4. Desarrollo de los modelos de diseño

5. Especificación de las interfaces de los objetos

A continuación se describen las características que la planta climatológica tiene,

así como también las necesidades que tiene. Tomando en consideración y en gran

detalle el hecho de que cada una de ellas deberán de ser tomadas para el diseño

correspondiente.

UN PROCESO DE DISEÑO


75/77


UN PROCESO DE DISEÑOORIENTADO A OBJETOS

Un sistema de registro del clima es necesario con el fin de generar mapasclimatológicos haciendo uso de datos recabados de estaciones climatológicas

lejanas y desatendidas, además de otras fuentes de datos tales como:

observadores climatológicos e información vía satélite. Las estaciones

climatológicas transmiten sus datos a la computadora en respuesta a las

peticiones de esa máquina.

Un sistema computacional dedicado valida los datos coleccionados y recaba la

Información de las diferentes fuentes. Tales datos son almacenados para

Posteriormente, son utilizados en conjunto con la información contenida dentro

De una base de datos de mapas digitalizados, para crear los mapas climatológicos.

Dichos mapas, pueden ser impresos para su distribución o pueden ser desplegados

En un número determinado de formatos

DISEÑO DE LA ARQUITECTURA


76/77


Q

Subsistema

Desplegado de los datos

Subsistema

Almacenamiento de datos

Subsistema

Procesamiento de datos

Subsistema

Colección de datos

En donde los objetos se relacionan con la

forma en la que los datos puedan ser

presentados en forma adecuada a los sereshumanos


forma en la que los datos puedan ser

almacenados para su uso posterior


verificación e integración de los datos


adquisición de los datos de las fuentes

remotas

PAQUETES DE UML


77/77

PAQUETES DE UMLEn la figura anterior se han mostrado las capas y se ha incluido el nombre de la capa en un

símbolo de paquete de UML que se ha denotado como un subsistema. Un paquete de UML

representa una colección de objetos y otros paquetes. Se verifica que cada capa incluye unnúmero determinado de otros componentes.

Almacenamiento

de datos

Almacenamiento Almacenamiento

Subsistema

Almacenamiento de datos

Checar

datos

Integración

de datos

Subsistema de

Procesamiento de datos

Observador

Comms

Satélite

Estación

climatológica Ballon

Subsistema de

Colección de datos

Interfaz de

usuario

Mapa de

desplegado

Mapa Mapa de

impresión

Subsistema de

desplegado de datos

Diseño de Software - Conceptos OO

Documents

Transcript of Diseño de Software - Conceptos OO