algoritmos y programación iii 8. diseño, patrones, arquitecturas carlos fontela, 2004

Algoritmos y Programación III

8. Diseño, patrones,

arquitecturasCarlos Fontela, 2004

Algoritmos y Programación IIICarlos Fontela, 2004

Temario

Diseño OO

Arquitecturas

Arquitecturas y UML

Patrones de arquitectura de componentes Diseño de clases (en general) Cohesión y acoplamiento Patrones de diseño típicos


Diseño

No es un simple epílogo del análisis Para el Proceso Unificado es más importante Para Extreme Programming es fundamental

Revalorizado en OO Incluye:

Las clases de diseño y las de implementación, con su estructura, operaciones y semántica.

Las distintas arquitecturas del sistema.


Diseño de clases

Clases de diseño Si bien describen conceptos de alto nivel, como

las clases de análisis, no pertenecen al dominio del problema sino al de la solución.

Clases de implementación Surgen por necesidades algorítmicas, como un

tipo de vector o árbol. Para encontrarlas se aplican los conocimientos

de algoritmos y estructuras de datos.

Veremos más adelante.


Arquitecturas (I)

De componentes Simplemente arquitectura. Idea de un diseño de sistema que consiste en

una descripción de sus principales componentes de software y sus interacciones.

Generalmente basada en patrones. De hardware

Despliegue de los distintos componentes en los nodos de hardware.

De conectividad Protocolos y dispositivos a usar.


Arquitecturas (II)

De datos Estructura de las bases de datos y la

persistencia.

Software Lenguajes, herramientas y nomenclatura que

se van a utilizar en la programación.

Interfaz de usuario Tipo de IU, elementos principales en cada caso,

relaciones entre ellos y normas de usabilidad.


Arquitecturas y UML (I)

Consulta Catálogo Intranet Sistema Compras

Servicio Web CatálogoPáginas JSP

Clases de Negocio Catálogo (Java)

Sistema Ventas

iCatalogo

Interfaz Web XML SOAP

Base de datos de Catálogo

Diagrama de componentes


Arquitecturas y UML (II)

Diagrama de despliegue

Servidor Base de Datos

Servidor de Aplicaciones

Servidor Web

Servidor ComercialPC Empleado

Consulta Catálogo Intranet

Sistema Compras

Servicio Web CatálogoPáginas JSP

Clases de Negocio Catálogo (Java)

Sistema Ventas

HTTP

Ethernet

HTTP

Ethernet

Base de Datos Catálogo


Patrones de arquitectura

Separación garantiza posibilidad de cambios

Clásicos MVC 3 capas N capas

Especializados Sun para J2EE MS para aplicaciones distribuidas en .NET


Patrón MVC

Ideal para aplicaciones stand-alone, con mucha IU

Basada en patrón Observador


Patrón de 3 capas

Interfaz de usuario

Modelo de negocio

Acceso a datos

Interfaz de usuario

Modelo de negocio

Acceso a datos

Ideal para aplicaciones distribuidas


Patrón de Sun para J2EE


Patrón de MS para .NETInterfaz de usuario

Modelo de negocio

Acceso a datos

Seguridad

Adm

inistración Operativa

Com

unicación

Interfaz de usuario

Modelo de negocio

Acceso a datos

Seguridad

Adm

inistración Operativa

Com

unicación

Seguridad

Adm

inistración

Com

unicación

Componentes de la IU

Componentes de procesos de la IU

Servicios de IU

Flujos delmodelo

Componentesdel modelo

Entidadesdel modelo

Componentes lógicosde acceso a datos

Agentes deservicios

Seguridad

Adm

inistración

Com

unicación

Componentes de la IU

Componentes de procesos de la IU

Servicios de IU

Flujos delmodelo

Componentesdel modelo

Entidadesdel modelo

Componentes lógicosde acceso a datos

Agentes deservicios


Bases del diseño de clases

Una buena arquitectura. Buenas prácticas de diseño y

programación. Patrones de diseño.

Eckel: “Un diseño termina cuando no se pueden

extraer más cosas del mismo.” “Las tareas más habituales se deben poder

hacer de una forma bien sencilla.”


Clases

Cada clase con un propósito simple y claro: una clase por abstracción y una

abstracción por clase.

Separar las dependencias de una plataforma en una clase aparte.


Patologías en diseño de clases

Clases con nombres verbales: No se supone que una clase hace algo, sino

que provee un conjunto de servicios. Clases sin métodos. Clases que no introducen nuevos métodos

