Arquitectura de Software

FACULTAD DE CIENCIAS BSICAS E
INGENIERIA
CORPORACIN
UNIVERSITARIA REMINGTON
DIRECCIN PEDAGGICA
Ingeniera
de Sistemas
Asignatura: Arquitectura del Software

Direccin de Educacin a Distancia y Virtual
Este material es propiedad de la Corporacin Universitaria Remington (CUR),
para los estudiantes de la CUR en todo el pas.
2012

Ingeniera de Sistemas
CRDITOS
El mdulo de estudio de la asignatura Arquitectura del Software es propiedad de la Corporacin Universitaria

Remington. Las imgenes fueron tomadas de diferentes fuentes que se relacionan en los derechos de autor y las citas
en la bibliografa. El contenido del mdulo est protegido por las leyes de derechos de autor que rigen al pas.
Este material tiene fines educativos y no puede usarse con propsitos econmicos o comerciales.
AUTOR
Edilberto Restrepo Restrepo
Magister en Educacin Superior de la Pontificia Universidad Javeriana, Especialista en Gerencia de Proyectos de la
Universidad del Tolima, Administrador de Empresas y Tecnlogo en Administracin de Redes de Datos. Con 18 Aos de
experiencia como docente y Diseador de asignaturas en las reas de Lgica y Programacin, Mantenimiento de
computadores, Administracin de Redes de Datos,
asesora de proyectos informticos y productivos de
emprendimiento. En instituciones como CESDE, Universidad San Martin, Universidad Cooperativa de Colombia,
Comfenalco, Comfama y Microempresas de Antioquia. Actualmente coordinador de la Unidad de formacin en la
corporacin Universitaria Remington. Con ponencias sobre procesos evaluativos, Cesde 2005, Aprendizajes
colaborativos, Remington, 2011. Actualmente miembro del grupo de investigacin AVICUR.
mgedirre@gmail.com
formaciondocente.coordinador01@remington.edu.co
Nota: el autor certific (de manera verbal o escrita) No haber incurrido en fraude cientfico, plagio o vicios de autora; en
caso contrario eximi de toda responsabilidad a la Corporacin Universitaria Remington, y se declar como el nico
responsable.
RESPONSABLES
Dr.Jorge Mauricio Seplveda Castao
jsepulveda@remington.edu.co
Director de la Facultad de Ciencias Bsicas e Ingeniera
Toms Vsquez Uribe
Director Educacin a Distancia y Virtual
tvasquez @remington.edu.co
Anglica Ricaurte Avendao
Coordinadora de Remington Virtual (CUR-Virtual)
rricaurte@remington.edu.co
Corporacin Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Pgina Web: www.remington.edu.co - Medelln - Colombia

GRUPO DE APOYO
Personal de la Unidad de Remington Virtual (CUR-Virtual)
EDICIN Y MONTAJE
Primera versin. Febrero de 2011.Segunda versin Marzo 2012
Derechos Reservados
Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia.

TABLA DE CONTENIDO
1. MAPA DE LA ASIGNATURA ................................................................................................. 9
2. EL MODELAMIENTO UNIFICADO ....................................................................................... 10
2.1. Relacin de conceptos ............................................................................................................ 11
2.2. Prueba Inicial ........................................................................................................................... 11
2.3. Tcnicas comunes y Avanzadas de modelado con UML. ........................................................ 12
2.4. Reglas del Negocio .................................................................................................................. 25
2.5. Principios de desarrollo de aplicaciones Web......................................................................... 26
2.6. La Arquitectura en el Proceso Unificado de Desarrollo .......................................................... 29
3. LA ARQUITECTURA DE SOFTWARE. ................................................................................... 37
3.1. Relacin de conceptos ............................................................................................................ 37
3.2. Prueba Inicial ........................................................................................................................... 38
3.3. Modelos de arquitectura de software. ................................................................................... 38
3.4. Enfoques arquitectnicos de software ................................................................................... 47
3.5. Modelado Arquitectnico en UML 2.0 .................................................................................... 51
4. DEFINICIONES Y PATRONES DE SOFTWARE. ...................................................................... 63
4.1. Prueba Inicial ........................................................................................................................... 64
4.2. Definiciones Bsicas ................................................................................................................ 64
4.3. Catlogos de Patrones ........................................................................................................... 68
5. FRAMEWORKS Y EL MDELO MDA (MODEL DRIVEN ARCHITECTURE) ............................. 101
5.1. Relacin de conceptos .......................................................................................................... 101
5.2. Prueba Inicial ......................................................................................................................... 102
5.3. Definicin y Estructura del Frameworks .............................................................................. 102
5.4. MDA (Model Driven Architecture) ........................................................................................ 106
6. ASPECTOS ...................................................................................................................... 121
6.1. Relacin de conceptos .......................................................................................................... 121
6.2. Prueba Inicial ......................................................................................................................... 121
6.3. Definiciones Bsicas .............................................................................................................. 122

6.4. Lenguajes orientados a aspectos .......................................................................................... 127

7. PISTAS DE APRENDIZAJE ................................................................................................. 134
8. GLOSARIO ...................................................................................................................... 135
9. BIBLIOGRAFA ................................................................................................................ 136

1. MAPA DE LA ASIGNATURA
ARQUITECTURA DEL SOFTWARE
OBJETIVO GENERAL DEL MODULO

En un mundo globalizado, donde cada da desaparecen las barreras comerciales y culturales, la calidad se
torna en necesidad, pues permite competir con mayores posibilidades de xito. A pesar de que la
programacin de sistemas no haba sido concebida desde la perspectiva de la calidad, la calidad en
productos de software ha tenido un auge importante en la sociedad informatizada de hoy, La calidad del
software permite elaborar actividades sistemticas que se necesitan para lograr software con calidad, la
Calidad involucra actividades de evaluaciones, auditorias y revisiones, estndares que se aplicaran al
proyecto, mecanismos de medida (mtricas), mtodos y herramientas de anlisis, diseo, programacin y
prueba, documentacin y control.
OBJETIVO GENERAL
Apropiar en el estudiante conceptos y prcticas de Arquitectura y Diseo de Software aplicables a
escenarios de la vida real.
OBJETIVOS ESPECFICOS
Dar a conocer las generalidades y conceptos bsicos de UML y el desarrollo de aplicaciones para la
infraestructura de un proyecto web.
Presentar de manera prctica las diferentes metodologas y buenas prcticas para documentacin y
evaluacin de arquitecturas de software
Apropiar el uso de catlogos de elementos reusables en el diseo de sistemas software
Identificar las caractersticas de un framework para Web y apropiarse del modelado bajo el enfoque
MDA.
Aprender a definir los conceptos entre Aspectos y un lenguaje orientado por objetos.
UNIDAD 1
Mediante
la
conceptualizacin
y aplicacin en
situaciones
problema,
el
estudiante podr
apropiarse de los
procesos
de
modelamientos
UML.
UNIDAD 2
El
estudiante
podr plantear
propuestas
metodolgicas
para
la
documentacin
de las prcticas
productivas de
desarrollo
de
software.
UNIDAD 3
Mediante
el
abordaje
y
aplicacin de los
diferentes
patrones
de
elementos
reusables
el
estudiante
obtendr criterios
de aplicacin en
contextos
diversos
UNIDAD 4
Identificando las
caractersticas de
los frameworks, y
modelado MDA, el
estudiante
plantear solucin
a
necesidades
reales
de
desarrollo
de
software
UNIDAD 5
Conociendo
los
conceptos sobre la
programacin
orientada a aspectos, el
estudiante
podr
determinar
las
situaciones
en
las
cuales
sea
ms
pertinente
su
aplicacin
en el
desarrollo de software

2. EL MODELAMIENTO UNIFICADO
OBJETIVO GENERAL
Dar a conocer las generalidades y conceptos de UML y el desarrollo de aplicaciones Web para la
infraestructura de un proyecto de software.
Evidenciar las tcnicas comunes y avanzadas del Modelamiento UML
grficamente la arquitectura de un proyecto web.
mostrando
Determinar de forma adecuada las polticas o reglas del negocio que rigen a una empresa
para hacerlo escalable en el tiempo.
Argumentar de forma clara y precisa cada una de las etapas empleadas en el Proceso
Unificado de Desarrollo.
Proponer modelamiento de negocios adecuado y apropiado a cualquier escenario de la
vida real.

2.1. Relacin de conceptos
2.2. Prueba Inicial

Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes
preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su
grado de asimilacin
a)
b)
c)
d)
e)
f)
g)
h)
Qu entiende usted por Modelado UML?

Qu tcnicas de modelamiento puedes describir?
Cmo se dividen los bloques de construccin?
Qu entiende usted por clase, Interfaz, Colaboracin, Casos de uso, Clase Activa?
Qu Conoce de los diagramas que se involucran en el modelamiento UML?
Qu aspectos se identifican mediante las reglas del negocio?
Sobre qu principios se fundamenta el desarrollo de aplicaciones web?
Mediante qu elementos se estructura el proceso unificado de desarrollo?

2.3. Tcnicas comunes y Avanzadas de modelado con UML.

Notas
Una nota es un smbolo grfico utilizado para suministrar restricciones o comentarios vinculados a
un elemento o a una coleccin de elementos. Grficamente, una nota se representa como un
rectngulo con la esquina superior derecha doblada, junto con un comentario textual o grfico.
El UML proporciona todas las herramientas necesarias para visualizar, especificar, construir y
documentar los artefactos de un rango amplio de sistemas completos de software. Tambin
podemos encontrar en algunas ocasiones de otros elementos adicionales al UML para poder
modelar un escenario que se adapte a nuestras necesidades. Un lenguaje es usado o empleado
para comunicar una idea de forma clara y precisa para cualquier sistema de informacin.
En UML utilizamos notas para dar a entender una idea clara sobre algo y por medio de ellas
explicamos ideas que de forma grfica se hace difcil. Las notas pueden representar artefactos,
para hacer ms atractivo del ciclo de vida en el desarrollo de software, tambin como los
requerimientos solicitados por el usuario, o pueden representar simplemente observaciones en
forma libre, revisiones, o explicaciones.
El UML proporciona la nota como una representacin grfica para incluir comentarios o
restricciones; por medio de las notas se permite realizar enlaces a archivos. En la Figura 1 tenemos
un ejemplo de una nota en UML.
Estereotipos: Un estereotipo ampla el vocabulario UML, permitiendo crear nuevos tipos de
bloques de construccin similares a los existentes pero especficos para tu problema.
Grficamente, un estereotipo se representa con un nombre encerrado entre pico parntesis y
colocado arriba del nombre de otro elemento. Como una opcin, el elemento estereotipado
puede ser representado usando un nuevo icono asociado con el estereotipo.
Los estereotipos, valores etiquetados y las restricciones son los mecanismos, proporcionados por
el UML, utilizados para aadir nuevos bloques de construccin, crear nuevas propiedades y
especificar semnticas nuevas respectivamente. Por ejemplo, si ests modelando una red, puedes
necesitar smbolos para los enrutadores y los concentradores; puedes usar nodos estereotipados
para hacer que estos elementos aparezcan como bloques primitivos de construccin.
Similarmente, si eres parte del equipo responsable del ensamble, de la prueba y de la liberacin,
puedes conservar registros con respecto al nmero de versin y resultados de la prueba para cada
subsistema. Puedes usar valores etiquetados para aadir informacin a tus modelos. Finalmente,
si ests modelando con dificultad sistemas en tiempo real, puedes adornar tus modelos con
informacin de tiempo presupuestal y lneas muertas; puedes usar restricciones para capturar
estos requerimientos de tiempo.

Ilustracin sobre Estereotipos, Valores etiquetados y Restricciones.
Valor etiquetado:Un valor etiquetado ampla las propiedades de un elemento UML, permitiendo
crear nueva informacin en lo que respecta a la especificacin del elemento. Grficamente, un
valor etiquetado se representa como una cadena encerrada entre llaves y colocada bajo el nombre
de otro elemento.
Restriccin: Una restriccin ampla la semntica de un elemento UML, permitiendo aadir nuevas
reglas, o modificar las existentes. Grficamente, una restriccin se representa como una cadena
encerrada entre llaves y colocada junto al elemento asociado o, conectada a el(los) elemento(s)
con relacin de dependencia. Como una alternativa, puedes incluir una restriccin en una nota.

Tcnicas avanzadas de modelado con UML

Primero comencemos haciendo una diferencia entre Metodologa y Modelo, Una metodologa es
aquella gua que se sigue a fin de realizar las acciones propias de una investigacin. En trminos
ms sencillos se trata de la gua que nos va indicando qu hacer y cmo actuar cuando se quiere
obtener algn tipo de investigacin. Es posible definir una metodologa como aquel enfoque que
permite observar un problema de una forma total, sistemtica, disciplinada y con cierta disciplina.
Al intentar comprender la definicin que se hace de lo que es una metodologa, resulta de suma
importancia tener en cuenta que una metodologa no es lo mismo que la tcnica de investigacin.
Las tcnicas son parte de una metodologa, y se define como aquellos procedimientos que se
utilizan para llevar a cabo la metodologa, por lo tanto, como es posible intuir, es uno de los
muchos elementos que incluye.
En el contexto de la investigacin son muchas las metodologas que es posible seguir, sin embargo,
existen 2 grandes grupos que incluyen a otras ms especficas. Se trata de la metodologa de
investigacin cuantitativa y la cualitativa.
La metodologa cuantitativa es aquella que permite la obtencin de informacin a partir de la
cuantificacin de los datos sobre variables, mientras que la metodologa cualitativa, evitando la
cuantificacin de los datos, produce registros narrativos de los fenmenos investigados. En este
tipo de metodologa los datos se obtienen por medio de la observacin y las entrevistas, entre
otros. Como vemos, la diferencia ms importante entre la metodologa cuantitativa y la

cualitativa radica en que la primera logra sus conclusiones a travs de la correlacin entre
variables cuantificadas, y as poder realizar generalizaciones y producir datos objetivos, mientras
que la segunda estudia la relacin entre las variables obtenidas a partir de la observacin en
contextos estructurales y situacionales.
Ahora miremos qu es un modelo: Un modelo es una estructura conceptual que sugiere un marco
de ideas para un conjunto de descripciones que de otra manera no podran ser sistematizadas. De
esta manera, su estructura es diferente de la que se supone existe en el conjunto de fenmenos
de la naturaleza. Para el caso de arquitectura de software usamos el Modelo de UML.
A continuacin veamos la Historia del UML
La notacin UML se deriva y unifica las tres metodologas de anlisis y diseo Orientada a Objeto
ms extendidas:
Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus relaciones.
Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling
Technique).
Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante
la metodologa de casos de uso (use case).
El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational
Software Corporation empezaron a unificar sus mtodos. A finales de 1995, Ivar Jacobson y su
compaa Objectory se incorporaron a Rational en su unificacin, aportando el mtodo OOSE.
De las tres metodologas de partida, las de Booch y Rumbaugh pueden ser descritas como
centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que
componen el sistema, su relacin y colaboracin. Por otro lado, la metodologa de Jacobson es
ms centrada a usuario, ya que todo en su mtodo se deriva de los escenarios de uso. UML se ha
ido fomentando y aceptando como estndar desde el OMG que es tambin el origen de CORBA, el
estndar lder en la industria para la programacin de objetos distribuidos. En 1997 UML 1.1 fue
aprobada por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo
orientado a objetos.
Qu es UML?
UML es el primer mtodo en publicar una meta-modelo en su propia notacin, incluyendo la
notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de una
meta-modelo auto-referencial, cualquier lenguaje de modelado de propsito general debera ser
capaz de modelarse a s mismo.

UML es un lenguaje estndar que sirve para escribir los planos del software, puede utilizarse para
visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con
gran cantidad de software. UML puede usarse para modelar desde sistemas de informacin hasta
aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real.
UML es solamente un lenguaje por lo que es slo una parte de un mtodo de desarrollo software,
es independiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por
casos de uso, centrado en la arquitectura, iterativo e incremental.
UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, adems es un
lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la
representacin conceptual y fsica del sistema.
UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante grficos o mediante
texto obteniendo modelos explcitos que ayudan a la comunicacin durante el desarrollo ya que al
ser estndar, los modelos podrn ser interpretados por personas que no participaron en su diseo
(e incluso por herramientas) sin ninguna ambigedad. En este contexto, UML sirve para
especificar, modelos concretos, no ambiguos y completos.
Debido a su estandarizacin y su definicin completa no ambigua, y aunque no sea un lenguaje de
programacin, UML se puede conectar de manera directa a lenguajes de programacin como Java,
C++ o Visual Basic, esta correspondencia permite lo que se denomina como ingeniera directa
(obtener el cdigo fuente partiendo de los modelos) pero adems es posible reconstruir un
modelo en UML partiendo de la implementacin, o sea, la ingeniera inversa.
UML proporciona la capacidad de modelar actividades de planificacin de proyectos y de sus
versiones, expresar requisitos y las pruebas sobre el sistema, representar todos sus detalles as
como la propia arquitectura. Mediante estas capacidades se obtiene una documentacin que es
vlida durante todo el ciclo de vida de un proyecto.
El lenguaje UML se compone de tres elementos bsicos, los bloques de construccin, las reglas y
algunos mecanismos comunes. Estos elementos interaccionan entre s para dar a UML el carcter
de completitud y no-ambigedad que antes comentbamos.
Los bloques de construccin se dividen en tres partes:
Elementos, que son las abstracciones de primer nivel.
Relaciones, que unen a los elementos entre s.

Diagramas, que son agrupaciones de elementos.

Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos:
Elementos estructurales.
Elementos de comportamiento.
Elementos de agrupacin
Elementos de anotacin.
Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se
nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia,
relaciones de asociacin, relaciones de generalizacin y relaciones de realizacin.
Se utilizan diferentes diagramas dependiendo de qu, nos interese representar en cada momento,
para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle..., por esta
razn UML soporta un gran nmero de diagramas diferentes aunque, en la prctica, slo se
utilicen un pequeo nmero de combinaciones.
UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones
entre objetos para poder obtener modelos bien formados, estas son reglas semnticas que
afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por otros,
a la integridad de unos elementos con otros y a la ejecucin, o sea la vista dinmica del sistema.
UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidad
adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo unas ciertas
reglas para que en el trasfondo de la adaptacin no se pierda la semntica propia de UML. Dentro
de estos mecanismos estn las especificaciones, que proporcionan la explicacin textual de la
sintaxis y semntica de los bloques de construccin.
Otro mecanismo es el de los adornos que sirven para conferir a los modelos de ms semntica, los
adornos son elementos secundarios ya que proporcionan ms nivel de detalle, que quiz en un
primer momento no sea conveniente descubrir. Las divisiones comunes permiten que los modelos
se dividan al menos en un par de formas diferentes para facilitar la comprensin desde distintos
puntos de vista, en primer lugar tenemos la divisin entre clase y objeto (clase es una abstraccin
y objeto es una manifestacin de esa abstraccin), en segundo lugar tenemos la divisin interfaz /
implementacin donde la interfaz presenta un contrato (algo que se va a cumplir de una
determinada manera) mientras que la implementacin es la manera en que se cumple dicho
contrato.

Por ltimo, los mecanismos de extensibilidad que UML proporciona sirven para evitar posibles
problemas que puedan surgir debido a la necesidad de poder representar ciertos matices, por esta
razn UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques de
construccin, los valores etiquetados, para extender las propiedades un bloque, y las restricciones,
para extender la semntica. De esta manera UML es un lenguaje estndar abierto-cerrado
siendo posible extender el lenguaje de manera controlada.
Elementos Estructurales
Los elementos estructurales en UML, es su mayora, son las partes estticas del modelo y
representan cosas que son conceptuales o materiales.
Clases
Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica. Una clase implementa una o ms interfaces. Grficamente se
representa como un rectngulo que incluye su nombre, sus atributos y sus operaciones.
Clase
Describe un conjunto de objetos que comparten los

mismos atributos, mtodos, relaciones y semntica. Las
clases implementan una o ms interfaces.
Interfaz: Una interfaz es una coleccin de operaciones que especifican un servicio de una
determinada clase o componente. Una interfaz describe el comportamiento visible externamente
de ese elemento, puede mostrar el comportamiento completo o slo una parte del mismo. Una
interfaz describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca
su implementacin. Se representa con un crculo, y rara vez se encuentra aislada sino que ms
bien conectada a la clase o componente que realiza.
Interfaz
Agrupacin de mtodos u operaciones que especifican

un servicio de una clase o componente, describiendo su
comportamiento, completo o parcial, externamente
visible. UML permite emplear un crculo para
representar las interfaces, aunque lo ms normal es
emplear la clase con el nombre en cursiva.

Colaboracin: Define una interaccin y es una sociedad de roles y otros elementos que colaboran
para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos
de sus elementos. Las colaboraciones tienen una dimensin tanto estructural como de
comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las
colaboraciones representan la implementacin de patrones que forman un sistema. Se representa
mediante una elipse con borde discontinuo.
Colaboracin
Define una interaccin entre elementos que cooperan

para proporcionar un comportamiento mayor que la
suma de los comportamientos de sus elementos.
Casos de Uso: Un caso de uso es la descripcin de un conjunto de acciones que un sistema ejecuta
y que produce un determinado resultado que es de inters para un actor particular. Un caso de
uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es
realizado por una colaboracin.
Caso de uso
Describe un conjunto de secuencias de acciones que un

sistema ejecuta, para producir un resultado observable
de inters. Se emplea para estructurar los aspectos de
comportamiento de un modelo.
Clase Activa: Es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin por lo y
tanto pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto
que sus objetos representan elementos cuyo comportamiento es concurrente con otros
elementos. Se representa igual que una clase, pero con lneas ms gruesas
Clase activa
Se trata de una clase, en la que existen procesos o hilos

de ejecucin concurrentes con otros elementos. Las
lneas del contorno son ms gruesas que en la clase
normal
Componentes: Un componente es una parte fsica y reemplazable de un sistema que conforma

con un conjunto de interfaces y proporciona la implementacin de dicho conjunto. Un

