Unidad 1. Arquitectura

Diseo y Arquitectura de Software
Unidad 1. Arquitectura

1

Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software
1

Ingeniera en Desarrollo de software
5 Cuatrimestre

Programa de la asignatura:

Clave: 150920517

Universidad abierta y a distancia de Mxico


2

2
ndice

UNIDAD 1.ARQUITECTURA ............................................................................................. 3
Presentacin de la unidad .............................................................................................. 3
Propsito ........................................................................................................................ 3
Competencia especfica ................................................................................................. 3
Actividad 1. Intercambio de conocimientos ..................................................................... 3
1.1. Introduccin a la arquitectura de software ............................................................... 4
1.1.1. Descripcin de la arquitectura .............................................................................. 5
1.1.2 Vistas de la arquitectura ...................................................................................... 10
1.1.3. Conjunto tpico de las vistas de una arquitectura. ............................................... 11
1.2. El enfoque arquitectnico ...................................................................................... 13
1.2.1. Patrones de arquitectura .................................................................................... 14
1.2.2. La arquitectura ubicada en el proceso de software ............................................. 15
Actividad 2. Lenguaje descriptor de arquitectura .......................................................... 17
Actividad 3. Patrones de arquitectura de software ........................................................ 17
Autoevaluacin ............................................................................................................. 18
Evidencia de aprendizaje. Lenguaje descriptor y patrones de arquitectura de software 18
Autorreflexiones ........................................................................................................... 18
Cierre de la unidad ....................................................................................................... 19
Para saber ms ............................................................................................................ 19
Fuentes de consulta ..................................................................................................... 19


3

3
Unidad 1.Arquitectura

Presentacin de la unidad

Bienvenido(a) a la asignatura de Diseo y Arquitectura de Software. En esta primera
unidad revisars una descripcin de lo que es y lo que no es una arquitectura de
software; as mismo conocers las distintas propuestas existentes en la industria del
desarrollo del software y en la academia acerca de un lenguaje formal, llamado lenguaje
descriptor de arquitectura, e identificars cuntas y cules son las vistas de la arquitectura
y cmo se pueden conjuntar estas vistas, de manera que sea habitual para cualquier
usuario que tenga acceso a la descripcin de la Arquitectura del Software a construir.

Las vistas nos llevarn a tener una descripcin de modelo de forma clara con un enfoque
arquitectnico, sealando los principales patrones existentes aplicables a la fabricacin de
la Arquitectura de Software y ubicarla dentro del ciclo de vida del desarrollo de software.
Bienvenido(a) a la unidad 1.

Propsito

Comprender el concepto de arquitectura de software y los lenguajes de descripcin de
arquitectura, para conocer cmo afecta al xito de un proyecto de desarrollo de software,
la adecuada seleccin y representacin de esta, mediante la aplicacin de patrones y un
lenguaje formal, adems de su correcta ubicacin en el ciclo de vida del desarrollo de
software.

Competencia especfica

Comprender la arquitectura de software para que use patrones de arquitectura en el ciclo
de vida del desarrollo de software mediante el lenguaje descriptor de arquitectura.

Actividad 1. Intercambio de conocimientos

Bienvenido(a) al foro General de la asignatura de Diseo y arquitectura de software, el
cual ha sido diseado para que ingreses cada vez que lo necesites, ya sea para
presentarte con el grupo, para compartir alguna pregunta, inquietud, o para apoyar a tus
compaeros(as) en la resolucin de dudas. El foro estar abierto durante todo el curso y
consta de varias entradas o categoras a las que debers ingresar dependiendo del tipo
de participacin que quieras hacer:

4

4

Comentar asuntos personales como tu nombre y experiencias propias.
Si tienes dudas o comentarios relacionados con detalles tcnicos, por ejemplo,
sobre la instalacin de alguno de los programas que se usan en el curso.
Comentarios de temas directamente relacionados con el contenido de la asignatura.
No est permitido realizar tareas en grupo, solo dudas especificas y apoyo.
Es recomendable que todos los comentarios sean de manera respetuosa y responsable.
Para comenzar ingresa al Foro Presentacin e intercambio de conocimientos.

Nota: El facilitador estar monitoreando el foro y tomara acciones al respecto en caso de
trabajos duplicados.

1.1. Introduccin a la arquitectura de software

