Enterprise Java Bean 3 (EJB 3)

DEPARTAMENTO DE SISTEMAS
Enterprise Java Bean 3
(EJB 3)
Agenda
DEPARTAMENTO DE SISTEMAS
•  Introducción
•  EJB 3
o 
o 
o 
Características
Beneficios
Arquitectura EJB 3
•  Session Bean
o 
o 
o 
Stateless Session Bean
Stateful Session Bean
Localización Session Bean
•  Desarrollo por Componentes
Introducción
DEPARTAMENTO DE SISTEMAS
Introducción
DEPARTAMENTO DE SISTEMAS
•  Contenedor EJB 3
o 
o 
o 
o 
o 
o 
Soporta concurrencia
Provee pools para administrar varias instancias de componentes,
Balanceo de carga y clustering
Provee (JNDI), para acceder a los EJB o a otros recursos
Soporta Java RMI-IIOP (Remote Method Invocation run over Internet InterOrb Protocol), el cual permite el acceso remoto de un cliente a un session
bean
Soporta mensajería que proveen los message-driven beans
Tomado de: EJB 3 in action
Agenda
DEPARTAMENTO DE SISTEMAS
•  Introducción
•  EJB 3
o 
o 
o 
Características
Beneficios
Arquitectura EJB 3
•  Session Bean
o 
o 
o 
Stateless Session Bean
Stateful Session Bean
Localización Session Bean
•  Desarrollo por Componentes
EJB
DEPARTAMENTO DE SISTEMAS
“Enterprise JavaBeans is an architecture for componentbased transaction-oriented enterprise
applications.” (JSR 220: Enterprise JavaBeansTM,Version 3.0)
“Un enterprise bean es un componente de lado del
servidor que encapsula la lógica del negocio de una
aplicación”.(Java EE 5Tutorial)
“Es una plataforma para construir aplicaciones de
negocios portables, reutilizables y escalables usando
lenguaje de programación JAVA” (EJB 3 In action, Debu Panda)
Características
DEPARTAMENTO DE SISTEMAS
• 
Contienen lógica de negocio, que opera sobre los datos de la
empresa
• 
Las instancias de un enterprise bean son administradas en tiempo
de ejecución por un contenedor
• 
Los servicios como transacción y seguridad, pueden ser
especificados junto con la lógica del negocio de la clase enterprise
bean en la forma de anotaciones, o en un descriptor de despliegue
XML
• 
El acceso del cliente es mediado por el contenedor en el cual el
enterprise bean es desplegado. Este acceso es transparente para
el cliente
• 
El contenedor asegura que los beans y sus clientes pueden ser
desplegados en múltiples ambientes de ejecución sin recompilación
• 
El estándar EJB 3 es desarrollado por Java Community Process
(JCP)
Beneficios
DEPARTAMENTO DE SISTEMAS
•  Simplifican desarrollo, el contenedor EJB es
responsable de la administración de transacciones y
autorizaciones de seguridad.
•  La lógica del negocio reside en los enterprise beans y
no en el lado del cliente, permitiendo que el desarrollo
del lado del cliente esté desacoplado de la lógica del
negocio.
•  Los enterprise bean son componentes portables,
reutilizables y pueden ser desplegados en servidores
que usen los estándares del API JEE.
•  Pueden residir en diferentes servidores y pueden ser
invocados por un cliente remoto.
Beneficios
DEPARTAMENTO DE SISTEMAS
•  Se deben utilizar en los siguientes casos:
o 
Aplicaciones que deben ser escalables, esto implica
distribución de componentes a través de múltiples
máquinas
o 
Aseguramiento de integridad de los datos de las
transacciones.
Los enterprise beans soportan
transacciones y el mecanismo que administra el
acceso concurrente de objetos compartidos
o 
Muti-usuarios locales y remotos
EJBs
DEPARTAMENTO DE SISTEMAS
•  Tipos de componentes EJB 3
o 
o 
o 
Session beans
Message-driven beans
Entity bean
Tomado de: EJB 3 in action
Estructura Enterprise Java Bean
DEPARTAMENTO DE SISTEMAS
• 
• 
Una aplicación EJB debe contener:
o  Componentes enterprise bean
o  Interfaces que definen los métodos que implementan las
componentes
o  Clases helper: clases utilitarias requeridas por los enterprise
bean
Se empaqueta en un archivo EJB.jar, son portables y pueden ser
empaquetados en un archivo EAR.
Tomado del libro JavaEE Tutorial
Agenda
DEPARTAMENTO DE SISTEMAS
•  Introducción
•  EJB 3
o 
o 
o 
Características
Beneficios
Arquitectura EJB 3
•  Session Bean
o 
o 
o 
Stateless Session Bean
Stateful Session Bean
Localización Session Bean
•  Desarrollo por Componentes
Session Bean
DEPARTAMENTO DE SISTEMAS
•  Que son los componentes session bean?
“Son una tecnología EJB que permiten encapsular procesos de
negocio” (EJB 3 developer guide)
Cliente
Web, local
o remoto
Contenedor EJB 3
Interfaz
Clase Bean
Provee todas las
definiciones de los
métodos
Provee
implementaciones de
los métodos
Implementa
Local
Remota
Session Bean
DEPARTAMENTO DE SISTEMAS
•  Características:
o 
o 
o 
o 
o 
o 
Vida corta, si el servidor falla la sesión se pierde
No manejan persistencia
No es compartido entre clientes
Pueden actualizar y crear entidades, estas últimas son
persistentes
Un cliente (WEB como JSP o servlet y un cliente aplicación
standalone) interactúa con un session bean a través de la
invocación de sus métodos (esta invocación se llama sesión)
Un componente session bean es un POJO anotado.
Tomado de: EJB 3 in action
Session Bean
DEPARTAMENTO DE SISTEMAS
•  Un session bean está compuesto por una o más
interfaces y una clase de implementación.
•  Un cliente puede acceder a un session bean
solamente a través de
métodos definidos en la
interfaz del bean.
•  La interfaz de define la vista al cliente de un bean.
•  Un Session Bean puede ser invocado a través de RMI
a través de una interfaz:
o 
Remota
o 
Local
Session Bean
DEPARTAMENTO DE SISTEMAS
•  Un cliente remoto invoca una interfaz remota
de un session bean
Tomado del libro EJB 3 Developer Guide
Session Bean
DEPARTAMENTO DE SISTEMAS
•  El cliente remoto puede ejecutarse en una máquina
diferente y una JVM diferente al enterprise bean que
accede.
•  Un cliente remoto puede ser un componente web, una
aplicación cliente u otro enterprise bean.
•  Para el cliente remoto la ubicación del enterprise bean
es transparente
•  La interfaz remota define el ciclo de vida de los métodos
que son especificados en el enterprise bean.
Session Bean
DEPARTAMENTO DE SISTEMAS
•  Definición de un session bean con interfaz
remota.
o 
o 
Definir la interfaz anotada con @Remote
Definir la clase que implementa la interfaz
Estado
Opcional
Session Bean
DEPARTAMENTO DE SISTEMAS
•  Un cliente local puede invocar un session bean a
través de una interfaz local. En este caso el
cliente reside en la misma instancia del session
bean.
Tomado del libro EJB 3 Developer Guide
Session Bean
DEPARTAMENTO DE SISTEMAS
•  El cliente local debe correr en la misma JVM
que los enterprise bean que accede
•  El cliente local puede ser un componente web
u otro enterprise bean.
•  La interfaz local define el ciclo de vida de los
métodos del bean.
•  La interfaz por defecto es local
Session Bean
DEPARTAMENTO DE SISTEMAS
•  Definición de un session bean con interfaz local.
o 
o 
Definir la interfaz anotada con @Local
Definir la clase que implementa la interfaz
Session Bean
DEPARTAMENTO DE SISTEMAS
•  El estado de un objeto se compone de los valores de
sus variables de instancia.
•  Las instancias de las variables representan el estado
de una única sesión cliente-bean.
•  El estado de la interacción del cliente con el bean es
llamado estado conversacional.
•  Modos de estado de administración
o 
o 
Stateful
Stateless
Stateful Session Bean
DEPARTAMENTO DE SISTEMAS
• 
• 
El estado se mantiene durante la sesión del cliente con el bean.
La instancia es reservada para el cliente y cada una almacena la
información del cliente.
• 
La sesión finaliza si el cliente remueve el bean o finaliza su
sesión.
Adicionar artículos
Realizar compra
Agregar información
adicional compra
Stateful Session Bean
DEPARTAMENTO DE SISTEMAS
• 
Definición de un session bean con estado
Ciclo de vida bean con estado
DEPARTAMENTO DE SISTEMAS
El método remove es el único
que es invocado directamente
por el cliente
El contendor decide
desactivar el bean
El cliente inicia el
ciclo de vida
obteniendo una
referencia al bean de
sesión -stateful
1.
2.
El cliente invoca
algún método del
negocio durante la
desactivación
Stateless Session Bean
DEPARTAMENTO DE SISTEMAS
• 
No mantiene un estado conversacional con el cliente.
o 
• 
Cuando un cliente invoca los métodos de un stateless bean, las variables
de instancia del bean pueden contener un estado específico del cliente,
pero sólo por la duración de la invocación. Cuando el método finaliza, el
estado del cliente específico no debería mantenerse.
Las instancias pueden estar compartidas por los clientes. El contenedor
tiene un pool de instancias, cuando el cliente invoca un método se asigna
una instancia, cuando la libere es retornada al pool.
Stateless Session Bean
DEPARTAMENTO DE SISTEMAS
• 
• 
Ofrecen mejor escalabilidad para aplicaciones con gran cantidad de
clientes
Puede implementar un web service, pero no otros tipos de enterprise
beans.
Ciclo de vida bean sin estado
DEPARTAMENTO DE SISTEMAS
El cliente inicia el
ciclo de vida
obteniendo una
referencia al bean de
sesión -stateful
1.
Callback Session Bean
DEPARTAMENTO DE SISTEMAS
•  Los métodos Callback son métodos del bean (no
expuestos en la interfaz) que el contenedor llama para
notificar la transición del ciclo de vida de un bean
•  Cuando el evento ocurre el contenedor invoca al
método callback correspondiente y los métodos pueden
ser utilizados para mejorar rendimiento
•  Estos métodos son marcados con anotaciones como
@PostContruct y @PreDestroy y para los stateful
session bean se agregan @PrePassivate y
@PostActivate
Session Beans
DEPARTAMENTO DE SISTEMAS
 
