ASTema 3

Análisis de Sistemas
TEMA 3
Métodos de desarrollo de software
Desarrollo orientados a objetos
María N. Moreno García

Departamento de Informática y Automática
Universidad de Salamanca
Contenidos
1. Introducción
2. Desarrollo de software orientado a aspectos
3. Desarrollo de software orientado a servicios
4. Desarrollo de software orientado a objetos
5. 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)
Principales metodologías de desarrollo de software
Métodos estructurados
Descomposición funcional del sistema
Construcción de modelos de datos
Representación del flujo de información
Transformación de diagramas de flujo de datos en estructura
modular 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)
Desarrollo orientado a aspectos (AOSD) [Elrad et al., 2001]
Enfoque
q metodológicog p
para especificar,
p , diseñar y construir
aspectos
Aspectos: definen los intereses generales que ejercen un impacto
a través de la arquitectura
q del software

Introducción (II)
Otros enfoques de desarrollo de software
Desarrollo basado en componentes
Diseño y desarrollo de aplicaciones (distribuidas) basadas en
componentes software reutilizables
Reutilización:
Arquitecturas
Marcos de trabajo
Patrones de diseño
Componentes
Plataformas: ActiveX/OLE (COM), Enterprise Bean (JavaBeans),
Orbix (CORBA)…
( )
Desarrollo orientado a servicios
Creación de sistemas a partir de servicios autónomos
Arquitectura SOA (Service Oriented Architecture): infraestructura
de alto nivel para crear soluciones basadas en servicios
Servicios: entidades que se implementan, versionan y administran
de forma independiente
p

Desarrollo de software orientado a aspectos (I)

El desarrollo de software orientado a aspectos (Aspect Oriented
Software Development
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)
y especificación
ifi ió de
d las
l relaciones
l i entre
t ellos
ll
Composición posterior de propósitos mediante un mecanismo
adecuado para formar un sistema coherente
Características del software producido
Comprensible
Flexible
Buena modularidad
Ventajas:
Facilidad de mantenimiento
Adaptabilidad

Desarrollo de software orientado a aspectos (II)

Ingeniería de componentes orientada a aspectos [Grundy,
2000]
000] [G
[Grundy
u dy y Hosking,
os g, 2004]
00 ]
Utiliza el concepto de capas horizontales a través de
componentes de software descompuestos en forma vertical,
llamados aspectos,
aspectos para caracterizar propiedades generales de
los componentes
Aspectos:
Interfaces de usuario
Trabajo en colaboración
Distribución
P i t
Persistencia
i
Gestión de memoria
Procesamiento de transacciones
Seguridad ...
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)
Aspecto
p de actualización de p
pantalla

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

Desarrollo de software orientado a servicios (I)
Arquitectura SOA
Capas independientes
Integración de servicios implementados en diferentes lenguajes
y alojados
j en diferentes p
plataformas
Soporte a servicios Web
Tecnologías
XML ( eXtensible
Xt ibl M
Markup
k L Language):
) fformato
t estándar
tá d ded
representación de los datos
SOAP ( 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 para
descripción de servicios común y extensible
UDDI (Universal Description, Discovery and Integration):
estándares para describir y descubrir servicios

Desarrollo de software orientado a servicios (II)
Servicios Web
Aplicaciones programables cuya lógica es accesible usando

protocolos de Internet estándares
Sus clientes son otras aplicaciones

p
Representan funcionalidad en cajas negras que pueden
reutilizarse sin preocuparse por su implementación
Son
S accedidosdid víaí protocolos
t l W Webb ubicuos
bi y fformatos
t d de d
datos
t
como HTTP y XML
Una interfaz de servicio Web ppuede implementarse
p sobre
cualquier plataforma y en cualquier lenguaje de programación

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 subyacente
L especificación
La ifi ió SOAP consta
t de
d tres
t partes:
t
SOAP envelop: normas sobre el contenido de los mensajes
Reglas de codificación SOAP: mecanismos usados en el
intercambio de instancias de tipos de datos definidos en
aplicaciones
Representación
R t ió SOAP RPC:
RPC convenciones
i usadas
d en llas
llamadas a procedimientos remotos

Desarrollo de software orientado a servicios (IV)

<?xml version='1.0' ?>
<env:Envelope
env:Envelope xmlns:env
xmlns:env="http://www.w3.org/2002/06/soap-envelope">
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)
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 sobre
diferentes protocolos y codificaciones
Un 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 mensaje
El lugar en el que está disponible el servicio
El protocolo de comunicación utilizado

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
puertos
Un documento WSDL usa los siguientes elementos en la
definición:
Tipos: contenedor para definiciones de tipos de datos
Mensaje: definición abstracta y tipada de los datos que se
comunican
Operación:
p descripción
p abstracta de una acción soportada
p p
por el
servicio
Enlace: especificación de un formato de datos y un protocolo
concreto para un tipo de puerto particular
Puerto: un punto de red simple definido como una combinación de
un enlace y una dirección de red
Servicio: Colección de puertos relacionados

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
p de la p
plataforma y del modelo de p
programación
g
Usa XML, HTTP y SOAP
Libre en Internet

Desarrollo de software orientado a servicios (VIII)
UDDI (Universal Description, Discovery and Integration) (II)

4.
1. compañías SW, estándares y
programadores pueblan el registro
con descripciones de diferentes
tipos de servicio
Mercados, motores de
búsqueda y aplicaciones de
2. negocio consultan el registro
para descubrir servicios en
otras compañías
Registro de negocios UDDI
La empresas 5.
Registros Registros de
pueblan el registro de negocio tipo de servicio
con descripciones
de los servicios
3.
que ellas soportan UBR asigna un identificador Los negocios usan estos datos para
único a cada registro de servicio realizar más fácilmente la
y de negocio integración entre ellos sobre la Web

Desarrollo de software orientado a servicios (IX)
Registro de información en UDDI
Páginas Describen los datos de la

empresa (nombre, dirección,
Los negocios
g registran
g su
información. blancas información
f ó dde contacto ...))
Una entrada de información Describen las categorías

en UDDI en un documento Páginas industriales basadas en
XML que describe un negocio amarillas taxonomías estándares
(NAICS)
y los servicios que ofrece.
Tiene tres p
partes
Páginas
Pá i Describen la interfaz del
verdes servicio
Estándares, programadores y
negocios registran información Registros de
sobre sus tipos
p de servicios tipo
p de servicio

Desarrollo de software orientado a objetos (I)

