arquitectura_de_software.pdf

CORPORACIN UNIVERSITARIA REMINGTON

DIRECCIN PEDAGGICA

Direccin de Educacin a Distancia y Virtual

Este material es propiedad de la Corporacin Universitaria Remington (CUR),

para los estudiantes de la CUR en todo el pas.

2012

FACULTAD DE CIENCIAS BSICAS E INGENIERIA

Ingeniera de Sistemas Asignatura: Arquitectura del Software


Ingeniera de Sistemas

Asignatura: Arquitectura del Software

Corporacin Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington

Pgina Web: www.remington.edu.co - Medelln - Colombia

CRDITOS

El mdulo de estudio de la asignatura Arquitectura del Software es propiedad de la Corporacin Universitaria Remington. Las imgenes fueron tomadas de diferentes fuentes que se relacionan en los derechos de autor y las citas en la bibliografa. El contenido del mdulo est protegido por las leyes de derechos de autor que rigen al pas. Este material tiene fines educativos y no puede usarse con propsitos econmicos o comerciales.

AUTOR

Edilberto Restrepo Restrepo Magister en Educacin Superior de la Pontificia Universidad Javeriana, Especialista en Gerencia de Proyectos de la Universidad del Tolima, Administrador de Empresas y Tecnlogo en Administracin de Redes de Datos. Con 18 Aos de experiencia como docente y Diseador de asignaturas en las reas de Lgica y Programacin, Mantenimiento de computadores, Administracin de Redes de Datos, asesora de proyectos informticos y productivos de emprendimiento. En instituciones como CESDE, Universidad San Martin, Universidad Cooperativa de Colombia, Comfenalco, Comfama y Microempresas de Antioquia. Actualmente coordinador de la Unidad de formacin en la corporacin Universitaria Remington. Con ponencias sobre procesos evaluativos, Cesde 2005, Aprendizajes colaborativos, Remington, 2011. Actualmente miembro del grupo de investigacin AVICUR. [email protected]

[email protected]

Nota: el autor certific (de manera verbal o escrita) No haber incurrido en fraude cientfico, plagio o vicios de autora; en caso contrario eximi de toda responsabilidad a la Corporacin Universitaria Remington, y se declar como el nico responsable.

RESPONSABLES

Dr.Jorge Mauricio Seplveda Castao

[email protected]

Director de la Facultad de Ciencias Bsicas e Ingeniera

Toms Vsquez Uribe Director Educacin a Distancia y Virtual tvasquez @remington.edu.co Anglica Ricaurte Avendao Coordinadora de Remington Virtual (CUR-Virtual) [email protected]






GRUPO DE APOYO

Personal de la Unidad de Remington Virtual (CUR-Virtual) EDICIN Y MONTAJE Primera versin. Febrero de 2011.Segunda versin Marzo 2012

Derechos Reservados

Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia.






TABLA DE CONTENIDO

1. MAPA DE LA ASIGNATURA ................................................................................................. 9

2. EL MODELAMIENTO UNIFICADO ....................................................................................... 10

2.1. Relacin de conceptos ............................................................................................................ 11

2.2. Prueba Inicial ........................................................................................................................... 11

2.3. Tcnicas comunes y Avanzadas de modelado con UML. ........................................................ 12

2.4. Reglas del Negocio .................................................................................................................. 25

2.5. Principios de desarrollo de aplicaciones Web......................................................................... 26

2.6. La Arquitectura en el Proceso Unificado de Desarrollo .......................................................... 29

3. LA ARQUITECTURA DE SOFTWARE. ................................................................................... 37

3.1. Relacin de conceptos ............................................................................................................ 37

3.2. Prueba Inicial ........................................................................................................................... 38

3.3. Modelos de arquitectura de software. ................................................................................... 38

3.4. Enfoques arquitectnicos de software ................................................................................... 47

3.5. Modelado Arquitectnico en UML 2.0 .................................................................................... 51

4. DEFINICIONES Y PATRONES DE SOFTWARE. ...................................................................... 63

4.1. Prueba Inicial ........................................................................................................................... 64

4.2. Definiciones Bsicas ................................................................................................................ 64

4.3. Catlogos de Patrones ........................................................................................................... 68

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

5.1. Relacin de conceptos .......................................................................................................... 101

5.2. Prueba Inicial ......................................................................................................................... 102

5.3. Definicin y Estructura del Frameworks .............................................................................. 102

5.4. MDA (Model Driven Architecture) ........................................................................................ 106

6. ASPECTOS ...................................................................................................................... 121

6.1. Relacin de conceptos .......................................................................................................... 121

6.2. Prueba Inicial ......................................................................................................................... 121

6.3. Definiciones Bsicas .............................................................................................................. 122






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

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

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

9. BIBLIOGRAFA ................................................................................................................ 136






1. MAPA DE LA ASIGNATURA

ARQUITECTURA DEL SOFTWARE

OBJETIVO GENERAL DEL MODULO

En un mundo globalizado, donde cada da desaparecen las barreras comerciales y culturales, la calidad se

torna en necesidad, pues permite competir con mayores posibilidades de xito. A pesar de que la

programacin de sistemas no haba sido concebida desde la perspectiva de la calidad, la calidad en

productos de software ha tenido un auge importante en la sociedad informatizada de hoy, La calidad del

software permite elaborar actividades sistemticas que se necesitan para lograr software con calidad, la

Calidad involucra actividades de evaluaciones, auditorias y revisiones, estndares que se aplicaran al

proyecto, mecanismos de medida (mtricas), mtodos y herramientas de anlisis, diseo, programacin y

prueba, documentacin y control.

OBJETIVO GENERAL

Apropiar en el estudiante conceptos y prcticas de Arquitectura y Diseo de Software aplicables a

escenarios de la vida real.

OBJETIVOS ESPECFICOS

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

infraestructura de un proyecto web.

Presentar de manera prctica las diferentes metodologas y buenas prcticas para documentacin y

evaluacin de arquitecturas de software

Apropiar el uso de catlogos de elementos reusables en el diseo de sistemas software

Identificar las caractersticas de un framework para Web y apropiarse del modelado bajo el enfoque

MDA.

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

UNIDAD 1

Mediante la

conceptualizacin

y aplicacin en

situaciones

problema, el

estudiante podr

apropiarse de los

procesos de

modelamientos

UML.

UNIDAD 2

El estudiante

podr plantear

propuestas

metodolgicas

para la

documentacin

de las prcticas

productivas de

desarrollo de

software.

UNIDAD 3

Mediante el

abordaje y

aplicacin de los

diferentes

patrones de

elementos

reusables el

estudiante

obtendr criterios

de aplicacin en

contextos

diversos

UNIDAD 4

Identificando las

caractersticas de

los frameworks, y

modelado MDA, el

estudiante

plantear solucin

a necesidades

reales de

desarrollo de

software

UNIDAD 5

Conociendo los

conceptos sobre la

programacin

orientada a aspectos, el

estudiante podr

determinar las

situaciones en las

cuales sea ms

pertinente su

aplicacin en el

desarrollo de software






2. EL MODELAMIENTO UNIFICADO

OBJETIVO GENERAL

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

infraestructura de un proyecto de software.


Evidenciar las tcnicas comunes y avanzadas del Modelamiento UML mostrando

grficamente la arquitectura de un proyecto web.

Determinar de forma adecuada las polticas o reglas del negocio que rigen a una empresa

para hacerlo escalable en el tiempo.

Argumentar de forma clara y precisa cada una de las etapas empleadas en el Proceso

Unificado de Desarrollo.

Proponer modelamiento de negocios adecuado y apropiado a cualquier escenario de la

vida real.






2.1. Relacin de conceptos