Los métodos Callback:
 
Deben ser públicos, sin retorno (void), y sin parámetros.
 
Utilizan las siguientes anotaciones
 
@PostConstruct: invocado sobre una instancia recientemente creada después
de la inyección (o JNDI lookup) de todas las dependencias y antes de la
invocación del primer método (javax.annotation.PostConstruct)
 
@PreDestroy: invocado luego de que un método anotado con @Remove ha
terminado y antes de que el contenedor elimine la instancia del bean
(javax.annotation.PreDestroy)
 
@PrePassivate: invocado antes de que el contenedor desactive (passivave) el
bean, el contenedor elimina temporalmente el bean y lo salva en memoria
secundaria (javax.ejb.PrePassivate)
 
@PostActivate: invocado después de que el contenedor mueve el bean de
memoria secundaria a estado activo (active) (javax.ejb.PostActivate)
Localización Enterprise Bean
DEPARTAMENTO DE SISTEMAS
Tomado: EJB 3 in action
•  Con JNDI es responsabilidad del cliente hacer la localización y obtener la
referencia al objeto.
•  Con EJB 3, usted puede utilizar la inyección de dependencia, dejando que el
contenedor se responsabilice de inyectar un objeto basado sobre la
declaración de la independencia
JNDI
DEPARTAMENTO DE SISTEMAS
 