Principios
Desarrollo de aplicaciones usando modelos basados en conceptos del mundo
real
Organización del software como una colección discreta de objetos que
incorporan datos (atributos) y comportamiento (operaciones o
p
procedimientos) )
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,
polimorfismo...
li fi
Análisis y diseño orientado a objetos
En 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
perspectiva
ti d
de lla clasificación
l ifi ió de
d objetos
bj t (identificación
(id tifi ió dde conceptos,
t atributos
t ib t 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
p satisfacer los requisitos
q
Vista dinámica: colaboraciones entre objetos
Vista 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 de
información que proporcionan una serie de servicios sobre la estructura
interna que implementan
Características Comportamiento visible
Estado: Conjunto de propiedades o atributos que Objeto

tiene el objeto (estructura estática) junto con los Estado interno
valores que pueden asumir cada una de estas
Representación del estado y
propiedades (estructura dinámica) comportamiento de un objeto
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 objeto
Selección: acceso al estado del objeto
Construcción: creación de un objeto e iniciación de su estado
Destrucció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ó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 objeto
Activación del objeto: reconstrucción del objeto por otro proceso
Transmisión (migración) de objetos: envío de objetos por un medio
de comunicación cualquiera de un espacio de direccionamiento a otro
Objetos espejo: alternativa a la transmisión de objetos mediante la
cual 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 objeto
Un bj t U clon
Un l
Soporte de comunicación
Transmisión de objetos
Contexto A Contexto B
U espejo
Un j U objeto
Un bj
Un cliente
Objeto 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ón
Segú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
activos
Servidores: son siempre destinatarios de los mensajes. Suelen ser
objetos pasivos que esperan que otro objeto requiera sus servicios
servicios. El
objeto que solicita el servicio actúa como cliente
Agentes: pueden interactuar con otros objetos en todo momento, por
iniciativa propia o como consecuencia de una solicitud externa. Forman
la base del mecanismo de delegación
Un agente
Un actor Un servidor
Categorías de objetos según su comportamiento

Desarrollo de software orientado a objetos (VI)

Comunicación entre objetos (II)
Encaminamiento
dinámico
Servidor 1
Un cliente Un agente Servidor 2
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 tareas
Garantiza el respeto de las restricciones
Un mensaje
j
Tiene un objeto emisor (expedidor) y un objeto receptor (destinatario)
Se puede implementar como una llamada a una operación o como una
señal
ñ l
Agrupa los flujos de control y los flujos de datos en una entidad única
Dato A
Dato B
Objeto 1 Objeto 2
Mensaje
Flujo de control y de datos del mensaje

Desarrollo de software orientado a objetos (VIII)

Comunicación entre objetos (IV)
Tipos de mensajes: describen diferentes formas de comunicación
entre objetos
Síncrono: el objeto emisor se bloquea hasta que el destinatario acepta
el mensaje.
j Generalmente es una llamada a un método
Así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 concurrente
De creación: crea un nuevo objeto
Perdido: se conoce la emisión del mensaje por el objeto emisor pero
no hay recepción del mensaje
Encontrado: se conoce al receptor del mensaje pero no al emisor
Retorno: respuesta del receptor de un mensaje al emisor de dicho
mensaje
Balking: sólo se envía si el receptor está preparado para aceptarlo
Time-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 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)
activar()
encender()
:Calentador :ControladorEntorno
fallo()
estaPreparado() <<time-out>>
reiniciar() :Luz
:Refrigerador
Ejemplo de sincronización

Desarrollo de software orientado a objetos (XI)

Clases (I)
Una clase describe un conjunto de objetos con propiedades similares,
relaciones comunes con otros y una semántica común
Los 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ón
Las clases son abstracciones que permiten crear categorías de
objetos. Todos los objetos son ejemplares o instancias de una clase
El proceso de crear objetos concretos a partir de una clase se
denomina instanciación
Nombre de clase
Atributos
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 partes
Especificación: describe el ámbito de definición y las propiedades de las
instancias
Realización: describe cómo se realiza la especificación, ya que contiene
el 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 la
especificación y los detalles en la realización
Interfaz de una clase: descriptor de las operaciones visibles
externamente de una clase
No ofrece implementación para ninguna de las operaciones
Se utiliza para especificar un servicio que ofrece una clase
La interfaz da nombre a un conjunto de operaciones que cooperan para
realizar un comportamiento de interés lógico
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
diferentes
t niveles
i l de d visibilidad
i ibilid d o accesibilidad
ibilid d
Niveles de visibilidad:
Nivel p
privado: visibilidad p
para la p
propia
p clase
Nivel protegido: visibilidad para la clases derivadas
Nivel público: visibilidad para todas las clases
Reglas de visibilidad
+ atributo público
# atributo
ib protegido
id
- atributo privado
+ operación pública ( )
# operación protegida ( )
- operación privada ( )
R
Representación
t ió d de llos niveles
i l d de visibilidad
i ibilid d en llas clases
l

Desarrollo de software orientado a objetos (XIV)

Clases (IV)
Marcador public class Marcador

- nDigitos: int {
- digitos: Vector
private Vector digitos;
private int nDigitos;
p g ;
+ digito (n:int) public void digito (int n);
# registroDigito (n:int):boolean
protected boolean registroDigito (int n);
}
Representación de los niveles de Implementación en Java de los

visibilidad de los miembros de la niveles de visibilidad de los miembros
clase Marcador 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 IBM
Una asociación describe un grupo de enlaces con una estructura y
una semántica comunes
Persona trabaja para empresa
public class Empresa

{
Empresa
// VectorPersonas es una especialización de
emplea
* // Vector (clase Java para arrays dinámicos)
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 asociaciones
Multiplicidad de la asociación especifica el número de instancias de la
clase que pueden estar relacionadas con una única instancia de una
clase asociada
Asociaciones cualificadas: tienen un atributo cualificador que permite
distinguir un conjunto de objetos del extremo muchos
Clase asociación: las asociaciones se modelan en forma de clase
public class Empresa

Empresa idPersona Persona {
private String idPersona;
cualificador public String getName ( ) {
Persona p = DB.getPersona
g ((idPer);
)
Empresa Persona return p.getName ( );
Trabajo clase }
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 amo-
amo
esclavo, todo-partes o agregado-componentes
Características de la agregación
Transitividad: si A es parte de B y B es parte de C, entonces A es parte de
C
Propagación
p g de operaciones
p ((activación):
) aplicación
p automática de una
operación a una red de objetos
Existen agregados recursivos: contienen directa o indirectamente una
instancia de esa misma clase de agregado
g g
Jefe
Empresa Servicio Sección Persona
Empleados
Agregación tipo
agregado-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 compuesto
La composición puede ser recursiva
Ventana
public class Ventana
- barraDeDesplazamiento [2]: Deslizador
- titulo: Cabecera {
- cuerpo: Panel
private Deslizador barraDeDesplazamiento [2];
private Cabecera titulo;
Ventana
1 private Panel cuerpo;
p p
2 1 1 }
Deslizador Cabecera Panel
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 un
conjunto de clases en una clase más general llamada superclase
La 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
Generalizació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)
La herencia
L h i es ell mecanismo
i por ell que las
l clases
l refinadas
fi d incorporan
i
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 superclase
Herencia 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
Es 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 p
para recoger
g características estructurales o de
comportamiento comunes a un conjunto de subclases
Una clase abstracta tiene que derivarse obligatoriamente
Las 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
abstract
b t t class
l A i l{
Animal
subclases: se produce cuando un protected String nombre;
servicio definido en una clase se abstract protected String comunica( );
redefine en alguna de sus subclases }
manteniendo la misma signatura class Perro extends Animal {
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:" +
Guau, guau!!! Miau, miau!!!
bolita.comunica( ) );
}
}
rufus bolita
Desarrollo de software orientado a objetos (XXIV)

Análisis (I)
Definición de procesos del dominio
Descripción de los principales requisitos funcionales del sistema
Se pueden representar como casos de uso
Modelo del dominio
También se denomina modelo conceptual, modelo de objetos del dominio
y modelo de objetos del análisis
Muestra clases conceptuales significativas en un dominio del problema
problema.
Una clase conceptual podría expresarse en términos de su
Símbolo: palabras o imágenes que representan la clase
Intensión: definición de la clase
Extensió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 se
define ninguna operación. Se muestran:
Objetos del dominio o clase conceptuales
Asociaciones entre clases conceptuales
Atributos de las clases conceptuales
Desarrollo de software orientado a objetos (XXV)

Análisis (II)
Ejemplo: jugar una partida de dados

Definició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:
Jugador 1 Lanza 2 Dado

nombre valorCara
1 2
Juega
1
JuegoDados 1 Incluye

Desarrollo de software orientado a objetos (XXVI)

Análisis (III)
Pasos para crear un modelo del dominio:
Listar las clases conceptuales candidatas
Utilización de una lista de categorías de clases conceptuales
Identificación de frases nominales
Representar las clases en un modelo del dominio
Añadir las asociaciones necesarias
Añadir
Añ di los
l atributos
t ib t necesarios
i y distinguir
di ti i entre
t atributos
t ib t
correctos e incorrectos
Añadir clases conceptuales
p de especificación
p cuando sea
oportuno
Producto EspecificacionDelProducto
descripcion descripcion 1 Describe * Articulo
precio precio numeroSerie
articuloID articuloID
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
j con responsabilidades
p
Responsabilidad: contrato u obligación de un objeto en cuanto a su
comportamiento
Tipos de responsabilidades: conocer y hacer
Realización de los casos de uso
Una 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 colaboran
Se representan mediante diagramas de interacción
Determinación de la visibilidad entre objetos
Visibilidad es la capacidad de un objeto de ver o tener una referencia a otro
Formas de visibilidad: de atributo,
atributo de parámetro,
parámetro local y global
Creación de los diagramas de clases de diseño
Representan las especificaciones de las clases e interfaces software. Contienen:
C ases, asoc
Clases, asociaciones
ac o es y aatributos
bu os
Interfaces con sus operaciones y constantes
Métodos
Información sobre los tipos de atributos
Navegabilidad
g
Dependencias

Desarrollo de software orientado a objetos (XXVIII)