2.2. Prueba Inicial

Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes

preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su

grado de asimilacin

a) Qu entiende usted por Modelado UML?

b) Qu tcnicas de modelamiento puedes describir?

c) Cmo se dividen los bloques de construccin?

d) Qu entiende usted por clase, Interfaz, Colaboracin, 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. Tcnicas comunes y Avanzadas de modelado con UML.

Notas

Una nota es un smbolo grfico utilizado para suministrar restricciones o comentarios vinculados a

un elemento o a una coleccin de elementos. Grficamente, una nota se representa como un

rectngulo con la esquina superior derecha doblada, junto con un comentario textual o grfico.

El UML proporciona todas las herramientas necesarias para visualizar, especificar, construir y

documentar los artefactos de un rango amplio de sistemas completos de software. Tambin

podemos encontrar en algunas ocasiones de otros elementos adicionales al UML para poder

modelar un escenario que se adapte a nuestras necesidades. Un lenguaje es usado o empleado

para comunicar una idea de forma clara y precisa para cualquier sistema de informacin.

En UML utilizamos notas para dar a entender una idea clara sobre algo y por medio de ellas

explicamos ideas que de forma grfica se hace difcil. Las notas pueden representar artefactos,

para hacer ms atractivo del ciclo de vida en el desarrollo de software, tambin como los

requerimientos solicitados por el usuario, o pueden representar simplemente observaciones en

forma libre, revisiones, o explicaciones.

El UML proporciona la nota como una representacin grfica para incluir comentarios o

restricciones; por medio de las notas se permite realizar enlaces a archivos. En la Figura 1 tenemos

un ejemplo de una nota en UML.

Estereotipos: Un estereotipo ampla el vocabulario UML, permitiendo crear nuevos tipos de

bloques de construccin similares a los existentes pero especficos para tu problema.

Grficamente, un estereotipo se representa con un nombre encerrado entre pico parntesis y

colocado arriba del nombre de otro elemento. Como una opcin, el elemento estereotipado

puede ser representado usando un nuevo icono asociado con el estereotipo.

Los estereotipos, valores etiquetados y las restricciones son los mecanismos, proporcionados por

el UML, utilizados para aadir nuevos bloques de construccin, crear nuevas propiedades y

especificar semnticas nuevas respectivamente. Por ejemplo, si ests modelando una red, puedes

necesitar smbolos para los enrutadores y los concentradores; puedes usar nodos estereotipados

para hacer que estos elementos aparezcan como bloques primitivos de construccin.

Similarmente, si eres parte del equipo responsable del ensamble, de la prueba y de la liberacin,

puedes conservar registros con respecto al nmero de versin y resultados de la prueba para cada

subsistema. Puedes usar valores etiquetados para aadir informacin a tus modelos. Finalmente,

si ests modelando con dificultad sistemas en tiempo real, puedes adornar tus modelos con

informacin de tiempo presupuestal y lneas muertas; puedes usar restricciones para capturar

estos requerimientos de tiempo.






Ilustracin sobre Estereotipos, Valores etiquetados y Restricciones.

Valor etiquetado:Un valor etiquetado ampla las propiedades de un elemento UML, permitiendo

crear nueva informacin en lo que respecta a la especificacin del elemento. Grficamente, un

valor etiquetado se representa como una cadena encerrada entre llaves y colocada bajo el nombre

de otro elemento.

Restriccin: Una restriccin ampla la semntica de un elemento UML, permitiendo aadir nuevas

reglas, o modificar las existentes. Grficamente, una restriccin se representa como una cadena

encerrada entre llaves y colocada junto al elemento asociado o, conectada a el(los) elemento(s)

con relacin de dependencia. Como una alternativa, puedes incluir una restriccin en una nota.






Tcnicas avanzadas de modelado con UML

Primero comencemos haciendo una diferencia entre Metodologa y Modelo, Una metodologa es

aquella gua que se sigue a fin de realizar las acciones propias de una investigacin. En trminos

ms sencillos se trata de la gua que nos va indicando qu hacer y cmo actuar cuando se quiere

obtener algn tipo de investigacin. Es posible definir una metodologa como aquel enfoque que

permite observar un problema de una forma total, sistemtica, disciplinada y con cierta disciplina.

Al intentar comprender la definicin que se hace de lo que es una metodologa, resulta de suma

importancia tener en cuenta que una metodologa no es lo mismo que la tcnica de investigacin.

Las tcnicas son parte de una metodologa, y se define como aquellos procedimientos que se

utilizan para llevar a cabo la metodologa, por lo tanto, como es posible intuir, es uno de los

muchos elementos que incluye.

En el contexto de la investigacin son muchas las metodologas que es posible seguir, sin embargo,

existen 2 grandes grupos que incluyen a otras ms especficas. Se trata de la metodologa de

investigacin cuantitativa y la cualitativa.

La metodologa cuantitativa es aquella que permite la obtencin de informacin a partir de la

cuantificacin de los datos sobre variables, mientras que la metodologa cualitativa, evitando la

cuantificacin de los datos, produce registros narrativos de los fenmenos investigados. En este

tipo de metodologa los datos se obtienen por medio de la observacin y las entrevistas, entre

otros. Como vemos, la diferencia ms importante entre la metodologa cuantitativa y la






cualitativa radica en que la primera logra sus conclusiones a travs de la correlacin entre

variables cuantificadas, y as poder realizar generalizaciones y producir datos objetivos, mientras

que la segunda estudia la relacin entre las variables obtenidas a partir de la observacin en

contextos estructurales y situacionales.

Ahora miremos qu es un modelo: Un modelo es una estructura conceptual que sugiere un marco

de ideas para un conjunto de descripciones que de otra manera no podran ser sistematizadas. De

esta manera, su estructura es diferente de la que se supone existe en el conjunto de fenmenos

de la naturaleza. Para el caso de arquitectura de software usamos el Modelo de UML.

A continuacin veamos la Historia del UML

La notacin UML se deriva y unifica las tres metodologas de anlisis y diseo Orientada a Objeto

ms extendidas:

Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus relaciones.

Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling

Technique).

Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante

la metodologa de casos de uso (use case).

El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational

Software Corporation empezaron a unificar sus mtodos. A finales de 1995, Ivar Jacobson y su

compaa Objectory se incorporaron a Rational en su unificacin, aportando el mtodo OOSE.

De las tres metodologas de partida, las de Booch y Rumbaugh pueden ser descritas como

centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que

componen el sistema, su relacin y colaboracin. Por otro lado, la metodologa de Jacobson es

ms centrada a usuario, ya que todo en su mtodo se deriva de los escenarios de uso. UML se ha

ido fomentando y aceptando como estndar desde el OMG que es tambin el origen de CORBA, el

estndar lder en la industria para la programacin de objetos distribuidos. En 1997 UML 1.1 fue

aprobada por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo

orientado a objetos.

Qu es UML?

UML es el primer mtodo en publicar una meta-modelo en su propia notacin, incluyendo la

notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de una

meta-modelo auto-referencial, cualquier lenguaje de modelado de propsito general debera ser

capaz de modelarse a s mismo.






UML es un lenguaje estndar que sirve para escribir los planos del software, puede utilizarse para

visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con

gran cantidad de software. UML puede usarse para modelar desde sistemas de informacin hasta

aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real.

UML es solamente un lenguaje por lo que es slo una parte de un mtodo de desarrollo software,

es independiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por

casos de uso, centrado en la arquitectura, iterativo e incremental.

UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, adems es un

lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la

representacin conceptual y fsica del sistema.

UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante grficos o mediante

texto obteniendo modelos explcitos que ayudan a la comunicacin durante el desarrollo ya que al

