REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA DEFENSA UNIVERSIDAD NACIONAL EXPERIMENTAL DE LAS FUERZAS ARMADAS

Introduccin a la Arquitectura del Software

Elaborado Por: ALEXANDER PULIDOJOS SUREZ CRISTIAN AGUILAR ROSNIER NAVAS JOSEPH CARACHE

SANTA DE CORO, MARZO DE 2012

NDICE pp Portada ndice Introduccin Desarrollo04 Arquitectura del Software..04 Antecedentes Histricos....04 Definicin y Delimitacin..09 Campos de la Arquitectura del Software11 Modalidades y Tendencias...13 Diferencias entre Arquitectura y Diseo15 Problemas pendientes en la Arquitectura del Software.16 Relevancia de la Arquitectura de Software..17 Importancia y Elementos que la Componen20 Especificaciones, Vistas Arquitectnicas.....21 Niveles de Diseo del Software.22 Estado Actual de la Tecnologa..24 Conclusin.26 Bibliografa.27

INTRODUCCIN Es la representacin que capacita al ingeniero del software para: Analizar la efectividad del diseo para la consecucin de los requisitos

fijados. Considerar las alternativas arquitectnicas en una etapa en la cual

hacer cambios en el diseo es relativamente fcil. Reducir los riesgos asociados a la construccin del software.

En el diseo arquitectnico, un componente del software puede ser tan simple como un mdulo de programa, pero tambin puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuracin de una red de clientes y servidores. Desde de la dcada de los el concepto de arquitectura del software se fue formando, siendo una tendencia subestimada y rechazada , logr sobrevivir para convertirse en una parte esencial del desarrollo de sistemas de la actualidad. No slo permite realizar los tres (3) puntos que se mencionaron en prrafos anteriores, sino que adems es el primer requisito para todo sistema que se piense realizar a gran escala. Las bases de la Arquitectura del Software fueron realizadas por Edsger Dijkstra, David Parnas y Fred Brooks sin embargo, no fue hasta 1992 que el trmino fue aceptado como tal con el ensayo realizado por Perry y Wolf. Desde la publicacin de ese trabajo, el trmino de arquitectura, que era ambiguo y desordenado, tom fuerza y su influencia ha aumentado de manera impresionante hasta la actualidad. El presente trabajo dar una introduccin a la Arquitectura del Software, explicando de manera bsica los trminos que maneja, sus caractersticas, modelos y la importancia de su existencia dentro del mbito de la ingeniera.

DESARROLLO

Arquitectura del Software La arquitectura de software de un programa o sistema de computadora, es la estructura de ese sistema, que incluye componentes de software, las propiedades visibles externas de esos componentes, y las relaciones entre estos. El trmino tambin puede incluir la documentacin sobre la arquitectura de software del sistema. Una arquitectura software consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construccin del software para un sistema de informacin.

Antecedentes Histricos Si bien la AS se remonta, al menos hasta la dcada de 1960, su historia no ha sido continua como la del campo ms amplio en el que se inscribe, la ingeniera de software. Despus de las tempranas inspiraciones del legendario Edsger Dijkstra, de David Parnas y de Fred Brooks, la AS qued en estado de vida latente durante unos cuantos aos, hasta comenzar su expansin explosiva con los manifiestos de Dewayne Perry de AT&T Bell Laboratories de New Jersey y Alexander Wolf de la Universidad de Colorado Puede decirse que Perry y Wolf fundaron la disciplina, y su llamamiento fue respondido en primera instancia por los miembros de lo que podra llamarse la escuela estructuralista de Carnegie Mellon: David Garlan, Mary Shaw, Paul Clements, Robert Allen. Cada vez que se narra la historia de la arquitectura de software (o de la ingeniera de software, segn el caso), se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de la Universidad Tecnolgica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una estructuracin correcta de los sistemas de software antes de lanzarse a programar, escribiendo cdigo de cualquier manera.
4