La presente asignatura tiene como finalidad ser una introduccin a la Arquitectura de
Software. Es una disciplina emergente que ayuda a abstraer, conceptualizar y modelar de
manera ptima con sus herramientas, modelos y patrones para aplicarla en la
construccin de software y con esta asignatura podrs observar el papel primordial que
juega esta disciplina para el xito o fracaso de un proyecto de software.

Tambin es importante aclarar que la fusin entre los conceptos que se abordarn sobre
AS y la prctica ser un tema que involucre mucha dedicacin, pues influyen muchos
factores para que suceda: a veces lo que dice la teora difiere con los problemas reales de
la industria del desarrollo de software, y viceversa. Toma en cuenta que ninguna visin es
ms importante que la otra. Considerando la problemtica descrita, podrs proponer
soluciones que satisfagan las dos visiones: industrial y terica.

En comparacin con otras actividades que realiza el ser humano, el desarrollo de software
es una disciplina joven. Haciendo conciencia de ello, habr quien diga que se puede
contar entre 60 u 80 aos de su aparicin formal. La evolucin del desarrollo de software
ha sido a pasos acelerados, pues en la actualidad son muy pocos los ambientes o
entornos donde no se involucra de una manera u otra el funcionamiento del software, y
hay casos en donde la dependencia se ha hecho total, llegando a tal medida que la vida
humana, la seguridad de un pas o la automatizacin del mecanismo de apagado de la
cafetera, dependen del correcto funcionamiento del software.

Esta acelerada evolucin ha hecho que el desarrollo de software se deba apoyarse en
otras disciplinas como la Ingeniera y la Arquitectura en su sentido ms puro, para as
tomar lo mejor de ellas en partes donde ya se tiene mucha experiencia, han pasado por
un proceso de aprendizaje y los resultados estn probados en la mayora de los casos
como exitosos. As, no es de extraarse que la base de la AS se haya tomado de la

5

5
industria de la construccin, utilizando sustantivos comunes como arquitecto y
arquitectura, que toman su definicin de ese mbito para aplicarlos de la misma manera
en el campo del desarrollo de software.

Haciendo un breve recorrido histrico sobre cmo se ha aplicado esta evolucin, e
identificando una semejanza entre la construccin de estructuras tangibles (edificios,
puentes, pirmides, aeropuertos, entre otros) y la construccin de software, se podra
decir que si se dibuja una lnea de tiempo imaginaria, hemos ido desde vivir en cuevas,
pasado por el adobe, hasta llegar al ladrillo y la prefabricacin de estructuras utilizables en
cualquier mbito que se requiera. Los mismos principios se aplican, sin mover muchos
elementos, a la construccin de software.

En esta analoga es importante aclarar que la descripcin de esta lnea de tiempo
imaginaria slo ser til para estructuras pequeas, como una casa-habitacin o incluso
un edificio pequeo de cinco u ocho niveles. Sin embargo cuando se trata de construir
edificios de ms de 100 niveles, capaces de soportar grandes presiones a causa de la
fuerza del viento, terremotos, o el clculo y equilibrio de las cargas mximas que soporta
el material de construccin utilizado para mantener la seguridad estructural; o si se trata
de la construccin de un puente que cruza de una ciudad a otra por encima de un enorme
ro o incluso el mar; entonces se est hablando de cosas y requisitos de diseo totalmente
distintos entre ambos tipos de estructuras descritas. De la misma manera ocurre para la
construccin del software: se ha evolucionado desde la construccin artesanal, enfocado
hacia problemas muy acotados y de operacin repetitiva (tales como simples impresiones
de mensajes a las salidas estndar), pasando por el mbito estrictamente acadmico
como el clculo de ecuaciones de cientos o miles de variables, el nmero PI, software que
simula modelos para predecir el clima, realizar el clculo de impuestos, definir la direccin
de naves espaciales, hasta el empleo completo de complejas arquitecturas para poder
soportar plataformas de software que prestan servicios inimaginables para la mayora de
la poblacin y solventan los problemas cotidianos como la escritura de una carta en un
procesador de palabras, la creacin de complejas redes sociales virtuales y reales, o el
cobro automtico del derecho a abordar un vehculo de transporte pblico con la simple
presentacin frente a un lector de una tarjeta dotada de chip.

La adaptabilidad de un sistema de software con otros semejantes u otras tecnologas
emergentes, su robustez, facilidad de mantenimiento e incluso gran parte del xito de sus
usuarios al consumir sus servicios, tendr que ver con un diseo correcto de la
arquitectura que lo soporta.

1.1.1. Descripcin de la arquitectura


6