ser estndar, los modelos podrn ser interpretados por personas que no participaron en su diseo

(e incluso por herramientas) sin ninguna ambigedad. En este contexto, UML sirve para

especificar, modelos concretos, no ambiguos y completos.

Debido a su estandarizacin y su definicin completa no ambigua, y aunque no sea un lenguaje de

programacin, UML se puede conectar de manera directa a lenguajes de programacin como Java,

C++ o Visual Basic, esta correspondencia permite lo que se denomina como ingeniera directa

(obtener el cdigo fuente partiendo de los modelos) pero adems es posible reconstruir un

modelo en UML partiendo de la implementacin, o sea, la ingeniera inversa.

UML proporciona la capacidad de modelar actividades de planificacin de proyectos y de sus

versiones, expresar requisitos y las pruebas sobre el sistema, representar todos sus detalles as

como la propia arquitectura. Mediante estas capacidades se obtiene una documentacin que es

vlida durante todo el ciclo de vida de un proyecto.

El lenguaje UML se compone de tres elementos bsicos, los bloques de construccin, las reglas y

algunos mecanismos comunes. Estos elementos interaccionan entre s para dar a UML el carcter

de completitud y no-ambigedad que antes comentbamos.

Los bloques de construccin se dividen en tres partes:

Elementos, que son las abstracciones de primer nivel.

Relaciones, que unen a los elementos entre s.






Diagramas, que son agrupaciones de elementos.

Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos:

Elementos estructurales.

Elementos de comportamiento.

Elementos de agrupacin

Elementos de anotacin.

Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se

nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia,

relaciones de asociacin, relaciones de generalizacin y relaciones de realizacin.

Se utilizan diferentes diagramas dependiendo de qu, nos interese representar en cada momento,

para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle..., por esta

razn UML soporta un gran nmero de diagramas diferentes aunque, en la prctica, slo se

utilicen un pequeo nmero de combinaciones.

UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones

entre objetos para poder obtener modelos bien formados, estas son reglas semnticas que

afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por otros,

a la integridad de unos elementos con otros y a la ejecucin, o sea la vista dinmica del sistema.

UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidad

adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo unas ciertas

reglas para que en el trasfondo de la adaptacin no se pierda la semntica propia de UML. Dentro

de estos mecanismos estn las especificaciones, que proporcionan la explicacin textual de la

sintaxis y semntica de los bloques de construccin.

Otro mecanismo es el de los adornos que sirven para conferir a los modelos de ms semntica, los

adornos son elementos secundarios ya que proporcionan ms nivel de detalle, que quiz en un

primer momento no sea conveniente descubrir. Las divisiones comunes permiten que los modelos

se dividan al menos en un par de formas diferentes para facilitar la comprensin desde distintos

puntos de vista, en primer lugar tenemos la divisin entre clase y objeto (clase es una abstraccin

y objeto es una manifestacin de esa abstraccin), en segundo lugar tenemos la divisin interfaz /

implementacin donde la interfaz presenta un contrato (algo que se va a cumplir de una

determinada manera) mientras que la implementacin es la manera en que se cumple dicho

contrato.






Por ltimo, los mecanismos de extensibilidad que UML proporciona sirven para evitar posibles

problemas que puedan surgir debido a la necesidad de poder representar ciertos matices, por esta

razn UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques de

construccin, los valores etiquetados, para extender las propiedades un bloque, y las restricciones,

para extender la semntica. De esta manera UML es un lenguaje estndar abierto-cerrado

siendo posible extender el lenguaje de manera controlada.

Elementos Estructurales

Los elementos estructurales en UML, es su mayora, son las partes estticas del modelo y

representan cosas que son conceptuales o materiales.

Clases

Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,

operaciones, relaciones y semntica. Una clase implementa una o ms interfaces. Grficamente se

representa como un rectngulo que incluye su nombre, sus atributos y sus operaciones.

Clase

Describe un conjunto de objetos que comparten los

mismos atributos, mtodos, relaciones y semntica. Las

clases implementan una o ms interfaces.

Interfaz: Una interfaz es una coleccin de operaciones que especifican un servicio de una

determinada clase o componente. Una interfaz describe el comportamiento visible externamente

de ese elemento, puede mostrar el comportamiento completo o slo una parte del mismo. Una

interfaz describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca

su implementacin. Se representa con un crculo, y rara vez se encuentra aislada sino que ms

bien conectada a la clase o componente que realiza.

Interfaz

Agrupacin de mtodos u operaciones que especifican

un servicio de una clase o componente, describiendo su

comportamiento, completo o parcial, externamente

visible. UML permite emplear un crculo para

representar las interfaces, aunque lo ms normal es

emplear la clase con el nombre en cursiva.






Colaboracin: Define una interaccin y es una sociedad de roles y otros elementos que colaboran

para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos

de sus elementos. Las colaboraciones tienen una dimensin tanto estructural como de

comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las

colaboraciones representan la implementacin de patrones que forman un sistema. Se representa

mediante una elipse con borde discontinuo.

Colaboracin

Define una interaccin entre elementos que cooperan

para proporcionar un comportamiento mayor que la

suma de los comportamientos de sus elementos.

Casos de Uso: Un caso de uso es la descripcin de un conjunto de acciones que un sistema ejecuta

y que produce un determinado resultado que es de inters para un actor particular. Un caso de

uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es

realizado por una colaboracin.

Caso de uso

Describe un conjunto de secuencias de acciones que un

sistema ejecuta, para producir un resultado observable

de inters. Se emplea para estructurar los aspectos de

comportamiento de un modelo.

Clase Activa: Es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin por lo y

tanto pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto

que sus objetos representan elementos cuyo comportamiento es concurrente con otros

elementos. Se representa igual que una clase, pero con lneas ms gruesas

Clase activa

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

de ejecucin concurrentes con otros elementos. Las

lneas del contorno son ms gruesas que en la clase

normal

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

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






componente representa tpicamente el empaquetamiento fsico de diferentes elementos lgicos,

como clases, interfaces y colaboraciones.

Componente

Parte fsica y por tanto reemplazable de un modelo,

que agrupa un conjunto de interfaces, archivos de

cdigo fuente, clases, colaboraciones y proporciona

la implementacin de dichos elementos.

Nodos: Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso

Computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad

de procesamiento. Un conjunto de componentes puede residir en un nodo.

Diagramas de Casos de Usos: Muestran un conjunto de casos de uso y actores (tipo especial de

clases) y sus relaciones. Cubren la vista esttica de los casos de uso y son especialmente

importantes para el modelado y organizacin del comportamiento.

Casos de Uso

Muestra un conjunto de casos de uso, los

actores implicados y sus relaciones. Son

diagramas fundamentales en el modelado y

organizacin del sistema.

Diagramas de Secuencia y de Colaboracin: Tanto los diagramas de secuencia como los diagramas

de colaboracin son un tipo de diagramas de interaccin. Constan de un conjunto de objetos y sus

relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista

dinmica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los

Nodo

Elemento fsico que existe en tiempo de ejecucin y

representa un recurso computacional con capacidad de

procesar.






mensajes mientras que los diagramas de colaboracin muestran la organizacin estructural de los

objetos que envan y reciben mensajes. Los diagramas de secuencia se pueden convertir en

diagramas de colaboracin sin prdida de informacin, lo mismo ocurren en sentido opuesto.

Secuencia

Son diagramas de interaccin, muestran un conjunto de

objetos y sus relaciones, as como los mensajes que se

intercambian entre ellos. Cubren la vista dinmica del

sistema. El diagrama de secuencia resalta la ordenacin

temporal de los mensajes, mientras que el de

colaboracin resalta la organizacin estructural de los