componente representa tpicamente el empaquetamiento fsico de diferentes elementos lgicos,

como clases, interfaces y colaboraciones.
Componente
Parte fsica y por tanto reemplazable de un modelo,

que agrupa un conjunto de interfaces, archivos de
cdigo fuente, clases, colaboraciones y proporciona
la implementacin de dichos elementos.
Nodos: Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso
Computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad
de procesamiento. Un conjunto de componentes puede residir en un nodo.
Nodo
Elemento fsico que existe en tiempo de ejecucin y

representa un recurso computacional con capacidad de
procesar.
Diagramas de Casos de Usos: Muestran un conjunto de casos de uso y actores (tipo especial de
clases) y sus relaciones. Cubren la vista esttica de los casos de uso y son especialmente
importantes para el modelado y organizacin del comportamiento.
Casos de Uso
Muestra un conjunto de casos de uso, los

actores implicados y sus relaciones. Son
diagramas fundamentales en el modelado y
organizacin del sistema.
Diagramas de Secuencia y de Colaboracin: Tanto los diagramas de secuencia como los diagramas
de colaboracin son un tipo de diagramas de interaccin. Constan de un conjunto de objetos y sus
relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista
dinmica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los

mensajes mientras que los diagramas de colaboracin muestran la organizacin estructural de los
objetos que envan y reciben mensajes. Los diagramas de secuencia se pueden convertir en
diagramas de colaboracin sin prdida de informacin, lo mismo ocurren en sentido opuesto.
Secuencia
Colaboracin
Son diagramas de interaccin, muestran un conjunto de

objetos y sus relaciones, as como los mensajes que se
intercambian entre ellos. Cubren la vista dinmica del
sistema. El diagrama de secuencia resalta la ordenacin
temporal de los mensajes, mientras que el de
colaboracin resalta la organizacin estructural de los
objetos, ambos siendo equivalentes o isomorfos. En el
diagrama de colaboracin de la figura de la izquierda, se
puede ver que los elementos grficos no son cajas
rectangulares, como cabra esperar, y en su lugar
encontramos sus versiones adornadas. Estas versiones
tienen como finalidad evidenciar un rol especfico del
objeto siendo modelado. En la figura encontramos de
izquierda a derecha y de arriba abajo un Actor, una
Interfaz, un Control (modela un comportamiento) y una
Instancia (modela un objeto de dato).
Diagramas de Estados: Muestran una mquina de estados compuesta por estados, transiciones,
eventos y actividades. Estos diagramas cubren la vista dinmica de un sistema y son muy
importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboracin.
Estados
Muestra una mquina de estados, con sus estados,

transiciones, eventos y actividades. Cubren la vista
dinmica de un sistema. Modelan comportamientos
reactivos en base a eventos.
Diagramas de Actividades: Son un tipo especial de diagramas de estados que se centra en mostrar
el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte
dinmica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el
flujo de control entre objetos.

Actividades
Tipo especial de diagrama de estados que

muestra el flujo de actividades dentro de
un sistema.
Diagramas de Componentes: Muestra la organizacin y las dependencias entre un conjunto de

componentes. Cubren la vista de la implementacin esttica y se relacionan con los diagramas de
clases ya que en un componente suele tener una o ms clases, interfaces o colaboraciones
Diagramas de Despliegue: Representan la configuracin de los nodos de procesamiento en tiempo
de ejecucin y los componentes que residen en ellos. Muestran la vista de despliegue esttica de
una arquitectura y se relacionan con los componentes ya que, por lo comn, los nodos contienen
uno o ms componentes.

Diagrama de Despliegue
Veamos un ejemplo de UML con casos de uso
Primero que todo debemos describir el problema sobre el cual vamos a aplicar el Modelo UML
Para mover una caja, el jugador debe colocarse al lado y empujarla. Si la casilla hacia la
que est empujando la caja est libre la caja se mover.
Si el jugador se queda bloqueado, es decir, no puede terminar el nivel, puede reiniciar el
nivel perdiendo una vida.
Cuando el jugador pierde todas sus vidas la partida termina.
Tambin debemos mirar que solicitudes le hacen al sistema para que podamos dar comienzo a
la representacin del Modelo UML.
El sistema debe permitir comenzar una nueva partida y terminarla.
El sistema debe permitir mover al jugador y a las cajas y reiniciar el nivel cuando el usuario
lo solicite.
El sistema deber almacenar varios niveles y cambiar de nivel cuando el usuario complete
el nivel actual
A continuacin miremos los casos de uso resultantes de acuerdo a la descripcin del problema y
los requerimientos que nos hace el usuario dueo del sistema:


2.4.
Reglas del Negocio
Esta capa es la encargada de procesar y validar las reglas del negocio, acta como un servidor para
la capa de presentacin y traslada las solicitudes de esta a la capa de datos actuando como cliente
de la misma. As mismo tambin funciona de la misma manera de la forma inversa.
Los servicios de negocios son el puente entre un usuario y los servicios de datos. Responden a
peticiones del usuario (u otros servicios de negocios) para ejecutar una tarea de este tipo.
Cumplen con esto aplicando procedimientos formales y reglas de negocio a los datos relevantes.
Cuando los datos necesarios residen en un servidor de bases de datos, garantizan los servicios de
datos indispensables para cumplir con la tarea de negocios o aplicar su regla. Esto asla al usuario
de la interaccin directa con la base de datos.
Una tarea de negocios es una operacin definida por los requerimientos de la aplicacin, como
introducir una orden de compra o imprimir una lista de clientes. Las reglas de negocio (business
rules) son polticas que controlan el flujo de las tareas.
Como las reglas de negocio tienden a cambiar ms frecuentemente que las tareas especficas de
negocios a las que dan soporte, son candidatos ideales para encapsularlas en componentes que
estn lgicamente separados de la lgica de la aplicacin en s.
Para ayudar a los desarrolladores a construir la lgica de negocio basado en componentes
Windows DNA incluye un conjunto muy poderoso de servicios que se encargan de la comunicacin

en una aplicacin de tres capas. Estos servicios estn altamente integrados unos con otros, bajo un
sistema operativo, y expuestos de forma nica a travs de COM.
El nivel de servicios de negocios es responsable de:
Recibir la entrada del nivel de presentacin
Interactuar con los servicios de datos para ejecutar las operaciones de negocios para los
que la aplicacin fue diseada a automatizar (por ejemplo, la preparacin de impuestos
por ingresos, el procesamiento de rdenes y as sucesivamente).
Enviar el resultado procesado al nivel de presentacin. Algunos de los servicios DNA para
la capa de negocios son los siguientes:
Servicios Web a travs de Microsoft Internet Information Server (IIS)
Transacciones y Servicios de Componentes, Microsoft Transaction Server (MTS)
Servicios Asncronos, Microsoft Message Queue Server (MSMQ).
Server-side Scripting, via Active Server Pages (ASP).
2.5. Principios de desarrollo de aplicaciones Web

Desarrollar un sitio, un proyecto web, no es tan complicado como pareciera. Solo hace falta tener
las ideas claras para hacerlo. A travs de mi experiencia prctica, he aprendido algunas ideas
desde dnde comenzar para desarrollar un sitio o portal web. Los llamo Principios para
desarrollar un proyecto para Internet.
Estos son los Principios:
El proyecto debe ser orientado al usuario, no al desarrollador.
El proyecto debe tener contenido tico.
El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseo grfico como
en usabilidad y contenidos.
El proyecto debe ser esttico y atractivo visualmente.
El proyecto debe transmitir emociones, segn su naturaleza.
El proyecto debe tener herramientas y contenido ms actuales disponibles y estos deben
mantenerse constantemente actualizadas.
El proyecto debe permitir, en la medida de lo posible, interactividad entre el receptor, el
mensaje y la fuente, completando el ciclo de la comunicacin.
El proyecto debe tener enfoque global, es decir, que no debe ser un fin en s mismo, sino
un medio para completar otros objetivos mayores, a la vez que mantiene consistencia con
estos.

El proyecto debe ser orientado al usuario, no al desarrollador.

Es demasiado fcil caer en la trampa de empezar a desarrollar un proyecto teniendo como
prioridad tus propios criterios, o los del desarrollador. Con el tiempo te dars cuenta de que
mientras ms apegado se est a los criterios del desarrollador, ms complejo le ser acceder al
usuario a la informacin, proyecto, servicio, etc.
Son innumerables los casos de esto, los ms tpicos son los portales de la Administracin pblica,
universidades, etc., que hacen que el usuario comience tirndose de los pelos, impaciente, hasta
que al final o bien se da por vencido, o bien termina siendo un experto en informtica solo por
usar una pgina web. Por el contrario, Organizaciones o portales web que manejan una enorme
cantidad de informacin han sido muy exitosos, donde en un abrir y cerrar de ojos el usuario
aprende a manejarlos muy bien, acceder y regresar una y otra vez, dado que los desarrolladores lo
ponen muy fcil. Cmo saber si tu pgina o proyecto web est orientado al usuario? Muy fcil:
pregntaselo a tus usuarios.
El proyecto debe tener contenido tico.
Todo proyecto serio, y que se precie de serlo, debe cuidar que sus contenidos sean ticos.
Tambin innumerables son los casos que puedo poner como ejemplos: contenidos que te ofrecen
hacerte millonario/a de la noche a la maana, te prometen la luna, las estrellas, vida eterna, etc,.
Asimismo, una amonestacin a quienes usan la estrategia del correo electrnico no solicitado
(llmese SPAM), ventanas emergentes no solicitadas (pop ups), banners parpadeantes sin cesar
(aarrgghhhhh!! mis ojos!!!) etc ni hablar de los sitios puramente fraudulentos.
No. No es necesario caer en esas prcticas para atraer lectores o usuarios. As vendas lotera,
coches, dietas, o informacin que puede dar beneficios al lector, tu producto, informacin o
servicio puede ser difundido desarrollando un proyecto ticamente, sin forzar, sin mentir.
Ofreciendo al usuario las ventajas y desventajas de tu informacin, haciendo comparaciones
honestas y, sobre todo, permitindole tomar una decisin.
El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseo grfico como en
usabilidad y contenidos.
Un proyecto puede ser tan complejo como quieras y al mismo tiempo ser simple de usar y leer. Sin
tanta parafernalia, sin tanto grfico. Echa un vistazo a Google.com y vers lo simple que es esa
pgina, que hoy por hoy es la ms visitada de todo el mundo. En definitiva, debes ofrecer a tus
lectores/usuarios la informacin que necesitan sin hacerlos dar vueltas por todos lados para
hallarla, o se irn sin pensarlo dos veces. Existen varias maneras de lograr hacer un proyecto muy

accesible, como por ejemplo mapas, buscadores internos, formas de redactar simples y al grano,
etc. Simplicidad es la palabra clave.
El proyecto debe ser esttico y atractivo visualmente.
Antes he dicho que la usabilidad, orientada al usuario, es uno de los aspectos ms importantes al
momento de desarrollar un proyecto para Internet. Pues bien, podra decir que la esttica tambin
juega un papel importante, dicha esttica, que personalmente prefiero minimalista, creo es la
clave en la credibilidad de lo que escribimos, tambin logra que nuestros usuarios/as se sientan
cmodos utilizando lo que ponemos a su disposicin. Concretamente hablando de desarrollo de
sitios web, por ejemplo, he visto cmo contenidos interesantes -algunos publicados por
catedrticos o expertos en alguna materia- quedan sepultados bajo un diseo muy pobre, que ni
siquiera haba razn para ser tan deficiente respecto a esttica. Tambin por el contrario, he visto
unos superdiseos grficos, tantos, que sepultan el verdadero contenido. Por tanto te recomiendo
atencin a la esttica, simplicidad y equilibrio en este aspecto.
El proyecto debe transmitir emociones, segn su naturaleza.
No podemos evitarlo, somos humanos que tenemos emociones y, sea mediante la palabra al
redactar o mediante la ayuda de grficos, transmitir un mensaje que contenga alguna emocin,
acorde a la naturaleza del mensaje, ser muy efectivo, por muchsimo. La industria de la publicidad
es experta en ello, pero tambin escritores que, mediante la palabra, nos transportan a otros
mundos.
El proyecto debe tener herramientas y contenido actuales disponibles y estos deben mantenerse
constantemente actualizadas.
As es. Cuando comenc a desarrollar proyectos para Internet, a disear mis propias pginas,
Internet ya llevaba varios aos de andadura, y en esa poca las pginas se hacan una por una,
eran estticas y sus contenidos lentamente actualizados. Hoy, hasta se puede ver televisin,
vdeos, escuchar radio, msica y mil cosas ms. En estos tiempos se empieza a poner de moda la
llamada Web 2.0 (como las redes sociales), donde los usuarios -y no el desarrollador- son quienes
tienen la ltima palabra en lo que hacen por Internet, etc. Con tanto cambio, dnde quedarn
tus contenidos o tu proyectos si nunca actualizas?
El proyecto debe permitir, en la medida de lo posible, interactividad entre el receptor, el
mensaje y la fuente, completando el ciclo de la comunicacin.
La comunicacin, para que sea completa, debe ser un ciclo entre la fuente, el mensaje y el
receptor que interactan simultneamente. Cmo te sentiras hablando con alguien que no te

contesta, ni siquiera con un gesto? En Internet es prcticamente igual. Por tanto, es importante
que t, como desarrollador, permitas que tus usuarios puedan interactuar contigo de alguna
manera, enviar feedback, sea mediante formularios, mensajes electrnicos, foros, etc, etc. As
tambin t podrs ir adquiriendo nuevas ideas que te podran servir para implementar
comprendes?
El proyecto debe tener enfoque global, es decir, que no debe ser un fin en s mismo, sino un
medio para completar otros objetivos mayores, a la vez que mantiene consistencia con estos.
Siempre que desarrolles un proyecto para Internet, ten mucho cuidado de que el proyecto no sea
el fin, sino solo una herramienta ms para alcanzar algn objetivo. De otra manera, puede que
termines gastando tiempo y recursos en otra cosa que no sea tu verdadero objetivo. Recuerda, el
proyecto es solo una herramienta o medio ms. Mantn la visin equilibrada y no descuides otras
herramientas o medios que tambin podran serte tiles.
2.6. La Arquitectura en el Proceso Unificado de Desarrollo

Etapas, hitos, iteraciones y ciclos
Identifica los diferentes procesos que deben llevar a cabo dentro de las fases de un proceso
unificado de desarrollo de software.
Iniciacin.
Elaboracin.
Construccin.
Transicin.
El proceso unificado de desarrollo de software Es un proceso orientado a objetos, es un proceso

guiado por casos de uso, centrado en la arquitectura y Con un ciclo de vida iterativo e incremental

El proceso unificado de desarrollo de software usa UML como podemos visualizar en la siguiente
figura
El proceso unificado de desarrollo de software est organizado de la siguiente manera:
a) Guiado por casos de uso.
b) Centrado en la arquitectura.
c) Ciclo de vida iterativo e incremental.
a) Guiado por casos de uso:
Los sistemas se crean para dar servicio a los usuarios
Qu REQUISITOS se necesitan
Un CASO de USO es una pieza de FUNCIONALIDAD de un sistema que le proporciona a algn
USUARIO un RESULTADO o VALOR.
Todos juntos constituyen el modelo de casos de uso
Funcionabilidad completa
Para todos los usuarios

Veamos a continuacin un ejemplo de un modelo de casos de uso:

En qu beneficia a un desarrollo guiado por casos de uso?
Los casos de uso: capturan requisitos, se especifican (analizan), se disean, se implementan y se
prueban
En siguiente figura podemos apreciar un ejemplo de un desarrollo por casos de uso:

a) Centrado en la arquitectura:
La arquitectura de un sistema software es un extracto de los
modelos del sistema es decir una vista de cada mdulo.
Que da una idea de la forma que tiene el sistema completo

b) Ciclo de vida iterativo e incremental

En el iterativo se repiten varios miniproyectos en el Incremental cada miniproyecto ampla el
producto, en el ciclo de vida del proceso unificado podemos anotar que
Un ciclo de vida se repite a lo largo del tiempo
Tras cada ciclo de vida versin nueva del producto
Un ciclo de vida se divide en fases
Cada fase se divide en iteraciones
En cada iteracin se realizan flujos de trabajo
Miremos grficamente estos componentes

Fases dentro del ciclo de vida del proceso unificado

Iniciacin:
Describir producto final / anlisis del negocio
Identificar riesgos ms importantes
Establecer planificacin inicial del proyecto
Decidir si se contina
Elaboracin:
Establecer Plan Y Arquitectura Estable
Construccin: desarrollar el producto
Transicin: proporcionar sistema a usuarios
Los flujos de trabajo, actividades, roles y artefactos
Dentro de los flujos de trabajo deben involucrarse aspectos referidos a conceptos que determinan
de alguna manera conceptos de Modelado del negocio, Anlisis de requerimientos, Anlisis y
diseo, Implementacin, Pruebas y Despliegue.
Flujos de trabajo
Captura de requisitos implica: identificar requisitos del sistema, construir un modelo del
mismo (de casos de uso y de dominio o negocio
Anlisis que implica: Especificar requisitos y construir modelo del anlisis
Diseo para encontrar la forma del sistema (solucin) y construir modelo del diseo

Implementacin donde se debe codificar el diseo (solucin) y construir modelo de

implementacin
Pruebas para verificar la implementacin y construir modelo de pruebas
Fase de Iniciacin:
Establecer la planificacin del proyecto
Qu va a hacer el sistema para cada uno de sus usuarios principales?
Un MCU simplificado con los CU ms crticos
Cmo sera la arquitectura para un sistema como ese?
Borrador con los subsistemas principales
Cul es el plan y cunto va a costar desarrollar el producto?
Identificar los riesgos principales y priorizarlos, planificar elaboracin y

presupuesto aproximado
Fase de Elaboracin:
Establecer un plan para el proyecto y una arquitectura correcta
Especificar en detalle los CU + crticos
Disear la arquitectura
Mediante vistas de todos los modelos del SI
Vista arquitectnica de MCU, M. Anlisis, M. Diseo, M. Implementacin (con los
componentes que demuestran que la arquitectura es ejecutable) y M. Distribucin.
Al final de esta fase se debe poder planificar las actividades y estimar los recursos para poder
completar el proyecto. Son los CU, arquitectura y planes lo suficientemente estables y los
riesgos bajo control suficiente para firmar un contrato para terminar el trabajo de desarrollo?
Fase de Construccin:
Desarrollar el sistema, Se construye el producto. En esta fase:
La arquitectura se completa para construir un sistema bien cimentado
La visin evoluciona hasta convertirse en un producto preparado para los usuarios
Es donde se gastan la mayora de los recursos
La arquitectura del sistema es estable. Sin embargo, se pueden realizar cambios mnimos a
la misma.
El producto se ajusta suficientemente a las necesidades de algunos usuarios como para
envirselo ya?
Fase de transicin:
Proporcionar el sistema a los usuarios finales, El producto se encuentra en fase beta
Un grupo reducido de usuarios experimentados prueba el producto e informa de los
defectos y deficiencias y sugieren mejoras.

Los desarrolladores corrigen las deficiencias e incorporan algunas de las mejoras

propuestas en una versin para un grupo de usuarios mayor.
En esta fase se encuentran actividades como la venta, formacin de los usuarios,
ofrecimiento de ayuda en lnea y correccin de defectos descubiertos tras la implantacin.
Los defectos: (1) los que justifican la aparicin de una nueva versin del sistema, (2) los
que se pueden dejar para la siguiente versin que se cree.
Ejercicio de autoevaluacin
Obtener el modelo conceptual de un sistema que gestiona las matrculas de los estudiantes de la
Universidad Remington.
Una persona viene caracterizada por su ID, nombre, direccin y estado civil, y sta puede convertirse
en estudiante al darse de alta como tal en la universidad. Como estudiante podr matricularse de las
asignaturas que se imparten en la universidad, que tendrn un cdigo, un nombre, un profesor
responsable y un curso asignado. Una vez matriculado, el estudiante podr recibir una beca, y en su
nueva condicin de becario tendr asignado un nuevo cdigo y se conocer el importe de la misma;
al finalizar el curso, la condicin de becario acabar. Una vez el estudiante se matrcula, tanto si
recibe beca como si no, deber examinarse de las asignaturas en las que se encuentra matriculado
hasta que finalice el curso y vuelva a matricularse de nuevo, o bien deje la universidad y con ello deje
de ser estudiante. Adems, convendr tener una serie de aplicaciones tales como dar de alta a
nuevas personas y asignaturas, llevar a cabo la matriculacin de estudiantes en asignaturas, registrar
las notas obtenidas por los estudiantes al examinarse de cualquier asignatura en la que estn
matriculados y una serie de listados tales como los alumnos matriculados en una asignatura, las
asignaturas en las que se ha matriculado un alumno y el listado de notas por asignatura (actas).

3. LA ARQUITECTURA DE SOFTWARE.
OBJETIVO GENERAL
Presentar de manera prctica las diferentes metodologas y buenas prcticas para documentacin
y evaluacin de arquitecturas de software
Identificar y comprender los diversos aspectos del software utilizando distintos modelos o
vistas.
Describir y disear una arquitectura basados en la estructura sintctica y semntica del
ADL.
Estructurar todo el anlisis del proyecto por medio de estructuras que nos provee UML
2.0.
Crear Arquitecturas de servicios web por medio SOA para garantizar una comunicacin
rpida y transparente entre aplicaciones.
Desarrollar implementaciones sobre computacin mvil aplicando arquitecturas de alta
escalabilidad.

3.2. Prueba Inicial

grado de asimilacin
a)
b)
c)
d)
e)
Qu caracteriza el diseo en la arquitectura del software?

Cules modelos de la arquitectura puedes mencionar?
Indique al menos una caracterstica de los estilos arquitectnicos
Qu es ADL y que componentes de ste puedes indicar?
Cules son las cualidades del enfoque arquitectnico a tener en cuenta para dicho
proceso de modelamiento?
f) Indique algunos componentes del modelado UML 2.0
3.3. Modelos de arquitectura de software.

