07 arquitectura de software

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


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]

[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

[email protected]

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]

mailto:[email protected]










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.






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






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

7. PISTAS DE APRENDIZAJE ................................................................................................. 134

8. GLOSARIO ...................................................................................................................... 135

9. BIBLIOGRAFÍA ................................................................................................................ 136






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






2. EL MODELAMIENTO UNIFICADO

OBJETIVO GENERAL

Dar a conocer las generalidades y conceptos de UML y el desarrollo de aplicaciones Web para la

infraestructura de un proyecto de software.


Evidenciar las 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.






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?






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.






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.






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






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.






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í.






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.






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.






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






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.






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.






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.






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:






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






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.






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






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






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






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






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:






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






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






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






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.






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).






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


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.2. Prueba Inicial




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.






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.






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.






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:






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






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






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






Semántica

Restricciones (constraints)

Evolución

Propiedades no funcionales

Conectores

Interfaz

Tipos

Semántica

Restricciones

Evolución


Configuraciones arquitectónicas

Comprensibilidad

Composicionalidad

Heterogeneidad

Restricciones

Refinamiento y trazabilidad

Escalabilidad

Evolución

Dinamismo


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.






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.






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.






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.






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.






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.






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.)






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.






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:






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.






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






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.






¿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).






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).






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






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






Escenario número1.

En el segundo escenario participan dos elementos:

El dispositivo móvil

La aplicación central


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.






4. DEFINICIONES Y PATRONES DE SOFTWARE.

OBJETIVO GENERAL

Apropiar el uso de catálogos de elementos reusables en el diseño de sistemas software


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






4.1. Prueba Inicial




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






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:






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






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).






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() )






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:






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.






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í.

http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art163.asp






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).






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() );






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.






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:






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:






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).






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






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






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();






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 ) {






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






****************************************************************/

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







return null;

}

}

**********************************************************

* Lee un archivo properties donde se indica la clase que debe ser instanciada

***********************************************************

private static String getClase( String nombrePropiedad ) {

try {

// Carga de propiedades desde archivo

if ( !propiedadesCargadas ) {

FileInputStream archivo = new FileInputStream(

"src/factoriaJuegosNewInstanceProperties/propiedades.properties" ); prop.load( archivo

); // Cargo propiedades propiedadesCargadas = true;

}

// Lectura de propiedad String nombreClase = prop.getProperty( nombrePropiedad, "");

if ( nombreClase.length() > 0)

return nombreClase;

return null;

}

catch ( FileNotFoundException e) { // No se puede encontrar archivo


return null;

}

catch ( IOException e) { // Falla load()


return null;

}

catch (Exception e) {


return null;

}

}

}

En el archivo properties tenemos:

dado=factoriaJuegosNewInstanceProperties.JuegoDelDado

moneda=factoriaJuegosNewInstanceProperties.JuegoDeMoneda






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.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html






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).






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 {






//// 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;






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;






}

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;






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;


// 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";


ResultSet rs = sentencia.executeQuery( orden );

while (rs.next()) {

cli = new Cliente( rs.getString("codigo"), rs.getString("nombre"),

rs.getString( "ape1" ), rs.getString( "ape2" ),

(rs.getString( "edad" )==null ? null : new Integer(rs.getInt( "edad" ))));

vecClientes.add( cli );

}

sentencia.close();







return vecClientes;

}

En la siguiente figura se muestra la 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 {

http://www.proactiva-calidad.com/java/patrones/factoria.html






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

archivo properties

return (InterfaceDAO) clase.newInstance(); // Creo una instancia

}

catch (ClassNotFoundException e) { // No existe la clase


return null;

}

catch (Exception e) { // No puedo instanciar la clase


return null;

}

}

/*****************************************************************

* Lee un archivo properties donde se indica la clase que debe ser instanciada

*****************************************************************/

private static String getClase( String nombrePropiedad ) {

String nombreClase = null;

try {

//// Carga de propiedades desde archivo

if ( !propiedadesCargadas ) {

FileInputStream archivo = new FileInputStream ( "src/dao /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


}

catch ( IOException e) { // Falla load()


}

catch (Exception e) {







}

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());

}






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

http://www.proactiva-calidad.com/java/servlets/servlet_jdbc.html






*****************************************************************/

public Vector selectConVentas( String condicion ) throws SQLException {

Vector vecClientes = new Vector();

Venta ven;

Cliente cliAnterior = null, cliActual = null;


//// 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";


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 );






}

}

sentencia.close();


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);

}






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:






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) {


}

}

}

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:






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


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.






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.


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.2. Prueba Inicial




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.






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






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.






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.






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.






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






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.






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.






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.






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.






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.






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.






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.






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).






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.






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.






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.






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.






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






6. ASPECTOS

OBJETIVO GENERAL

Aprender a definir los conceptos entre Aspectos y un lenguaje orientado por objetos.


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.2. Prueba Inicial




¿Qué significan las siglas POA, LOA?

¿Qué propiedades debe satisfacer el LOA?

¿En el este contexto y en sus palabras defina lo que es un aspecto?

¿Qué lenguajes orientados a aspectos puedes indicar?






6.3. Definiciones 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.






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.






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:






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






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






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






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.






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.






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.






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







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?






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.






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






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

http://www.wikipedia.com/

http://www.lawebdelprogramador.com/

07 arquitectura de software

Documents

Transcript of 07 arquitectura de software