6
Cuando los requerimientos del software a desarrollar han salido de la etapa del anlisis y
han sido entregados al arquitecto, ste decide que es tiempo de pensar en el cmo har
que esos requerimientos queden cubiertos con una slida arquitectura de software;
entonces, deber modelar esas caractersticas de los requerimientos en la mencionada
arquitectura, es decir, describirla con una convencin grfica o un lenguaje formal de alto
nivel propio para representar la arquitectura resultante.

En pantallas anteriores se ha dicho que la evolucin del software ha llegado a grandes
soluciones basadas en las mejores prcticas de otras disciplinas, y podra pensarse que
esta misma evolucin ya tendra disponible para los arquitectos de software un estndar
totalmente aceptado en la industria del desarrollo de software sobre cmo plasmar en
forma grfica la arquitectura, sin embargo, no lo hay.

Tras una larga tradicin de construccin de arquitecturas, se ha credo de manera
generalizada que para definir una arquitectura estndar es posible y necesario tener a
disposicin un ambiente grfico abundante, como es el caso del modelado CASE o UML,
y as tambin es necesario que la visualizacin del sistema sea con componentes
grficos. El mismo arquitecto previamente mencionado puede aadir o poner estos
componentes segn sea la necesidad que se presente, sin tener que aprender un
lenguaje formal que describa de mejor manera dichas propuestas. En la actualidad con el
auge que tienen las tecnologas web y mviles, podra suponerse que se cuenta con
todos los elementos para poder hacer una arquitectura que cumpla con lo antes
mencionado, o ms an, con servicios web o ambientes heterogneos: se ha pensado en
el mundo ideal, pero al ver la realidad de un arquitecto de software, se observa que la
situacin es mucho ms compleja y que las cosas no son tan sencillas como pudiera
apreciarse.

Como ejemplo de la situacin compleja podemos observar la acelerada aparicin de
tecnologas mviles y de nuevas propuestas de arquitectura ha hecho que para modelar
un servicio web, el acceso desde o hacia un dispositivo mvil o la infraestructura en la
nube, se empleen tcnicas altamente cuestionables o incluso totalmente fuera de
estndares (sea cual sea) para poder dar cumplimiento a ello(por mencionar una de
tantas situaciones); la realidad es que existe un desfase con relacin al avance y
lanzamiento de nuevas tecnologas y dispositivos.

Para poder describir una arquitectura de manera estndar y adecuada surgi el uso de los
lenguajes de descripcin de arquitecturas (ADLs), los cuales se utilizan para satisfacer
requerimientos descriptivos que necesitan un alto nivel de abstraccin, requisito que
puede cumplir, por ejemplo, UML. Este nivel de abstraccin en los sistemas se debe a
que cada vez se necesita que el software resuelva ms problemas de la vida cotidiana, y
se ha permeado a todas las ramas y fases de la vida de las personas, no en ambientes
tan controlados como la academia, con las frmulas matemticas.

7

7

Siguiendo con la comprensin de los ADLs es necesario considerar una definicin un
poco ms formal, la que se habr de aplicar desde ahora es la de un lenguaje descriptivo
de modelado, del cual su principal inters es la estructura de alto nivel del producto de
software antes que los detalles finos de desarrollo e implementacin de los mdulos que
lo conforman. Ante esta situacin, se podran enumerar los ADLs que se encuentran
actualmente en la industria para dar una idea de cuntos esfuerzos se han hecho por las
empresas u organismos por generar su propio estndar, algunos con resultados bastante
buenos y otros han tenido grandes dificultades para ser siquiera aceptados.

De esta forma, en la que cada quien lanza y usa su propia definicin y especificacin de
ADLs, no existe una definicin generalizada los lenguajes, pero comnmente debe
pensarse que estos lenguajes proporcionan un modelo explcito de componentes
conectores y sus respectivas configuraciones. Esta idea no es contradictoria con la
definicin aplicada en prrafos anteriores, ya que all se define como aplicacin y aqu se
menciona como aceptacin unvoca.

Los lenguajes de interconexin de mdulos son los predecesores de los ADLs, pero estos
comienzan un desarrollo serio a partir de principios de los noventas, un poco antes de que
la arquitectura de software se tomara como una propuesta seria y necesaria. Los ADLs
cuentan con cuatro criterios que los definen como una entidad: componentes, conectores,
configuraciones y restricciones. Para poder considerar un lenguaje que pertenezca a la
familia de ADLs debe soportar por lo menos los siguientes elementos:

Componentes
Conexiones
Composicin jerrquica
Paradigmas de computacin
Paradigmas de comunicacin
Modelos formales subyacentes
Soporte de herramientas para modelado, anlisis, validacin y verificacin
Composicin automtica de cdigo aplicativo
Abstraccin de componentes
Relatividad
Capacidad para modelar componentes
Tipos y verificacin de tipos

Esta lista es tomada de diversos autores de forma sinttica. A continuacin a modo de
resumen se presenta la siguiente tabla para suponer el entendimiento de los requisitos
que debe cumplir un ADLs.


8

8
Componentes Conectores Configuraciones
arquitectnicas
Soporte de
herramientas
Interfaz Interfaz Comprensibilidad Especificacin
activa
Tipos Tipos Composicionalidad Mltiples vistas
Semntica Semntica Heterogeneidad Anlisis
Restricciones Restricciones Restricciones Refinamiento
Evolucin Evolucin Refinamiento y
trazabilidad
Generacin de
cdigo
Propiedades no
funcionales
Propiedades no
funcionales
Escalabilidad Dinamismo
Evolucin
Dinamismo
Propiedades no
funcionales

Considerando las propuestas sealadas, a continuacin se definen 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 (Reynoso, 2004):

Elementos Definicin Algunos ejemplos ms
comunes
Componentes

(descripciones de caja
y-linea)
Elementos
computacionales
primarios de un sistema.
Se exponen en diferentes
interfaces, que definen la
interaccin de un
componente y entorno.
Clientes, base de datos,
servidores, filtros,
objetos, pizarras.
Conectores
(descripciones de caja
y-linea)
Interacciones entre
componentes.
Se exponen en diferentes
interfaces, que definen los
roles de los componente
que participan en la
interaccin.
Tuberas (pipes),
protocolos cliente-
servidor, broadcast de
eventos.
Configuraciones o
sistemas
Compuestos como grafos
de componentes y
conectores.
---------------------

9

9
La topologa del sistema
se define de forma aparte
de los componentes y
conectores en los ADLs
ms avanzados.
Los sistemas pueden ser
jerrquicos.
Propiedades. Representan informacin
semntica sobre un
sistema ms all de su
estructura.
Diferentes ADLs dan
importancia a las
diferentes clases de
propiedades pero definen
las no funcionales o
admiten herramientas
complementarias para su
anlisis.
Troughput y la latencia
probables, cuestiones de
seguridad, dependencias
de bibliotecas o
configuraciones mnima
de hardware y tolerancia
a fallas.
Restricciones Representan condiciones
de diseo de acuerdo a
las evoluciones en el
tiempo.
Una restriccin comn
seria las configuraciones
topolgicas admisibles.
El nmero de clientes que
se conectan al mismo
tiempo a un servicio.
Estilos Representan: familias de
sistemas, vocabulario de
tipos de elementos de
diseo y reglas para
componerlos.
Algunos prescriben un
framework o patrones
arquitectnicos
Arquitecturas deflujo de
datos basados en
tuberas y filtros, sistemas
en capas.
Evolucin En los ADLs no todos
soportan los procesos de
evolucin para el
refinamiento de sus
rasgos, son pocos los que
lo soportan dependiendo
de lenguajes que ya no
----

10

10
son los de diseo
arquitectnico sino los de
programacin.
Propiedades no
funcionales
Son necesarias para
simular la conducta
runtime, analizar la
conducta de los
componenentes, imponer
restricciones, mapear
implementaciones sobre
procesadores
determinados
------

Ahora que ya tienes claro los elementos, te invitamos a comprender el siguiente tema de
las vistas de la arquitectura y no olvides comentar a tu facilitador las dudas que tengas
durante tu estudio en la unidad.

1.1.2 Vistas de la arquitectura

En la AS no todo est homogenizado ni es igual para todo en cuestiones de vistas de
arquitectura de software, as tambin la opinin de acadmicos y organismos reconocidos
como ISO, IEEE,ACM, IBM, por mencionar algunos, no han presentado alguna definicin
de las vistas. Por ello las recomendaciones de los frameworks o marcos de trabajo se
usan tpicamente para basarse en las vistas y se usan con mucho respeto, pero igual con
algo de recelo, como ya se mencion antes, por parte de los involucrados; estos mismos
marcos de trabajo y modelos arquitectnicos acostumbran ordenar las diferentes
perspectivas de una arquitectura en trminos de vistas.