ni los redefinen. Sólo heredan.

Clases que se refieren a varias abstracciones: Se deberían dividir en varias.


Clases de asociación

Para representar atributos o comportamiento de las asociaciones.

Persona Empresa

periodo : Date

Empleo

* 0..1


Cohesión y acoplamiento

Cohesión: Cada módulo haga una sola cosa simple.

Acoplamiento: Independencia entre módulos.

Asegurar bajo acoplamiento y alta cohesión en: Métodos Clases Paquetes

Algunos patrones ayudan.


Interfaces de clases (I)

Es lo que ve el cliente Más clara Más consistente Más simple Más intuitiva

No quitar funcionalidad En Java: /** @deprecated */ “privatizar” lo más posible


Interfaces de clases (II)

Implementar operaciones canónicas Comparable Serialización, toString() Clonación

Pocos parámetros No incluir opciones en métodos que realizan

acciones: Hacerlo en el constructor. O en forma sucesiva:

documento.establecerHoja(A4);

documento.establecerColor(rojo);

documento.imprimir();


Atributos

Atributos deberían mostrar sólo estado y los métodos sólo comportamiento.

No abusar de la herencia para expresar estado: el color de una figura es un atributo.

Estado condicionado por los invariantes de clase: Se expresan como restricciones entre atributos. Conviene separar atributos vinculados en una clase

aparte que controle el cumplimiento de los invariantes.

Cuestiones de eficiencia nos pueden llevar a que no mantengamos siempre los invariantes de la clase.


Métodos

Ojo con métodos con grandes switch en los que se hace una cosa u otra en base al valor de un atributo: if (unaFigura.getClass() == Elipse.class)

(Elipse)unaFigura.dibujar();

else if (unaFigura.getClass() == Poligono.class)

(Poligono)unaFigura.dibujar();

Habría que analizar el uso de herencia y polimorfismo.

O sobrecarga.


Jerarquías (I)

Poner la mayor parte de los atributos y métodos lo más arriba que se pueda: para evitar luego definiciones duplicadas.

Si una porción de código se repite en muchas clases hermanas, habría que generar un método y ponerlo en la clase base.

Se puede generar un ancestro de todas las clases que tengan código en común. Sólo recomendable si se puede establecer la relación

“es un”.


Jerarquías (II)

Evitar generalizar todo lo que parezca generalizable de entrada. Primero debemos resolver el problema que tenemos

entre manos de la manera lo más simple posible.

Una nueva clase descendiente debe añadir o redefinir un método (modificar la interfaz). Si no, no es necesaria. Riesgo de complicar la jerarquía sin un fin práctico. Tentación de especializar una clase en “varones” y

“mujeres” en vez de agregar un atributo booleano. Las jerarquías deben ayudar a dominar la complejidad,

no a complicarla.


Jerarquías (III)

La herencia se debe usar sólo cuando la relación entre los conceptos sea permanente. Patrón “Estado abstracto” o “State”.

Es más sencillo describir una jerarquía de lo general a lo particular.

Pero esto no siempre se aplica a la construcción: Jerarquía construida por demanda.

Generalizaciones que surgen al descubrir atributos o métodos en común en clases ya construidas.

Sí para clases adquiridas.


Excepciones a la herencia (I) Aves como animales voladores.

• ¿Pingüinos, gallinas, etc.? Idiomas de Europa como indoeuropeos.

• ¿magiar, finés y turco?

El uso de herencia con excepciones es una práctica cuestionable. Utilizar subclases para expresar las

excepciones. Pero las clasificaciones con subclases no

permiten excepciones por diferentes categorías.• No voy a poder clasificar a las aves también como

americanas y europeas sin caer en herencia repetida.


Excepciones a la herencia (II)

Pocas soluciones en el terreno práctico. Herencia múltiple, en los lenguajes que la

manejan.

Interfaces cuando las excepciones se dan a

nivel de métodos.

Caso de discusión: ¿La circunferencia es una elipse con un radio

menos? ¿Cómo lo manejamos?


Condiciones anormales (I)

Una excepción indica un error de

ejecución.

Mala idea elevar una excepción si no hay error.

Por ejemplo, si en una búsqueda no se

encontró el valor buscado.

Máxima: “Cuando todo falle, lance una

excepción”.


Condiciones anormales (II)

“Un parámetro de error consume menos recursos”.

No nos guiemos por microeficiencias: privilegiar la robustez y la seguridad.

