4.4.

Diseño basado en
Componentes (UML)

 Chesmann
b. Desarrollo con reutilización

definitivos
 Desarrollo Basado en
Componentes
 Encontrar e integrar componentes reutilizables.
 Es indispensable buscar un equilibrio entre los requisitos ideales
y los servicios prestados por los componentes disponibles.
 (1) Determinar los requisitos -- no cambia
 (2..3) La búsqueda (negociación incluida) de posibles componentes
que satisfagan los requisitos impuestos tanto por el cliente como
por la arquitectura de la aplicación
 (4) Diseño de la arquitectura basada en componentes

 (5) La búsqueda y evaluación de los componentes candidatos para

seleccionar los más idóneos, incluyendo su Validación.
 (6) La adaptación y/o extensión de los componentes seleccionados
para que se ajusten a los requisitos. Integración, configuración e
interconexión de dichos componentes para construir la aplicación
final
 Selección de componentes
 Confianza
 Se debe poder confiar en el proveedor de un componente.
 Un componente puede que no funcione como se anuncia, y en
el peor de los casos, puede violar la seguridad del sistema
 Requisitos
 Diferentes componentes pueden satisfacer los diferentes
requisitos de forma parcial

 Los componentes pueden tener una funcionalidad no deseada.

¿Cómo se puede probar que no va a interferir con mi
aplicación?
 Validación de componentes
 Desarrollo de un conjunto de casos de prueba para un
componente (o extender los casos de prueba suministrados )

 Desarrollo de una aplicación de prueba para ejecutar las

pruebas

 El principal problema es que la especificación del componente

no sea lo suficientemente detallada

 Además de probar que un componente hace lo que se necesita,

hay que comprobar que el componente no incluye ningún
código malicioso o bloquear la funcionalidad que no es
necesaria
 El caso del Ariane 5
 En 1996, la primera prueba de vuelo del cohete Ariane 5
terminó en desastre cuando el lanzador se salió de control 37
segundos después de despegar

 El problema se debió a un componente proveniente de una

versión anterior del cohete lanzador (el sistema de navegación
inercial) que fracasó porque la precondición necesaria para una
función de ese componente no la cumplió el Ariane 5

 La funcionalidad que falló en este componente no se necesitaba

en el Ariane 5!
 Arquitectura del sistema
 Subsistemas e interfaces forman la arquitectura física
 Se organizan las interfaces y subsistemas para crear
la arquitectura:
 Los subsistemas están dispuestos según el patrón
arquitectónico capas.
 Capa de presentación, capa de Dominio (Lógica de negocio),
capa de Servicios, capa de Utilidades …

 Cada subsistema (componente o paquete de biblioteca)

encaja en alguna de ellas

 Las dependencias entre capas van en una sola dirección (y a

través de interfaces si son componentes o bibliotecas API)
Arquitectura en capas
«ClientJEE»
GUI
Presentación «library»
javax.swing Sales Manager

Customer Product
Manager Manager
«component» «component» «component»
Customer Sales Product

Dominio/
Lógica de Account
Manager
Negocio

«component»
Accounts

«subsystem»
Persistencia Persistence
«library»
java.sql
Puede integrarse en
cada componente
 Larman, C. “UML y Patrones. Introducción al Análisis y Diseño
Orientado a Objetos y al Proceso Unificado ”. Prentice Hall, 2002

Subsistemas de diseño
UI

Web

Dominio

Ventas Basico Productos

Persistencia

Productos-Ventas Clientes
 Transformar en componentes
 Las dependencias entre subsistemas se pueden
implementar con conectores
 Utilizar el patrón Fachada!
 Las interfaces se pueden utilizar para crear las "costuras" de
un sistema:
 Identificar las partes cohesivas del sistema
 Empaquetar éstas en un componente
 Definir una interfaz para cada componente
 Dependencias -> interfaces
UI

Web

Dominio

Ventas Productos