Dijkstra, quien sostena que las ciencias de la computacin eran una rama aplicada de las matemticas y sugera seguir pasos formales para descomponer problemas mayores, fue uno de los introductores de la nocin de sistemas operativos organizados en capas que se comunican slo con las capas adyacentes y que se superponen como capas de cebolla. Invent o ayud a precisar adems docenas de conceptos: el algoritmo del camino ms corto, los stacks, los vectores, los semforos, los abrazos mortales. De sus ensayos arranca la tradicin de hacer referencia a niveles de abstraccin que ha sido tan comn en la arquitectura subsiguiente. Aunque Dijkstra no utiliza el trmino arquitectura para describir el diseo conceptual del software, sus conceptos sientan las bases para lo que luego expresaran otros pioneros de la materia. Por unos aos, arquitectura fue una metfora de la que se ech mano cada tanto, pero sin precisin semntica ni consistencia pragmtica. En 1969 Fred Brooks Jr y Ken Iverson llamaban arquitectura a la estructura conceptual de un sistema en la perspectiva del programador. En 1971, C. R. Spooner titul uno de sus ensayos Una arquitectura de software para los 70s, sin que la mayor parte de la historiografa de la AS registrara ese antecedente. En 1975, Brooks, diseador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el concepto de arquitectura del sistema para designar la especificacin completa y detallada de la interfaz de usuario y consideraba que el arquitecto es un agente del usuario, igual que lo es quien disea su casa , empleando una nomenclatura que ya nadie aplica de ese modo. En el mismo texto, identificaba y razonaba sobre las estructuras de alto nivel y reconoca la importancia de las decisiones tomadas a ese nivel de diseo. Tambin distingua entre arquitectura e implementacin; mientras aquella deca qu hacer, la implementacin se ocupa de cmo. Aunque el concepto de AS actual y el de Brooks difieren en no escasa medida, el texto de Brooks
5

The mythical man-month sigue siendo, un cuarto de siglo ms tarde, el ms ledo en ingeniera de software. Se ha sealado que Dijkstra y Brooks, el primero partidario de un formalismo matemtico y el segundo de considerar las variables humanas, constituyen dos personalidades opuestas, que se sitan en los orgenes de las metodologas fuertes y de las heterodoxias giles, respectivamente. Una novedad importante en la dcada de 1970 fue el advenimiento del diseo estructurado y de los primeros modelos explcitos de desarrollo de software. Estos modelos comenzaron a basarse en una estrategia ms orgnica, evolutiva, cclica, dejando atrs las metforas del desarrollo en cascada que se inspiraban ms bien en la lnea de montaje de la ingeniera del hardware y la manufactura. Surgieron entonces las primeras

investigaciones acadmicas en materia de diseo de sistemas complejos o intensivos. Poco a poco el diseo se fue independizando de la implementacin, y se forjaron herramientas, tcnicas y lenguajes de modelado especficos. En la misma poca, otro precursor importante, David Parnas, demostr que los criterios seleccionados en la descomposicin de un sistema impactan en la estructura de los programas y propuso diversos principios de diseo que deban seguirse a fin de obtener una estructura adecuada. En 1972, Parnas public un ensayo en el que discuta la forma en que la modularidad en el diseo de sistemas poda mejorar la flexibilidad y el control conceptual del sistema, acortando los tiempos de desarrollo. Introdujo entonces el concepto de ocultamiento de informacin

(information hiding), uno de los principios de diseo fundamentales en diseo de software an en la actualidad. La herencia de este concepto en la ingeniera y la arquitectura ulterior es inmensa, y se confunde estrechamente con la idea de abstraccin. El concepto de ocultamiento se fue mezclando con encapsulamiento y abstraccin, tras algunos avatares de avance y
6

retroceso.

Los

arquitectos

ms

escrupulosos

distinguen

entre

encapsulamiento y ocultamiento, considerando a aqul como una capacidad de los lenguajes de programacin y a ste como un principio ms general de diseo. De hecho, Parnas no hablaba en trminos de programacin orientada a objeto, sino de mdulos y sub-rutinas, porque el momento de los objetos no haba llegado todava. El pensamiento de Parnas sobre familias de programas, en particular, anticipa ideas que luego habran de desarrollarse a propsito de los estilos de arquitectura: Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o lo sern alguna vez) a los cuales es provechoso o til considerar como grupo. Esto evita el uso de conceptos ambiguos tales como similitud funcional que surgen a veces cuando se describen dominios. Por ejemplo, los ambientes de ingeniera de software y los juegos de video no se consideran usualmente en el mismo dominio, aunque podran considerarse miembros de la misma familia de programas en una discusin sobre herramientas que ayuden a construir interfaces grficas, que casualmente ambos utilizan. Una familia de programas puede enumerarse en principio mediante la especificacin del rbol de decisin que se atraviesa para llegar a cada miembro de la familia. Las hojas del rbol representan sistemas ejecutables. El concepto soporta la nocin de derivar un miembro de la familia a partir de uno ya existente. El procedimiento consiste en seguir hacia atrs el rbol hasta que se alcanza un nodo (punto de decisin) genealgicamente comn a ambos, y luego proceder hacia abajo hasta llegar al miembro deseado. El concepto tambin soporta la nocin de derivar varios miembros de la familia de un punto de decisin comn, aclarando la semejanza y las diferencias entre ellos.