Diseño (II)
Diseño de la arquitectura
Diseñ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 subsistemas
Arquitectura en capas: modelo general de n niveles para la
arquitectura lógica. Capas básicas:
Presentación (interfaz): clases encargadas de interaccionar con el
usuario y mostrar la información
Dominio (negocio o procesamiento): clases que contienen la lógica de la
aplicación
Almacenamiento: clases persistentes (base de datos y clases
adicionales)
Uso de patrones de arquitectura y de diseño
Despliegue de la arquitectura
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)
Vista 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

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 objetos
Extensión del modelado conceptual en el modelo entidad-relación
Métodos: OMT [Rumbaugh et al., 1991], FUSION [Coleman et al., 1994]
Di i id por llas responsabilidades

Dirigidos bilid d
Se centran en las responsabilidades de los objetos, es decir, las acciones
que puede llevar a cabo un objeto
La 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 uso

Los 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
(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 de
Lista d superclases
l
Lista de subclases
Responsabilidad 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 soporta
Las responsabilidades sólo determinan en una primera fase qué
acciones deben llevarse a cabo, pero no cómo
Responsabilidades
Conocimiento que tiene la clase
Acciones que puede realizar un objeto de la misma
Las colaboraciones representan peticiones por parte de un cliente a
los servidores para el cumplimiento de las responsabilidades del
cliente
Los
L servicios
i i se agrupan en contratos
t t
La relación entre las colaboraciones y las responsabilidades no es
de tipo
p 1:1

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 papeles
importantes
Capturar los requisitos funcionales del sistema. Aporta una visión de
“ j negra”” d
“caja dell sistema
i t
Simplificar la construcción de los modelos de objetos
Un modelo de casos de uso es un g
grafo con dos tipos
p de nodos
Actor: representa cualquier elemento que intercambia información con
el sistema, por lo que está fuera de él
Caso 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
estructurado
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
cliente
sistema del banco
transferencias
depositar dinero
operador administración
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ño
El 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)
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 estado
estados.
Modelo funcional: describe las transformaciones funcionales. Se
representa mediante DFDs
El diseño se desarrolla en dos etapas
Diseño del sistema
Di ñ d
Diseño de objetos
bj t

Métodos orientados a objetos (VII)

OMT (II)
Análisis – Modelo de objetos

j ((I))
Actividades:
Identificar los objetos y clases
Identificar
f asociaciones entre objetos
Identificar atributos de objetos y enlaces
Organizar y simplificar las clases de objetos empleando la herencia
Iterar y refinar el modelo
Identificar objetos y clases
Clases de
Identificación objetos
bj t Eliminar
Eli i clases
l Clases de
Cl d
Extraer nombres inadecuadas
de requisitos tentativas objetos

Métodos orientados a objetos (VIII)

OMT (III)
Análisis – Modelo de objetos (II)
Persona (Persona) (Persona)

Nombre: Juan López Ana Alonso
Edad: 52 19
Clase Instancias
Nombre de la clase
Nombre_atributo1: tipo_dato1=valor_por_defecto1
Nombre_atributo1: tipo_dato2=valor_por_defecto2
Nombre_operación1(lista_arg1): tipo_resultado1
N b
Nombre_operación2(lista_arg2):
ió 2(li t 2) ti
tipo_resultado2
lt d 2
N t ió OMT para clases

Notación l y objetos
bj t

Métodos orientados a objetos (IX)

OMT (IV)
Análisis – Modelo de objetos (III)
Id tifi
Identificar asociaciones
i i
Dependencia de dos o más clases
Referencia de una clase a otra
Pais Asociación Ciudad Diagrama

Nombre Nombre de clases
Su capital es
(Pais) (Ciudad)
España Madrid
Diagrama
Enlaces de
(Pais) (Ciudad) instancias
Suiza Berna
Representació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
Asociación ternaria
Métodos orientados a objetos (XI)

OMT (VI)
Análisis – Modelo de objetos (V)
Empresa Servicio Sección
Persona Microordenador
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

j ((VI))
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 herencia

Generalizar 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 ...
Refinamiento mediante la herencia
Iterar y refinar el modelo

Objetos 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)
El vuelo 123 parte para Paris
– Un 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
que transmiten
t it
Escenarios: Secuencia de eventos que ocurren durante una
ejecución
j p
particular del sistema
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)

Objeto1 Objeto2 Objeto3
Evento1
Evento2
Evento3
Evento4
E
Evento5
t 5
Evento6 Evento7
Evento8
Evento10 Evento9 Usuario Cajero Consorcio Banco
Insertar tarjeta
verificar tarjeta
verificar cantidad
cantidad mal
Diagramas de eventos
rechazar
expulsar tarjeta
tarjeta

Métodos orientados a objetos (XVI)

OMT (XI)
Análisis – Modelo dinámico (III)
Diagramas de
Di d estados:
t d E
Especifica
ifi lla secuencia
i dde estados
t d
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
turno Jaque mate

blancas Ganan
negras
Mueve Mueve
negra blanca
turno Jaque mate

negras Ganan
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 sistema
Especifica el significado de las operaciones en el modelo de objetos y
de las acciones en el modelo dinámico
F
Formadod por diagramas
di de
d flujo
fl j de
d datos
d t (DFDs)
(DFD ) que incluyen:
i l
Procesos: transforman los datos
Flujos de datos: mueven los datos
Almacenes de datos: objetos que almacenan los datos de forma estática
Actores: son objetos activos que conducen el flujo de datos produciendo o
consumiendo valores
Almacen1 Objeto1
P1 P2 P3
Objeto2 P4
Diagrama de flujo de datos

Métodos orientados a objetos (XVIII)

OMT (XIII)
Diseño
Diseño del sistema
Descomposición del sistema en subsistemas
Identificación de concurrencias
Asignación de subsistemas a procesadores y tareas
Manejo de acceso a recursos globales
Manejoj de excepciones
Asignación de prioridades
Diseño de objetos
Combinación de los modelos de análisis
Diseño de algoritmos y estructuras de datos
Definición de clases y objetos
Optimizar las vías de acceso a los datos
Implementar el control para interacciones externas
Ajuste de la herencia
Di ñ asociaciones
Diseño i i
Empaquetamiento 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].
Estructura lógica Nombre del paquete
Diagramas de clases
Tipo
Di
Diagramas d
de objetos
bj t
Estructura física Op
Diagramas de módulos
Diagramas de procesos Op
p
Dinámica de clases
Diagramas de transición de estados
Dinámica de instancias Representación de las clases como paquetes
Diagramas temporales
A B
A es cliente de B
Obj t
Objeto Cl
Clase
Relación cliente/servidor
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 y ssuss plantillas
asociadas
Diseño físico
Diagramas
g de módulos: segmentos
g de p
programa
g (p
(paquetes
q o funciones))
Diagramas de proceso: diagramas de bloques que muestran las relaciones de comunicación entre
dispositivos físicos y procesadores
Estructura dinámica
Diagramas 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
Operación 1
Objeto R
Operación 2
Objeto S
Objeto T Operación 3
Objeto U
Operación 4
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.,
al 1992]
Es un método dirigido por los casos de uso, técnica propuesta por el autor del
método
El 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 uso
Los casos de uso se utilizan en el análisis de requisitos
q
Enumeración de los escenarios principales para el funcionamiento del sistema
Los 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 objetos
los bj t colaboran
l b
Según continua el proceso de desarrollo estos escenarios iniciales se
expanden para considerar condiciones excepcionales, así como
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
Definición de d
dominios
i i reutilizables
tili bl
Modelos:
Modelo de información: muestra los objetos,
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
Método centrado en el análisis y basado en Identificador

