as tema 3 - avellano.usal.esavellano.usal.es/~mmoreno/astema3.pdf · análisis y diseño orientado...

Análisis de Sistemas

TEMA 3TEMA 3Métodos de desarrollo de softwareDesarrollo orientados a objetosDesarrollo orientados a objetos

María N. Moreno GarcíaDepartamento de Informática y AutomáticaUniversidad de SalamancaUniversidad de Salamanca


ContenidosContenidos

1. Introducción2. Desarrollo de software orientado a aspectos3. Desarrollo de software orientado a servicios4. Desarrollo de software orientado a objetos5. Métodos orientados a objetos

6. Reutilización

7. Patrones de diseño

8. Portabilidad

9. Interoperabilidad

Métodos de desarrollo de software 2


Introducción (I)Introducción (I)Principales metodologías de desarrollo de software

Métodos estructuradosMétodos estructuradosDescomposición funcional del sistemaConstrucción de modelos de datosRepresentación del flujo de informaciónTransformación de diagramas de flujo de datos en estructura modular de programamodular de programa

Métodos orientados a objetos: Organización del software como una colección discreta de objetos que incorporan datos (atributos) y comportamiento (operaciones o procedimientos)(atributos) y comportamiento (operaciones o procedimientos)Desarrollo orientado a aspectos (AOSD) [Elrad et al., 2001]

Enfoque metodológico para especificar, diseñar y construir q g p p , yaspectosAspectos: definen los intereses generales que ejercen un impacto a través de la arquitectura del software


q


Introducción (II)Introducción (II)Otros enfoques de desarrollo de software

Desarrollo basado en componentesDesarrollo basado en componentesDiseño y desarrollo de aplicaciones (distribuidas) basadas en componentes software reutilizablesReutilización:Reutilización:

ArquitecturasMarcos de trabajoPatrones de diseñoPatrones de diseñoComponentes

Plataformas: ActiveX/OLE (COM), Enterprise Bean (JavaBeans), Orbix (CORBA)…( )

Desarrollo orientado a serviciosCreación de sistemas a partir de servicios autónomosArquitectura SOA (Service Oriented Architecture): infraestructuraArquitectura SOA (Service Oriented Architecture): infraestructura de alto nivel para crear soluciones basadas en serviciosServicios: entidades que se implementan, versionan y administran de forma independiente


p


Desarrollo de software orientado a aspectos (I)Desarrollo de software orientado a aspectos (I)

El desarrollo de software orientado a aspectos (Aspect Oriented Software Development AOSD) tiene como objetivo mejorar laSoftware Development, AOSD) tiene como objetivo mejorar la expresividad de los paradigmas orientados a objetos

Desarrollo de software mediante la separación de propósitos (aspectos) ifi ió d l l i t lly especificación de las relaciones entre ellos

Composición posterior de propósitos mediante un mecanismo adecuado para formar un sistema coherente

Características del software producidoComprensibleFlexibleFlexibleBuena modularidad

Ventajas:Facilidad de mantenimientoAdaptabilidad



Desarrollo de software orientado a aspectos (II)Desarrollo de software orientado a aspectos (II)Ingeniería de componentes orientada a aspectos [Grundy, 2000] [Grundy y Hosking, 2004]000] [G u dy y os g, 00 ]

Utiliza el concepto de capas horizontales a través de componentes de software descompuestos en forma vertical, llamados aspectos para caracterizar propiedades generales dellamados aspectos, para caracterizar propiedades generales de los componentes Aspectos:

Interfaces de usuarioInterfaces de usuarioTrabajo en colaboraciónDistribuciónP i t iPersistenciaGestión de memoriaProcesamiento de transaccionesSeguridad ...

Los componentes pueden proporcionar o requerir uno o más “detalles de aspecto” relacionados con un aspecto particular



Desarrollo de software orientado a aspectos (III)Desarrollo de software orientado a aspectos (III)

Aspecto de actualización de pantalla


p p


Desarrollo de software orientado a aspectos (IV)Desarrollo de software orientado a aspectos (IV)

Ejemplo de lenguaje de programación orientado a aspectos (AspectJ)



Desarrollo de software orientado a servicios (I)Desarrollo de software orientado a servicios (I)

Arquitectura SOACapas independientesIntegración de servicios implementados en diferentes lenguajes y alojados en diferentes plataformasy j pSoporte a servicios Web

TecnologíasXML ( Xt ibl M k L ) f t tá d dXML ( eXtensible Markup Language): formato estándar de representación de los datosSOAP ( Simple Object Access Protocol)

Protocolo estándar para transmisión de mensajes entre servicios Formato de mensajes común y extensible

WSDL (Web Services Description Language): lenguaje paraWSDL (Web Services Description Language): lenguaje para descripción de servicios común y extensible UDDI (Universal Description, Discovery and Integration): estándares para describir y descubrir servicios


estándares para describir y descubrir servicios


Desarrollo de software orientado a servicios (II)Desarrollo de software orientado a servicios (II)

Servicios Web

Aplicaciones programables cuya lógica es accesible usando protocolos de Internet estándaresprotocolos de Internet estándares

Sus clientes son otras aplicacionespRepresentan funcionalidad en cajas negras que pueden reutilizarse sin preocuparse por su implementaciónS did í t l W b bi f t d d tSon accedidos vía protocolos Web ubicuos y formatos de datos como HTTP y XMLUna interfaz de servicio Web puede implementarse sobre p pcualquier plataforma y en cualquier lenguaje de programación



Desarrollo de software orientado a servicios (III)Desarrollo de software orientado a servicios (III)

SOAP (Simple Object Access Protocol) :

Proporciona la definición de información de intercambio basada en XML en entornos distribuidos y heterogéneos Define la manera de realizar llamadas a procedimientos remotos usando HTTP como protocolo de comunicación subyacenteL ifi ió SOAP t d t tLa especificación SOAP consta de tres partes:

SOAP envelop: normas sobre el contenido de los mensajesReglas de codificación SOAP: mecanismos usados en elReglas de codificación SOAP: mecanismos usados en el intercambio de instancias de tipos de datos definidos en aplicacionesR t ió SOAP RPC i d lRepresentación SOAP RPC: convenciones usadas en las llamadas a procedimientos remotos



Desarrollo de software orientado a servicios (IV)Desarrollo de software orientado a servicios (IV)

<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">env:Envelope xmlns:env http://www.w3.org/2002/06/soap envelope

<env:Header><m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2002/06/soap-envelope/role/next" env:mustUnderstand="true">

<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>m:reference uuid:093a2da1 q345 739r ba5d pqff98fe8j7d /m:reference<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>

</m:reservation><n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2002/06/soap-

envelope/role/next" env:mustUnderstand="true">envelope/role/next env:mustUnderstand true<n:name>John Q. Public</n:name>

</n:passenger></env:Header><env:Body>env:Body

<p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"><p:departure> <p:departing>New York</p:departing> <p:arriving>Los Angeles</p:arriving> ...

</p:itinerary>/p e a y<q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging>

</env:Body></env:Envelope>


Ejemplo de mensaje SOAP


Desarrollo de software orientado a servicios (V)Desarrollo de software orientado a servicios (V)

WSDL (Web Services Description Language) (I)

Lenguaje para la descripción de interfaces de servicios Web basado en XML

WSDL proporciona a los proveedores de servicios una manera de describir el formato básico de las peticiones de servicio sobrede describir el formato básico de las peticiones de servicio sobre diferentes protocolos y codificacionesUn archivo WDSL es un documento XML que describe un conjunto de mensajes SOAP y la forma en la que éstos se intercambian. En él se definen:

El contenido de un mensajeEl contenido de un mensajeEl lugar en el que está disponible el servicioEl protocolo de comunicación utilizado



Desarrollo de software orientado a servicios (VI)Desarrollo de software orientado a servicios (VI)

WSDL (Web Services Description Language) (II)Los servicios se definen como una colección de puntos de red o puertosUn documento WSDL usa los siguientes elementos en laUn documento WSDL usa los siguientes elementos en la definición:

Tipos: contenedor para definiciones de tipos de datosMensaje: definición abstracta y tipada de los datos que se comunicanOperación: descripción abstracta de una acción soportada por el p p p pservicioEnlace: especificación de un formato de datos y un protocolo concreto para un tipo de puerto particularconcreto para un tipo de puerto particularPuerto: un punto de red simple definido como una combinación de un enlace y una dirección de redServicio: Colección de puertos relacionados


Servicio: Colección de puertos relacionados


Desarrollo de software orientado a servicios (VII)Desarrollo de software orientado a servicios (VII)

UDDI (Universal Description, Discovery and Integration) (I)

Framework abierto, independiente de la plataforma para describir servicios e integrar servicios de negocio utilizando Internet

Características de UDDI

Describe servicios Web

Describe negocios y los servicios que soportan

Independiente de la plataforma y del modelo de programación p p y p g

Usa XML, HTTP y SOAP

Libre en Internet



Desarrollo de software orientado a servicios (VIII)Desarrollo de software orientado a servicios (VIII)

UDDI (Universal Description, Discovery and Integration) (II)

4.compañías SW, estándares y 1.

Mercados, motores de búsqueda y aplicaciones de

programadores pueblan el registro con descripciones de diferentes tipos de servicio

Registro de negocios UDDI

búsqueda y aplicaciones de negocio consultan el registro para descubrir servicios en otras compañías

2.

Registro de negocios UDDI

Registros de tipo de servicio

Registros de negocio

La empresas pueblan el registro

5.

3. UBR asigna un identificador único a cada registro de servicio

tipo de serviciode negociopueblan el registro con descripciones de los servicios que ellas soportan Los negocios usan estos datos para

realizar más fácilmente la


y de negocio integración entre ellos sobre la Web


Desarrollo de software orientado a servicios (IX)Desarrollo de software orientado a servicios (IX)

Registro de información en UDDI

Los negocios registran su Páginas blancas

Describen los datos de la empresa (nombre, dirección,

f ó d )g g

información.Una entrada de información en UDDI en un documento

blancas

Páginas

información de contacto ...)

Describen las categorías industriales basadas enen UDDI en un documento

XML que describe un negocio y los servicios que ofrece. Tiene tres partes

Páginasamarillas

Pá i

industriales basadas en taxonomías estándares (NAICS)

pPáginasverdes

Describen la interfaz del servicio

Estándares, programadores y negocios registran información sobre sus tipos de servicios

Registros de tipo de servicio


p p


Desarrollo de software orientado a objetos (I)Desarrollo de software orientado a objetos (I)Principios

Desarrollo de aplicaciones usando modelos basados en conceptos del mundo realreal Organización del software como una colección discreta de objetos que incorporan datos (atributos) y comportamiento (operaciones o procedimientos)p )Los objetos se comunican a través del paso de mensajes. El objeto receptor del mensaje ejecuta una acción (operación)Modelo objeto: abstracción, encapsulación, jerarquía, modularidad,

li fipolimorfismo...

Análisis y diseño orientado a objetosEn el análisis se presta especial atención a encontrar y describir objetos enEn el análisis se presta especial atención a encontrar y describir objetos en el dominio del problema

Descripción de los procesos del dominio (casos de uso)Definición de un modelo del dominio: descripción del dominio desde la