En la dcada de 1980, los mtodos de desarrollo estructurado demostraron no escalar suficientemente y fueron dejando el lugar a un nuevo paradigma, el de la programacin orientada a objetos. En teora, pareca posible modelar el dominio del problema y el de la solucin en un lenguaje de implementacin. La investigacin que llev a lo que despus sera el diseo orientado a objetos puede remontarse incluso a la dcada de 1960 con Simula, un lenguaje de programacin de simulaciones, el primero que proporcionaba tipos de datos abstractos y clases, y despus fue refinada con el advenimiento de Smalltalk. Paralelamente, hacia fines de la dcada de 1980 y comienzos de la siguiente, la expresin arquitectura de software comienza a aparecer en la literatura para hacer referencia a la configuracin morfolgica de una aplicacin. El primer estudio en que aparece la expresin arquitectura de software en el sentido en que hoy lo conocemos es sin duda el de Perry y Wolf; ocurri en 1992, aunque el trabajo se fue gestando desde 1989. En l, los autores proponen concebir la AS por analoga con la arquitectura de edificios, una analoga de la que luego algunos abusaron, otros encontraron til y para unos pocos ha devenido inaceptable. Los autores pusieron en claro que el diseo es una actividad separada de la implementacin y que requiere notaciones, tcnicas y herramientas especiales. Considerada como disciplina por mrito propio, la AS ha de ser, para ellos, beneficiosa como marco de referencia para satisfacer requerimientos, una base esencial para la estimacin de costos y administracin del proceso y para el anlisis de las dependencias y la consistencia del sistema. Dando cumplimiento a las profecas de Perry y Wolf, la dcada de 1990 fue sin duda la de la consolidacin y diseminacin de la AS en una escala sin precedentes. Las contribuciones ms importantes surgieron en torno del instituto de ingeniera de la informacin de la Universidad Carnegie Mellon (CMU SEI), antes que de cualesquiera organismos de industria. En la misma
8

dcada,

demasiado

prdiga

en

acontecimientos,

surge

tambin

la

programacin basada en componentes, que en su momento de mayor impacto impuls a algunos arquitectos mayores, como Paul Clements [Cle96b], a afirmar que la AS promova un modelo que deba ser ms de integracin de componentes pre-programados que de programacin. En la arquitectura, la idea dominante es la de re-utilizacin. A impulsos de otra idea mayor de la poca (la crisis del software), la bibliografa sobre el impacto econmico de la re-utilizacin alcanza hoy magnitudes de cuatro dgitos. Como quiera que sea, la AS de este perodo realiz su trabajo de homogeneizacin de la terminologa, desarroll la tipificacin de los estilos arquitectnicos y elabor lenguajes de descripcin de arquitectura (ADLs)

Definicin y Delimitacin No es novedad que ninguna definicin de la AS es respaldada unnimemente por la totalidad de los arquitectos. Una definicin reconocida es la de Clements: La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones. Existe en general acuerdo de que ella se refiere a la estructura a grandes rasgos del sistema, estructura consistente en componentes y relaciones entre ellos. Estas cuestiones estructurales se vinculan con el diseo, pues la AS es despus de todo una forma de diseo de software que se manifiesta tempranamente en el proceso de creacin de un sistema; pero este diseo

ocurre a un nivel ms abstracto que el de los algoritmos y las estructuras de datos. Sin embargo, la definicin ms aceptada es: La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin. Obsrvese entonces que la nocin clave de la arquitectura es la organizacin (un concepto cualitativo o estructural). Cabe destacar que existen varios modelos que poseen definiciones propias de la arquitectura, los cuales resultan interesantes pues, demuestra que de acuerdo al enfoque que se le d, la AS puede tomar diferentes elementos. Entre dichos modelos destacan: 1) Modelos estructurales: Sostienen que la AS est compuesta por componentes, conexiones entre ellos y (usualmente) otros aspectos tales como configuracin, estilo, restricciones, semntica, anlisis, propiedades, racionalizaciones, requerimientos, necesidades de los participantes. El trabajo en esta rea est caracterizada por el desarrollo de lenguajes de descripcin arquitectnica (ADLs). 2) Modelos de framework: Son similares a la vista estructural, pero su nfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composicin. Los modelos de framework a menudo se refieren a dominios o clases de problemas especficos. El trabajo que ejemplifica esta variante incluye arquitecturas de software especficas de dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes especficos, como PRISM. 3) Modelos dinmicos: Enfatizan la cualidad conductual de los sistemas. Dinmico puede referirse a los cambios en la configuracin del sistema, o a la dinmica involucrada en el progreso de la computacin, tales como valores cambiantes de datos.

10

4) Modelos de proceso: Se concentran en la construccin de la arquitectura, y en los pasos o procesos involucrados en esa construccin. En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el actual trabajo sobre programacin de procesos para derivar arquitecturas. 5) Modelos funcionales: Una minora considera la arquitectura como un conjunto de componentes funcionales, organizados en capas que

proporcionan servicios hacia arriba. Es tal vez til pensar en esta visin como un framework particular. Ninguna de estas vistas excluye a las otras, ni representa un conflicto fundamental sobre lo que es o debe ser la AS. Por el contrario, representan un espectro en la comunidad de investigacin sobre distintos nfasis que pueden aplicarse a la arquitectura: sobre sus partes constituyentes, su totalidad, la forma en que se comporta una vez construida, o el proceso de su construccin.