objetos, ambos siendo equivalentes o isomorfos. En el

diagrama de colaboracin de la figura de la izquierda, se

puede ver que los elementos grficos no son cajas

rectangulares, como cabra esperar, y en su lugar

encontramos sus versiones adornadas. Estas versiones

tienen como finalidad evidenciar un rol especfico del

objeto siendo modelado. En la figura encontramos de

izquierda a derecha y de arriba abajo un Actor, una

Interfaz, un Control (modela un comportamiento) y una

Instancia (modela un objeto de dato).

Colaboracin

Diagramas de Estados: Muestran una mquina de estados compuesta por estados, transiciones,

eventos y actividades. Estos diagramas cubren la vista dinmica de un sistema y son muy

importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboracin.

Estados

Muestra una mquina de estados, con sus estados,

transiciones, eventos y actividades. Cubren la vista

dinmica de un sistema. Modelan comportamientos

reactivos en base a eventos.

Diagramas de Actividades: Son un tipo especial de diagramas de estados que se centra en mostrar

el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte

dinmica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el

flujo de control entre objetos.






Actividades

Tipo especial de diagrama de estados que

muestra el flujo de actividades dentro de

un sistema.

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

componentes. Cubren la vista de la implementacin esttica y se relacionan con los diagramas de

clases ya que en un componente suele tener una o ms clases, interfaces o colaboraciones

Diagramas de Despliegue: Representan la configuracin de los nodos de procesamiento en tiempo

de ejecucin y los componentes que residen en ellos. Muestran la vista de despliegue esttica de

una arquitectura y se relacionan con los componentes ya que, por lo comn, los nodos contienen

uno o ms componentes.






Diagrama de Despliegue

Veamos un ejemplo de UML con casos de uso

Primero que todo debemos describir el problema sobre el cual vamos a aplicar el Modelo UML

Para mover una caja, el jugador debe colocarse al lado y empujarla. Si la casilla hacia la

que est empujando la caja est libre la caja se mover.

Si el jugador se queda bloqueado, es decir, no puede terminar el nivel, puede reiniciar el

nivel perdiendo una vida.

Cuando el jugador pierde todas sus vidas la partida termina.

Tambin debemos mirar que solicitudes le hacen al sistema para que podamos dar comienzo a

la representacin del Modelo UML.

El sistema debe permitir comenzar una nueva partida y terminarla.

El sistema debe permitir mover al jugador y a las cajas y reiniciar el nivel cuando el usuario

lo solicite.

El sistema deber almacenar varios niveles y cambiar de nivel cuando el usuario complete

el nivel actual

A continuacin miremos los casos de uso resultantes de acuerdo a la descripcin del problema y

los requerimientos que nos hace el usuario dueo del sistema:






2.4. Reglas del Negocio

Esta capa es la encargada de procesar y validar las reglas del negocio, acta como un servidor para

la capa de presentacin y traslada las solicitudes de esta a la capa de datos actuando como cliente

de la misma. As mismo tambin funciona de la misma manera de la forma inversa.

Los servicios de negocios son el puente entre un usuario y los servicios de datos. Responden a

peticiones del usuario (u otros servicios de negocios) para ejecutar una tarea de este tipo.

Cumplen con esto aplicando procedimientos formales y reglas de negocio a los datos relevantes.

Cuando los datos necesarios residen en un servidor de bases de datos, garantizan los servicios de

datos indispensables para cumplir con la tarea de negocios o aplicar su regla. Esto asla al usuario

de la interaccin directa con la base de datos.

Una tarea de negocios es una operacin definida por los requerimientos de la aplicacin, como

introducir una orden de compra o imprimir una lista de clientes. Las reglas de negocio (business

rules) son polticas que controlan el flujo de las tareas.

Como las reglas de negocio tienden a cambiar ms frecuentemente que las tareas especficas de

negocios a las que dan soporte, son candidatos ideales para encapsularlas en componentes que

estn lgicamente separados de la lgica de la aplicacin en s.

Para ayudar a los desarrolladores a construir la lgica de negocio basado en componentes

Windows DNA incluye un conjunto muy poderoso de servicios que se encargan de la comunicacin






en una aplicacin de tres capas. Estos servicios estn altamente integrados unos con otros, bajo un

sistema operativo, y expuestos de forma nica a travs de COM.

El nivel de servicios de negocios es responsable de:

Recibir la entrada del nivel de presentacin

Interactuar con los servicios de datos para ejecutar las operaciones de negocios para los

que la aplicacin fue diseada a automatizar (por ejemplo, la preparacin de impuestos

por ingresos, el procesamiento de rdenes y as sucesivamente).

Enviar el resultado procesado al nivel de presentacin. Algunos de los servicios DNA para

la capa de negocios son los siguientes:

Servicios Web a travs de Microsoft Internet Information Server (IIS)

Transacciones y Servicios de Componentes, Microsoft Transaction Server (MTS)

Servicios Asncronos, Microsoft Message Queue Server (MSMQ).

Server-side Scripting, via Active Server Pages (ASP).

2.5. Principios de desarrollo de aplicaciones Web

Desarrollar un sitio, un proyecto web, no es tan complicado como pareciera. Solo hace falta tener

las ideas claras para hacerlo. A travs de mi experiencia prctica, he aprendido algunas ideas

desde dnde comenzar para desarrollar un sitio o portal web. Los llamo Principios para

desarrollar un proyecto para Internet.

Estos son los Principios:

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

El proyecto debe tener contenido tico.

El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseo grfico como

en usabilidad y contenidos.

El proyecto debe ser esttico y atractivo visualmente.

El proyecto debe transmitir emociones, segn su naturaleza.

El proyecto debe tener herramientas y contenido ms actuales disponibles y estos deben

mantenerse constantemente actualizadas.

El proyecto debe permitir, en la medida de lo posible, interactividad entre el receptor, el

mensaje y la fuente, completando el ciclo de la comunicacin.

El proyecto debe tener enfoque global, es decir, que no debe ser un fin en s mismo, sino

un medio para completar otros objetivos mayores, a la vez que mantiene consistencia con

estos.






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

Es demasiado fcil caer en la trampa de empezar a desarrollar un proyecto teniendo como

prioridad tus propios criterios, o los del desarrollador. Con el tiempo te dars cuenta de que

mientras ms apegado se est a los criterios del desarrollador, ms complejo le ser acceder al

usuario a la informacin, proyecto, servicio, etc.

Son innumerables los casos de esto, los ms tpicos son los portales de la Administracin pblica,

universidades, etc., que hacen que el usuario comience tirndose de los pelos, impaciente, hasta

que al final o bien se da por vencido, o bien termina siendo un experto en informtica solo por

usar una pgina web. Por el contrario, Organizaciones o portales web que manejan una enorme

cantidad de informacin han sido muy exitosos, donde en un abrir y cerrar de ojos el usuario

aprende a manejarlos muy bien, acceder y regresar una y otra vez, dado que los desarrolladores lo

ponen muy fcil. Cmo saber si tu pgina o proyecto web est orientado al usuario? Muy fcil:

pregntaselo a tus usuarios.

El proyecto debe tener contenido tico.

Todo proyecto serio, y que se precie de serlo, debe cuidar que sus contenidos sean ticos.

Tambin innumerables son los casos que puedo poner como ejemplos: contenidos que te ofrecen

hacerte millonario/a de la noche a la maana, te prometen la luna, las estrellas, vida eterna, etc,.

Asimismo, una amonestacin a quienes usan la estrategia del correo electrnico no solicitado

(llmese SPAM), ventanas emergentes no solicitadas (pop ups), banners parpadeantes sin cesar

(aarrgghhhhh!! mis ojos!!!) etc ni hablar de los sitios puramente fraudulentos.