Caractersticas de un diseo de arquitectura
Propiedades estructurales: Define los componentes de un sistema y la manera en que dichos
componentes se agrupan en paquetes e interaccionan entres ellos.
Propiedades extra-funcionales: Debe indicar cmo el diseo arquitectnico alcanza los requisitos
no funcionales como: rendimiento, capacidad, fiabilidad, seguridad, adaptabilidad, etc.
Familias de sistemas relacionados: Debe permitir reconocer su estructura en los patrones
repetitivos que se encuentran de manera habitual en el diseo de sistemas similares. Debe ser
capaz de reutilizar bloques de construccin arquitecturales.
Modelos:
Estructurales: Representan la arquitectura como una coleccin organizada de componentes.
De Frameworks: Identifican patrones de diseo arquitectnico repetibles que se encuentran en
aplicaciones similares.
Dinmicos: Muestran los aspectos del comportamiento dinmico de la arquitectura, indicando
como la estructura o la configuracin del sistema pueden cambiar en funcin de eventos externos.
De procesos: Se enfocan en el diseo de los procesos del negocio que el sistema debe soportar.

Funcionales: Pueden utilizarse para representar la jerarqua funcional de un sistema.

Para tener un concepto ms claro sobre arquitectura de software podemos tener en cuenta los
siguientes aspectos:
Facilita la comunicacin entre los diferentes participantes en el desarrollo.
Resalta las decisiones de diseo que pueden tener un gran impacto en todo el proceso de
desarrollo posterior.
Aporta una visin de cmo se estructura el sistema y cmo sus componentes trabajan
juntos.
Miremos ahora los estilos arquitectnicos:
Modelos de descomposicin de sistemas.
Modelo de almacn central.
Cliente/servidor.
Modelo de mquinas abstractas.
Modelo de control
Centralizado.
Modelo de eventos.
Modelos de descomposicin modular
Modelo de flujo de datos.
Modelo orientado a objetos.
Modelo de dominio especfico
Arquitectura centrada en los datos.
Arquitectura centrada en los flujos de datos.
Arquitectura llamada y respuesta (call and return)
Arquitectura orientada a objetos.
Arquitectura en capas.
Un problema puede satisfacerse mediante diferentes estructuras a las que se llegarn
posiblemente utilizando tcnicas distintas, A veces la frontera entre dos estilos no est muy clara,
lo que provoca que haya mezcla entre ellos.

Arquitectura centrada en los datos: Como parte central de esta arquitectura aparece un almacn
de datos, el cual es accedido de manera frecuente por otros componentes que actualizan, aaden,
borran o modifican dichos almacenes.
Repositorio pasivo: El cliente software accede a los datos independientemente de cualquier
cambio en los datos o a las acciones de otros clientes software.
Repositorio activo (pizarra): El repositorio enva informacin a los clientes cuando los datos de su
inters cambian, siendo por tanto un ente activo.
Arquitectura centradas en datos proporcionan integridad, es decir, los componentes existentes
pueden cambiar y pueden aadirse nuevos componentes a la arquitectura sin que afecte a otros
clientes. A su vez los datos pueden ser pasados entre cliente a travs de mecanismos que
coordinen dicha transferencia de informacin. Miremos a continuacin una figura que nos
visualiza de manera ms general lo que acabamos de expresar.
Componentes cliente ejecutan procesos independientemente
Arquitectura centrada en los flujos de datos: Se basa en el patrn pipe and filter (tuberas y
filtros). Este consta de un conjunto de componentes denominados filtros conectados entre s
por tuberas que transmiten datos desde un componente al siguiente.
Cada filtro trabaja de manera independiente de los componentes que se encuentran situados
antes o despus de ella. Se disean de tal modo que esperan un conjunto de datos en un
determinado formato y obtiene como resultado otros datos de salida en un formato especfico.

Si el flujo degenera en una nica lnea de transformacin, se denomina secuencial batch.

Veamos una figura referente a esta arquitectura
Arquitectura llamada y respuesta (call and return): Permite a los diseadores software conseguir
estructuras de programas relativamente fciles de modificar y escalar.
Podemos encontrar diferentes estilos de este tipo:
Programa principal/subprograma: Descompone las funciones en una jerarqua de control donde el
programa principal invoca a los otros programas subordinados, los cuales pueden a su vez invocar
otros.
Llamada de procedimiento remoto: Los componentes de la arquitectura son distribuidos entre
diferentes ordenadores de la red.
Veamos a continuacin una figura de esta arquitectura:

Arquitectura orientada a objetos: Los componentes del sistema encapsulan datos y operaciones
que deben utilizarse para manipular dichos datos. La comunicacin y coordinacin entre
componentes se realiza mediante envo de mensajes.
En esencia es un sistema parecido al anterior, donde se enfatiza el empaquetamiento entre datos
y operaciones que permiten manipular y acceder a dichos datos.
Arquitectura en capas: Se definen un conjunto de niveles o capas, cada nivel interno que se
atraviesa se aproxima ms al nivel del conjunto de instrucciones mquina.
Sistemas en capas puros: Cada capa slo puede comunicarse con las vecinas. Esta solucin aunque
puede ser menos eficiente en algunos casos, facilita la portabilidad de los diseos. A continuacin
visualizamos una figura:
Una vez que el arquitecto de software, tras conocer el requerimiento, se decide a delinear su
estrategia y a articular los patrones que se le ofrecen hoy en profusin, se supone que debera
expresar las caractersticas de su sistema, o en otras palabras, modelarlo, aplicando una
convencin grfica o algn lenguaje avanzado de alto nivel de abstraccin.
A esta altura del desarrollo de la arquitectura de software, podra pensarse que hay abundancia de
herramientas de modelado que facilitan la especificacin de desarrollos basados en principios
arquitectnicos, que dichas herramientas han sido consensuadas y estandarizadas hace tiempo y
que son de propsito general, adaptables a soluciones de cualquier mercado vertical y a cualquier

estilo arquitectnico. La creencia generalizada sostendra que modelar arquitectnicamente un

sistema se asemeja al trabajo de articular un modelo en ambientes ricos en prestaciones grficas,
como es el caso del modelado de tipo CASE o UML, y que el arquitecto puede analizar visualmente
el sistema sin sufrir el aprendizaje de una sintaxis especializada. Tambin podra pensarse que los
instrumentos incluyen la posibilidad de disear modelos correspondientes a proyectos basados en
tecnologa de internet, Web services o soluciones de integracin de plataformas heterogneas, y
que, una vez trazado el modelo, el siguiente paso en el ciclo de vida de la solucin se produzca con
naturalidad y est servido por tcnicas bien definidas. Como se ver en este documento, la
situacin es otra, dista de ser clara y es harto ms compleja.
Entre las comunidades consagradas al modelado OO y la que patrocina o frecuenta los ADLS (as
como entre las que se inclinan por el concepto de estilos arquitectnicos y las que se trabajan en
funcin de patrones) existen relaciones complejas que algunas veces son de complementariedad y
otras de antagonismo.
Aunque algunos arquitectos influyentes, como Jorgen Thelin, alegan que el perodo de gloria de la
OOP podra estar acercndose a su fin, el hecho concreto es que el modelado orientado a objetos
de sistemas basados en componentes posee cierto nmero de rasgos muy convenientes a la hora
de disear o al menos describir un sistema. En primer lugar, las notaciones de objeto resultan
familiares a un gran nmero de ingenieros de software.
TEMA 2 Criterios de definicin de un ADL

Los ADLs se remontan a los lenguajes de interconexin de mdulos (MIL) de la dcada de 1970,
pero se han comenzado a desarrollar con su denominacin actual a partir de 1992 o 1993, poco
despus de fundada la propia arquitectura de software como especialidad profesional. La
definicin ms simple es la de Tracz [Wolf97] que define un ADL como una entidad consistente en
cuatro Cs: componentes, conectores, configuraciones y restricciones (constraints). Una de las
definiciones ms tempranas es la de Vestal [Ves93] quien sostiene que un ADL debe modelar o
soportar los siguientes conceptos:
Componentes
Conexiones
Composicin jerrquica, en la que un componente puede contener una sub-arquitectura
Completa
Paradigmas de computacin, es decir, semnticas, restricciones y propiedades no
funcionales
Paradigmas de comunicacin

Modelos formales subyacentes

Soporte de herramientas para modelado, anlisis, evaluacin y verificacin
Composicin automtica de cdigo aplicativo
Basndose en su experiencia sobre Rapide, Luckham y Vera [LV95] establecen como
requerimientos:
Abstraccin de componentes
Abstraccin de comunicacin
Integridad de comunicacin (slo los componentes que estn conectados pueden
comunicarse)
Capacidad de modelar arquitecturas dinmicas
Composicin jerrquica
Relatividad (o sea, la capacidad de mapear o relacionar conductas entre arquitecturas)
Tomando como parmetro de referencia a UniCon, Shaw y otros [SDK+95] alegan que un ADL
debe exhibir:
Capacidad para modelar componentes con aserciones de propiedades, interfaces e
implementaciones
Capacidad de modelar conectores con protocolos, asercin de propiedades e
implementaciones
Abstraccin y encapsulamiento
Tipos y verificacin de tipos
Capacidad para integrar herramientas de anlisis
Otros autores, como Shaw y Garlan [SG94] estipulan que en los ADLs los conectores sean tratados
explcitamente como entidades de primera clase (lo que dejara al margen de la lista a dos de ellos
al menos) y han afirmado que un ADL genuino tiene que proporcionar propiedades de
composicin, abstraccin, reusabilidad, configuracin, heterogeneidad y anlisis, lo que excluira a
todos los lenguajes convencionales de programacin y a los MIL.
La especificacin ms completa y sutil (en tanto que se presenta como provisional, lo que es
propio de un campo que recin se est definiendo) es la de Medvidovic [Med96]:
Componentes
Interfaz
Tipos

Semntica
Restricciones (constraints)
Evolucin
Propiedades no funcionales
Conectores
Interfaz
Tipos
Semntica
Restricciones
Evolucin
Configuraciones arquitectnicas
Comprensibilidad
Composicionalidad
Heterogeneidad
Restricciones
Refinamiento y trazabilidad
Escalabilidad
Evolucin
Dinamismo
Soporte de herramientas
Especificacin activa
Mltiples vistas
Anlisis
Refinamiento
Generacin de cdigo
Dinamismo
Ntese, en todo caso, que no se trata tanto de aspectos definitorios del concepto de ADL, sino de
criterios para la evaluacin de los ADLs existentes, o sea de un marco de referencia para la
clasificacin y comparacin de los ADLs.

En base a las propuestas sealadas, definiremos a continuacin los elementos constitutivos

primarios que, ms all de la diversidad existente, son comunes a la ontologa de todos los ADLs y
habrn de ser orientadores de su tratamiento en este estudio.
Componentes: Representan los elementos computacionales primarios de un sistema.
Intuitivamente, corresponden a las cajas de las descripciones de caja-y-lnea de las arquitecturas
de software. Ejemplos tpicos seran clientes, servidores, filtros, objetos, pizarras y bases de datos.
En la mayora de los ADLs los componentes pueden exponer varias interfaces, las cuales definen
puntos de interaccin entre un componente y su entorno.
Conectores. Representan interacciones entre componentes. Corresponden a las lneas de las
descripciones de caja-y-lnea. Ejemplos tpicos podran ser tuberas (pipes), llamadas a
procedimientos, broadcast de eventos, protocolos cliente-servidor, o conexiones entre una
aplicacin y un servidor de base de datos. Los conectores tambin tienen una especie de interfaz
que define los roles entre los componentes participantes en la interaccin.
Configuraciones o sistemas. Se constituyen como grafos de componentes y conectores. En los
ADLs ms avanzados la topologa del sistema se define independientemente de los componentes y
conectores que lo conforman. Los sistemas tambin pueden ser jerrquicos: componentes y
conectores pueden subsumir la representacin de lo que en realidad son complejos subsistemas.
Propiedades. Representan informacin semntica sobre un sistema ms all de su estructura.
Distintos ADLs ponen nfasis en diferentes clases de propiedades, pero todos tienen alguna forma
de definir propiedades no funcionales, o pueden admitir herramientas complementarias para
analizarlas y determinar, por ejemplo, el throughput y la latencia probables, o cuestiones de
seguridad, escalabilidad, dependencia de bibliotecas o servicios especficos, configuraciones
mnimas de hardware y tolerancia a fallas.
Restricciones. Representan condiciones de diseo que deben acatarse incluso en el caso que el
sistema evolucione en el tiempo. Restricciones tpicas seran restricciones en los valores posibles
de propiedades o en las configuraciones topolgicas admisibles. Por ejemplo, el nmero de
clientes que se puede conectar simultneamente a un servicio.
Estilos. Representan familias de sistemas, un vocabulario de tipos de elementos de diseo y de
reglas para componerlos. Ejemplos clsicos seran las arquitecturas de flujo de datos basados en
grafos de tuberas (pipes) y filtros, las arquitecturas de pizarras basadas en un espacio de datos
compartido, o los sistemas en capas. Algunos estilos prescriben un framework, un estndar de
integracin de componentes, patrones arquitectnicos o como se lo quiera llamar.

Evolucin. Los ADLs deberan soportar procesos de evolucin permitiendo derivar subtipos a partir
de los componentes e implementando refinamiento de sus rasgos.
Slo unos pocos lo hacen efectivamente, dependiendo para ello de lenguajes que ya no son los de
diseo arquitectnico sino los de programacin.
Propiedades no funcionales. La especificacin de estas propiedades es necesaria para simular la
conducta de runtime, analizar la conducta de los componentes, imponer restricciones, mapear
implementaciones sobre procesadores determinados, etctera.
3.4.
Enfoques arquitectnicos de software
Antes de enfrentarnos a tomar la decisin de una arquitectura creo que debemos tener en cuenta
cualidades como: Performance, Availability, Security, Modifiability
Tambin se debe analizar muy bien atributos como:
El sistema debe ser robusto
El sistema debe ser modificable
El sistema debe ser seguro
El sistema debe tener un desempeo aceptable
A continuacin vamos a centrarnos en 2 enfoques arquitectnicos SAAM y ATAM
SAAM - Software Architecture Analysis Method
Propsito, Contexto y escenarios, Roles, Mtodo de anlisis, Fortalezas, Debilidades
Propsito: Basado en escenarios, Foco modificabilidad, Evaluar una arquitectura o evaluar y
comparar varias
Contexto y escenarios: Atributos de calidad complejos y amorfos para evaluarse simplemente
Dependientes del contexto: Escenario. Interaccin entre un interesado y el sistema
Un escenario directo es el que puede satisfacerse sin la necesidad de modificaciones en la
arquitectura.

Un escenario indirecto es aquel que requiere modificaciones en la arquitectura para poder

satisfacerse.
Interaccin de escenarios n escenarios. Dos o ms escenarios indirectos requieren cambios sobre
el mismo componente
Roles:
Interesados externos externos (Organizacin cliente, usuarios finales, administradores del sistema,
etc.)
Interesados internos internos(Arquitectos de Software, analistas de requerimientos)
Equipo SAAM SAAM(Lder, expertos en el dominio de la aplicacin, expertos externos en
arquitectura y secretario)
Mtodo de anlisis:
Paso1: Desarrollo de escenarios.
Paso2: Descripcin de la Arquitectura.
Paso3: Clasificacin de escenarios.
Paso4: Evaluacin de escenarios.
Paso5: Interaccin de escenarios.
Paso6: Evaluacin general.
1. Desarrollo de escenarios:
Un escenario es una breve descripcin de usos anticipados o deseados del sistema. De igual forma,
estos pueden incluir cambios a los que puede estar expuesto el sistema en el futuro.
2. Descripcin de la arquitectura
La arquitectura (o las candidatas) debe ser descrita haciendo uso de alguna notacin
arquitectnica que sea comn a todas las partes involucradas en el anlisis. Deben incluirse los
componentes de datos y conexiones relevantes, as como la descripcin del comportamiento
general del sistema.
El desarrollo de escenarios y la descripcin de la arquitectura son usualmente llevados a cabo de
forma intercalada, o a travs de varias iteraciones.
3. Clasificacin y asignacin de prioridad de los escenarios
La clasificacin de los escenarios puede hacerse en dos clases: directos e indirectos.

Los escenarios indirectos son de especial inters para SAAM, pues son los que permiten medir el
grado en el que una arquitectura puede ajustarse a los cambios de evolucin que son importantes
para los involucrados en el desarrollo.
4. Evaluacin individual de los escenarios indirectos
Para cada escenario indirecto, se listan los cambios necesarios sobre la arquitectura, y se calcula
su costo.
Una modificacin sobre la arquitectura significa que debe introducirse un nuevo componente o
conector, o que alguno de los existentes requiere cambios en su especificacin.
5. Evaluacin de la interaccin entre escenarios
Cuando dos o ms escenarios indirectos proponen cambios sobre un mismo componente, se dice
que interactan sobre ese componente.
Es necesario evaluar este hecho, puesto que la interaccin de componentes semnticamente no
relacionados revela que los componentes de la arquitectura efectan funciones semnticamente
distintas.
De forma similar, puede verificarse si la arquitectura se encuentra documentada a un nivel
correcto de descomposicin estructural.
6. Creacin de la evaluacin global
Debe asignrsele un peso a cada escenario, en trminos de su importancia relativa al xito del
sistema.
Esta asignacin de peso suele hacerse con base en las metas del negocio que cada escenario
soporta. En el caso de la evaluacin de mltiples arquitecturas, la asignacin de pesos puede ser
utilizada para la determinacin de una escala general.
Fortalezas:
Los interesados comprenden con facilidad las arquitecturas evaluadas.
La documentacin es mejorada.
El esfuerzo y el costo de los cambios pueden ser estimados con anticipacin.
Analoga con el concepto de bajo acoplamiento y alta cohesin.
Debilidades:
La generacin de escenarios est basada en la visin de los interesados.
No provee una mtrica clara sobre la calidad de la arquitectura Evaluada.

El equipo de evaluacin confa en la experiencia de los arquitectos para proponer arquitecturas

candidatas.
Ahora miremos el enfoque con:
ATAM Architecture Tradeoff Analysis Method
Este mtodo de evaluacin indica cuan bien una arquitectura particular satisface las metas de
calidad, y provee ideas de cmo esas metas de calidad interactan entre ellas, como realizan
concesiones mutuas (trade off) entre ellas.
El mtodo consta de 9 pasos divididos en cuatro grupos:
1.
2.
3.
4.
Presentacin.
Investigacin y Anlisis.
Pruebas
Informes
Grupo 1 Presentacin:
1. Presentacin del ATAM: El lder de evaluacin describe el mtodo a los participantes, trata de
establecer las expectativas y responde las preguntas propuestas.
2. Presentacin de las metas del negocio: Se realiza la descripcin de las metas del negocio que
motivan el esfuerzo, y aclara que se persiguen objetivos de tipo arquitectnico.
3. Presentacin de la arquitectura: El arquitecto describe la arquitectura, enfocndose en cmo
sta cumple con los objetivos del negocio.
Grupo 2 Investigacin y Anlisis:
4. Identificacin de los enfoques arquitectnicos: Estos elementos son detectados, pero no
analizados.
5. Generacin del UtilityTree: Se priorizan los atributos de calidad que engloban la utilidad
del sistema (desempeo, disponibilidad, seguridad, modificabilidad, usabilidad, etc.),
especificados en forma de escenarios.
Se anotan los estmulos y respuestas, as como se establece la prioridad entre ellos.

6. Anlisis de los enfoques arquitectnicos: Con base en los resultados del establecimiento de
prioridades del paso anterior, se analizan los elementos del paso 4. En este paso se identifican
riesgos arquitectnicos, puntos de sensibilidad y puntos de balance.
Grupo 3 Pruebas:
7. Lluvia de ideas y establecimiento de prioridad de escenarios: Con la colaboracin de todos los
involucrados, se complementa el conjunto de escenarios.
8. Anlisis de los enfoques arquitectnicos: Este paso repite las actividades del paso 6, haciendo
uso de los resultados del paso 7. Los escenarios son considerados como casos de prueba para
confirmar el anlisis realizado hasta el momento.
Grupo 4 Reporte:
9. Presentacin de los resultados: Basado en la informacin recolectada a lo largo de la evaluacin
del ATAM, se presentan los hallazgos a los participantes.
3.5. Modelado Arquitectnico en UML 2.0

DESCOMPOSICION DE UN SISTEMA
UML 2.0 usa interfaces basadas en componentes de desarrollo.

Descompone jerrquicamente el sistema en partes ms pequeas.
Permite la reutilizacin en diferentes contextos.
AADIENDO EL COMPORTAMIENTO A LA MEZCLA
El comportamiento de una clase es delegada a sus partes y la clase misma debe contener su
comportamiento. (Mquina de estado, d. actividad, d. interaccin )
El contenedor describe el comportamiento de cmo crear las partes.
ACTUANDO SOBRE LAS ACCIONES
Acciones: Es la unidad fundamental de la especificacin de comportamiento que representa

alguna transformacin o proceso.
Las acciones tienden a ser generales y se aplican a todos los tipos e comportamiento por
instancia, mquinas de estado, interacciones o actividades.
Actividad: Es la construccin bsica del comportamiento, utilizados para modelar diagramas de
actividad, que especifican el comportamiento usando un hibrido entre el control y un modelo del
flujo de datos.)

ARQUITECTURA DE SISTEMAS EXISTENTES.

Esto sucede cuando el sistema ha sido desarrollados in una descripcin arquitectnica, o cuando el
arquitecto tiene que abandonar el proyecto por algn motivo. Para poder tener una descripcin
arquitectnica en estos casos se hace uso de la ingeniera en reversa. Es necesario tener esta
descripcin arquitectnica, con el fin de hacer mantenimiento y desarrollo de nuevas versiones del
mismo sistema.
EVALUACIN ARQUITECTNICA
El propsito de esta evaluacin es determinar la calidad de la descripcin arquitectnica, y