Campos de la Arquitectura del Software La AS es hoy en da un conjunto inmenso y heterogneo de reas de investigacin terica y de formulacin prctica, por lo que conviene enumerar algunos de sus campos y sus focos. La AS comenz siendo una abstraccin descriptiva puntual que en los primeros aos no investig de manera sistemtica ni las relaciones que la vinculaban con los requerimientos previos, ni los pasos metodolgicos a dar luego para comenzar a componer el diseo. David Garlan y Dewayne Perry enumeran las siguientes reas de investigacin Lenguajes de descripcin de arquitecturas Fundamentos formales de la AS (bases matemticas,

caracterizaciones formales de propiedades extra-funcionales tales como mantenibilidad, teoras de la interconexin, etctera).

11

Tcnicas de anlisis arquitectnicas Mtodos de desarrollo basados en arquitectura Recuperacin y reutilizacin de arquitectura Codificacin y gua arquitectnica Herramientas y ambientes de diseo arquitectnico Estudios de casos

Paul Clements, por otro lado, define cinco temas fundamentales en torno de los cuales se agrupa la disciplina: Diseo o seleccin de la arquitectura: Cmo crear o seleccionar una arquitectura en base de requerimientos funcionales, de rendimiento o de calidad. Representacin de la arquitectura: Cmo comunicar una arquitectura. Este problema se ha manifestado como el problema de la representacin de arquitecturas utilizando recursos lingsticos, pero el problema tambin incluye la seleccin del conjunto de informacin a ser comunicada. Evaluacin y anlisis de la arquitectura: Cmo analizar una arquitectura para predecir cualidades del sistema en que se manifiesta. Un problema semejante es cmo comparar y escoger entre diversas arquitecturas en competencia. Desarrollo y evolucin basados en arquitectura: Cmo construir y mantener un sistema dada una representacin de la cual se cree que es la arquitectura que resolver el problema correspondiente. Recuperacin de la arquitectura: Cmo hacer que un sistema legacy evolucione cuando los cambios afectan su estructura; para los sistemas de los que se carezca de documentacin confiable, esto involucra primero una arqueologa arquitectnica que extraiga su arquitectura.

12

Modalidades y Tendencias En la dcada de 1990 se establece definitivamente la AS como un dominio todava hoy separado de manera confusa de ese marco global que es la ingeniera y de esa prctica puntual que es el diseo. La divisin preliminar de escuelas de AS que proponemos es la siguiente: 1. Arquitectura como etapa de ingeniera y diseo orientada a objetos. En esta postura, la arquitectura se restringe a las fases iniciales y preliminares del proceso y concierne a los niveles ms elevados de abstraccin, pero no est sistemticamente ligada al requerimiento que viene antes o a la composicin del diseo que viene despus. Lo que sigue al momento arquitectnico es business as usual, y a cualquier configuracin, topologa o morfologa de las piezas del sistema se la llama arquitectura. En esta escuela, si bien se reconoce el valor primordial de la abstraccin (nadie despus de Dijkstra osara oponerse a ello) y del ocultamiento de informacin promovido por Parnas, estos conceptos tienen que ver ms con el encapsulamiento en clases y objetos que con la visin de conjunto arquitectnica. 2. Arquitectura estructural, basada en un modelo esttico de estilos, ADLs y vistas. Se trata de la visin de la AS dominante en la academia, y aunque es la que ha hecho el esfuerzo ms importante por el reconocimiento de la AS como disciplina, sus categoras y herramientas son todava mal conocidas en la prctica industrial. En principio se pueden reconocer tres modalidades en cuanto a la formalizacin; los ms informales utilizan descripciones verbales o diagramas de cajas, los de talante intermedio se sirven de ADLs y los ms exigentes usan lenguajes formales de especificacin como CHAM y Z. En
13

toda la corriente, el diseo arquitectnico no slo es el de ms alto nivel de abstraccin, sino que adems no tiene por qu coincidir con la configuracin explcita de las aplicaciones. 3. Estructuralismo arquitectnico radical. Se trata de un desprendimiento de la corriente anterior, mayoritariamente europeo, que asume una actitud ms confrontativa con el mundo UML. 4. Arquitectura basada en patrones. Esta corriente surgida hacia 1996 no se encuentra tan rgidamente vinculada a UML en el modelado, ni a CMM en la metodologa. En esta manifestacin de la AS prevalece cierta tolerancia hacia modelos de proceso tctico, no tan macroscpico, y eventualmente se expresa cierta simpata por las ideas de Martin Fowler y las premisas de la programacin extrema. El diseo consiste en identificar y articular patrones preexistentes, que se definen en forma parecida a los estilos de arquitectura 5. Arquitectura procesual. Intenta establecer modelos de ciclo de vida y tcnicas de elicitacin de requerimientos, brainstorming, diseo, anlisis, seleccin de alternativas, validacin, comparacin, estimacin de calidad y justificacin econmica especficas para la arquitectura de software. 6. Arquitectura basada en escenarios. Es la corriente ms nueva. Se trata de un movimiento predominantemente europeo, con centro en Holanda. Recupera el nexo de la AS con los requerimientos y la funcionalidad del sistema En esta corriente suele utilizarse diagramas de casos de uso UML como herramienta informal u

