Вы находитесь на странице: 1из 19

Diseo y Arquitectura de Software

Unidad 1. Arquitectura

Ingeniera en Desarrollo de software 5 Cuatrimestre

Programa de la asignatura: Diseo y Arquitectura de Software Unidad 1. Arquitectura

Clave: 150920517

Universidad abierta y a distancia de Mxico

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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: 3 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 3

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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 4 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 4

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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. 6 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 6

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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.

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

Componentes Interfaz Tipos Semntica Restricciones Evolucin Propiedades no funcionales

Conectores Interfaz Tipos Semntica Restricciones Evolucin Propiedades no funcionales

Configuraciones arquitectnicas Comprensibilidad Composicionalidad Heterogeneidad Restricciones Refinamiento y trazabilidad Escalabilidad Evolucin Dinamismo Propiedades no funcionales

Soporte de herramientas Especificacin activa Mltiples vistas Anlisis Refinamiento Generacin de cdigo Dinamismo

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 Componentes (descripciones de caja y-linea) Definicin Elementos computacionales primarios de un sistema. Se exponen en diferentes interfaces, que definen la interaccin de un componente y entorno. Interacciones entre componentes. Se exponen en diferentes interfaces, que definen los roles de los componente que participan en la interaccin. Compuestos como grafos de componentes y conectores. Algunos ejemplos ms comunes Clientes, base de datos, servidores, filtros, objetos, pizarras.

Conectores (descripciones de caja y-linea)

Tuberas (pipes), protocolos clienteservidor, broadcast de eventos.

Configuraciones o sistemas

---------------------

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

Propiedades.

Restricciones

Estilos

Evolucin

La topologa del sistema se define de forma aparte de los componentes y conectores en los ADLs ms avanzados. Los sistemas pueden ser jerrquicos. 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. Representan condiciones de diseo de acuerdo a las evoluciones en el tiempo. Una restriccin comn seria las configuraciones topolgicas admisibles. Representan: familias de sistemas, vocabulario de tipos de elementos de diseo y reglas para componerlos. Algunos prescriben un framework o patrones arquitectnicos 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

Troughput y la latencia probables, cuestiones de seguridad, dependencias de bibliotecas o configuraciones mnima de hardware y tolerancia a fallas.

El nmero de clientes que se conectan al mismo tiempo a un servicio.

Arquitecturas deflujo de datos basados en tuberas y filtros, sistemas en capas.

----

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

Propiedades no funcionales

son los de diseo arquitectnico sino los de programacin. 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. 10 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 10

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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 Vista Esttica Diagrama Diagrama de clases Concepto principal Clase, asociacin, generalizacin, dependencia, realizacin, interfaz Caso de uso, actor, asociacin, extensin, inclusin, generalizacin de casos de uso Componente, interfaz, dependencia, realizacin Nodo, componente, dependencia, localizacin Estado, evento, 12 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 12

Vista de casos de uso Estructural Vista de implementacin

Diagrama de casos de uso

Diagrama de componentes

Vista de despliegue

Diagrama de despliegue Diagrama de

Dinmica

Vista de mquinas

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

de estados Vista de actividad

estados Diagrama de actividad

Vista de interaccin

Diagrama de secuencia Diagrama de colaboracin

Gestin del modelo

Vista de gestin del modelo

Diagrama de clases

transicin, accin Estado, actividad, transicin de terminacin, divisin, unin Interaccin, objeto, mensaje, activacin Colaboracin, interaccin, rol de colaboracin, mensaje 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


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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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. 14 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 14

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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 15 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 15

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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:

AS

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. 16 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 16

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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.

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

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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 18 Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 18

Diseo y Arquitectura de Software


Unidad 1. Arquitectura

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.

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

Вам также может понравиться