Entonces decimos que las vistas de una arquitectura pueden entenderse como un
subconjunto resultante de practicar una seleccin o abstraccin sobre una realidad, desde
un punto de vista determinado para aplicarlo en la solucin al problema presentado por
los requerimientos del cliente.
De manera ms concreta, las vistas de una arquitectura dan el sentido de las partes que
conformarn la aplicacin; como la mejor manera de dividir las operaciones que realizar
la solucin de software, facilitando su entendimiento y mantenimiento.

De una manera ms coloquial, imagina que tuvieras la necesidad de cocinar un pastel.
Las vistas de este pastel sern:
Ingredientes y preparacin de la cobertura.

11

11
Ingredientes y preparacin del interior del pastel.
Recipiente de presentacin/almacenamiento.

Es decir, cmo se ve, cmo se hace y cmo se har uso de l; no confundir con los pasos
para su elaboracin.

Existen muchas opiniones de las vistas de arquitectura. Hay comits muy reputados junto
con sus propuestas como RM-ODP, RUP, RDS, MDA, MOF, MEMO, XMI o IEEE 1471-
2000.

No se har un anlisis exhaustivo de las vistas que propone cada uno de estos comits,
solo mencionaremos que las vistas de una arquitectura describen, de manera lgica y de
sentido comn, la divisin del trabajo total que har la aplicacin de software. Esta
descripcin es muy cercana en cuanto a sus pasos a cualquier metodologa de desarrollo
de software.

La vista ms simple que se puede presentar es:
Lgica
Conceptual
Fsica

Estos tres puntos mencionados describen de manera simple pero relevante y en trminos
muy bsicos lo que una arquitectura denota en su vista alcanzar la solucin
conceptualizada por el arquitecto.

1.1.3. Conjunto tpico de las vistas de una arquitectura.

Con el conocimiento conceptual de qu es una vista, ahora se precisar mejor el
significado arquitectnico de las vistas y el para qu proporcionar un amplio conocimiento
sobre estas.

La expresin mltiples vistas significa que la solucin de software tiene dentro de s
muchas partes independientes pero colaborativas que la conforman, sta representa lo
ms importante para la ingeniera de software y los requerimientos de sistemas.

Las razones para ello son variadas: en primer lugar, no existe una fundamentacin
coherente para su uso en la disciplina; en segundo trmino, muchos estudiosos las
consideran problemticas, porque la existencia de mltiples vistas introduce problemas de
integracin y consistencia entre las diferentes vistas. Sin embargo, los arquitectos

12

12
practicantes las usan de todas maneras, porque simplifican la visualizacin de sistemas
complejos (Reynoso, 2004).

La conceptualizacin y la abstraccin de un sistema (de cualquier tipo) no son originarias
de la AS, sino que se trata de una teora ms amplia que se aplica y se conoce como
anlisis sistmico. La necesidad de dividir el trabajo resultante de cualquier desarrollo de
software es muy simple: que cada parte haga el trabajo que le corresponda sin
entrometerse en la participacin del otro, aunque tengan (o deban tener) comunicacin.

Existe un problema comn en AS, que consiste en tratar de solventar un problema cuya
complejidad sea muy alta por el elevado nmero de reglas de negocio que debe atender
con el desarrollo de software que est conformado por una sola pieza nica e indivisible,
provocando que sea intratable e inmantenible, por ello el arquitecto, quien es el
encargado de modelar soluciones fiables, propone dividir las complejidades a diferentes
vistas para dividir la citada complejidad y hacer el acercamiento hacia la solucin ms fcil
para l y para quienes estarn participando en etapas posteriores del ciclo de vida del
desarrollo del software.

Si se pudieran dividir las vistas de la AS se podra obtener dos versiones segn el mbito
de aplicacin: el normal y el referido desde UML.

En seguida se presenta a manera de tabla la relacin de ambas versiones.

rea Vista Diagrama Concepto principal
Estructural
Vista Esttica Diagrama de clases Clase, asociacin,
generalizacin,
dependencia,
realizacin, interfaz
Vista de casos de
uso
Diagrama de casos
de uso
Caso de uso, actor,
asociacin,
extensin, inclusin,
generalizacin de
casos de uso
Vista de
implementacin
Diagrama de
componentes
Componente,
interfaz,
dependencia,
realizacin
Vista de despliegue Diagrama de
despliegue
Nodo, componente,
dependencia,
localizacin
Dinmica Vista de mquinas Diagrama de Estado, evento,

13