14

ocasional, dado que los casos de uso son uno de los escenarios posibles. Los casos de uso no estn orientados a objeto.

Diferencias entre Arquitectura y Diseo Existen tres (3) posturas referentes a la Arquitectura del Software:

1) Una postura afirma que arquitectura y diseo son lo mismo. 2) Otra, en cambio, alega que la arquitectura se encuentra en un nivel de abstraccin por encima del diseo, o es simplemente otro paso (un artefacto) en el proceso de desarrollo de software. 3) Una tercera establece que la arquitectura es algo nuevo y en alguna medida diferente del diseo (pero de qu manera y en qu medida se dejan sin especificar). Para Shaw y Garlan la AS es el primer paso en la produccin de un diseo de software, en una secuencia que distingue tres pasos: 1) Arquitectura. Asocia las capacidades del sistema especificadas en el requerimiento con los componentes del sistema que habrn de implementarla. La descripcin arquitectnica incluye componentes y conectores (en trminos de estilos) y la definicin de operadores que crean sistemas a partir de subsistemas o, en otros trminos, componen estilos complejos a partir de estilos simples. 2) Diseo del cdigo. Comprende algoritmos y estructuras de datos; los componentes son aqu primitivas del lenguaje de programacin, tales como nmeros, caracteres, punteros e hilos de control. Tambin hay operadores primitivos.

15

3) Diseo ejecutable. Remite al diseo de cdigo a un nivel de detalle todava ms bajo y trata cuestiones tales como la asignacin de memoria, los formatos de datos, etctera. Problemas pendientes en la Arquitectura del Software Aunque la evaluacin dominante de la trayectoria de la AS es abiertamente positiva, en los primeros aos del siglo comienzan a percibirse desacuerdos y frustraciones en el proyecto de la disciplina. Por empezar, est muy claro que la definicin original del proyecto, formulada en crculos acadmicos, guarda poca relacin con la imagen que se tiene de la AS en las prcticas de la industria. Adems, un nmero desmesurado de artculos y ponencias destaca asimismo la frustracin que muchos sienten por no haber podido consensuar una definicin de la AS universalmente aceptada.

Otros aspectos negativos fueron destacados por Clements y Northrop, entre ellos: Los abogados de las distintas posturas traen sus sesgos consigo. En

efecto, mientras las definiciones propuestas para la AS coinciden en su ncleo, difieren seriamente en los bordes. Algunos autores requieren que la arquitectura incluya racionalizacin, otros piden ms bien pasos para el proceso de construccin. Algunos exigen que se identifique la funcionalidad de los componentes, otros alegan que una simple topologa es suficiente. En la lectura de los textos de AS se torna esencial entonces conocer la motivacin de sus responsables. El estudio de la AS est siguiendo a la prctica, no liderndola. El

estudio de la AS ha evolucionado de la observacin de los principios de diseo y las acciones que toman los diseadores cuando trabajan en sistemas de la vida real. La AS es un intento de abstraer los rasgos comunes

16

inherentes al diseo de sistemas, y como tal debe dar cuenta de un amplio rango de actividades, conceptos, mtodos, estrategias y resultados. Lo que en realidad sucede es que la AS se redefine constantemente en funcin de lo que hacen los programadores. El estudio es sumamente nuevo. Aunque sus races se prolongan en

el tiempo, el campo de la AS es realmente muy nuevo, segn puede juzgarse de la reciente avalancha de libros, conferencias, talleres y literatura consagrada a ella. Las fundamentaciones han sido imprecisas. El campo se ha

destacado por la proliferacin de trminos inciertos, verdaderas amenazas para los no precavidos. Por ejemplo, la arquitectura definida como la estructura global de un sistema agrega confusin en lugar de reducirla, porque implica que un sistema posee una sola estructura. El trmino se ha usado en exceso. El significado de la palabra arquitectura en su relacin con la ingeniera de software se ha ido diluyendo simplemente porque parece estar de moda. Es posible encontrar referencias a las siguientes clases de arquitectura: sistemas, especfica redes, de dominio,

megaprogramacin,

destinatario,

infraestructura,