No. No es necesario caer en esas prcticas para atraer lectores o usuarios. As vendas lotera,

coches, dietas, o informacin que puede dar beneficios al lector, tu producto, informacin o

servicio puede ser difundido desarrollando un proyecto ticamente, sin forzar, sin mentir.

Ofreciendo al usuario las ventajas y desventajas de tu informacin, haciendo comparaciones

honestas y, sobre todo, permitindole tomar una decisin.

El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseo grfico como en

usabilidad y contenidos.

Un proyecto puede ser tan complejo como quieras y al mismo tiempo ser simple de usar y leer. Sin

tanta parafernalia, sin tanto grfico. Echa un vistazo a Google.com y vers lo simple que es esa

pgina, que hoy por hoy es la ms visitada de todo el mundo. En definitiva, debes ofrecer a tus

lectores/usuarios la informacin que necesitan sin hacerlos dar vueltas por todos lados para

hallarla, o se irn sin pensarlo dos veces. Existen varias maneras de lograr hacer un proyecto muy






accesible, como por ejemplo mapas, buscadores internos, formas de redactar simples y al grano,

etc. Simplicidad es la palabra clave.

El proyecto debe ser esttico y atractivo visualmente.

Antes he dicho que la usabilidad, orientada al usuario, es uno de los aspectos ms importantes al

momento de desarrollar un proyecto para Internet. Pues bien, podra decir que la esttica tambin

juega un papel importante, dicha esttica, que personalmente prefiero minimalista, creo es la

clave en la credibilidad de lo que escribimos, tambin logra que nuestros usuarios/as se sientan

cmodos utilizando lo que ponemos a su disposicin. Concretamente hablando de desarrollo de

sitios web, por ejemplo, he visto cmo contenidos interesantes -algunos publicados por

catedrticos o expertos en alguna materia- quedan sepultados bajo un diseo muy pobre, que ni

siquiera haba razn para ser tan deficiente respecto a esttica. Tambin por el contrario, he visto

unos superdiseos grficos, tantos, que sepultan el verdadero contenido. Por tanto te recomiendo

atencin a la esttica, simplicidad y equilibrio en este aspecto.

El proyecto debe transmitir emociones, segn su naturaleza.

No podemos evitarlo, somos humanos que tenemos emociones y, sea mediante la palabra al

redactar o mediante la ayuda de grficos, transmitir un mensaje que contenga alguna emocin,

acorde a la naturaleza del mensaje, ser muy efectivo, por muchsimo. La industria de la publicidad

es experta en ello, pero tambin escritores que, mediante la palabra, nos transportan a otros

mundos.

El proyecto debe tener herramientas y contenido actuales disponibles y estos deben mantenerse

constantemente actualizadas.

As es. Cuando comenc a desarrollar proyectos para Internet, a disear mis propias pginas,

Internet ya llevaba varios aos de andadura, y en esa poca las pginas se hacan una por una,

eran estticas y sus contenidos lentamente actualizados. Hoy, hasta se puede ver televisin,

vdeos, escuchar radio, msica y mil cosas ms. En estos tiempos se empieza a poner de moda la

llamada Web 2.0 (como las redes sociales), donde los usuarios -y no el desarrollador- son quienes

tienen la ltima palabra en lo que hacen por Internet, etc. Con tanto cambio, dnde quedarn

tus contenidos o tu proyectos si nunca actualizas?

El proyecto debe permitir, en la medida de lo posible, interactividad entre el receptor, el

mensaje y la fuente, completando el ciclo de la comunicacin.

La comunicacin, para que sea completa, debe ser un ciclo entre la fuente, el mensaje y el

receptor que interactan simultneamente. Cmo te sentiras hablando con alguien que no te






contesta, ni siquiera con un gesto? En Internet es prcticamente igual. Por tanto, es importante

que t, como desarrollador, permitas que tus usuarios puedan interactuar contigo de alguna

manera, enviar feedback, sea mediante formularios, mensajes electrnicos, foros, etc, etc. As

tambin t podrs ir adquiriendo nuevas ideas que te podran servir para implementar

comprendes?

El proyecto debe tener enfoque global, es decir, que no debe ser un fin en s mismo, sino un

medio para completar otros objetivos mayores, a la vez que mantiene consistencia con estos.

Siempre que desarrolles un proyecto para Internet, ten mucho cuidado de que el proyecto no sea

el fin, sino solo una herramienta ms para alcanzar algn objetivo. De otra manera, puede que

termines gastando tiempo y recursos en otra cosa que no sea tu verdadero objetivo. Recuerda, el

proyecto es solo una herramienta o medio ms. Mantn la visin equilibrada y no descuides otras

herramientas o medios que tambin podran serte tiles.

2.6. La Arquitectura en el Proceso Unificado de Desarrollo

Etapas, hitos, iteraciones y ciclos

Identifica los diferentes procesos que deben llevar a cabo dentro de las fases de un proceso

unificado de desarrollo de software.

Iniciacin.

Elaboracin.

Construccin.

Transicin.

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

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






El proceso unificado de desarrollo de software usa UML como podemos visualizar en la siguiente

figura

El proceso unificado de desarrollo de software est organizado de la siguiente manera:

a) Guiado por casos de uso.

b) Centrado en la arquitectura.

c) Ciclo de vida iterativo e incremental.

a) Guiado por casos de uso:

Los sistemas se crean para dar servicio a los usuarios

Qu REQUISITOS se necesitan

Un CASO de USO es una pieza de FUNCIONALIDAD de un sistema que le proporciona a algn

USUARIO un RESULTADO o VALOR.

Todos juntos constituyen el modelo de casos de uso

Funcionabilidad completa

Para todos los usuarios






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

En qu beneficia a un desarrollo guiado por casos de uso?

Los casos de uso: capturan requisitos, se especifican (analizan), se disean, se implementan y se

prueban

En siguiente figura podemos apreciar un ejemplo de un desarrollo por casos de uso:






a) Centrado en la arquitectura:

La arquitectura de un sistema software es un extracto de los

modelos del sistema es decir una vista de cada mdulo.

Que da una idea de la forma que tiene el sistema completo






b) Ciclo de vida iterativo e incremental

En el iterativo se repiten varios miniproyectos en el Incremental cada miniproyecto ampla el

producto, en el ciclo de vida del proceso unificado podemos anotar que

Un ciclo de vida se repite a lo largo del tiempo

Tras cada ciclo de vida versin nueva del producto

Un ciclo de vida se divide en fases

Cada fase se divide en iteraciones

En cada iteracin se realizan flujos de trabajo

Miremos grficamente estos componentes






Fases dentro del ciclo de vida del proceso unificado

Iniciacin:

Describir producto final / anlisis del negocio

Identificar riesgos ms importantes

Establecer planificacin inicial del proyecto

Decidir si se contina

Elaboracin:

Establecer Plan Y Arquitectura Estable

Construccin: desarrollar el producto

Transicin: proporcionar sistema a usuarios

Los flujos de trabajo, actividades, roles y artefactos

Dentro de los flujos de trabajo deben involucrarse aspectos referidos a conceptos que determinan

de alguna manera conceptos de Modelado del negocio, Anlisis de requerimientos, Anlisis y

diseo, Implementacin, Pruebas y Despliegue.

Flujos de trabajo

Captura de requisitos implica: identificar requisitos del sistema, construir un modelo del