Acceso desde un componente a otros componentes o recursos
(e.g., bases de datos)
 
Un servlet puede invocar métodos remotos de un enterprise bean
que consulta información de una bd
 
JNDI es un servicio de nombres que permite a un componente
localizar otros componentes o recursos
 
Habilita a las aplicaciones para acceder múltiples servicios de
nombres y de directorios. Por ejemplo servicios como LDAP,
NDS,DNS, y NIS.
 
Ofrece los métodos de
 
 
 
Asociar un nombre con un objeto (binding)
Buscar un objeto (lookup)
El uso de JNDI en aplicaciones Java EE permite almacenar o
consultar cualquier objeto de java: acceso a sistemas y
aplicaciones Legado
JNDI
DEPARTAMENTO DE SISTEMAS
 
Un administrador crea un recurso en un namespace de JNDI
 
En el servidor de aplicaciones se pueden crear recursos con la consola de
administración o el comando asadmin
 
Las aplicaciones utilizan anotaciones para acceder a los recursos. Cuando
una aplicación utiliza la “inyección” del recurso, el servidor de aplicaciones
invoca el API JNDI (@Resource)
 
La aplicación puede hacer llamados directos del API JNDI
 
Un recurso y su nombre JNDI son ligados por el servicio de nombres
 
Un recurso nuevo es creado en JNDI con la asociación del nombre del
recurso en el namespace de JNDI (bind del recurso)
 