aplicaciones, operaciones, tcnica, framework, conceptual, de referencia, empresarial, de factora, C4I, de manufactura, de edificio, de mquinaherramienta, etctera. A menudo la palabra arquitectura se usa de maneras inapropiadas. Relevancia de la Arquitectura de Software La AS ha resultado instrumental en un nmero respetable de escenarios reduciendo costos, evitando errores, encontrando fallas, implementando sistemas de misin crtica. Cada uno de los documentos que describen lenguajes de descripcin arquitectnica, por ejemplo, subraya su utilizacin exitosa en proyectos de gran envergadura requeridos por organizaciones de

17

gobierno o por grandes empresas. Aun cuando aqu y all se sealen dificultades ocasionales, nadie duda de la necesidad de una visin arquitectnica. Escribe Barry Boehm, especialista mximo en gestin de riesgo y bien conocido creador del COCOMO y del mtodo de desarrollo en espiral: Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su justificacin, el proyecto no debe empezar el desarrollo en gran escala. Si se especifica la arquitectura como un elemento a entregar, se la puede usar a lo largo de los procesos de desarrollo y mantenimiento. Adems, la AS trae consigo una gran cantidad de beneficios como: 1. Comunicacin mutua. La AS representa un alto nivel de abstraccin comn que la mayora de los participantes, si no todos, pueden usar como base para crear entendimiento mutuo, formar consenso y comunicarse entre s. En sus mejores expresiones, la descripcin arquitectnica expone las restricciones de alto nivel sobre el diseo del sistema, as como la justificacin de decisiones arquitectnicas fundamentales. 2. Decisiones tempranas de diseo. La AS representa la encarnacin de las decisiones de diseo ms tempranas sobre un sistema, y esos vnculos tempranos tienen un peso fuera de toda proporcin en su gravedad individual con respecto al desarrollo restante del sistema, su servicio en el despliegue y su vida de mantenimiento. La arquitectura representa lo que el mtodo SAAM una puerta de peaje: el desarrollo no puede proseguir hasta que los participantes involucrados aprueben su diseo. 3. Restricciones proporciona constructivas. parciales Una para el descripcin desarrollo, arquitectnica indicando los

blueprints

componentes y las dependencias entre ellos. Por ejemplo, una vista en capas de un arquitectura documenta tpicamente los lmites de abstraccin

18

entre las partes, identificando las principales interfaces y estableciendo las formas en que unas partes pueden interactuar con otras. 4. Reutilizacin, o abstraccin transferible de un sistema. La AS encarna un modelo relativamente pequeo, intelectualmente tratable, de la forma en que un sistema se estructura y sus componentes se entienden entre s; este modelo es transferible a travs de sistemas; en particular, se puede aplicar a otros sistemas que exhiben requerimientos parecidos y puede promover reutilizacin en gran escala. El diseo arquitectnico soporta reutilizacin de grandes componentes o incluso de frameworks en el que se pueden integrar componentes. 5. Evolucin. La AS puede exponer las dimensiones a lo largo de las cuales puede esperarse que evolucione un sistema. Haciendo explcitas estas paredes perdurables, quienes mantienen un sistema pueden comprender mejor las ramificaciones de los cambios y estimar con mayor precisin los costos de las modificaciones. Esas delimitaciones ayudan tambin a establecer mecanismos de conexin que permiten manejar requerimientos cambiantes de interoperabilidad, prototipado y reutilizacin. 6. Anlisis. Las descripciones arquitectnicas aportan nuevas

oportunidades para el anlisis, incluyendo verificaciones de consistencia del sistema, conformidad con las restricciones impuestas por un estilo, conformidad con atributos de calidad, anlisis de dependencias y anlisis especficos de dominio y negocios. 7. Administracin. La experiencia demuestra que los proyectos exitosos consideran una arquitectura viable como un logro clave del proceso de desarrollo industrial. La evaluacin crtica de una arquitectura conduce tpicamente a una comprensin ms clara de los requerimientos, las estrategias de implementacin y los riegos potenciales.

19

Importancia y Elementos que la Componen Es importante ya que la arquitectura del software se define como la estructura del sistema y esta estructura se constituye como componentes, mdulos o piezas de cdigo que nacen de la nocin de abstraccin, cumpliendo funciones especificas e interactuando entre si con un comportamiento definido. La arquitectura del software puede considerarse entonces como el puente entre los requerimientos del sistema y la implementacin. Adems, como se mencion anteriormente, la arquitectura del software compone a una fase inicial del diseo de sistema, donde se definen realmente las interacciones de los componentes que lo conforman en base a los requerimientos. Por otro lado, la AS permite Analizar la efectividad del diseo para la consecucin de los requisitos fijados. Considerar las alternativas arquitectnicas en una etapa en la cual hacer cambios en el diseo es relativamente fcil. Reducir los riesgos asociados a la construccin del software.

En el diseo arquitectnico, un componente del software puede ser tan simple como un mdulo de programa, pero tambin puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuracin de una red de clientes y servidores.