Pero difícil de
Reutilizar!!
Persistencia

Productos-Ventas
 Dependencias -> interfaces
UI

Web

Ventas
Productos

Ventas.Dominio Productos.Dominio

Ventas.Persistencia
Productos.Persistencia
 Acitividades de Diseño
(enfoque Top Down)
 Diseño paso a paso…

Asignar
Identificar Diseñar las Diseñar los Verificar los
responsabilidades a
Interfaces Interfaces componentes requisitos…
componentes
 Actividades de diseño
 Identificar Interfaces  Operaciones del Sistema
 Asignar responsabilidades  componentes (caja negra)
 Diseñar en detalle las Interfaces, incluyendo las que
interconectan los componentes
 Organizar en paquetes y diseñar los componentes (caja
blanca)

 Verificar los requisitos funcionales y comparar contra

escenarios (CU)

 Analizar interacciones y flexibilidad del sistema

 Ejemplo: Biblioteca
 Se pueden consultar (todos los ejemplares) o prestar
ejemplares (de ciertos tipos)
 El préstamo es diferente para profesor o alumno
Dominio

prestamos
Después DS y añadir operaciones:
Clases <<Control>>
<<control>> <<control>>
GestorPrestamos GestorCatalogo

Prestamo

0..* 0..* Ejemplar

EjPrestable
1
1

Usuario EjCD EjRevista

EjLibro

inv: prestamos->size() <9

Alumno Profesor
inv: prestamos->forAll(duracion <91)

inv: prestamos->size() <4

inv: prestamos->forAll(duracion <16)
 1. Identificar Interfaces
 Utilizar los requisitos funcionales para identificar
responsabilidades (a partir de los casos de uso) de
alto nivel
 La interfaces agrupan conjuntos de operaciones
relacionadas
 Información manejada
 Servicios Ofrecidos
 2. Asignar Responsabilidades
a los componentes
 Después de identificar componentes candidatos, se
les asignan responsabilidades claras (Interfaces)
 Identificar los componentes que realizarán esas
responsabilidades
 Evaluar los componentes identificados contra los
criterios de diseño deseables

 Iterar sobre los pasos anteriores hasta obtener un conjunto

de componentes
 Prever interfaces requeridas para plug-in alternativos
(características o algoritmos)
Componentes básicos

<<interface>>
Iconsultar

<<interface>>
IPrestar

+ buscarUsuario() : Usuario
+ crearPrestamo() : void
+ devolverPrestamo() : void
 Responsabilidades
 IPrestar debe incluir las operaciones de prestar y
devolver un ejemplar
 Iconsultar incluirá búsqueda de ejemplares por título,
por signatura, etc
 Caja negra:

ComponentePrestamos
IPrestar
Iconsultar

ComponenteCatalogo
 3. Diseñar las Interfaces
 Para cada interfaz del componente definir en detalle
las Operaciones ofrecidas o requeridas por la
interfaz:
 Parámetros de entrada y salida: objetos? int o String?
 Pre y post-condiciones
 Efectos de cada operación
 Naturaleza de la Interfaz (llamada síncrona, mensaje
asíncrono, Web Service)
 Para su definición se puede utilizar
 UML+OCL
 Lenguajes de programación
 IDLs
 [Organizar en puertos]
 Encontrar más interfaces
 Herencia e Interfaces!
 Estudiar cada asociación:
 ¿La asociación tiene que ser a otra clase, o puede ser a una
interfaz?
 Estudiar los mensaje enviados:
 ¿El mensaje tiene que ser enviado a otra clase, o puede
utilizar una interfaz?
 Buscar grupos de operaciones repetidas, que puedan
ser útiles en el futuro  PARA REUTILIZACIÓN
 ¿Algún componente ya existe en la empresa? ¿Se
puede adquirir?  CON REUTILIZACIÓN
 4. Diseñar los componentes
 4.1. “Romper” el modelo original en paquetes
 4.2. Eliminar las posibles asociaciones que cruzan las