Las excepciones nos obligan a hacer algo con ellas: chequeo de condiciones lógicas puede evitarse,

dando la impresión de que no ha habido un error cuando en verdad lo hay.

Máxima del diseño robusto: “Nunca se debe dar la impresión de que no pasó nada cuando algo ha fallado”.


Condiciones anormales (III)

Una implementación de clase debería venir con

las excepciones que puede disparar. Ponerlas en el mismo paquete.

Cuando se produce una excepción luego de

capturar recursos, a veces debemos liberarlos. El recolector de basura se va a ocupar de la memoria.

El resto los debe liberar el programador.

En el bloque finally.

Buena práctica: liberar en orden inverso a la adquisición.


Diseño por contrato

Invento de Meyer.

Hay un contrato entre implementador y cliente basado en: Invariantes de clase.

Precondiciones de métodos.

Postcondiciones de métodos.

Implementado directamente en Eiffel. Facilidad para pasar de diseño a implementación.

Se centra más en qué hacen las clases que en cómo se hace.


Patrones de diseño

Solución a un problema en un contexto. Indican cómo utilizar clases y objetos de formas

conocidas y estudiadas para adaptarlos a la resolución de parte de un

problema o a un escenario particular.

Reutilización llevada al diseño. Se aplica a una sociedad de clases. Se resuelve mediante una colaboración:

aspectos estructurales, aspectos de comportamiento.


Patrones de diseño: usos

Colaboraciones probadas previamente. Fácil interpretación de diseños ya conocidos. Completitud frente a las soluciones caseras. Implementación directa

sin análisis y diseño complejos.

Facilidad de separar los aspectos que cambian de los que no cambian.

Lenguaje común para construir software y la enseñanza, el aprendizaje y el trabajo en grupos.


Antipatrones de diseño

Diseños que han arruinado proyectos.

Para construir nuevos patrones.

Para no caer en ellos.

Interesante:http://www.hillside.net/patterns

http://www.enteract.com/~bradapp/docs/patterns-

intro.html


Falsos patrones de diseño

Reutilización de código.

Soluciones a problemas puntuales. Generalmente se llega por buscar patrones a la fuerza.

Soluciones evidentes.

Interpretaciones de problemas sin su solución.

Soluciones que llegan a la implementación. Herramientas CASE modernas.

Hay excepciones: Singleton, Observador, Iterador, etc.


Observador (I)

Paradigma de publicador - suscriptor. Para manejo de eventos. Para MVC. Para mensajería.

Hay dos objetos: Observador. Observado u Observable (pueden ser varios).

Cambios en Observado provocan cambios en Observador.


Observador (II)

Implementado en java.util.

Clase o interfaz

Método Funcionalidad

Observable void setChanged() Marca que el objeto ha sido modificado. La función hasChanged va a devolver true.

Observable boolean hasChanged() Indica si el objeto ha sido modificado.Observable void clearChanged() Marca que el objeto no ha cambiado, o bien ya notificó a los observadores.

La función hasChanged va a devolver false.Observable void notifyObservers

(Object novedad)Si el objeto ha cambiado (hasChanged devuelve true), invoca a los métodos update de los observadores.

Observable void notifyObservers() Equivale a notifyObservers(null)Observable void addObserver

(Observer o)Agrega un observador a la lista.

Observable void deleteObserver (Observer o)

Elimina un observador de la lista.

Observable void deleteObservers (Observer o)

Elimina todos los observadores de la lista.

Observable int countObservers() Devuelve la cantidad de observadores de la lista.Observer void update (Observable

o, Object novedad)Es llamado automáticamente desde el notifyObservers de Observable cada vez que hay un cambio. Debe implementarse en la clase observadora.


Observador (III)

Usando java.util.*: Definir una clase descendiente de Observable:• que ante determinados cambios, invoque los

métodos setChanged y notifyObservers. En general los métodos de Observable

no se redefinen. Construir una clase que implemente Observer,• implementando el método update.


Observador (IV)

Observador consulta Observado cada tanto y se actualiza. Observador debe poder acceder a Observado. Sistemas de simulación. Sistemas que se manejan en base al tiempo.

“Estilo Java”: el observado envía un mensaje de actualización cada vez que modifica su estado. Sólo notifica cuando hay modificación digna de notificarse. El observado conoce a sus observadores y lo que necesitan.

Observado envía sólo una notificación de que hubo cambios. Observadores deben consultar al observado para ver qué cambió. Menos acoplado en un sentido y más en el otro.