13
de estados estados transicin, accin
Vista de actividad Diagrama de
actividad
Estado, actividad,
transicin de
terminacin,
divisin, unin
Vista de interaccin
Diagrama de
secuencia
Interaccin, objeto,
mensaje, activacin
Diagrama de
colaboracin
Colaboracin,
interaccin, rol de
colaboracin,
mensaje
Gestin del
modelo
Vista de gestin del
modelo
Diagrama de clases Paquete,
subsistema, modelo

La propuesta de vistas no tiene lmites en cuanto cantidad y orden refirindose a la
aplicacin de ellas a la solucin de cualquier problema.

Podra dedicarse mucho tiempo a discutir el concepto y la conformacin de las diferentes
vistas, y de hecho los numerosos simposios que ha habido sobre la manera en cmo
deben usarse las vistas de una arquitectura han sido de inters, mas no han definido
conclusiones sobre el mtodo correcto ni estndar de hacerlo.

Se acostumbra poner las vistas que denotan niveles de abstraccin en cuadros
superpuestos, por ejemplo, como si fueran anlogas a las capas del modelo OSI, pero:
Son ambas representaciones estrictamente homlogas?, Constituye el conjunto de las
vistas un sistema?, por qu cada vez que se enumeran los artefactos caractersticos de
cada vista aparece la palabra etctera o la expresin elementos principales?(Reynoso,
2004).

Estos niveles de abstraccin (vistas) si pueden considerarse como una representacin
homloga del modelo OSI, pero no en su sentido ms estricto, pues ambas denotan un
orden jerrquico de superposicin donde los niveles inferiores soportan los superiores y
sin la existencia de ellos no se pueden siquiera pensar en la colocacin de los niveles de
orden superior. Adems, este conjunto de vistas slo puede considerar sistema si hay
cooperacin entre las distintas vistas para llegar a un fin (dictado por los requerimientos
dados por el cliente).

1.2. El enfoque arquitectnico


14

14
Siempre se debe tener una perspectiva de lo que se va a realizar en cualquier situacin, y
en el mundo del software no es una excepcin. Un enfoque arquitectnico se debe
entender como la capacidad de arquitecto de software para poder describir un problema,
este problema o problemas vienen derivados de los requerimientos que el cliente pide
para poder satisfacer su necesidad, en trminos de un lenguaje comnmente aceptado y
con los trminos adecuados, es decir, saber cmo modelar un software desde el punto
de vista estructural.

Para lo anterior se deben tener patrones arquitectnicos a los cuales adherirse, stos nos
darn la pauta para poder tener una gua sobre cul es la mejor manera de solventar la
situacin que presentan los requerimientos del cliente, basado en experiencias anteriores
al resolver problemas similares con la finalidad de poder describir de manera correcta
una estructura que soportara al software (a la solucin) por completo.

1.2.1. Patrones de arquitectura

Cuando se enfrenta la problemtica sobre cmo se estructurar la AS para solventar
determinada situacin, se hace uso de los patrones de arquitectura, pues ellos dan una
clara descripcin de los componentes del sistema y las relaciones que se tienen.

Respecto del prrafo anterior, un patrn de arquitectura deber entenderse como una
gua que ofrecen solucin a determinados problemas ya conocidos, respecto a
problemticas fundadas en la ingeniera de software. Tambin expresa de manera clara la
relacin que hay entre los componentes de una solucin basada en software y su
esquema de organizacin estructural, incluyendo todos los subsistemas y acciones que
deber realizar cada uno de ellos, adems de la manera correcta de comunicar el
resultado de esas acciones entre los mismos componentes, entre vistas o con otros
sistemas externos.

Los patrones arquitectnicos sirven tambin para describir las restricciones que tienen los
mdulos que comprendern al sistema, por ejemplo en la manera de comunicarse, la
seguridad que deber implementar el sistema para resguardar los datos, de qu manera
viajarn estos datos y por qu protocolo de transmisin se har.

Las relaciones entre los mdulos, las vistas y los sistemas externos dan la estructura
necesaria para pasar de cualquier sistema de software a forma de esquema (grfico o
no); la estructura, expresa de forma clara la composicin total del sistema de software,
pudiendo ser de un nivel de abstraccin muy alto hasta poder llegar a representarse de
manera muy detallada, a diferencia de los ADLs.

Nota: Los ADLs y los patrones arquitectnicos son complementarios.

15

15