fronteras
 ¿Es necesario exportar alguna clase?
 ¿Puede usarse un DTO común?
 [El DTO más simple es el que corresponde al identificador de
esa clase]

 4.3. Completar el diseño interno en capas de cada

componente (según lo visto en el capítulo anterior)
 Organizar en paquetes…
ComponentePrestamos
ComponenteCatalogo

<<interface>>
<<interface>> Iconsultar
IPrestar

+ buscarUsuario() : Usuario
+ crearPrestamo() : void
+ devolverPrestamo() : void

<<interface>>
IPrestable
<<control>>
GestorPrestamos + buscarEjemplarP() : EjPrestable
<<control>>
GestorCatalogo

Prestamo
Ejemplar
0..*
0..*
1 Usuario
EjRevista

EjPrestable
1
Profesor
Alumno
 Paquetes no asociados…
ComponentePrestamos
ComponenteCatalogo
<<interface>>
<<interface>> Iconsultar
IPrestar

<<interface>>
IPrestable
<<control>>
GestorPrestamos
<<control>>
GestorCatalogo

Prestamo
- duracion : int
- fecha : Date
- ejemplar : EjPrestable
Ejemplar
0..*
1 Usuario
EjRevista

EjPrestable

Alumno

Profesor
EjPrestable
 …y Componentes
¿Interfaces locales?
ComponentePrestamos
ComponenteCatalogo
<<control>>
IPrestar GestorPrestamos IPrestable

Iconsultar

<<control>>
GestorCatalogo
Prestamo

0..*
Ejemplar
1
Usuario

Alumno
Profesor EjPrestable EjRevista
 IPrestar
¿…o Interfaces remotas?
IPrestable

Iconsultar
ComponentePrestamos
ComponenteCatalogo

<<control>>
GestorPrestamos <<control>>
GestorCatalogo

Prestamo

0..* Ejemplar
1
Usuario

Alumno
Profesor EjPrestable EjRevista
 UML: Caja Blanca
IPrestable
IPrestar

Iconsultar
ComponentePrestamos
ComponenteCatalogo

IPrestar IPrestable
IPrestable
Iconsultar

Iconsultar
<<control>>
GestorPrestamos <<control>>
GestorCatalogo

Prestamo

0..* Ejemplar
1
Usuario

Alumno
Profesor EjPrestable EjRevista
Caja Negra: las dos opciones
ComponentePrestamos
IPrestar
Iconsultar

ComponenteCatalogo
IPrestable

<<JEE app>> ComponenteBiblioteca

<<EJB modulo>>
Iconsultar cp : ComponentePrestamos
IPrestar

<<EJB modulo>>
cc : ComponenteCatalogo
IPrestable
 5. Verificar requisitos
 5.1. Verificar los requisitos funcionales
 Hacer el seguimiento de cada requisito, utilizando la
estructura funcional
 Utilizar una tabla de requisitos funcionales contra componentes
del modelo estructural

 5.2. Verificar los casos de uso

 Analizar la estructura funcional propuesta, junto con los
participantes, a través de los casos de uso.
 Detalle casos de uso
: Alumno
: Bibliotecario : GestorPrestamos : UsuarioFacadeLocal : IPrestable : PrestamoFacadeLocal

buscarUsuario() : Usuario
buscarUsuario() : usuario

comprobarLimite() : boolean

crearPrestamo() : void
buscarEjemplarP() : EjPrestable

crearPrestamo() : void

<<create>>
Prestamo() prestamo : Prestamo

create(prestamo)
 6. Análisis crítico
 6. Análisis de Interacciones
 Analizar la estructura propuesta en busca de interacciones
excesivas (acoplamiento excesivo entre los componentes)
 7. Análisis de Flexibilidad
 Escenarios “what if ”, ¿qué pasaría si…?
 Algunos errores frecuentes
 Mala definición de interfaces
 Mala definición de responsabilidades
 Componentes de tipo utilidad modelados como