Elementos que la conforman: Se entiende por componentes los bloques de construccin que conforman las partes de un sistema de software. A nivel de lenguajes de programacin, puede ser representado como mdulos, clases, objetos o un conjunto de funciones relacionadas. La nocin de componente puede llegar a ser muy amplia; el trmino puede ser utilizado para especificar un conjunto de componentes.

20

Se distinguen tres tipos de componentes, denominados tambin elementos que son: Elementos de datos: contienen la informacin que ser transformada. Elementos de proceso: transforman los elementos de datos. Elementos de conexin: llamados tambin conectores, que bien puede

ser elementos de datos o proceso, y mantienen las diferentes piezas de la arquitectura.

Especificaciones, Vistas Arquitectnicas De acuerdo al nivel de responsabilidad dentro del desarrollo de un sistema y la relacin que se establezca con el mismo, son muchas las partes involucradas e interesadas en la arquitectura de software (Kruchten, 1999), a saber: 1) El analista del sistema, quien la utiliza para organizar y expresar

claramente los requerimientos y entender las restricciones de tecnologa y los riesgos. 2) Usuarios finales y clientes, que necesitan conocer el sistema que

estn adquiriendo. 3) El gerente de proyecto, que la utiliza para organizar el equipo y

planificar el desarrollo. 4) Los diseadores, que lo utilizan para entender los principios

subyacentes y localizar los lmites de su propio diseo. 5) Otras organizaciones desarrolladoras (si el sistema es abierto), que la

utilizan para entender cmo interactuar con el sistema. 6) Las compaas subcontratadas, que la utilizan para entender los

lmites de su seccin de desarrollo. 7) Los arquitectos, quienes velan por la evolucin del sistema y la

reutilizacin de componentes.

21

Todas estas personas deben comunicarse de manera efectiva para discutir y razonar acerca de la arquitectura, y as alcanzar las metas del desarrollo. En virtud de esto, Kruchten (1999) plantea que debe tenerse una representacin del sistema que todos puedan comprender.

Niveles de Diseo del Software El diseo de la arquitectura del software tiene en cuenta 2 niveles, el diseo de datos y el diseo arquitectnico. El diseo de datos nos facilita la representacin de los componentes de datos de la arquitectura. El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e interacciones. 1) Diseo de Datos. El diseo de datos tambin llamado arquitectura de datos, crea un modelo de datos y/o informacin que se representa con un nivel de abstraccin (visin de datos cliente/usuario). Este modelo de datos, es refinado en progresivas representaciones especficas de la implementacin, que pueden ser procesadas por un sistema basado en computadora. Al nivel de los componentes del programa, el diseo de las estructuras de datos y de los algoritmos asociados requeridos para su manipulacin, son la parte esencial en la creacin de aplicaciones de alta calidad. Al nivel de aplicacin, la traduccin de un modelo de datos en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema. Al nivel de negocios, el conjunto de informacin almacenada en las diferentes bases de datos y reorganiza en el almacn de datos facilita la minera de datos o el descubrimiento de conocimiento que puede influir en el prximo xito del negocio.

22

2) Diseo Arquitectnico. Cada estilo describe una categora del sistema que contiene: un conjunto de componentes, que realiza una funcin requerida por el sistema, un conjunto de conectores que posibilitan la comunicacin, la coordinacin y la cooperacin entre los componentes; restricciones que definen como se puede integrar los componentes que forman el sistema; y modelos semnticos que permiten al diseador entender las propiedades globales de un sistema para analizar las propiedades conocidas de sus partes constituyentes. Arquitecturas centradas a datos

En el centro de esta arquitectura se encuentra un almacn al que otros componentes acceden con frecuencia para actualizar, aadir, borrar o modificar los datos del almacn. El software del cliente accede a l almacn central, es decir accede a lo datos independientes de cualquier cambio en los datos o de las acciones de de cliente. Arquitecturas de flujo de datos

Se aplica cuando los datos de entrada son transformados a travs de una serie de componentes computacionales o manipulativos en los datos de salida. Un patrn tubera y filtro tiene un grupo de componentes llamados filtros, conectados por tuberas que transmiten datos de un componente al siguiente. El filtro est diseado para recibir entrada de datos de una forma y producir la salida de datos de una forma especfica. Si el flujo de datos degenera en una simple lnea de transformadores se le llama Secuencial por Lotes.

23

Arquitecturas de llamada y retorno

Permite al diseador del software construir una estructura de programa relativamente fcil de modificar y ajustar a escala. Existen 2 subestilos: Arquitectura de programa principal: Clasifica de programacin descompone las funciones en una jerarqua de control donde un programa principal llama a un nmero de componentes del programa, los cuales pueden tambin llamar a otros componentes. Arquitectura de llamada de procedimiento remoto: Los componentes de una arquitectura de programa principal/subprograma, estn distribuidos entre varias computadoras en una red.

