ARQUITECTURA DE SOFTWARE Es la serie de decisiones que debemos tomar al momento de implementar un sistema de software esto incluye componentes, principios y fundamentos entre otros, con sus responsabilidades y efectos que influyen en su respectivo desarrollo y la estructura del sistema. Debemos tener en cuenta el funcionamiento e interacción entre las partes del software y el hardware el cual nos forma un marco de referencia necesario para su correcto desarrollo e implementación.

1. ANTECEDENTES HISTÓRICOS

Se empieza a pensar en la idea de arquitectura de software en 1960 por algunos círculos de investigación y en 1969 por la OTAN pero toma popularidad en 1990 tras reconocerse la crisis del software convirtiéndose esta en la década de la arquitectura del software. Academia de Carnegie Mellon. Su historia no ha sido tan continua como la ingeniería de software pero ha empezado a tomar fuerza en los últimos años.en un principio, hacia 1968, Edsger Dijkstra, aunque él no empezó a utilizar el término de arquitectura. Perry y Wolf en 1992 construye el fundamento para la arquitectura de software.

2. DEFINICIONES Y DELIMITACIÓN DE LA DISCIPLINA

Existen grandes compilaciones de definiciones pero una de las más reconocidas es la de Clements dice que es una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema.

Buscando una definición más extensa, David Garlan dice:” La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes. Los autores clasifican los modelos de esta forma:

1) Modelos estructurales 2) Modelos de framework 3) Modelos dinámicos 4) Modelos de proceso 5) Modelos funcionales

3. CONCEPTOS FUNDAMENTALES

Más allá de que hoy existan numerosos conceptos en el plano detallado de las técnicas y metodologías, la arquitectura de software se basa en unos pocos concepciones y elementos básicos y unas pocas instrumentales especiales.

Estilos: Un estilo es un concepto descriptivo que define una forma de articulación u organización arquitectónica.

Lenguajes de descripción arquitectónica: conjunto de propuestas de variado nivel de rigurosidad, todas ellas de estirpe académico.

Frameworks y Vistas: La mayoría de los frameworks y estrategias reconoce entre tres y seis vistas, son las que se encierran en el cuadro. Una vista es, para concretar brevemente, un subconjunto consecuencia de hacer una selección o preocupación sobre un entorno, desde un punto de vista determinado

Procesos y Metodologías: corresponden con las perspectivas particulares de los diferentes participantes.

Abstracción: radica en extraer las pertenencias esenciales, o equiparar los aspectos transcendentales, o explorar selectivamente ciertos talentes de un problema, olvidando o ignorando los datos menos sustanciales, distractivos o notables.

Escenarios: han sido esencialmente técnicas que se hacen en la elicitación de las obligaciones, exclusivamente en relación a los especialistas de sistemas.

4. CAMPOS DE LA ARQUITECTURA DE SOFTWARE

Es un conjunto inmenso y heterogéneo de áreas de investigación teórica y de formulación práctica.

Lenguajes de descripción de arquitecturas Fundamentos formales de la AS (bases matemáticas, determinaciones formales de pertenencias extra- utilitarias tales como mantenibilidad, supuestos de la interconexión, etcétera). Técnicas de análisis arquitectónicas Métodos de desarrollo basados en arquitectura Recuperación y reutilización de arquitectura Codificación y guía arquitectónica. Herramientas y ambientes de diseño arquitectónico

Paul Clements [Cle96b] define cinco temas fundamentales en torno de los cuales se agrupa la disciplina.

Diseño o elección de la arquitectura: Cómo erigir o preferir una arquitectura en base de exigencias funcionales, de ganancia o de calidad.

Escritura de la arquitectura: Cómo informar una arquitectura. Este complicación se ha mostrado como el problema de la carácter de arquitecturas manejando recursos filológicos, pero la dificultad también encierra la selección del ligado de información a ser anunciada.

Evaluación y estudios de la arquitectura: Cómo razonar una arquitectura para adivinar cualidades del procedimiento en que se revela. Un problema semejante es cómo confrontar y escoger entre varias arquitecturas en competitividad.

Desarrollo y maniobra basados en arquitectura: Cómo montar y conservar un sistema dada uncarácter de la cual se cree que es la arquitectura que satisfará el problema conveniente.

Independencia de la arquitectura: Cómo hacer que un sistema legacy despliegue cuando los cambios perturban su estructura; para los sistemas de los que se escasee de expediente confiable, esto envuelve primero una “arqueología arquitectónica” que desentierre su arquitectura.

5. MODALIDADES Y TENDENCIAS

Arquitectura como etapa de ingeniería y diseño orientada a objetos: etapa de ingeniería y diseño orientada a objetos. Es el patrón de James Rumbaugh, Ivar Jacobson, Grady Booch, Craig Larman y otros, combinado apretadamente al universo de UML y Rational. No cabe incertidumbre que se conoce de una corriente concreta.