componentes funcionales (listados, informes)
 Nivel inapropiado de detalle

 Número elevado de dependencias

 “God component” / “Manager”
 50% de las responsabilidades en menos del 25% de los
componentes
 Lista final de control
 ¿El modelo tiene un número razonable de componentes?
 ¿Todos los componentes tienen nombre, responsabilidades
claras e interfaces claramente definidas?
 ¿Todas las interacciones entre los componentes ocurren a
través de interfaces y conectores entre ellas?
 ¿Los componentes tienen una alta cohesión y bajo
acoplamiento?
 ¿Se ha validado la estructura propuesta contra los requisitos
funcionales?
 ¿Ha considerado como se porta la arquitectura en escenarios
hipotéticos de cambio?
Ejemplo:
Videoclub
 Ejemplo: Videoclub [on line]
Diseñar un sistema basado en componentes a partir del ejemplo presentado en:
“Metodología para la Elicitación de Requisitos de Sistemas Software” y
“Metodología para el Análisis de Requisitos de Sistemas Software”, Amador Durán
Toro y Beatriz Bernárdez Jiménez. Universidad de Sevilla.

Se trata de un videoclub con películas (de cada una existen varios ejemplares cada
una). Mantiene información sobre las películas, los socios y los alquileres. La forma de
pago es con cargos y abonos en una cuenta.
Algunos Casos de Uso
39
40
 Modelo de Dominio

Cuenta

+ cargarAlquiler(a : Alquiler, imp : float) : void

+ registrarIngreso(imp : float) : void

Socio
ArtistaCine 1 1
- numero : int 0..*
- nombre : String - dni : String 1 {ordered} Movimiento
- nombre : String - fecha : Date
- fechaNacimiento : Date - importe : float
- fechaAlta : Date
- direccion : String
- telefonos : int[1..*]
+ buscarSocio(dni : String) : Socio
Actor Director + crearAlquiler(c : Cinta) : void
Ingreso
1 Cargo
1..* 1 + Ingreso() : void
Productora
0..*
- nombre : String 1 0..* 0..*
0..* Pelicula Alquiler CargoAlquiler
1 1
- titulo : String - fechaAlquiler : Date
<<enum>> + CargoAlquiler() : void
- año : int - horaAlquiler : float
Tema
- tema : Tema 1 - fechaDevolucion : Date[0..1] 1
- infantil : int - duracion : float 0..* - horaDevolucion : float[0..1]
1
0..* 0..1
- accion : int - estaDevuelto : boolean = false
CargoMulta
Cinta + Alquiler() : void
- numero : int
+ buscarCinta(n : int) : Cinta
4.4.1.
Composición y adaptación
 Composición de componentes
 Es el proceso de ensamblaje de componentes para crear un
sistema.
 La composición involucra la integración de los componentes
entre sí y con la infraestructura de componentes.
 Normalmente hay que escribir “código pegamento” (“glue
code”) para integrar los componentes
 Tipos de composición
 a: Composición secuencial
 los componentes se ejecutan en secuencia. Esto implica
componer las interfaces que proporciona cada componente.
 b: Composición jerárquica
 uno de los componentes usa los servicios de otro. La interfaz
proporcionada de un componente se conecta con la interfaz
requerida de otro
 c: Composición aditiva
 Las interfaces de dos componentes se unen para crear un
nuevo componente. Las interfaces del componente
integrado son una combinación de las interfaces de los
componentes constituyentes.
 Compatibilidad de interfaces
 Incompatibilidad de parámetros
 Las operaciones tienen el mismo nombre pero los parámetros o el
resultado que devuelve son de tipos diferentes

 Incompatibilidad operaciones
 Los nombres de las operaciones en las interfaces compuestas son
diferentes

 Ausencia de operaciones
 La interfaz que proporciona el interfaz de un componente es un