mismo (de casos de uso y de dominio o negocio

Anlisis que implica: Especificar requisitos y construir modelo del anlisis

Diseo para encontrar la forma del sistema (solucin) y construir modelo del diseo






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

implementacin

Pruebas para verificar la implementacin y construir modelo de pruebas

Fase de Iniciacin:

Establecer la planificacin del proyecto

Qu va a hacer el sistema para cada uno de sus usuarios principales?

Un MCU simplificado con los CU ms crticos

Cmo sera la arquitectura para un sistema como ese?

Borrador con los subsistemas principales

Cul es el plan y cunto va a costar desarrollar el producto?

Identificar los riesgos principales y priorizarlos, planificar elaboracin y

presupuesto aproximado

Fase de Elaboracin:

Establecer un plan para el proyecto y una arquitectura correcta

Especificar en detalle los CU + crticos

Disear la arquitectura

Mediante vistas de todos los modelos del SI

Vista arquitectnica de MCU, M. Anlisis, M. Diseo, M. Implementacin (con los

componentes que demuestran que la arquitectura es ejecutable) y M. Distribucin.

Al final de esta fase se debe poder planificar las actividades y estimar los recursos para poder

completar el proyecto. Son los CU, arquitectura y planes lo suficientemente estables y los

riesgos bajo control suficiente para firmar un contrato para terminar el trabajo de desarrollo?

Fase de Construccin:

Desarrollar el sistema, Se construye el producto. En esta fase:

La arquitectura se completa para construir un sistema bien cimentado La visin evoluciona hasta convertirse en un producto preparado para los usuarios Es donde se gastan la mayora de los recursos La arquitectura del sistema es estable. Sin embargo, se pueden realizar cambios mnimos a

la misma. El producto se ajusta suficientemente a las necesidades de algunos usuarios como para

envirselo ya? Fase de transicin:

Proporcionar el sistema a los usuarios finales, El producto se encuentra en fase beta

Un grupo reducido de usuarios experimentados prueba el producto e informa de los

defectos y deficiencias y sugieren mejoras.






Los desarrolladores corrigen las deficiencias e incorporan algunas de las mejoras

propuestas en una versin para un grupo de usuarios mayor.

En esta fase se encuentran actividades como la venta, formacin de los usuarios,

ofrecimiento de ayuda en lnea y correccin de defectos descubiertos tras la implantacin.

Los defectos: (1) los que justifican la aparicin de una nueva versin del sistema, (2) los

que se pueden dejar para la siguiente versin que se cree.

Ejercicio de autoevaluacin

Obtener el modelo conceptual de un sistema que gestiona las matrculas de los estudiantes de la

Universidad Remington.

Una persona viene caracterizada por su ID, nombre, direccin y estado civil, y sta puede convertirse

en estudiante al darse de alta como tal en la universidad. Como estudiante podr matricularse de las

asignaturas que se imparten en la universidad, que tendrn un cdigo, un nombre, un profesor

responsable y un curso asignado. Una vez matriculado, el estudiante podr recibir una beca, y en su

nueva condicin de becario tendr asignado un nuevo cdigo y se conocer el importe de la misma;

al finalizar el curso, la condicin de becario acabar. Una vez el estudiante se matrcula, tanto si

recibe beca como si no, deber examinarse de las asignaturas en las que se encuentra matriculado

hasta que finalice el curso y vuelva a matricularse de nuevo, o bien deje la universidad y con ello deje

de ser estudiante. Adems, convendr tener una serie de aplicaciones tales como dar de alta a

nuevas personas y asignaturas, llevar a cabo la matriculacin de estudiantes en asignaturas, registrar

las notas obtenidas por los estudiantes al examinarse de cualquier asignatura en la que estn

matriculados y una serie de listados tales como los alumnos matriculados en una asignatura, las

asignaturas en las que se ha matriculado un alumno y el listado de notas por asignatura (actas).






3. LA ARQUITECTURA DE SOFTWARE.

OBJETIVO GENERAL

Presentar de manera prctica las diferentes metodologas y buenas prcticas para documentacin

y evaluacin de arquitecturas de software


Identificar y comprender los diversos aspectos del software utilizando distintos modelos o

vistas.

Describir y disear una arquitectura basados en la estructura sintctica y semntica del

ADL.

Estructurar todo el anlisis del proyecto por medio de estructuras que nos provee UML

2.0.

Crear Arquitecturas de servicios web por medio SOA para garantizar una comunicacin

rpida y transparente entre aplicaciones.

Desarrollar implementaciones sobre computacin mvil aplicando arquitecturas de alta

escalabilidad.

3.1. Relacin de conceptos






3.2. Prueba Inicial

Desde sus conocimientos previos a la unidad, plantee respuestas coherentes a las siguientes

preguntas de manera que le permitan al finalizar la unidad confrontar sus respuestas y medir su

grado de asimilacin

a) Qu caracteriza el diseo en la arquitectura del software?

b) Cules modelos de la arquitectura puedes mencionar?

c) Indique al menos una caracterstica de los estilos arquitectnicos

d) Qu es ADL y que componentes de ste puedes indicar?

e) Cules son las cualidades del enfoque arquitectnico a tener en cuenta para dicho

proceso de modelamiento?

f) Indique algunos componentes del modelado UML 2.0

3.3. Modelos de arquitectura de software.

Caractersticas de un diseo de arquitectura

Propiedades estructurales: Define los componentes de un sistema y la manera en que dichos

componentes se agrupan en paquetes e interaccionan entres ellos.

Propiedades extra-funcionales: Debe indicar cmo el diseo arquitectnico alcanza los requisitos

no funcionales como: rendimiento, capacidad, fiabilidad, seguridad, adaptabilidad, etc.

Familias de sistemas relacionados: Debe permitir reconocer su estructura en los patrones

repetitivos que se encuentran de manera habitual en el diseo de sistemas similares. Debe ser

capaz de reutilizar bloques de construccin arquitecturales.

Modelos:

Estructurales: Representan la arquitectura como una coleccin organizada de componentes.

De Frameworks: Identifican patrones de diseo arquitectnico repetibles que se encuentran en

aplicaciones similares.

Dinmicos: Muestran los aspectos del comportamiento dinmico de la arquitectura, indicando

como la estructura o la configuracin del sistema pueden cambiar en funcin de eventos externos.

De procesos: Se enfocan en el diseo de los procesos del negocio que el sistema debe soportar.






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

Para tener un concepto ms claro sobre arquitectura de software podemos tener en cuenta los

siguientes aspectos:

Facilita la comunicacin entre los diferentes participantes en el desarrollo.

Resalta las decisiones de diseo que pueden tener un gran impacto en todo el proceso de

desarrollo posterior.

Aporta una visin de cmo se estructura el sistema y cmo sus componentes trabajan

juntos.

Miremos ahora los estilos arquitectnicos:

Modelos de descomposicin de sistemas.

Modelo de almacn central.

Cliente/servidor.

Modelo de mquinas abstractas.

Modelo de control

Centralizado.

Modelo de eventos.

Modelos de descomposicin modular

Modelo de flujo de datos.

Modelo orientado a objetos.

Modelo de dominio especfico

Arquitectura centrada en los datos.

Arquitectura centrada en los flujos de datos.

Arquitectura llamada y respuesta (call and return)

Arquitectura orientada a objetos.

Arquitectura en capas.

Un problema puede satisfacerse mediante diferentes estructuras a las que se llegarn

posiblemente utilizando tcnicas distintas, A veces la frontera entre dos estilos no est muy clara,

lo que provoca que haya mezcla entre ellos.






Arquitectura centrada en los datos: Como parte central de esta arquitectura aparece un almacn

de datos, el cual es accedido de manera frecuente por otros componentes que actualizan, aaden,

borran o modifican dichos almacenes.

Repositorio pasivo: El cliente software accede a los datos independientemente de cualquier

cambio en los datos o a las acciones de otros clientes software.

Repositorio activo (pizarra): El repositorio enva informacin a los clientes cuando los datos de su