Arquitectura organizada, asentada en un tipo detenido de estilos, ADLs y vistas: es una corriente fundacional y clásica de la disciplina.

Estructuralismo arquitectónico radical: es una actitud más confrontativa con el mundo con dos tendencias; una que excluye de plano la relevancia del modelado orientado a objetos para la arquitectura de software y otra que procura definir nuevos metamodelos y estereotipos de UML como correctivos de la situación.

Arquitectura basada en patrones: esta variante reconoce como referencia la serie POSA de Buschmann, predomina cierta pasividad hacia tipos de proceso estratégicos.

Arquitectura procesual: se intenta establecer modelos de ciclo de vida y técnicas de elicitación de requerimientos, brainstorming, diseño, análisis, selección de dilemas, validación, comparación, apreciación de calidad y apología económica concretas para la construcción de software.

Arquitectura basada en escenarios: es la corriente más nueva. En este estándar suele esgrimir diagramas de temas de uso UML como herramienta inconstante u ocasional, dado que los asuntos de uso son uno de los teatros posibles. Los casos de uso no están orientados a objetos.

6. DIFERENCIAS ENTRE ARQUITECTURA Y DISEÑO

La ingeniería de software estudia los principios y las metodologías de desarrollo de software. Es la diligencia del juicio científico al esquema y fábrica de software y toda la expediente requerida para desplegar, operar y conservarlo. En si la técnica de software es una Ciencia. Mientras que la construcción de software es solamente la colocación o distribución del programa. Es expresar el croquis del presentación desde los esquemas, diagramas, elección de lenguaje, elección de inconstantes para el programa, en si la representación total de que llevara a cabo el programa y de qué forma. Dicho de otra forma la ingeniería de software comprende todos las técnicas correspondidos para desarrollar programas y dentro de esos métodos se encuentra la arquitectura del software.

7. RELEVANCIA DE LA ARQUITECTURA DE SOFTWARE

Comunicación mutua. La AS personifica un alto nivel de meditación común que la generalidad de las colaboradoras, si no todos, pueden utilizar como asiento para crear intelecto mutuo, formar consentimiento y notificar entre sí. En sus mejores palabras, la representación arquitectónica exhibe las prohibiciones de alto ras sobre el croquis del sistema, así como la defensa de medidas arquitectónicas principales.

Decisiones anticipadas de diseño. La AS representa la representación de las arbitrajes de croquis más adelantados sobre un sistema, y esos vínculos adelantados tienen un compromiso fuera de toda simetría en su dificultad propia con respecto al perfeccionamiento restante del sistema, su asistencia en el expansión y su vida de sostenimiento. La arquitectura figura lo que la regla SAAM un portón de canon: el desarrollo no puede subsistir hasta que los partícipes involucrados certifiquen su diseño.

Limitaciones constructivas. Un retrato arquitectónico provee blueprints improcedentes para el avance, indicando los mecanismos y las obediencias entre ellos. Por ejemplo, un panorama en capas de una construcción documenta típicamente los fines de ensimismamiento entre las piezas, nivelando las importantes interfaces instituyendo las formas en que unas piezas pueden interactuar las demás.

Reutilización, o contemplación transferible de un procedimiento. La AS incorpora un modelo comparativamente pequeño, intuitivamente tratable, del carácter en que un sistema se organización y sus componentes se hallan entre sí; esta guía es transferible a través de sistemas; en particular, se puede aplicar a otros sistemas que exteriorizan amonestaciones parecidos y puede originar reutilización en gran

escalafón. El esquema arquitectónico aguanta reutilización de grandes dispositivos o incluso de frameworks en el que se pueden integrar dispositivos.

Evolución. La AS puede exponer las extensiones a lo largo de las cuales puede esperarse que aumente un sistema. Haciendo evidentes estas “paredes” perpetuas, quienes conservan un sistema pueden percibir mejor las derivaciones de los cambios y evaluar con mayor claridad los costos de las transformaciones. Esas demarcaciones ayudan también a instituir mecanismos de enlace que permiten manejar exigencias cambiantes de interoperabilidad, prototipado y nueva utilización tilización.

Análisis. Las representaciones arquitectónicas aportan sucesos y congruencias para el análisis, conteniendo verificaciones de firmeza del sistema, aprobación con las restricciones imputadas por un estilo, conformidad con propiedades de calidad, exámenes de dependencias y exámenes específicos de mando y negocios.

Administración. La experiencia manifiesta que los proyectos triunfantes consideran una arquitectura realizable como una ganancia clave del transcurso de progreso industrial. La valoración crítica de una arquitectura transporta típicamente a una penetración más clara de los requerimientos, las estrategias de ejecución y los riegos permisibles.

BERNARDO RUEDA HERNANDEZ LUIS FELIPE MANCILLA MURILLO