Cabe aclarar que la utilizacin de patrones de arquitectura no es en s la arquitectura
completa, pues como se ha mencionado, solo dan una descripcin de la organizacin de
sus componentes y relaciones que carecen de sentido de representacin de detalles en la
comunicacin de datos.

Debe considerarse a la AS como una conjuncin de todos los elementos hasta ahora
descritos (ADLs, patrones arquitectnicos, vistas) que harn una AS completa y robusta;
por ejemplo, hablando de diferentes sistemas con diferentes arquitecturas, entre ellas
pueden usar los mismos patrones arquitectnicos y tener ms facilidad para la integracin
entre ellos. Imagina que un estudiante de arquitectura (la arquitectura tradicional) est
encargado de elaborar un proyecto completo para un edificio; los patrones arquitectnicos
que l utilice debern describir de manera clara cmo estar conformado el edificio, y lo
ms importante: qu relacin tendr con otros edificios y con el ambiente en el cual se
encuentra.

La calidad en el desarrollo de software se ve beneficiada de manera muy importante con
los patrones arquitectnicos, pues dentro de ellos, por definicin, se resuelven muchos
problemas de rendimiento, de comunicacin, de transacciones, entre otros.

1.2.2. La arquitectura ubicada en el proceso de software

El proceso de desarrollo de software debe entenderse como un mtodo ordenado donde
se describe paso por paso lo que se har y cmo se har al momento de administrar un
proyecto de desarrollo de software. Estos pasos que se mencionan deben estar incluidos
a un proceso o metodologa ampliamente aceptada, que de manera clara, se pueda
ubicar y secuenciar lo necesario para poder llevar a cabo un proyecto de desarrollo de
software.

Algunas metodologas se clasifican por su extensin y mbito. Hay metodologas giles,
predictivas y descriptivas. A continuacin se menciona una metodologa comnmente
usada en la industria del desarrollo del software, y que define de manera clara cmo se
debe administrar un proyecto desde su concepcin hasta su implementacin: se trata de
la metodologa RUP.

La metodologa RUP (del ingls RationalUnifiedProcess) distingue varios pasos (fases)
que se deben completar para poder decir que se realiz la administracin del desarrollo
de un proyecto de software:
Venta
Planeacin

16

16
Anlisis
Diseo
Construccin
Pruebas
Implementacin

Es importante aclarar que cada una de estas las etapas son especficas de RUP, pero no
difieren mucho de una teora ampliamente aceptada e implementada por el proceso
administrativo.

La parte donde se involucra directamente la AS es en la etapa del Diseo de software,
pues en sta llegan desde la fase anterior (anlisis) los requerimientos que el cliente pide,
y a partir de ellos es que se podr comenzar a elaborar la mejor arquitectura a
consideracin del arquitecto.

Para tener de manera ms clara la ubicacin fsica de la AS dentro del modelo presentado
por RUP, se muestra la siguiente imagen donde se seala la etapa de Diseo, junto con
las etapas antecesoras y predecesoras:

En la imagen anterior la etiqueta AS denota la ubicacin fsica del proceso de
elaboracin de la arquitectura del software y se ve claramente el impacto que tendr en la
calidad del software completo, pues si no se hace de manera correcta, aunque el anlisis
haya sido aceptado por el cliente, al llegar a la etapa de construccin se llevarn una serie
de errores (fsicos, lgicos, de implementacin, entre otros) y el resultado final estar
destinado al fracaso.

No se debe confundir el diseo del software con la elaboracin de la arquitectura, pues
sta misma es una parte (sub etapa) de la fase del diseo del software. Una no sustituye
a la otra, sino que forma parte de ella.

A continuacin te presentamos la actividad de Lenguaje descriptor de
arquitectura, que a diferencia de otros cuatrimestres, a partir de ste
podrs consultar los criterios de evaluacin de cada una de las actividades.

AS

17

17

Actividad 2. Lenguaje descriptor de arquitectura

Despus de haber comprendido la AS podrs realizar esta actividad que tiene la finalidad
de identificar los principales lenguajes de descripcin de arquitecturas y sus
caractersticas para hacer de manera individual una descripcin de estos elementos.

En seguida realiza las siguientes instrucciones:

1. Identifica y describe qu es un lenguaje descriptor de arquitecturas.
2. Elabora una lista de manera tabular al menos 5 lenguajes descriptores de
arquitectura, incluyendo sus principales caractersticas.
3. En un archivo de texto, coloca los elementos solicitados en los puntos1 y 2.
4. Guarda la actividad con el nombre DRS_U1_A2_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y
la Z por la inicial de tu segundo apellido.
5. Ingresa al apartado de Tareas.
6. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