inters cambian, siendo por tanto un ente activo.

Arquitectura centradas en datos proporcionan integridad, es decir, los componentes existentes

pueden cambiar y pueden aadirse nuevos componentes a la arquitectura sin que afecte a otros

clientes. A su vez los datos pueden ser pasados entre cliente a travs de mecanismos que

coordinen dicha transferencia de informacin. Miremos a continuacin una figura que nos

visualiza de manera ms general lo que acabamos de expresar.

Componentes cliente ejecutan procesos independientemente

Arquitectura centrada en los flujos de datos: Se basa en el patrn pipe and filter (tuberas y

filtros). Este consta de un conjunto de componentes denominados filtros conectados entre s

por tuberas que transmiten datos desde un componente al siguiente.

Cada filtro trabaja de manera independiente de los componentes que se encuentran situados

antes o despus de ella. Se disean de tal modo que esperan un conjunto de datos en un

determinado formato y obtiene como resultado otros datos de salida en un formato especfico.






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

Veamos una figura referente a esta arquitectura

Arquitectura llamada y respuesta (call and return): Permite a los diseadores software conseguir

estructuras de programas relativamente fciles de modificar y escalar.

Podemos encontrar diferentes estilos de este tipo:

Programa principal/subprograma: Descompone las funciones en una jerarqua de control donde el

programa principal invoca a los otros programas subordinados, los cuales pueden a su vez invocar

otros.

Llamada de procedimiento remoto: Los componentes de la arquitectura son distribuidos entre

diferentes ordenadores de la red.

Veamos a continuacin una figura de esta arquitectura:






Arquitectura orientada a objetos: Los componentes del sistema encapsulan datos y operaciones

que deben utilizarse para manipular dichos datos. La comunicacin y coordinacin entre

componentes se realiza mediante envo de mensajes.

En esencia es un sistema parecido al anterior, donde se enfatiza el empaquetamiento entre datos

y operaciones que permiten manipular y acceder a dichos datos.

Arquitectura en capas: Se definen un conjunto de niveles o capas, cada nivel interno que se

atraviesa se aproxima ms al nivel del conjunto de instrucciones mquina.

Sistemas en capas puros: Cada capa slo puede comunicarse con las vecinas. Esta solucin aunque

puede ser menos eficiente en algunos casos, facilita la portabilidad de los diseos. A continuacin

visualizamos una figura:

Una vez que el arquitecto de software, tras conocer el requerimiento, se decide a delinear su

estrategia y a articular los patrones que se le ofrecen hoy en profusin, se supone que debera

expresar las caractersticas de su sistema, o en otras palabras, modelarlo, aplicando una

convencin grfica o algn lenguaje avanzado de alto nivel de abstraccin.

A esta altura del desarrollo de la arquitectura de software, podra pensarse que hay abundancia de

herramientas de modelado que facilitan la especificacin de desarrollos basados en principios

arquitectnicos, que dichas herramientas han sido consensuadas y estandarizadas hace tiempo y

que son de propsito general, adaptables a soluciones de cualquier mercado vertical y a cualquier






estilo arquitectnico. La creencia generalizada sostendra que modelar arquitectnicamente un

sistema se asemeja al trabajo de articular un modelo en ambientes ricos en prestaciones grficas,

como es el caso del modelado de tipo CASE o UML, y que el arquitecto puede analizar visualmente

el sistema sin sufrir el aprendizaje de una sintaxis especializada. Tambin podra pensarse que los

instrumentos incluyen la posibilidad de disear modelos correspondientes a proyectos basados en

tecnologa de internet, Web services o soluciones de integracin de plataformas heterogneas, y

que, una vez trazado el modelo, el siguiente paso en el ciclo de vida de la solucin se produzca con

naturalidad y est servido por tcnicas bien definidas. Como se ver en este documento, la

situacin es otra, dista de ser clara y es harto ms compleja.

Entre las comunidades consagradas al modelado OO y la que patrocina o frecuenta los ADLS (as

como entre las que se inclinan por el concepto de estilos arquitectnicos y las que se trabajan en

funcin de patrones) existen relaciones complejas que algunas veces son de complementariedad y

otras de antagonismo.

Aunque algunos arquitectos influyentes, como Jorgen Thelin, alegan que el perodo de gloria de la

OOP podra estar acercndose a su fin, el hecho concreto es que el modelado orientado a objetos

de sistemas basados en componentes posee cierto nmero de rasgos muy convenientes a la hora

de disear o al menos describir un sistema. En primer lugar, las notaciones de objeto resultan

familiares a un gran nmero de ingenieros de software.

TEMA 2 Criterios de definicin de un ADL

Los ADLs se remontan a los lenguajes de interconexin de mdulos (MIL) de la dcada de 1970,

pero se han comenzado a desarrollar con su denominacin actual a partir de 1992 o 1993, poco

despus de fundada la propia arquitectura de software como especialidad profesional. La

definicin ms simple es la de Tracz [Wolf97] que define un ADL como una entidad consistente en

cuatro Cs: componentes, conectores, configuraciones y restricciones (constraints). Una de las

definiciones ms tempranas es la de Vestal [Ves93] quien sostiene que un ADL debe modelar o

soportar los siguientes conceptos:

Componentes

Conexiones

Composicin jerrquica, en la que un componente puede contener una sub-arquitectura

Completa

Paradigmas de computacin, es decir, semnticas, restricciones y propiedades no

funcionales

Paradigmas de comunicacin






Modelos formales subyacentes

Soporte de herramientas para modelado, anlisis, evaluacin y verificacin

Composicin automtica de cdigo aplicativo

Basndose en su experiencia sobre Rapide, Luckham y Vera [LV95] establecen como

requerimientos:

Abstraccin de componentes

Abstraccin de comunicacin

Integridad de comunicacin (slo los componentes que estn conectados pueden

comunicarse)

Capacidad de modelar arquitecturas dinmicas

Composicin jerrquica

Relatividad (o sea, la capacidad de mapear o relacionar conductas entre arquitecturas)

Tomando como parmetro de referencia a UniCon, Shaw y otros [SDK+95] alegan que un ADL

debe exhibir:

Capacidad para modelar componentes con aserciones de propiedades, interfaces e

implementaciones

Capacidad de modelar conectores con protocolos, asercin de propiedades e

implementaciones

Abstraccin y encapsulamiento

Tipos y verificacin de tipos

Capacidad para integrar herramientas de anlisis

Otros autores, como Shaw y Garlan [SG94] estipulan que en los ADLs los conectores sean tratados

explcitamente como entidades de primera clase (lo que dejara al margen de la lista a dos de ellos

al menos) y han afirmado que un ADL genuino tiene que proporcionar propiedades de

composicin, abstraccin, reusabilidad, configuracin, heterogeneidad y anlisis, lo que excluira a

todos los lenguajes convencionales de programacin y a los MIL.

La especificacin ms completa y sutil (en tanto que se presenta como provisional, lo que es

propio de un campo que recin se est definiendo) es la de Medvidovic [Med96]:

Componentes

Interfaz

Tipos






Semntica

Restricciones (constraints)

Evolucin

Propiedades no funcionales

Conectores

Interfaz

Tipos

Semntica

Restricciones

Evolucin


Configuraciones arquitectnicas

Comprensibilidad

Composicionalidad

Heterogeneidad

Restricciones

Refinamiento y trazabilidad

Escalabilidad

Evolucin

Dinamismo


Soporte de herramientas

Especificacin activa

Mltiples vistas

Anlisis

Refinamiento

Generacin de cdigo

Dinamismo

Ntese, en todo caso, que no se trata tanto de aspectos definitorios del concepto de ADL, sino de