Arquitecturas orientadas a objetos

Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos. La comunicacin y la coordinacin entre componentes se consiguen a travs del paso de mensaje. Se Arquitecturas Estratificadas crean diferentes capas y cada una realiza operaciones que

progresivamente se aproximan mas al cuadro de instrucciones de la maquina. En la capa externa, los componentes sirven a las operaciones de interfaz de usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las capas intermedias proporcionan servicios de utilidad y funciones de software de aplicaciones.

Estado Actual de la Tecnologa La tecnologa siempre ha sido parte de la sociedad, si tomamos el concepto del trmino anteriormente mencionado (tecnologa) de forma

24

general, podremos darnos cuenta que, en forma amplia; todo avance logrado por el hombre se debe a la tecnologa. No hay que encerrarse en la definicin de tecnologa como se ve actualmente, sino en como ha ido evolucionando a lo largo de los aos debido a la capacidad del ser humano para adaptarse al medio. Por ejemplo, el descubrimiento accidental del fuego o de la rueda en cierta forma, son una forma de tecnologa que luego sera aprovechada por la humanidad para facilitar las tareas o las dificultades que se presentaban en la poca. Dicho esto, y enfocndose en el mbito que maneja la carrera de ingeniera en sistemas, puede verse que hay un avance cada vez ms acelerado por la parte computacional y Web. Desde la dcada de los aos 60 hasta la actualidad ha sido una evolucin constante, tanto es as, que los expertos no creen que vuelva a haber una revolucin en el mbito de los ordenadores y se quedar en la 5ta Generacin. Es una realidad que, la tecnologa se ha adaptado a la sociedad y viceversa, y las empresas la han aprovechado para agilizar y hacer ms eficiente la resolucin de problemas y necesidades de la poblacin general pues, el objetivo principal de la existencia de la tecnologa consiste en buscar la forma ms rpida y sencilla de resolver un problema. Actualmente se vive en una era tecnolgica y seguir de esta manera; debido a que facilitan en gran medida la vida diaria, el internet es la viva prueba de ello. Sin embargo hay que destacar que el mal uso de la tecnologa puede traer serias consecuencias, algunas de ellas ya estn en manifiesto actualmente. Por otro lado se debe destacar que el avance tecnolgico actualmente es extremadamente rpido, a pasado de ser cada ao a ser cada 6 meses. Lo ideal es que se encuentre un equilibrio a la hora de usar la tecnologa de manera tal que no dae el planeta de forma permanente.

25

CONCLUSIN La arquitectura del software nos proporciona una visin global del sistema a construir. Por otro lado se ha evidenciado que, los componentes del software incluyen mdulos de programas y varias representaciones de datos que son manipulados por el programa. Y an ms importante, la arquitectura marca decisiones de diseo tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas. La AS Posee antecedentes que datan desde la dcada de los 60, donde surgieron las tendencias de que un sistema no se deba hacer por separado mediante similitudes de mtodos debido a que estaban condenados al fracaso y la ineficiencia; se necesitaba de un paradigma o un plan que analizara bien los requerimientos en la fase ms primordial del diseo, y dictar los lineamientos que guiaran el diseo estructurado y posterior implantacin del Sistema. Pese a las afirmaciones de la poca no fue hasta diez aos despus, que se tom en cuenta la tendencia que diferenciaba al diseo de la arquitectura como tal (aunque el trmino no se manejaba), y hasta la dcada de los 90, el concepto de Arquitectura del Software no fue una realidad. Sin embargo, el paradigma y la tendencia creci rpidamente y, aunque todava no hay un concepto universal del trmino, es evidente que la Arquitectura del Software corresponde a la parte inicial y primordial del diseo de software y es la principal causante de beneficios como reduccin de costos, evita errores, descubrimiento de fallas, entre otros. Esto deja claro que, la AS est destinado ha convertirse en un paradigma esencial de todo diseo de sistemas y que ignorar el trmino, es un error fatal.

26

BIBLIOGRAFA http://www.slideshare.net/jose_rob/diseo-de-la-arquitectura-delsoftware http://www.mitecnologico.com/Main/Dise%F1oArquitecturaDelSoftware prof.usb.ve/lmendoza/Documentos/PS-6116/Guia Arquitectura v.2.pdf http://www.alegsa.com.ar/Dic/arquitectura%20de%20software.php www.hacienda.go.cr/centro/datos/Articulo/Introducci%C3%B3n%20a% 20la%20Arquitectura%20de%20Software.doc http://es.scribd.com/doc/54216012/13/Diferencias-entre-Arquitectura-yDiseno http://www.buenastareas.com/ensayos/Arquitectura-Del-Software-EnCapas/962028.html http://es.scribd.com/doc/54216012/11/Campos-de-la-Arquitectura-deSoftware http://es.wikipedia.org/wiki/Arquitectura_de_software

27