ti d l l ifi ió d bj t (id tifi ió d t t ib tperspectiva de la clasificación de objetos (identificación de conceptos, atributos y asociaciones significativas)

Durante el diseño se presta especial atención a la definición de objetos software y en como se colaboran para satisfacer los requisitos


y p qVista dinámica: colaboraciones entre objetosVista estática: diagramas de clases de diseño


Desarrollo de software orientado a objetos (II)Objetos (I)Unidades básicas de construcción de software: elementos autónomos deinformación que proporcionan una serie de servicios sobre la estructurainformación que proporcionan una serie de servicios sobre la estructurainterna que implementan

Comportamiento visibleCaracterísticasObjeto

Estado interno

CaracterísticasEstado: Conjunto de propiedades o atributos que tiene el objeto (estructura estática) junto con los valores que pueden asumir cada una de estas

Representación del estado y comportamiento de un objeto

valores que pueden asumir cada una de estas propiedades (estructura dinámica)

Comportamiento: Forma en que actúa un objeto al recibir un estímulo externo (mensaje). Cada unidad de comportamiento se llama operación. Existen cuatro tipos

Modificación: alteración del estado del objetoSelección: acceso al estado del objetoConstrucción: creación de un objeto e iniciación de su estadoDestrucción: liberación del estado de un objeto

Identidad: Propiedad característica de un objeto que le distingue de todos los demás


Encapsulación: Los atributos y operaciones se reúnen en una entidad única: el objeto


Desarrollo de software orientado a objetos (III)Objetos (II)

Restricciones de realización: características relacionadas con el entorno de realizaciónentorno de realización

Persistencia de objetos: capacidad de un objeto de trascender el tiempo o el espacio. Un objeto persistente conserva su estado en un sistema de almacenamiento permanente, pudiendo realizar las operaciones

Pasivación del objeto: parar el proceso que lo ha creado sin perder la información representada por el objetoActivación del objeto: reconstrucción del objeto por otro proceso

Transmisión (migración) de objetos: envío de objetos por un medioTransmisión (migración) de objetos: envío de objetos por un medio de comunicación cualquiera de un espacio de direccionamiento a otroObjetos espejo: alternativa a la transmisión de objetos mediante la cual se puede manipular un objeto espejo como si se estuvieracual se puede manipular un objeto espejo como si se estuviera manipulando un objeto remoto con el que está sincronizado



Desarrollo de software orientado a objetos (IV)Objetos (III)

U bj t U lUn objeto Un clon

Soporte de comunicaciónSoporte de comunicación

Transmisión de objetos

U j U bj

Contexto A Contexto B

Un espejo Un objeto

Un cliente

Métodos de desarrollo de software 21Objeto definido en el contexto B y su espejo en el contexto A


Desarrollo de software orientado a objetos (V)Comunicación entre objetos (I)

Los sistemas de objetos interactúan para realizar las funciones de la aplicaciónSegún la naturaleza de las interacciones se puede describir el comportamiento de los objetos. Existen tres clases de comportamiento

Actores: objetos en el origen de una interacción, son siempre objetos activosServidores: son siempre destinatarios de los mensajes. Suelen ser objetos pasivos que esperan que otro objeto requiera sus servicios Elobjetos pasivos que esperan que otro objeto requiera sus servicios. El objeto que solicita el servicio actúa como clienteAgentes: pueden interactuar con otros objetos en todo momento, por iniciativa propia o como consecuencia de una solicitud externa. Formaniniciativa propia o como consecuencia de una solicitud externa. Forman la base del mecanismo de delegación

Un actor Un servidor

Un agente


Categorías de objetos según su comportamiento


Desarrollo de software orientado a objetos (VI)Comunicación entre objetos (II)

Encaminamiento

Servidor 1

Encaminamiento dinámico

Un cliente Servidor 2Un agente

Servidor 3

Ilustración del mecanismo de delegación



Desarrollo de software orientado a objetos (VII)Comunicación entre objetos (III)

Concepto de mensaje: unidad de comunicación entre objetos. Asegura la delegación de las tareasAsegura la delegación de las tareasGarantiza el respeto de las restricciones

Un mensaje jTiene un objeto emisor (expedidor) y un objeto receptor (destinatario) Se puede implementar como una llamada a una operación o como una

ñ lseñalAgrupa los flujos de control y los flujos de datos en una entidad única

Dato ADato B

Objeto 1 Objeto 2Dato B

Mensaje


Flujo de control y de datos del mensaje


Desarrollo de software orientado a objetos (VIII)

Tipos de mensajes: describen diferentes formas de comunicación entre objetos

Comunicación entre objetos (IV)

entre objetos

Síncrono: el objeto emisor se bloquea hasta que el destinatario acepta el mensaje. Generalmente es una llamada a un métodojAsíncrono: el expedidor envía el mensaje sin saber cuándo, ni siquiera si el mensaje será tratado por el destinatario. No se interrumpe la ejecución del expedidor. Permite la ejecución concurrenteDe creación: crea un nuevo objetoPerdido: se conoce la emisión del mensaje por el objeto emisor pero no hay recepción del mensajeEncontrado: se conoce al receptor del mensaje pero no al emisorRetorno: respuesta del receptor de un mensaje al emisor de dicho mensajeBalking: sólo se envía si el receptor está preparado para aceptarloTime-out: se cancela si el receptor no lo maneja en un tiempo especificado



Desarrollo de software orientado a objetos (IX)Comunicación entre objetos (V)

Mensaje síncrono

Mensaje asíncrono

Mensaje de creación

Mensaje asíncrono

Mensaje encontrado

Mensaje perdido

Mensaje de retorno

Tipos de mensajes: notación de UML



Desarrollo de software orientado a objetos (X)Comunicación entre objetos (VI)

:ControladorEntorno:Calentador encender()activar()

:ControladorEntorno:Calentador

<<time-out>>estaPreparado()

fallo()

:Luzreiniciar()

:Refrigerador

Ejemplo de sincronización



Desarrollo de software orientado a objetos (XI)

Una clase describe un conjunto de objetos con propiedades similares, relaciones comunes con otros y una semántica común

Clases (I)

relaciones comunes con otros y una semántica comúnLos objetos de una clase comparten además de atributos y comportamiento (operaciones), un propósito semántico común. La interpretación de la semántica depende de la aplicaciónLas clases son abstracciones que permiten crear categorías de objetos. Todos los objetos son ejemplares o instancias de una claseobjetos. Todos los objetos son ejemplares o instancias de una claseEl proceso de crear objetos concretos a partir de una clase se denomina instanciación

Nombre de clase

AtributosAtributos

Operaciones ( )


Representación gráfica de las clases


Desarrollo de software orientado a objetos (XII)Clases (II)

La descripción de las clases se divide en dos partesEspecificación: describe el ámbito de definición y las propiedades de lasEspecificación: describe el ámbito de definición y las propiedades de las instanciasRealización: describe cómo se realiza la especificación, ya que contiene el cuerpo de las operaciones y los datos necesarios para suel cuerpo de las operaciones y los datos necesarios para su funcionamiento

La separación entre especificación y realización eleva el nivel de abstracción: las características destacables se describen en laabstracción: las características destacables se describen en la especificación y los detalles en la realizaciónInterfaz de una clase: descriptor de las operaciones visibles externamente de una clase

No ofrece implementación para ninguna de las operacionesSe utiliza para especificar un servicio que ofrece una claseSe utiliza para especificar un servicio que ofrece una claseLa interfaz da nombre a un conjunto de operaciones que cooperan para realizar un comportamiento de interés lógico

En Java:


En Java: interface Interfaz { … }


Desarrollo de software orientado a objetos (XIII)Clases (III)

La encapsulación facilita la ocultación de la información al definir dif t i l d i ibilid d ibilid ddiferentes niveles de visibilidad o accesibilidadNiveles de visibilidad:

Nivel privado: visibilidad para la propia clasep p p pNivel protegido: visibilidad para la clases derivadasNivel público: visibilidad para todas las clases

Reglas de visibilidad

+ atributo público# ib id# atributo protegido- atributo privado

+ operación pública ( )# operación protegida ( )

R t ió d l i l d i ibilid d l l

# operación protegida ( )- operación privada ( )


Representación de los niveles de visibilidad en las clases


Desarrollo de software orientado a objetos (XIV)Clases (IV)

Marcador

nDigitos: int

public class Marcador

{- nDigitos: int- digitos: Vector

{

private Vector digitos;

private int nDigitos;+ digito (n:int)# registroDigito (n:int):boolean

p g ;

public void digito (int n);

protected boolean registroDigito (int n);

Representación de los niveles de

}

Implementación en Java de losvisibilidad de los miembros de la

clase Marcador

Implementación en Java de los niveles de visibilidad de los miembros

de la clase Marcador



Desarrollo de software orientado a objetos (XV)Relaciones entre clases (I)

Asociación: conexión semántica bidireccional entre clases.Un enlace es una conexión física o conceptual entre instancias

Juan López trabaja para IBMUna asociación describe un grupo de enlaces con una estructura y una semántica comunes

Persona trabaja para empresa

Empresa

public class Empresa

{Empresa

Persona*

// VectorPersonas es una especialización de

// Vector (clase Java para arrays dinámicos)

private VectorPersonas emplea;

emplea

Persona private VectorPersonas emplea;

. . .

}


Representación UML e implementación Java de asociaciones entre clases


Desarrollo de software orientado a objetos (XVI)Relaciones entre clases (II)

Características de las asociacionesMultiplicidad de la asociación especifica el número de instancias de la clase que pueden estar relacionadas con una única instancia de una clase asociadaAsociaciones cualificadas: tienen un atributo cualificador que permite distinguir un conjunto de objetos del extremo muchosClase asociación: las asociaciones se modelan en forma de clase

Empresa PersonaidPersona

public class Empresa{

cualificadorprivate String idPersona;public String getName ( ) {

Persona p = DB.getPersona (idPer);Empresa Persona

Trabajo clase asociación

p g ( )return p.getName ( );

}}


asociación }

Implementación de asociación cualificada en Java


Desarrollo de software orientado a objetos (XVII)Relaciones entre clases (III)

Agregación: conexión bidireccional asimétrica. La agregación es una forma de asociación que permite representar relaciones del tipo amoforma de asociación que permite representar relaciones del tipo amo-esclavo, todo-partes o agregado-componentesCaracterísticas de la agregación

Transitividad: si A es parte de B y B es parte de C, entonces A es parte de CPropagación de operaciones (activación): aplicación automática de una p g p ( ) poperación a una red de objetosExisten agregados recursivos: contienen directa o indirectamente una instancia de esa misma clase de agregadog g

PersonaJefe

Empresa Servicio SecciónEmpleados

Agregación recursiva

Agregación tipoagregado-componentes


Agregación recursiva


Desarrollo de software orientado a objetos (XVIII)Relaciones entre clases (IV)

Composición: Relación semántica que describe una forma de agregación con un matiz fuerte de propiedad y de coincidencia de vida como partes de un todo

Las partes con una multiplicidad que no es fija pueden ser creadas después del objeto compuesto, pero una vez creadas ellas viven y mueren con él. Estas partes pueden ser también eliminadas antes de la muerte del objeto compuestoLa composición puede ser recursiva

- barraDeDesplazamiento [2]: Deslizador- titulo: Cabecera

public class Ventana

{

Ventana

- cuerpo: Panel

Ventana

1

private Deslizador barraDeDesplazamiento [2];

private Cabecera titulo;

private Panel cuerpo;

Deslizador Cabecera Panel1

1

12

p p

}


Representación de la relación de composición Implementación de la composición en Java


Desarrollo de software orientado a objetos (XIX)Relaciones entre clases (V)

Relaciones jerárquicas (I)La generalización consiste en factorizar los elementos comunes de unLa generalización consiste en factorizar los elementos comunes de un conjunto de clases en una clase más general llamada superclaseLa especialización permite capturar las particularidades de un conjunto de objetos no discriminados por las clases ya identificadas. Las nuevas características se representan en una subclase de las clases existentes

Métodos de desarrollo de software 36Generalización y especialización en una jerarquía de clases


Desarrollo de software orientado a objetos (XX)Relaciones entre clases (VI)

Relaciones jerárquicas (II)

L h i l i l l l fi d iLa herencia es el mecanismo por el que las clases refinadas incorporan las características de una o más clases superiores en la estructura jerárquica

Una subclase heredará atributos y operaciones de una superclase que está más arriba en el árbol jerárquico y a su vez pueden incorporar nuevas características. Una subclase puede anular una característica de una superclase definiendo una característica de igual nombre

Una instancia de una subclase es simultáneamente una instancia de todas sus clases antecesoras (principio de sustitución)

Herencia simple es el tipo de herencia por la que una clase sólo puede tener una superclaseHerencia múltiple es aquélla que permite que una clase tenga más deHerencia múltiple es aquélla que permite que una clase tenga más de una superclase y que herede características de todos sus antecesores

Una misma característica que llegue por distintas vías se heredará una sola vez


vezEs necesario resolver la ambigüedad en la implementación


Desarrollo de software orientado a objetos (XXI)Relaciones entre clases (VII)

Relaciones jerárquicas (III)


Herencia simple y múltiple en una jerarquía de clases


Desarrollo de software orientado a objetos (XXII)Relaciones entre clases (VIII)

Relaciones jerárquicas (IV)

Clase abstracta: clase para la cual no se pueden crear instancias directas

Se utilizan para recoger características estructurales o de p gcomportamiento comunes a un conjunto de subclasesUna clase abstracta tiene que derivarse obligatoriamenteLas operaciones de la clase pueden ser abstractas: carecen deLas operaciones de la clase pueden ser abstractas: carecen de implementación


Clase abstracta y subclases


Desarrollo de software orientado a objetos (XXIII)Relaciones entre clases (IX)

Relaciones jerárquicas (V)Polimorfismo de inclusión o de

b t t l A i l {subclases: se produce cuando un servicio definido en una clase se redefine en alguna de sus subclases manteniendo la misma signatura

abstract class Animal {protected String nombre;abstract protected String comunica( );

}class Perro extends Animal {manteniendo la misma signatura {

protected String comunica ( ) {return "Guau, guau !!!";

}}class Gato extends Animal {{

protected String comunica ( ) {return "Miau, miau !!!";

}}class Ejemplo {

public static void main (String args[ ]) {Perro rufus = new Perro( );Gato bolita = new Gato( );System.out.println ("\nrufus dice:" +

rufus.comunica( ) );System.out.println ("\nbolita dice:" +

bolita.comunica( ) );}

}

Guau, guau!!! Miau, miau!!!


}

rufus bolita


Desarrollo de software orientado a objetos (XXIV)Análisis (I)

Definición de procesos del dominioDescripción de los principales requisitos funcionales del sistemaDescripción de los principales requisitos funcionales del sistemaSe pueden representar como casos de uso

Modelo del dominioTambién se denomina modelo conceptual, modelo de objetos del dominioy modelo de objetos del análisisMuestra clases conceptuales significativas en un dominio del problemaMuestra clases conceptuales significativas en un dominio del problema. Una clase conceptual podría expresarse en términos de su

Símbolo: palabras o imágenes que representan la claseIntensión: definición de la claseIntensión: definición de la claseExtensión: conjunto de ejemplos a los que se aplica la clase[Martin y Odell 1995]

Se representa por un conjunto de diagramas de clases en los que no seSe representa por un conjunto de diagramas de clases en los que no se define ninguna operación. Se muestran:

Objetos del dominio o clase conceptualesAsociaciones entre clases conceptuales


Asociaciones entre clases conceptualesAtributos de las clases conceptuales


Desarrollo de software orientado a objetos (XXV)Análisis (II)

Ejemplo: jugar una partida de dadosDefinición de procesos del dominio:

Un jugador recoge y lanza dos dados. Si el valor de las caras de los dados suman 7 gana, en otro caso pierde

Modelo del dominio:

Jugadornombre

DadovalorCara

Lanza1 2

Juega

1 2

JuegoDados

1

Incluye1



Desarrollo de software orientado a objetos (XXVI)Análisis (III)

Pasos para crear un modelo del dominio:Listar las clases conceptuales candidatasListar las clases conceptuales candidatas

Utilización de una lista de categorías de clases conceptualesIdentificación de frases nominales

Representar las clases en un modelo del dominioAñadir las asociaciones necesariasAñ di l t ib t i di ti i t t ib tAñadir los atributos necesarios y distinguir entre atributos correctos e incorrectosAñadir clases conceptuales de especificación cuando sea p poportuno

EspecificacionDelProductoProducto EspecificacionDelProductodescripcionprecioarticuloID

ArticulonumeroSerie

Describe1 *

Producto

descripcionprecioarticuloIDnumeroSerie


numeroSerie

Ejemplo de uso de clases de especificación


Desarrollo de software orientado a objetos (XXVII)Diseño (I)Diseño de objetos

Diseño de objetos con responsabilidadesj pResponsabilidad: contrato u obligación de un objeto en cuanto a su comportamientoTipos de responsabilidades: conocer y hacer

Realización de los casos de usoUna realización describe cómo se realiza un caso de uso particular en el modelo de diseño, en función de los objetos que colaboranSe representan mediante diagramas de interacciónSe representan mediante diagramas de interacción

Determinación de la visibilidad entre objetosVisibilidad es la capacidad de un objeto de ver o tener una referencia a otroFormas de visibilidad: de atributo de parámetro local y globalFormas de visibilidad: de atributo, de parámetro, local y global

Creación de los diagramas de clases de diseñoRepresentan las especificaciones de las clases e interfaces software. Contienen:

Clases, asociaciones y atributosC ases, asoc ac o es y a bu osInterfaces con sus operaciones y constantesMétodosInformación sobre los tipos de atributosNavegabilidad


gDependencias


Desarrollo de software orientado a objetos (XXVIII)Diseño (II)

Diseño de la arquitecturaDiseño de la arquitectura lógicaDiseño de la arquitectura lógica

Descripción del sistema en términos de su organización conceptual en capas, paquetes, frameworks, clases, interfaces y subsistemasArquitectura en capas: modelo general de n niveles para la arquitectura lógica. Capas básicas:

Presentación (interfaz): clases encargadas de interaccionar con elPresentación (interfaz): clases encargadas de interaccionar con el usuario y mostrar la informaciónDominio (negocio o procesamiento): clases que contienen la lógica de la aplicaciónaplicaciónAlmacenamiento: clases persistentes (base de datos y clases adicionales)

Uso de patrones de arquitectura y de diseñoUso de patrones de arquitectura y de diseño

Despliegue de la arquitecturaDescripción del sistema en términos de la asignación de los procesos


Descripción del sistema en términos de la asignación de los procesos a unidades de proceso y la configuración de la red


Desarrollo de software orientado a objetos (XXIX)Diseño (III)


Diagrama de interacción (relación entre responsabilidades y métodos)


Desarrollo de software orientado a objetos (XXX)Diseño (IV)

Métodos de desarrollo de software 47Vista lógica de las capas de una aplicación


Desarrollo de software orientado a objetos (XXXI)Diseño (V)

Despliegue de una arquitectura lógica (3 capas) en dos arquitecturas físicas diferentes


Despliegue de una arquitectura lógica (3 capas) en dos arquitecturas físicas diferentes


Métodos orientados a objetos (I)Clasificación de los métodos (I)Dirigidos por los datos

Se basan principalmente en la parte estructural de los objetosSe basan principalmente en la parte estructural de los objetosExtensión del modelado conceptual en el modelo entidad-relaciónMétodos: OMT [Rumbaugh et al., 1991], FUSION [Coleman et al., 1994]

Di i id l bilid dDirigidos por las responsabilidadesSe centran en las responsabilidades de los objetos, es decir, las acciones que puede llevar a cabo un objetoLa técnica que se utiliza es la de tarjetas de clase (CRC)Métodos: RDD [Wirfs-Brock et al., 1990] y OBA [Rubin y Goldberg 1992]

Dirigidos por los casos de usoDirigidos por los casos de usoLos casos de uso o formas de utilización (use cases) fueron propuestos en OOPSLA’87 por Ivar Jacobson [Jacobson, 1987]Un caso de uso es una forma o patrón o ejemplo concreto de utilización, un escenario que comienza con algún usuario del sistema que inicia alguna transacción o secuencia de eventos interrelacionados [Jacobson et al. 1992]


Métodos: Objectory [Jacobson et al. 1992], RUP [Jacobson et al., 1999]


Métodos orientados a objetos (II)Clasificación de los métodos (II)Tarjetas CRC (I)

La técnica de CRC (Class Responsability and CollaborationLa técnica de CRC (Class, Responsability and Collaboration -Clases, Responsabilidades, y Colaboraciones ) fue propuesta inicialmente por Beck y Cunningham [Beck y Cunningham, 1989]Popularizadas por Rebecca Wirfs-Brock [Wirfs-Brock et al., 1990] También reciben el nombre de fichas o tarjetas de clase

Clase: nombre de la clase (Abstracta o concreta)Li t d lLista de superclasesLista de subclasesResponsabilidad Colaboración


Tarjetas CRC (“Class, Responsability and Collaboration”)


Métodos orientados a objetos (III)Clasificación de los métodos (III)

Tarjetas CRC (II)Las responsabilidades de un objeto son todos los servicios que proporciona para todos los contratos que soportaLas responsabilidades sólo determinan en una primera fase quéLas responsabilidades sólo determinan en una primera fase qué acciones deben llevarse a cabo, pero no cómoResponsabilidades

Conocimiento que tiene la claseAcciones que puede realizar un objeto de la misma

Las colaboraciones representan peticiones por parte de un cliente aLas colaboraciones representan peticiones por parte de un cliente a los servidores para el cumplimiento de las responsabilidades del clienteL i i t tLos servicios se agrupan en contratosLa relación entre las colaboraciones y las responsabilidades no es de tipo 1:1


p


Métodos orientados a objetos (IV)Clasificación de los métodos (IV)

Casos de uso (I)Los casos de uso o formas de utilización tienen dos papelesLos casos de uso o formas de utilización tienen dos papeles importantes

Capturar los requisitos funcionales del sistema. Aporta una visión de “ j ” d l i t“caja negra” del sistemaSimplificar la construcción de los modelos de objetos

Un modelo de casos de uso es un grafo con dos tipos de nodosg pActor: representa cualquier elemento que intercambia información con el sistema, por lo que está fuera de élCaso de uso: secuencia de transacciones en un diálogo con elCaso de uso: secuencia de transacciones en un diálogo con el sistema que se encuentran relacionadas por su comportamiento. Cada forma de utilización tiene una descripción informal en lenguaje natural estructuradoestructurado

Los arcos entre los actores y las formas de utilización se denominan arcos de comunicación



Métodos orientados a objetos (V)Clasificación de los métodos (V)

Casos de uso (II)

sacar dinero

transferencias

clientesistema del banco

depositar dinero

administraciónoperador


Ejemplo de casos de uso para un cajero automático


Métodos orientados a objetos (VI)OMT (I)

OMT (Object Modeling Technique) fue propuesto por Rumbaugh [Rumbaugh et al., 1991]Comprende las fases de análisis y diseñoEl modelo de análisis se expresa desde tres puntos de vista

Modelo de objetos: describe la estructura de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones)(identidad, relaciones con otros objetos, atributos y operaciones)Modelo dinámico: describe aquellos aspectos del sistema que tratan la temporización y secuencia de operaciones y la organización de sucesos y estados Se representa gráficamente mediante diagramas de estadoestados. Se representa gráficamente mediante diagramas de estadoModelo funcional: describe las transformaciones funcionales. Se representa mediante DFDs

El diseño se desarrolla en dos etapasDiseño del sistemaDi ñ d bj t


Diseño de objetos


Métodos orientados a objetos (VII)OMT (II)

Análisis – Modelo de objetos (I)j ( )Actividades:

Identificar los objetos y clasesfIdentificar asociaciones entre objetos

Identificar atributos de objetos y enlaces Organizar y simplificar las clases de objetos empleando la herenciaIterar y refinar el modelo

Identificar objetos y clasesIdentificar objetos y clases

Eli i l Identificación Clases de bj t Cl dExtraer nombres Eliminar clases

inadecuadasIdentificaciónde requisitos

objetostentativas

Clases deobjetos



Métodos orientados a objetos (VIII)OMT (III)

Análisis – Modelo de objetos (II)

Persona

Nombre: Edad:

(Persona)

Juan López52

(Persona)

Ana Alonso19

Clase InstanciasNombre de la clase

Nombre_atributo1: tipo_dato1=valor_por_defecto1Nombre_atributo1: tipo_dato2=valor_por_defecto2Nombre_operación1(lista_arg1): tipo_resultado1N b ió 2(li t 2) ti lt d 2Nombre_operación2(lista_arg2): tipo_resultado2

N t ió OMT l bj t


Notación OMT para clases y objetos


Métodos orientados a objetos (IX)OMT (IV)

Análisis – Modelo de objetos (III)Id tifi i iIdentificar asociaciones

Dependencia de dos o más clasesReferencia de una clase a otra

Diagrama de clases

Pais Ciudad

Nombre Nombre

Asociaciónde clasesNombre Nombre

(Pais) (Ciudad)

Su capital es

(Pais) (Ciudad)España Madrid

EnlacesDiagrama

de (Pais) (Ciudad)Suiza Berna

Enlaces de instancias

Métodos de desarrollo de software 57Representación de enlaces y asociaciones en OMT


Métodos orientados a objetos (X)OMT (V)

Análisis – Modelo de objetos (IV)

Estación Ventana

Empresa Persona

Notación OMT para la representación de la cardinalidad de asociaciones

Curso Profesor

Alumno

Métodos de desarrollo de software 58Asociación ternaria


Métodos orientados a objetos (XI)OMT (VI)

Análisis – Modelo de objetos (V)

Empresa Servicio Sección

Persona MicroordenadorMicroordenador

Monitor Caja Sist. Ratón Teclado

Caja CPU RAM . . .


Notación OMT para la representación de agregaciones


Métodos orientados a objetos (XII)OMT (VII)

Análisis – Modelo de objetos (VI)j ( )Identificar atributos de objetos y enlaces

Archivo Usuario

Permiso de acceso

Atributo de enlace

Atributo de enlace entre dos clases

Organizar y simplificar las clases de objetos empleando la herenciaGeneralizar aspectos comunes de clases existentes en una superclase


Refinando clases existentes para dar subclases especializadas


Métodos orientados a objetos (XIII)OMT (VIII)

Análisis – Modelo de objetos (VII)

Empleado

Temporal Fijo Por horas Jubilado

Director Jefe área . . .

Iterar y refinar el modelo

Director Jefe área . . .

Refinamiento mediante la herencia

Iterar y refinar el modeloObjetos no identificados (atributos y operaciones dispares en una clase, asociaciones duplicadas, asimetrías...)Clases innecesarias (carencia de atributos, operaciones...)


Asociaciones no representadas (falta de vías de acceso para operaciones)Asociaciones innecesarias (información redundante)


Métodos orientados a objetos (XIV)OMT (IX)

Análisis – Modelo dinámico (I)Componentes

Eventos: Un evento es algo que sucede en un momento determinado (un punto en el tiempo)(un punto en el tiempo)

El vuelo 123 parte para Paris– Un evento puede preceder o seguir a otroUn evento puede preceder o seguir a otro

– Dos eventos no relacionados causalmente se dice que son concurrentes– Los eventos se agrupan en clases cuyos atributos indican la información

t itque transmiten

Escenarios: Secuencia de eventos que ocurren durante una ejecución particular del sistemaj p

Estados: Un estado es una abstracción del valor de los atributos y enlaces de un objeto



Métodos orientados a objetos (XV)OMT (X)

Análisis – Modelo dinámico (II)Análisis Modelo dinámico (II)Objeto1 Objeto2 Objeto3

Evento1Evento2Evento3Evento4E t 5Evento5Evento6 Evento7

Evento8Evento10 Evento9 Usuario Cajero Consorcio

Insertar tarjetaverificar tarjeta

verificar cantidad

Banco

cantidad malrechazar

tarjetaexpulsar

Diagramas de eventos


tarjeta


Métodos orientados a objetos (XVI)OMT (XI)

Análisis – Modelo dinámico (III)Di d t d E ifi l i d t dDiagramas de estados: Especifica la secuencia de estados causada por una secuencia de eventos

Describe el comportamiento de una sola clase de objetos El modelo dinámico es una colección de diagramas de estado que interactúan vía eventos compartidos

turnoblancas

Jaque mateGanannegras

Muevenegra

Mueveblanca

turnonegras

Jaque mateGanan blancas


Diagrama de estados para el juego del ajedrez


Métodos orientados a objetos (XVII)OMT (XII)Análisis – Modelo funcional

Describe las transformaciones que ocurren dentro del sistemaDescribe las transformaciones que ocurren dentro del sistemaEspecifica el significado de las operaciones en el modelo de objetos y de las acciones en el modelo dinámicoF d di d fl j d d t (DFD ) i lFormado por diagramas de flujo de datos (DFDs) que incluyen:

Procesos: transforman los datosFlujos de datos: mueven los datosAlmacenes de datos: objetos que almacenan los datos de forma estáticaActores: son objetos activos que conducen el flujo de datos produciendo o consumiendo valores

Almacen1 Objeto1

Objeto2

P1 P2 P3

P4

Métodos de desarrollo de software 65Diagrama de flujo de datos


Métodos orientados a objetos (XVIII)OMT (XIII)

DiseñoDiseño del sistema

Descomposición del sistema en subsistemasIdentificación de concurrenciasAsignación de subsistemas a procesadores y tareasManejo de acceso a recursos globalesManejo de excepcionesjAsignación de prioridades

Diseño de objetosCombinación de los modelos de análisisCombinación de los modelos de análisisDiseño de algoritmos y estructuras de datosDefinición de clases y objetosOptimizar las vías de acceso a los datosOptimizar las vías de acceso a los datosImplementar el control para interacciones externasAjuste de la herenciaDi ñ i i


Diseño asociacionesEmpaquetamiento de asociaciones y clases en módulos


Métodos orientados a objetos (XIX)Método de Booch (I)

Método de diseño [Booch, 1991] que se amplió a la fase de análisis [Booch, 1994] Consta de cuatro actividades principales y seis notaciones:1994]. Consta de cuatro actividades principales y seis notaciones:

Estructura lógicaDiagramas de clasesDi d bj t Tipo

Nombre del paquete

Diagramas de objetosEstructura física

Diagramas de módulosDiagramas de procesos

Tipo

Op

OpDiagramas de procesosDinámica de clases

Diagramas de transición de estadosDinámica de instancias

p

Dinámica de instanciasDiagramas temporales

Representación de las clases como paquetes

A BA es cliente de BObj t Cl


Relación cliente/servidorObjeto Clase

Notación de Booch


Métodos orientados a objetos (XX)Método de Booch (II)Estructura estática

Diseño lógico: se describe mediante los diagramas de clases de objetos s s plantillasDiseño lógico: se describe mediante los diagramas de clases de objetos y sus plantillas asociadasDiseño físico

Diagramas de módulos: segmentos de programa (paquetes o funciones)g g p g (p q )Diagramas de proceso: diagramas de bloques que muestran las relaciones de comunicación entre dispositivos físicos y procesadores

Estructura dinámicaDiagramas de transición de estados: Muestran la dinámica a nivel de clases. Se centran en aquellos estados que den lugar a cambios en los datos o que sean significativos

Diagramas temporales: muestran el comienzo y terminación de los métodos de cada instancia en relación con otros

Objeto R Operación 1

Objeto SObjeto TObjeto U

Operación 2

Operación 4

Operación 3


Tiempo

Diagrama temporal


Métodos orientados a objetos (XXI)Método de Jacobson (I)

Método OOSE (Object Oriented Software Engineering) / Objectory [Jacobson et al 1992]et al., 1992]Es un método dirigido por los casos de uso, técnica propuesta por el autor del métodoEl propósito del método es el modelado de sistemas complejos comenzandoEl propósito del método es el modelado de sistemas complejos comenzando por los modelos de empresa u organización. A este nivel se aplican los casos de desarrollo, análogos a los casos de usoLos casos de uso se utilizan en el análisis de requisitosq

Enumeración de los escenarios principales para el funcionamiento del sistemaLos escenarios en conjunto describen las funciones del sistema

El análisis procede como un estudio de cada escenario, utilizando técnicas de presentación (storyboard)A medida que el equipo pasa por cada escenario, debe identificar los objetos que participan en él, las responsabilidades de cada objeto, y la forma en que l bj t l blos objetos colaboranSegún continua el proceso de desarrollo estos escenarios iniciales se expanden para considerar condiciones excepcionales, así como comportamientos secundarios del sistema


comportamientos secundarios del sistema


Métodos orientados a objetos (XXII)OOSA

OOSA (Object Oriented System Analysis) [Shaler y Mellor, 1992]

Método complejo con influencias del modelo relacional: los objetos están normalizados

Inicialmente no consideraban la herencia

La identidad de los objetos es confusa

Los métodos se obtienen modelando los ciclos de vida de las entidades con diagramas de transición de estados

D fi i ió d d i i tili blDefinición de dominios reutilizables

Modelos:Modelo de información: muestra los objetos atributos y relacionesModelo de información: muestra los objetos, atributos y relaciones

Modelo de estado: describe los estados de los objetos y las transiciones de los estados


Modelo de procesos: representado mediante un DFD


Métodos orientados a objetos (XXIII)Coad/Yourdon

IdentificadorMétodo centrado en el análisis y basado en Identificador

Atributos

yel modelado de entidades y relaciones [Coad y Yourdon, 1991]Aplicaciones comerciales

Métodos

Aplicaciones comercialesTemas: representan los niveles o capas de DFDObjetos: Se identifican los objetos con Clase genérica

Identificador

Objetos: Se identifican los objetos con detalleEstructuras

f AtributosDe clasificaciónDe composición

Atributos: especificación de relaciones de

Clase con instancias

Métodosmultiplicidad y modalidadServicios: Identificación de operaciones (crear y borrar instancias, tomar y poner


Notación de Coad y Yourdon

( y , y pvalores y métodos especiales)


Métodos orientados a objetos (XXIV)SOMASOMA (Semantic Object Model Approach) [Graham 1994] Identificador[Graham, 1994]Método que combina una notación única para el análisis OO con unas reglas del estilo de los sistemas basados en el conocimiento

Identificador

Atributos

Mét dsistemas basados en el conocimientoActividades

Identificar capas: Forma de descomponer el d i i d l bl

Métodos

Reglas

dominio del problemaIdentificar objetosIdentificar estructuras

D l ifi ió

Clase

Identificador

AtributosDe clasificaciónDe composición

Definir la semántica de los datos y asociaciones: Relaciones estructurales entre

Atributos

Métodosasociaciones: Relaciones estructurales entre clases Añadir atributos y operaciones a los objetosAñadir la semántica declarativa de objetos: Clase con instancias

Reglas


Añadir la semántica declarativa de objetos: Reglas para resolver conflictos

Notación de Graham


ReutilizaciónReutilizaciónReutilización: uso de componentes de un producto para facilitar el desarrollo de productos diferentes con diferente funcionalidad

Accidental u oportunistaDeliberada o sistemática

Reusabilidad: facilidad con la que se pueden usar esos componentes enReusabilidad: facilidad con la que se pueden usar esos componentes en situaciones nuevasLa reutilización sistemática de software proporciona bases para el incremento de la calidad y la fiabilidad y a largo plazo reduce los costes delincremento de la calidad y la fiabilidad y a largo plazo reduce los costes del desarrollo y mantenimiento de softwareUn componente reutilizable puede ser código, diseño, parte de un manual, un conjunto de datos de prueba o una estimación de coste o duraciónun conjunto de datos de prueba o una estimación de coste o duración...La reutilización está muy ligada al paradigma de orientación a objetos (OO)

La reutilización es uno de los principales objetivos de la orientación a objetos

Las características de la OO favorecen la reutilización (abstracción, encapsulamiento, jerarquías de herencia y composición, delegación...) y ayudan a conseguir los beneficios potenciales que presenta



ReutilizaciónReutilización del diseño (I)

Tipos de reutilización:Marcos de trabajo (Frameworks):

“Diseño reutilizable de todo o parte de un sistema representado por un conjunto de clases abstractas y la forma en la cual sus instancias j yinteractúan”“Conjunto de clases que cooperan que constituyen un diseño reutilizable para una clase específica de software”

Patrones de arquitectura: Reutilización del diseño a gran escala y de grano grueso: organización de elementos estructurales y sus interfacesLos patrones de capas estructuran el sistema en niveles o capas con distintas responsabilidades

Patrones de diseño: “cada patrón describe un problema que p p qocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar esa solución un millón de veces sin hacer lo mismo dos veces” [Alexander et al.,


1977]


ReutilizaciónReutilización del diseño (II)

( ) (b) ( ) (d)

Representación simbólica de reutilización del diseño ( ) bibli t (b) f k ( ) t ó d di ñ (d) it t ft

(a) (b) (c) (d)


(a) biblioteca, (b) framework, (c) patrón de diseño, (d) arquitectura softwareLas zonas sombreadas representan reutilización


ReutilizaciónReutilización del diseño (III)

Marcos de trabajo (MT)Un MT encapsula el patrón de la arquitectura software de un sistema o de alguna de sus partesUn MT suele estar compuesto por una colección de patrones de diseñoLos MT se extienden normalmente en los puntos de entrada (hot spots o hooks)Según su aplicabilidad los MT pueden ser:

H i l d di d d l d l i bHorizontales: dedicados a modelar aspectos del sistema subyacenteVerticales: desarrollados específicamente para un dominio de aplicación concreto

Según el mecanismo de extensión los MT se clasifican en:Según el mecanismo de extensión los MT se clasifican en:Caja blanca: se extienden mediante el mecanismo de la herencia. Los puntos de entrada se representan como clases y métodos abstractosCaja de cristal: admiten la inspección de su estructura e implementación, pero j p p , pno su modificación ni reescritura, salvo para sus puntos de entradaCaja negra: se extienden mediante composición y delegación. No utilizan la herenciaCaja gris: parte del interior de un MT o componente es público el resto se


Caja gris: parte del interior de un MT o componente es público, el resto se oculta


ReutilizaciónReutilización del diseño (IV)

Extensibilidad de los marcos de trabajoHot spots: Puntos de refinamiento predefinido donde se produce la adaptación o especialización. Permiten conectar una clase o subsistema específico de una aplicación porp p p

selección de un conjunto de clases o subsistemas suministrado en un MT de caja negraprogramación de una clase o subsistema en un MT de caja blancaprogramación de una clase o subsistema en un MT de caja blanca

Métodos plantilla (template): métodos complejos que definen comportamientos abstractos y que pueden ser implementados tomando

b ét d h k l t lcomo base métodos hook elementalesMétodos hook: implementan los hot spots de un MT. El comportamiento abstracto se adapta sobreescribiendo los métodos hookClases plantilla (template): clases que contienen los métodos plantillaClases hook: Clases que contienen los métodos hook



ReutilizaciónReutilización del diseño (V)

Ejemplos de extensibilidad de MTMetapatrón de unificación: flexibilidad en tiempo de desarrollo

calc larTasa()

Renta

imprimirFactura ()

<<abstract>>calcularTasa()

imprimirFactura ()calcularTasa()TemplateHook

metodoTemplate ()

RentaConcr1 RentaConcr2

p ()metodoHook()

calcularTasa() calcularTasa()


Clases hook


ReutilizaciónReutilización del diseño (VI)

Ejemplos de extensibilidad de MTMetapatrón de conexión: flexibilidad en tiempo de ejecución

Template HookTemplate

metodoTemplate ()

Hook

metodoHook()

hookRef

CalculoTasaRenta calculo

calcularTasa()imprimirFactura()

ca cu o

CalculoTasaConcr1 CalculoTasaConcr2calculo.calcularTasa()


calcularTasa() calcularTasa()


ReutilizaciónReutilización del diseño (VII)

Ejemplos de marcos de trabajoP ió d I t f áfi d iProgramación de Interfaces gráficas de usuario

MacAppMFC (Microsoft Foundation Classes)Java AWT y Swingy g

Componentes visualesOpenDocBlacKBox

M lti diMultimediaJMF (Java Media Framework)

Redes y comunicacionesMultiTel (Multimedia TELecommunication services )MultiTel (Multimedia TELecommunication services )FIONA

Componentes distribuidosCORBAA ti X/OLE/COMActiveX/OLE/COMJavaBeans

Aplicaciones Web - JavaWeb MVC: Struts, JSF (Java Server Faces)


Web MVC: Struts, JSF (Java Server Faces)Abstracción de servicios: SpringPersistencia: iBatis, Hibernate


ReutilizaciónReutilización del diseño (VIII)


Modelo UML del MT MultiTel [Fuentes et al., 2002]


ReutilizaciónReutilización del diseño (IX)


Framework Struts (http://struts.apache.org)


ReutilizaciónReutilización del diseño (X)

Frameworks iBatis (http://ibatis.apache.org)

iBATIS SQL Maps: framework que ayuda a disminuir el código Java para el acceso a la base de datos y permite fácilmente mapear un JavaBean en parámetros de una consulta SQL y viceversa, mapear el resultado de una consulta SQL en un JavaBeaniBatis Data Access Object: framework que proporciona una infraestructura para la creación de aplicaciones basadas en el patrón DAO (Data Access Object) y proporciona un interfaz para el manejo de transacciones independientemente del mecanismo de almacenamiento que se utilice

Métodos de desarrollo de software 83Clases del patrón DAO


ReutilizaciónReutilización del diseño (XI)

Patrones de arquitecturaEstilo arquitectónico: familia de arquitecturas restringidas por

Un vocabulario de componentes y conectoresTopologíap gRestricciones semánticas

Patrón arquitectónico: se define para cada estilo de arquitecturaP i f l til it tó iProporciona una forma al estilo arquitectónicoSe centra en la identificación del problema, contexto del problema y en una solución con sus consecuenciasHace hincapié en la composición de patrones de diseño

Taxonomía de estilos y patrones arquitectónicos (POSA [Buschmann et al., 1996])

Jerarquía: Layersq yFlujo de datos: Pipes & FiltersSistemas distribuidos: BrokerProcesos interactivos: Model-View


Repositorios orientados a datos: Blackboard…


ReutilizaciónReutilización del diseño (XII)

Patrones de arquitectura: Layers (I)Propósito:

Organización de la estructura lógica de gran escala de un sistema en capas separadas con responsabilidades distintas y relacionadascapas separadas con responsabilidades distintas y relacionadasColaboración y el acoplamiento desde las capas más altas a las más bajas

Elementos:Componentes: grupo de subtareas que implementan una máquina virtual en alguna capa de la jerarquíag p j qConectores: protocolos/interfaces que definen la interacción entre las capas

Solución:Solución:Cada capa puede invocar operaciones de las capas inferioresLas interfaces hacia las capas superiores están estandarizadas


Cada capa es independiente de sus capas superiores


ReutilizaciónReutilización del diseño (XIII)

Patrones de arquitectura: Layers (II)Presentación

Consecuencias:Las capas se pueden desarrollar independientemente (+)

Presentación

Swingindependientemente (+)Mantenimiento: se puede cambiar una capa sin que afecte a otras capas (+)R tili ió S d i t bi Dominio

…

Reutilización: Se pueden intercambiar diferentes implementaciones del mismo nivel (+)S t l di t ib ió ( )

Dominio

Ventas MotorReglasSoporte para la distribución (+)Estandarización basada en capas (p.ej. OSI) (+)

Servicios Técnicos

…

El diseño de interfaces entre capas puede ser difícil (-)El rendimiento puede verse afectado (-)

Servicios Técnicos

Persistencia Jess


p ( ) …


ReutilizaciónReutilización del diseño (XIV)

Patrones de arquitectura: Layers (III)Variante distribuida:

Cada una de las capas se puede distribuirCada capa en un nodo se conecta lógicamente con la correspondiente p g pcapa en otro nodo

Capas relajadas:Llamadas combinando varios componentes en una capap p

FTP FTPProtocolo FTP

TCP

IP

TCP

IP

Protocolo TCP

Protocolo IPIP

Ethernet

IP

EthernetProtocolo EthernetConexión física

Métodos de desarrollo de software 87Variante distribuida


ReutilizaciónReutilización del diseño (XV)Patrones de arquitectura: Layers (IV)

UUsos: Protocolos de comunicaciónToolkits de sistemas de ventanas

Aplicación

PresentaciónSistemas operativosS.I. Modelo de capas en una arquitectura lógica

Presentación: ventanas GUI, informes, interfaz de voz,

Presentación

SesiónPresentación: ventanas GUI, informes, interfaz de voz, HTML, XML, XMLT, JSP, Javascript…Aplicación: gestión de las peticiones de la capa de presentación, flujo de trabajo, estado de la sesión, transiciones a ventanas/páginas transformación de

Transporte

transiciones a ventanas/páginas, transformación de datosDominio: gestión de las peticiones de la capa de aplicación, reglas de dominio, servicios de dominio

Red

Enlace de datosInfraestructura de negocio: servicios de negocio de bajo nivelServicios técnicos: servicios técnicos de alto nivel, persistencia y seguridad

Física


persistencia y seguridadBase: servicios técnicos de bajo nivel, estructuras de datos, hilos, redes, BBDD

Modelo OSI


ReutilizaciónReutilización del diseño (XVI)Patrones de arquitectura: Layers (V)

Presentación Dominio Servicios Técnicos

Swing Ventas MotorReglas……

Persistencia Jess………

Métodos de desarrollo de software 89Diagrama de interacción entre capas de una arquitectura


ReutilizaciónReutilización del diseño (XVII)Patrones de arquitectura: Layers (VI)

Arquitectura JSF-Spring-HibernateCapas:

Capa de presentaciónCapa de presentaciónCapa de lógica de negocioCapa de integración

Características:Características:Orientada a serviciosSeparación limpia de capas: uso de ficheros de configuración XMLficheros de configuración XMLUso con clientes ligeros (navegadores web, wap…) y pesados (Swing, SWT…)( g, )Inversión de control o inyección de dependenciasMapeo del modelo de clases a un


Arquitectura orientada a servicios

pmodelo objeto relacional


ReutilizaciónReutilización del diseño (XVIII)Patrones de arquitectura: Layers (VII)

A i JSF S i HibArquitectura JSF-Spring-HibernateJSF (Java Server Faces)

Estándar de Sun para la capa de t ió W bpresentación Web

Patrón MVCModelo: Beans de respaldoVista: Páginas JSPVista: Páginas JSPControlador: Faces Servlet

Spring framework (http://www.springframework.org)

Abstracción de servicios (SOA)Publicación: ficheros XMLLocalización: patrón Service Locator

Inversión de control (IoC)Programación orientada a aspectos

Hibernate (http://www.hibernate.org)


Arquitectura orientada a serviciosPersistencia transparenteORM (Object Relational Mapping)


ReutilizaciónReutilización del diseño (XIX)

Patrones de arquitectura: Pipes & Filters (I)Propósito:

Descomponer aplicaciones que procesan flujos de datos en filtrosreutilizables

Elementos:Componentes: Filters

Leen flujos de datos de entrada y producen flujos de datos de salidaTransformación incremental local de los fl jos de entradaTransformación incremental local de los flujos de entradaLos datos son procesados a medida que llegan

Conectores: PipesConducen las salidas de un filtro a la entrada de otroConducen las salidas de un filtro a la entrada de otro

Flujo de datos (pipe)

Procesamiento Procesamiento Procesamiento


Procesamiento (filter)


ReutilizaciónReutilización del diseño (XX)

Patrones de arquitectura: Pipes & Filters (II)Solución:

El flujo de datos es unidireccional Los formatos de datos están estandarizados por lo que los filtros seLos formatos de datos están estandarizados por lo que los filtros se pueden combinar de varias formas

Consecuencias:Fácil ensamblaje de aplicaciones mediante combinación de filtros (+)Reutilización: dos filtros se pueden conectar si concuerdan los formatos de datos (+)Fácil mantenimiento: se pueden añadir o reemplazar filtros (+)Difícil diseñar filtros incrementales (-)No son apropiados para aplicaciones interactivas ( )No son apropiados para aplicaciones interactivas (-)

Usos:Filtros UNIXC il d


CompiladoresOptimizadores de código


ReutilizaciónReutilización del código

Bibliotecas de clases (toolkits)Conjunto de clases relacionadas y reutilizables diseñadas paraConjunto de clases relacionadas y reutilizables diseñadas para proporcionar funcionalidad útil de propósito general:

CientíficasMatemáticasMatemáticas Interfaces gráficas de usuario (GUI) . . .

Las bibliotecas de código no imponen un diseño particular, sólo proporcionan funcionalidadproporcionan funcionalidadEl diseñador es el responsable de la lógica de control del producto completo

Métodos de desarrollo de software 94Diferencias en la reutilización usando bibliotecas y marcos de trabajo

Clases de biblioteca (toolkit) Marco de trabajo (framework)


Patrones de diseño (I)Patrones de diseño (I)

Un patrón de diseño ofrece una solución abstracta a un problema de diseño q e aparece m frec entementeproblema de diseño que aparece muy frecuentemente, expresada mediante un conjunto de relaciones e interrelaciones entre componentesinterrelaciones entre componentesElementos de un patrón:

N b d ib l t óNombre: describe el patrónProblema: explica el problema y su contextoSolución: describe los elementos del diseño sus relacionesSolución: describe los elementos del diseño, sus relaciones, responsabilidades y colaboracionesConsecuencias: resultados, ventajas e inconvenientes de aplicar jel patrón

Los patrones de diseño varían en su granularidad y nivel


de abstracción


Patrones de diseño (II)Patrones de diseño (II)

Patrones POSA (Pattern-Oriented Software Architecture)[B schmann et al 1996][Buschmann et al., 1996]

Arquitectónicos: Layers, Pipes&Filters, Broker , MVC…Diseño: Master Slave Proxy Command Processor ViewDiseño: Master-Slave, Proxy, Command Processor, View Handler… Idiomas: Counted Pointer…

Patrones GRAPS (General Responsability Assignment Software Patterns) [Larman 2002]) [ ]

Principios generales: Experto en Información, Creador, Alta Cohesión, Bajo Acoplamiento, ControladorOtros patrones: Polimorfismo, Indirección, Fabricación Pura, Variaciones Protegidas

P G F (G f F )Métodos de desarrollo de software 96

Patrones GoF (Gangs of Four) [Gamma et al., 1995]


Patrones de diseño (III)Patrones de diseño (III)Clasificación de los patrones de diseño GoF [Gamma et al., 1995]

Según su propósitoSegún su propósitoDe creación: relacionados con el proceso de creación de objetosEstructurales: tratan la composición de clases u objetosDe comportamiento: caracterizan el modo en que las clases y objetosDe comportamiento: caracterizan el modo en que las clases y objetos interactúan y se reparten la responsabilidad

Según su ámbito: especifica si el patrón se aplica principalmente a clases o a objetoso a objetos

Propósito De Creación Estructurales De comportamiento

I t tClase Factory Method Adapter (de clases) Interpreter Template Method

Abstract Factory Builder

Adapter (de objetos)Bridge

Chain of Responsibility Command

Ámbito Objeto

PrototypeSingleton

Composite Decorator Facade Flyweight Proxy

Iterator Mediator Memento Observer State


Proxy State Strategy Visitor


Patrones de diseño (IV)Patrones de diseño (IV)Mecanismos de reutilización:

Herencia: definición de una implementación en términos de otraReutilización de caja blancaSe define estáticamente en tiempo de compilación

Composición: la nueva funcionalidad se logra ensamblando o componiendo objetosobjetos

Reutilización de caja negraSe define dinámicamente en tiempo de ejecución

Delegación: el objeto receptor de una petición delega operaciones en otro objetoDelegación: el objeto receptor de una petición delega operaciones en otro objeto (delegado)Tipos parametrizados: mecanismo que permite definir un tipo sin especificar todos los otros tipos que usa. Éstos se proporcionan como parámetros cuando se p q p p pvan a usar

Ventana Rectanguloanchoalto

area ( )alto

area ( )

Métodos de desarrollo de software 98Mecanismo de delegación

return ancho * altoreturn rectangulo->area ( )


Patrones de diseño (V)Patrones de diseño (V)Patrón Abstract Factory (I)

Proporciona una interfaz para crear familias de objetosProporciona una interfaz para crear familias de objetos relacionados o dependientes sin especificar la clase concreta

AbstractFactoryAbstractFactoryAbstractFactory

CreateProductA ()CreateProductB ()

ClienteAbstractFactory

CrearProductoA ()Cliente

CrearProductoB ()

ConcreteFactory1 ConcreteFactory2ProdA2

AbstrProdA

ProdA1ConcreteFactory1 ConcreteFactory2

ProdA2

ProdAbstrA

ProdA1ProdA2

AbstrProdB

ProdA1ProdA2

ProdAbstrB

ProdA1CrearProductoA ()CrearProductoB ()

CrearProductoA ()CrearProductoB ()

ProdB2 ProdB1ProdB2 ProdB1



Patrones de diseño (VI)Patrones de diseño (VI)Patrón Abstract Factory (II)

FabricaIGU

crearBarraDesp()crearMenu()

Cliente

Menu

MotifFabricaIGU

crearBarraDesp()crearMenu()

PMFabricaIGU

crearBarraDesp()crearMenu ()

PMMenu MotifMenu

BarraDesp

PMBarraDesp MotifBarraDesp


Uso del patrón Abstract Factory en la creación de GUIs


Patrones de diseño (VII)Patrones de diseño (VII)Patrón Abstract Factory (III)

A li bilid dAplicabilidadUn sistema debe ser independiente de cómo se crean, se componen y representan sus productoscomponen y representan sus productosUn sistema debería configurarse para una familia de productosUna familia de objetos producto relacionados se diseña para jusarse conjuntamente y se debe cumplir esta restricciónSe quiere proporcionar una biblioteca de clases de productos y se quiere revelar sólo la interfaz no la implementaciónse quiere revelar sólo la interfaz, no la implementación

ConsecuenciasAísla las clases concretasFacilita el intercambio de familias de productosPromueve la consistencia entre productosEs difícil soportar nuevas clases de productos


Es difícil soportar nuevas clases de productos


Patrones de diseño (VIII)Patrones de diseño (VIII)Patrón Builder (I)

Separa la construcción de un objeto complejo de suSepara la construcción de un objeto complejo de su representación, así que el mismo proceso de construcción puede crear diferentes representaciones

Director Builder+builder

Construir()construirParte()

+builder

BuilderConcretoProducto

para todo objeto de la estructura {

construirParte()getResultado()

Productoestructura {builder.construirParte ( )}



Patrones de diseño (IX)Patrones de diseño (IX)Patrón Builder (II)

ConversorTexto

convertirCaracter()convertirCambioFont()

TraductorRTF

analizarRTF() convertirCambioFont()ConvertirParrafo()

ConversorASCII ConversorTeX

convertirCaracter()getTextoASCII()

convertirCaracter()convertirCambioFont()convertirParrafo()getTextoTeX()

TextoASCII TextoTeX


Uso del patrón Builder en la creación de un conversor de texto


Patrones de diseño (X)Patrones de diseño (X)Patrón Builder (III)

AplicabilidadEl algoritmo para crear un objeto complejo debe ser independiente de las partes componentes del objeto y deindependiente de las partes componentes del objeto y de cómo se ensamblanEl proceso de construcción debe permitir diferentes representaciones del objeto que se construye

ConsecuenciasPermite variar la representación interna de un productoAísla el código de representación del código de construcciónProporciona un control fino sobre el proceso de construcciónProporciona un control fino sobre el proceso de construcción



Patrones de diseño (XI)Patrones de diseño (XI)Patrón Factory Method (I)

Define una interfaz para crear un objeto pero permite a lasDefine una interfaz para crear un objeto, pero permite a las subclases decidir la clase a instanciar: instanciación diferida a las subclases

CreadorProducto

<<abstract>

metodoFabricacion()unaOperacion()

Producto

prod = metodoFabricación()

CreadorConcretot P d t C t ()ProductoConcreto metodoFabricacion()

return new ProductoConcreto()



Patrones de diseño (VII)Patrones de diseño (VII)Patrón Factory Method (II)

Documento

open()

<<abstract>>Aplicacion

Documento d;d = crearDocumento();open()

close()save()revert()

crearDocumento()nuevoDocumento()openDocumento()

d = crearDocumento();setDoc.add(d);d.open()

MiAplicacionMiDocumento

p

crearDocumento() Factory Method

return new MiDocumento


Uso del patrón Factory Method en la creación de una clase aplicación que gestiona diferentes tipos de documentos


Patrones de diseño (XIII)Patrones de diseño (XIII)Patrón Factory Method (III)

AplicabilidadAplicabilidadUna clase no puede prever la clase de objetos que debe crearUna clase desea que sus subclases especifiquen los objetos q p q jque debe crearUna clase delega responsabilidad a una entre varias subclases auxiliares (helper) y se quiere localizar el conocimiento de enauxiliares (helper) y se quiere localizar el conocimiento de en qué subclase auxiliar concreta delega

ConsecuenciasEvita ligar un código a clases específicas de la aplicaciónPuede suceder que las subclases de Creador sólo se crean con el fin de la creación de objetoscon el fin de la creación de objetosMayor flexibilidad en la creación: subclases ofreciendo versiones extendidas de un objeto


Conecta jerarquías de clases paralelas


Patrones de diseño (XIV)Patrones de diseño (XIV)Patrón Singleton (I)

Asegurar que una clase tiene una única instancia y asegurar unAsegurar que una clase tiene una única instancia y asegurar un acceso global

Singletonstatic unicaInstanciadatosSingleton return unicaInstanciadatosSingleton

static instancia()operacionSingleton()

tSi l t ()getSingleton()

Singleton.instancia().operacionSingleton()



Patrones de diseño (XV)Patrones de diseño (XV)Patrón Singleton (II)

Implementación en Javappublic class Singleton {

private static Singleton unicaInstancia = null;bli t ti Si l t i t i () {public static Singleton instancia() {

if (unicaInstancia = = null) {unicaInstancia = new Singleton()};

return unicaInstancia};protected Singleton();

Implementación en C++Implementación en C++class Singleton {public:

static Singleton* instancia();

Singleton* Singleton::_unicaInstancia = 0;Singleton* Singleton::_instancia ( ) {

static Singleton* instancia(); protected:

Singleton();private:

if (unicaInstancia = = 0) {_unicaInstancia = new Singleton;

}return unicaInstancia;


private:static Singleton* _unicaInstancia;

return _unicaInstancia;}


Patrones de diseño (XVI)Patrones de diseño (XVI)Patrón Singleton (III)

A li bilid dAplicabilidadDebe existir una única instancia de una clase, accesible a los clientes desde un punto conocidoclientes desde un punto conocidoDebe ser extensible mediante herencia y los clientes deben ser capaces de usar una instancia extendida sin modificar su ódicódigo

ConsecuenciasAcceso controlado a la única instanciaEspacio de nombres reducido. Evita usar variables globalesPermite generalizar a un número variable de instanciasPermite generalizar a un número variable de instanciasMás flexible que las operaciones de claseLa clase Singleton puede tener subclases


g p


Patrones de diseño (XVII)Patrones de diseño (XVII)Patrón Adapter (I)

Convierte la interfaz de una clase en otra que el cliente espera. q pPermite la colaboración de ciertas clases que tienen interfaces incompatiblesDos tipos:Dos tipos:

Adaptador de clasesAdaptador de objetos

Un adaptador de clases usa la herencia múltiple para adaptar lasUn adaptador de clases usa la herencia múltiple para adaptar las interfaces

AdaptadoCliente Objetivo AdaptableCliente

Objetivo

especificoMet1()

<<implementation>>

metodo1() peticiónConcreta()peticion()

<<implementation>>

Adapter

peticion() especificoMet1


p () especificoMet1peticiónConcreta()


Patrones de diseño (XVIII)Patrones de diseño (XVIII)Patrón Adapter (II)

Un adaptador de objetos se basa en la composición de objetos

ClienteObjetivo

peticion()

Adaptado

especificoMet1()

Adaptable

peticionConcreta()

AdapterAdapter

peticion() +adaptable

adaptable. peticionConcreta()



Patrones de diseño (XIX)Patrones de diseño (XIX)

Patrón Adapter (III)

Forma

EditorDeDibujo marco()crearManipulador()

Linea

marco()

FormaTexto

marco()

return texto.getExtension

marco()crearManipulador()

marco()crearManipulador()

+texto return new ManipuladorTexto

VistaTexto*


getExtension()


Patrones de diseño (XX)Patrones de diseño (XX)Patrón Adapter (IV)

AplicabilidadAplicabilidadSe desea usar una clase existente y su interfaz no coincide con la que se necesitaSe desea crear una clase reutilizable que debe colaborar con clases no qrelacionadas o imprevistasSe necesita usar varias subclases existentes y no es práctico adaptar su interfaz heredando de cada una de ellas (sólo para adaptador de objetos)

C iConsecuenciasAdaptador de clases

Sólo adapta una clase Adaptable concretaPermite a la clase Adaptador redefinir parte del comportamiento de AdaptableNo implica ninguna indirección, sólo introduce un objeto

Adaptador de objetosAdaptador de objetosPermite adaptar una clase y sus subclases, pudiendo añadir funcionalidad a todos los adaptados a la vezHace más difícil redefinir comportamiento de Adaptable y que el adaptador


Hace más difícil redefinir comportamiento de Adaptable y que el adaptador se refiera a la subclase


Patrones de diseño (XXI)Patrones de diseño (XXI)Patrón Composite (I)

Compone objetos en estructuras jerárquicas para representarCompone objetos en estructuras jerárquicas para representar jerarquías parte/todo. Permite a los clientes tratar de manera uniforme a los objetos elementales y a los compuestos

Componente

i ()Cliente operacion()añadir(Componente)eliminar(Componente)obtenerHijo(int)

Cliente

H j CompositeHoja

operacion()

Composite

operacion()añadir(Componente)eliminar(Componente) +hijos


eliminar(Componente)obtenerHijo(int)

hijos


Patrones de diseño (XXII)Patrones de diseño (XXII)Patrón Composite (II)

Figura

dibujar()añadir(Figura)eliminar(Figura)eliminar(Figura)obtenerHijo(int)

Linea Rectangulo FiguraCompuesta

dibujar() dibujar() dibujar()añadir(Figura f)eliminar(Figura)obtenerHijo(int)


j ( )


Patrones de diseño (XXIII)Patrones de diseño (XXIII)Patrón Composite (III)

A li bilid dAplicabilidadSe quiere representar jerarquías parte/todoSe quiere que los clientes ignoren la diferencia entre objetosSe quiere que los clientes ignoren la diferencia entre objetos compuestos y los objetos individuales que los forman

ConsecuenciasDefine jerarquía con clases formadas por objetos primitivos y objetos compuestos de manera recursivaSimplifica el cliente Los clientes pueden tratar objetosSimplifica el cliente. Los clientes pueden tratar objetos primitivos y compuestos de modo uniformeFacilita la adición de nuevos tipos de componentesPuede hacer que un diseño sea demasiado general. No se puede confiar al sistema de tipos que asegure que un objeto compuesto sólo contendrá objetos de ciertas clases, se


compuesto sólo contendrá objetos de ciertas clases, se requieren comprobaciones en tiempo de ejecución


Patrones de diseño (XXIV)Patrones de diseño (XXIV)Patrón Decorator (I)

Asigna responsabilidades adicionales a un objeto dinámicamenteAsigna responsabilidades adicionales a un objeto dinámicamente. Alternativa flexible a la herencia para extender la funcionalidad.

Componente

operacion()

CompConcreto

operacion()Decorator

+componentecomponente.operacion()

p ()operacion()

+componente

DecoratorConcrAestadoAdicional

DecoratorConcrBestadoAdicional

operacion()super.operacion;


operacion()operacion()comportAdicional()

comportAdicional();


Patrones de diseño (XXV)Patrones de diseño (XXV)Patrón Decorator (II)

ComponenteVisual

mostrar()

VistaTexto

mostrar()Decorator

mostrar() +componentet t ()

()componente.mostrar ()

DesplazamientoDecorator

posicionDesplazamiento

mostrar()

BordeDecoratoranchoBorde

mostrar() super mostrar;


mostrar()desplazarA()

mostrar()mostrarBorde()

super.mostrar;mostrarBorde ();


Patrones de diseño (XXVI)Patrones de diseño (XXVI)

Patrón Decorator (III)Aplicabilidad

Añadir objetos individuales de forma dinámica y transparenteResponsabilidades de un objeto pueden ser retiradasCuando la extensión mediante la herencia no es viable

ConsecuenciasMás flexibilidad que la herencia estática: se pueden añadir y eliminar responsabilidades en tiempo de ejecucióneliminar responsabilidades en tiempo de ejecuciónEvita que las clases de la parte alta de la jerarquía estén cargadas de funcionesUn decorador y su componente no son idénticosSistemas formados por muchos objetos pequeños. Dificultad de comprensión y depuración


de comprensión y depuración


Patrones de diseño (XXVII)Patrones de diseño (XXVII)Patrón Facade (I)

Proporciona una interfaz unificada para un conjunto de interfacesProporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar

FacadeClases del subsistema



Patrones de diseño (XXVIII)Patrones de diseño (XXVIII)Patrón Facade (II)

Clases del subsistema de compilación

Compilador

compilar()de compilación

Lexico Token

Sintactico Simbolo

Flujo

Constructor NodoPrograma NodoProgramaFlujoDeCodigoDeBytes

GeneradorDeCodigo

NodoInstruccion ...

GeneradorDeCodigo

NodoExpresion

NodoVariable

GeneradorDeCodigoRISC

GeneradorDeCodigoMaquinaDePila

...



Patrones de diseño (XXIX)Patrones de diseño (XXIX)Patrón Facade (III)

AplicabilidadProporcionar una interfaz simple a un subsistema complejoHay muchas dependencias entre clientes y las clases que implementan una abstracciónSe desea dividir en capas el subsistema: una fachada define elSe desea dividir en capas el subsistema: una fachada define el punto de entrada para cada nivel del subsistema

ConsecuenciasCo secue c asOculta a los clientes los componentes del subsistemaProporciona un acoplamiento débil entre un subsistema y los clientes: cambios en los componentes no afectan a los clientesNo se impide a las aplicaciones clientes el uso de las clases del subsistema


del subsistema


Patrones de diseño (XXX)Patrones de diseño (XXX)Patrón Proxy (I)

Proporciona un representante o sustituto (surrogate) de un objetoProporciona un representante o sustituto (surrogate) de un objeto para controlar el acceso a éste

Cliente

Sujeto

peticion()

Proxy

peticion()

SujetoReal

peticion() +sujetoReal sujetoReal.peticion()



Patrones de diseño (XXXI)Patrones de diseño (XXXI)Patrón Proxy (II)

EditorDocumentos

Grafico

dibujar()dibujar()getExtension()guardar()cargar()

P II ProxyImagennombreFichextension

dibujar()

ImagenimpImagenextension

if (imagen == null) {imagen = cargarImagen(nombreFich)}

imagen.dibujar()dibujar()getExtension()guardar()cargar()

dibujar()getExtension()guardar()lcargar()

+imagen if (imagen == null) {return extension}

else {imagen.getExtension ()}



Patrones de diseño (XXXII)Patrones de diseño (XXXII)Patrón Proxy (III)

AplicabilidadAplicabilidadSiempre que hay necesidad de una referencia a un objeto más versátil o sofisticada que un simple puntero. Situaciones comunes:

Proxy acceso remoto (representante local de un objeto en otro espacio de direcciones)Proxy virtual (crea objetos costosos sobre demanda)y ( j )Proxy para protección (controlar acceso al objeto original)Referencia inteligente (sustituto de un puntero que lleva a cabo operaciones adicionales)

ConsecuenciasUn proxy remoto oculta el hecho que un objeto reside en un espacio de direcciones diferentesespacio de direcciones diferentesUn proxy virtual puede realizar optimizaciones tales como crear un objeto por encargoTanto los proxies de protección como las referencias


Tanto los proxies de protección como las referencias inteligentes, permiten realizar tareas de mantenimiento adicionales cuando se accede a un objeto


Patrones de diseño (XXXIII)Patrones de diseño (XXXIII)Patrón Iterator (I)

Proporciona un modo de acceder secuencialmente a los elementosProporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna

AgregadoCliente

Iterator

primero()crearIterador() primero()siguiente ()haTerminado()elementoActual()

AgregadoConcreto

IteradorConcreto

g g

crearIterador()



Patrones de diseño (XXIV)Patrones de diseño (XXIV)Patrón Iterator (II)

Lista

contar()insertar(elemento)

+lista

IteradorLista

primero()

índice

insertar(elemento)eliminar(elemento)

p ()siguientet()haTerminado()elementoActual()

Cliente

Iterator

primero()

ListaAbstracta

crearIterador()contar() p ()

siguientet()haTerminado()elementoActual()

contar()insertar(elemento)eliminar(elemento)

Lista IteradorListaListaConSaltos IteradorListaConSaltos



Patrones de diseño (XXXV)Patrones de diseño (XXXV)Patrón Iterator (III)

AplicabilidadAcceder a un objeto agregado sin exponer su representación internainternaPermitir varios recorridos sobre objetos agregadosProporcionar una interfaz uniforme para recorrer diferentes p pestructuras agregadas (iteración polimórfica)

ConsecuenciasPermite variaciones en el recorrido de un agregadoLos iteradores simplifican la interfaz agregadoS d h á d id l bSe puede hacer más de un recorrido a la vez sobre un agregado



Patrones de diseño (XXXVI)Patrones de diseño (XXXVI)Patrón Mediator (I)

Define un objeto que encapsula como interaccionan un conjuntoDefine un objeto que encapsula como interaccionan un conjuntode objetos. Favorece un bajo acoplamiento, liberando a losobjetos de referenciarse unos a otros explícitamente, y permitevariar la interacción de manera independientevariar la interacción de manera independiente

+mediatorMediator Colega+mediator

ColegaConcr1MediatorConcreto ColegaConcr2ColegaConcr1MediatorConcreto ColegaConcr2



Patrones de diseño (XXXVII)Patrones de diseño (XXXVII)Patrón Mediator (II)

DirectorDialogoUtildi tmostrarDialogo()

crearUtiles()utilModificado(Util)

Util

modificado()

+director

director.utilModificado(this)

ListaDesplegableDirectorDialogoFuente+lista

CampoDeEntrada

getSeleccion()

lista

setTexto()

+campo

crearUtiles()utilModificado(Util)



Patrones de diseño (XXXVIII)Patrones de diseño (XXXVIII)Patrón Mediator (III)

:Cliente :ListaDesplegable :CampoDeEntradaDirectorDialogoFuente

mostrarDialogo()

utilModificado(Util)

getSeleccion()

setTexto()



Patrones de diseño (XXXIX)Patrones de diseño (XXXIX)Patrón Mediator (IV)

AplicabilidadAplicabilidadUn conjunto de objetos se comunica entre sí de una forma bien definida, pero compleja. Las interdependencias resultantes están poco estructuradas y son difíciles de comprenderEs difícil reutilizar un objeto porque se refiere a otros muchosEs difícil reutilizar un objeto porque se refiere a otros muchos objetos con los que se comunica.Un comportamiento que está distribuido entre varias clases d b í d d i h b ldebería ser adaptado sin crear muchas subclases

ConsecuenciasReduce la herenciaReduce la herenciaDesacopla a los colegasSimplifica los protocolos de los objetos


Abstrae cómo cooperan los objetosCentraliza el control


Patrones de diseño (XL)Patrones de diseño (XL)Patrón Observer (I)

Define una dependencia de uno a muchos entre objetos de formaDefine una dependencia de uno a muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y se actualicen todos los objetos que dependen de él.

Observer

actualizar()

Sujeto

adscribir(Observer) 1..*1 1 1..*

+observers

1 1 actualizar()quitar(Observer)notificar()

1..1..1 1..1..1

Para todo o en observers{o actualizar()}

SubjetoConcretoObserverConcreto

{o.actualizar()}

estadoSujeto

obtenerEstado()establecerEstado()

estadoObserver+sujeto

actualizar()return estadoSujetoestadoObserver =

sujeto.obtenerEstado()



Patrones de diseño (XL)Patrones de diseño (XL)

ObserverSi Observer

actualizar()

Sistema

adscribir(Observer)quitar(Observer)notificar()

1..*1..1 1..*

+observers

1..1

notificar()

Para todo o en observers{o.actualizar()}

SistemaConcreto

estadoSujeto

RelojAnalógico

estadoAnalógico

actualizar()

RelojDigital

estadoDigital

+sujeto

obtenerEstado()establecerEstado() +sujeto

actualizar()

return estadoSujetoestadoAnalógico =

actualizar()

t d Di it lsujeto.obtenerEstado()almacena información horaria

estadoDigital =sujeto.obtenerEstado()



Patrones de diseño (XLI)Patrones de diseño (XLI)Patrón Observer (II)

90

405060708090

Este 4tr2tr Vistas

010203040

1er trim 2do 3er trim 4to trim

OesteNorte 1tr

3tr1er trim. 2do

trim.3er trim.4to trim.

1tr. 2tr. 3tr. 4tr.Este 20 25 90 20Oeste 30 38 32 32

ModeloOeste 30 38 32 32Norte 47 47 45 45

t1=20t2=25t3=90


t4=20


Patrones de diseño (XLII)Patrones de diseño (XLII)Patrón Observer (III)

:SistemaConcreto :Reloj Analógico :RelojDigital:Otra

1. establecerEstado()

1.1. notificar()

1.1.1. actualizar()

1.1.2. actualizar()



Patrones de diseño (XLII)Patrones de diseño (XLII)Patrón Observer (III)

:Sujeto o1:Observer o2:Observer:Otra

1. establecerEstado()

1.1. notificar()

1.1.1. actualizar()

1.1.2. actualizar()



Patrones de diseño (XLIII)Patrones de diseño (XLIII)Patrón Observer (IV)

AplicabilidadAplicabilidadCuando una abstracción tiene dos aspectos y uno depende de otrootroCuando un cambio de estado en un objeto requiere cambios en otros objetos, y no sabemos cuántos objetos necesitan cambiarsecambiarseCuando un objeto debe ser capaz de notificar algo a otros objetos, sin hacer asunciones sobre quiénes son estos objetos

ConsecuenciasPermite modificar independientemente sujetos y observersAcoplamiento abstracto entre Sujeto y ObserverCapacidad de comunicación mediante difusión


Capacidad de comunicación mediante difusiónActualizaciones inesperadas


Patrones de diseño (XLIV)Patrones de diseño (XLIV)Patrón State (I)

Permite a un objeto cambiar su comportamiento cuando cambiaPermite a un objeto cambiar su comportamiento cuando cambia su estado. El objeto parece cambiar de clase

StateContexto +state

manejar()petición()

StateConcr1 StateConcr2state.manejar() StateConcr1 StateConcr2

manejar() manejar()



Patrones de diseño (XLV)Patrones de diseño (XLV)Patrón State (II)

TCPEstadoTCPConexion+estado

abrir()cerrar()acuseRecibo()

abrir()cerrar()acuseRecibo()

+estado

TCPEstablecida

abrir()cerrar()

TCPEscuchando

abrir()cerrar()

TCPCerrada

abrir()cerrar()

estado.abrir()

cerrar()acuseRecibo()





Patrones de diseño (XLVI)Patrones de diseño (XLVI)Patrón State (III)

AplicabilidadEl comportamiento del objeto depende de su estado, y debe cambiar su comportamiento en tiempo de ejecucióncambiar su comportamiento en tiempo de ejecución dependiendo de su estadoLas operaciones tienen grandes sentencias condicionales (normalmente estructuras CASE) que dependen del estado del objeto, que se representa por uno o más constantes de tipo enumerado

ConsecuenciasLocaliza el comportamiento dependiente al estado y lo divideLocaliza el comportamiento dependiente al estado y lo divide entre diferentes estadosHace explícitas las transiciones entre estados


Los objetos State pueden ser compartidos


PortabilidadPortabilidadUn producto se considera portable si es significativamente menos costoso adaptarlo a una nueva plataforma que construirlo desde el principio

Programa Compilador Hardware Sistema operativo

P C H S

Si el coste de convertir P en P’ es significativamente menor que el coste de codificar P’ desde el

P C H SP’ C’ H’ S’

Si el coste de convertir P en P es significativamente menor que el coste de codificar P desde el principio, entonces P es portable

IncompatibilidadesH dHardwareSistema operativoSoftware numéricoCompiladorCompilador

Recomendaciones para lograr la portabilidad:Aislar las partes dependientes de la implementaciónUtili tá d d ió


Utilizar estándares de programaciónUtilizar ficheros de datos sin estructura


Interoperabilidad (I)Interoperabilidad (I)Operación mutua de código objeto de diferentes vendedores, escrito en diferentes lenguajes y ejecutándose en diferentes plataformasEstándares que promueven la interoperabilidad:Estándares que promueven la interoperabilidad:

CORBA (Object Request Broker Architecture)Estándar internacional y OMG (Object Management Group) para sistemas orientados a objetosorientados a objetosSoporta la interoperabilidad de aplicaciones ejecutándose en diferentes máquinas en un entorno distribuidoInteroperabilidad entre vendedores, redes, lenguajes y sistemas operativosp , , g j y pTecnología sencilla

COM (Component Object Model)Propuesto por MicrosoftProporciona un entorno basado en objetos para desarrollar aplicaciones interoperables en diferentes dominiosUso de un mecanismo común para todas las situaciones en que un componente proporciona servicios a otro componentecomponente proporciona servicios a otro componenteMecanismo de comunicación propietario de MicrosoftTecnología muy compleja

.NET


.NETTecnología de Microsoft que permite el desarrollo y la integración de sistemas software basados en servicios Web


Interoperabilidad (II)Interoperabilidad (II)CORBA (I)

La implementación CORBA permite la comunicación entre objetos de forma transparente al usario

ORB (Object Request Broker) media y dirige peticiones

Cliente Proxy-Cliente Broker Proxy-Servidor Servidor

método(proxy)

iniciarregistrar_servicio

puerto_asignadolocalizar_servidor

puerto_servidor

marshal

recibe_petición

unmarshalunmarshal

dispatch

método(impl.)

lt dresultado

marshalrecibe_resultado


unmarshalresultado


Interoperabilidad (III)Interoperabilidad (III)CORBA (II)

Separación entre la interfaz de los objetos y su implementación:p j y pLas interfaces para los objetos se especifican en lenguaje IDL (InterfaceDefinition Language), que forma parte del estándar CORBALa implementación se puede hacer con cualquier lenguaje que proporcioneenlaces con IDL

Para cada objeto servidor se codifica una interfaz IDL que contiene sólo las descripciones de datos:

Constantes, tipos, excepciones, atributos y métodos

Un compilador IDL transforma las especificaciones IDL en IDL- stubs (para los clientes) y en IDL- skeletons (para las implementaciones de objetos) en el lenguaje de programación elegido (Java, C++, etc.)Después de compilar la interfaz se implementa en el lenguaje de programación correspondiente para obtener la implementación del objeto servidor

<<Interfaz Java >><<Interfaz IDL >><<implements >>compilación


<<Interfaz Java >>IEjemplo Ejemplo<<Interfaz IDL >>

IEjemplo


Interoperabilidad (IV)Interoperabilidad (IV)Componentes de la arquitectura CORBA (I)

Objeto (servidor) : entidad que puede ser localizada por un ORB y aceptar peticiones de clientesCliente: entidad de programación que hace una petición a un objeto CORBA (invoca una operación sobre una implementación de un objeto)Obj t R t B k (ORB) C ( ú l ) id d d ft diObject Request Broker (ORB) Core (núcleo): unidad de software que media y dirige peticiones de los clientes CORBA a los objetos servidores CORBAInterfaz ORB: entidad lógica que desliga a las aplicaciones de los detalles de implementaciónimplementación

Métodos de desarrollo de software 147Arquitectura CORBA


Interoperabilidad (V)Interoperabilidad (V)Componentes de la arquitectura CORBA (II)

Stubs y skeletons CORBA IDL : constituyen la unión entre las aplicaciones li t idcliente y servidor

Compilador IDL: Automatiza la transformación de las definiciones CORBA IDL en el lenguaje de programaciónDII(Dynamic Invocation Interface): permite a un cliente acceder directamente aDII(Dynamic Invocation Interface): permite a un cliente acceder directamente a los mecanismos de petición subyacentes proporcionados por un ORBDSI (Dynamic Skeleton Interface): análogo a DSI pero del lado del servidorAdaptador de objetos: Asiste al ORB en las peticiones recibidas por el objeto y

l i ió d l bjen la activación del objeto

Métodos de desarrollo de software 148Arquitectura CORBA


Interoperabilidad (VI)Interoperabilidad (VI)Plataforma .NET

Nueva plataforma para el desarrollo y p p yexplotación de aplicaciones “gestionadas” (managed) modernas y orientadas a objetosorientadas a objetosLas aplicaciones .NET se pueden desarrollar en cualquier lenguaje de programación q e se aj sta a NETprogramación que se ajusta a .NET.NET soporta una extensa biblioteca de clases independientes del lenguaje de programación.NET soporta la creación de componentes auto-descriptiblescomponentes auto descriptibles.NET ofrece integración multilenguaje, reutilización de componentes, y h i t t

Plataforma .NET


herencia entre componentes desarrollados en diferentes lenguajes


Interoperabilidad (VII)Interoperabilidad (VII)Componentes de la plataforma .NET

Common Language Runtime (CLR): Entorno de ejecución de laCommon Language Runtime (CLR): Entorno de ejecución de la plataforma

Entorno donde se ejecutarán las aplicaciones .NET que han sido compiladas a un lenguaje común llamado Microsoft Intermediate Language (MSIL)un lenguaje común llamado Microsoft Intermediate Language (MSIL)

Microsoft Intermediate Language (MSIL) es el lenguaje de programación que generan los compiladores de lenguajes .NET

Es el código máquina de la máquina virtualEs el único código que es capaz de interpretar el CLR

.NET Framework Class Library (FCL): Añaden funcionalidad.NET Framework Class Library (FCL): Añaden funcionalidadLa librería de clases (FCL) es una librería formada por cientos de tipos que permiten acceder a los servicios ofrecidos por el CLR y a sus funcionalidades más frecuentemente usadasmás frecuentemente usadasEl programador puede crear nuevas clases que extiendan su funcionalidad y se integren perfectamente con el resto de las clases de la FCL

ASP NET: Versión Net de ASP Incluye los servicios Web


ASP.NET: Versión .Net de ASP. Incluye los servicios Web


Interoperabilidad (VIII)Interoperabilidad (VIII)Generación de código en la Plataforma .NET

Plataforma NET


Plataforma .NET


BibliografíaBibliografíaAlexander, C.; Ishikawa, S.; Silverstein, M., Jacobson, M.; Fiksdahl-King, I. y Angel, S. “A pattern Language”,

Oxford University Press, New York, 1977.Alonso, F.; Segovia F.J. “Entornos y metodologías de programación”, Paraninfo, 1995.

C “ f O O ” fBeck, K.; Cunningham, W. “A Laboratory for Teaching Object-Oriented Thinking”. In Proceedings of the 1989 OOPSLA - Conference proceedings on Object-Oriented Programming Systems, Languages and Applications (October 2 - 6, 1989, New Orleans, USA); Reprinted in Sigplan Notices, 24(10):1-6. 1989.

Booch, G.; “Object-Oriented Design with Applications”, Benjamin Cummings, 1991.Booch G ; “Object-Oriented Analysis and Design with Applications” Benjamin Cummings 1994Booch, G.; Object Oriented Analysis and Design with Applications , Benjamin Cummings, 1994.Bood, T. “Introducción a la programación orientada a objetos”, Adison-Wesley, 1994.Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. y Stal, M..”Pattern-Oriented Software Architecture. A

System of Patterns”. ohn Wiley & Sons Ltd., Chichester, UK, 1996Coad, P.; Yourdon, E. “Object-Oriented Analysis”´. 2nd Edition. Yourdon Press, 1991.Coleman, D.; Arnold, P.; Bodoff, S. “Object-Oriented Development: The Fusion Method”. Prentice-Hall, 1994Elrad, T., Filma, R. y Bader, A. (eds.), “Aspect-Oriented Programming”, en Comm. ACM (ed especial), 44(10),

2001.Fuentes, L., Troya, J. M., "MultiTel: Multimedia Telecommunication Service Framework. A chapter of the book

Domain Specific Application Frameworks: Frameworks Experience by Industry Chapter 21 pp 437 467Domain-Specific Application Frameworks: Frameworks Experience by Industry. Chapter 21, pp.437-467, Wiley & Sons. October 1999.

Fuentes, L., Troya, J.M. y Vallecillo A. "Documenting Web-based Application Frameworks“, Annals of Software Engineering, Vol. 13, pp. 249-264, June 2002.

Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. “Patrones de Diseño”. Addison Wesley, 2003., ; , ; , ; , y,Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. “Design Patterns: Elements of Reusable Object-Oriented

Software”. Addison Wesley, 1995.García Molina, J. “Patrones de diseño”, Material didáctico, http://dis.um.es/~jmolina.Graham, I. “Object-Oriented Methods”. 2nd Edition. Addison-Wesley, 1994.G d J C A i l t ti hit t f t i t d t i i I P di f th


Grundy, J.C. An implementation architecture for aspect-oriented component engineering, In Proceedings of the 2000 International Conference on Parallel and Distributed Processing Techniques and Applications, Las Vagas, CA, June 26-29 2000, CSREA Press, pp. 249-256, 2000.


BibliografíaBibliografíaGrundy, J.C. and Hosking, J.G. Developing Software Components with Aspects: Some Issues and Experiences,

Chapter 25 in Aspect-Oriented Software Development, Prentice-Hall, , pp. 585-604, 2004. Jacobson, I. “Object Oriented Development in an Industrial Environment”. In Proceedings of the 1987 OOPSLA -

C f di Obj t O i t d P i S t L d A li ti (O t bConference proceedings on Object-Oriented Programming Systems, Languages and Applications. (October 4-8, 1987, Orlando, FL USA). Pages 183-191. ACM, 1987

Jacobson, I.; Christerson, M.; Jonsson, P.; Overgaard, G. “Object-Oriented Software Engineering. A Use Case Driven Approach”, Adison-Wesley, 1992.

Jacobson I ; Booch G ; Rumbaugh J “The Unified Software Development Process” Object Technology SeriesJacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process . Object Technology Series. Addison-Wesley, 1999.

Larman, C. “UML y Patrones” 2ª ed., Pearson Educación, 2003.Martin, J. y Odell, J. “Object-Oriented Methods: A Foundation”. Englewood Cliffs, NJ., Prentice Hall, 1995.Meyer, B. “Construcción de software orientado a objetos”, Prentice Hall, 1998.Muller, P. A. “Modelado de objetos con UML”, Eyrolles-Ediciones Gestión 2000, 1997.OMG. The Common Object Request Broker: Core Specification, v. 3.0.3, marzo 2004

http://www.omg.org/docs/formal/04-03-01.pdfRubin, K. S.; Goldberg, A. “Object Behavior Analysis”. Communications of the ACM 35 (9): 48-62. September,

19921992.Rumbaugh, J.; Blaha, M.; Premerlani, W.; Frederick, E.; Lorensen, W. “Object-Oriented Modeling and Design”.

Prentice-Hall, 1991Shaler, S.; Mellor, S. “Object Life Cycles: Modeling the World in States”. Prentice-Hall, 1992.Yourdon, E.; Whitehead, K.; Thomann, J.; Oppel, K.; Nevermann, P. “Mainsteam Objects”, Prentice Hall, 1995.ou do , ; e ead, ; o a , J ; Oppe , ; e e a , a s ea Objec s , e ce a , 995Wirfs-Brock, R.; Wilkerson, B.; Wiener, L. “Designing Object-Oriented Software”. Prentice-Hall, 1990.Otras fuentes de información

Microsoft .NET SDK Framework Documentation


http://msdn.microsoft.com/netframework/http://www.microsoft.com/net/

as tema 3 - avellano.usal.esavellano.usal.es/~mmoreno/astema3.pdf · análisis y diseño orientado...

Documents