Actividad 3. Patrones de arquitectura de software

Para esta actividad es importante tener presente los trminos estudiados durante esta
unidad, ya que tiene la finalidad de identificar los principales patrones de arquitectura de
software y distinguir de manera personal sus principales caractersticas, haciendo una
descripcin de estos elementos. Por ello presta atencin a lo que a continuacin se te
solicita:

Instrucciones:

1. Identifica y describe qu es un patrn de arquitectura.
2. Redacta una lista de manera tabular para cada patrn de arquitectura, incluyendo
sus principales caractersticas.
3. En un archivo de texto, coloca los elementos solicitados en los puntos 1 y 2.
4. Guarda la actividad con el nombre DRS_U1_A3_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tuprimer apellido y la
Z por la inicial de tu segundo apellido.
5. Ingresa al apartado de Tareas.
6. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.


18

18

Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
primera unidad del curso, es necesario que resuelvas el cuestionario de Autoevaluacin.
Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y
elegir la opcin adecuada para cada uno.

Evidencia de aprendizaje. Lenguaje descriptor y patrones de
arquitectura de software

Como parte de la evaluacin de esta unidad, es necesario realizar un reporte donde se
explique y distinga los diferentes patrones de arquitectura de software, as como los
lenguajes descriptores de arquitectura y su aplicacin a cada modelo, de manera que
investigues patrones y lenguajes que no se hayan incluido en el desarrollo de esta primer
unidad.

1. Identifica y describe los diferentes lenguajes descriptores de arquitectura y agrega
la utilidad que tiene.
2. Identifica y describe los patrones de arquitectura y agrega la utilidad que tienen.
3. Elabora ejemplos de uso de la combinacin de lenguajes y patrones y describe
cada ejemplo (mnimo 2).
4. Investiga la aplicacin de lenguajes y patrones que no se hayan presentado en el
desarrollo de la unidad.
5. En un archivo de texto, redacta un reporte con los elementos solicitados en los
puntos 1, 2, 3 y 4.
6. Guarda la actividad con el nombre DRS_U1_EA_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y
la Z por la inicial de tu segundo apellido.
7. Enva el archivo a tu Facilitador(a) a travs de la seccin Evidencia de
aprendizaje.
8. Consulta la escala de evaluacin para conocer los parmetros de la actividad.

Autorreflexiones

Adems de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexin y consultes las interrogantes que presenta tu
Facilitador(a), a partir de ellas elabora tu Autorreflexin en un archivo de texto llamado
DRS_U1_ATR_XXYZ. Recuerda sustituirlas XX por las dos primeras letras de tu primer

19

19
nombre, la Y por la inicial de tuprimer apellido y la Z por la inicial de tu segundo
apellido.Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad

Has concluido la primera unidad del curso. A travs de una revisin cronolgica te has
introducido al conocimiento de los principales lenguajes descriptores de arquitectura y su
posible aplicacin al mbito real; tambin has estudiado la forma de cmo distinguir y
aplicar los diferentes patrones arquitectnicos.

La comprensin total de los ejemplos y definiciones presentadas a lo largo de la unidad
ser de importancia para las materias siguientes y para su correcta utilizacin en
ambientes de produccin real.

Es aconsejable que revises nuevamente la unidad en caso de que los temas que se
acaban de mencionar no te sean familiares o no los recuerdes, de no ser este tu caso, ya
ests preparado(a) para seguir con la unidad dos, en donde continuars con la revisin de
los modelos de arquitectura ms utilizados. Todo ello con el fin de obtener el conocimiento
necesario para comenzar a realizar propuestas de arquitectura al final de la unidad 2.

Para saber ms

Es importante que identifiques un software de cdigo libre y realices una descripcin
formal de arquitectura basndote en un lenguaje de definicin de arquitectura, instlalo
en tu computadora personal para que realices pruebas de descripcin y veas la aplicacin
de los conceptos presentados.

Fuentes de consulta

Bass, L., Clemens, P., Kazman, R. (2003). Software Architecture in Practice (2
Ed.). Estados Unidos: Addison Wesley.
Reynoso, C., Kicillof, N (2004). Lenguajes de Descripcin de Arquitectura.
Argentina: Universidad de Buenos Aires.

Unidad 1. Arquitectura

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 1. Arquitectura

Cargado por

Copyright:

Formatos disponibles

Diseo y Arquitectura de Software

También podría gustarte