07 arquitectura de software
DESCRIPTION
ModuloTRANSCRIPT
CORPORACIÓN UNIVERSITARIA REMINGTON
DIRECCIÓN PEDAGÓGICA
Dirección de Educación a Distancia y Virtual
Este material es propiedad de la Corporación Universitaria Remington (CUR),
para los estudiantes de la CUR en todo el país.
2012
FACULTAD DE CIENCIAS BÁSICAS E INGENIERIA
Ingeniería de Sistemas Asignatura: Arquitectura del Software
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
CRÉDITOS
El módulo de estudio de la asignatura Arquitectura del Software es propiedad de la Corporación Universitaria Remington. Las imágenes fueron tomadas de diferentes fuentes que se relacionan en los derechos de autor y las citas en la bibliografía. El contenido del módulo está protegido por las leyes de derechos de autor que rigen al país. Este material tiene fines educativos y no puede usarse con propósitos económicos o comerciales.
AUTOR
Edilberto Restrepo Restrepo
Magister en Educación Superior de la Pontificia Universidad Javeriana, Especialista en Gerencia de Proyectos de la Universidad del Tolima, Administrador de Empresas y Tecnólogo en Administración de Redes de Datos. Con 18 Años de experiencia como docente y Diseñador de asignaturas en las áreas de Lógica y Programación, Mantenimiento de computadores, Administración de Redes de Datos, asesoría de proyectos informáticos 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 formación en la corporación Universitaria Remington. Con ponencias sobre procesos evaluativos, Cesde 2005, Aprendizajes colaborativos, Remington, 2011. Actualmente miembro del grupo de investigación AVICUR. [email protected]
Nota: el autor certificó (de manera verbal o escrita) No haber incurrido en fraude científico, plagio o vicios de autoría; en caso contrario eximió de toda responsabilidad a la Corporación Universitaria Remington, y se declaró como el único responsable.
RESPONSABLES
Dr.Jorge Mauricio Sepúlveda Castaño
Director de la Facultad de Ciencias Básicas e Ingeniería
Tomás Vásquez Uribe Director Educación a Distancia y Virtual tvasquez @remington.edu.co Angélica Ricaurte Avendaño Coordinadora de Remington Virtual (CUR-Virtual) [email protected]
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
GRUPO DE APOYO
Personal de la Unidad de Remington Virtual (CUR-Virtual) EDICIÓN Y MONTAJE Primera versión. Febrero de 2011.Segunda versión Marzo 2012
Derechos Reservados
Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
TABLA DE CONTENIDO
1. MAPA DE LA ASIGNATURA ................................................................................................. 9
2. EL MODELAMIENTO UNIFICADO ....................................................................................... 10
2.1. Relación de conceptos ............................................................................................................ 11
2.2. Prueba Inicial ........................................................................................................................... 11
2.3. Técnicas 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. Relación de conceptos ............................................................................................................ 37
3.2. Prueba Inicial ........................................................................................................................... 38
3.3. Modelos de arquitectura de software. ................................................................................... 38
3.4. Enfoques arquitectónicos de software ................................................................................... 47
3.5. Modelado Arquitectónico en UML 2.0 .................................................................................... 51
4. DEFINICIONES Y PATRONES DE SOFTWARE. ...................................................................... 63
4.1. Prueba Inicial ........................................................................................................................... 64
4.2. Definiciones Básicas ................................................................................................................ 64
4.3. Catálogos de Patrones ........................................................................................................... 68
5. FRAMEWORKS Y EL MÓDELO MDA (MODEL DRIVEN ARCHITECTURE) ............................. 101
5.1. Relación de conceptos .......................................................................................................... 101
5.2. Prueba Inicial ......................................................................................................................... 102
5.3. Definición y Estructura del Frameworks .............................................................................. 102
5.4. MDA (Model Driven Architecture) ........................................................................................ 106
6. ASPECTOS ...................................................................................................................... 121
6.1. Relación de conceptos .......................................................................................................... 121
6.2. Prueba Inicial ......................................................................................................................... 121
6.3. Definiciones Básicas .............................................................................................................. 122
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
6.4. Lenguajes orientados a aspectos .......................................................................................... 127
7. PISTAS DE APRENDIZAJE ................................................................................................. 134
8. GLOSARIO ...................................................................................................................... 135
9. BIBLIOGRAFÍA ................................................................................................................ 136
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
1. MAPA DE LA ASIGNATURA
ARQUITECTURA DEL SOFTWARE
OBJETIVO GENERAL DEL MODULO
En un mundo globalizado, donde cada día 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
programación de sistemas no había 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 sistemáticas que se necesitan para lograr software con calidad, la
Calidad involucra actividades de evaluaciones, auditorias y revisiones, estándares que se aplicarían al
proyecto, mecanismos de medida (métricas), métodos y herramientas de análisis, diseño, programación y
prueba, documentación y control.
OBJETIVO GENERAL
Apropiar en el estudiante conceptos y prácticas de Arquitectura y Diseño de Software aplicables a
escenarios de la vida real.
OBJETIVOS ESPECÍFICOS
Dar a conocer las generalidades y conceptos básicos de UML y el desarrollo de aplicaciones para la
infraestructura de un proyecto web.
Presentar de manera práctica las diferentes metodologías y buenas prácticas para documentación y
evaluación de arquitecturas de software
Apropiar el uso de catálogos de elementos reusables en el diseño de sistemas software
Identificar las características 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
conceptualización
y aplicación en
situaciones
problema, el
estudiante podrá
apropiarse de los
procesos de
modelamientos
UML.
UNIDAD 2
El estudiante
podrá plantear
propuestas
metodológicas
para la
documentación
de las prácticas
productivas de
desarrollo de
software.
UNIDAD 3
Mediante el
abordaje y
aplicación de los
diferentes
patrones de
elementos
reusables el
estudiante
obtendrá criterios
de aplicación en
contextos
diversos
UNIDAD 4
Identificando las
características de
los frameworks, y
modelado MDA, el
estudiante
planteará solución
a necesidades
reales de
desarrollo de
software
UNIDAD 5
Conociendo los
conceptos sobre la
programación
orientada a aspectos, el
estudiante podrá
determinar las
situaciones en las
cuales sea más
pertinente su
aplicación en el
desarrollo de software
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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.
OBJETIVOS ESPECÍFICOS
Evidenciar las técnicas comunes y avanzadas del Modelamiento UML mostrando
gráficamente la arquitectura de un proyecto web.
Determinar de forma adecuada las políticas 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.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
2.1. Relación 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 asimilación
a) ¿Qué entiende usted por Modelado UML?
b) ¿Qué técnicas de modelamiento puedes describir?
c) ¿Cómo se dividen los bloques de construcción?
d) ¿Qué entiende usted por clase, Interfaz, Colaboración, Casos de uso, Clase Activa?
e) ¿Qué Conoce de los diagramas que se involucran en el modelamiento UML?
f) ¿Qué aspectos se identifican mediante las reglas del negocio?
g) ¿Sobre qué principios se fundamenta el desarrollo de aplicaciones web?
h) ¿Mediante qué elementos se estructura el proceso unificado de desarrollo?
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
2.3. Técnicas comunes y Avanzadas de modelado con UML.
Notas
Una nota es un símbolo gráfico utilizado para suministrar restricciones o comentarios vinculados a
un elemento o a una colección de elementos. Gráficamente, una nota se representa como un
rectángulo con la esquina superior derecha doblada, junto con un comentario textual o gráfico.
El UML proporciona todas las herramientas necesarias para visualizar, especificar, construir y
documentar los artefactos de un rango amplio de sistemas completos de software. También
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 información.
En UML utilizamos notas para dar a entender una idea clara sobre algo y por medio de ellas
explicamos ideas que de forma gráfica se hace difícil. Las notas pueden representar artefactos,
para hacer más atractivo del ciclo de vida en el desarrollo de software, también 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 representación gráfica 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 amplía el vocabulario UML, permitiendo crear nuevos tipos de
bloques de construcción similares a los existentes pero específicos para tu problema.
Gráficamente, un estereotipo se representa con un nombre encerrado entre pico paréntesis y
colocado arriba del nombre de otro elemento. Como una opción, 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 añadir nuevos bloques de construcción, crear nuevas propiedades y
especificar semánticas nuevas respectivamente. Por ejemplo, si estás modelando una red, puedes
necesitar símbolos para los enrutadores y los concentradores; puedes usar nodos estereotipados
para hacer que estos elementos aparezcan como bloques primitivos de construcción.
Similarmente, si eres parte del equipo responsable del ensamble, de la prueba y de la liberación,
puedes conservar registros con respecto al número de versión y resultados de la prueba para cada
subsistema. Puedes usar valores etiquetados para añadir información a tus modelos. Finalmente,
si estás modelando con dificultad sistemas en tiempo real, puedes adornar tus modelos con
información de tiempo presupuestal y líneas muertas; puedes usar restricciones para capturar
estos requerimientos de tiempo.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Ilustración sobre Estereotipos, Valores etiquetados y Restricciones.
Valor etiquetado:Un valor etiquetado amplía las propiedades de un elemento UML, permitiendo
crear nueva información en lo que respecta a la especificación del elemento. Gráficamente, un
valor etiquetado se representa como una cadena encerrada entre llaves y colocada bajo el nombre
de otro elemento.
Restricción: Una restricción amplía la semántica de un elemento UML, permitiendo añadir nuevas
reglas, o modificar las existentes. Gráficamente, una restricción se representa como una cadena
encerrada entre llaves y colocada junto al elemento asociado o, conectada a el(los) elemento(s)
con relación de dependencia. Como una alternativa, puedes incluir una restricción en una nota.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Técnicas avanzadas de modelado con UML
Primero comencemos haciendo una diferencia entre Metodología y Modelo, Una metodología es
aquella guía que se sigue a fin de realizar las acciones propias de una investigación. En términos
más sencillos se trata de la guía que nos va indicando qué hacer y cómo actuar cuando se quiere
obtener algún tipo de investigación. Es posible definir una metodología como aquel enfoque que
permite observar un problema de una forma total, sistemática, disciplinada y con cierta disciplina.
Al intentar comprender la definición que se hace de lo que es una metodología, resulta de suma
importancia tener en cuenta que una metodología no es lo mismo que la técnica de investigación.
Las técnicas son parte de una metodología, y se define como aquellos procedimientos que se
utilizan para llevar a cabo la metodología, por lo tanto, como es posible intuir, es uno de los
muchos elementos que incluye.
En el contexto de la investigación son muchas las metodologías que es posible seguir, sin embargo,
existen 2 grandes grupos que incluyen a otras más específicas. Se trata de la metodología de
investigación cuantitativa y la cualitativa.
La metodología cuantitativa es aquella que permite la obtención de información a partir de la
cuantificación de los datos sobre variables, mientras que la metodología cualitativa, evitando la
cuantificación de los datos, produce registros narrativos de los fenómenos investigados. En este
tipo de metodología los datos se obtienen por medio de la observación y las entrevistas, entre
otros. Como vemos, la diferencia más importante entre la metodología cuantitativa y la
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
cualitativa radica en que la primera logra sus conclusiones a través de la correlación entre
variables cuantificadas, y así poder realizar generalizaciones y producir datos objetivos, mientras
que la segunda estudia la relación entre las variables obtenidas a partir de la observación 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 podrían ser sistematizadas. De
esta manera, su estructura es diferente de la que se supone existe en el conjunto de fenómenos
de la naturaleza. Para el caso de arquitectura de software usamos el Modelo de UML.
A continuación veamos la Historia del UML
La notación UML se deriva y unifica las tres metodologías de análisis y diseño Orientada a Objeto
más extendidas:
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling
Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante
la metodología 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 métodos. A finales de 1995, Ivar Jacobson y su
compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
De las tres metodologías 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 relación y colaboración. Por otro lado, la metodología de Jacobson es
más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha
ido fomentando y aceptando como estándar desde el OMG que es también el origen de CORBA, el
estándar líder en la industria para la programación de objetos distribuidos. En 1997 UML 1.1 fue
aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño
orientado a objetos.
Qué es UML?
UML es el primer método en publicar una meta-modelo en su propia notación, incluyendo la
notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de una
meta-modelo auto-referencial, cualquier lenguaje de modelado de propósito general debería ser
capaz de modelarse a sí mismo.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
UML es un lenguaje estándar 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 información hasta
aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real.
UML es solamente un lenguaje por lo que es sólo una parte de un método 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, además es un
lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la
representación conceptual y física del sistema.
UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante gráficos o mediante
texto obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo ya que al
ser estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño
(e incluso por herramientas) sin ninguna ambigüedad. En este contexto, UML sirve para
especificar, modelos concretos, no ambiguos y completos.
Debido a su estandarización y su definición completa no ambigua, y aunque no sea un lenguaje de
programación, UML se puede conectar de manera directa a lenguajes de programación como Java,
C++ o Visual Basic, esta correspondencia permite lo que se denomina como ingeniería directa
(obtener el código fuente partiendo de los modelos) pero además es posible reconstruir un
modelo en UML partiendo de la implementación, o sea, la ingeniería inversa.
UML proporciona la capacidad de modelar actividades de planificación 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 documentación que es
válida durante todo el ciclo de vida de un proyecto.
El lenguaje UML se compone de tres elementos básicos, los bloques de construcción, las reglas y
algunos mecanismos comunes. Estos elementos interaccionan entre sí para dar a UML el carácter
de completitud y no-ambigüedad que antes comentábamos.
Los bloques de construcción se dividen en tres partes:
Elementos, que son las abstracciones de primer nivel.
Relaciones, que unen a los elementos entre sí.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 agrupación
Elementos de anotación.
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 asociación, relaciones de generalización y relaciones de realización.
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
razón UML soporta un gran número de diagramas diferentes aunque, en la práctica, sólo se
utilicen un pequeño número 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 semánticas 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 ejecución, o sea la vista dinámica 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 adaptación no se pierda la semántica propia de UML. Dentro
de estos mecanismos están las especificaciones, que proporcionan la explicación textual de la
sintaxis y semántica de los bloques de construcción.
Otro mecanismo es el de los adornos que sirven para conferir a los modelos de más semántica, los
adornos son elementos secundarios ya que proporcionan más 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 comprensión desde distintos
puntos de vista, en primer lugar tenemos la división entre clase y objeto (clase es una abstracción
y objeto es una manifestación de esa abstracción), en segundo lugar tenemos la división interfaz /
implementación donde la interfaz presenta un contrato (algo que se va a cumplir de una
determinada manera) mientras que la implementación es la manera en que se cumple dicho
contrato.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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
razón UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques de
construcción, los valores etiquetados, para extender las propiedades un bloque, y las restricciones,
para extender la semántica. De esta manera UML es un lenguaje estándar “abierto-cerrado”
siendo posible extender el lenguaje de manera controlada.
Elementos Estructurales
Los elementos estructurales en UML, es su mayoría, son las partes estáticas del modelo y
representan cosas que son conceptuales o materiales.
Clases
Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente se
representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones.
Clase
Describe un conjunto de objetos que comparten los
mismos atributos, métodos, relaciones y semántica. Las
clases implementan una o más interfaces.
Interfaz: Una interfaz es una colección 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 sólo una parte del mismo. Una
interfaz describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca
su implementación. Se representa con un círculo, y rara vez se encuentra aislada sino que más
bien conectada a la clase o componente que realiza.
Interfaz
Agrupación de métodos u operaciones que especifican
un servicio de una clase o componente, describiendo su
comportamiento, completo o parcial, externamente
visible. UML permite emplear un círculo para
representar las interfaces, aunque lo más normal es
emplear la clase con el nombre en cursiva.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Colaboración: Define una interacción 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 dimensión tanto estructural como de
comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las
colaboraciones representan la implementación de patrones que forman un sistema. Se representa
mediante una elipse con borde discontinuo.
Colaboración
Define una interacción 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 descripción de un conjunto de acciones que un sistema ejecuta
y que produce un determinado resultado que es de interés 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 colaboración.
Caso de uso
Describe un conjunto de secuencias de acciones que un
sistema ejecuta, para producir un resultado observable
de interés. Se emplea para estructurar los aspectos de
comportamiento de un modelo.
Clase Activa: Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución 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 líneas más gruesas
Clase activa
Se trata de una clase, en la que existen procesos o hilos
de ejecución concurrentes con otros elementos. Las
líneas del contorno son más gruesas que en la clase
“normal”
Componentes: Un componente es una parte física y reemplazable de un sistema que conforma
con un conjunto de interfaces y proporciona la implementación de dicho conjunto. Un
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos,
como clases, interfaces y colaboraciones.
Componente
Parte física y por tanto reemplazable de un modelo,
que agrupa un conjunto de interfaces, archivos de
código fuente, clases, colaboraciones y proporciona
la implementación de dichos elementos.
Nodos: Un nodo es un elemento físico que existe en tiempo de ejecución 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.
Diagramas de Casos de Usos: Muestran un conjunto de casos de uso y actores (tipo especial de
clases) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente
importantes para el modelado y organización 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
organización del sistema.
Diagramas de Secuencia y de Colaboración: Tanto los diagramas de secuencia como los diagramas
de colaboración son un tipo de diagramas de interacción. Constan de un conjunto de objetos y sus
relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista
dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los
Nodo
Elemento físico que existe en tiempo de ejecución y
representa un recurso computacional con capacidad de
procesar.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
mensajes mientras que los diagramas de colaboración muestran la organización estructural de los
objetos que envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en
diagramas de colaboración sin pérdida de información, lo mismo ocurren en sentido opuesto.
Secuencia
Son diagramas de interacción, muestran un conjunto de
objetos y sus relaciones, así como los mensajes que se
intercambian entre ellos. Cubren la vista dinámica del
sistema. El diagrama de secuencia resalta la ordenación
temporal de los mensajes, mientras que el de
colaboración resalta la organización estructural de los
objetos, ambos siendo equivalentes o isomorfos. En el
diagrama de colaboración de la figura de la izquierda, se
puede ver que los elementos gráficos no son cajas
rectangulares, como cabría esperar, y en su lugar
encontramos sus versiones adornadas. Estas versiones
tienen como finalidad evidenciar un rol específico 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).
Colaboración
Diagramas de Estados: Muestran una máquina de estados compuesta por estados, transiciones,
eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy
importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración.
Estados
Muestra una máquina de estados, con sus estados,
transiciones, eventos y actividades. Cubren la vista
dinámica 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
dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el
flujo de control entre objetos.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Actividades
Tipo especial de diagrama de estados que
muestra el flujo de actividades dentro de
un sistema.
Diagramas de Componentes: Muestra la organización y las dependencias entre un conjunto de
componentes. Cubren la vista de la implementación estática y se relacionan con los diagramas de
clases ya que en un componente suele tener una o más clases, interfaces o colaboraciones
Diagramas de Despliegue: Representan la configuración de los nodos de procesamiento en tiempo
de ejecución y los componentes que residen en ellos. Muestran la vista de despliegue estática de
una arquitectura y se relacionan con los componentes ya que, por lo común, los nodos contienen
uno o más componentes.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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.
También debemos mirar que solicitudes le hacen al sistema para que podamos dar comienzo a
la representación 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 continuación miremos los casos de uso resultantes de acuerdo a la descripción del problema y
los requerimientos que nos hace el usuario dueño del sistema:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
2.4. Reglas del Negocio
Esta capa es la encargada de procesar y validar las reglas del negocio, actúa como un servidor para
la capa de presentación y traslada las solicitudes de esta a la capa de datos actuando como cliente
de la misma. Así mismo también 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 aísla al usuario
de la interacción directa con la base de datos.
Una tarea de negocios es una operación definida por los requerimientos de la aplicación, como
introducir una orden de compra o imprimir una lista de clientes. Las reglas de negocio (business
rules) son políticas que controlan el flujo de las tareas.
Como las reglas de negocio tienden a cambiar más frecuentemente que las tareas específicas de
negocios a las que dan soporte, son candidatos ideales para encapsularlas en componentes que
están lógicamente separados de la lógica de la aplicación en sí.
Para ayudar a los desarrolladores a construir la lógica de negocio basado en componentes
Windows DNA incluye un conjunto muy poderoso de servicios que se encargan de la comunicación
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
en una aplicación de tres capas. Estos servicios están altamente integrados unos con otros, bajo un
sistema operativo, y expuestos de forma única a través de COM.
El nivel de servicios de negocios es responsable de:
Recibir la entrada del nivel de presentación
Interactuar con los servicios de datos para ejecutar las operaciones de negocios para los
que la aplicación fue diseñada a automatizar (por ejemplo, la preparación de impuestos
por ingresos, el procesamiento de órdenes y así sucesivamente).
Enviar el resultado procesado al nivel de presentación. Algunos de los servicios DNA para
la capa de negocios son los siguientes:
Servicios Web a través de Microsoft Internet Information Server (IIS)
Transacciones y Servicios de Componentes, Microsoft Transaction Server (MTS)
Servicios Asíncronos, 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 través de mi experiencia práctica, he aprendido algunas ideas
desde dónde 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 diseño gráfico como
en usabilidad y contenidos.
El proyecto debe ser estético y atractivo visualmente.
El proyecto debe transmitir emociones, según su naturaleza.
El proyecto debe tener herramientas y contenido más 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 comunicación.
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.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
El proyecto debe ser orientado al usuario, no al desarrollador.
Es demasiado fácil caer en la trampa de empezar a desarrollar un proyecto teniendo como
prioridad tus propios criterios, o los del desarrollador. Con el tiempo te darás cuenta de que
mientras más apegado se esté a los criterios del desarrollador, más complejo le será acceder al
usuario a la información, proyecto, servicio, etc.
Son innumerables los casos de esto, los más típicos son los portales de la Administración pública,
universidades, etc., que hacen que el usuario comience tirándose de los pelos, impaciente, hasta
que al final o bien se da por vencido, o bien termina siendo un experto en informática solo por
usar una página web. Por el contrario, Organizaciones o portales web que manejan una enorme
cantidad de información 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 fácil. ¿Cómo saber si tu página o proyecto web está orientado al usuario? Muy fácil:
pregúntaselo 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.
También innumerables son los casos que puedo poner como ejemplos: contenidos que te ofrecen
hacerte millonario/a de la noche a la mañana, te prometen la luna, las estrellas, vida eterna, etc,.
Asimismo, una amonestación a quienes usan la estrategia del correo electrónico no solicitado
(llámese 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 prácticas para atraer lectores o usuarios. Así vendas lotería,
coches, dietas, o información que puede dar beneficios al lector, tu producto, información o
servicio puede ser difundido desarrollando un proyecto éticamente, sin forzar, sin mentir.
Ofreciendo al usuario las ventajas y desventajas de tu información, haciendo comparaciones
honestas y, sobre todo, permitiéndole tomar una decisión.
El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseño gráfico 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 gráfico. Echa un vistazo a Google.com y verás lo simple que es esa
página, que hoy por hoy es la más visitada de todo el mundo. En definitiva, debes ofrecer a tus
lectores/usuarios la información que necesitan sin hacerlos dar vueltas por todos lados para
hallarla, o se irán sin pensarlo dos veces. Existen varias maneras de lograr hacer un proyecto muy
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
accesible, como por ejemplo mapas, buscadores internos, formas de redactar simples y al grano,
etc. Simplicidad es la palabra clave.
El proyecto debe ser estético y atractivo visualmente.
Antes he dicho que la usabilidad, orientada al usuario, es uno de los aspectos más importantes al
momento de desarrollar un proyecto para Internet. Pues bien, podría decir que la estética también
juega un papel importante, dicha estética, que personalmente prefiero minimalista, creo es la
clave en la credibilidad de lo que escribimos, también logra que nuestros usuarios/as se sientan
cómodos utilizando lo que ponemos a su disposición. Concretamente hablando de desarrollo de
sitios web, por ejemplo, he visto cómo contenidos interesantes -algunos publicados por
catedráticos o expertos en alguna materia- quedan sepultados bajo un diseño muy pobre, que ni
siquiera había razón para ser tan deficiente respecto a estética. También por el contrario, he visto
unos superdiseños gráficos, tantos, que sepultan el verdadero contenido. Por tanto te recomiendo
atención a la estética, simplicidad y equilibrio en este aspecto.
El proyecto debe transmitir emociones, según su naturaleza.
No podemos evitarlo, somos humanos que tenemos emociones y, sea mediante la palabra al
redactar o mediante la ayuda de gráficos, transmitir un mensaje que contenga alguna emoción,
acorde a la naturaleza del mensaje, será muy efectivo, por muchísimo. La industria de la publicidad
es experta en ello, pero también 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 diseñar mis propias páginas,
Internet ya llevaba varios años de andaduría, y en esa época las páginas se hacían una por una,
eran estáticas y sus contenidos lentamente actualizados. Hoy, hasta se puede ver televisión,
vídeos, escuchar radio, música y mil cosas más. 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, ¿dónde quedarán
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 comunicación.
La comunicación, para que sea completa, debe ser un ciclo entre la fuente, el mensaje y el
receptor que interactúan simultáneamente. ¿Cómo te sentirías hablando con alguien que no te
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
contesta, ni siquiera con un gesto? En Internet es prácticamente 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 electrónicos, foros, etc, etc. Así
también tú podrás ir adquiriendo nuevas ideas que te podrían 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 más para alcanzar algún 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 más. Mantén la visión equilibrada y no descuides otras
herramientas o medios que también podrían 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.
Iniciación.
Elaboración.
Construcción.
Transición.
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
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 algún
USUARIO un RESULTADO o VALOR.
Todos juntos constituyen el modelo de casos de uso
Funcionabilidad completa
Para todos los usuarios
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Veamos a continuación 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 diseñan, se implementan y se
prueban
En siguiente figura podemos apreciar un ejemplo de un desarrollo por casos de uso:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 módulo.
Que da una idea de la forma que tiene el sistema completo
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
b) Ciclo de vida iterativo e incremental
En el iterativo se repiten varios miniproyectos en el Incremental cada miniproyecto amplía 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 versión nueva del producto
Un ciclo de vida se divide en fases
Cada fase se divide en iteraciones
En cada iteración se realizan flujos de trabajo
Miremos gráficamente estos componentes
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Fases dentro del ciclo de vida del proceso unificado
Iniciación:
Describir producto final / análisis del negocio
Identificar riesgos más importantes
Establecer planificación inicial del proyecto
Decidir si se continúa
Elaboración:
Establecer Plan Y Arquitectura Estable
Construcción: desarrollar el producto
Transición: 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, Análisis de requerimientos, Análisis y
diseño, Implementación, 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
Análisis que implica: Especificar requisitos y construir modelo del análisis
Diseño para encontrar la forma del sistema (solución) y construir modelo del diseño
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Implementación donde se debe codificar el diseño (solución) y construir modelo de
implementación
Pruebas para verificar la implementación y construir modelo de pruebas
Fase de Iniciación:
Establecer la planificación del proyecto
• ¿Qué va a hacer el sistema para cada uno de sus usuarios principales?
– Un MCU simplificado con los CU más críticos
• ¿Cómo sería la arquitectura para un sistema como ese?
– Borrador con los subsistemas principales
• ¿Cuál es el plan y cuánto va a costar desarrollar el producto?
– Identificar los riesgos principales y priorizarlos, planificar elaboración y
presupuesto aproximado
Fase de Elaboración:
Establecer un plan para el proyecto y una arquitectura correcta
Especificar en detalle los CU + críticos
Diseñar la arquitectura
Mediante vistas de todos los modelos del SI
Vista arquitectónica de MCU, M. Análisis, M. Diseño, M. Implementación (con los
componentes que demuestran que la arquitectura es ejecutable) y M. Distribución.
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 Construcción:
Desarrollar el sistema, Se construye el producto. En esta fase:
La arquitectura se completa para construir un sistema bien cimentado La visión evoluciona hasta convertirse en un producto preparado para los usuarios Es donde se gastan la mayoría de los recursos La arquitectura del sistema es estable. Sin embargo, se pueden realizar cambios mínimos a
la misma. ¿El producto se ajusta suficientemente a las necesidades de algunos usuarios como para
enviárselo ya? Fase de transición:
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.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Los desarrolladores corrigen las deficiencias e incorporan algunas de las mejoras
propuestas en una versión para un grupo de usuarios mayor.
En esta fase se encuentran actividades como la venta, formación de los usuarios,
ofrecimiento de ayuda en línea y corrección de defectos descubiertos tras la implantación.
Los defectos: (1) los que justifican la aparición de una nueva versión del sistema, (2) los
que se pueden dejar para la siguiente versión que se cree.
Ejercicio de autoevaluación
Obtener el modelo conceptual de un sistema que gestiona las matrículas de los estudiantes de la
Universidad Remington.
Una persona viene caracterizada por su ID, nombre, dirección 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 tendrán un código, un nombre, un profesor
responsable y un curso asignado. Una vez matriculado, el estudiante podrá recibir una beca, y en su
nueva condición de becario tendrá asignado un nuevo código y se conocerá el importe de la misma;
al finalizar el curso, la condición de becario acabará. Una vez el estudiante se matrícula, 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. Además, convendrá tener una serie de aplicaciones tales como dar de alta a
nuevas personas y asignaturas, llevar a cabo la matriculación de estudiantes en asignaturas, registrar
las notas obtenidas por los estudiantes al examinarse de cualquier asignatura en la que están
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).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
3. LA ARQUITECTURA DE SOFTWARE.
OBJETIVO GENERAL
Presentar de manera práctica las diferentes metodologías y buenas prácticas para documentación
y evaluación de arquitecturas de software
OBJETIVOS ESPECÍFICOS
Identificar y comprender los diversos aspectos del software utilizando distintos modelos o
vistas.
Describir y diseñar una arquitectura basados en la estructura sintáctica y semántica del
ADL.
Estructurar todo el análisis del proyecto por medio de estructuras que nos provee UML
2.0.
Crear Arquitecturas de servicios web por medio SOA para garantizar una comunicación
rápida y transparente entre aplicaciones.
Desarrollar implementaciones sobre computación móvil aplicando arquitecturas de alta
escalabilidad.
3.1. Relación de conceptos
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
3.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 asimilación
a) ¿Qué caracteriza el diseño en la arquitectura del software?
b) ¿Cuáles modelos de la arquitectura puedes mencionar?
c) Indique al menos una característica de los estilos arquitectónicos
d) ¿Qué es ADL y que componentes de éste puedes indicar?
e) ¿Cuáles son las cualidades del enfoque arquitectónico 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.
Características de un diseño 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 cómo el diseño arquitectónico 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 diseño de sistemas similares. Debe ser
capaz de reutilizar bloques de construcción arquitecturales.
Modelos:
Estructurales: Representan la arquitectura como una colección organizada de componentes.
De Frameworks: Identifican patrones de diseño arquitectónico repetibles que se encuentran en
aplicaciones similares.
Dinámicos: Muestran los aspectos del comportamiento dinámico de la arquitectura, indicando
como la estructura o la configuración del sistema pueden cambiar en función de eventos externos.
De procesos: Se enfocan en el diseño de los procesos del negocio que el sistema debe soportar.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Funcionales: Pueden utilizarse para representar la jerarquía funcional de un sistema.
Para tener un concepto más claro sobre arquitectura de software podemos tener en cuenta los
siguientes aspectos:
Facilita la comunicación entre los diferentes participantes en el desarrollo.
Resalta las decisiones de diseño que pueden tener un gran impacto en todo el proceso de
desarrollo posterior.
Aporta una visión de cómo se estructura el sistema y cómo sus componentes trabajan
juntos.
Miremos ahora los estilos arquitectónicos:
Modelos de descomposición de sistemas.
Modelo de almacén central.
Cliente/servidor.
Modelo de máquinas abstractas.
Modelo de control
Centralizado.
Modelo de eventos.
Modelos de descomposición modular
Modelo de flujo de datos.
Modelo orientado a objetos.
Modelo de dominio específico
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 llegarán
posiblemente utilizando técnicas distintas, A veces la frontera entre dos estilos no está muy clara,
lo que provoca que haya mezcla entre ellos.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Arquitectura centrada en los datos: Como parte central de esta arquitectura aparece un almacén
de datos, el cual es accedido de manera frecuente por otros componentes que actualizan, añaden,
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 envía información a los clientes cuando los datos de su
interés cambian, siendo por tanto un ente activo.
Arquitectura centradas en datos proporcionan integridad, es decir, los componentes existentes
pueden cambiar y pueden añadirse nuevos componentes a la arquitectura sin que afecte a otros
clientes. A su vez los datos pueden ser pasados entre cliente a través de mecanismos que
coordinen dicha transferencia de información. Miremos a continuación una figura que nos
visualiza de manera más general lo que acabamos de expresar.
Componentes cliente ejecutan procesos independientemente
Arquitectura centrada en los flujos de datos: Se basa en el patrón “pipe and filter” (tuberías y
filtros). Este consta de un conjunto de componentes denominados “filtros” conectados entre sí
por “tuberías” que transmiten datos desde un componente al siguiente.
Cada filtro trabaja de manera independiente de los componentes que se encuentran situados
antes o después de ella. Se diseñan de tal modo que esperan un conjunto de datos en un
determinado formato y obtiene como resultado otros datos de salida en un formato específico.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Si el flujo degenera en una única línea de transformación, se denomina secuencial batch.
Veamos una figura referente a esta arquitectura
Arquitectura llamada y respuesta (call and return): Permite a los diseñadores software conseguir
estructuras de programas relativamente fáciles de modificar y escalar.
Podemos encontrar diferentes estilos de este tipo:
Programa principal/subprograma: Descompone las funciones en una jerarquía 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 continuación una figura de esta arquitectura:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Arquitectura orientada a objetos: Los componentes del sistema encapsulan datos y operaciones
que deben utilizarse para manipular dichos datos. La comunicación y coordinación entre
componentes se realiza mediante envío 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 más al nivel del conjunto de instrucciones máquina.
Sistemas en capas puros: Cada capa sólo puede comunicarse con las vecinas. Esta solución aunque
puede ser menos eficiente en algunos casos, facilita la portabilidad de los diseños. A continuación
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 profusión, se supone que debería
expresar las características de su sistema, o en otras palabras, modelarlo, aplicando una
convención gráfica o algún lenguaje avanzado de alto nivel de abstracción.
A esta altura del desarrollo de la arquitectura de software, podría pensarse que hay abundancia de
herramientas de modelado que facilitan la especificación de desarrollos basados en principios
arquitectónicos, que dichas herramientas han sido consensuadas y estandarizadas hace tiempo y
que son de propósito general, adaptables a soluciones de cualquier mercado vertical y a cualquier
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
estilo arquitectónico. La creencia generalizada sostendría que modelar arquitectónicamente un
sistema se asemeja al trabajo de articular un modelo en ambientes ricos en prestaciones gráficas,
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. También podría pensarse que los
instrumentos incluyen la posibilidad de diseñar modelos correspondientes a proyectos basados en
tecnología de internet, Web services o soluciones de integración de plataformas heterogéneas, y
que, una vez trazado el modelo, el siguiente paso en el ciclo de vida de la solución se produzca con
naturalidad y esté servido por técnicas bien definidas. Como se verá en este documento, la
situación es otra, dista de ser clara y es harto más 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 arquitectónicos y las que se trabajan en
función 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 período de gloria de la
OOP podría estar acercándose a su fin, el hecho concreto es que el modelado orientado a objetos
de sistemas basados en componentes posee cierto número de rasgos muy convenientes a la hora
de diseñar o al menos describir un sistema. En primer lugar, las notaciones de objeto resultan
familiares a un gran número de ingenieros de software.
TEMA 2 Criterios de definición de un ADL
Los ADLs se remontan a los lenguajes de interconexión de módulos (MIL) de la década de 1970,
pero se han comenzado a desarrollar con su denominación actual a partir de 1992 o 1993, poco
después de fundada la propia arquitectura de software como especialidad profesional. La
definición más 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 más tempranas es la de Vestal [Ves93] quien sostiene que un ADL debe modelar o
soportar los siguientes conceptos:
Componentes
Conexiones
Composición jerárquica, en la que un componente puede contener una sub-arquitectura
Completa
Paradigmas de computación, es decir, semánticas, restricciones y propiedades no
funcionales
Paradigmas de comunicación
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Modelos formales subyacentes
Soporte de herramientas para modelado, análisis, evaluación y verificación
Composición automática de código aplicativo
Basándose en su experiencia sobre Rapide, Luckham y Vera [LV95] establecen como
requerimientos:
Abstracción de componentes
Abstracción de comunicación
Integridad de comunicación (sólo los componentes que están conectados pueden
comunicarse)
Capacidad de modelar arquitecturas dinámicas
Composición jerárquica
Relatividad (o sea, la capacidad de mapear o relacionar conductas entre arquitecturas)
Tomando como parámetro 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, aserción de propiedades e
implementaciones
Abstracción y encapsulamiento
Tipos y verificación de tipos
Capacidad para integrar herramientas de análisis
Otros autores, como Shaw y Garlan [SG94] estipulan que en los ADLs los conectores sean tratados
explícitamente como entidades de primera clase (lo que dejaría al margen de la lista a dos de ellos
al menos) y han afirmado que un ADL genuino tiene que proporcionar propiedades de
composición, abstracción, reusabilidad, configuración, heterogeneidad y análisis, lo que excluiría a
todos los lenguajes convencionales de programación y a los MIL.
La especificación más completa y sutil (en tanto que se presenta como provisional, lo que es
propio de un campo que recién se está definiendo) es la de Medvidovic [Med96]:
Componentes
Interfaz
Tipos
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Semántica
Restricciones (constraints)
Evolución
Propiedades no funcionales
Conectores
Interfaz
Tipos
Semántica
Restricciones
Evolución
Propiedades no funcionales
Configuraciones arquitectónicas
Comprensibilidad
Composicionalidad
Heterogeneidad
Restricciones
Refinamiento y trazabilidad
Escalabilidad
Evolución
Dinamismo
Propiedades no funcionales
Soporte de herramientas
Especificación activa
Múltiples vistas
Análisis
Refinamiento
Generación de código
Dinamismo
Nótese, en todo caso, que no se trata tanto de aspectos definitorios del concepto de ADL, sino de
criterios para la evaluación de los ADLs existentes, o sea de un marco de referencia para la
clasificación y comparación de los ADLs.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
En base a las propuestas señaladas, definiremos a continuación los elementos constitutivos
primarios que, más allá de la diversidad existente, son comunes a la ontología de todos los ADLs y
habrán 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-línea de las arquitecturas
de software. Ejemplos típicos serían clientes, servidores, filtros, objetos, pizarras y bases de datos.
En la mayoría de los ADLs los componentes pueden exponer varias interfaces, las cuales definen
puntos de interacción entre un componente y su entorno.
Conectores. Representan interacciones entre componentes. Corresponden a las líneas de las
descripciones de caja-y-línea. Ejemplos típicos podrían ser tuberías (pipes), llamadas a
procedimientos, broadcast de eventos, protocolos cliente-servidor, o conexiones entre una
aplicación y un servidor de base de datos. Los conectores también tienen una especie de interfaz
que define los roles entre los componentes participantes en la interacción.
Configuraciones o sistemas. Se constituyen como grafos de componentes y conectores. En los
ADLs más avanzados la topología del sistema se define independientemente de los componentes y
conectores que lo conforman. Los sistemas también pueden ser jerárquicos: componentes y
conectores pueden subsumir la representación de lo que en realidad son complejos subsistemas.
Propiedades. Representan información semántica sobre un sistema más 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 específicos, configuraciones
mínimas de hardware y tolerancia a fallas.
Restricciones. Representan condiciones de diseño que deben acatarse incluso en el caso que el
sistema evolucione en el tiempo. Restricciones típicas serían restricciones en los valores posibles
de propiedades o en las configuraciones topológicas admisibles. Por ejemplo, el número de
clientes que se puede conectar simultáneamente a un servicio.
Estilos. Representan familias de sistemas, un vocabulario de tipos de elementos de diseño y de
reglas para componerlos. Ejemplos clásicos serían las arquitecturas de flujo de datos basados en
grafos de tuberías (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 estándar de
integración de componentes, patrones arquitectónicos o como se lo quiera llamar.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Evolución. Los ADLs deberían soportar procesos de evolución permitiendo derivar subtipos a partir
de los componentes e implementando refinamiento de sus rasgos.
Sólo unos pocos lo hacen efectivamente, dependiendo para ello de lenguajes que ya no son los de
diseño arquitectónico sino los de programación.
Propiedades no funcionales. La especificación de estas propiedades es necesaria para simular la
conducta de runtime, analizar la conducta de los componentes, imponer restricciones, mapear
implementaciones sobre procesadores determinados, etcétera.
3.4. Enfoques arquitectónicos de software
Antes de enfrentarnos a tomar la decisión de una arquitectura creo que debemos tener en cuenta
cualidades como: Performance, Availability, Security, Modifiability
También 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 desempeño aceptable
A continuación vamos a centrarnos en 2 enfoques arquitectónicos SAAM y ATAM
SAAM - Software Architecture Analysis Method
Propósito, Contexto y escenarios, Roles, Método de análisis, Fortalezas, Debilidades
Propósito: 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. Interacción entre un interesado y el sistema
Un escenario directo es el que puede satisfacerse sin la necesidad de modificaciones en la
arquitectura.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Un escenario indirecto es aquel que requiere modificaciones en la arquitectura para poder
satisfacerse.
Interacción de escenarios n escenarios. Dos o más escenarios indirectos requieren cambios sobre
el mismo componente
Roles:
Interesados externos externos (Organización cliente, usuarios finales, administradores del sistema,
etc.)
Interesados internos internos(Arquitectos de Software, analistas de requerimientos)
Equipo SAAM SAAM(Líder, expertos en el dominio de la aplicación, expertos externos en
arquitectura y secretario)
Método de análisis:
Paso1: Desarrollo de escenarios.
Paso2: Descripción de la Arquitectura.
Paso3: Clasificación de escenarios.
Paso4: Evaluación de escenarios.
Paso5: Interacción de escenarios.
Paso6: Evaluación general.
1. Desarrollo de escenarios: Un escenario es una breve descripción 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. Descripción de la arquitectura
La arquitectura (o las candidatas) debe ser descrita haciendo uso de alguna notación
arquitectónica que sea común a todas las partes involucradas en el análisis. Deben incluirse los
componentes de datos y conexiones relevantes, así como la descripción del comportamiento
general del sistema.
El desarrollo de escenarios y la descripción de la arquitectura son usualmente llevados a cabo de
forma intercalada, o a través de varias iteraciones.
3. Clasificación y asignación de prioridad de los escenarios
La clasificación de los escenarios puede hacerse en dos clases: directos e indirectos.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Los escenarios indirectos son de especial interés para SAAM, pues son los que permiten medir el
grado en el que una arquitectura puede ajustarse a los cambios de evolución que son importantes
para los involucrados en el desarrollo.
4. Evaluación individual de los escenarios indirectos
Para cada escenario indirecto, se listan los cambios necesarios sobre la arquitectura, y se calcula
su costo.
Una modificación sobre la arquitectura significa que debe introducirse un nuevo componente o
conector, o que alguno de los existentes requiere cambios en su especificación.
5. Evaluación de la interacción entre escenarios
Cuando dos o más escenarios indirectos proponen cambios sobre un mismo componente, se dice
que interactúan sobre ese componente.
Es necesario evaluar este hecho, puesto que la interacción de componentes semánticamente no
relacionados revela que los componentes de la arquitectura efectúan funciones semánticamente
distintas.
De forma similar, puede verificarse si la arquitectura se encuentra documentada a un nivel
correcto de descomposición estructural.
6. Creación de la evaluación global
Debe asignársele un peso a cada escenario, en términos de su importancia relativa al éxito del
sistema.
Esta asignación de peso suele hacerse con base en las metas del negocio que cada escenario
soporta. En el caso de la evaluación de múltiples arquitecturas, la asignación de pesos puede ser
utilizada para la determinación de una escala general.
Fortalezas:
Los interesados comprenden con facilidad las arquitecturas evaluadas.
La documentación es mejorada.
El esfuerzo y el costo de los cambios pueden ser estimados con anticipación.
Analogía con el concepto de bajo acoplamiento y alta cohesión.
Debilidades:
La generación de escenarios está basada en la visión de los interesados.
No provee una métrica clara sobre la calidad de la arquitectura Evaluada.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
El equipo de evaluación confía en la experiencia de los arquitectos para proponer arquitecturas
candidatas.
Ahora miremos el enfoque con:
ATAM Architecture Tradeoff Analysis Method
Este método de evaluación indica cuan bien una arquitectura particular satisface las metas de
calidad, y provee ideas de cómo esas metas de calidad interactúan entre ellas, como realizan
concesiones mutuas (trade off) entre ellas.
El método consta de 9 pasos divididos en cuatro grupos:
1. Presentación.
2. Investigación y Análisis.
3. Pruebas
4. Informes
Grupo 1 Presentación:
1. Presentación del ATAM: El líder de evaluación describe el método a los participantes, trata de
establecer las expectativas y responde las preguntas propuestas.
2. Presentación de las metas del negocio: Se realiza la descripción de las metas del negocio que
motivan el esfuerzo, y aclara que se persiguen objetivos de tipo arquitectónico.
3. Presentación de la arquitectura: El arquitecto describe la arquitectura, enfocándose en cómo
ésta cumple con los objetivos del negocio.
Grupo 2 Investigación y Análisis:
4. Identificación de los enfoques arquitectónicos: Estos elementos son detectados, pero no
analizados.
5. Generación del UtilityTree: Se priorizan los atributos de calidad que engloban la “utilidad”
del sistema (desempeño, disponibilidad, seguridad, modificabilidad, usabilidad, etc.),
especificados en forma de escenarios.
Se anotan los estímulos y respuestas, así como se establece la prioridad entre ellos.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
6. Análisis de los enfoques arquitectónicos: 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 arquitectónicos, puntos de sensibilidad y puntos de balance.
Grupo 3 Pruebas:
7. Lluvia de ideas y establecimiento de prioridad de escenarios: Con la colaboración de todos los
involucrados, se complementa el conjunto de escenarios.
8. Análisis de los enfoques arquitectónicos: 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 análisis realizado hasta el momento.
Grupo 4 Reporte:
9. Presentación de los resultados: Basado en la información recolectada a lo largo de la evaluación
del ATAM, se presentan los hallazgos a los participantes.
3.5. Modelado Arquitectónico en UML 2.0
DESCOMPOSICION DE UN SISTEMA
UML 2.0 usa interfaces basadas en componentes de desarrollo.
Descompone jerárquicamente el sistema en partes más pequeñas.
Permite la reutilización en diferentes contextos.
AÑADIENDO EL COMPORTAMIENTO A LA MEZCLA
El comportamiento de una clase es delegada a sus partes y la clase misma debe contener su
comportamiento. (Máquina de estado, d. actividad, d. interacción )
El contenedor describe el comportamiento de cómo crear las partes.
ACTUANDO SOBRE LAS ACCIONES
Acciones: Es la unidad fundamental de la especificación de comportamiento que representa
alguna transformación o proceso.
Las acciones tienden a ser generales y se aplican a todos los tipos e comportamiento por
instancia, máquinas de estado, interacciones o actividades.
Actividad: Es la construcción básica 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.)
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
ARQUITECTURA DE SISTEMAS EXISTENTES.
Esto sucede cuando el sistema ha sido desarrollados in una descripción arquitectónica, o cuando el
arquitecto tiene que abandonar el proyecto por algún motivo. Para poder tener una descripción
arquitectónica en estos casos se hace uso de la ingeniería en reversa. Es necesario tener esta
descripción arquitectónica, con el fin de hacer mantenimiento y desarrollo de nuevas versiones del
mismo sistema.
EVALUACIÓN ARQUITECTÓNICA
El propósito de esta evaluación es determinar la calidad de la descripción arquitectónica, y
predecir la calidad del sistema que cuyas arquitecturas hacen parte de la descripción
arquitectónica.
UML 2.0 integra las actividades con sus acciones relacionadas.
UML tuvo la iniciativa para especificar modelos ejecutables.
Sustituye los modelos de acción anteriores con uno nuevo en el que se puede expresar acciones
con semántica de precisión porcentual.
El sistema permite la verificación en una etapa más temprana en el desarrollo del ciclo de vida y
permite a las herramientas automatizar las pruebas mediante el uso de modelos UML.
La notación 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 definición flexible de la semántica que
debe reforzarse en algunas zonas o especificar con más 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 DESCRIPCIÓN ARQUITECTÓNICA
Análisis de alternativas arquitectónicas.
Planeación para la migración de arquitecturas.
Comunicación entre compradores y desarrolladores.
Comunicación entre compradores y desarrolladores.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Comunicación entre las organizaciones involucradas en el desarrollo, la producción,
presentación, operación, y mantenimiento del sistema.
Documentación para el desarrollo y el mantenimiento.
Soporte operacional y de infraestructura.
Soporte para planeación y presupuesto.
Preparación de documentos de adquisición.
Revisión, análisis y evaluación del sistema a través del ciclo de vida.
Especificación para un grupo de sistemas que comparten las mismas características.
PRÁCTICAS DE DESCRIPCIÓN ARQUITECTÓNICA
Documentación arquitectónica.Ladescripcióndeunaarquitecturadebecontenerlossiguientesítems:
Fecha y estado de la cuestión.
Organización de la cuestión.
Historial de cambios.
Resumen.
Alcance.
Contexto.
Glosario.
Referencias.
Usuarios del sistema.
Compradores del sistema.
Desarrolladores del sistema.
Encargados del mantenimiento del sistema.
Vistas arquitectónicas. 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 información introductoria.
Representación del sistema.
Información de la configuración.
Consistencia entre las vistas arquitectónicas.
Justificación arquitectónica.
Conclusiones:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
SOA (Services Oriented Architecture)
Para empezar este tutorial, me gustaría comenzar con una serie de afirmaciones que creo que
nadie me podría negar:
Los procesos de negocio de las empresas son cada día más complejos.
La evolución del mercado y la fuerte competencia exige a las empresas una respuesta más
á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 añadido apoyándose en acuerdos con otras empresas (por ejemplo, una línea aérea
quiere ofrecer a través de su vez, no sólo reservar billetes en un vuelo, sino ofrecer una
solución 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 tecnológica, o dicho de otro modo, la
arquitectura
A lo largo de los años, 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 archipiélago de aplicaciones.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
La realidad del mercado nos ha llevado a las siguientes aseveraciones:
Nuestras aplicaciones internas están de alguna manera condenadas a entenderse, si
queremos dar una respuesta ágil, a las necesidades de negocio que surgen.
Las aplicaciones de nuestra empresa están 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 cajón de sastre, donde SOA pretende hacer su aparición.
La palabra arquitectura en el mundo del software se podría 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, máquinas, sistemas operativos, lenguajes de programación, 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 más 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 metodología de proyecto, aunque a la hora de iniciar un proyecto orientado
a conseguir una arquitectura SOA en mi empresa, algunas metodologías se ajustan mejor
que otras: es preferible seguir un modelo en iteraciones (no confundir con iterativo como
UP), como las metodologías ágiles (XP, etc..), que seguir metodologías Waterfall
SOA no es otra forma de llamar a los WebServices, aunque los webservices son una
herramienta válida para conseguir una arquitectura SOA, incluso una arquitectura SOA
podría apoyarse en la programación distribuida (DCOM, CORBA, RMI, EJBs...)
¿QUÉ ES SOA?
Entonces, ¿Qué es SOA?
Yo me atrevería 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
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
montar nuestra infraestructura tecnológica. Para poder continuar explicando la definición, urge
definir previamente qué es un servicio. Primeramente, antes de continuar con la exposición, os
planteo la siguiente pregunta: ¿Cuál es la duración media de los componentes que forman parte
de la infraestructura tecnológica de una empresa?
Una respuesta aproximada podría ser:
Las innovaciones tecnológicas y productos nuevos aparecen aproximadamente cada 5
años.
Nuestras aplicaciones empresariales tienen una duración de unos 8 a 10 años
La lógica de negocio o los procesos de negocio permanecen en vigor unos 17 o 18 años.
Los datos (o la estructura de los datos) perduran aproximadamente 25 años.
En base a esas respuestas, podemos intuir que a la hora de elegir como organizar nuestra
infraestructura tecnológica, si nuestro objetivo es obtener la máxima reusabilidad y permanencia
en el tiempo, debemos adoptar decisiones que vayan orientadas hacia la independencia
tecnológica y al acercamiento al proceso de negocio y los datos.
Entonces, ¿Qué es un servicio?
Un servicio lo podríamos definir como la resolución de una necesidad de negocio, que debe ser
autocontenida (es decir que no contenga la resolución de otra necesidad en el mismo) y que está
constituido por tres partes bien diferenciadas:
1. Un contrato: que define la especificación del propósito del servicio, así como restricciones
en su uso, calidad que debe ofrecer etc..., pero sin especificar nada acerca de la tecnología
subyacente.
2. Un interfaz físico donde los clientes que quieren usar el servicio pueden invocarlo (podría
ser una URL)
3. Una implementación: un servicio se apoya en alguna tecnología para realizar lo que se
expone en su contrato. La implementación de un servicio podrá consistir en la interacción
de distintos artefactos (EJBs, CORBA, Bases de datos ... ), y estará compuesta de:
1. Una lógica 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 agnósticos de la
tecnología. Estos servicios que podríamos denominar básicos, permitirán construir servicios de
mayor valor añadido mediante la composición o el engranaje de estos servicios básicos.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
¿ACTORES DE SOA?
Una vez que hemos visto lo que es un servicio, os voy a presentar los demás actores que deberían
participar en una arquitectura SOA:
1. Frontales de aplicación. Estos serán no tanto partes funcionales de una arquitectura SOA sino
aquellos que se van a beneficiar de ella, es decir serán aquellos que quieran hacer uso de los
servicios ofrecidos dentro de la arquitectura. Frontales de aplicación podrán 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á algún componente de mi
arquitectura que permitirá tanto a los frontales de aplicación como a otros servicios, descubrir
que servicios existen, cuál es su interfaz y donde se encuentran físicamente. Los objetivos de
este componente serán:
1. Crear un nivel de indirección para localizar a los servicios
2. Servir como repositorio de información 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 aplicación y los servicios.
2. Debe ser agnóstico de lenguajes de programación y tecnologías. Es decir debe ofrecer
una forma de comunicación universal, para que todos puedan entenderse (por
ejemplo, puede usar XML como formato de comunicación de los mensajes)
3. Debe ser capaz de ofrecer diferentes paradigmas de comunicación (sincronismo y
asincronismo).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
4. Debería ser capaz de ofrecer otra serie de funcionalidades transversales como:
Trazabilidad de las operaciones (logging)
Mecanismos de seguridad (autenticación, autorización, encriptación, no repudio ...)
Mecanismos de transaccionalidad: protocolo de commit en dos fases (2PC) o transacciones
en cadena y mecanismos de compensación (SAGA) etc...
Enriquecimiento de mensajes, adaptación etc...
Control centralizado, mecanismos de monitorización.
Que incluyese un procesador de BPM, que permitiese construir servicios de mayor valor
añadido en base a servicios básicos, simplemente definiendo la lógica en algún lenguaje
del tipo BPEL o BPEL4WS, etc...
EPÍLOGO
Conseguir reorganizar la infraestructura tecnológica de nuestra empresa para que se encamine
hacia una arquitectura SOA es un proceso muy complejo. He leído en algún sitio que el 70% de los
proyectos que se embarcan en esta tarea fracasan.
No sólo nos encontraremos problemas tecnológicos, sino también muchos problemas debido a la
política y cultura empresarial. Además, es un proceso largo (de años) que debe ser iniciado de
manera muy cuidadosa. Es muy recomendable llevarlo a cabo de una manera gradual, y no todo
de una vez, acompañando la tarea de llevarlo a cabo con una continua "evangelización" de las
ventajas de SOA a todos los niveles de la empresa.
Es probable que debamos cambiar la metodología de proyectos para orientarlo hacia
metodologías más ágiles (XP) etc...
Es probable también que debamos empezar a modelar siguiendo la filosofía de MDA (Model
Driven Architecture), de una manera independiente de la tecnología, partiendo desde los procesos
de negocio para ir gradualmente obteniendo el modelado específico de la plataforma en la que
vamos a realizar la implementación del proceso de negocio (o servicio).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Por mi parte nada más, espero que os haya servido para entender un poco de que va esto del SOA.
Arquitecturas para computación móvil
A principios del nuevo milenio las tecnologías móviles, obviamente, no estaban tan evolucionadas
como en la actualidad. Entre otros, se tenían los celulares por un lado, los busca personas por
otro, y las PDA (Asistentes Personales Digitales), a las que tenía acceso el autor eran las de familia
PALM, el color que predominaba en la pantalla de estos dispositivos era el verde. Para la
comunicación se disponía de un accesorio denominado modem; este accesorio se utilizaba para
enviar y recibir datos por medio de la línea telefónica.
Emulador Palm OS, principios de los 2000
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Toma del Pedido, almacenado en el Dispositivo móvil y Envió posterior por medio de la línea
telefónica.
Arquitectura de una aplicación móvil
Existen varios escenarios en los cuales se puede establecer la arquitectura de aplicaciones móviles;
aquí se abordaran dos de ellos.
En el primero participan tres elementos:
La aplicación central
El proceso de sincronización
La aplicación en el dispositivo móvil
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Escenario número1.
En el segundo escenario participan dos elementos:
El dispositivo móvil
La aplicación central
Ejercicio de autoevaluación
De acuerdo a las siguientes figuras desarrolle una aplicación con los elementos descritos en esta
unidad teniendo en cuenta una muy buena arquitectura de software, como lenguaje de
programación puede utilizar Java y su herramienta NetBeans u otra.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
4. DEFINICIONES Y PATRONES DE SOFTWARE.
OBJETIVO GENERAL
Apropiar el uso de catálogos de elementos reusables en el diseño de sistemas software
OBJETIVOS ESPECÍFICOS
Clarificar cada uno de los conceptos utilizados en patrones de software
Evitar la reiteración en la búsqueda de soluciones a problemas solucionados
anteriormente
Estandarizar el modo en que se realiza el diseño por medio de la utilización de patrones
GoF
Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando
conocimiento ya existentes
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
4.1. 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 asimilación
a) ¿Qué entiendes por patrones de diseño de software?
b) ¿Cuáles son los propósitos y el ámbito de los patrones de diseño?
c) ¿Caracterice de forma sencilla al menos 2 patrones de diseño?
4.2. Definiciones Básicas
Patrones de diseño software
El diseño es un modelo del sistema, realizado con una serie de principios y técnicas, 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 diseño podemos observar que los buenos ingenieros
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
tienen esquemas y estructuras de solución que usan numerosas veces en función del contexto del
problema. Este es el sentido cabal de la expresión "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
solución ante problemas similares.
El concepto de "patrón de diseño" que tenemos en Ingeniería 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 notación específica
de Alexander.
Alexander comenta que “Cada patrón describe un problema que ocurre una y otra vez en nuestro
entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa
solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos veces de la misma
forma”. El patrón es un esquema de solución que se aplica a un tipo de problema, esta aplicación
del patrón no es mecánica, sino que requiere de adaptación y matices. Por ello, dice Alexander
que los numerosos usos de un patrón no se repiten dos veces de la misma forma.
La idea de patrones de diseño estaba "en el aire", la prueba es que numerosos diseñadores se
dirigieron a aplicar las ideas de Alexander a su contexto. El catálogo más 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, también conocido
como el libro GOF (Gang-Of-Four).
Siguiendo el libro de GOF los patrones se clasifican según el proposito para el que han sido
definidos:
Creacionales: solucionan problemas de creación de instancias. Nos ayudan a encapsular y
abstraer dicha creación.
Estructurales: solucionan problemas de composición (agregación) de clases y objetos.
De Comportamiento: soluciones respecto a la interacción y responsabilidades entre clases
y objetos, así como los algoritmos que encapsulan.
Según el ámbito se clasifican en patrones de clase y de objeto:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Creación Estructural De Conducta
Clase Método de Fabricación Adaptador (clases) Interprete
Plantilla
Objeto Fábrica, Constructor,
Prototipo, Singleton
Adaptador (objetos),
Puente, Composición,
Decorador, Fachada,
Flyweight
Cadena de Responsabilidad,
Comando (orden), Iterador,
Intermediario, Observador, Estado,
Estrategia, Visitante,
Memoria
Concepto de patrón de diseño
"Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad de un
sistema orientado a objetos se mide por la atención que los diseñadores han prestado a las
colaboraciones entre sus objetos. Los patrones conducen a arquitecturas más pequeñas, más
simples y más comprensibles". (Grady Booch)
Los patrones de diseño son descripciones de clases cuyas instancias colaboran entre sí. Cada
patrón es adecuado para ser adaptado a un cierto tipo de problema. Para describir un caso
debemos especificar:
Nombre
Propósito o finalidad
Sinónimos (otros nombres por los que puede ser conocido)
Problema al que es aplicable
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Estructura (diagrama de clases)
Participantes (responsabilidad de cada clase)
Colaboraciones (diagrama de interacciones)
Implementación (consejos, notas y ejemplos)
Otros patrones con los que está relacionado
Ventajas de los patrones:
La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de modo que los
sistemas evolucionen de forma adecuada. Cada patrón permite que algunos aspectos de la
estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la
reusabilidad, extensibilidad y mantenimiento.
Un patrón es un esquema o microarquitectura que supone una solución a problemas (dominios
de aplicación) semejantes (aunque los dominios de problema pueden ser muy diferentes e ir
desde una aplicación CAD a un cuadro de mando empresarial). Interesa constatar una vez más la
vieja distinción entre dominio del problema (donde aparecen las clases propias del dominio, como
cuenta, empleado, coche o beneficiario) y el dominio de la solución o aplicación (donde además
aparecen clases como ventana, menú, contenedor o listener). Los patrones son patrones del
dominio de la solución.
También conviene distinguir entre un patrón y una arquitectura global del sistema. Por decirlo en
breve, es la misma distancia que hay entre el diseño de un componente (o módulo) y el análisis 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 patrón es el denominador común, una estructura común que tienen aplicaciones
semejantes. Esto también ocurre en otros ordenes de la vida. Por ejemplo, en nuestra vida
cotidiana aplicamos a menudo el esquema saludo-presentación-mensaje-despedida en ocasiones
diversas, que van desde un intento de ligar hasta dar una conferencia (si todavía no cree que
existan patrones o que no son útiles intente ligar con el esquema despedida-mensaje-
presentación-saludo, a ver qué ocurre).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
4.3. Catálogos de Patrones
Patrón "delegado" La herencia es útil para modelar relaciones de tipo es-uno es-una, ya que estos tipos de relaciones
son de naturaleza estática. 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 método de comparación. En Java tenemos un caso: la clase Collections tiene el
método estático sort(); desde este método se delega en un comparador para establecer el orden:
Collections tiene el método sort() con un algoritmo de ordenación.
Comparador tiene el método compare() que implementa el orden de comparación.
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() )
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
return 1;
return 0;
}
}
Patrón "compuesto"
Crear jerarquías 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 composición de otras
figuras simples. Otro ejemplo puede ser un activo financiero (un fondo de inversión) 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 fácil añadir
nuevos tipos de componentes.
Implementación
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:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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:
Añadir un componente simple a un Panel (tipo de Container): panel_sup.add( t_n1 )
Crear compuestos recursivos, añadiendo 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.
Patrón "decorador"
Imaginemos que tenemos un editor de texto básico y queremos añadirle nuevas funcionalidades,
como un scroll o un borde. Una solución podría ser crear subclases para un editor con scroll, sin
scroll, con scroll y con borde, etc. Evidentemente esta no es una buena solución, ya que acabamos
con una jungla de clases y subclases.
Con este patrón tratamos de evitar este efecto de herencia-jungla, ya que asignamos
dinámicamente nuevas responsabilidades a un objeto. Es una alternativa más flexible a crear
subclases para extender la funcionalidad de una clase. De esta forma añadimos atributos o
comportamiento adicional a un objeto concreto, no a una clase.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Un ejemplo de implementación con Java
El componente gráfico es un modesto editor de texto:
JEditorPane panel_text = new JEditorPane();
Es muy sencillo añadir la funcionalidad del scroll sin usar herencia:
JScrollPane scroll_text = new JScrollPane( panel_text ); // Asignamos scroll al panel de texto.
El último paso es añadir el decorador (y por añadidura el editor) al contenedor raíz 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 razón de que al añadir (add) al contenedor raíz debamos usar el
decorador (scroll) y no el componente (editor).
Componentes y decoradores deben heredar de una clase común. En nuestro ejemplo JEditorPane
y JScrollPane heredan de JComponent.
Para ir a un tutorial sobre el patrón Decorador en tecnologías .NET pulse aquí.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Patrón "intermediario"
Supongamos una ventana con numerosos componentes gráficos (widgets) que tienen fuertes
dependencias entre si. Por ejemplo, reglas del tipo "si el campo de edición E2 está relleno,
entonces inhabilito el botón B1 y el campo de edición 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 explícita. Permite
variar la interacción sin tocar los colegas, por tanto favorece la reutilización.
Ventajas:
Evita crear subclases
Desacopla a los colegas
Simplifica los protocolos entre las clases
Abstrae el cómo cooperan los objetos
Centraliza el control en el mediador: clase difícil de mantener
Para la implementación:
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 interés ocurre, esta
comunicación puede hacerse con un Observer o un interfaz de notificación (ViewManager
de Smalltalk-V).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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
mandándolo a un campo de texto. Ver el siguiente diagrama:
Patrón "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 patrón tenemos la ventaja de
simplificar la interfaz de un contenedor, ya que no contiene los métodos de recorrerlo.
Un ejemplo típico lo tenemos en Java. El cliente solicita al contenedor un iterador. A continuación
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() );
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Patrón "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 automáticamente.
Supongamos que tenemos un o unos objetos dependientes de otro. Por ejemplo, supongamos que
una ventana o applet depende de los componentes gráficos que reciben eventos (clic en botón,
etc.). Otro caso, típico del patrón, es tener diversas vistas de una fuente de datos, de tal forma que
si cambia la fuente, entonces las vistas se actualicen automáticamente.
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
método notify() que se encarga de mandar el mensaje de update() a todos los observadores.
Permite la división de un sistema en niveles. Además de permitir reusar sujetos y observadores
por separado.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Una extensión natural de este patrón es hacer mezcla del patrón mediador y del patrón
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 semántica de
actualización en una clase ManejadorCambio(Mediador).
Implementación
Es posible que un observer esté ligado a más de un subject: la operación update tendrá como
argumento el subject.¿Quién dispara la notificación?
Métodos 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 implementación en Java
Java 1.1 introdujo un nuevo modelo de eventos para GUI basado en el patrón 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 patrón.
Los listeners deben registrarse en las fuentes (componentes GUI).
El orden sería "componente_GUI --->Listener ---> Objeto_dependiente (un applet, por ejemplo)
Un ejemplo en Java, extraido de una clase applet, donde al botón le añadimos 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:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
void boton_crear_actionPerformed(ActionEvent e) {
...
}
Obsérvese que el evento queda encapsulado por la clase ItemEvent.
Patrón "Modelo-Vista-Controlador"
Para el diseño de aplicaciones con sofisticados interfaces se utiliza el patrón de diseño Modelo-
Vista-Controlador. La lógica de un interfaz de usuario cambia con más frecuencia que los
almacenes de datos y la lógica de negocio. Si realizamos un diseño 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 más riesgo de error.
Se trata de realizar un diseño 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 lógica
de negocio o de datos.
Elementos del patrón:
Modelo: datos y reglas de negocio
Vista: muestra la información del modelo al usuario
Controlador: gestiona las entradas del usuario
Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo
clásico es el de la información de una base de datos, que se puede presentar de diversas formas:
diagrama de tarta, de barras, tabular, etc. Veamos cada componente:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar 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 inserción, 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 gestión de eventos, del tipo "SI Evento Z, entonces Acción W".
Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas
peticiones a las vistas puede ser una llamada al método "Actualizar()". Una
petición 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 además lo
instancia).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Pueden dar el servicio de "Actualización ()", 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
navegación 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 petición al Modelo (aunque también
puede llamar directamente a la vista).
3. El modelo (si es necesario) llama a la vista para su actualización.
4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo.
5. El Controlador recibe el control.
Bien, pero esto ¿cómo se implementa? Existe una pequeña 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 patrón. En el siguiente ejemplo en Java, el objeto vista es un
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Applet AWT. El controlador (controlador.java) puede gestionar el clic en un botón, de tal forma
que recoge datos por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista (el applet)
para su actualización (vista.mostrar_texto( )):
/****************************************************************
Responde al click en botón "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);
}
Patrón "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 métodos pueden ser estáticos.
Factory Method: Se define una interface para crear objetos, como en el Abstract Factory,
pero se delega a las subclases implementar la creación en concreto
Abstract Factory: Nos da una interface para crear objetos de alguna familia, sin especificar
la clase en concreto
Los dos últimos están incluidos en el catálogo del GoF
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Estos patrones entran en la categoría de patrones de creación [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 además la responsabilidad y el conocimiento
necesario para encapsular la forma en que se crean determinados tipos de objetos en una
aplicación. 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 lógico (implements). En nuestro
caso usamos interfaz.
A continuación puede ver un sencillo ejemplo en el que cada juego implementa el método lanzar
(): el juego del dado muestra un número 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();
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 creación de instancias (a diferencia
de Factory Method). Esta factoria es muy sencilla: en función del argumento crea un juego u otro:
public class FactoriaJuegos {
public static Juego getJuego( String nombreJuego ) {
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 creacioón de la instancia.
La clase cliente (Inicio.java) llama al método estático getJuego() de la factoría, para que le
devuelva el juego señalado en el argumento. Introduce todos los juegos en un vector y a
continuación le dice a cada juego que juegue. El método jugar() es un ejemplo de patrón
'estrategia': el método contiene un comportamiento genérico (en nuestro ejemplo realiza dos
lanzamientos para cada juego). El comportamiento específico se define en función del objeto que
se pasa como argumento. La parte que varía 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
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
****************************************************************/
public static void jugar( Juego juego ) {
juego.lanzar();
juego.lanzar();
}
}
Al recorrer el vector de juegos vemos un ejemplo típico de polimorfismo: a cada referencia del
tipo Juego (usamos el mismo interfaz) le decimos que juegue, pero cada juego implementa su
forma específica de jugar (más en concreto de lanzar). Es la idea de polimorfismo: un interfaz y
múltiples implementaciones.
Aunque la forma más abstracta y profesional es usar en la factoria newInstance() en función 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
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
e.printStackTrace();
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
e.printStackTrace();
return null;
}
catch ( IOException e) { // Falla load()
e.printStackTrace();
return null;
}
catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
En el archivo properties tenemos:
dado=factoriaJuegosNewInstanceProperties.JuegoDelDado
moneda=factoriaJuegosNewInstanceProperties.JuegoDeMoneda
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Patrón "Data Access Object"
El problema que viene a resolver este patrón 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 patrón surge históricamente de la necesidad de gestionar una diversidad de
fuentes de datos, aunque su uso se extiende al problema de ancapsular no sólo la fuente de datos,
sino además 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 cómo se realiza el acceso a los datos o de cuál es la fuente
de almacenamiento.
Enlace a las páginas 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 estándar 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
método estándar para acceder a tablas y vistas. La idea de este patrón es ocultar la fuente de
datos y la complejidad del uso de JDBC a la capa de presentación o de negocio.
Un DAO define la relación entre la lógica de presentación y empresa por una parte y por otra los
datos. El DAO tiene un interfaz común, sea cual sea el modo y fuente de acceso a datos.
Algunas características:
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.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 información de la fuente de datos. El ejemplo
sencillo es entenderlo como un "bean de tabla", es decir, como una representación 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 colección de ellos)
como consecuencia de una transacción 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 colección de TrasnferObject de la clase Venta
al objeto Cliente. También puede ocurrir que el objeto Cliente mande un TransferObject
para parametrizar una consulta o actualización de datos por parte del DAO.
En el siguiente gráfico se muestran las interacciones entre los elementos del patrón. En este
gráfico el TransferObject se denomina ValueObject. Puede observarse las llamadas que recibe y
genera el DAO para una consulta y actualización de datos:
1. El DAO es creado por el cliente (BusinessObject) (llamada 1 del gráfico).
2. A continuación el cliente solicita los datos al DAO (getData) (2).
3. El DAO responde a la llamada pidiendo los datos a la fuente de datos (2.1).
4. Para cada fila recibida, el DAO crea un TransferObjet (ValueObject del gráfico) (2.2).
5. El DAO devuelve al cliente el(los) TransferObject (2.3).
6. A continuación el cliente define un TransferObject mediante llamadas a setProperty. Por
ejemplo, supongamos que buscamos personas de sexo varón y 36 años; para ello el
BusinessObject define en el objeto de la clase Persona la edad y sexo que busca. Lo
siguiete es fácil de imaginar: el BusinessObject invoca al DAO, pasando a la persona como
argumento (3,4, y 5 del gráfico).
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).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Ejemplo de código: 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 común (Bean.java):
package dao.bean;
public interface Bean {
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
//// Me indica si los objetos corresponden al mismo registro de base de datos (identidad de clave
primaria)
public boolean esIgual( Bean bean );
}
A continuación 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 métodos 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;
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 relación 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 métodos 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;
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
}
public String toString() {
return (idVenta + ", " + codigo + ", " + precio + ", " + coste );
}
}
Ejemplo de código: los DAOs
Hemos empezado por lo más 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
genérico 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 continuación y a modo de resumen, una parte de DAOCliente.java. Se puede ver que
implementa el interface anterior y que además 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;
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 método insert() recibe el Transfer Object (bean) que vamos a insertar, devolviendo el número
de registros insertados (uno si ha ido bien, 0 en caso de no inserción). En el método select()
recibimos la condición (claúsula WHERE) y devuelve un vector cuyos elementos son los clientes
que cumplen la condición. Podría también devolver un ArrayList, que resulta más eficiente, pero lo
esencial es que este método, al igual que el anterior, oculta el uso de SQL y JDBC a la clase que la
llama (presentación o BusinessObject):
public Vector select( String condicion ) throws SQLException {
Vector vecClientes = new Vector();
Cliente cli;
Connection con = getConexion();
// Si la condición 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";
Statement sentencia = con.createStatement();
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();
cerrarConexion( con );
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
return vecClientes;
}
En la siguiente figura se muestra la relación de las clases anteriores:
Ejemplo de código: la factoría 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 patrón factoria. En nuestro ejemplo hemos
implementado una Factoria Simple (FactoriaDAO.java):
package dao.accesoDatos;
import java.io.*;
/*****************************************************************
*
* Factoria que crea el DAO en función del argumento del método 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 {
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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
e.printStackTrace();
return null;
}
catch (Exception e) { // No puedo instanciar la clase
e.printStackTrace();
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 /accesoDatos
/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
e.printStackTrace();
}
catch ( IOException e) { // Falla load()
e.printStackTrace();
}
catch (Exception e) {
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
e.printStackTrace();
}
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 método 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 método 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 bástante 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 genérico o abstracto, ya que
aunque tenga 15 clases de DAOs diferentes que instanciar, devuelve un tipo genérico, es decir,
devuelve el interface que implementan todos los DAOs.
Ejemplo de código: usando lo anterior
Vamos a ver un sencillo ejemplo de capa cliente, es decir, la capa (sea presentación 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 abstracción (y resuabilidad). Veamos el ejemplo:
condicion = Teclado.getCadena("Condición:"); // Obtengo condición 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());
}
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 genérico (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 código para DAOCliente, otro para DAOVenta, etc; sino que con el mismo código
manejamos diversos DAOs. Este es un ejemplo de patrón estrategia: el código es el mismo
(unificado) y la estrategia (el comportamiento específico) depende de los objetos (DAOs)
utilizados.
Un ejemplo final de abstracción 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 específico.
Otro ejemplo de aplicación del patrón DAO con servlets. En este ejemplo las clases DAO han
cambiado ligeramente para soportar un login y password diferentes en cada conexión.
Nota final
Evidentemente los DAOs deben implementar los métodos del interface (InterfaceDAO) que
declaran. Pero además pueden implementar otros métodos que no están en el interfaz (lo cual
resta generalidad). En nuestro ejemplo hemos introducido un método 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 relación 1:N de nuestras
tablas. El siguiente método de DAOCliente.java nos devuelve un vector de clientes y cada cliente
contiene un vector de ventas:
/*****************************************************************
* Consulta de clientes CON sus ventas
* Si condición es null o vacia, no se aplica en el WHERE
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
*****************************************************************/
public Vector selectConVentas( String condicion ) throws SQLException {
Vector vecClientes = new Vector();
Venta ven;
Cliente cliAnterior = null, cliActual = null;
Connection con = getConexion();
//// Si la condición 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";
Statement sentencia = con.createStatement();
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 añado venta
cliActual.setVentas( new Vector());
cliActual.addVenta( ven );
//// Añado cliente actual al vector
vecClientes.add( cliActual );
}
//// SI NO ES NUEVO CLIENTE: simplemente añado venta al cliente
else { //// Añado venta al cliente actual
cliAnterior.addVenta( ven );
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
}
}
sentencia.close();
cerrarConexion( con );
return vecClientes;
}
Patrón "Proxy"
El proxy es útil si queremos añadir 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();
}
Además tenemos una clase, denominada Pizarra, que implementa el interface Soporte y que en su
método escribir(String mensaje) simplemente añade el argumento a un Vector. El método 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);
}
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
public Vector leer() {
return mensajes;
}
}
El proxy es un intermediario (que también implementa el interface del objeto real) y que nos
permite añadir o modificar comportamiento sin reescribir el objeto real. En escribir() del proxy
añado el número de línea y delega en la Pizarra el resto de comportamiento. Es interesante
observar que este patrón evita abusar del uso de herencia. Este abuso es la primera tentación 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 aplicándola a todo tipo de problema. De esta forma no
caeremos en el vicio de aquel que sólo sabía usar martillos y todos los problemas le parecían
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 sólo utiliza el tipo Interface Soporte para acceder al
proxy, con lo que conseguimos generalidad:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
public class Inicio {
static public void main(String[] args) {
try {
//// Creamos el proxy
Soporte proxy = Factoria.getPizarra("ProxyDePizarra");
//// Escribimos (el proxy inserta número de línea)
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) {
e.printStackTrace();
}
}
}
La factoria simple es otro patrón importante. Una factoría se centra en ocultar la instanciación 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 sólo sirve para diferenciar el
modelo de la vista:
public class Visor {
static public void mostrar( String mensaje ) {
System.out.println( mensaje );
}
}
El resultado final sería:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
1 En un lugar de La Mancha
2 de cuyo nombre no quiero acordarme
Otras características
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 añadir 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 ningún acceso
directo a él, podríamos 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 añade nº de línea
proxy.escribir("QQQ"); // SI añade nº de línea
Ejercicio de autoevaluación
Diseñe el análisis del ejercicio de la Unidad1 utilizando Patrones de Software de tal manera que el
objetivo final sea la base fundamental para una posterior implementación en cualquier lenguaje de
programación orientado por aspectos.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
5. FRAMEWORKS Y EL MÓDELO MDA (MODEL DRIVEN ARCHITECTURE)
OBJETIVO GENERAL
Identificar las características de un framework para Web y apropiarse del modelado bajo el
enfoque MDA.
OBJETIVOS ESPECÍFICOS
Conocer y graficar los conceptos y estructura de un frameworks
Establecer y aplicar las técnicas para la implementación de framework a nivel empresarial.
Identificar y diferenciar las tecnologías para desarrollos de software basados en
MDA/MDD
Diferenciar PSM de PIM aplicadas en MDA
5.1. Relación de conceptos
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
5.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 asimilación
1. ¿Sabes en que consiste el Framework?
2. ¿Qué aspectos relevantes del patrón MVC podrías indicar?
3. ¿Qué podrías aportar acerca de Strust y URLs desde éste contexto?
4. ¿Sobre los conceptos MDA, PIM, PSM y CIM que podrías aportar?
5. ¿Podrías graficar el proceso interactivo del modelado MDA?
6. ¿A qué se hace referencia con los términos infraestructura y núcleo común, perfiles y
metamodelado.
5.3. Definición 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 características generales de éstos, A continuación se realiza una breve
descripción de Struts, uno de los framewoks más utilizados en desarrollo Web bajo plataforma
Java.
1. ¿Qué es un framework Web?.
En general, con el término framework, nos estamos refiriendo a una estructura software
compuesta de componentes personalizables e intercambiables para el desarrollo de una
aplicación. En otras palabras, un framework se puede considerar como una aplicación genérica
incompleta y configurable a la que podemos añadirle las últimas piezas para construir una
aplicación concreta.
Los objetivos principales que persigue un framework son: acelerar el proceso de desarrollo,
reutilizar código ya existente y promover buenas prácticas 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 configuración enXML) que componen un
diseño reutilizable que facilita y agiliza el desarrollo de sistemas Web.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
2. Patrón MVC y Model 2.
Para comprender como trabajan los frameworks Web existentes es imprescindible conocer el
patrón MVC.
El patrón Modelo-Vista-Controlador es una guía para el diseño de arquitecturas de aplicaciones
que ofrezcan una fuerte interactividad con usuarios. Este patrón organiza la aplicación en tres
modelos separados, el primero es un modelo que representa los datos de la aplicación y sus reglas
de negocio, el segundo es un conjunto de vistas que representa los formularios de entrada y salida
de información, el tercero es un conjunto de controladores que procesa las peticiones de los
usuarios y controla el flujo de ejecución del sistema.
La mayoría, por no decir todos, de los framewroks para Web implementan este patrón. Una
aplicación de este patrón en entornos Java para programación Web es lo que se conoce con el
nombre de arquitectura modelo 2.
Esta arquitectura consiste, a grandes rasgos, en la utilización de servlets paraprocesar las
peticiones (controladores) y páginas 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 publicación de documentos, como Coocon, orientados a la
parte de control de eventos, como Struts y algunos que incluyen varios elementos como Tapestry.
La mayoría de frameworks Web se encargan de ofrecer una capa de controladores de acuerdo con
el patrón MVC o con el modelo 2 de Servlets y JSP, ofreciendo mecanismos para facilitar la
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
integración con otras herramientas para la implementación de las capas de negocio y
presentación.
4. Características.
A continuación enunciamos una serie de características que podemos encontraren prácticamente
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 patrón MVC.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Struts ofrece su propio componente controlador y proporciona integración con otras tecnologías
para implementar el modelo, mediante tecnologías de acceso a datos como JDBC o Hibernate, y la
vista, mediante JSP, Velocity o XSLT.
Struts ofrece un sistema de tuberías que permite la comunicación entre el modelo que contiene
los datos y las vistas que ofrecen estos datos a los usuarios y reciben sus órdenes.
6. URLs.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
5.4. MDA (Model Driven Architecture)
Model Driven Architecture (MDA) es una aproximación definida por el Object Management Group
(OMG) [OMG], mediante la cual el diseño de los sistemas se orienta a modelos. En ocasiones, el
término 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 definición
formal. Definición creada por el grupo de trabajo OMG, que se centra en la creación de un marco
de trabajo formal, en el que puede operar MDD [Gardner 2006].
A pesar de estas sutiles diferencias, ambos términos se utilizan de manera indistinta en este
trabajo.
El desarrollo orientado a modelos permite una alta flexibilidad en la implementación, integración,
mantenimiento, prueba y simulación de los sistemas. Una de las ideas principales por la que surge
MDA es separar la especificación de los sistemas de los detalles de su implementación en una
determinada plataforma. MDA provee un conjunto de herramientas para especificar un sistema
independientemente de la plataforma de implementación, 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 catalogación de modelos que
permiten especificar el sistema desde diferentes puntos de vista. Los tipos más 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
específicos.
Platform Independent Model (PIM): muestra una vista del diseño del sistema obviando
detalles de plataformas concretas.
Platform Specific Model (PSM): muestra un diseño del sistema incluyendo detalles
específicos de la plataforma.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Desarrollo de Software Tradicional
El desarrollo de sistemas software siempre ha sido una labor intensa, pero a medida que ha ido
evolucionando la tecnología, esta labor se ha complicado cada vez más. La evolución de los
lenguajes, entornos y técnicas de programación provoca que haya que desarrollar los mismos
sistemas una y otra vez, que éstos utilicen e integren diferentes tecnologías o que exista una
necesidad de comunicación entre sistemas dispares. A todo esto hay que añadirle los continuos
cambios en los requerimientos, ya sean impuestos por los usuarios de los sistemas o derivados de
los cambios tecnológicos [Schach 2005].
El enfoque tradicional del desarrollo de software no es capaz de absorber toda esta casuística de
una forma eficiente, por problemas que vienen derivadas de su propio planteamiento, que se
resumirán a continuación.
Uno de los principales problemas es la productividad. Los desarrollos como los conocemos están
dirigidos por un diseño y una codificación a bajo nivel. El proceso típico de un desarrollo de
software, tal y como se muestra en la Figura 2-1 ([Kleppe 2005]), incluye las siguientes fases:
Conceptualización y toma de requisitos
Análisis y descripción funcional
Diseño
Codificación
Pruebas
Implantación
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Ciclo de vida del desarrollo de software tradicional
Como se expresa en la figura, las tres primeras fases se centran en generar la documentación 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 interacción o de actividades. Por el contrario, las
tres últimas fases se centran básicamente en la codificación, utilizando como punto de partida la
documentación generada previamente. En el momento de iniciar la codificación del software, toda
la documentación generada hasta el momento, la utilizan los programadores para poder iniciar su
trabajo. Incluso, en el caso de utilizar UML en la fase de análisis, muchas herramientas CASE
generan código 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 gráficamente 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 documentación, ya que ésta es uno de los valores fundamentales de los sistemas. Un sistema no
es sólo el código.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Aproximación MDA
La arquitectura dirigida por modelos (MDA) [Mellor 2004] es una aproximación 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 sección anterior. En realidad, el enfoque de Kleppe se
centra en las fases de desarrollo, pero en según el proceso unificado de desarrollo [Jacobson
2001], el ciclo de vida del desarrollo de software se basa en una combinación 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
información (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 pequeño proyecto en el que se ejecutarán las fases de requisitos, análisis, diseño
implementación y pruebas.
Dentro de cada una de ellas, existirán las iteraciones necesarias para revisar cada artefacto hasta
que se complete el incremento y se pueda continuar con el siguiente.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Básicamente los modelos tres tipos de modelos explicados a continuación, son la base de MDA
[OMG 2003a]:
Modelos independientes del cómputo (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 hablaría de las entidades persistentes Usuario, Ejemplar, Préstamo, etc.
Modelos independientes de la plataforma (PIM): son modelos con un alto nivel de abstracción que
son independientes de la tecnología 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
hablaría de servicios de la aplicación de la biblioteca, de los objetos del negocio Usuario, Ejemplar,
Préstamo, etc.
Modelos específicos de plataforma (PSM): especifican el sistema en términos de las
construcciones que se van a implementar a la hora de desarrollar. Un modelo PIM puede
generar distintos modelos PSM, en función de las tecnologías utilizadas. Así, un PSM de
una biblioteca hablaría de JSP [SUN JSP], conexiones JDBC [SUN JDBC], etc.
Código: la fase final del desarrollo es transformar cada PSM en código. Como cada PSM es
relativo a una tecnología determinada esta transformación es, teóricamente,
relativamente sencilla.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Proceso unificado de desarrollo. Diagrama de incrementos e iteraciones
MDA define los modelos PIM, PSM y el código, así como la manera de relacionarse unos con otros.
Los modelos PIM se deben crear, después se deben transformar en uno o varios PSM (el paso más
complejo en los desarrollos MDA) y finalmente transformarlo en código.
La novedad de MDA frente al desarrollo tradicional, es que las transformaciones se hacen se
pueden hacer mediante herramientas que las ejecutan de forma automática. En concreto, la
mayor aportación de MDA y su mayor beneficio, es la transformación de modelos PIM a modelos
PSM.
Las transformaciones, aunque es deseable que se realicen de forma automática 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 tecnología, sólo será necesario
generar el PSM apropiado para la nueva plataforma. Sólo es necesario tener una herramienta que
realice la transformación, que puede encontrarse en el mercado para tecnologías con una alta tasa
de uso o que haya que construirla, en caso de ser una tecnología poco utilizada.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Interoperabilidad MDA mediante puentes
Como hemos visto más arriba, un PIM puede generar uno o varios PSM, en función de las
plataformas en las que se vaya a implantar el sistema. El conjunto resultante de PSM, sin embargo,
no estarán directamente comunicados entre ellos. Para conseguir la interoperatibilidad, hay que
transformar conceptos de una plataforma en los de otra, construyendo lo que en terminología
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 técnicos de ambas plataformas, ya que sin ellos no se
podrían definir las transformaciones, podemos obtener toda la información necesaria para
construir los puentes entre los dos PSM. Lo mismo ocurre a nivel de código.
Infraestructura común
La infraestructura UML se define por la InfrastructureLibrary que especifica el núcleo (core) del
metalenguaje. Define constructores básicos y conceptos comunes que se reutilizan para definir
varios metalenguajes, tales como MOF o CWM, a parte del propio UML. También tiene el objetivo
de alinear arquitectónicamente MOF y UML con el fin de poder reutilizar los mismos metamodelos
para ambos lenguajes. Por último, esta librería también permite una personalización de UML
mediante perfiles que facilitan la creación de nuevos lenguajes basados en el mismo core.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
La InfrastructureLibrary es un paquete que está compuesto a su vez por los paquetes Core y
Profiles.
El paquete Core es un metamodelo completo diseñado para una alta reusabilidad, de manera que
permita extender metamodelos descritos en MOF en el mismo metanivel, mediante la utilización o
especialización de sus metaclases. Tal es el caso de UML, CWM y MOF que todas dependen de un
núcleo común, tal y como se muestra en la Figura 3-1 ([OMG 2007a]). El paquete Core, por lo
tanto, es el corazón que sustenta toda la arquitectura de la aproximación MDA.
Papel del núcleo común
El paquete Profiles depende del paquete Core y define los mecanismos que se usan para
personalizar metamodelos existentes centrándose en plataformas específicas 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 específico y
personalizado. Se puede considerar como un mecanismo de extensión ligero de los metamodelos
definidos con MOF alternativo al metamodelado, ya que es mucho más cómodo ampliar el
metamodelo que crear uno completamente nuevo. Además 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 definición original.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Extensión 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 explícita a Metaclase2 que anula la referencia al metamodelo. La
aplicación de MiPerfil sobre algún modelo basado en MiMetamodelo, mostrará instancias de
Metaclase2 (porque está explícitamente referenciada mediante una referencia de metaclase).
También estarán 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
permanecerán ocultas.
Unified Model Language (UML)
UML [Booch 2005] es un lenguaje estándar para visualización, especificación, construcción y
documentación de sistemas software y otros sistemas no software. Representa una colección de
buenas prácticas que proporcionan un éxito acreditado en el modelado de grandes y complejos
sistemas [OMG 2005a]. Fusiona conceptos de las metodologías 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 común, sencillo y
ampliamente utilizado por los usuarios de éstos y otros métodos 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 fácil de usar y visual para el desarrollo
de modelos.
Proporcionar mecanismos de especialización y extensión de conceptos elementales del
Core.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Soportar especificaciones independientes de lenguajes de programación y procesos de
desarrollo específicos.
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 prácticas en los procesos de desarrollo.
La especificación del lenguaje UML está basada en la aproximación de metamodelado, por lo que
se sitúa en el nivel M2 de la arquitectura MDA. La definición de UML está basada en los siguientes
principios de diseño [OMG 2007a]:
Modularidad: que se consigue agrupando constructores en paquetes y organizando
aspectos comunes en metaclases.
Estratificación: la división 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 núcleo (core) del metalenguaje, de los constructores de alto nivel que los
usan. En segundo lugar, el patrón de la arquitectura de cuatro capas se aplica para separar
aspectos en diferentes niveles de abstracción.
División 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 específicos.
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 sería ya un metamodelo diferente.
Reusabilidad: la reusabilidad se consigue mediante librerías 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 verán más
adelante.
El metamodelo de UML se define en UML Superstructure [OMG 2007b], metamodelo descrito en
MOF y que a su vez está basado también 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 estáticos (o de
estructura) y dinámicos (o de comportamiento).
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 añadiendo 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 propósitos o
necesidades concretas, tales como los demandados por diferentes plataformas (como pueden ser
J2EE o .NET) o dominios de aplicación (como los de tiempo real, modelado de procesos de
negocio, etc.).
[OMG 2007a] señala varias razones por las que se puede necesitar personalizar un metamodelo:
Disponer de una terminología propia que se adapte a una plataforma particular o un
dominio de aplicación.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Dotarse de una sintaxis para construcciones que no cuentan con una notación propia
(como es el caso de las acciones).
Obtener nuevas notaciones para símbolos ya existentes para adaptarlas al dominio de
aplicación.
Añadir semántica no especificada en el metamodelo
Añadir restricciones al metamodelo de manera que acoten el uso del metamodelo y sus
constructores.
Añadir información útil para la realización 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. Gráficamente, los estereotipos se definen dentro de cajas estereotipas
«stereotypes» que se asocian con las metaclases que va a extender, según 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 sólo 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
restricción de que si dos o más clases están unidas por una asociación coloreada, el color de las
clases debe coincidir con el de la asociación. 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 asociación
que haya sido estereotipada como Weighed. Los valores etiquetados se representan como
atributos de la clase que define el estereotipo.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
EJEMPLO DE PERFIL UML
Meta Object Facility (MOF)
MOF es un estándar de OMG que provee de un marco de trabajo de gestión 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 tecnologías estandarizadas por OMG (UML, el
propio MOF, CWM, SPEM, XMI y varios perfiles UML) usan MOF y sus tecnologías derivadas
para un intercambio dirigido por metadatos y la manipulación de los mismos. Así mismo, MOF
introduce el concepto de los modelos independientes de plataforma de metadatos, además del
mapeo de estos PIM a plataformas específicas.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Meta niveles de MOF y UML
Como se muestra en la Figura anterior, en la arquitectura de metamodelado de cuatro capas MOF
estaría 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 versión, MOF ha estado
íntimamente ligado a UML, debido al alineamiento arquitectónico derivado de compartir el mismo
core. Uno de los mayores éxitos de la infraestructura común 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 común la InfrastructureLibrary, incluye los
siguientes beneficios:
Simplifica las reglas para el modelado de metadatos
Las tecnologías 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 fácilmente Además de estos
beneficios, MOF incluye una serie de paquetes que facilitan la consecución de las
capacidades de reutilización de MOF desde otros modelos o metamodelos. Estos paquetes
son los descritos a continuación:
Reflection: que extiende un modelo con la habilidad de ser autodescriptivo.
Identifiers: que provee una extensión para objetos del metamodelo identificados
excepcionalmente, sin contar con el dato del modelo que puede ser sujeto de cambio.
Extensión: un simple significado para extensiones de elementos del modelo con el par
nombre – valor.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Ahora veamos un esquema completo de MDA
Ejercicios de autoevaluación
Explique claramente por medio de un cuadro paralelo las ventajas, desventajas, diferencias y
características sobre los diferentes FrameWorks.
Aplique el modelo MDA completamente al ejercicio planteado para la Unidad 1
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
6. ASPECTOS
OBJETIVO GENERAL
Aprender a definir los conceptos entre Aspectos y un lenguaje orientado por objetos.
OBJETIVOS ESPECÍFICOS
Identificar e implementar los parámetros sobre diferenciadores entre los lenguajes por
objetos y lenguajes por aspectos
Crear ambientes de desarrollo aplicando las metodologías por aspectos
Apropiar las principales características de las Bases de Datos orientadas a aspectos.
6.1. Relación de conceptos
6.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 asimilación
¿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?
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
6.3. Definiciones Básicas
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 través 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 definición para tales lenguajes sería: Los LOA son aquellos
lenguajes que permiten separar la definición de la funcionalidad pura de la definición 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 fácilmente 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 abstracción y composición pueden verse como agrupados bajo una misma
raíz. Esa raíz tendría la forma de un procedimiento generalizado. Los métodos de diseño que han
surgido para los LPG tienden a dividir el sistema en unidades de comportamiento o funciones. A
este estilo se lo conoce como descomposición funcional (si bien la naturaleza exacta de la
descomposición funcional difiere entre los paradigmas, para los propósitos 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 aún deban ser coordinadas. Esto se debe a que tienen un comportamiento
en común. Al proveer los LPG solamente un único medio de composición, 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 código.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 fácilmente 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 semántica de los
componentes en forma sistemática (Ejemplo: sincronización, manejo de memoria, distribución,
etc.)
A la luz de estos términos, 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 través 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 código. Los aspectos son la unidad básica de la programación orientada a aspectos.
Una definición más 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 diseño como en la de implementación. Un aspecto de diseño es una unidad
modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de
implementación es una unidad modular del programa que aparece en otras unidades modulares
del programa. Dicha definición 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 implementación basada en los LPG versus implementación basada en POA.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Implementación POA versus LPG
Fundamentos de la POA
Los tres principales requerimientos de la POA son:
Un lenguaje para definir la funcionalidad básica, conocido como lenguaje base o
componente. Podría 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 sincronización, RIDL, para distribución, AspectJ, de propósito general.)
Un tejedor de aspectos (Weaver), que se encargará de combinar los lenguajes. Tal proceso
se puede retrasar para hacerse en tiempo de ejecución o en tiempo de compilación.
Los lenguajes orientados a aspectos definen una nueva unidad de programación de software para
encapsular aquellos conceptos que cruzan todo el código.
Estructura general
La estructura de una implementación basada en aspectos es análoga a la estructura de una
implementación basada en los LPG.
Una implementación basada en LPG consiste en:
Un lenguaje.
Un compilador o intérprete para ese lenguaje.
Un programa escrito en ese lenguaje que implemente la aplicación.
Veamos a continuación una gráfica de los LPG
Una implementación basada en POA consiste en:
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
El lenguaje base o componente para programar la funcionalidad básica.
Uno o más lenguajes de aspectos para especificar los aspectos.
Un tejedor de aspectos para la combinación de los lenguajes.
El programa escrito en el lenguaje componente que implementa los componentes.
Uno o más programas de aspectos que implementan los aspectos.
Visualicemos, por medio de una gráfica
Estructura de POA
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Desarrollo orientado a aspectos
Diseñar 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 básica
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 aplicación basada en aspectos consiste de tres pasos:
1- Descomposición de aspectos: es descomponer los requerimientos para distinguir aquellos que
son componentes de los que son aspectos.
2- Implementación de requerimientos: implementar cada requerimiento por separado.
3- Recomposición: dar las reglas de recomposición que permitan combinar el sistema completo.
En un reporte técnico de la Universidad de Virginia, se establece que muchos de los principios
centrales a la POO son ignorados dentro del diseño orientado a aspectos, como por ejemplo el
ocultamiento de información, debido a que los aspectos tienen la habilidad de violar estos
principios. Para esto se propone una filosofía de diseño 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 característica 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 definición 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 más 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 implementación de dichas interfaces. Al afectar solamente
la implementación de las clases y no sus interfaces, la encapsulación no se rompe. Las clases
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
mantienen su condición 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 información
puede ser violado en cierta forma por los aspectos porque éstos conocen detalles de un objeto
que están ocultos al resto de los objetos.
Sin embargo, no deben manipular la representación interna del objeto más allá de lo que sean
capaz de manipular el resto de los objetos. A los aspectos se les permite tener esta visión especial,
pero debería limitarse a manipular objetos de la misma forma que los demás objetos lo hacen, a
través de la interface.
6.4. Lenguajes orientados a aspectos
A continuación describiremos informalmente algunos lenguajes orientados a aspectos disponibles
actualmente. En la sección 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 característica 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 automáticamente conecta el código base con los
programas de aspectos en puntos de control llamados acciones.
El código que agrega el Esquema del Tejedor invoca, cuando es alcanzado en ejecución, las
acciones correspondientes para permitir la ejecución de los programas de aspectos. Esto permite
una vinculación dinámica con los programas de aspectos, lo cual hace posible modificar en
tiempos de ejecución los programas de aspectos. Sin embargo, esta solución no es lo
suficientemente poderosa como para agregar o reemplazar programas de aspectos en ejecución.
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 aplicación y puede llamar a
métodos de aspectos registrados. Es implementado como una librería dinámica que almacena los
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
aspectos y permite dinámicamente agregar, quitar o modificar aspectos, y mandar mensajes a
dichos aspectos. La comunicación entre el Administrador y el Esquema del Tejedor se logra a
través de un Protocolo de Comunicación entre Procesos que permite registrar aspectos
dinámicamente.
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 implementación. Esta separación permite generar un Esquema de Tejedor para
cualquier lenguaje de aspectos. Este esquema ofrece un puente entre el control de la ejecución y
la ejecución de la acción.
Tomando ventaja de esta redirección se obtiene un modelo de arquitectura para el manejo
dinámico de aspectos.
Su principal aplicación es para la implementación de sistemas distribuidos.
D
D es un ambiente de lenguajes de aspectos para la programación distribuida. Se llama ambiente
de lenguajes, en vez de solamente lenguaje, porque consiste en realidad de dos lenguajes: COOL,
para controlar la sincronización de hilos(threads), y RIDL, para programar la interacción entre
componentes remotos.
Estos dos lenguajes se diseñaron de manera independiente de un lenguaje componente. Sin
embargo establecen un número de condiciones sobre el lenguaje componente.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
El diseño 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 teoría podría ser implementado con C++, Smalltalk, CLOS, Java o Eiffel. Cristina Lopez,
principal diseñadora del lenguaje, implementó D sobre Java llamando al lenguaje resultante DJ.
Con respecto a la herencia, los módulos de aspectos se relacionan con la herencia de clases a
través de simples reglas: Sea C una clase y A el módulo 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 propagación de efectos: A no afecta a ninguna superclase de C.
Redefinición de semántica: A redefine completamente cualquier módulo de aspecto del
mismo tipo definido en una superclase de C.
No hay ninguna relación entre A y los módulos de aspectos de las superclases de C.
- Herencia de coordinación: A afecta todas las subclases de C que no tienen asociado un módulo
de aspecto del mismo tipo. A no afecta los nuevos métodos definidos en una subclase de C. Si un
método mdeclarado en C es redefinido por una subclase de C sin asociarle otromódulo de aspecto
del mismo tipo entonces A también es el aspecto para ese método.
No es posible para los módulos de aspectos referir a otro módulo de aspecto, como consecuencia
no es posible establecer ninguna relación entre los módulos de aspectos, incluyendo a la herencia.
COOL
COOL (COOrdination aspect Language) es un lenguaje de aspectos de dominio específico para
tratar con la exclusión mutua de hilos, sincronización, suspensión y reactivación de hilos.
Un programa COOL consiste de un conjunto de módulos coordinadores. Los módulos
coordinadores, o directamente coordinadores, se asocian con las clases a través del nombre. Un
mismo coordinador puede coordinar a más de una clase. La unidad mínima de sincronización es el
método. La declaración de un coordinador describe la estrategia de coordinación. Los
coordinadores no son clases: utilizan un lenguaje diferente, no pueden ser instanciados y sirven
para un propósito muy específico. Los coordinadores se asocian automáticamente con las
instancias de clases que coordinan en tiempo de instanciación, y durante el tiempo de vida de los
objetos esta relación tiene un protocolo bien definido.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
El cuerpo de un coordinador contiene declaración de variables de condición y ordinarias, un
conjunto de métodos auto-exclusivos, varios conjuntos de métodos mutuamente exclusivos y
manejadores de métodos. Los métodos nombrados en el cuerpo deben ser métodos válidos de las
clases coordinadas.
Un coordinador asociado a una clase C tiene la siguiente visibilidad:
Todos los métodos públicos, protegidos y privados de C.
Todos los métodos no privados de las superclases de C.
Todas las variables privadas, protegidas y públicas de C.
Todas las variables no privadas de las superclases de C.
La siguiente figura describe el protocolo de comunicación entre un coordinador y un objeto:
Protocolo de comunicación de un coordinador en COOL
RIDL
RIDL (Remote Interaction and Data transfers aspect Language) es un lenguaje de aspectos de
dominio específico que maneja la transferencia de datos entre diferentes espacios de ejecución.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Un programa RIDL consiste de un conjunto de módulos de portales. Los módulos de portales o
directamente portales se asocian con las clases por el nombre.
Un portal es el encargado de manejar la interacción remota y la transferencia de datos de la clase
asociada a él, y puede asociarse como máximo a una clase. La unidad mínima de interacción
remota es el método.
Protocolo de comunicación de un portal en RIDL
Tenemos otros lenguajes POA
ASPECTC
ASPECTS
ASPECTC++
MALAJ
HYPERJ
A continuación veamos un resumen de estas herramientas
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
Ejercicio de autoevaluación
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. Interacción entre aspectos en aplicaciones AOP (EA, IMP)
2. ¿Qué es un aspecto a nivel arquitectónico? (EA, ARQ)
3. Los aspectos identificados en la especificación de requisitos son luego aspectos a nivel
arquitectónico?
4. Significado de las relaciones de weaving en el modelo de objetivos. ¿Qué técnicas pueden ser
utilizadas para especificar el weaving en early aspects.
5. Identificación de aspectos en la especificación de requisitos/objetivos.
6. Conceptos reales de DSOA ¿Están demasiado influenciados por AspectJ?
7. Derivación de arquitecturas (¿AO?) de una especificación orientada a aspectos.
8. ¿Qué es un aspecto a nivel arquitectónico? (EA, ARQ)
9. Los aspectos identificados en la especificación de requisitos son luego aspectos a nivel
arquitectónico?
10. Varias opciones de diseño vivas a lo largo del ciclo de vida. ¿Ventajas?
11 Aspectos asociados a conectores Vs aspectos asociados a componentes
12. ¿Son diferentes los aspectos arquitectónicos?
13. Derivación de arquitecturas (¿AO?) de una especificación orientada a aspectos.
14. Hasta qué nivel MDA se mantiene la separación?
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
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 diseñar y desarrollar software para la web, los Principios planteados para ello
en éste módulo, son determinantes de su eficiencia, eficacia y funcionalidad
Traer a la memoria: Que las reglas del negocio están determinadas por las necesidades y
parámetros sobre los cuales debe levantarse el diseño del software a desarrollar.
Tenga presente: Los diferentes diagramas mostrados son solo guías de solución 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 específicos, pero no constituyen como tal una solución estandarizada a una situación de
desarrollo.
Traer a la memoria: Que los diferentes procesos y patrones de modelamiento serán efectivos en
la medida que se usen en los escenarios más adecuados para ello.
Tenga presente: UML es un lenguaje para interpretar sistemas mediante gráficos o texto
obteniendo modelos explícitos para a la comunicación durante el desarrollo al ser estándar, los
modelos podrán ser interpretados por personas que no participaron en su diseño
Tener en cuenta: Que una restricción se representa como una cadena encerrada entre llaves y
colocada junto al elemento asociado o conectada a los elementos con relación 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 colección de elementos.
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
8. GLOSARIO
FRAMEWORK: Estructura software compuesta de componentes personalizables e intercambiables
UML: Lenguaje de Modelamiento Unificado (Unified Model Language)
MOF: Estándar de OMG que provee un marco de trabajo de gestión de metadatos
JPAL: Junction Point Aspect Language
D: ambiente de lenguajes de aspectos para la programación distribuida
COOL: Coordination aspect Language, Coordinación de Aspectos del lenguaje
RIDL: Remote Interaction and Data transfers aspect Language: Interacción Remota y Transferencia
de Datos en lenguajes orientados a aspectos.
LOA: Lenguaje de programación Orientado a Aspectos
POA: Programación Orientada a Aspectos
MALAJ: Modularización de aspectos de sincronización y relación
Dirección de Educación a Distancia y Virtual
Ingeniería de Sistemas
Asignatura: Arquitectura del Software
Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington
Página Web: www.remington.edu.co - Medellín - Colombia
9. BIBLIOGRAFÍA
SÁNCHEZ PÉREZ Javier, Metodologías de Desarrollo Software Facultad de Informática, 1998,
GARCÍA MOLINA Jesús Ignacio, Departamento de Informática y Sistemas, 2004, Univ. De Murcia.
REYNOSO Billy, Arquitectura para distribución y agregación: 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 producción, 2011, CESDE.
WEBGRAFÍA
www.monografías.com, Arquitectura de Desarrollo de Software, tomado el 4 de Noviembre 2011
www.wikipedia.com
www.Lawebdelprogramador.com