criterios para la evaluacin de los ADLs existentes, o sea de un marco de referencia para la

clasificacin y comparacin de los ADLs.






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

primarios que, ms all de la diversidad existente, son comunes a la ontologa de todos los ADLs y

habrn de ser orientadores de su tratamiento en este estudio.

Componentes: Representan los elementos computacionales primarios de un sistema.

Intuitivamente, corresponden a las cajas de las descripciones de caja-y-lnea de las arquitecturas

de software. Ejemplos tpicos seran clientes, servidores, filtros, objetos, pizarras y bases de datos.

En la mayora de los ADLs los componentes pueden exponer varias interfaces, las cuales definen

puntos de interaccin entre un componente y su entorno.

Conectores. Representan interacciones entre componentes. Corresponden a las lneas de las

descripciones de caja-y-lnea. Ejemplos tpicos podran ser tuberas (pipes), llamadas a

procedimientos, broadcast de eventos, protocolos cliente-servidor, o conexiones entre una

aplicacin y un servidor de base de datos. Los conectores tambin tienen una especie de interfaz

que define los roles entre los componentes participantes en la interaccin.

Configuraciones o sistemas. Se constituyen como grafos de componentes y conectores. En los

ADLs ms avanzados la topologa del sistema se define independientemente de los componentes y

conectores que lo conforman. Los sistemas tambin pueden ser jerrquicos: componentes y

conectores pueden subsumir la representacin de lo que en realidad son complejos subsistemas.

Propiedades. Representan informacin semntica sobre un sistema ms all de su estructura.

Distintos ADLs ponen nfasis en diferentes clases de propiedades, pero todos tienen alguna forma

de definir propiedades no funcionales, o pueden admitir herramientas complementarias para

analizarlas y determinar, por ejemplo, el throughput y la latencia probables, o cuestiones de

seguridad, escalabilidad, dependencia de bibliotecas o servicios especficos, configuraciones

mnimas de hardware y tolerancia a fallas.

Restricciones. Representan condiciones de diseo que deben acatarse incluso en el caso que el

sistema evolucione en el tiempo. Restricciones tpicas seran restricciones en los valores posibles

de propiedades o en las configuraciones topolgicas admisibles. Por ejemplo, el nmero de

clientes que se puede conectar simultneamente a un servicio.

Estilos. Representan familias de sistemas, un vocabulario de tipos de elementos de diseo y de

reglas para componerlos. Ejemplos clsicos seran las arquitecturas de flujo de datos basados en

grafos de tuberas (pipes) y filtros, las arquitecturas de pizarras basadas en un espacio de datos

compartido, o los sistemas en capas. Algunos estilos prescriben un framework, un estndar de

integracin de componentes, patrones arquitectnicos o como se lo quiera llamar.






Evolucin. Los ADLs deberan soportar procesos de evolucin permitiendo derivar subtipos a partir

de los componentes e implementando refinamiento de sus rasgos.

Slo unos pocos lo hacen efectivamente, dependiendo para ello de lenguajes que ya no son los de

diseo arquitectnico sino los de programacin.

Propiedades no funcionales. La especificacin de estas propiedades es necesaria para simular la

conducta de runtime, analizar la conducta de los componentes, imponer restricciones, mapear

implementaciones sobre procesadores determinados, etctera.

3.4. Enfoques arquitectnicos de software

Antes de enfrentarnos a tomar la decisin de una arquitectura creo que debemos tener en cuenta

cualidades como: Performance, Availability, Security, Modifiability

Tambin se debe analizar muy bien atributos como:

El sistema debe ser robusto

El sistema debe ser modificable

El sistema debe ser seguro

El sistema debe tener un desempeo aceptable

A continuacin vamos a centrarnos en 2 enfoques arquitectnicos SAAM y ATAM

SAAM - Software Architecture Analysis Method

Propsito, Contexto y escenarios, Roles, Mtodo de anlisis, Fortalezas, Debilidades

Propsito: Basado en escenarios, Foco modificabilidad, Evaluar una arquitectura o evaluar y

comparar varias

Contexto y escenarios: Atributos de calidad complejos y amorfos para evaluarse simplemente

Dependientes del contexto: Escenario. Interaccin entre un interesado y el sistema

Un escenario directo es el que puede satisfacerse sin la necesidad de modificaciones en la

arquitectura.






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

satisfacerse.

Interaccin de escenarios n escenarios. Dos o ms escenarios indirectos requieren cambios sobre

el mismo componente

Roles:

Interesados externos externos (Organizacin cliente, usuarios finales, administradores del sistema,

etc.)

Interesados internos internos(Arquitectos de Software, analistas de requerimientos)

Equipo SAAM SAAM(Lder, expertos en el dominio de la aplicacin, expertos externos en

arquitectura y secretario)

Mtodo de anlisis:

Paso1: Desarrollo de escenarios.

Paso2: Descripcin de la Arquitectura.

Paso3: Clasificacin de escenarios.

Paso4: Evaluacin de escenarios.

Paso5: Interaccin de escenarios.

Paso6: Evaluacin general.

1. Desarrollo de escenarios: Un escenario es una breve descripcin de usos anticipados o deseados del sistema. De igual forma,

estos pueden incluir cambios a los que puede estar expuesto el sistema en el futuro.

2. Descripcin de la arquitectura

La arquitectura (o las candidatas) debe ser descrita haciendo uso de alguna notacin

arquitectnica que sea comn a todas las partes involucradas en el anlisis. Deben incluirse los

componentes de datos y conexiones relevantes, as como la descripcin del comportamiento

general del sistema.

El desarrollo de escenarios y la descripcin de la arquitectura son usualmente llevados a cabo de

forma intercalada, o a travs de varias iteraciones.

3. Clasificacin y asignacin de prioridad de los escenarios

La clasificacin de los escenarios puede hacerse en dos clases: directos e indirectos.






Los escenarios indirectos son de especial inters para SAAM, pues son los que permiten medir el

grado en el que una arquitectura puede ajustarse a los cambios de evolucin que son importantes

para los involucrados en el desarrollo.

4. Evaluacin individual de los escenarios indirectos

Para cada escenario indirecto, se listan los cambios necesarios sobre la arquitectura, y se calcula

su costo.

Una modificacin sobre la arquitectura significa que debe introducirse un nuevo componente o

conector, o que alguno de los existentes requiere cambios en su especificacin.

5. Evaluacin de la interaccin entre escenarios

Cuando dos o ms escenarios indirectos proponen cambios sobre un mismo componente, se dice

que interactan sobre ese componente.

Es necesario evaluar este hecho, puesto que la interaccin de componentes semnticamente no

relacionados revela que los componentes de la arquitectura efectan funciones semnticamente

distintas.

De forma similar, puede verificarse si la arquitectura se encuentra documentada a un nivel

correcto de descomposicin estructural.

6. Creacin de la evaluacin global

Debe asignrsele un peso a cada escenario, en trminos de su importancia relativa al xito del

sistema.

Esta asignacin de peso suele hacerse con base en las metas del negocio que cada escenario

soporta. En el caso de la evaluacin de mltiples arquitecturas, la asignacin de pesos puede ser

utilizada para la determinacin de una escala general.

Fortalezas:

Los interesados comprenden con facilidad las arquitecturas evaluadas.

La documentacin es mejorada.

El esfuerzo y el costo de los cambios pueden ser estimados con anticipacin.

Analoga con el concepto de bajo acoplamiento y alta cohesin.

Debilidades:

La generacin de escenarios est basada en la visin de los interesados.

No provee una mtrica clara sobre la calidad de la arquitectura Evaluada.






El equipo de evaluacin confa en la experiencia de los arquitectos p

Documents

arquitectura_de_software.pdf