subconjunto de la interfaz que requiere de otro
 Ejemplos de adaptación
 Recolector de datos y sensor
 Glue code
 Ej: adaptador que extrae el código postal de addressFinder con
postCodeStripper y lo pasa al componente mapper

address = addressFinder.location (phonenumber) ;

postCode = postCodeStripper.getPostCode (address) ;
mapper.displayMap(postCode, 10000)
 Adaptación y semántica
 Biblioteca de fotos
 Semántica y sintaxis
 Estudiar la documentación de los componentes para
saber si interfaces que son sintácticamente
compatibles son realmente compatibles:

/* Este método agrega una fotografía a la biblioteca y

asocia el identificador de fotografía y descriptor de
catálogo con la fotografía*/
public void addItem (Identifier pid, Photograph p,
CatalogEntry photodesc) ;

/* Otros… */
public Photograph retrieve (Identifier pid) ;
public CatalogEntry catEntry (Identifier pid) ;
 Semántica y sintaxis
 ¿qué pasa si el identificador de la fotografía ya está
asociado con una fotografía en la biblioteca?

 ¿Está la fotografía asociada con la entrada de

catálogo?
 Si elimino la entrada del catálogo ¿elimino la fotografía en
sí?
 Si elimino la fotografía, ¿también se debe borrar la
información del catálogo?
 OCL
public void addItem (Identifier pid , Photograph p,
CatalogEntry photodesc) ;

context addItem(Identifier pid , Photograph p, CatalogEntry

photodesc)
pre: PhotoLibrary.libSize() >= 0
PhotoLibrary.retrieve(pid) = null
post:libSize () = libSize()@pre + 1
PhotoLibrary.retrieve(pid) = p
PhotoLibrary.catEntry(pid) = photodesc

context deleteCatEntry (pid)

pre: PhotoLibrary.catEntry(pid) <> null
post: PhotoLibrary.catEntry(pid) = null
PhotoLibrary.libSize() = libSize()@pre—1
PhotoLibrary.retrieve(pid) = PhotoLibrary.retrieve(pid)@pre
 Semántica (Expresiones OCL)
 La biblioteca debe existir
 No puede haber una fotografía en la biblioteca con el
mismo identificador que la fotografía que se quiere
incluir
 Cada entrada aumenta el tamaño de la biblioteca en
un elemento
 Si se recupera utilizando el mismo identificador a
continuación, se obtiene la foto que ha añadido
 Si se busca en el catálogo utilizando ese
identificador, entonces devolverá la entrada de
catálogo que acaba de insertar
4.6.
Despliegue de componentes
 Implementación y despliegue
Modelo de diseño Modelo de implementación/despliegue

Los componentes
se realizan con «device»
n1 node
artefactos físicos
que los
implementan «component»
c1 «artifact»
a1
El modelo de
despliegue describe artifact
donde se
encuentran «device»
físicamente n2
«component» «artifact»
c2 a2
 Modelo de despliegue
 Describe cómo se distribuye la funcionalidad en nodos
físicos
 Se modela la traducción de la arquitectura de software a la
arquitectura del sistema físico
 Es el modelo del sistema como artefactos desplegados
en los nodos o recursos computacionales
 Los nodos tienen relaciones que representan los métodos de
comunicación entre ellos, por ejemplo http, iiop, netbios
 Los artefactos representan software, por ejemplo, un .JAR,
.class o .exe
 Pasos del Diseño de la arquitectura física:
 Determinar nodos y conexiones
 Despliegue de artefactos
 UML: diagramas de
Despliegue
 «device» y «execution environment» son esteretipos
estándar

«device» «device»
WindowsPC LinuxServer

0..* «http» 0..*

«execution environment» «execution environment»
IE9 GlassFish
 Artefactos
 Un artefacto representa un elemento concreto, como
un archivo
 Puede ser desplegado en los nodos
 Instancias de Artefactos se despliegan en instancias de