Namespace: conjunto de todos los nombres de un servicio de nombres
JNDI - Ejemplo
DEPARTAMENTO DE SISTEMAS
 
Acceso a una base de datos con el API JDBC: recurso JDBC con información
sobre
 
 
 
Servidor de BD
Nombre de la BD
Protocolo de red utilizado para la comunicación
 
Un objeto DataSource es una fábrica de conexiones de una fuente de datos
específica. El método getConnection retorna una conexión física a la fuente de
datos
 
Si el objeto DataSource es registrado con JNDI, una aplicación puede utilizar el
API JNDI (lookup) para obtener el objeto y posteriormente conectarse a la
fuente de datos
 
Las aplicaciones utilizando el API de persistencia especifican la fuente de
datos en el archivo persistence.xml
<jta-data-source>jdbc/MyOrderDB</jta-data-source>
 
Este punto es el único que referencia algo sobre el objeto JDBC
JNDI
DEPARTAMENTO DE SISTEMAS
• 
Los servicios de nombres de Java EE proveen ambientes de nombres JNDI a
las aplicaciones cliente, enterprise beans, y componente web
• 
Un naming environment permite personalizar a un componente sin acceder o
cambiar el código fuente de los componentes
• 
Un contenedor implementa el ambiente de los componentes como un contexto
de nombres
• 
Contexto es un objeto cuyo estado tiene asociados un conjunto de relaciones
entre nombres y objetos (bindings)
• 
Un contexto tiene asociado una convención de nombres
• 
Contexto inicial es el punto de partida para hacer las operaciones
• 
En JNDI todas las operaciones son realizadas en un contexto
JNDI
DEPARTAMENTO DE SISTEMAS
 
Un componente Java EE puede localizar su contexto de nombres con JNDI
 
Un componente puede crear un objeto javax.naming.InitialContext y buscar
su contexto bajo el nombre de java:comp/env.
 
Un componente Java EE puede acceder nombres provistos por el sistema
(named system-provided) y objetos definidos por los usuarios (user-defined
objects)
 
Nombres de objetos provistos por el sistema (e.g., objetos JTA) son
almacenados en el contexto java:comp/env
 