predecir la calidad del sistema que cuyas arquitecturas hacen parte de la descripcin
arquitectnica.
UML 2.0 integra las actividades con sus acciones relacionadas.
UML tuvo la iniciativa para especificar modelos ejecutables.
Sustituye los modelos de accin anteriores con uno nuevo en el que se puede expresar acciones
con semntica de precisin porcentual.
El sistema permite la verificacin en una etapa ms temprana en el desarrollo del ciclo de vida y
permite a las herramientas automatizar las pruebas mediante el uso de modelos UML.
La notacin no se ha especificado para las acciones de UML, diferentes vendedores de
herramientas especifican su propia sintaxis.
UML est destinado a muchas reas diferentes, tiene una definicin flexible de la semntica que
debe reforzarse en algunas zonas o especificar con ms detalle otras.
Los programadores normalmente definen un conjunto de tipos de datos predefinidos para ser
usados directamente en los modelos; El mecanismo de los perfiles de UML se destinan para
acomodarse a cada caso.
USOS DE LA DESCRIPCIN ARQUITECTNICA
Anlisis de alternativas arquitectnicas.
Planeacin para la migracin de arquitecturas.
Comunicacin entre compradores y desarrolladores.
Comunicacin entre compradores y desarrolladores.

Comunicacin entre las organizaciones involucradas en el desarrollo, la produccin,

presentacin, operacin, y mantenimiento del sistema.
Documentacin para el desarrollo y el mantenimiento.
Soporte operacional y de infraestructura.
Soporte para planeacin y presupuesto.
Preparacin de documentos de adquisicin.
Revisin, anlisis y evaluacin del sistema a travs del ciclo de vida.
Especificacin para un grupo de sistemas que comparten las mismas caractersticas.
PRCTICAS DE DESCRIPCIN ARQUITECTNICA
Documentacin arquitectnica.Ladescripcindeunaarquitecturadebecontenerlossiguientestems:
Fecha y estado de la cuestin.
Organizacin de la cuestin.
Historial de cambios.
Resumen.
Alcance.
Contexto.
Glosario.
Referencias.
Usuarios del sistema.
Compradores del sistema.
Desarrolladores del sistema.
Encargados del mantenimiento del sistema.
Vistas arquitectnicas. Es importante tener en cuenta que cada una de las vistas generadas, debe
estar relacionada con uno de los puntos de vistas mencionados anteriormente. Estas vistas deben
contener:
Un identificador y una informacin introductoria.
Representacin del sistema.
Informacin de la configuracin.
Consistencia entre las vistas arquitectnicas.
Justificacin arquitectnica.
Conclusiones:

SOA (Services Oriented Architecture)

Para empezar este tutorial, me gustara comenzar con una serie de afirmaciones que creo que
nadie me podra negar:
Los procesos de negocio de las empresas son cada da ms complejos.
La evolucin del mercado y la fuerte competencia exige a las empresas una respuesta ms
gil para aprovechar la curva de oportunidad, a la hora de ofrecer distintos servicios a los
clientes.
Esta fuerte competencia implica que las empresas tengan que ofrecer servicios de mayor
valor aadido apoyndose en acuerdos con otras empresas (por ejemplo, una lnea area
quiere ofrecer a travs de su vez, no slo reservar billetes en un vuelo, sino ofrecer una
solucin completa en base a itinerarios, hoteles, coches de alquiler, etc...)
Sin embargo, gran parte de los problemas con los que se encuentran las empresas para
evolucionar acorde al mercado es la infraestructura tecnolgica, o dicho de otro modo, la
arquitectura
A lo largo de los aos, en nuestras empresas se han ido acumulando una gran cantidad de
aplicaciones distintas que se fueron desarrollando para tratar de resolver las distintas necesidades
que iban surgiendo: ERPs, CRMs, Bases de datos, Mainframes, Sistemas CICS junto con
aplicaciones WEB / J2EE, .NET, etc... . Pero estas aplicaciones no se crearon con la idea de
interactuar entre ellas, sino como herramientas para resolver un problema en un momento dado.
En definitiva, el paisaje que nos encontramos es parecido a un archipilago de aplicaciones.

La realidad del mercado nos ha llevado a las siguientes aseveraciones:

Nuestras aplicaciones internas estn de alguna manera condenadas a entenderse, si
queremos dar una respuesta gil, a las necesidades de negocio que surgen.
Las aplicaciones de nuestra empresa estn condenadas a entenderse de alguna manera
gil con las aplicaciones de las empresas con las que queremos cooperar para ofrecer
mejor servicio a nuestros clientes.
Es, en este cajn de sastre, donde SOA pretende hacer su aparicin.
La palabra arquitectura en el mundo del software se podra definir como un conjunto de
decisiones que hemos de tomar a la hora de organizar nuestras aplicaciones, como van a
interactuar entre ellas, qu software se va a usar a la hora de comunicar entre ellas (MOMs, EAIs
etc...), qu plataformas, mquinas, sistemas operativos, lenguajes de programacin, qu tipo de
mensajes se van a intercambiar, etc...
Las decisiones que tomamos a la hora de decidir nuestra arquitectura son fundamentales, no
tanto a corto plazo, sino ms bien a largo plazo, y pueden ser a veces una trampa mortal.
SOA pretende ayudarnos a la hora de tomar este tipo de decisiones.
QU NO ES SOA?
La mejor manera de comenzar a explicar SOA, es explicar qu NO es:
SOA no es un software, no es un MOM, no es un EAI, aunque una arquitectura SOA puede
apoyarse en un conjunto de herramientas como MOMs o EAIs para conseguir su objetivo.
SOA no es una metodologa de proyecto, aunque a la hora de iniciar un proyecto orientado
a conseguir una arquitectura SOA en mi empresa, algunas metodologas se ajustan mejor
que otras: es preferible seguir un modelo en iteraciones (no confundir con iterativo como
UP), como las metodologas giles (XP, etc..), que seguir metodologas Waterfall
SOA no es otra forma de llamar a los WebServices, aunque los webservices son una
herramienta vlida para conseguir una arquitectura SOA, incluso una arquitectura SOA
podra apoyarse en la programacin distribuida (DCOM, CORBA, RMI, EJBs...)
QU ES SOA?
Entonces, Qu es SOA?
Yo me atrevera a definir SOA "una arquitectura donde la pieza fundamental es el servicio. Al ser
una arquitectura, entendemos que es un conjunto de decisiones que debemos adoptar para

montar nuestra infraestructura tecnolgica. Para poder continuar explicando la definicin, urge
definir previamente qu es un servicio. Primeramente, antes de continuar con la exposicin, os
planteo la siguiente pregunta: Cul es la duracin media de los componentes que forman parte
de la infraestructura tecnolgica de una empresa?
Una respuesta aproximada podra ser:
Las innovaciones tecnolgicas y productos nuevos aparecen aproximadamente cada 5
aos.
Nuestras aplicaciones empresariales tienen una duracin de unos 8 a 10 aos
La lgica de negocio o los procesos de negocio permanecen en vigor unos 17 o 18 aos.
Los datos (o la estructura de los datos) perduran aproximadamente 25 aos.
En base a esas respuestas, podemos intuir que a la hora de elegir como organizar nuestra
infraestructura tecnolgica, si nuestro objetivo es obtener la mxima reusabilidad y permanencia
en el tiempo, debemos adoptar decisiones que vayan orientadas hacia la independencia
tecnolgica y al acercamiento al proceso de negocio y los datos.
Entonces, Qu es un servicio?
Un servicio lo podramos definir como la resolucin de una necesidad de negocio, que debe ser
autocontenida (es decir que no contenga la resolucin de otra necesidad en el mismo) y que est
constituido por tres partes bien diferenciadas:
1. Un contrato: que define la especificacin del propsito del servicio, as como restricciones
en su uso, calidad que debe ofrecer etc..., pero sin especificar nada acerca de la tecnologa
subyacente.
2. Un interfaz fsico donde los clientes que quieren usar el servicio pueden invocarlo (podra
ser una URL)
3. Una implementacin: un servicio se apoya en alguna tecnologa para realizar lo que se
expone en su contrato. La implementacin de un servicio podr consistir en la interaccin
de distintos artefactos (EJBs, CORBA, Bases de datos ... ), y estar compuesta de:
1. Una lgica de negocio
2. Una serie de datos.
La idea que presenta SOA es construir nuestra arquitectura en base a un gran conjunto de
servicios independientes, localizables e invocables de manera transparente y agnsticos de la
tecnologa. Estos servicios que podramos denominar bsicos, permitirn construir servicios de
mayor valor aadido mediante la composicin o el engranaje de estos servicios bsicos.

ACTORES DE SOA?
Una vez que hemos visto lo que es un servicio, os voy a presentar los dems actores que deberan
participar en una arquitectura SOA:
1. Frontales de aplicacin. Estos sern no tanto partes funcionales de una arquitectura SOA sino
aquellos que se van a beneficiar de ella, es decir sern aquellos que quieran hacer uso de los
servicios ofrecidos dentro de la arquitectura. Frontales de aplicacin podrn ser tanto
aplicaciones WEB, CRMs, ERPs..., as como procesos Batch que se ejecutan de manera
nocturna, etc...
2. Servicios.
3. Repositorio de servicios. Un repositorio de servicios ser algn componente de mi
arquitectura que permitir tanto a los frontales de aplicacin como a otros servicios, descubrir
que servicios existen, cul es su interfaz y donde se encuentran fsicamente. Los objetivos de
este componente sern:
1. Crear un nivel de indireccin para localizar a los servicios

2. Servir como repositorio de informacin de los servicios existentes, contratos, calidad
de los mismos, etc...
4. Bus de servicios (ESB). Este ser un componente que permitir a todos los participantes o
actores de la arquitectura SOA comunicarse entre ellos. Este componente fundamental en la
arquitectura SOA debe ofrecer:
1. Conectividad entre frontales de aplicacin y los servicios.

2. Debe ser agnstico de lenguajes de programacin y tecnologas. Es decir debe ofrecer
una forma de comunicacin universal, para que todos puedan entenderse (por
ejemplo, puede usar XML como formato de comunicacin de los mensajes)
3. Debe ser capaz de ofrecer diferentes paradigmas de comunicacin (sincronismo y
asincronismo).

4. Debera ser capaz de ofrecer otra serie de funcionalidades transversales como:
Trazabilidad de las operaciones (logging)

Mecanismos de seguridad (autenticacin, autorizacin, encriptacin, no repudio ...)
Mecanismos de transaccionalidad: protocolo de commit en dos fases (2PC) o transacciones
en cadena y mecanismos de compensacin (SAGA) etc...
Enriquecimiento de mensajes, adaptacin etc...
Control centralizado, mecanismos de monitorizacin.
Que incluyese un procesador de BPM, que permitiese construir servicios de mayor valor
aadido en base a servicios bsicos, simplemente definiendo la lgica en algn lenguaje
del tipo BPEL o BPEL4WS, etc...
EPLOGO
Conseguir reorganizar la infraestructura tecnolgica de nuestra empresa para que se encamine
hacia una arquitectura SOA es un proceso muy complejo. He ledo en algn sitio que el 70% de los
proyectos que se embarcan en esta tarea fracasan.
No slo nos encontraremos problemas tecnolgicos, sino tambin muchos problemas debido a la
poltica y cultura empresarial. Adems, es un proceso largo (de aos) que debe ser iniciado de
manera muy cuidadosa. Es muy recomendable llevarlo a cabo de una manera gradual, y no todo
de una vez, acompaando la tarea de llevarlo a cabo con una continua "evangelizacin" de las
ventajas de SOA a todos los niveles de la empresa.
Es probable que debamos cambiar la metodologa de proyectos para orientarlo hacia
metodologas ms giles (XP) etc...
Es probable tambin que debamos empezar a modelar siguiendo la filosofa de MDA (Model
Driven Architecture), de una manera independiente de la tecnologa, partiendo desde los procesos
de negocio para ir gradualmente obteniendo el modelado especfico de la plataforma en la que
vamos a realizar la implementacin del proceso de negocio (o servicio).

Por mi parte nada ms, espero que os haya servido para entender un poco de que va esto del SOA.
Arquitecturas para computacin mvil
A principios del nuevo milenio las tecnologas mviles, obviamente, no estaban tan evolucionadas
como en la actualidad. Entre otros, se tenan los celulares por un lado, los busca personas por
otro, y las PDA (Asistentes Personales Digitales), a las que tena acceso el autor eran las de familia
PALM, el color que predominaba en la pantalla de estos dispositivos era el verde. Para la
comunicacin se dispona de un accesorio denominado modem; este accesorio se utilizaba para
enviar y recibir datos por medio de la lnea telefnica.
Emulador Palm OS, principios de los 2000

Toma del Pedido, almacenado en el Dispositivo mvil y Envi posterior por medio de la lnea
telefnica.
Arquitectura de una aplicacin mvil
Existen varios escenarios en los cuales se puede establecer la arquitectura de aplicaciones mviles;
aqu se abordaran dos de ellos.
En el primero participan tres elementos:
La aplicacin central
El proceso de sincronizacin
La aplicacin en el dispositivo mvil

Escenario nmero1.
En el segundo escenario participan dos elementos:
El dispositivo mvil
La aplicacin central
De acuerdo a las siguientes figuras desarrolle una aplicacin con los elementos descritos en esta
unidad teniendo en cuenta una muy buena arquitectura de software, como lenguaje de
programacin puede utilizar Java y su herramienta NetBeans u otra.


4. DEFINICIONES Y PATRONES DE SOFTWARE.

OBJETIVO GENERAL
Apropiar el uso de catlogos de elementos reusables en el diseo de sistemas software
Clarificar cada uno de los conceptos utilizados en patrones de software
Evitar la reiteracin en la bsqueda de soluciones a problemas solucionados
anteriormente
Estandarizar el modo en que se realiza el diseo por medio de la utilizacin de patrones
GoF
Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando
conocimiento ya existentes

4.1. Prueba Inicial

grado de asimilacin
a) Qu entiendes por patrones de diseo de software?
b) Cules son los propsitos y el mbito de los patrones de diseo?
c) Caracterice de forma sencilla al menos 2 patrones de diseo?
4.2. Definiciones Bsicas

Patrones de diseo software
El diseo es un modelo del sistema, realizado con una serie de principios y tcnicas, que permite
describir el sistema con el suficiente detalle como para ser implementado. Pero los principios y
reglas no son suficientes, en el contexto de diseo podemos observar que los buenos ingenieros

tienen esquemas y estructuras de solucin que usan numerosas veces en funcin del contexto del
problema. Este es el sentido cabal de la expresin "tener un mente bien amueblada", y no el
significado de tener una notable inteligencia. Estos esquemas y estructuras son conceptos
reusables y nos permiten no reinventar la rueda. Un buen ingeniero reutiliza un esquema de
solucin ante problemas similares.
El concepto de "patrn de diseo" que tenemos en Ingeniera del Software se ha tomado prestado
de la arquitectura. En 1977 se publica el libro "A Pattern Language: Towns/Building/Construction",
de Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King y
Shlomo Angel, Oxford University Press. Contiene numerosos patrones con una notacin especfica
de Alexander.
Alexander comenta que Cada patrn describe un problema que ocurre una y otra vez en nuestro
entorno, para describir despus el ncleo de la solucin a ese problema, de tal manera que esa
solucin pueda ser usada ms de un milln de veces sin hacerlo siquiera dos veces de la misma
forma. El patrn es un esquema de solucin que se aplica a un tipo de problema, esta aplicacin
del patrn no es mecnica, sino que requiere de adaptacin y matices. Por ello, dice Alexander
que los numerosos usos de un patrn no se repiten dos veces de la misma forma.
La idea de patrones de diseo estaba "en el aire", la prueba es que numerosos diseadores se
dirigieron a aplicar las ideas de Alexander a su contexto. El catlogo ms famoso de patrones se
encuentra en Design Patterns: Elements of Reusable Object-Oriented Software, de Erich
Gamma, Richard Helm, Ralph Johnson y John Vlissides, 1995, Addison-Wesley, tambin conocido
como el libro GOF (Gang-Of-Four).
Siguiendo el libro de GOF los patrones se clasifican segn el proposito para el que han sido
definidos:
Creacionales: solucionan problemas de creacin de instancias. Nos ayudan a encapsular y
abstraer dicha creacin.
Estructurales: solucionan problemas de composicin (agregacin) de clases y objetos.
De Comportamiento: soluciones respecto a la interaccin y responsabilidades entre clases
y objetos, as como los algoritmos que encapsulan.
Segn el mbito se clasifican en patrones de clase y de objeto:

Creacin
Estructural
De Conducta
Interprete
Plantilla
Clase
Mtodo de Fabricacin Adaptador (clases)
Objeto
Cadena
de
Responsabilidad,
Adaptador (objetos),
Comando
(orden),
Iterador,
Fbrica,
Constructor, Puente, Composicin,
Intermediario, Observador, Estado,
Prototipo, Singleton
Decorador, Fachada,
Estrategia,
Visitante,
Flyweight
Memoria
Concepto de patrn de diseo

"Una arquitectura orientada a objetos bien estructurada est llena de patrones. La calidad de un
sistema orientado a objetos se mide por la atencin que los diseadores han prestado a las
colaboraciones entre sus objetos. Los patrones conducen a arquitecturas ms pequeas, ms
simples y ms comprensibles". (Grady Booch)
Los patrones de diseo son descripciones de clases cuyas instancias colaboran entre s. Cada
patrn es adecuado para ser adaptado a un cierto tipo de problema. Para describir un caso
debemos especificar:
Nombre
Propsito o finalidad
Sinnimos (otros nombres por los que puede ser conocido)
Problema al que es aplicable

Estructura (diagrama de clases)

Participantes (responsabilidad de cada clase)
Colaboraciones (diagrama de interacciones)
Implementacin (consejos, notas y ejemplos)
Otros patrones con los que est relacionado
Ventajas de los patrones:
La clave para la reutilizacin es anticiparse a los nuevos requisitos y cambios, de modo que los
sistemas evolucionen de forma adecuada. Cada patrn permite que algunos aspectos de la
estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la
reusabilidad, extensibilidad y mantenimiento.
Un patrn es un esquema o microarquitectura que supone una solucin a problemas (dominios
de aplicacin) semejantes (aunque los dominios de problema pueden ser muy diferentes e ir
desde una aplicacin CAD a un cuadro de mando empresarial). Interesa constatar una vez ms la
vieja distincin entre dominio del problema (donde aparecen las clases propias del dominio, como
cuenta, empleado, coche o beneficiario) y el dominio de la solucin o aplicacin (donde adems
aparecen clases como ventana, men, contenedor o listener). Los patrones son patrones del
dominio de la solucin.
Tambin conviene distinguir entre un patrn y una arquitectura global del sistema. Por decirlo en
breve, es la misma distancia que hay entre el diseo de un componente (o mdulo) y el anlisis del
sistema. Es la diferencia que hay entre el aspecto micro y el macro, por ello, en ocasiones se
denomina a los patrones como "microarquitecturas".
En resumen, un patrn es el denominador comn, una estructura comn que tienen aplicaciones
semejantes. Esto tambin ocurre en otros ordenes de la vida. Por ejemplo, en nuestra vida
cotidiana aplicamos a menudo el esquema saludo-presentacin-mensaje-despedida en ocasiones
diversas, que van desde un intento de ligar hasta dar una conferencia (si todava no cree que
existan patrones o que no son tiles intente ligar con el esquema despedida-mensajepresentacin-saludo, a ver qu ocurre).

4.3. Catlogos de Patrones

Patrn "delegado"
La herencia es til para modelar relaciones de tipo es-uno es-una, ya que estos tipos de relaciones
son de naturaleza esttica. Sin embargo, relaciones de tipo es-un-rol-ejecutado-por son mal
modeladas con herencia.
Un objeto receptor delega operaciones en su delegado. Presente en muchos patrones: State,
Strategy, Visitor,..
Un ejemplo: supongamos que un objeto debe ordenar una estructura de datos. Puede delegar en
otro objeto el mtodo de comparacin. En Java tenemos un caso: la clase Collections tiene el
mtodo esttico sort(); desde este mtodo se delega en un comparador para establecer el orden:
Collections tiene el mtodo sort() con un algoritmo de ordenacin.
Comparador tiene el mtodo compare() que implementa el orden de comparacin.
import java.util.Comparator;
public class comparador implements Comparator {
public int compare( Object o1, Object o2 ) {
if ( ((ente)o1).obt_id() < ((ente)o2).obt_id() )
return 1;
if ( ((ente)o1).obt_id() > ((ente)o2).obt_id() )

return 1;
return 0;
}
}
Patrn "compuesto"
Crear jerarquas parte/todo de tal forma que los clientes manejan a los objetos primitivos y
compuestos de forma uniforme. Por ejemplo, crear figuras que son una composicin de otras
figuras simples. Otro ejemplo puede ser un activo financiero (un fondo de inversin) que es un
compuesto de otros activos financieros simples (valores o acciones).
Los clientes pueden tratar objetos primitivos y compuestos de modo uniforme y es fcil aadir
nuevos tipos de componentes.
Implementacin
Vamos a ver un ejemplo con un applet AWT en donde existen diferentes subclases de Component:
Componentes simples como TextField, List, Button, etc.
Componentes compuestos como Container, del que hereda Panel.
Veamos los atributos de la clase:

public class calculador2 extends Applet {

TextField t_n1 = new TextField(8);
TextField t_n2 = new TextField(8);
List lista = new List();
Button bot = new Button( "C a l c u l a r");
Panel panel_sup = new Panel();
Para crear compuestos podemos:
Aadir un componente simple a un Panel (tipo de Container): panel_sup.add( t_n1 )
Crear compuestos recursivos, aadiendo un Panel a otro Panel: panel_global.add(
panel_sup, BorderLayout.NORTH )
Referencias de componentes hijos a su padre puede ayudar a el recorrido y manejo de la
estructura compuesta.
Patrn "decorador"
Imaginemos que tenemos un editor de texto bsico y queremos aadirle nuevas funcionalidades,
como un scroll o un borde. Una solucin podra ser crear subclases para un editor con scroll, sin
scroll, con scroll y con borde, etc. Evidentemente esta no es una buena solucin, ya que acabamos
con una jungla de clases y subclases.
Con este patrn tratamos de evitar este efecto de herencia-jungla, ya que asignamos
dinmicamente nuevas responsabilidades a un objeto. Es una alternativa ms flexible a crear
subclases para extender la funcionalidad de una clase. De esta forma aadimos atributos o
comportamiento adicional a un objeto concreto, no a una clase.

Un ejemplo de implementacin con Java

El componente grfico es un modesto editor de texto:
JEditorPane panel_text = new JEditorPane();
Es muy sencillo aadir la funcionalidad del scroll sin usar herencia:
JScrollPane scroll_text = new JScrollPane( panel_text ); // Asignamos scroll al panel de texto.
El ltimo paso es aadir el decorador (y por aadidura el editor) al contenedor raz del applet:
cont_global.add( scroll_text );
El componente no conoce a su decorador (en este caso el scroll). Es el decorador el que referencia
a su componente. Esta es la razn de que al aadir (add) al contenedor raz debamos usar el
decorador (scroll) y no el componente (editor).
Componentes y decoradores deben heredar de una clase comn. En nuestro ejemplo JEditorPane
y JScrollPane heredan de JComponent.
Para ir a un tutorial sobre el patrn Decorador en tecnologas .NET pulse aqu.

Patrn "intermediario"
Supongamos una ventana con numerosos componentes grficos (widgets) que tienen fuertes
dependencias entre si. Por ejemplo, reglas del tipo "si el campo de edicin E2 est relleno,
entonces inhabilito el botn B1 y el campo de edicin E3".
El mediador o intermediario encapsula la forma en que interaccionan un conjunto de objetos
("colegas"). Es el especialista que define las interdependencias entre ellos. Favorece un bajo
acoplamiento, ya que evita que los objetos se referencien unos a otros de forma explcita. Permite
variar la interaccin sin tocar los colegas, por tanto favorece la reutilizacin.
Ventajas:
Evita crear subclases
Desacopla a los colegas
Simplifica los protocolos entre las clases
Abstrae el cmo cooperan los objetos
Centraliza el control en el mediador: clase difcil de mantener
Para la implementacin:
No hay necesidad de definir una clase abstracta Mediator si los colegas trabajan con un
nico mediador
Los colegas deben comunicarse con el mediador cuando un evento de inters ocurre, esta
comunicacin puede hacerse con un Observer o un interfaz de notificacin (ViewManager
de Smalltalk-V).

Cada colega tiene una referencia al mediador y de esta manera le pueden informar de los
cambios realizados. Por ejemplo, una lista informa al mediador del cambio de item
seleccionado; el mediador puede responder solicitando el texto seleccionado en la lista y
mandndolo a un campo de texto. Ver el siguiente diagrama:
Patrn "iterador"
Supongamos que tenemos un contenedor (por ejemplo, un vector) y queremos tener una forma
de acceder a los elementos sin mostrar los detalles. Un objeto contenedor debe permitir una
forma de recorrer sus elementos sin exponer su estructura interna, es decir, separar el
contenedor de la forma de recorrer sus elementos. Con este patrn tenemos la ventaja de
simplificar la interfaz de un contenedor, ya que no contiene los mtodos de recorrerlo.
Un ejemplo tpico lo tenemos en Java. El cliente solicita al contenedor un iterador. A continuacin
el iterador dirige la forma de recorrer el contenedor:
Vector vec = new Vector();
vec.add( new String( "hola ) );
vec.add( new String( "adios ) );
Iterator it = vec.iterator();
while ( it.hasNext() )
System.out.println( (String) it.next() );

Patrn "observador"
Definir una dependencia de 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos
sean avisados y se actualicen automticamente.
Supongamos que tenemos un o unos objetos dependientes de otro. Por ejemplo, supongamos que
una ventana o applet depende de los componentes grficos que reciben eventos (clic en botn,
etc.). Otro caso, tpico del patrn, es tener diversas vistas de una fuente de datos, de tal forma que
si cambia la fuente, entonces las vistas se actualicen automticamente.
El observador no es un mediador entre los sujetos (objetos que cambian de estado) y los objetos
dependientes, ya que el mismo es un objeto dependiente. El observador recibe la orden de
actualizarse por parte del sujeto "dominante"
Interesante cuando un cambio en un objeto implique cambios en otros y no se sepa cuantos

objetos necesitan cambiar. Como se puede observar en el siguiente diagrama el sujeto tiene un
mtodo notify() que se encarga de mandar el mensaje de update() a todos los observadores.
Permite la divisin de un sistema en niveles. Adems de permitir reusar sujetos y observadores

por separado.

Una extensin natural de este patrn es hacer mezcla del patrn mediador y del patrn
observador, de tal forma que los avisos de cambios que mandamos al observador sean notificados
a otros objetos dependientes. El observador recibe un mensaje de cambio de estado y notifica a
los objetos dependientes que se actualicen. Dicho de otra forma, cuando las relaciones de
dependencia entre Subject y Observer son complicadas conviene encapsular la semntica de
actualizacin en una clase ManejadorCambio(Mediador).
Implementacin
Es posible que un observer est ligado a ms de un subject: la operacin update tendr como
argumento el subject.Quin dispara la notificacin?
Mtodos set en la clase Subject
Clientes de la clase Subject
Asegurarse de notificar siendo el estado de Subject consistente. Al registrar un observar es posible
asociarle el evento sobre el que quiere ser notificado:
attach(Observer obs, Evento interes);
Ejemplo de implementacin en Java
Java 1.1 introdujo un nuevo modelo de eventos para GUI basado en el patrn Observer.
Componentes GUI que pueden generar eventos son llamados fuentes de eventos (event
sources).
Objetos que desean ser notificados de eventos GUI son llamados oyentes de eventos
(event listeners). Estos oyentes en Java trabajan como observers de nuestro patrn.
Los listeners deben registrarse en las fuentes (componentes GUI).
El orden sera "componente_GUI --->Listener ---> Objeto_dependiente (un applet, por ejemplo)
Un ejemplo en Java, extraido de una clase applet, donde al botn le aadimos un listener:
boton_crear.addActionListener(new ap_robot_boton_actionAdapter(this));
Lo primero es que el listener (ap_robot_boton_actionAdapter) se registra en el componente GUI
(en este caso boton_crear de la clase Button) por medio de una llamada a addItemListener(). En
segundo lugar, cuando se produce un evento el componente lo notifica al listener y este manda
un mensaje al applet (en nuestro caso a boton_crear_actionPerformed(ActionEvent e), para que
realice las acciones oportunas:

void boton_crear_actionPerformed(ActionEvent e) {
...
}
Obsrvese que el evento queda encapsulado por la clase ItemEvent.
Patrn "Modelo-Vista-Controlador"
Para el diseo de aplicaciones con sofisticados interfaces se utiliza el patrn de diseo ModeloVista-Controlador. La lgica de un interfaz de usuario cambia con ms frecuencia que los
almacenes de datos y la lgica de negocio. Si realizamos un diseo ofuscado, es decir, un pastiche
que mezcle los componentes de interfaz y de negocio, entonces la consecuencia ser que, cuando
necesitemos cambiar el interfaz, tendremos que modificar trabajosamente los componentes de
negocio. Mayor trabajo y ms riesgo de error.
Se trata de realizar un diseo que desacople la vista del modelo, con la finalidad de mejorar la
reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lgica
de negocio o de datos.
Elementos del patrn:
Modelo: datos y reglas de negocio
Vista: muestra la informacin del modelo al usuario
Controlador: gestiona las entradas del usuario
Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo
clsico es el de la informacin de una base de datos, que se puede presentar de diversas formas:
diagrama de tarta, de barras, tabular, etc. Veamos cada componente:

1. El modelo es el responsable de:

2. Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea
independiente del sistema de almacenamiento.
3. Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser:
"Si la mercanca pedida no est en el almacn, consultar el tiempo de entrega estndar del
proveedor".
4. Lleva un registro de las vistas y controladores del sistema.
5. Si estamos ante un modelo activo, notificar a las vistas los cambios que en los datos
pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos,
un temporizador que desencadena una insercin, etc).
6. El controlador es responsable de:
Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
Contiene reglas de gestin de eventos, del tipo "SI Evento Z, entonces Accin W".
Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas
peticiones a las vistas puede ser una llamada al mtodo "Actualizar()". Una
peticin
al
modelo
puede
ser
"Obtener_tiempo_de_entrega(
nueva_orden_de_venta )".
7. Las vistas son responsables de:
Recibe datos del modelo y los muestra al usuario.
Tienen un registro de su controlador asociado (normalmente porque adems lo
instancia).

Pueden dar el servicio de "Actualizacin ()", para que sea invocado por el controlador o por el
modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por
otros agentes).
Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es la
navegacin web, que responde a las entradas del usuario, pero no detecta los cambios en datos
del servidor.
El diagrama de secuencia:
Pasos:
1. El usuario introduce el evento.
2. El Controlador recibe el evento y lo traduce en una peticin al Modelo (aunque tambin
puede llamar directamente a la vista).
3. El modelo (si es necesario) llama a la vista para su actualizacin.
4. Para cumplir con la actualizacin la Vista puede solicitar datos al Modelo.
5. El Controlador recibe el control.
Bien, pero esto cmo se implementa? Existe una pequea dificultad: la mayor parte de las
herramientas de desarrollo incorporan en las clases de la vista gran parte o todo el procesamiento
de eventos. Con lo que el controlador queda semioculto dentro de la vista. A pesar de ello,
podemos acercarnos bastante al patrn. En el siguiente ejemplo en Java, el objeto vista es un

Applet AWT. El controlador (controlador.java) puede gestionar el clic en un botn, de tal forma
que recoge datos por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista (el applet)
para su actualizacin (vista.mostrar_texto( )):
/****************************************************************
Responde al click en botn "abrir"
La respuesta al evento es hacer que se abra en la vista
el archivo correspondiente a la referencia seleccionada en el combo box
****************************************************************/
void b_abrir_actionPerformed(ActionEvent e) {
String texto_archivo = model.cargar_texto( indice_ref ); // Obtener texto de archivo
/*** Si la carga de archivo es ok, lo muestro. Si no, aviso de error ****/
if (texto_archivo != null) {
vista.mostrar_texto(texto_archivo);
// Mostrar texto
vista.mostrar_aviso("Carga de " + path + " completada.");
}
else
vista.mostrar_aviso("Error en la carga de " + path);
}
Patrn "Factoria"
En realidad son una familia de patrones:
Factoria simple: una clase que crea objetos de otras clases. No delega en otras subclases y
sus mtodos pueden ser estticos.
Factory Method: Se define una interface para crear objetos, como en el Abstract Factory,
pero se delega a las subclases implementar la creacin en concreto
Abstract Factory: Nos da una interface para crear objetos de alguna familia, sin especificar
la clase en concreto
Los dos ltimos estn incluidos en el catlogo del GoF

Estos patrones entran en la categora de patrones de creacin [GoF95], la cual comparten con
otros patrones tales como el Singleton, Builder y Prototype [GoF95]. Tienen la responsabilidad de
crear instancias de objetos de otras clases. Tienen adems la responsabilidad y el conocimiento
necesario para encapsular la forma en que se crean determinados tipos de objetos en una
aplicacin. Existen diferentes patrones de tipo Factory.
Factorial simple
Como en todas las factorias, tenemos las clases instanciadas (JuegoDelDado y JuegoDeMoneda)
que se relacionan con una clase madre (extends) o con un interfaz lgico (implements). En nuestro
caso usamos interfaz.
A continuacin puede ver un sencillo ejemplo en el que cada juego implementa el mtodo lanzar
(): el juego del dado muestra un nmero aleatorio del 1 al 6 y el de la moneda 'Cara' o 'Cruz':
public interface Juego {
void lanzar();
}
import java.util.Random;
public class JuegoDelDado implements Juego {
public void lanzar() {
Random ran = new Random();

int resul = ran.nextInt(6) + 1;
// Aleatorio de 1 a
6
System.out.println( resul );
}
}
import java.util.Random;
public class JuegoDeMoneda implements Juego {
public void lanzar() {
Random ran = new Random();
if ( ran.nextBoolean() )
System.out.println( "Cara" );
else
System.out.println( "Cruz" );
}
}
La clase FactoriaJuegos es nica. No delega en una subclase la creacin de instancias (a diferencia

de Factory Method). Esta factoria es muy sencilla: en funcin del argumento crea un juego u otro:
public class FactoriaJuegos {
public static Juego getJuego( String nombreJuego ) {

if ( nombreJuego.equals("JuegoDelDado") )
return new JuegoDelDado();
else {
if ( nombreJuego.equals("JuegoDeMoneda") )
return new JuegoDeMoneda();
else
return null;
}
}
}
Lo esencial de la clase Factoria es que oculta a la clase cliente (Inicio.java) la complejidad de crear
un objeto. Encapsula la creacion de la instancia.
La clase cliente (Inicio.java) llama al mtodo esttico getJuego() de la factora, para que le
devuelva el juego sealado en el argumento. Introduce todos los juegos en un vector y a
continuacin le dice a cada juego que juegue. El mtodo jugar() es un ejemplo de patrn
'estrategia': el mtodo contiene un comportamiento genrico (en nuestro ejemplo realiza dos
lanzamientos para cada juego). El comportamiento especfico se define en funcin del objeto que
se pasa como argumento. La parte que vara es el argumento, esta es la estrategia.
public class Inicio {
public static void main(String[] args) {
//// Crea un vector de juegos
Vector vec = new Vector();
vec.add(FactoriaJuegos.getJuego( "JuegoDelDado") );
vec.add(FactoriaJuegos.getJuego( "JuegoDeMoneda") );
vec.add(FactoriaJuegos.getJuego( "JuegoDelDado") );
//// A cada juego del vector le dice que juegue
for ( int i = 0; i < vec.size(); i++ ) {
Juego j = (Juego) vec.get(i);
if ( j != null )
jugar( j );
else
System.out.println("Juego no encontrado");
}
}
/*****************************************************************
* Lanza dos veces

****************************************************************/
public static void jugar( Juego juego ) {
juego.lanzar();
juego.lanzar();
}
}
Al recorrer el vector de juegos vemos un ejemplo tpico de polimorfismo: a cada referencia del
tipo Juego (usamos el mismo interfaz) le decimos que juegue, pero cada juego implementa su
forma especfica de jugar (ms en concreto de lanzar). Es la idea de polimorfismo: un interfaz y
mltiples implementaciones.
Aunque la forma ms abstracta y profesional es usar en la factoria newInstance() en funcin de
los valores de un archivo .properties:
import java.io.*;
public class FactoriaJuegos {
// true=Carga de Properties desde archivo
private static boolean propiedadesCargadas = false;
// Propiedades
private static java.util.Properties prop = new java.util.Properties();
**********************************************************
Crea y devuelve el juego
*****************************************************************
public static Juego getJuego( String nombreJuego ) {
try {
//// La clase se consigue leyendo del archivo properties
Class clase = Class.forName( getClase( nombreJuego ) );
//// Creo una instancia
return (Juego) clase.newInstance();
}
catch (ClassNotFoundException e) { // No existe la clase
e.printStackTrace();
return null;
}
catch (Exception e) {// No puedo instanciar la clase

return null;
}
}
**********************************************************
* Lee un archivo properties donde se indica la clase que debe ser instanciada
***********************************************************
private static String getClase( String nombrePropiedad ) {
try {
// Carga de propiedades desde archivo
if ( !propiedadesCargadas ) {
FileInputStream
archivo
=
new
FileInputStream(
"src/factoriaJuegosNewInstanceProperties/propiedades.properties" );
prop.load( archivo
); // Cargo propiedades
propiedadesCargadas = true;
}
// Lectura de propiedad String nombreClase = prop.getProperty( nombrePropiedad, "");
if ( nombreClase.length() > 0)
return nombreClase;
return null;
}
catch ( FileNotFoundException e) { // No se puede encontrar archivo
return null;
}
catch ( IOException e) { // Falla load()
return null;
}
catch (Exception e) {
return null;
}
}
}
En el archivo properties tenemos:
dado=factoriaJuegosNewInstanceProperties.JuegoDelDado
moneda=factoriaJuegosNewInstanceProperties.JuegoDeMoneda

Patrn "Data Access Object"

El problema que viene a resolver este patrn es el de contar con diversas fuentes de datos (base
de datos, archivos, servicios externos, etc). De tal forma que se encapsula la forma de acceder a la
fuente de datos. Este patrn surge histricamente de la necesidad de gestionar una diversidad de
fuentes de datos, aunque su uso se extiende al problema de ancapsular no slo la fuente de datos,
sino adems ocultar la forma de acceder a los datos. Se trata de que el software cliente se centre
en los datos que necesita y se olvide de cmo se realiza el acceso a los datos o de cul es la fuente
de almacenamiento.
Enlace a las pginas de SUN.
Las aplicaciones pueden utilizar el API JDBC para acceder a los datos de una base de datos
relacional. Este API permite una forma estndar de acceder y manipular datos en una base de
datos ralacional. El API JDBC permite a las aplicaciones J2EE utilizar sentencias SQL, que son el
mtodo estndar para acceder a tablas y vistas. La idea de este patrn es ocultar la fuente de
datos y la complejidad del uso de JDBC a la capa de presentacin o de negocio.
Un DAO define la relacin entre la lgica de presentacin y empresa por una parte y por otra los
datos. El DAO tiene un interfaz comn, sea cual sea el modo y fuente de acceso a datos.
Algunas caractersticas:
No es imprescindible, pero en proyectos de cierta complejidad resulta util que el DAO
implemente un interfaz. De esta forma los objetos cliente tienen una forma unificada de
acceder a los DAO.

El DAO accede a la fuente de datos y la encapsula para los objetos clientes. Entendiendo
que oculta tanto la fuente como el modo (JDBC) de acceder a ella.
El TransferObject encapsula una unidad de informacin de la fuente de datos. El ejemplo
sencillo es entenderlo como un "bean de tabla", es decir, como una representacin de una
tabla de la base de datos, por lo que representamos las columnas de la tabla como
atributos del TransferObject. El DAO crea un TransferObject (o una coleccin de ellos)
como consecuencia de una transaccin contra la fuente de datos. Por ejemplo, una
consulta sobre ventas debe crear tantos objetos (TransferObject) de la clase Venta como
registros de la consulta; el DAO devolver la coleccin de TrasnferObject de la clase Venta
al objeto Cliente. Tambin puede ocurrir que el objeto Cliente mande un TransferObject
para parametrizar una consulta o actualizacin de datos por parte del DAO.
En el siguiente grfico se muestran las interacciones entre los elementos del patrn. En este
grfico el TransferObject se denomina ValueObject. Puede observarse las llamadas que recibe y
genera el DAO para una consulta y actualizacin de datos:
1.
2.
3.
4.
5.
6.
El DAO es creado por el cliente (BusinessObject) (llamada 1 del grfico).

A continuacin el cliente solicita los datos al DAO (getData) (2).
El DAO responde a la llamada pidiendo los datos a la fuente de datos (2.1).
Para cada fila recibida, el DAO crea un TransferObjet (ValueObject del grfico) (2.2).
El DAO devuelve al cliente el(los) TransferObject (2.3).
A continuacin el cliente define un TransferObject mediante llamadas a setProperty. Por
ejemplo, supongamos que buscamos personas de sexo varn y 36 aos; para ello el
BusinessObject define en el objeto de la clase Persona la edad y sexo que busca. Lo
siguiete es fcil de imaginar: el BusinessObject invoca al DAO, pasando a la persona como
argumento (3,4, y 5 del grfico).
7. En DAO.setData() se solicita (5.1 y 5.2) al TransferObjet o ValueObject (nuestra persona del
ejemplo) los datos (edad, sexo, etc.) para realizar el acceso a datos (dataSource.setData()),
(5.3).

Ejemplo de cdigo: los bean (Transfer Object)

En el siguiente sencillo ejemplo tenemos dos tablas en nuestra base de datos. La tabla de clientes
incluye:
Codigo (clave primaria)
Nombre, apellido 1 y apellido 2
Edad
En la tabla de ventas tenemos las ventas realizadas a cada cliente:
Id de la venta (clave primaria)
Codigo de cliente (clave externa)
Precio y coste de la venta
Vamos a representar estas tablas en clases que de manera informal se conocen como "beans de
tabla". Antes de crear estas tablas vamos a ver su interface comn (Bean.java):
package dao.bean;
public interface Bean {

//// Me indica si los objetos corresponden al mismo registro de base de datos (identidad de clave
primaria)
public boolean esIgual( Bean bean );
}
A continuacin escribimos los bean de tabla que implementan el interface anterior, empezamos
por la calse Cliente.java:
***************************************************************** * Bean de tabla
"cliente"
*****************************************************************
public class Cliente implements Bean {
private String codigo = null;
private String nombre = null;
private String ape1 = null;
private String ape2 = null;
private Integer edad = null;
private Vector ventas = null;
public Cliente( String codigo, String nombre, String ape1, String ape2, Integer edad ) {
setCodigo( codigo );
setNombre( nombre );
setApe1( ape1 );
setApe2( ape2 );
setEdad( edad );
}
public Cliente(){}
public String getApe1() {
return ape1; }
public void setApe1(String ape1) { this.ape1 = ape1; }
... Otros mtodos set/get ...
// Me indica si los objetos corresponden al mismo registro (identidad de clave primaria)
public boolean esIgual( Bean bean ) {
Cliente cli = (Cliente) bean;
if ( cli.getCodigo().equals( this.getCodigo()) )
return true;

return false;
}
public String toString() {
return (codigo + ", " + nombre + ", " + ape1 + ", " + ape2 + ", " + edad);
}
}
En Cliente.java se puede observar que uno de los atributos es un vector de ventas. La utilidad de
este Vector es representar en modo "objetos" una relacin 1:N de tablas (cliente y ventas) de la
base de datos. Seguimos con la clase Venta.java:
*****************************************************************
* Bean de tabla "venta"
*****************************************************************
public class Venta implements Bean {
Integer idVenta = null;
String codigo = null;
Float precio = null;
Float coste = null;
Cliente cliente = null;
public Venta(Integer idVenta, String codigo, Float precio, Float coste ) {
setIdVenta( idVenta );
setCodigo( codigo );
setPrecio( precio );
setCoste( coste );
}
public Venta() {}
public Float getCoste() {
return coste; }
public void setCoste(Float coste) {this.coste = coste; }
... Otros mtodos set/get ...
//// Me indica si los objetos corresponden al mismo registro (identidad de clave primaria)
public boolean esIgual( Bean bean ) {
Venta ven = (Venta) bean;
if ( ven.getIdVenta().intValue() == this.getIdVenta().intValue() )
return true;
return false;

}
public String toString() {
return (idVenta + ", " + codigo + ", " + precio + ", " + coste );
}
}
Ejemplo de cdigo: los DAOs
Hemos empezado por lo ms sencillo, representar las tablas de nuestra base de datos. Dicho de
otra forma proyectar el modelo relacional sobre un modelo de objetos. Ahora tenemos que
implementar los DAOs, los componentes que encapsulan el acceso a la fuente de datos (la base de
datos). Empezamos creando un interface (InterfaceDAO.java) que representa el comportamiento
genrico de cualquier DAO:
package dao.accesoDatos;
import java.sql.SQLException;
import java.util.Vector;
import dao.bean.Bean;
public interface InterfaceDAO {
public int insert( Bean bean ) throws SQLException;
public int update( Bean bean, String condicion ) throws SQLException;
public Bean find( String codigo ) throws SQLException;
public Vector select( String condicion ) throws SQLException;
public int delete(String condicion) throws SQLException;
}
A continuacin y a modo de resumen, una parte de DAOCliente.java. Se puede ver que
implementa el interface anterior y que adems hereda de DAOGeneral, una clase que contiene
servicios comunes, como por ejemplo getConexion(), cerrarConexion(Connection), etc:
public class DAOCliente extends DAOGeneral implements InterfaceDAO {
/*****************************************************************
* Inserta cliente (argumento bean)
*****************************************************************/
public int insert( Bean bean ) throws SQLException {
int numFilas = 0;
Cliente cli = (Cliente) bean;

Connection con = getConexion();

String orden = "INSERT INTO CLIENTE VALUES (" +
(cli.getCodigo()==null? null: "'" + cli.getCodigo() + "' ") + ","+
(cli.getNombre()==null? null: "'" + cli.getNombre() + "' ") +", " + (cli.getApe1()==null? null: "'" +
cli.getApe1() + "' ") +", " + cli.getApe2()==null? null: "'" + cli.getApe2() + "' ") + ", " + cli.getEdad()
+ ")";
Statement sentencia = con.createStatement();
numFilas = sentencia.executeUpdate(orden);
sentencia.close();
cerrarConexion( con );
return numFilas;
}
....
El mtodo insert() recibe el Transfer Object (bean) que vamos a insertar, devolviendo el nmero
de registros insertados (uno si ha ido bien, 0 en caso de no insercin). En el mtodo select()
recibimos la condicin (clasula WHERE) y devuelve un vector cuyos elementos son los clientes
que cumplen la condicin. Podra tambin devolver un ArrayList, que resulta ms eficiente, pero lo
esencial es que este mtodo, al igual que el anterior, oculta el uso de SQL y JDBC a la clase que la
llama (presentacin o BusinessObject):
public Vector select( String condicion ) throws SQLException {
Vector vecClientes = new Vector();
Cliente cli;
// Si la condicin es null o vacia, no hay parte WHERE
String orden = "SELECT * FROM cliente c " +
(condicion==null || condicion.length()==0 ? "":"WHERE " + condicion) +
" ORDER BY c.ape1, c.ape2, c.nombre";
ResultSet rs = sentencia.executeQuery( orden );
while (rs.next()) {
cli = new Cliente( rs.getString("codigo"), rs.getString("nombre"),
rs.getString( "ape1" ), rs.getString( "ape2" ),
(rs.getString( "edad" )==null ? null : new Integer(rs.getInt( "edad" ))));
vecClientes.add( cli );
}
sentencia.close();

return vecClientes;
}
En la siguiente figura se muestra la relacin de las clases anteriores:
Ejemplo de cdigo: la factora de DAOs

Aunque no resulta imprescindible, en proyectos de cierta envergadura necesitaremos una factoria
de objetos DAO, que se responsabiliza de instanciar el DAO adecuado (en nuestro ejemplo
DAOCliente.java o DAOVenta.java). Enlace al patrn factoria. En nuestro ejemplo hemos
implementado una Factoria Simple (FactoriaDAO.java):
package dao.accesoDatos;
import java.io.*;
/*****************************************************************
*
* Factoria que crea el DAO en funcin del argumento del mtodo getDAO()
* *****************************************************************/
public class FactoriaDAO {
// true=Carga de Properties desde archivo
private static boolean propiedadesCargadas = false;
// Propiedades
private static java.util.Properties prop = new java.util.Properties();
/*****************************************************************
* Crea y devuelve el DAO
*****************************************************************/
public static InterfaceDAO getDAO( String nombre ) {
try {

Class clase = Class.forName( getClase( nombre ) ); // La clase se consigue leyendo del

archivo properties
return (InterfaceDAO) clase.newInstance();
// Creo una instancia
}
catch (ClassNotFoundException e) {
// No existe la clase
return null;
}
catch (Exception e) { // No puedo instanciar la clase
return null;
}
}
/*****************************************************************
* Lee un archivo properties donde se indica la clase que debe ser instanciada
*****************************************************************/
private static String getClase( String nombrePropiedad ) {
String nombreClase = null;
try {
//// Carga de propiedades desde archivo
if ( !propiedadesCargadas ) {
FileInputStream archivo = new FileInputStream ( "src/dao
/propiedades.properties" );
prop.load( archivo ); // Cargo propiedades
propiedadesCargadas = true;
}
//// Lectura de propiedad
nombreClase = prop.getProperty( nombrePropiedad, "");
if ( nombreClase.length() == 0)
return null;
}
catch ( FileNotFoundException e) {// No se puede encontrar archivo
}
catch ( IOException e) {
// Falla load()
}
catch (Exception e) {
/accesoDatos

}
return nombreClase;
}
}
Esta clase lee un archivo properties donde asociamos una clave con una clase DAO. Su contenido
es sencillo:
cliente=dao.accesoDatos.DAOCliente
venta=dao.accesoDatos.DAOVenta
El mtodo getClase() recibe un String (la vlave: cliente o venta). Si no se ha cargado el archivo
properties en el atributo 'Properties prop', entonces lee archivo y carga las propiedades en prop.
getClase() devuelve el valor de la clave, por ejemplo, si recibe 'cliente' devuelve
'dao.accesoDatos.DAOCliente'. El mtodo getDAO() llama a getClase() para saber la clase DAO que
debe instanciar.
Un aspecto importante es lo que devuelve getDAO(): el tipo InterfaceDAO. Al devolver el interface,
estamos actuando con bstante generalidad: instanciamos objetos concretos, un DAOCliente.java
o un DAOVenta.java, pero lo esencial es que usamos como tipo de referencia el interface que
ambas clases implementan. La factoria hace su trabajo de modo genrico o abstracto, ya que
aunque tenga 15 clases de DAOs diferentes que instanciar, devuelve un tipo genrico, es decir,
devuelve el interface que implementan todos los DAOs.
Ejemplo de cdigo: usando lo anterior
Vamos a ver un sencillo ejemplo de capa cliente, es decir, la capa (sea presentacin o de negocio)
que debe usar lo anterior (factoria, beans y DAOs). Este sencillo ejemplo destaca una de las
ventajas de trabajar con los interface: obtenemos abstraccin (y resuabilidad). Veamos el ejemplo:
condicion = Teclado.getCadena("Condicin:"); // Obtengo condicin por teclado
InterfaceDAO dao = FactoriaDAO.getDAO( nombreTabla )
// Obtengo el DAO de la
factoria
Vector vec = dao.select( condicion );
//
La
Select
devuelve Vector
Iterator it = vec.iterator();
while (it.hasNext()) {
bean = (Bean) it.next();
System.out.println( bean.toString());
}

La variable nombreTabla es un sencillo String que contiene la clave del archivo properties. De esta
forma la factoria sabe la clase DAO que debe instanciar. Lo primero que interesa destacar es que el
DAO instanciado y devuelto por la factoria lo manejamos por medio del tipo interface
(InterfaceDAO): sea la que sea la clase instanciada usamos un tipo genrico (el interface que
implemnetan los DAO). Esto nos permite actuar con un alto grado de generalidad: para cualquier
tipo de DAO le mandamos el mismo mensaje: dao.select( condicion ). No nos vemos obligados a
realizar un cdigo para DAOCliente, otro para DAOVenta, etc; sino que con el mismo cdigo
manejamos diversos DAOs. Este es un ejemplo de patrn estrategia: el cdigo es el mismo
(unificado) y la estrategia (el comportamiento especfico) depende de los objetos (DAOs)
utilizados.
Un ejemplo final de abstraccin es que los elementos del vector los manejamos con el tipo
interface Bean (que implementan las clases 'bean'). Esto permite que les mande a todos el mismo
mensaje, bean.toString(), y que cada bean (sea de la clase que sea) implemente su
comportamiento especfico.
Otro ejemplo de aplicacin del patrn DAO con servlets. En este ejemplo las clases DAO han
cambiado ligeramente para soportar un login y password diferentes en cada conexin.
Nota final
Evidentemente los DAOs deben implementar los mtodos del interface (InterfaceDAO) que
declaran. Pero adems pueden implementar otros mtodos que no estn en el interfaz (lo cual
resta generalidad). En nuestro ejemplo hemos introducido un mtodo que nos permite hacer un
select de clientes con sus ventas correspondientes. Antes hemos visto que uno de los atributos del
'bean' Cliente.java es un vector de ventas:
public class Cliente implements Bean {

...
private Vector ventas = null;
Este vector nos permite representar en nuestro modelo de objetos la relacin 1:N de nuestras
tablas. El siguiente mtodo de DAOCliente.java nos devuelve un vector de clientes y cada cliente
contiene un vector de ventas:
/*****************************************************************
* Consulta de clientes CON sus ventas
* Si condicin es null o vacia, no se aplica en el WHERE

*****************************************************************/
public Vector selectConVentas( String condicion ) throws SQLException {
Vector vecClientes = new Vector();
Venta ven;
Cliente cliAnterior = null, cliActual = null;
//// Si la condicin es null o vacia, no hay parte WHERE
String orden = "SELECT c.codigo, c.nombre, c.ape1, c.ape2, c.edad, v.id_venta, v.precio,
v.coste FROM cliente c, venta v " +
" WHERE c.codigo = v.codigo " + (condicion==null ||
condicion.length()==0 ? "":"AND " + condicion) + " ORDER BY c.ape1, c.ape2, c.nombre";
ResultSet rs = sentencia.executeQuery( orden );
//// Recorremos el ResultSet y guardamos los clientes en un vector. Cada cliente tiene su vector de
ventas
while (rs.next()) {
//// Obtengo cliente y venta
cliActual = new Cliente(rs.getString("c.codigo"), rs.getString("c.nombre"),
rs.getString( "c.ape1" ), rs.getString( "c.ape2" ), (rs.getString( "c.edad" )==null ? null : new
Integer(rs.getInt( "c.edad" ))));
ven = new Venta( rs.getInt("v.id_venta"), rs.getString("c.codigo"),
rs.getFloat("v.precio"), rs.getFloat("v.coste"));
//// SI ES NUEVO: Si es el primer cliente (cliAnterior==null) o es distinto que el anterior ...
if ( cliAnterior == null || !cliActual.esIgual( cliAnterior ) ) {
//// El anterior es el actual
cliAnterior = cliActual;
//// Inicializo vector de ventas del cliente actual y aado venta
cliActual.setVentas( new Vector());
cliActual.addVenta( ven );
//// Aado cliente actual al vector
vecClientes.add( cliActual );
}
//// SI NO ES NUEVO CLIENTE: simplemente aado venta al cliente
else { //// Aado venta al cliente actual
cliAnterior.addVenta( ven );

}
}
sentencia.close();
return vecClientes;
}
Patrn "Proxy"
El proxy es til si queremos aadir o modificar comportamiento de una clase (la llamaremos
"objeto real") sin tener que modificarla. El proxy es un intermediario que implica un
recubrimiento del objeto real.
Un ejemplo
Tenemos un interface para escribir y leer de un soporte:
public interface Soporte {
public void escribir( String mensaje );
public String leer( int numLinea );
public Vector leer();
}
Adems tenemos una clase, denominada Pizarra, que implementa el interface Soporte y que en su
mtodo escribir(String mensaje) simplemente aade el argumento a un Vector. El mtodo leer(int
numLinea) devuelve la cadena cuyo orden dentro del vector es el argumento. El cliente (main)
pueda insertar (escribir) y obtener (leer) cadenas.
import java.util.*;
public class Pizarra implements Soporte {
private Vector mensajes = new Vector();
public void escribir(String mensaje) {
mensajes.add(mensaje);
}
public String leer(int numLinea) {
return mensajes.get(numLinea);
}

public Vector leer() {

return mensajes;
}
}
El proxy es un intermediario (que tambin implementa el interface del objeto real) y que nos
permite aadir o modificar comportamiento sin reescribir el objeto real. En escribir() del proxy
aado el nmero de lnea y delega en la Pizarra el resto de comportamiento. Es interesante
observar que este patrn evita abusar del uso de herencia. Este abuso es la primera tentacin del
novato, ya que piensa: "si quiero modificar el comportamiento de una clase hago el nuevo
comportamiento en una clase hija". No es que la herencia sea de partida ilegal o inconveniente,
simplemente se trata de no abusar de ella aplicndola a todo tipo de problema. De esta forma no
caeremos en el vicio de aquel que slo saba usar martillos y todos los problemas le parecan
clavos.
import java.util.Vector;
public class ProxyDePizarra implements Soporte {
private Soporte soporte;
public ProxyDePizarra() {
this.soporte = new Pizarra();
}
public ProxyDePizarra( Soporte soporte) {
this.soporte = soporte;
}
public void escribir( String mensaje ) {
String linea = String.valueOf(soporte.leer().size()+1) + " " + mensaje;
soporte.escribir( linea );
}
public String leer( int numLinea ) {
return soporte.leer( numLinea );
}
public Vector leer() {
return soporte.leer();
}
}
Un aspecto importante del cliente es que slo utiliza el tipo Interface Soporte para acceder al
proxy, con lo que conseguimos generalidad:

public class Inicio {

static public void main(String[] args) {
try {
//// Creamos el proxy
Soporte proxy = Factoria.getPizarra("ProxyDePizarra");
//// Escribimos (el proxy inserta nmero de lnea)
proxy.escribir("En un lugar de La Mancha");
proxy.escribir("de cuyo nombre no quiero acordarme");
for (String str : proxy.leer())
Visor.mostrar(str);
} catch (Exception e) {
}
}
}
La factoria simple es otro patrn importante. Una factora se centra en ocultar la instanciacin de
una clase. En nuestro caso anterior devuelve un objeto del tipo ProxyDePizarra:
/*****************************************************************
* Factoria de pizarra (objeto real o proxy). Recibe el nombre de la clase
* (sin especificar paquete) y crea y devuelve el objeto (real o proxy).
*****************************************************************/
public class Factoria {
static public Soporte getPizarra( String nomClase ) throws Exception {
Class clase = Class.forName( Factoria.class.getPackage().getName() + "." + nomClase);
return (Soporte) clase.newInstance();
}
}
Nota: Para que el newInstance() de la Factoria pueda funcionar debe existir un constructor sin
argumentos en el ProxyDePizarra. El visor es algo elemental, tan slo sirve para diferenciar el
modelo de la vista:
public class Visor {
static public void mostrar( String mensaje ) {
System.out.println( mensaje );
}
}
El resultado final sera:

1 En un lugar de La Mancha
2 de cuyo nombre no quiero acordarme
Otras caractersticas
El proxy y el objeto real comparten interface. El proxy debe tener una referencia al objeto real.
Ya hemos dicho que el proxy es un intermediario que implica un recubrimiento del objeto real
para aadir o modificar comportamiento. Especialmente apropiado cuando estamos en
situaciones en las que tenemos que elegir entre las operaciones del objeto real y las del proxy.
Aunque en el ejemplo anterior no hacemos instancia del objeto real ni permitimos ningn acceso
directo a l, podramos tener dos tipos de acceso: uno directo al objeto real y otro al proxy.
soporte piz = Factoria.getPizarra("Pizarra");
Soporte proxy = new ProxyDePizarra(piz);
piz.escribir("XYZ"); // NO aade n de lnea
proxy.escribir("QQQ"); // SI aade n de lnea
Disee el anlisis del ejercicio de la Unidad1 utilizando Patrones de Software de tal manera que el
objetivo final sea la base fundamental para una posterior implementacin en cualquier lenguaje de
programacin orientado por aspectos.

5. FRAMEWORKS Y EL MDELO MDA (MODEL DRIVEN ARCHITECTURE)

OBJETIVO GENERAL
Identificar las caractersticas de un framework para Web y apropiarse del modelado bajo el
enfoque MDA.
Conocer y graficar los conceptos y estructura de un frameworks
Establecer y aplicar las tcnicas para la implementacin de framework a nivel empresarial.
Identificar y diferenciar las tecnologas para desarrollos de software basados en
MDA/MDD
Diferenciar PSM de PIM aplicadas en MDA

5.2. Prueba Inicial

grado de asimilacin
1.
2.
3.
4.
5.
6.
Sabes en que consiste el Framework?

Qu aspectos relevantes del patrn MVC podras indicar?
Qu podras aportar acerca de Strust y URLs desde ste contexto?
Sobre los conceptos MDA, PIM, PSM y CIM que podras aportar?
Podras graficar el proceso interactivo del modelado MDA?
A qu se hace referencia con los trminos infraestructura y ncleo comn, perfiles y
metamodelado.
5.3. Definicin y Estructura del Frameworks

El objetivo de este trabajo es explicar de forma clara y sencilla en que consiste un framework para
sistemas Web y las caractersticas generales de stos, A continuacin se realiza una breve
descripcin de Struts, uno de los framewoks ms utilizados en desarrollo Web bajo plataforma
Java.
1. Qu es un framework Web?.
En general, con el trmino framework, nos estamos refiriendo a una estructura software
compuesta de componentes personalizables e intercambiables para el desarrollo de una
aplicacin. En otras palabras, un framework se puede considerar como una aplicacin genrica
incompleta y configurable a la que podemos aadirle las ltimas piezas para construir una
aplicacin concreta.
Los objetivos principales que persigue un framework son: acelerar el proceso de desarrollo,
reutilizar cdigo ya existente y promover buenas prcticas de desarrollo como el uso de patrones.
Un framework Web, por tanto, podemos definirlo como un conjunto de componentes (por
ejemplo clases en java y descriptores y archivos de configuracin enXML) que componen un
diseo reutilizable que facilita y agiliza el desarrollo de sistemas Web.

2. Patrn MVC y Model 2.

Para comprender como trabajan los frameworks Web existentes es imprescindible conocer el
patrn MVC.
El patrn Modelo-Vista-Controlador es una gua para el diseo de arquitecturas de aplicaciones
que ofrezcan una fuerte interactividad con usuarios. Este patrn organiza la aplicacin en tres
modelos separados, el primero es un modelo que representa los datos de la aplicacin y sus reglas
de negocio, el segundo es un conjunto de vistas que representa los formularios de entrada y salida
de informacin, el tercero es un conjunto de controladores que procesa las peticiones de los
usuarios y controla el flujo de ejecucin del sistema.
La mayora, por no decir todos, de los framewroks para Web implementan este patrn. Una
aplicacin de este patrn en entornos Java para programacin Web es lo que se conoce con el
nombre de arquitectura modelo 2.
Esta arquitectura consiste, a grandes rasgos, en la utilizacin de servlets paraprocesar las

peticiones (controladores) y pginas JSP para mostrar la interfaz de usuario(vistas),
implementando la parte del modelo mediante JavaBeans o POJOs.
3. Tipos de framework Web.
Existen varios tipos de frameworks Web: orientados a la interfaz de usuario, como Java Server
Faces, orientados a aplicaciones de publicacin de documentos, como Coocon, orientados a la
parte de control de eventos, como Struts y algunos que incluyen varios elementos como Tapestry.
La mayora de frameworks Web se encargan de ofrecer una capa de controladores de acuerdo con
el patrn MVC o con el modelo 2 de Servlets y JSP, ofreciendo mecanismos para facilitar la

integracin con otras herramientas para la implementacin de las capas de negocio y

presentacin.
4. Caractersticas.
A continuacin enunciamos una serie de caractersticas que podemos encontraren prcticamente
todos los frameworks existentes.
5. Un ejemplo: Struts
El framwrok open-source Struts ha sido desarrollado en Java mediante servlets y est basado en el
Modelo 2, el cual es una variante del patrn MVC.

Struts ofrece su propio componente controlador y proporciona integracin con otras tecnologas
para implementar el modelo, mediante tecnologas de acceso a datos como JDBC o Hibernate, y la
vista, mediante JSP, Velocity o XSLT.
Struts ofrece un sistema de tuberas que permite la comunicacin entre el modelo que contiene
los datos y las vistas que ofrecen estos datos a los usuarios y reciben sus rdenes.
6. URLs.

5.4. MDA (Model Driven Architecture)

Model Driven Architecture (MDA) es una aproximacin definida por el Object Management Group
(OMG) [OMG], mediante la cual el diseo de los sistemas se orienta a modelos. En ocasiones, el
trmino MDA se intercambia con el de MDD (Model-Driven Development). MDD se refiere a las
actividades que llevan a cabo los desarrolladores, mientras que MDA se refiere a su definicin
formal. Definicin creada por el grupo de trabajo OMG, que se centra en la creacin de un marco
de trabajo formal, en el que puede operar MDD [Gardner 2006].
A pesar de estas sutiles diferencias, ambos trminos se utilizan de manera indistinta en este
trabajo.
El desarrollo orientado a modelos permite una alta flexibilidad en la implementacin, integracin,
mantenimiento, prueba y simulacin de los sistemas. Una de las ideas principales por la que surge
MDA es separar la especificacin de los sistemas de los detalles de su implementacin en una
determinada plataforma. MDA provee un conjunto de herramientas para especificar un sistema
independientemente de la plataforma de implementacin, especificar dichas plataformas, elegir
una determinada plataforma para el sistema, y transformar las especificaciones de los sistemas a
la plataforma elegida. Todo esto se complementa con los objetivos de portabilidad,
interoperabilidad y reusabilidad.
La independencia propuesta por MDA se consigue mediante una catalogacin de modelos que
permiten especificar el sistema desde diferentes puntos de vista. Los tipos ms destacables de
modelos son los siguientes:
Computational Independent Model (CIM): son visiones de los sistemas desde el punto de
vista del problema a resolver, es decir, un modelo simplificado que se abstrae de detalles
especficos.
Platform Independent Model (PIM): muestra una vista del diseo del sistema obviando
detalles de plataformas concretas.
Platform Specific Model (PSM): muestra un diseo del sistema incluyendo detalles
especficos de la plataforma.

Desarrollo de Software Tradicional

El desarrollo de sistemas software siempre ha sido una labor intensa, pero a medida que ha ido
evolucionando la tecnologa, esta labor se ha complicado cada vez ms. La evolucin de los
lenguajes, entornos y tcnicas de programacin provoca que haya que desarrollar los mismos
sistemas una y otra vez, que stos utilicen e integren diferentes tecnologas o que exista una
necesidad de comunicacin entre sistemas dispares. A todo esto hay que aadirle los continuos
cambios en los requerimientos, ya sean impuestos por los usuarios de los sistemas o derivados de
los cambios tecnolgicos [Schach 2005].
El enfoque tradicional del desarrollo de software no es capaz de absorber toda esta casustica de
una forma eficiente, por problemas que vienen derivadas de su propio planteamiento, que se
resumirn a continuacin.
Uno de los principales problemas es la productividad. Los desarrollos como los conocemos estn
dirigidos por un diseo y una codificacin a bajo nivel. El proceso tpico de un desarrollo de
software, tal y como se muestra en la Figura 2-1 ([Kleppe 2005]), incluye las siguientes fases:
Conceptualizacin y toma de requisitos
Anlisis y descripcin funcional
Diseo
Codificacin
Pruebas
Implantacin

Ciclo de vida del desarrollo de software tradicional

Como se expresa en la figura, las tres primeras fases se centran en generar la documentacin y los
diagramas que definen el sistema, e incluso en muchos casos, se utiliza UML [OMG UML] para
definir los casos de uso, diagramas de clases, de interaccin o de actividades. Por el contrario, las
tres ltimas fases se centran bsicamente en la codificacin, utilizando como punto de partida la
documentacin generada previamente. En el momento de iniciar la codificacin del software, toda
la documentacin generada hasta el momento, la utilizan los programadores para poder iniciar su
trabajo. Incluso, en el caso de utilizar UML en la fase de anlisis, muchas herramientas CASE
generan cdigo a partir de los diagramas.
El desarrollo tradicional de software trata las fases del ciclo de vida como fases independientes y
completas. [Schach 2005], explica grficamente que si un sistema es un modelo de la realidad, si
sta cambia, el sistema debe cambiar, por lo que los requerimientos pueden modificarse
constantemente. Este y otros factores como los errores que se puedan producir por el equipo de
desarrollo en las diferentes fases del ciclo de vida, lo que provocan el que haya un proceso
iterativo que obligue a volver a la fase de requisitos para volver a revisar todas las fases anteriores.
Las iteraciones deben ser completas por muchas razones, pero la principal es el mantenimiento de
la documentacin, ya que sta es uno de los valores fundamentales de los sistemas. Un sistema no
es slo el cdigo.

Aproximacin MDA
La arquitectura dirigida por modelos (MDA) [Mellor 2004] es una aproximacin para el desarrollo
de software definido por el OMG. La clave de MDA es la importancia que le da a los modelos en el
los procesos de desarrollo.
Como se puede observar en la Figura 2-2 ([Kleppe 2005]), que el ciclo de vida de los desarrollos
MDA, no es muy diferente del visto en la seccin anterior. En realidad, el enfoque de Kleppe se
centra en las fases de desarrollo, pero en segn el proceso unificado de desarrollo [Jacobson
2001], el ciclo de vida del desarrollo de software se basa en una combinacin de incrementos de
estas fases. Como ya se ha comentado, se pueden cometer errores en cada una de estas, por lo
que es conveniente detectarlos de forma temprana para evitar costes y desviaciones posteriores.
Para facilitar esta tarea, lo ideal es abordar los diferentes componentes de un sistema de
informacin (o artefactos) de forma incremental, de manera que en cada incremento se van a
realizar todas las fases del ciclo de vida en mayor o menor medida. Cada incremento, ser como
un pequeo proyecto en el que se ejecutarn las fases de requisitos, anlisis, diseo
implementacin y pruebas.
Dentro de cada una de ellas, existirn las iteraciones necesarias para revisar cada artefacto hasta
que se complete el incremento y se pueda continuar con el siguiente.

Bsicamente los modelos tres tipos de modelos explicados a continuacin, son la base de MDA
[OMG 2003a]:
Modelos independientes del cmputo (CIM): asimilable a los modelos del dominio y/o del
negocio del proceso unificado de desarrollo [Jacobson 2001]. As, por ejemplo, un CIM de
una biblioteca hablara de las entidades persistentes Usuario, Ejemplar, Prstamo, etc.
Modelos independientes de la plataforma (PIM): son modelos con un alto nivel de abstraccin que
son independientes de la tecnologa en la que se van a implantar. Describen el sistema desde el
punto de vista de los procesos de negocio que van a soportar. As, un PIM de una biblioteca
hablara de servicios de la aplicacin de la biblioteca, de los objetos del negocio Usuario, Ejemplar,
Prstamo, etc.
Modelos especficos de plataforma (PSM): especifican el sistema en trminos de las
construcciones que se van a implementar a la hora de desarrollar. Un modelo PIM puede
generar distintos modelos PSM, en funcin de las tecnologas utilizadas. As, un PSM de
una biblioteca hablara de JSP [SUN JSP], conexiones JDBC [SUN JDBC], etc.
Cdigo: la fase final del desarrollo es transformar cada PSM en cdigo. Como cada PSM es
relativo a una tecnologa determinada esta transformacin es, tericamente,
relativamente sencilla.

Proceso unificado de desarrollo. Diagrama de incrementos e iteraciones

MDA define los modelos PIM, PSM y el cdigo, as como la manera de relacionarse unos con otros.
Los modelos PIM se deben crear, despus se deben transformar en uno o varios PSM (el paso ms
complejo en los desarrollos MDA) y finalmente transformarlo en cdigo.
La novedad de MDA frente al desarrollo tradicional, es que las transformaciones se hacen se
pueden hacer mediante herramientas que las ejecutan de forma automtica. En concreto, la
mayor aportacin de MDA y su mayor beneficio, es la transformacin de modelos PIM a modelos
PSM.
Las transformaciones, aunque es deseable que se realicen de forma automtica mediante
herramientas, no siempre se pueden realizar.
La portabilidad en MDA se consigue gracias a su propio planteamiento. Siempre se va a partir del
mismo PIM y en el caso de tener que migrar el sistema a otra tecnologa, slo ser necesario
generar el PSM apropiado para la nueva plataforma. Slo es necesario tener una herramienta que
realice la transformacin, que puede encontrarse en el mercado para tecnologas con una alta tasa
de uso o que haya que construirla, en caso de ser una tecnologa poco utilizada.

Interoperabilidad MDA mediante puentes

Como hemos visto ms arriba, un PIM puede generar uno o varios PSM, en funcin de las
plataformas en las que se vaya a implantar el sistema. El conjunto resultante de PSM, sin embargo,
no estarn directamente comunicados entre ellos. Para conseguir la interoperatibilidad, hay que
transformar conceptos de una plataforma en los de otra, construyendo lo que en terminologa
MDA se llaman puentes (bridges). Esta idea est mostrada en la Figura 2-4 ([Kleppe 2005]).
En un caso como el del ejemplo, se pueden deducir los elementos relacionados de los PSM,
mediante las transformaciones que se deben realizar desde el PIM a cada uno de los PSM
resultantes. Como conocemos los detalles tcnicos de ambas plataformas, ya que sin ellos no se
podran definir las transformaciones, podemos obtener toda la informacin necesaria para
construir los puentes entre los dos PSM. Lo mismo ocurre a nivel de cdigo.
Infraestructura comn
La infraestructura UML se define por la InfrastructureLibrary que especifica el ncleo (core) del
metalenguaje. Define constructores bsicos y conceptos comunes que se reutilizan para definir
varios metalenguajes, tales como MOF o CWM, a parte del propio UML. Tambin tiene el objetivo
de alinear arquitectnicamente MOF y UML con el fin de poder reutilizar los mismos metamodelos
para ambos lenguajes. Por ltimo, esta librera tambin permite una personalizacin de UML
mediante perfiles que facilitan la creacin de nuevos lenguajes basados en el mismo core.

La InfrastructureLibrary es un paquete que est compuesto a su vez por los paquetes Core y
Profiles.
El paquete Core es un metamodelo completo diseado para una alta reusabilidad, de manera que
permita extender metamodelos descritos en MOF en el mismo metanivel, mediante la utilizacin o
especializacin de sus metaclases. Tal es el caso de UML, CWM y MOF que todas dependen de un
ncleo comn, tal y como se muestra en la Figura 3-1 ([OMG 2007a]). El paquete Core, por lo
tanto, es el corazn que sustenta toda la arquitectura de la aproximacin MDA.
Papel del ncleo comn
El paquete Profiles depende del paquete Core y define los mecanismos que se usan para
personalizar metamodelos existentes centrndose en plataformas especficas o dominios
particulares. Si se desea extender un metamodelo, como es el caso de UML, se puede especificar
un perfil partiendo de este paquete y generar un nuevo lenguaje de modelado especfico y
personalizado. Se puede considerar como un mecanismo de extensin ligero de los metamodelos
definidos con MOF alternativo al metamodelado, ya que es mucho ms cmodo ampliar el
metamodelo que crear uno completamente nuevo. Adems la ventaja es que, como se indica en la
Figura 3-2 ([OMG 2007a]), con Profiles se puede extender un metamodelo definido en MOF sin
variar su definicin original.

Extensin de un metamodelo mediante Profiles

En este ejemplo se ve que MiMetamodelo es un metamodelo que contiene dos metaclases.
MiPerfil es un perfil que referencia a MiMetamodelo y a una de sus clases (Metaclase1). Sin
embargo hay una referencia explcita a Metaclase2 que anula la referencia al metamodelo. La
aplicacin de MiPerfil sobre algn modelo basado en MiMetamodelo, mostrar instancias de
Metaclase2 (porque est explcitamente referenciada mediante una referencia de metaclase).
Tambin estarn visibles las instancias de Metaclase1 que son extendidas por una instancia de
MiEstereotipo. Sin embargo, las instancias de Metaclase1 que no se extienden por MiEstereotipo
permanecern ocultas.
Unified Model Language (UML)
UML [Booch 2005] es un lenguaje estndar para visualizacin, especificacin, construccin y
documentacin de sistemas software y otros sistemas no software. Representa una coleccin de
buenas prcticas que proporcionan un xito acreditado en el modelado de grandes y complejos
sistemas [OMG 2005a]. Fusiona conceptos de las metodologas de Booch [Booch 2007], de OMT
(Object Modeling Technique) [Rumbaugh 1996] y de OOSE (Object-Oriented Software Engineering)
[Jacobson 1996] consiguiendo como resultado un lenguaje de modelado comn, sencillo y
ampliamente utilizado por los usuarios de stos y otros mtodos de desarrollo, ampliando sus
posibilidades. Por ejemplo, UML puede modelar sistemas concurrentes y distribuidos.
Los grandes objetivos que se persiguen con UML son los siguientes:
Proveer a los usuarios de un lenguaje de modelado fcil de usar y visual para el desarrollo
de modelos.
Proporcionar mecanismos de especializacin y extensin de conceptos elementales del
Core.

Soportar especificaciones independientes de lenguajes de programacin y procesos de

desarrollo especficos.
Alentar a la industria para aportar nuevas herramientas al mercado.
Soportar conceptos de desarrollo de alto nivel como componentes, colaboraciones,
entornos de trabajo y patrones.
Integrar las buenas prcticas en los procesos de desarrollo.
La especificacin del lenguaje UML est basada en la aproximacin de metamodelado, por lo que
se sita en el nivel M2 de la arquitectura MDA. La definicin de UML est basada en los siguientes
principios de diseo [OMG 2007a]:
Modularidad: que se consigue agrupando constructores en paquetes y organizando
aspectos comunes en metaclases.
Estratificacin: la divisin en capas se aplica de dos formas en el metamodelo UML. La
primera es la estructura de los paquetes que se estratifica para separar los constructores,
que forman el ncleo (core) del metalenguaje, de los constructores de alto nivel que los
usan. En segundo lugar, el patrn de la arquitectura de cuatro capas se aplica para separar
aspectos en diferentes niveles de abstraccin.
Divisin en partes: se organizan en partes diferentes reas conceptuales dentro de la
misma capa.
Extensibilidad: UML se puede extender de dos maneras.
Mediante el uso de perfiles (profiles) se pueden crear nuevos dialectos, adaptando
construcciones a plataformas o dominios especficos.
Reutilizando parte del paquete InfraestructureLibray para aumentarlo con nuevas
metaclases y metarrelaciones y as crear un nuevo lenguaje de modelado relacionado con
UML, que estrictamente sera ya un metamodelo diferente.
Reusabilidad: la reusabilidad se consigue mediante libreras de metamodelado flexibles
que permitan definir metamodelos como el UML o como otros relacionados, tales como
MOF (Meta Object Facility) o CWM (Common Warehouse Metamodel), que se vern ms
adelante.
El metamodelo de UML se define en UML Superstructure [OMG 2007b], metamodelo descrito en
MOF y que a su vez est basado tambin el paquete Core, como se ha comentado en el apartado
anterior. El paquete UML proporciona los constructores a nivel de usuario y se compone de
diferentes paquetes que se encargan de gestionar los diferente modelos estticos (o de
estructura) y dinmicos (o de comportamiento).

Paquetes UML que soportan modelos estructurales y de comportamiento

UML Profiles
Como ya hemos comentado, UML Infrastructure define la posibilidad de extender UML de manera
que se pueda crear un nuevo lenguaje de modelado sin necesidad de definirlo modificando su
metamodelo definido en MOF. Este mecanismo lo proporcionan los perfiles UML (Profiles) y lo que
permiten es aplicar a UML nuevas especificaciones aadiendo nuevos tipos de elementos del
lenguaje o restricciones al mismo.
Este mecanismo lo proporciona el paquete Profiles el cual define los mecanismos para extender y
adaptar las clases de un metamodelo cualquiera descrito en MOF a diferentes propsitos o
necesidades concretas, tales como los demandados por diferentes plataformas (como pueden ser
J2EE o .NET) o dominios de aplicacin (como los de tiempo real, modelado de procesos de
negocio, etc.).
[OMG 2007a] seala varias razones por las que se puede necesitar personalizar un metamodelo:
Disponer de una terminologa propia que se adapte a una plataforma particular o un
dominio de aplicacin.

Dotarse de una sintaxis para construcciones que no cuentan con una notacin propia
(como es el caso de las acciones).
Obtener nuevas notaciones para smbolos ya existentes para adaptarlas al dominio de
aplicacin.
Aadir semntica no especificada en el metamodelo
Aadir restricciones al metamodelo de manera que acoten el uso del metamodelo y sus
constructores.
Aadir informacin til para la realizacin de transformaciones entre modelos.
Un perfil se define en un paquete UML estereotipado profile que extiende a un metamodelo o a
otro perfil. Los mecanismos para definir los perfiles son tres: estereotipos (stereotypes),
restricciones (constraints) y valores etiquetados (tagged values) [Fuentes 2004].
Un estereotipo viene definido por un nombre y por una serie de metamodelos sobre los que
puede asociarse. Grficamente, los estereotipos se definen dentro de cajas estereotipas
stereotypes que se asocian con las metaclases que va a extender, segn la Figura 3-4 ([Fuentes
2004]), el perfil UML WeighthsAndColors define dos estereotipos: Colored y Weighed que se
asocian a las metaclases Class y Association el primero y slo a Association el segundo.
Las restricciones son condiciones que se aplican a los estereotipos. En concreto a los elementos
del metamodelo que han sido estereotipados. En el ejemplo de la Figura 3-4, se puede imponer la
restriccin de que si dos o ms clases estn unidas por una asociacin coloreada, el color de las
clases debe coincidir con el de la asociacin. Estas restricciones suelen escribirse con el lenguaje
OCL.
Un valor etiquetado es una meta-atributo adicional que se asocia a una metaclase del
metamodelo extendido por un perfil. Todo valor etiquetado deber tener un nombre y un tipo y
deber estar asociado a un determinado estereotipo. En el ejemplo de la Figura 3-4 el estereotipo
Weighed tiene un valor etiquetado Weight de tipo integer que indicar el peso de cada asociacin
que haya sido estereotipada como Weighed. Los valores etiquetados se representan como
atributos de la clase que define el estereotipo.

EJEMPLO DE PERFIL UML

Meta Object Facility (MOF)
MOF es un estndar de OMG que provee de un marco de trabajo de gestin de metadatos y de un
conjunto de servicios para permitir el desarrollo de la interoperabilidad de sistemas dirigidos por
modelos y metadatos [OMG 2006a]. Muchas de las tecnologas estandarizadas por OMG (UML, el
propio MOF, CWM, SPEM, XMI y varios perfiles UML) usan MOF y sus tecnologas derivadas
para un intercambio dirigido por metadatos y la manipulacin de los mismos. As mismo, MOF
introduce el concepto de los modelos independientes de plataforma de metadatos, adems del
mapeo de estos PIM a plataformas especficas.

Meta niveles de MOF y UML

Como se muestra en la Figura anterior, en la arquitectura de metamodelado de cuatro capas MOF
estara situado a nivel del meta-meta modelo (M3), ya que con l, como hemos viso, se definen los
meta modelos situados en el nivel M2. No obstante, desde su primera versin, MOF ha estado
ntimamente ligado a UML, debido al alineamiento arquitectnico derivado de compartir el mismo
core. Uno de los mayores xitos de la infraestructura comn es precisamente este alineamiento.
Mediante el paquete Core se consigue que todos los elementos del meta modelo sean
compartidos por UML y MOF. No obstante, UML se define como un modelo descrito mediante un
metamodelos MOF. Es decir, cada elemento de UML es una instancia de un elemento del modelo
de MOF. Este alineamiento es posible porque la InfrastructureLibrary UML se usa en ambos
metaniveles.
El hecho de que tanto MOF como UML tengan en comn la InfrastructureLibrary, incluye los
siguientes beneficios:
Simplifica las reglas para el modelado de metadatos
Las tecnologas de mapeos de MOF (XMI, JMI, etc.), se pueden aplicar a los modelos UML,
incluidos los perfiles UML.
Permite un amplio abanico de herramientas para el metamodelado, ya que cualquier
herramienta UML se podr utilizar para modelar metadatos fcilmente Adems de estos
beneficios, MOF incluye una serie de paquetes que facilitan la consecucin de las
capacidades de reutilizacin de MOF desde otros modelos o metamodelos. Estos paquetes
son los descritos a continuacin:
Reflection: que extiende un modelo con la habilidad de ser autodescriptivo.
Identifiers: que provee una extensin para objetos del metamodelo identificados
excepcionalmente, sin contar con el dato del modelo que puede ser sujeto de cambio.
Extensin: un simple significado para extensiones de elementos del modelo con el par
nombre valor.

Ahora veamos un esquema completo de MDA
Ejercicios de autoevaluacin
Explique claramente por medio de un cuadro paralelo las ventajas, desventajas, diferencias y
caractersticas sobre los diferentes FrameWorks.
Aplique el modelo MDA completamente al ejercicio planteado para la Unidad 1

6. ASPECTOS
OBJETIVO GENERAL
Aprender a definir los conceptos entre Aspectos y un lenguaje orientado por objetos.
Identificar e implementar los parmetros sobre diferenciadores entre los lenguajes por
objetos y lenguajes por aspectos
Crear ambientes de desarrollo aplicando las metodologas por aspectos
Apropiar las principales caractersticas de las Bases de Datos orientadas a aspectos.
6.2. Prueba Inicial

grado de asimilacin
Qu significan las siglas POA, LOA?
Qu propiedades debe satisfacer el LOA?
En el este contexto y en sus palabras defina lo que es un aspecto?
Qu lenguajes orientados a aspectos puedes indicar?

6.3. Definiciones Bsicas

La idea central que persigue la POA es permitir que un programa sea construido describiendo cada
concepto separadamente.
El soporte para este nuevo paradigma se logra a travs de una clase especial de lenguajes,
llamados lenguajes orientados a aspectos (LOA), los cuales brindan mecanismos y constructores
para capturar aquellos elementos que se diseminan por todo el sistema. A estos elementos se les
da el nombre de aspectos. Una definicin para tales lenguajes sera: Los LOA son aquellos
lenguajes que permiten separar la definicin de la funcionalidad pura de la definicin de los
diferentes aspectos.
Los LOA (Lenguajes Orientados a Aspectos) deben satisfacer varias propiedades deseables, entre
ellas:
- Cada aspecto debe ser claramente identificable.
- Cada aspecto debe auto-contenerse.
- Los aspectos deben ser fcilmente intercambiables.
- Los aspectos no deben interferir entre ellos.
- Los aspectos no deben interferir con los mecanismos usados para definir y evolucionar la
funcionalidad, como la herencia.
Qu es un aspecto?
Gregor Kickzales y su grupo, Lo que propone es agrupar los lenguajes orientados a objetos, los
procedurales y funcionales como lenguajes de procedimiento generalizado (LPG), ya que sus
mecanismos claves de abstraccin y composicin pueden verse como agrupados bajo una misma
raz. Esa raz tendra la forma de un procedimiento generalizado. Los mtodos de diseo que han
surgido para los LPG tienden a dividir el sistema en unidades de comportamiento o funciones. A
este estilo se lo conoce como descomposicin funcional (si bien la naturaleza exacta de la
descomposicin funcional difiere entre los paradigmas, para los propsitos de este trabajo
alcanza con agruparlos bajo LPG).
En general, decimos que dos propiedades se entrecruzan si al implementarse deben componerse
de manera diferente, y an deban ser coordinadas. Esto se debe a que tienen un comportamiento
en comn. Al proveer los LPG solamente un nico medio de composicin, es el programador quien
debe realizar la tarea extra deco-componer manualmente las propiedades que se entrecruzan, lo
cual lleva a un oscurecimiento y a un aumento de la complejidad del cdigo.

Al momento de implementar una propiedad, tenemos que la misma tomar una de las dos
siguientes formas:
1. Un componente: si puede encapsularse claramente dentro de un procedimiento generalizado.
Un elemento es claramente encapsulado si est bien localizado, es fcilmente accesible y resulta
sencillo componerlo.
2. Un aspecto: si no puede encapsularse claramente en un procedimiento generalizado. Los
aspectos tienden a ser propiedades que afectan la performance o la semntica de los
componentes en forma sistemtica (Ejemplo: sincronizacin, manejo de memoria, distribucin,
etc.)
A la luz de estos trminos, podemos enunciar la meta principal de la POA: brindar un contexto al
programador que permita separar claramente componentes y aspectos, separando componentes
entre s, aspectos entre s, y aspectos de componentes, a travs de mecanismos que hagan posible
abstraerlos y componerlos para producir el sistema completo. Tenemos entonces una importante
y clara diferencia respecto de los LPG, donde todos los esfuerzos se concentran nicamente en los
componentes, dejando de lado los aspectos.
Una vez diferenciados los aspectos de los componentes, estamos en condiciones de definir a un
aspecto como un concepto que no es posible encapsularlo claramente, y que resulta diseminado
por todo el cdigo. Los aspectos son la unidad bsica de la programacin orientada a aspectos.
Una definicin ms formal, y con la que se trabaja actualmente es: Un aspecto es una unidad
modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen
tanto en la etapa de diseo como en la de implementacin. Un aspecto de diseo es una unidad
modular del diseo que se entremezcla en la estructura de otras partes del diseo. Un aspecto de
implementacin es una unidad modular del programa que aparece en otras unidades modulares
del programa. Dicha definicin pertenece al creador de la POA, Gregor Kickzales.
Ahora que ya hemos introducido los principales rasgos de la POA, podemos comparar la forma de
una implementacin basada en los LPG versus implementacin basada en POA.

Implementacin POA versus LPG

Fundamentos de la POA
Los tres principales requerimientos de la POA son:
Un lenguaje para definir la funcionalidad bsica, conocido como lenguaje base o
componente. Podra ser un lenguaje imperativo, o un lenguaje no imperativo (C++, Java,
Lisp, ML).
Uno o varios lenguajes de aspectos, para especificar el comportamiento de los aspectos.
(COOL, para sincronizacin, RIDL, para distribucin, AspectJ, de propsito general.)
Un tejedor de aspectos (Weaver), que se encargar de combinar los lenguajes. Tal proceso
se puede retrasar para hacerse en tiempo de ejecucin o en tiempo de compilacin.
Los lenguajes orientados a aspectos definen una nueva unidad de programacin de software para
encapsular aquellos conceptos que cruzan todo el cdigo.
Estructura general
La estructura de una implementacin basada en aspectos es anloga a la estructura de una
implementacin basada en los LPG.
Una implementacin basada en LPG consiste en:
Un lenguaje.
Un compilador o intrprete para ese lenguaje.
Un programa escrito en ese lenguaje que implemente la aplicacin.
Veamos a continuacin una grfica de los LPG
Una implementacin basada en POA consiste en:

El lenguaje base o componente para programar la funcionalidad bsica.

Uno o ms lenguajes de aspectos para especificar los aspectos.
Un tejedor de aspectos para la combinacin de los lenguajes.
El programa escrito en el lenguaje componente que implementa los componentes.
Uno o ms programas de aspectos que implementan los aspectos.
Visualicemos, por medio de una grfica
Estructura de POA

Desarrollo orientado a aspectos

Disear un sistema basado en aspectos requiere entender qu se debe incluir en el lenguaje base,
qu se debe incluir dentro de los lenguajes de aspectos y qu debe compartirse entre ambos
lenguajes. El lenguaje componente debe proveer la forma de implementar la funcionalidad bsica
y asegurar que los programas escritos en ese lenguaje componente no interfieran con los
aspectos. Los lenguajes de aspectos tienen que proveer los medios para implementar los aspectos
deseados de una manera intuitiva, natural y concisa.
En general el desarrollo de una aplicacin basada en aspectos consiste de tres pasos:
1- Descomposicin de aspectos: es descomponer los requerimientos para distinguir aquellos que
son componentes de los que son aspectos.
2- Implementacin de requerimientos: implementar cada requerimiento por separado.
3- Recomposicin: dar las reglas de recomposicin que permitan combinar el sistema completo.
En un reporte tcnico de la Universidad de Virginia, se establece que muchos de los principios
centrales a la POO son ignorados dentro del diseo orientado a aspectos, como por ejemplo el
ocultamiento de informacin, debido a que los aspectos tienen la habilidad de violar estos
principios. Para esto se propone una filosofa de diseo orientada a aspectos que consiste de
cuatro pasos:
Un objeto es algo.
Un aspecto no es algo. Es algo sobre algo.
Los objetos no dependen de los aspectos.
Los aspectos representan alguna caracterstica o propiedad de los objetos, pero no tienen
control sobre los mismos.
Un objeto es algo: un objeto existe por s mismo, es una entidad.
Un aspecto no es algo. Es algo sobre algo: un aspecto se escribe para encapsular un concepto
entrecruzado. Por definicin un aspecto entrecruza diferentes componentes, los cuales en la POO
son llamados objetos. Si un aspecto no est asociado con ninguna clase, entonces entrecruza cero
clases, y por lo tanto no tiene sentido en este contexto. Luego, para que un aspecto tenga sentido
debe estar asociado a una o ms clases; no es una unidad funcional por s mismo.
Los objetos no dependen de los aspectos: Un aspecto no debe cambiar las interfaces de las clases
asociadas a l. Solo debe aumentar la implementacin de dichas interfaces. Al afectar solamente
la implementacin de las clases y no sus interfaces, la encapsulacin no se rompe. Las clases

mantienen su condicin original de cajas negras, aun cuando puede modificarse el interior de las
cajas.
Los aspectos no tienen control sobre los objetos: Esto significa que el ocultamiento de informacin
puede ser violado en cierta forma por los aspectos porque stos conocen detalles de un objeto
que estn ocultos al resto de los objetos.
Sin embargo, no deben manipular la representacin interna del objeto ms all de lo que sean
capaz de manipular el resto de los objetos. A los aspectos se les permite tener esta visin especial,
pero debera limitarse a manipular objetos de la misma forma que los dems objetos lo hacen, a
travs de la interface.
6.4. Lenguajes orientados a aspectos

A continuacin describiremos informalmente algunos lenguajes orientados a aspectos disponibles
actualmente. En la seccin 3.9 estudiaremos con mayor profundidad el lenguaje orientado a
aspectos AspectJ, ya que hemos seleccionado este lenguaje por ser la herramienta con mayor
usabilidad, futuro, popularidad y desarrollo.
JPAL
La principal caracterstica de esta herramienta es que los puntos de enlace son especificados
independientemente del lenguaje base. Estos puntos de enlace independientes reciben el nombre
de Junction Point (JP). Por lo tanto la herramienta se llama JPAL que significa Junction Point Aspect
Language, esto es, Lenguaje de Aspectos basados en JP. Usar programas escritos en JPAL para
describir nuevos lenguajes de aspectos facilita para ese lenguaje el desarrollo de tejedores. De
hecho, el tejedor JPAL genera un esquema del tejedor de aspectos llamado Esquema del Tejedor.
Este esquema tiene un mecanismo que automticamente conecta el cdigo base con los
programas de aspectos en puntos de control llamados acciones.
El cdigo que agrega el Esquema del Tejedor invoca, cuando es alcanzado en ejecucin, las
acciones correspondientes para permitir la ejecucin de los programas de aspectos. Esto permite
una vinculacin dinmica con los programas de aspectos, lo cual hace posible modificar en
tiempos de ejecucin los programas de aspectos. Sin embargo, esta solucin no es lo
suficientemente poderosa como para agregar o reemplazar programas de aspectos en ejecucin.
Para tal efecto se agrega al Esquema del Tejedor una entidad llamada Administrador de Programas
de Aspectos (APA), el cual puede registrar un nuevo aspecto de una aplicacin y puede llamar a
mtodos de aspectos registrados. Es implementado como una librera dinmica que almacena los

aspectos y permite dinmicamente agregar, quitar o modificar aspectos, y mandar mensajes a

dichos aspectos. La comunicacin entre el Administrador y el Esquema del Tejedor se logra a
travs de un Protocolo de Comunicacin entre Procesos que permite registrar aspectos
dinmicamente.
Arquitectura JPAL
Resumiendo, JPAL, un descendiente de AspectJ, tiene la particularidad de separar los puntos de
enlace, que son independientes del lenguaje base, de sus acciones asociadas que dependen de
decisiones de implementacin. Esta separacin permite generar un Esquema de Tejedor para
cualquier lenguaje de aspectos. Este esquema ofrece un puente entre el control de la ejecucin y
la ejecucin de la accin.
Tomando ventaja de esta redireccin se obtiene un modelo de arquitectura para el manejo
dinmico de aspectos.
Su principal aplicacin es para la implementacin de sistemas distribuidos.
D
D es un ambiente de lenguajes de aspectos para la programacin distribuida. Se llama ambiente
de lenguajes, en vez de solamente lenguaje, porque consiste en realidad de dos lenguajes: COOL,
para controlar la sincronizacin de hilos(threads), y RIDL, para programar la interaccin entre
componentes remotos.
Estos dos lenguajes se disearon de manera independiente de un lenguaje componente. Sin
embargo establecen un nmero de condiciones sobre el lenguaje componente.

El diseo de D es semi-independiente del lenguaje componente, ya que D impone requerimientos

sobre el lenguaje componente que satisfacen naturalmente los lenguajes orientados a objetos.
Luego el lenguaje componente puede ser cualquiera mientras sea orientado a objetos. Por lo
tanto, en teora podra ser implementado con C++, Smalltalk, CLOS, Java o Eiffel. Cristina Lopez,
principal diseadora del lenguaje, implement D sobre Java llamando al lenguaje resultante DJ.
Con respecto a la herencia, los mdulos de aspectos se relacionan con la herencia de clases a
travs de simples reglas: Sea C una clase y A el mdulo de aspecto asociado a C, se verifican las
siguientes propiedades:
Visibilidad de campos: Los elementos heredados desde ancestros de C son visibles a A.
No hay propagacin de efectos: A no afecta a ninguna superclase de C.
Redefinicin de semntica: A redefine completamente cualquier mdulo de aspecto del
mismo tipo definido en una superclase de C.
No hay ninguna relacin entre A y los mdulos de aspectos de las superclases de C.
- Herencia de coordinacin: A afecta todas las subclases de C que no tienen asociado un mdulo
de aspecto del mismo tipo. A no afecta los nuevos mtodos definidos en una subclase de C. Si un
mtodo mdeclarado en C es redefinido por una subclase de C sin asociarle otromdulo de aspecto
del mismo tipo entonces A tambin es el aspecto para ese mtodo.
No es posible para los mdulos de aspectos referir a otro mdulo de aspecto, como consecuencia
no es posible establecer ninguna relacin entre los mdulos de aspectos, incluyendo a la herencia.
COOL
COOL (COOrdination aspect Language) es un lenguaje de aspectos de dominio especfico para
tratar con la exclusin mutua de hilos, sincronizacin, suspensin y reactivacin de hilos.
Un programa COOL consiste de un conjunto de mdulos coordinadores. Los mdulos
coordinadores, o directamente coordinadores, se asocian con las clases a travs del nombre. Un
mismo coordinador puede coordinar a ms de una clase. La unidad mnima de sincronizacin es el
mtodo. La declaracin de un coordinador describe la estrategia de coordinacin. Los
coordinadores no son clases: utilizan un lenguaje diferente, no pueden ser instanciados y sirven
para un propsito muy especfico. Los coordinadores se asocian automticamente con las
instancias de clases que coordinan en tiempo de instanciacin, y durante el tiempo de vida de los
objetos esta relacin tiene un protocolo bien definido.

El cuerpo de un coordinador contiene declaracin de variables de condicin y ordinarias, un

conjunto de mtodos auto-exclusivos, varios conjuntos de mtodos mutuamente exclusivos y
manejadores de mtodos. Los mtodos nombrados en el cuerpo deben ser mtodos vlidos de las
clases coordinadas.
Un coordinador asociado a una clase C tiene la siguiente visibilidad:
Todos los mtodos pblicos, protegidos y privados de C.
Todos los mtodos no privados de las superclases de C.
Todas las variables privadas, protegidas y pblicas de C.
Todas las variables no privadas de las superclases de C.
La siguiente figura describe el protocolo de comunicacin entre un coordinador y un objeto:
Protocolo de comunicacin de un coordinador en COOL

RIDL
RIDL (Remote Interaction and Data transfers aspect Language) es un lenguaje de aspectos de
dominio especfico que maneja la transferencia de datos entre diferentes espacios de ejecucin.

Un programa RIDL consiste de un conjunto de mdulos de portales. Los mdulos de portales o

directamente portales se asocian con las clases por el nombre.
Un portal es el encargado de manejar la interaccin remota y la transferencia de datos de la clase
asociada a l, y puede asociarse como mximo a una clase. La unidad mnima de interaccin
remota es el mtodo.
Protocolo de comunicacin de un portal en RIDL

Tenemos otros lenguajes POA
ASPECTC
ASPECTS
ASPECTC++
MALAJ
HYPERJ
A continuacin veamos un resumen de estas herramientas


De acuerdo a todos los temas vistos y analizados en esta unidad, se pide realizar el siguiente trabajo
que abarca los siguientes numerales de manera ptima y clara:
1. Interaccin entre aspectos en aplicaciones AOP (EA, IMP)
2. Qu es un aspecto a nivel arquitectnico? (EA, ARQ)
3. Los aspectos identificados en la especificacin de requisitos son luego aspectos a nivel
arquitectnico?
4. Significado de las relaciones de weaving en el modelo de objetivos. Qu tcnicas pueden ser
utilizadas para especificar el weaving en early aspects.
5. Identificacin de aspectos en la especificacin de requisitos/objetivos.
6. Conceptos reales de DSOA Estn demasiado influenciados por AspectJ?
7. Derivacin de arquitecturas (AO?) de una especificacin orientada a aspectos.
8. Qu es un aspecto a nivel arquitectnico? (EA, ARQ)
9. Los aspectos identificados en la especificacin de requisitos son luego aspectos a nivel
arquitectnico?
10. Varias opciones de diseo vivas a lo largo del ciclo de vida. Ventajas?
11 Aspectos asociados a conectores Vs aspectos asociados a componentes
12. Son diferentes los aspectos arquitectnicos?
13. Derivacin de arquitecturas (AO?) de una especificacin orientada a aspectos.
14. Hasta qu nivel MDA se mantiene la separacin?

7. PISTAS DE APRENDIZAJE
Tenga presente: Dentro de un procesos unificado de desarrollo, deben tenerse muy pendientes y
bien estructuradas las diferentes fases y etapas propuestas por el modelo UML.
Tener en cuenta: Al disear y desarrollar software para la web, los Principios planteados para ello
en ste mdulo, son determinantes de su eficiencia, eficacia y funcionalidad
Traer a la memoria: Que las reglas del negocio estn determinadas por las necesidades y
parmetros sobre los cuales debe levantarse el diseo del software a desarrollar.
Tenga presente: Los diferentes diagramas mostrados son solo guas de solucin a posibles
necesidades presentadas en la cotidianidad del desarrollo de software.
Tener en cuenta: Los patrones son modelos a seguir que han sido probados y aprobados en
escenario especficos, pero no constituyen como tal una solucin estandarizada a una situacin de
desarrollo.
Traer a la memoria: Que los diferentes procesos y patrones de modelamiento sern efectivos en
la medida que se usen en los escenarios ms adecuados para ello.
Tenga presente: UML es un lenguaje para interpretar sistemas mediante grficos o texto
obteniendo modelos explcitos para a la comunicacin durante el desarrollo al ser estndar, los
modelos podrn ser interpretados por personas que no participaron en su diseo
Tener en cuenta: Que una restriccin se representa como una cadena encerrada entre llaves y
colocada junto al elemento asociado o conectada a los elementos con relacin de dependencia.
Tenga presente: Que los valores etiquetados se representa como una cadena encerrada entre
llaves y colocada bajo el nombre de otro elemento.
Traer a la memoria: usar las notas para suministrar restricciones o comentarios vinculados a un
elemento o a una coleccin de elementos.

8. GLOSARIO
FRAMEWORK: Estructura software compuesta de componentes personalizables e intercambiables
UML: Lenguaje de Modelamiento Unificado (Unified Model Language)

MOF: Estndar de OMG que provee un marco de trabajo de gestin de metadatos
JPAL: Junction Point Aspect Language
D: ambiente de lenguajes de aspectos para la programacin distribuida
COOL: Coordination aspect Language, Coordinacin de Aspectos del lenguaje
RIDL: Remote Interaction and Data transfers aspect Language: Interaccin Remota y Transferencia
de Datos en lenguajes orientados a aspectos.
LOA: Lenguaje de programacin Orientado a Aspectos
POA: Programacin Orientada a Aspectos
MALAJ: Modularizacin de aspectos de sincronizacin y relacin

9. BIBLIOGRAFA
SNCHEZ PREZ Javier, Metodologas de Desarrollo Software Facultad de Informtica, 1998,
GARCA MOLINA Jess Ignacio, Departamento de Informtica y Sistemas, 2004, Univ. De Murcia.
REYNOSO Billy, Arquitectura para distribucin y agregacin: Services Oriented Architecture (SOA)
2006, U. Buenos Aires
CARMONA VANEGAS Juan de Dios, Web Services en paralelo con SOA , implementaciones, 2010
CESDE,
CARMONA VANEGAS Juan de Dios, Diagramas de casos de uso de los ejercicios que realizados
para proyectos de produccin, 2011, CESDE.
WEBGRAFA
www.monografas.com, Arquitectura de Desarrollo de Software, tomado el 4 de Noviembre 2011
www.wikipedia.com
www.Lawebdelprogramador.com

Arquitectura de Software

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Arquitectura de Software

Transféré par

Droits d'auteur :

Formats disponibles

FACULTAD DE CIENCIAS BSICAS E

Asignatura: Arquitectura del Software

Direccin de Educacin a Distancia y Virtual

El mdulo de estudio de la asignatura Arquitectura del Software es propiedad de la Corporacin Universitaria

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

6.4. Lenguajes orientados a aspectos .......................................................................................... 127

Direccin de Educacin a Distancia y Virtual

OBJETIVO GENERAL DEL MODULO

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

2.1. Relacin de conceptos

2.2. Prueba Inicial

Qu entiende usted por Modelado UML?

Direccin de Educacin a Distancia y Virtual

2.3. Tcnicas comunes y Avanzadas de modelado con UML.

Direccin de Educacin a Distancia y Virtual

Ilustracin sobre Estereotipos, Valores etiquetados y Restricciones.

Direccin de Educacin a Distancia y Virtual

Tcnicas avanzadas de modelado con UML

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

Diagramas, que son agrupaciones de elementos.

Direccin de Educacin a Distancia y Virtual

Describe un conjunto de objetos que comparten los

Agrupacin de mtodos u operaciones que especifican

Direccin de Educacin a Distancia y Virtual

Define una interaccin entre elementos que cooperan

Describe un conjunto de secuencias de acciones que un

Se trata de una clase, en la que existen procesos o hilos

Componentes: Un componente es una parte fsica y reemplazable de un sistema que conforma

Direccin de Educacin a Distancia y Virtual

componente representa tpicamente el empaquetamiento fsico de diferentes elementos lgicos,

Parte fsica y por tanto reemplazable de un modelo,

Elemento fsico que existe en tiempo de ejecucin y

Muestra un conjunto de casos de uso, los

Direccin de Educacin a Distancia y Virtual

Son diagramas de interaccin, muestran un conjunto de

Muestra una mquina de estados, con sus estados,

Direccin de Educacin a Distancia y Virtual

Tipo especial de diagrama de estados que

Diagramas de Componentes: Muestra la organizacin y las dependencias entre un conjunto de

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

Reglas del Negocio

Direccin de Educacin a Distancia y Virtual

2.5. Principios de desarrollo de aplicaciones Web

Direccin de Educacin a Distancia y Virtual

El proyecto debe ser orientado al usuario, no al desarrollador.

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

2.6. La Arquitectura en el Proceso Unificado de Desarrollo

El proceso unificado de desarrollo de software Es un proceso orientado a objetos, es un proceso

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

Veamos a continuacin un ejemplo de un modelo de casos de uso:

Direccin de Educacin a Distancia y Virtual

Direccin de Educacin a Distancia y Virtual

b) Ciclo de vida iterativo e incremental

Direccin de Educacin a Distancia y Virtual

Fases dentro del ciclo de vida del proceso unificado