nodos
 Un artefacto puede “manifestar” uno o más
componentes
 El artefacto representa la manifestación física de los
componentes (por ejemplo, un archivo JAR con varios EJBs)
 «artifact»

Relaciones jdom.jar

 Con los «artifact»

componentes que librarySystem.jar

realiza
«manifest» «manifest» «manifest»
 Con otros
artefactos: «component»
Book
«component»
Library
«component»
Ticket
 Dependencia ISBN TicketID
 Composición 1 1
LibraryImpl
1 1

BookImpl TicketImpl

Book Library Ticket

 Estereotipos estándar UML
 «executable» .jar, .war, .ear, .class, .EXE
 «library» .jar, .DLL
 «script» .js
 «deployment spec» persistence.xml

 «document» .DOC, .TXT, ...

 «source» .java
 «file»
 UML Java Profile
 Además de puede utilizar un perfil específico
(conjunto de estereotipos para Java)
«JAR»
librarySystem.jar

«JavaClassFile» «JavaClassFile» «JavaClassFile» «JavaClassFile» «JavaClassFile»

ISBN.class BookImpl.class LibraryImpl.class TicketImpl.class TicketID.class

«JAR» «JavaClassFile» «JavaClassFile» «JavaClassFile»

jdom.jar Book.class Library.class Ticket.class

«directory»
META_INF

«file»
MANIFEST.MF
UML Java Profile

«device»
Server: WindowsPC

«device» «RMI» «execution environment»

client:WindowsPC JEE Server
«JAR» «JAR»
ConverterClient.jar ConverterApp.jar

«deployment spec»
converterDeploymentSpecification
BeanClass: ConverterBean
BeanName: ConverterBean
BeanType: StatelessSession
Ejemplo simple
 Presentación

Dominio-DTO <<Servlet>>
Controller
<<entity>> - fecha_arranque : String JSPs
Manufacturer - num_accesos : int
- manufacturerId : Integer - url : String
- name : String # processRequest() : void
- addressline1 : String # doGet() : void
- addressline2 : String # doPost() : void
- city : String + getServletInfo() : String
- state : String
- zip : String
- phone : String
- fax : String
- email : String
- rep : String ManufacturerManagerRemote

Despliegue

<<Stateless EJB>>
ManufacturerManager

Acceso a Datos

ManufacturerFacadeLocal <<Stateless EJB>>

ManufacturerFacade

# getEntityManager() : EntityManager
+ ManufacturerFacade()
 Aplicacion.war
<<Servlet>>

Módulos:
Controller

<<entity>>
Manufacturer

 Ejemplo típico ManufacturerManagerRemote

con dos
proyectos:
 .war
 .jar Aplicacion.jar

<<Stateless EJB>>
ManufacturerManager

ManufacturerFacadeLocal <<entity>>
Manufacturer

<<Stateless EJB>>
ManufacturerFacade
 Dos servidores:
Servidor Web y Servidor JEE
PC WIndows/Linux
0..* 1
Chrome.exe <<http>> Servidor TomCat

Aplicacion.war

1..*
<<http>>
1
Servidor EJB

Aplicacion.jar
Servidor Linux/Oracle 1 1
Base Datos
 Un servidor (y servidor BD)
Servidor GlassFish
PC WIndows/Linux Aplicacion.ear
Chrome.exe Aplicacion.war

Aplicacion.jar

Servidor Linux/Oracle

Base Datos

 (en este caso, mejor todas las interfaces locales)

 Despliegue y Diseño:
Recordatorio
 Cuando se usa más de un servidor, hay que definir
interfaces remotas
 Eso influye en la forma de diseñar el Acceso a Datos:
 perdemos la referencia directa a la instancia
 No hay acceso directo a la clases Entity (hay que colocarlas
en una biblioteca compartida)

 El rendimiento disminuye con interfaces remotas y

con los EJB Stateful