el modelado de entidades y relaciones
Atributos
[Coad y Yourdon, 1991]
Aplicaciones comerciales
Temas: representan los niveles o capas de Métodos
DFD
Objetos: Se identifican los objetos con Clase genérica
detalle
Estructuras Identificador
De clasificación
f Atributos
De composición
Atributos: especificación de relaciones de
multiplicidad y modalidad Métodos
Servicios: Identificación de operaciones
((crear y borrar instancias,, tomar y poner
p Clase con instancias
valores y métodos especiales)

Notación de Coad y Yourdon
Métodos orientados a objetos (XXIV)

SOMA
SOMA (Semantic Object Model Approach)
[Graham 1994]
[Graham, Identificador
Método que combina una notación única para el Atributos
análisis OO con unas reglas del estilo de los
sistemas basados en el conocimiento Mét d
Métodos
Actividades Reglas
Identificar capas: Forma de descomponer el
d i i d
dominio dell problema
bl Clase
Identificar objetos
Identificador
Identificar estructuras
De clasificación
D l ifi ió Atributos
De composición
Definir la semántica de los datos y Métodos
asociaciones: Relaciones estructurales entre
Reglas
clases
Añadir atributos y operaciones a los objetos
Clase con instancias
Añadir la semántica declarativa de objetos:
Reglas para resolver conflictos
Notación de Graham
Reutilización
Reutilización: uso de componentes de un producto para facilitar el
desarrollo de productos diferentes con diferente funcionalidad
Accidental u oportunista
Deliberada o sistemática
Reusabilidad: facilidad con la que se pueden usar esos componentes en
situaciones nuevas
La reutilización sistemática de software proporciona bases para el
incremento de la calidad y la fiabilidad y a largo plazo reduce los costes del
desarrollo y mantenimiento de software
Un 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ón
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ón
Reutilizació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
j de clases abstractas y la forma en la cual sus instancias
interactú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 interfaces
Los patrones de capas estructuran el sistema en niveles o capas
con distintas responsabilidades
Patrones de diseño: “cada p patrón describe un p
problema qque
ocurre 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ón
Reutilización del diseño (II)
( )
(a) (b) ( )
(c) (d)
Representación simbólica de reutilización del diseño

( ) biblioteca,
(a) bibli t (b) fframework,
k ((c)) patrón
tó d de di
diseño,
ñ (d) arquitectura
it t software
ft
Las zonas sombreadas representan reutilización
Reutilización
Reutilizació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 partes
Un MT suele estar compuesto por una colección de patrones de diseño
Los MT se extienden normalmente en los puntos de entrada (hot spots o
hooks)
Según su aplicabilidad los MT pueden ser:
Horizontales:
H i l d di d a modelar
dedicados d l aspectos ddell sistema
i subyacente
b
Verticales: desarrollados específicamente para un dominio de aplicación
concreto
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 abstractos
Caja
j de cristal: admiten la inspección
p de su estructura e implementación,
p ,p
pero
no su modificación ni reescritura, salvo para sus puntos de entrada
Caja negra: se extienden mediante composición y delegación. No utilizan la
herencia
Caja gris: parte del interior de un MT o componente es público,
público el resto se
oculta
Reutilización
Reutilización del diseño (IV)
Extensibilidad de los marcos de trabajo
Hot spots: Puntos de refinamiento predefinido donde se produce la
adaptación o especialización. Permiten conectar una clase o subsistema
p
específico de una aplicación
p p
por
selección de un conjunto de clases o subsistemas suministrado en un MT de
caja negra
programació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
como base
b métodos
ét d hookh k elementales
l t l
Métodos hook: implementan los hot spots de un MT. El comportamiento
abstracto se adapta sobreescribiendo los métodos hook
Clases plantilla (template): clases que contienen los métodos plantilla
Clases hook: Clases que contienen los métodos hook

Reutilización
Reutilización del diseño (V)
Ejemplos de extensibilidad de MT
Metapatrón de unificación: flexibilidad en tiempo de desarrollo
calc larTasa()
calcularTasa()
<<abstract>>
Renta
imprimirFactura ()
TemplateHook calcularTasa()
metodoTemplate
p ()
metodoHook()
RentaConcr1 RentaConcr2
calcularTasa() calcularTasa()
Clases hook

Reutilización
Reutilización del diseño (VI)
Ejemplos de extensibilidad de MT
Metapatrón de conexión: flexibilidad en tiempo de ejecución
Template Hook
hookRef
metodoTemplate () metodoHook()
Renta calculo
ca cu o CalculoTasa
imprimirFactura() calcularTasa()
calculo.calcularTasa() CalculoTasaConcr1 CalculoTasaConcr2
calcularTasa() calcularTasa()

Reutilización
Reutilización del diseño (VII)
Ejemplos de marcos de trabajo
P
Programación
ió de
d Interfaces
I t f gráficas
áfi de
d usuario
i
MacApp
MFC (Microsoft Foundation Classes)
Java AWT y Swing g
Componentes visuales
OpenDoc
BlacKBox
M lti di
Multimedia
JMF (Java Media Framework)
Redes y comunicaciones
MultiTel (Multimedia TELecommunication services )
FIONA
Componentes distribuidos
CORBA
A ti X/OLE/COM
ActiveX/OLE/COM
JavaBeans
Aplicaciones Web - Java
Web MVC: Struts, JSF (Java Server Faces)
Abstracción de servicios: Spring
Persistencia: iBatis, Hibernate
Reutilización
Reutilización del diseño (VIII)
Modelo UML del MT MultiTel [Fuentes et al., 2002]

Reutilización
Reutilización del diseño (IX)
Framework Struts (http://struts.apache.org)

Reutilización
Reutilizació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 JavaBean
iBatis 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
Clases del patrón DAO

Reutilización
Reutilización del diseño (XI)
Patrones de arquitectura
Estilo arquitectónico: familia de arquitecturas restringidas por
Un vocabulario de componentes y conectores
Topología
p g
Restricciones semánticas
Patrón arquitectónico: se define para cada estilo de arquitectura
P
Proporciona
i una fforma all estilo
til arquitectónico
it tó i
Se centra en la identificación del problema, contexto del problema y en una
solución con sus consecuencias
Hace 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:
q Layers
y
Flujo de datos: Pipes & Filters
Sistemas distribuidos: Broker
Procesos interactivos: Model-View
Repositorios orientados a datos: Blackboard
…
Reutilización
Reutilizació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 relacionadas
Colaboració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
g capa
p de la jjerarquía
q
Conectores: protocolos/interfaces que definen la interacción entre
las capas
Solución:
Cada capa puede invocar operaciones de las capas inferiores
Las interfaces hacia las capas superiores están estandarizadas
Cada capa es independiente de sus capas superiores
Reutilización
Reutilización del diseño (XIII)
Patrones de arquitectura: Layers (II)
Presentación
Consecuencias:
Las capas se pueden desarrollar
independientemente (+)
Swing
…
Mantenimiento: se puede cambiar una
capa sin que afecte a otras capas (+)
R tili
Reutilización:
ió S Se pueden
d iintercambiar
t bi Dominio
diferentes implementaciones del mismo
nivel (+)
S
Soportet para la
l distribución
di t ib ió (+)
( )
Ventas MotorReglas
…
Estandarización basada en capas (p.ej.
OSI) (+)
Servicios Técnicos
El diseño de interfaces entre capas
puede ser difícil (-)
El rendimiento p puede verse afectado ((-)) Persistencia Jess
…
Reutilización
Reutilización del diseño (XIV)
Patrones de arquitectura: Layers (III)
Variante distribuida:
Cada una de las capas se puede distribuir
Cada capa
p en un nodo se conecta lógicamente
g con la correspondiente
p
capa en otro nodo
Capas relajadas:
Llamadas combinando varios componentes
p en una capa
p
Protocolo FTP
FTP FTP
Protocolo TCP
TCP TCP
Protocolo IP
IP IP
Protocolo Ethernet
Ethernet Ethernet
Conexión física
Variante distribuida
Reutilización
Reutilización del diseño (XV)
Patrones de arquitectura: Layers (IV)
U
Usos:
Aplicación
Protocolos de comunicación
Toolkits de sistemas de ventanas
Presentación
Sistemas operativos
S.I. Modelo de capas en una arquitectura lógica Sesión
Presentación: ventanas GUI, informes, interfaz de voz,
HTML, XML, XMLT, JSP, Javascript…
Aplicación: gestión de las peticiones de la capa de Transporte
presentación, flujo de trabajo, estado de la sesión,
transiciones a ventanas/páginas
ventanas/páginas, transformación de
datos Red
Dominio: gestión de las peticiones de la capa de
aplicación, reglas de dominio, servicios de dominio Enlace de datos
Infraestructura de negocio: servicios de negocio de
bajo nivel
Servicios técnicos: servicios técnicos de alto nivel, Física
persistencia y seguridad
Modelo OSI
Base: servicios técnicos de bajo nivel, estructuras de
datos, hilos, redes, BBDD
Reutilización
Reutilización del diseño (XVI)
Patrones de arquitectura: Layers (V)
Presentación Dominio Servicios Técnicos
Ventas MotorReglas Persistencia Jess

… …
Swing
…
Diagrama de interacción entre capas de una arquitectura

Reutilización
Reutilización del diseño (XVII)
Patrones de arquitectura: Layers (VI)
Arquitectura JSF-Spring-Hibernate
Capas:
Capa de presentación
Capa de lógica de negocio
Capa de integración
Características:
Orientada a servicios
Separación limpia de capas: uso de
ficheros de configuración XML
Uso con clientes ligeros
(navegadores web, wap…) y pesados
((Swing,
g, SWT…))
Inversión de control o inyección de
dependencias
Mapeo
p del modelo de clases a un
modelo objeto relacional
Arquitectura orientada a servicios
Reutilización
Reutilización del diseño (XVIII)
Patrones de arquitectura: Layers (VII)
Arquitectura
A i JSF
JSF-Spring-Hibernate
S i Hib
JSF (Java Server Faces)
Estándar de Sun para la capa de
presentación
t ió W Web
b
Patrón MVC
Modelo: Beans de respaldo
Vista: Páginas JSP
Controlador: Faces Servlet
Spring framework
(http://www.springframework.org)
Abstracción de servicios (SOA)
Publicación: ficheros XML
Localización: patrón Service Locator
Inversión de control (IoC)
Programación orientada a aspectos
Hibernate (http://www.hibernate.org)
Persistencia transparente
Arquitectura orientada a servicios
ORM (Object Relational Mapping)
Reutilización
Reutilización del diseño (XIX)
Patrones de arquitectura: Pipes & Filters (I)
Propósito:
Descomponer aplicaciones que procesan flujos de datos en filtros
reutilizables
Elementos:
Componentes: Filters
Leen flujos de datos de entrada y producen flujos de datos de salida
Transformación incremental local de los flflujos
jos de entrada
Los datos son procesados a medida que llegan
Conectores: Pipes
Conducen las salidas de un filtro a la entrada de otro
Flujo de datos (pipe)
Procesamiento Procesamiento Procesamiento
Procesamiento (filter)

Reutilización
Reutilizació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 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 (-)
()
Usos:
Filtros UNIX
C
Compiladores
il d
Optimizadores de código
Reutilización
Reutilización del código
Bibliotecas de clases (toolkits)
Conjunto de clases relacionadas y reutilizables diseñadas para
proporcionar funcionalidad útil de propósito general:
Científicas
Matemáticas
Interfaces gráficas de usuario (GUI) . . .
Las bibliotecas de código no imponen un diseño particular, sólo
proporcionan funcionalidad
El diseñador es el responsable de la lógica de control del producto
completo
Clases de biblioteca (toolkit) Marco de trabajo (framework)
Diferencias en la reutilización usando bibliotecas y marcos de trabajo

Patrones de diseño (I)

Un patrón de diseño ofrece una solución abstracta a un
problema de diseño q quee aparece m
muy frec
frecuentemente,
entemente
expresada mediante un conjunto de relaciones e
interrelaciones entre componentes
Elementos de un patrón:
N b
Nombre: d
describe
ib ell patrón
tó
Problema: explica el problema y su contexto
Solución: describe los elementos del diseño
diseño, sus relaciones
relaciones,
responsabilidades y colaboraciones
Consecuencias: resultados, ventajas
j e inconvenientes de aplicar
el patrón
Los patrones de diseño varían en su granularidad y nivel
de abstracción
Patrones de diseño (II)

Patrones POSA (Pattern-Oriented Software Architecture)
[B schmann et al
[Buschmann al., 1996]
Arquitectónicos: Layers, Pipes&Filters, Broker , MVC…
Diseño: Master-Slave,
Master Slave Proxy
Proxy, Command Processor,
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, Controlador
Otros patrones: Polimorfismo, Indirección, Fabricación Pura,
Variaciones Protegidas
P
Patrones GoF
G F (Gangs
(G off Four)
F ) [Gamma et al., 1995]
Patrones de diseño (III)

Clasificación de los patrones de diseño GoF [Gamma et al., 1995]
Según su propósito
De creación: relacionados con el proceso de creación de objetos
Estructurales: tratan la composición de clases u objetos
De 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 objetos
Propósito
De Creación Estructurales De comportamiento
I t
Interpreter
t
Clase Factory Method Adapter (de clases)
Template Method
Abstract Factory Adapter (de objetos) Chain of Responsibility
Builder Bridge Command
Prototype Composite Iterator
Ámbito Singleton Mediator
Decorator
Objeto Facade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
Patrones de diseño (IV)

Mecanismos de reutilización:
Herencia: definición de una implementación en términos de otra
Reutilización de caja blanca
Se define estáticamente en tiempo de compilación
Composición: la nueva funcionalidad se logra ensamblando o componiendo
objetos
Reutilización de caja negra
Se define dinámicamente en tiempo de ejecución
Delegació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
p q que usa. Éstos se p
proporcionan
p como p
parámetros cuando se
van a usar
Ventana Rectangulo
ancho
alto
area ( )
area ( )
return rectangulo->area ( ) return ancho * alto
Mecanismo de delegación Métodos de desarrollo de software 98

Patrones de diseño (V)

Patrón Abstract Factory (I)
Proporciona una interfaz para crear familias de objetos
relacionados o dependientes sin especificar la clase concreta
AbstractFactory
Cliente
CrearProductoA
CreateProductA() ()
CrearProductoB
CreateProductB()()
ProdAbstrA
AbstrProdA
ConcreteFactory1 ConcreteFactory2
ProdA2 ProdA1
CrearProductoA () CrearProductoA ()
CrearProductoB () CrearProductoB ()
AbstrProdB
ProdAbstrB
ProdB2 ProdB1

Patrones de diseño (VI)

Patrón Abstract Factory (II)
FabricaIGU
Cliente
crearBarraDesp()
crearMenu()
Menu
MotifFabricaIGU PMFabricaIGU
crearBarraDesp() crearBarraDesp() PMMenu MotifMenu
crearMenu() crearMenu ()
BarraDesp
PMBarraDesp MotifBarraDesp
Uso del patrón Abstract Factory en la creación de GUIs

Patrones de diseño (VII)

Patrón Abstract Factory (III)
A li bilid d
Aplicabilidad
Un sistema debe ser independiente de cómo se crean, se
componen y representan sus productos
Un sistema debería configurarse para una familia de productos
Una familia de objetos
j producto relacionados se diseña para
usarse conjuntamente y se debe cumplir esta restricción
Se quiere proporcionar una biblioteca de clases de productos y
se quiere revelar sólo la interfaz
interfaz, no la implementación
Consecuencias
Aísla las clases concretas
Facilita el intercambio de familias de productos
Promueve la consistencia entre productos
Es difícil soportar nuevas clases de productos

Patrones de diseño (VIII)

Patrón Builder (I)
Separa 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()
para todo objeto de la BuilderConcreto

estructura { Producto
builder.construirParte ( )} construirParte()
getResultado()

Patrones de diseño (IX)

Patrón Builder (II)
ConversorTexto
TraductorRTF
convertirCaracter()
analizarRTF() convertirCambioFont()
ConvertirParrafo()
ConversorASCII ConversorTeX
convertirCaracter() convertirCaracter()
getTextoASCII() convertirCambioFont()
convertirParrafo()
getTextoTeX()
TextoASCII TextoTeX
Uso del patrón Builder en la creación de un conversor de texto

Patrones de diseño (X)

Patrón Builder (III)
Aplicabilidad
El algoritmo para crear un objeto complejo debe ser
independiente de las partes componentes del objeto y de
cómo se ensamblan
El proceso de construcción debe permitir diferentes
representaciones del objeto que se construye
Consecuencias
Permite variar la representación interna de un producto
Aísla el código de representación del código de construcción
Proporciona un control fino sobre el proceso de construcción

Patrones de diseño (XI)

Patrón Factory Method (I)
Define una interfaz para crear un objeto
objeto, pero permite a las
subclases decidir la clase a instanciar: instanciación diferida a las
subclases
<<abstract> Creador
Producto
metodoFabricacion()
unaOperacion() prod = metodoFabricación()
CreadorConcreto
ProductoConcreto return
t new ProductoConcreto()
P d t C t ()
metodoFabricacion()

Patrones de diseño (VII)

Patrón Factory Method (II)
<<abstract>>
Documento Aplicacion
Documento d;
open() d = crearDocumento();
close() crearDocumento() setDoc.add(d);
save() nuevoDocumento() d.open()
revert() openDocumento()
MiAplicacion
p
MiDocumento
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)

Patrón Factory Method (III)
Aplicabilidad
Una clase no puede prever la clase de objetos que debe crear
Una clase desea q que sus subclases especifiquen
p q los objetos
j
que debe crear
Una clase delega responsabilidad a una entre varias subclases
auxiliares (helper) y se quiere localizar el conocimiento de en
qué subclase auxiliar concreta delega
Consecuencias
Evita ligar un código a clases específicas de la aplicación
Puede suceder que las subclases de Creador sólo se crean
con el fin de la creación de objetos
Mayor flexibilidad en la creación: subclases ofreciendo
versiones extendidas de un objeto
Conecta jerarquías de clases paralelas
Patrones de diseño (XIV)

Patrón Singleton (I)
Asegurar que una clase tiene una única instancia y asegurar un
acceso global
Singleton
static unicaInstancia
datosSingleton
return unicaInstancia
static instancia()
operacionSingleton()
getSingleton()
tSi l t ()
Singleton.instancia().operacionSingleton()

Patrones de diseño (XV)

Patrón Singleton (II)
Implementación
p en Java
public class Singleton {
private static Singleton unicaInstancia = null;
public
bli static
t ti Si
Singleton
l t iinstancia()
t i () {
if (unicaInstancia = = null) {
unicaInstancia = new Singleton()};
return unicaInstancia};
protected Singleton();
Implementación en C++
class Singleton { Singleton* Singleton::_unicaInstancia = 0;
public: Singleton* Singleton::_instancia ( ) {
static Singleton* instancia(); if (unicaInstancia = = 0) {
protected: _unicaInstancia = new Singleton;
Singleton(); }
private: return _unicaInstancia;
unicaInstancia;
static Singleton* _unicaInstancia; }
Patrones de diseño (XVI)

Patrón Singleton (III)
A li bilid d
Aplicabilidad
Debe existir una única instancia de una clase, accesible a los
clientes desde un punto conocido
Debe ser extensible mediante herencia y los clientes deben
ser capaces de usar una instancia extendida sin modificar su
código
ódi
Consecuencias
Acceso controlado a la única instancia
Espacio de nombres reducido. Evita usar variables globales
Permite generalizar a un número variable de instancias
Más flexible que las operaciones de clase
La clase Singleton
g puede tener subclases
p

Patrones de diseño (XVII)

Patrón Adapter (I)
Convierte la interfaz de una clase en otra q
que el cliente espera.
p
Permite la colaboración de ciertas clases que tienen interfaces
incompatibles
Dos tipos:
Adaptador de clases
Adaptador de objetos
Un adaptador de clases usa la herencia múltiple para adaptar las
interfaces
Objetivo Adaptable
Adaptado
Cliente
Cliente
peticion()
metodo1() peticiónConcreta()
especificoMet1()
<<implementation>>
Adapter
peticion()
p () especificoMet1
peticiónConcreta()

Patrones de diseño (XVIII)

Patrón Adapter (II)
Un adaptador de objetos se basa en la composición de objetos
Adaptable
Adaptado
Objetivo
Cliente
peticion() peticionConcreta()
especificoMet1()
Adapter
peticion() +adaptable
adaptable. peticionConcreta()

Patrones de diseño (XIX)

Patrón Adapter (III)
Forma
EditorDeDibujo
marco()
crearManipulador()
return texto.getExtension
Linea FormaTexto
marco() marco()
crearManipulador() crearManipulador()
+texto return new ManipuladorTexto
*
VistaTexto
getExtension()

Patrones de diseño (XX)

Patrón Adapter (IV)
Aplicabilidad
Se desea usar una clase existente y su interfaz no coincide con la que se
necesita
Se desea crear una clase reutilizable q
que debe colaborar con clases no
relacionadas o imprevistas
Se 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
Consecuencias
i
Adaptador de clases
Sólo adapta una clase Adaptable concreta
Permite a la clase Adaptador redefinir parte del comportamiento de
Adaptable
No implica ninguna indirección, sólo introduce un objeto
Adaptador de objetos
Permite adaptar una clase y sus subclases, pudiendo añadir funcionalidad
a todos los adaptados a la vez
Hace más difícil redefinir comportamiento de Adaptable y que el adaptador
se refiera a la subclase

Patrones de diseño (XXI)

Patrón Composite (I)
Compone 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
Cliente
operacion()
i ()
añadir(Componente)
eliminar(Componente)
obtenerHijo(int)
H j
Hoja Composite
operacion() operacion()
añadir(Componente)
eliminar(Componente) +hijos
hijos
obtenerHijo(int)

Patrones de diseño (XXII)

Patrón Composite (II)
Figura
dibujar()
añadir(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)

Patrón Composite (III)
A li bilid d
Aplicabilidad
Se quiere representar jerarquías parte/todo
Se quiere que los clientes ignoren la diferencia entre objetos
compuestos y los objetos individuales que los forman
Consecuencias
Define jerarquía con clases formadas por objetos primitivos y
objetos compuestos de manera recursiva
Simplifica el cliente
cliente. Los clientes pueden tratar objetos
primitivos y compuestos de modo uniforme
Facilita la adición de nuevos tipos de componentes
Puede 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
requieren comprobaciones en tiempo de ejecución
Patrones de diseño (XXIV)

Patrón Decorator (I)
Asigna responsabilidades adicionales a un objeto dinámicamente
dinámicamente.
Alternativa flexible a la herencia para extender la funcionalidad.
Componente
operacion()
CompConcreto
Decorator
operacion()
p () +componente
operacion() componente.operacion()
DecoratorConcrB
DecoratorConcrA
estadoAdicional
estadoAdicional
super.operacion;
operacion() comportAdicional();
operacion() comportAdicional()

Patrones de diseño (XXV)

Patrón Decorator (II)
ComponenteVisual
mostrar()
VistaTexto
Decorator
mostrar()
mostrar()
() +componente
componente.mostrar
t t ()
DesplazamientoDecorator BordeDecorator
posicionDesplazamiento anchoBorde
mostrar() mostrar() super.mostrar;

super mostrar;
desplazarA() mostrarBorde() mostrarBorde ();

Patrones de diseño (XXVI)

Patrón Decorator (III)
Aplicabilidad
Añadir objetos individuales de forma dinámica y transparente
Responsabilidades de un objeto pueden ser retiradas
Cuando la extensión mediante la herencia no es viable
Consecuencias
Más flexibilidad que la herencia estática: se pueden añadir y
eliminar responsabilidades en tiempo de ejecución
Evita que las clases de la parte alta de la jerarquía estén
cargadas de funciones
Un decorador y su componente no son idénticos
Sistemas formados por muchos objetos pequeños. Dificultad
de comprensión y depuración

Patrones de diseño (XXVII)

Patrón Facade (I)
Proporciona 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
Clases del subsistema

Facade

Patrones de diseño (XXVIII)

Patrón Facade (II)
Compilador
Clases del subsistema compilar()

de compilación
Flujo Lexico Token
Sintactico Simbolo
FlujoDeCodigoDeBytes Constructor NodoPrograma NodoPrograma
GeneradorDeCodigo
NodoInstruccion ...
NodoExpresion
GeneradorDeCodigoRISC ...
NodoVariable
GeneradorDeCodigoMaquinaDePila

Patrones de diseño (XXIX)

Patrón Facade (III)
Aplicabilidad
Proporcionar una interfaz simple a un subsistema complejo
Hay muchas dependencias entre clientes y las clases que
implementan una abstracción
Se desea dividir en capas el subsistema: una fachada define el
punto de entrada para cada nivel del subsistema
Consecuencias
Co secue c as
Oculta a los clientes los componentes del subsistema
Proporciona un acoplamiento débil entre un subsistema y los
clientes: cambios en los componentes no afectan a los clientes
No se impide a las aplicaciones clientes el uso de las clases
del subsistema

Patrones de diseño (XXX)

Patrón Proxy (I)
Proporciona un representante o sustituto (surrogate) de un objeto
para controlar el acceso a éste
Sujeto
Cliente
peticion()
SujetoReal Proxy
+sujetoReal sujetoReal.peticion()
peticion() peticion()

Patrones de diseño (XXXI)

Patrón Proxy (II)
Grafico
EditorDocumentos dibujar()
getExtension()
guardar()
cargar()
I
Imagen P
ProxyImagen
I
impImagen nombreFich if (imagen == null)
extension extension {imagen = cargarImagen(nombreFich)}
imagen.dibujar()
dibujar() dibujar()
getExtension() +imagen getExtension() if (imagen == null) {
guardar() guardar() return extension}
lcargar() cargar() else {imagen.getExtension ()}

Patrones de diseño (XXXII)

Patrón Proxy (III)
Aplicabilidad
Siempre 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)
Proxyy virtual ((crea objetos
j costosos sobre demanda))
Proxy para protección (controlar acceso al objeto original)
Referencia inteligente (sustituto de un puntero que lleva a cabo
operaciones adicionales)
Consecuencias
Un proxy remoto oculta el hecho que un objeto reside en un
espacio de direcciones diferentes
Un proxy virtual puede realizar optimizaciones tales como crear
un objeto por encargo
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)

Patrón Iterator (I)
Proporciona un modo de acceder secuencialmente a los elementos
de un objeto agregado sin exponer su representación interna
Iterator
Agregado
Cliente
primero()
crearIterador()
siguiente ()
haTerminado()
elementoActual()
AgregadoConcreto
g g
crearIterador() IteradorConcreto

Patrones de diseño (XXIV)

Patrón Iterator (II)
IteradorLista
Lista
+lista índice
contar()
p
primero()
()
insertar(elemento)
siguientet()
eliminar(elemento) haTerminado()
elementoActual()
ListaAbstracta Iterator
crearIterador()
Cliente p
primero()
()
contar()
insertar(elemento) siguientet()
haTerminado()
eliminar(elemento)
elementoActual()
Lista IteradorLista
ListaConSaltos IteradorListaConSaltos

Patrones de diseño (XXXV)

Patrón Iterator (III)
Aplicabilidad
Acceder a un objeto agregado sin exponer su representación
interna
Permitir varios recorridos sobre objetos agregados
Proporcionar
p una interfaz uniforme p
para recorrer diferentes
estructuras agregadas (iteración polimórfica)
Consecuencias
Permite variaciones en el recorrido de un agregado
Los iteradores simplifican la interfaz agregado
S puede
Se d h
hacer más
á d de un recorrido
id a lla vez sobre
b un
agregado

Patrones de diseño (XXXVI)

Patrón Mediator (I)
Define un objeto que encapsula como interaccionan un conjunto
de objetos. Favorece un bajo acoplamiento, liberando a los
objetos de referenciarse unos a otros explícitamente, y permite
variar la interacción de manera independiente
Mediator +mediator Colega
MediatorConcreto ColegaConcr1 ColegaConcr2

Patrones de diseño (XXXVII)

Patrón Mediator (II)
DirectorDialogo
+director
di t Util
mostrarDialogo()
crearUtiles() director.utilModificado(this)
modificado()
utilModificado(Util)
DirectorDialogoFuente ListaDesplegable CampoDeEntrada

+lista
lista
crearUtiles()
getSeleccion() setTexto()
+campo

Patrones de diseño (XXXVIII)

Patrón Mediator (III)
:Cliente DirectorDialogoFuente :ListaDesplegable :CampoDeEntrada
mostrarDialogo()
getSeleccion()
setTexto()

Patrones de diseño (XXXIX)

Patrón Mediator (IV)
Aplicabilidad
Un 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
comprender
Es 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 í ser adaptado
debería d d sin
i crear muchas
h subclases
b l
Consecuencias
Reduce la herencia
Desacopla a los colegas
Simplifica los protocolos de los objetos
Abstrae cómo cooperan los objetos
Centraliza el control Métodos de desarrollo de software 133
Patrones de diseño (XL)

Patrón Observer (I)
Define una dependencia de uno a muchos entre objetos
objetos, de forma
que cuando un objeto cambie de estado se notifique y se
actualicen todos los objetos que dependen de él.
Sujeto +observers Observer
adscribir(Observer) 1 1
1..1 1..*
1.. actualizar()
quitar(Observer)
notificar()
Para todo o en observers

{o actualizar()}
{o.actualizar()}
SubjetoConcreto
ObserverConcreto
estadoSujeto
estadoObserver
+sujeto estadoObserver =
obtenerEstado() actualizar()
establecerEstado() return estadoSujeto sujeto.obtenerEstado()

Patrones de diseño (XL)
Si
Sistema +observers Observer
adscribir(Observer) 1..1 1..* actualizar()

quitar(Observer)
notificar()
Para todo o en observers

{o.actualizar()}
RelojAnalógico
SistemaConcreto +sujeto
estadoAnalógico RelojDigital
estadoSujeto
estadoDigital
actualizar()
obtenerEstado()
actualizar()
establecerEstado() +sujeto
return estadoSujeto
estadoAnalógico =
estadoDigital
t d Di it l =
sujeto.obtenerEstado()
sujeto.obtenerEstado()
almacena información horaria

Patrones de diseño (XLI)

Patrón Observer (II)
90
80
2tr
Vistas
70
60
50
Este 4tr
40
Oeste
30
20
Norte 1tr
10
0
3tr
1er trim
trim. 2do 3er trim
trim.4to
4to trim
trim.
trim.
1tr. 2tr. 3tr. 4tr.

Modelo Este 20 25 90 20
t1=20
Oeste 30 38 32 32
t2=25 Norte 47 47 45 45
t3=90
t4=20

Patrones de diseño (XLII)

Patrón Observer (III)
:Otra :SistemaConcreto :Reloj Analógico :RelojDigital
1. establecerEstado()
1.1. notificar()
1.1.1. actualizar()
1.1.2. actualizar()

Patrones de diseño (XLII)

Patrón Observer (III)
:Otra :Sujeto o1:Observer o2:Observer
1. establecerEstado()
1.1. notificar()
1.1.1. actualizar()
1.1.2. actualizar()

Patrones de diseño (XLIII)

Patrón Observer (IV)
Aplicabilidad
Cuando una abstracción tiene dos aspectos y uno depende de
otro
Cuando un cambio de estado en un objeto requiere cambios
en otros objetos, y no sabemos cuántos objetos necesitan
cambiarse
Cuando un objeto debe ser capaz de notificar algo a otros
objetos, sin hacer asunciones sobre quiénes son estos
objetos
Consecuencias
Permite modificar independientemente sujetos y observers
Acoplamiento abstracto entre Sujeto y Observer
Capacidad de comunicación mediante difusión
Actualizaciones inesperadas
Patrones de diseño (XLIV)

Patrón State (I)
Permite a un objeto cambiar su comportamiento cuando cambia
su estado. El objeto parece cambiar de clase
Contexto +state State
petición() manejar()
state.manejar()
StateConcr1 StateConcr2
manejar() manejar()

Patrones de diseño (XLV)

Patrón State (II)
TCPConexion TCPEstado
+estado
abrir() abrir()
cerrar() cerrar()
acuseRecibo() acuseRecibo()
TCPEstablecida TCPEscuchando TCPCerrada

estado.abrir()
abrir() abrir() abrir()
cerrar() cerrar() cerrar()
acuseRecibo() acuseRecibo() acuseRecibo()

Patrones de diseño (XLVI)

Patrón State (III)
Aplicabilidad
El comportamiento del objeto depende de su estado, y debe
cambiar su comportamiento en tiempo de ejecución
dependiendo de su estado
Las 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
Consecuencias
Localiza el comportamiento dependiente al estado y lo divide
entre diferentes estados
Hace explícitas las transiciones entre estados
Los objetos State pueden ser compartidos
Portabilidad
Un producto se considera portable si es significativamente menos costoso
adaptarlo a una nueva plataforma que construirlo desde el principio
Sistema
Programa Compilador Hardware
operativo
P C H S
P’ C’ H’ S’
Si el coste de convertir P en P’
P es significativamente menor que el coste de codificar P’
P desde el
principio, entonces P es portable
Incompatibilidades
Hardware
H d
Sistema operativo
Software numérico
Compilador
Recomendaciones para lograr la portabilidad:
Aislar las partes dependientes de la implementación
Utili
Utilizar estándares
tá d d
de programación
ió
Utilizar ficheros de datos sin estructura
Interoperabilidad (I)
Operación mutua de código objeto de diferentes vendedores, escrito
en diferentes lenguajes y ejecutándose en diferentes plataformas
Estándares que promueven la interoperabilidad:
CORBA (Object Request Broker Architecture)
Estándar internacional y OMG (Object Management Group) para sistemas
orientados a objetos
Soporta la interoperabilidad de aplicaciones ejecutándose en diferentes
máquinas en un entorno distribuido
Interoperabilidad
p entre vendedores,, redes,, lenguajes
g j y sistemas operativos
p
Tecnología sencilla
COM (Component Object Model)
Propuesto por Microsoft
Proporciona un entorno basado en objetos para desarrollar aplicaciones
interoperables en diferentes dominios
Uso de un mecanismo común para todas las situaciones en que un
componente proporciona servicios a otro componente
Mecanismo de comunicación propietario de Microsoft
Tecnología muy compleja
.NET
Tecnología de Microsoft que permite el desarrollo y la integración de sistemas
software basados en servicios Web
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

iniciar
registrar_servicio
método(proxy)
localizar_servidor
puerto_asignado
puerto_servidor
marshal
recibe_petición
unmarshal
dispatch
método(impl.)
resultado
lt d
marshal
recibe_resultado
resultado unmarshal

Interoperabilidad (III)
CORBA (II)
Separación
p entre la interfaz de los objetos
j y su implementación:
p
Las interfaces para los objetos se especifican en lenguaje IDL (Interface
Definition Language), que forma parte del estándar CORBA
La implementación se puede hacer con cualquier lenguaje que proporcione
enlaces 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
compilación <<implements >>
<<Interfaz IDL >> <<Interfaz Java >>
Ejemplo
IEjemplo IEjemplo
Interoperabilidad (IV)
Componentes de la arquitectura CORBA (I)
Objeto (servidor) : entidad que puede ser localizada por un ORB y aceptar
peticiones de clientes
Cliente: 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 Request
Object R t Broker
B k (ORB) Core C ( ú l ) unidad
(núcleo): id d d
de software
ft que media
di y
dirige peticiones de los clientes CORBA a los objetos servidores CORBA
Interfaz ORB: entidad lógica que desliga a las aplicaciones de los detalles de
implementación
Arquitectura CORBA
Interoperabilidad (V)
Componentes de la arquitectura CORBA (II)
Stubs y skeletons CORBA IDL : constituyen la unión entre las aplicaciones
cliente
li t y servidor
id
Compilador IDL: Automatiza la transformación de las definiciones CORBA IDL en
el lenguaje de programación
DII(Dynamic Invocation Interface): permite a un cliente acceder directamente a
los mecanismos de petición subyacentes proporcionados por un ORB
DSI (Dynamic Skeleton Interface): análogo a DSI pero del lado del servidor
Adaptador de objetos: Asiste al ORB en las peticiones recibidas por el objeto y
en la
l activación
i ió ddell objeto
bj
Arquitectura CORBA
Interoperabilidad (VI)
Plataforma .NET
Nueva pplataforma p
para el desarrollo y
explotación de aplicaciones
“gestionadas” (managed) modernas y
orientadas a objetos
Las aplicaciones .NET se pueden
desarrollar en cualquier lenguaje de
programación q que
e se aj
ajusta
sta a .NET
NET
.NET soporta una extensa biblioteca
de clases independientes del lenguaje
de programación
.NET soporta la creación de
componentes auto-descriptibles
auto descriptibles
.NET ofrece integración multilenguaje,
Plataforma .NET
reutilización de componentes, y
h
herenciai entre
t componentest
desarrollados en diferentes lenguajes
Interoperabilidad (VII)
Componentes de la plataforma .NET
Common 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)
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 virtual
Es el único código que es capaz de interpretar el CLR
.NET Framework Class Library (FCL): Añaden funcionalidad
La 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 usadas
El 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
ASP.NET: Net de ASP
ASP. Incluye los servicios Web

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

Bibliografía
Alexander, 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.
Beck, K.; Cunningham,
C W. ““A Laboratory for
f Teaching Object-Oriented
O O Thinking”.
” In Proceedings off 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
Booch, G.;; “Object-Oriented
Object Oriented Analysis and Design with Applications”
Applications , Benjamin Cummings
Cummings, 1994 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, 1996
Coad, 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, 1994
Elrad, 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
Domain-Specific Industry. Chapter 21,21 pp.437-467,
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, y, 2003.
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 JJ.C.
Grundy, C AAn iimplementation
l t ti architecture
hit t ffor aspect-oriented
t i t d componentt engineering,
i i IIn P
Proceedings
di off th
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ía
Grundy, 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
Conference proceedings
di on Obj
Object-Oriented
t O i t d Programming
P i S
Systems,
t Languages
L anddA Applications.
li ti (O t b
(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 II.;; Booch
Jacobson, Booch, G G.;; Rumbaugh
Rumbaugh, JJ. “The
The Unified Software Development Process
Process”. Object Technology Series
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.pdf
Rubin, K. S.; Goldberg, A. “Object Behavior Analysis”. Communications of the ACM 35 (9): 48-62. September,
1992.
1992
Rumbaugh, J.; Blaha, M.; Premerlani, W.; Frederick, E.; Lorensen, W. “Object-Oriented Modeling and Design”.
Prentice-Hall, 1991
Shaler, S.; Mellor, S. “Object Life Cycles: Modeling the World in States”. Prentice-Hall, 1992.
ou do , E.;; Whitehead,
Yourdon, e ead, K.;; Thomann,
o a , JJ.;; Oppe
Oppel,, K.;; Nevermann,
e e a , P. “Mainsteam
a s ea Objec
Objects”,
s , Prentice
e ce Hall,
a , 1995.
995
Wirfs-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/

ASTema 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ASTema 3

Cargado por

Copyright:

Formatos disponibles

Análisis de Sistemas

María N. Moreno García

Métodos de desarrollo de software 2

Métodos de desarrollo de software 3

Métodos de desarrollo de software 4

Desarrollo de software orientado a aspectos (I)

Métodos de desarrollo de software 5

Desarrollo de software orientado a aspectos (II)

Métodos de desarrollo de software 6

Desarrollo de software orientado a aspectos (III)

Métodos de desarrollo de software 7

Desarrollo de software orientado a aspectos (IV)

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

Métodos de desarrollo de software 8

Desarrollo de software orientado a servicios (I)

Métodos de desarrollo de software 9

Desarrollo de software orientado a servicios (II)

Aplicaciones programables cuya lógica es accesible usando

Sus clientes son otras aplicaciones

Métodos de desarrollo de software 10

Desarrollo de software orientado a servicios (III)

 SOAP (Simple Object Access Protocol) :

Métodos de desarrollo de software 11

Desarrollo de software orientado a servicios (IV)

Ejemplo de mensaje SOAP

Desarrollo de software orientado a servicios (V)

 WSDL (Web Services Description Language) (I)

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

WSDL proporciona a los proveedores de servicios una manera

Métodos de desarrollo de software 13

Desarrollo de software orientado a servicios (VI)

 WSDL (Web Services Description Language) (II)

Métodos de desarrollo de software 14

Desarrollo de software orientado a servicios (VII)

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

Métodos de desarrollo de software 15

Desarrollo de software orientado a servicios (VIII)

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

Métodos de desarrollo de software 16

Desarrollo de software orientado a servicios (IX)

 Registro de información en UDDI

Páginas Describen los datos de la

 Una entrada de información Describen las categorías

Métodos de desarrollo de software 17

Desarrollo de software orientado a objetos (I)

Desarrollo de software orientado a objetos (II)

 Estado: Conjunto de propiedades o atributos que Objeto

 Comportamiento: Forma en que actúa un objeto al recibir un estímulo externo

Desarrollo de software orientado a objetos (III)

Métodos de desarrollo de software 20

Desarrollo de software orientado a objetos (IV)

Objeto definido en el contexto B y su espejo en el contexto A

Desarrollo de software orientado a objetos (V)

Categorías de objetos según su comportamiento

Desarrollo de software orientado a objetos (VI)

Un cliente Un agente Servidor 2

Ilustración del mecanismo de delegación

Métodos de desarrollo de software 23

Desarrollo de software orientado a objetos (VII)

Flujo de control y de datos del mensaje

Desarrollo de software orientado a objetos (VIII)

Métodos de desarrollo de software 25

Desarrollo de software orientado a objetos (IX)

SOAP (Simple Object Access Protocol) :

WSDL (Web Services Description Language) (I)

WSDL (Web Services Description Language) (II)

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

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

Registro de información en UDDI

Una entrada de información Describen las categorías

Estado: Conjunto de propiedades o atributos que Objeto

Comportamiento: Forma en que actúa un objeto al recibir un estímulo externo

Ejemplo: jugar una partida de dados

Di i id por llas responsabilidades

Dirigidos por los casos de uso

OMT (Object Modeling Technique) fue propuesto por Rumbaugh

Análisis – Modelo de objetos

Identificar objetos y clases