Según el tipo de objeto a definir por el usuario el subcontexto para
registrarlo varía
 
 
Enterprise beans: java:comp/env/ejb
JDBC DataSource: java:comp/env/jdbc
JNDI
DEPARTAMENTO DE SISTEMAS
 
Ejemplo con propiedades del ambiente
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, args[2]); //rmi://localhost:1099
Context ctxt = new InitialContext(env);
Compute comp = (Compute) ctxt.lookup(name);
 
Ejemplo con archivo de configuración de las propiedades
Context initial = new InitialContext();
Object objref = initial.lookup("java:comp/env/ejb/SimpleConverter”);
Archivo build.xml
<target name="run" depends="buildjar">
<java fork="true" classname="client.ComputePi">
<classpath path="${build}" />
<classpath path="${compute}" />
…
<sysproperty key="java.naming.factory.initial"
value="com.sun.jndi.rmi.registry.RegistryContextFactory" />
<sysproperty key="java.naming.provider.url" value="rmi://${hostname}:${port}" />
</java>
</target>
JNDI
DEPARTAMENTO DE SISTEMAS
 
Las propiedades del ambiente JNDI se deben configurar de
acuerdo con las características del proveedor del servicio que
se va a utilizar
 
Las propiedades se clasifican en:
  Estándares (java.naming……): java.naming.factory.initial
  Específicas del servicio (java.naming.service……):
java.naming.corba.orb
  Característica específica (java.naming.feature….):
java.naming.security.sasl
  Especificas del proveedor: com.sun.jndi.ldap.trace.ber
JNDI
DEPARTAMENTO DE SISTEMAS
 
java.naming.factory.initial
 
 
 
nombre de la clase de la fábrica del contexto inicial
La clase debe implementar la interface
InitialContextFactory
Ejemplo valores:
 
 
com.sun.jndi.ldap.LdapCtxFactory
com.sun.jndi.rmi.registry.RegistryContextFactory
JNDI
DEPARTAMENTO DE SISTEMAS
 
java.naming.provider.url
 
 
El URL para configurar el proveedor del servicio
definido en la propiedad "java.naming.factory.initial"
Ejemplo valores:
 
 
ldap://localhost:389/o=JNDITutorial
rmi://localhost:1099
Localización Enterprise Bean
DEPARTAMENTO DE SISTEMAS
•  La localización se puede realizar definiendo
explícitamente la búsqueda con JNDI.
Localización Enterprise Bean
DEPARTAMENTO DE SISTEMAS
@EJB
private HelloUser helloUser;
void hello() {
helloUser.saludo(“Pepito");
}
Inyección
@Stateless
public class HelloUserBean implement HelloUser {
public void saludo(String nombre) {
System.out.println("Hola " + nombre + " bienvenido a EJB 3!");
}
}
• 
• 
• 
Un cliente de aplicación JEE para referir la instancia de un
enterprise bean lo puede realizar a través de la anotación
estática @EJB.
El contenedor EJB es el que inyecta en cada objeto los objetos
según las anotaciones que incluya.
EJB3 permite reemplazar los descriptores XML por
anotaciones en el código
Localización Enterprise Bean
DEPARTAMENTO DE SISTEMAS
Inyección
JNDI
DEPARTAMENTO DE SISTEMAS
•  @EJB
o 
o 
Declaración del atributo
Método Setter
•  Atributos Opcionales
o 
beanName
 
 
o 
beanInterface
 
o 
Nombre de la clase
Ejb-name si el EJB tiene un descriptor XML
Interface local o remota
mappedName
 
Nombre JNDI
JNDI
DEPARTAMENTO DE SISTEMAS
Partes de un @Resource
 
 
 
 
 
 
name: nombre del recurso en JNDI
type: el tipo (Java) del recurso
authenticationType: tipo de autenticación para utilizar el recurso
shareable: indica si el recurso puede ser compartido
mappedName: nombre específico de la implementación que indica que el recurso
puede ser mapeado a
description: descripción del recurso
Ejemplos de estilos de inyección: atributos, métodos y clases
  Atributos:
public class SomeClass { @Resource(name="customerDB")
private javax.sql.DataSource myDB; ... }
  Métodos
public class SomeClass { private javax.sql.DataSource myDB; ... @Resource
(name="customerDB")
private void setMyDB(javax.sql.DataSource ds) { myDB = ds; }
  Clases
@Resource(name="myMessageQueue", type="javax.jms.ConnectionFactory")
public class SomeMessageBean { …}
Session Beans - Anotaciones
DEPARTAMENTO DE SISTEMAS
 
Interface
 
 
 
@Remote: indica que se trata de una interfaz de negocio remota
@Local: acceso al bean de forma local únicamente
Clase
 
@stateless similar a @stateful /* bean de sesión con estado */
  Indica que el bean de sesión es sin estado
  Dependiendo del contenedor
 
 
 
Se crea el stub del bean
Registra en JNDI el bean con el nombre lógico "java:comp/env/ejb/
nombreBean“ o con un nombre dado en la anotación
@EJB
  Aplica para interfaces remotas únicamente
  Genera el lookup del bean de sesión en JNDI con el nombre "java:comp/
env/ejb/nombreBean“
  En serviciosCliente.java
@EJB(name = "co.com.uniandes.ejemplo.servicios.IServiciosProducto")
private IServiciosProducto serviciosProducto;
 
@Resource
  Inyección de recursos
  @Resource(name="jdbc/sqetestDB",type=javax.sql.DataSource.class)
public javax.sql.DataSource myTestDB;
Agenda
DEPARTAMENTO DE SISTEMAS
•  Introducción
•  EJB 3
o 
o 
o 
Características
Beneficios
Arquitectura EJB 3
•  Session Bean
o 
o 
o 
Stateless Session Bean
Stateful Session Bean
Localización Session Bean
•  Desarrollo por Componentes
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Existen diferentes estrategias de diseño para
desarrollar software basado en componentes
•  El objetivo de esta sesión es proveer una guía
general de diseño
o 
Basada en el diseño orientado por objetos
o 
Interfaces de Negocio
o 
Defición de los contratos entre componentes antes
de la implementación
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Diseño de Componentes con UML-2.0
o 
o 
o 
o 
o 
Interfaces
Puertos
Clasificadores Estructurados
Componentes
Conectores
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Interfaces
o 
o 
Requeridas
Provistas
Tomado de [2] página 12
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Puertos
o 
o 
o 
o 
Similar a las interfaces, describe como un
clasificador interactúa con el ambiente
A diferencia de las interfaces cada puerto es un
punto de interacción diferente
Pueden tener tipos y Multiplicidad
Puede tener interfaces
Tomado de [2] página 13
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Clasificadores Estructurados
o 
Una nueva manera de representar descomposición
de clasificadores
Tomado de [2] página 14
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Componentes
o 
UML 1.4 “a modular, deployable, and replaceable
part of a system that encapsulates implementation
and exposes a set of interfaces” [OMG 01, p. 2-31]
o 
UML 2.0 “a modular part of a system that
encapsulates its contents and whose manifestation
is replaceable within its environment” [OMG 03, p.
136].
o 
Extienden el comportamiento de las clases (a nivel
de metamodelo)
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
Tomado de [2] página 16
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Conectores
o 
Representa un enlace de comunicación entre
dos o mas elementos conectables (puertos,
interfaces)
 
 
Assembly
Delegation
Tomado de [2] páginas 17-18
DEPARTAMENTO DE SISTEMAS
Desarrollo por Componentes
•  Actividades a Desarrollar durante el
Diseño
o 
Identificar los Elementos
o 
Asignar responsabilidades a los elementos
o 
Diseñar las Interfaces
o 
Verificar los requerimientos funcionales
o 
Comparar contra escenarios
o 
Analizar interacciones
o 
Analizar la Flexibilidad del sistema
56
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  1. Identificar los Elementos
o 
Utilizar los requerimientos
identificar responsabilidades
o 
Identificar elementos funcionales que cumplirán
esas responsabilidades
o 
Evaluar los elementos identificados contra los
criterios de diseño deseables
o 
Iterar sobre los pasos anteriores hasta obtener un
conjunto de elementos razonable
57
funcionales
para
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  2. Asignar Responsabilidades a los Elementos
o 
58
Después de identificar elementos candidatos, se
les asignan responsabilidades claras
 
Información manejada
 
Servicios Ofrecidos
 
Actividades iniciadas por este elemento
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  3. Diseñar las Interfaces
o 
Para cada interface expuesta por el elemento
definir claramente
 
 
 
 
 
 
o 
Para su definición se puede utilizar
 
 
 
59
Operaciones ofrecidas por la interfaz
Naturaleza de la Interfaz (mensaje, RPC, WebService)
Entradas
Salidas
Precondiciones
Efectos de cada operación
 
Lenguajes de programación
IDLs
UML
DataFlow
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  4. Verificar los requerimientos funcionales
o 
Hacer el seguimiento de cada requerimiento,
utilizando la estructura funcional
o 
Es aconsejable utilizar una tabla de requerimientos
funcionales contra elementos del modelo
estructural
60
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  5. Comparar contra Escenarios
o 
Analizar la estructura funcional propuesta, en
conjunto con los stakeholders, a través de
escenarios de uso.
•  6. Análisis de Interacciones
o 
Analizar la estructura propuesta en busca de
interacciones excesivas
•  7. Análisis de Flexibilidad
o 
61
“what if ” escenarios
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Algunas errores frecuentes
o 
o 
o 
o 
o 
o 
Mala definición de interfaces
Mala definición de responsabilidades
Elementos de Infraestructura modelados como
elementos funcionales
Nivel inapropiado de detalle
Número elevado de dependencias
“God Element” / “Manager”
 
62
50% de las responsabilidades en menos del 25% de
los elementos
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Lista de Chequeo
o 
Su modelo tiene entre 15 y 20 elementos?
o 
Todos los elementos tienen nombre, responsabilidades claras e
interfaces claramente definidas?
o 
Todas las interacciones entre los elementos ocurren a través de
interfaces y conectores entre ellas
o 
Los elementos tienen una alta cohesión?
o 
Los elementos muestran un bajo acoplamiento?
o 
Se ha validado la estructura
requerimientos funcionales?
o 
Ha considerado como se porta la arquitectura en escenarios
hipotéticos de cambio?
o 
El punto de vista tiene en cuenta los intereses de los
stakeholders?
propuesta
contra
los
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  Ejemplo – Sistema de Reserva de Cuartos
[2]
64
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  1. Identificar Elementos
65
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  1. Identificar Elementos
66
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  2. Asignar Responsabilidades
67
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  3. Diseñar las Interfaces
68
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  3. Diseñar las Interfaces
69
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  3. Diseñar las Interfaces
70
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  4. Verificar Requerimientos Funcionales
71
Desarrollo por Componentes
DEPARTAMENTO DE SISTEMAS
•  5. Verificar Escenarios
•  6. Analizar Interacciones
72
Bibliografía
DEPARTAMENTO DE SISTEMAS
•  EJB 3 in action. Panda Debu, Rahman Reza, Lane
Derek. Manning. 2007.
•  EJB 3 Developer Guide. Sikora, Michael. 2008.
•  JSR 220: Enterprise JavaBeansTM,Version 3.0.
Sun Microsystems.
•  The Java™ EE 5 Tutorial Third Edition. For Sun
Java System Application Server Platform Edition 9.
Eric Jendrock. 2006.