Decorador (I)

Objetos en capas, para agregar responsabilidades dinámicamente.

Ejemplo: un modelo de automóvil en tres variantes, llamadas

sedán, coupé y familiar, y cada variante tiene un precio básico de venta;

a cada variante se le pueden agregar opcionales como techo corredizo, aire acondicionado, sistema de frenos ABS, motor diesel y motor de 16 válvulas, y cada uno tiene un precio que se suma al básico;

cada auto podrá tener ninguno, uno o más opcionales.

¿Cómo calculamos los precios?


Decorador (II)

Solución tradicional: herencia. Una clase para cada combinación

posible. Con 3 variantes y 5 opcionales, las

combinaciones posibles son 3 x 25 = ¡96 clases!

Solución con Decorador: Diseño inicial más complejo. Más escalable.


Decorador (III)

«interface»ComponenteCliente

Sedan Familiar Coupe Decorador

TechoCorredizo AireAcondicionado ABS Diesel Valvulas16


Decorador (IV)

public interface Componente {

double costoTotal();

}

public class Sedan implements Componente {

private double costo = 30000.0;

public double costoTotal() {

return costo;

} }

public class Familiar implements Componente {



return costo;

} }


Decorador (V)public abstract class Decorador implements Componente {

protected Componente basico;

public Decorador (Componente comp) { basico = comp; }


return basico.costoTotal();

} }

public class TechoCorredizo extends Decorador {


public TechoCorredizo (Componente comp) { super(comp); }


return basico.costoTotal() + costo;

} }

public class AireAcondicionado extends Decorador { …


Decorador (VI)

Instanciación:Componente a = new TechoCorredizo(

new AireAcondicionado(new Sedan()));

Un nuevo opcional Con herencia, 96 clases más Con Decorador, una clase más

Cambio del precio de un opcional Con herencia, 48 cambios Con Decorador, 1 cambio


Singleton

Clase con una instancia única. Fácil de llevar a código:

final class Singleton {

private Object valor;

private static Singleton u = new Singleton ();

private Singleton() { valor = null; }

public static Singleton obtenerUnico() { return u; }

public Object obtenerValor() { return valor; }

public void darValor (Object x) { valor = x; }

}


Pool de objetos

Extensión a Singleton para generar una cantidad finita de instancias.

Se debe poder eliminar objetos y colocarlos de nuevo en el pool.

Muy útil en aplicaciones distribuidas: conexiones a bases de datos referencias a instancias transacciones


Proxy (I)

Apoderado o sucedáneo (surrogate). Un objeto que hace de interfaz de otro.

Con métodos similares. Los clientes tratan con un intermediario.

Aplicaciones: Proxy remoto: el objeto objetivo está en un sistema remoto.

Suele servir como caché o copia local. Proxy virtual: no se crea el objeto objetivo sino hasta que sea

realmente necesario, porque es costoso hacerlo. Proxy de protección: para controlar el acceso. Proxy de sincronización: para gestionar acceso de varios

clientes.


Proxy (II)

Cliente Proxy Objetivo

a()

preProceso()

a()

postProceso()

a()


Proxy (III)

+a()+b()+c()

«interface»BaseProxy

+a()+b()+c()+preProceso()+postProceso()

Proxy

+a()+b()+c()

Objetivo

1

1

1

1

Cliente


Resumen

El diseño ha sido revalorizado con la OO Incluye diseño de arquitecturas y de clases Importante conocer los patrones de arquitectura Diseño debe mantenerse sencillo y claro Las clases deben tener estado y comportamiento Nunca se debe dar la impresión de que no pasó

nada cuando algo ha fallado. Los patrones llevan la reutilización al diseño. No son soluciones evidentes. Están suficientemente probados.


Qué sigue

Diseño de interfaces de usuario Vuelta a Java

Concurrencia y persistencia Aplicaciones distribuidas, web y demás ¡Fin!


Bibliografía y otras fuentes

Para MVC: http://www.enode.com/x/markup/tutorial/mvc.html

http://www.cica.es/formacion/JavaTut/Apendice/mvc.html

Para arquitecturas relacionadas con J2EE: http://java.sun.com/j2ee/tutorial/

Para arquitecturas relacionadas con .NET: http://www.microsoft.com/resources/practices/

Muchas Gracias.

Carlos Fontela, 2004

algoritmos y programación iii 8. diseño, patrones, arquitecturas carlos fontela, 2004

Documents