DOCENTEEVA MORA COLORADO

TRABAJO INVESTIGACION

ESTUDIANTEJESUS VIDAL RODRIGUEZ

CARRERAINGENIERÍA EN SISTEMAS

COMPUTACIONALES

MATERIAARQUITECTURA Y DISEÑO DE SOFTWARE

FECHA DE REVISIÓN TIERRA BLANCA, VER. 07 DE DICIEMBRE DE 2015

INSTITUTO TECNOLÓGICO SUPERIOR DE TIERRA

BLANCA

INTRODUCCIÓN

El diseño arquitectónico comienza con el diseño de datos y después procede a la derivación de una o modelos de arquitecturas de software, normalmente incluye la producción de modelos gráficos del sistema y conduce a una gran cantidad de documentación de diseños.La arquitectura no es el software operacional. Más bien, es la representación que capacita al ingeniero del software para: Analizar la efectividad del diseño para la consecución de los requisitos fijados a considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil. Reducir los riesgos asociados a la construcción del software.

5.1 LÍNEAS DE PRODUCTOS DE SOFTWARE

Si miramos al sistema de producción de las lavadoras, por poner un ejemplo, laPersonalización en serie se consigue mediante la introducción de la cadena de montaje o línea de producto. El objetivo: sacar partido de los elementos comunes y gestionar de una manera eficaz las variaciones. En lugar de permitir la máxima flexibilidad que permite el proceso artesanal pero con grandes costes, las líneas de producto delimitan las variantes de sus productos a un conjunto preestablecido, y optimizan los procesos para estas variantes.En la producción de software, el proceso ha venido estando centrado en el producto antes que en la línea de montaje. Las herramientas de desarrollo (IDE) y las metodologías ayudaban a agilizar y sistematizar la creación de un único producto. Sí que existe una inquietud por reutilizar pero en la mayor parte de los casos, la reutilización es oportunista, es decir, surgía la posibilidad de reutilizar a posteriori, no era algo que se supiera positivamente que se iba a poder reutilizar. Por ello, muchos esfuerzos de re-utilización no se amortizaban ya que no terminaba de surgir la oportunidad para poder reutilizarlo. Esta situación cambia con las líneas de producto. Ahora ya no se quiere producir un único producto, sino una cadena de montaje que gestione eficiente y eficazmente las diferentes variaciones que pueden existir entre los productos. La empresa ya no se centra en un producto para un cliente (por ejemplo, construir un portal para Iberia), sino en un dominio (por ejemplo, construir portales para líneas aéreas). El reto está en delimitar el ámbito de este dominio, identificar las variaciones que se van a soportar, y dotarse de la infraestructura que permita producir el producto a bajo coste pero manteniendo altas cuotas de calidad. Es decir, aplicar los principios de la producción en serie también al software.

Este enfoque resulta en mejoras tanto en la eficiencia (reducción del time-to-market) como en la eficacia (mejora de la calidad del software). Entre los precursores de este enfoque en el mundo del software se encuentran McIllory (1968), Parnas (1976) y Neighbors (1989) que en sus trabajos ya intuían el potencial de estas ideas.Las Líneas de Producto Software (LPS) pueden por tanto englobarse dentro de ese anhelo recurrente dentro de la Ingeniería del Software que es la reutilización. Pero nos han recordado que mejorar la reutilización no lleva necesariamente a reducir los costes globales de desarrollo debido a los costes adicionales de desarrollar (y gestionar) precisamente estos artefactos re-usables. Las LPS han vuelto a recordarnos que la reutilización eficaz no es sólo un problema técnico, sino también de procesos y organización. El proceso determina cuándo y dónde se debe realizar el esfuerzo de reutilización.La decisión no es baladí. De hecho, muchos de los fracasos en el desarrollo basado en componentes (también orientado a la reutilización) se deben a fallos en el proceso, más que en las técnicas que se utilizaban: se invertían esfuerzos en hacer el componente reutilizable para determinadas situaciones que finalmente no se presentaban.

Así mismo, las LPS suponen una importante reorganización de los equipos humanos. De estar orientados al producto pasan a pivotar sobre la LPS. Aquí pueden surgir tensiones entre los desarrolladores de los artefactos comunes (o reutilizables) frente a aquellos encargados de desarrollar el producto con estos artefactos. ¿Qué ocurre ante nuevas peticiones del cliente no contempladas hasta entonces? Si la planificación no se cumple o se detecta algún error, ¿a qué equipo se le imputa el coste? ¿Cómo se reparten las responsabilidades/presupuestos entre los dos tipos de equipos?

Los "métodos estructurados" son un conjunto de notaciones y lineamientos para el diseño de software que propone un enfoque metódico. Ejemplos de estos métodos son el Diseño Estructurado (Constantine y Yourdon, 1979), el Análisis Estructurado de Sistemas (Gane y Sardon, 1979). EL Desarrollo de Sistemas de Jackson (Jackson, 1983) y los diversos enfoques de diseño orientado a objetos (Robinson, 1992; Booch, 1994; Rumbaugh et al., 1991; Boch et al 1999 Rumbaugh et al 1999 a. 1999 b).

El uso de métodos estructurados normalmente incluye la producción de modelos gráficos del sistema y conduce a una gran cantidad de documentación de diseños .Las herramientas CASE se han desarrollado para ayudar a métodos particulares. Los métodos estructurados se han aplicado exitosamente en muchos proyectos grandes. Comprenden gran reducción en los costos debido al uso de notaciones estándar y aseguran la producción de documentación estándar del diseño. No se puede demostrar que algún método sea mejor o peor que otro. A menudo, el éxito de los métodos depende de que éstos sean apropiados para un dominio de aplicación.

Un método estructurado incluye un modelo de proceso de diseño, notaciones para representar el diseño, formatos de informes, reglas y lineamientos de diseño. Aunque exista una gran variedad de métodos, todos tiene mucho en común. Los métodos estructurados ayudan a todos o alguno de los siguientes modelos de un sistema:

1. Un modelo de flujo de datos en el que el sistema se modela utilizando la

transformación de datos que tiene lugar cuando se procesan.

2. Un modelo entidad-relación el cual se utiliza para describir las entidades

fundamentales en el diseño y las relaciones entre ellas.

Los modelos entidad-relación son la técnica normal que se para describir las

estructuras.

3. Un modelo estructural en el cual se documentan los componentes del sistema y

interacciones.

4. Los métodos orientados a objetos incluyen un modelo de herencia del sistema,

modelos de relaciones estáticas y dinámicas entre los objetos y un modelo de

interacción de los objetos cuando el sistema se ejecuta.

Algunos métodos particulares complementan éstos con otros modelos del sistema, como diagramas de transición de estados, narrativos del periodo de vida de una entidad que muestran la manera en que ésta se transforma y procesa, etcétera. Muchos métodos sugieren el uso de un depósito para la información del sistema o de un diccionario de datos. En la práctica, la guía que proporciona los métodos es informal, de tal manera que diferentes diseñadores desarrollan diferentes diseños. Estos "métodos" son realmente notaciones estándar que comprenden prácticas aceptables. Si se siguen y aplican estos métodos, puede surgir un diseño razonable. La creatividad del diseñador se requiere para decidir la descomposición del sistema y asegurar que el diseño capture de forma adecuada la especificación del mismo.

Los estudios empíricos de los diseñadores (Bansler y Bodker, 1993) raramente siguen los métodos convencionales. Seleccionan y eliminan temas de los lineamientos, dependiendo de las circunstancias locales.

5.2 ARQUITECTURAS ORIENTADAS A SERVICIOS.

La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones  SOA  han sido creadas para satisfacer los objetivos de negocio las cuales incluyen facilidad y flexibilidad de integración con sistemas legados, alineación directa a los procesos de negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil ante cambios incluyendo reacción temprana ante la competitividad.1

Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.

Actualmente es común utilizar un enfoque orientado a objetos para el desarrollo completo del software, en particular para el desarrollo de sistemas interactivos. Estos significa expresar los requerimientos del sistema utilizando un modelo de objetos llevar a cabo el diseño utilizando objetos y desarrollar el sistema en un lenguaje de programación orientado a objetos como Java o C++.

Los modelos de objetos desarrollados durante el análisis de requerimientos se utilizan para representar los datos del sistema y su procesamiento. A este respecto, combinan algunas de las formas de utilización de los modelos de flujo de datos y semánticos de datos. También son útiles para mostrar la manera en que las entidades en el sistema se clasifican y se componen de otras entidades.

Para algunas clases de sistemas, los modelos de objetos son la forma natural de reflejar las entidades del mundo real que manipulan el sistema. Esto es particularmente cierto cuando el sistema procesa información de entidades concretas como autos, aviones, libros etcétera, los cueles tienen atributos claramente identificados. De forma más abstracta, las entidades de alto nivel, como el concepto de biblioteca, un sistema médico o un procesador de texto difíciles de modelar como clases de objetos. No necesariamente tienen una interfaz sencilla que éste compuesta de atributos y operaciones independientes.

Indudablemente, los modelos de objetos desarrollados durante el análisis de requerimientos simplifican la transición al diseño y programación orientados a objetos. Sin embargo, a menudo se observa que los usuarios finales de un sistema encuentran dichos modelos poco naturales y difíciles de comprender. Frecuentemente, prefieren adoptar una visión más funcional del procesamiento de datos. Por lo tanto, algunas veces es de gran ayuda complementar dichos modelos con los flujos de datos que muestran el procesamiento de datos en el sistema.

Una clase de objetos es una abstracción sobre un conjunto de objetos que identifican los atributos comunes ( como el modelo semántico de datos ) y los servicios u operaciones que provee cada objeto. Los objetos son entidades ejecutables con los atributos y servicios de la clase de objetos. Éstos son instancias de dicha clase, de tal forma que se puedan crear diferentes objetos a partir de una clase. De forma general los modelos desarrollados se centran en estas clases y sus relaciones.

Los modelos de sistemas que se desarrollan durante el análisis de requerimientos modelan entidades del mundo real utilizando clases de objetos. No incluyen detalles de los objetos individuales del sistema. Se pueden producir varios tipos de modelos de objetos que muestran la manera en que las clases se relacionan entre ellas, la manera en que los objetos se agregan para formar otros, como interactúan con otros, etcétera. Todo esto se puede agregar a la compresión del sistema que se especifica.

Modelos de Herencia.

El modelado orientado a objetos implica la identificación de clases de objetos que son importantes en el dominio de estudio. Estos objetos se organizan en una taxonomía. Una taxonomía es un esquema de clasificación que muestra la manera en que una clase de objetos está relacionada con otras clases a través de atributos y servicios comunes.

Para desplegar esta taxonomía, las clases se organizan en una jerarquía de herencia en la que las clases de objetos más generales se encuentran en la parte alta de la jerarquía. Los objetos más especializados heredan sus atributos y servicios. Estos objetos tienen sus propios atributos y servicios.

En la notación UML, la herencia se muestra hacía arriba y no hacia abajo como en otras notaciones orientadas a objetos. Esto es, la cabeza de la flecha (con forma de triángulo) apunta de la clase que hereda atributos y operaciones a la superclase. En lugar de utilizar el término herencia, UML le llaman relación de generalización.

El diseño de jerarquías de clases no es fácil. Una ventaja al desarrollar tales modelos es que el analista necesita comprender, en detalle, el dominio en el que el sistema se instalará. Como un ejemplo de los problemas que surgen en la práctica, considere la jerarquía de artículos de la biblioteca. Parecería que el atributo "Título" debe estar en el artículo más general y que se debe heredar a los artículos en los niveles inferiores. Sin embargo, aunque todo en la biblioteca debe tener algún tipo de identificador o un número de registro, esto no significa que todo deba tener un título. Por ejemplo una biblioteca puede tener los discursos personales de un político retirado. Muchos de esos artículos no tiene un título explicito. Estos se clasifican utilizando otra clase (que no se muestra aquí) que tiene un conjunto diferente de atributos.

El problema principal de la herencia múltiple es diseñar un grafo de herencia en el cual los objetos no heredan atributos innecesarios. Otros problemas que se presentan son la dificultad de reorganizar dicho grafico cuando se solicitan cambios y cuando los nombres chocan entre sí al existir dos o más superclases que se tiene atributos con el mismo nombre pero con diferentes significados. En cada nivel del modelo del sistema, tal coche es respectivamente fácil de resolver de forma manual alterando el modelo de objetos. Pero provoca problemas en la programación orienta a objetos.

Agregación de objetos

Así como se adquieren atributos y servicios a través de una relación de herencia con otros objetos, algunos objetos están hechos de otros objetos. Esto es, un objeto es un agregado de un conjunto de otros objetos. Las clases que representan a éstos se modelan utilizando un modelo de agregación de objetos como se muestra en la figura siguiente. En este ejemplo, se ha modelado un artículo de biblioteca, el cual es un paquete de estudio para un curso universitario. Este paquete incluye notas de clase, ejercicios, soluciones de muestra, copias de las transparencias utilizadas en las clases y videos.

La notación UML, para la agregación es representar la composición a través de una figura de diamante colocada en la fuente del vínculo. Por lo tanto, la figura siguiente se puede leer como "Un paquete de estudio se compone de una o más tareas, paquetes de diapositivas OHP, notas de clase y videos."Para modelar el comportamiento de los objetos, se tiene que mostrar cómo se utilizan las operaciones de éstos. En UML, se modelan utilizando escenarios basados en los casos de uso. Un ejemplo de modelado de comportamiento se muestra en la figura anterior que ilustra la administración de un catálogo de biblioteca. Así como los diagramas de colaboración que muestran la secuencia de mensajes

intercambiados por los objetos. Son similares a los diagramas de secuencia y no se cubren aquí.

Modelado del comportamiento de objetos.

Para ilustrar cómo se utilizan los diagramas de secuencia para modelar el comportamiento, se describe un escenario en el que los usuarios solicitan préstamos a la biblioteca de forma electrónica. Por ejemplo, imagine una situación en las que los paquetes de estudio mostrados en la figura siguiente se mantienen electrónicamente y se descargan a la computadora del estudiante.

La figura siguiente muestra un diagrama de secuencia con los objetos en la parte alta de diagrama. Las operaciones se indican por las etiquetas de las flechas y las secuencia de operaciones es de arriba hacia abajo. En este escenario, el usuario tiene acceso al catálogo para ver si el artículo requerido está disponible electrónicamente y, si es así, lo solicita. Por razones de derechos de autor, a este artículo se le designa una licencia de tal forma que existe una transacción entre al artículo solicitado se envía a una red de servidores de objetos para su comprensión de ser enviado al usuario.

Los subsistemas que componen un sistema debe intercambiar información con el fin de que puedan trabajar de forma conjunta y efectiva. Existen dos formas fundamentales de lograr esto.

1. Todos los datos compartidos se ubican en una base de datos central que puede ser accedida por todos los subsistemas. Un modelo del sistema basado en una base de datos compartida se denomina algunas veces modelo de depósito.

2. Cada subsistema tiene su propia base de datos. Los datos se intercambian con otros subsistemas pasando mensajes entre ellos.

La mayoría de los sistemas que utilizan grandes cantidades de datos se organizan alrededor de una base de datos compartida o depósito. Por lo tanto, este modelo es adecuado para aplicaciones donde los datos sean generados por un subsistema y utilizados por otro. Ejemplo de este tipo de sistemas son los sistemas de mando y control, los sistemas de administración de la información, los sistemas CAD y los conjuntos de herramientas CASE.

La siguiente figura es un ejemplo de una arquitectura para un conjunto de herramientas CASE basada en un depósito compartido.

El primer depósito compartido para las herramientas CASE se desarrolló probablemente a principios de los 70 por una compañía del Reino Unido,

denominada ICL, como ayuda al desarrollo de su sistema operativo (Mc-Guffin et al. 1979).Este modelo llegó a ser ampliamente conocido cuando Bouxton (1980) hizo las propuestas para el entorno Stoneman como ayuda al desarrollo de sistemas escritos en Ada. Desde entonces, muchos de los conjuntos de herramientas CASE se han desarrollado alrededor de un depósito compartido.

Las ventajas y desventajas de un depósito compartido son:

1. Es una forma eficiente de compartir grandes cantidades de datos. No existe la necesidad de transmitir datos explícitamente de un subsistema a otro.

2. Sin embargo, los subsistemas deben estar acordes al modelo de depósito de datos. De forma inevitable, esto es un compromiso entre las necesidades específicas de cada herramienta. El desempeño se puede ver afectado por este compromiso. Puede ser difícil o imposible integrar los nuevos subsistemas si sus modelos datos no se ajustan al esquema acordado.

3. Los subsistemas que producen datos no necesitan saber cómo son utilizados esos datos por otros subsistemas.

4. Sin embargo, si se genera un gran volumen de información, será difícil evolucionar si se ha acordado un modelo de datos. Traducir esto a un nuevo modelo será costoso; puede ser difícil o incluso imposible.

5. Las actividades como las de respaldo, seguridad, control de acceso y recuperación de errores están centralizados. Son las responsables de administrar el depósito. Las herramientas se enfocan a su función principal más que a estas cuestiones.

6. Sin embargo, varios subsistemas tienen diferentes requerimientos de políticas de seguridad, recuperación y respaldo. El modelo de depósito fuerza a la misma política para todos los subsistemas.

7. El modelo de comparación es visible a lo largo del esquema de depósito. De forma directa se integran las nuevas herramientas puesto que son compatibles con el modelo de datos acordado.

8. Sin embargo, es difícil distribuir el depósito en varias máquinas. Aunque es posible distribuir un depósito centralizado lógicamente, habrá problemas con la redundancia e inconsistencia en los datos.

En el modelo anterior, el depósito es pasivo y el control es responsabilidad de los subsistemas que utiliza el depósito .Existe un enfoque alternativo para los sistemas Ia que utilizan un modelo de pizarrón en el cual dispara subsistemas cuando están disponibles ciertos datos. Esto es apropiado cuando la forma del depósito de datos no es tan estructurada. Las decisiones sobre que herramienta activar se toman cuando los datos ser han analizado. (1986) trata este modelo.

5.3 ARQUITECTO DE SOFTWARE.

Los sistemas grandes siempre se descomponen en subsistemas que suministran algún conjunto relacionado de servicios. El proceso de diseño inicial para identificar estos subsistemas y establecer un marco de trabajo para el control y comunicación de los subsistemas y establecer un marco de trabajo para el control y comunicación de los subsistemas se llama diseño arquitectónico y lo que produce este proceso de diseño es una descripción de la arquitectura de software.

El diseño arquitectónico es la primera etapa en el proceso y representa un vínculo crítico entre el diseño y los procesos de ingeniería de requerimientos. De forma ideal, una especificación no debe incluir ninguna formación del diseño. En la práctica, esto no es real excepto para los sistemas muy pequeños. La descomposición arquitectónica es necesaria para estructurar y organizar la especificación.

El proceso de diseño arquitectónico comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Esto implica identificar los componentes principales del sistema. Esto implica identificar los componentes principales del sistema y la comunicación entre ellos. Bass et al. (1998) plantean tres ventajas de la especificación del diseño y la documentación de una arquitectura de software:

1. Comunicación entre los stakeholders. La arquitectura es una presentación de alto nivel del sistema que es utilizada como punto de discusión `por un rango de stakeholders diferentes.

2. Análisis del sistema. Hacer explícita la arquitectura del sistema en una etapa inicial del desarrollo del sistema, significa que debe de llevar a cabo cierto tipo de análisis .Las decisiones en el diseño arquitectónico tiene un efecto profundo sobre cuándo el sistema puede cumplir los requerimientos críticos como el desempeño, la fiabilidad y la mantenibilidad.

3. Reutilización a una gran escala. Una arquitectura del sistema es una descripción compacta y manejable de cómo se organiza el sistema y cómo interoperan los componentes. La arquitectura se puede transferir a lo largo de los sistemas con requerimientos similares y así poder reutilizar software a gran escala, Es posible desarrollar arquitecturas de líneas de productos donde la misma arquitectura se utilice en varios sistemas relacionados.

Diversos diseñadores enfocan el proceso de diseño arquitectónico de diferentes formas. El proceso utilizado depende del conocimiento de la aplicación y de la capacidad e intuición de los arquitectónicos del sistema. Sin embargo, las

siguientes actividades son comunes para todos los procesos de diseño arquitectónico:

1. Estructuración del sistema. El sistema se estructura en varios subsistemas principales, donde un subsistema es una unidad de software independiente. Se identifican las comunicaciones entre los subsistemas.

2. Modelado del control. Se establece un modelo general de las relaciones de control entre las partes del sistema.

3. Descomposición modular. Cada subsistema identificado se descompone en módulos. El arquitecto debe decidirse sobre los tipos de módulos y sus interconexiones.

Por lo general, estas actividades están entrelazadas más que llevarse a cabo de forma secuencial. Durante cualquiera de estos procesos, se tiene que desarrollar el diseño en más detalle para descubrir si las decisiones en el diseño arquitectónico permiten al sistema cumplir sus requerimientos.

No existe una distinción clara entre los subsistemas y módulos, pero es útil distinguirlos como se muestra a continuación:

1. Un subsistema es un sistema que por si mismo cuya operación no depende de los servicios suministrados por otros subsistemas. Los subsistemas se componen de módulos y tiene interfaces definidas que se utilizan para la comunicación con otros subsistemas.2. Un módulo es por lo regular un componente del sistema que suministra uno o más servicios a otros módulos. Utiliza los servicios suministrados por otros módulos. Por lo general no se considera un sistema independiente. Generalmente, los módulos están compuestos de varios componentes simples del sistema.

La salida del proceso de diseño arquitectónico es un documento de diseño arquitectónico. Éste consiste de varias representaciones gráficas de los modelos del sistema junto con el texto descriptivo asociado. Describe cómo se estructura el sistema en subsistemas y cómo cada subsistema se estructura en módulos.

Los diversos modelos gráficos del sistema muestran diferentes perspectivas de la arquitectura. Los modelos arquitectónicos que se pueden desarrollar son:

1. Un modelo estructural estático que muestran los subsistemas o componentes a desarrollar como unidades independientes.

2. Un modelo de proceso dinámico que muestra cómo se organiza el sistema en tiempo de ejecución. Este modelo puede ser diferente al modelo estático.

3. Un modelo de interfaz que define los servicios ofrecidos por cada subsistema a través de su interfaz pública.

4. Modelos de relación que se muestran las relaciones de, por ejemplo, el flujo de datos entre los subsistemas.

Varios investigadores han propuesto la utilización de ADSL (Lenguajes de descripción arquitectónica) para describir las arquitecturas del sistema. Bass et al (1998) describe las características principales de estos lenguajes.

Los elementos básicos del ADSL son componentes y conectores que incluyen reglas y lineamientos para arquitecturas bien arquitecturas bien formadas. Sin embargo, como otros lenguajes especializados, tiene la desventaja de que sólo los expertos en el lenguaje los comprenden- son inaccesibles para los especialistas en el dominio y en la aplicación.

Esto hace difícil analizarlos desde una perspectiva práctica. Por lo tanto, se utilizan en un número reducido de aplicaciones. En su lugar, los modelos y notaciones informales como UML, son más útiles en la descripción arquitectónica.

El diseño arquitectónico se basa en un modelo o estilo arquitectónico particular (Garlan y Shaw, 1993) .Por lo tanto, es importante conocer estos modelos, sus aplicaciones, fortalezas y debilidades. En este capítulo de describen varios modelos estructurales diferentes, modelos de control y modelos de descomposición.

Sin embargo, las arquitecturas de muchos sistemas grandes comprenden más de un modelo. Las diversas partes del sistema se diseñan utilizando diferentes modelos arquitectónicos. Más aún, en algunos casos, la arquitectura del sistema es una arquitectura.

Compuesta. Ésta se crea al combinar diferentes modelos arquitectónicos. Los diseñadores deben encontrar el modelo más apropiado y modificarlo acorde a los requerimientos del problema.

La arquitectura del sistema afecta al desempeño, la robustez, la distributibilidad y la mantenibilidad de un sistema. Por lo tanto, el estilo particular y la estructura elegida para una aplicación pueden depender de los requerimientos no funcionales del sistema:

1. Desempeño. Si el desempeño es un requerimiento crítico , esto sugiere que la arquitectura se debe diseñar para localizar las operaciones críticas dentro de un número reducido de subsistemas. Estos significa utilizar componentes de grano grueso más que de grano fino para reducir los componentes de comunicación.

2. Seguridad. Si la seguridad es un requerimiento crítico, esto sugiere que la estructura en capas más internas y con un alto nivel de validación de la seguridad aplicado a esas capas.

3. Protección. Si la protección es un requerimiento crítico esto sugiere que la arquitectura se debe diseñar de tal forma que las operaciones relacionadas con la protección se localicen en un solo subsistema o en un número reducido de subsistemas. Esto reduce los costos y los problemas de validación y hace posible crear sistemas de protección relacionados.

4. Disponibilidad. Si la disponibilidad es un requerimiento crítico, esto sugiere que la arquitectura debe diseñarse para incluir componentes redundantes de tal forma que sea posible reemplazar a actualizar los componentes sin detener el sistema.

5. Mantenibilidad si la mantenibilidad es un requerimiento crítico, esto sugiere que la arquitectura del sistema se debe diseñar utilizando componentes auto contenidos de grano fino que pueden cambiarse con facilidad. Los productores de datos deben estar separados de los consumidores y las estructuras de datos compartidas deben evitarse.

Obviamente existe un conflicto potencial entre algunas de estas arquitecturas. Por ejemplo, el desempeño se mejora utilizando componentes de grano grueso y el mantenimiento utilizando componentes de grano fino. Si ambos son requerimientos importantes del sistema, se deben encontrar una solución mediadora como se discutió anteriormente, algunas veces esto se puede llevar a cabo utilizando estilos arquitectónicos para las diversas partes del sistema.

La primera fase de la actividad de diseño arquitectónico se refiere, por lo general, a la descomposición del sistema en conjunto de subsistemas que interactúan. En el nivel más abstracto, un diseño arquitectónico se puede ver como un diagrama de bloques en el que cada cuadro del diagrama representa un subsistema. Los cuadros dentro de otros cuadros indican que el subsistema a se ha descompuesto en subsistemas. Las fechas indican que los datos y/o el control se pasan de un subsistema a otro subsistema en la dirección de las flechas. Un diagrama arquitectónico de bloques presenta un panorama general de la estructura del sistema.

Por lo general, éste es comprensible por los diversos ingenieros que están involucrados en el proceso de desarrollo. Este sistema puede empacar diferentes tipos de objetos. Utilizan un sistema de visión para seleccionar los objetos de una banda transportadora, identifican el tipo de objetos y seleccionan el tipo de embalaje correcto. Después mueve los objetos de la banda transportadora para empacarlos. Los objetos empaquetados se colocan en una banda transportadora.

Bass et al (1998) señalan que los diagramas de cuadros y flechas no son representaciones arquitectónicas útiles puesto que no muestran la naturaleza de

las relaciones entres los componentes del sistema ni sus propiedades visibles externas. Desde una perspectiva de un diseñador de software, esto es absolutamente correcto. Sin embargo, este tipo de modelo es efectivo para la comunicación con los stakeholders de los sistemas y los planeadores del proyecto. Puesto que no muestra los detalles, los gestores lo relacionan con el sistema y tiene una visión abstracta de él. Identifica a los subsistemas clave a desarrollar de forma independiente de tal forma que los administradores pueden iniciar asignando personas al plan de desarrollo de esos sistemas. Los diagramas de cuadros y flechas no son la única representación arquitectónica que se utiliza; sin embargo, es uno de los modelos de representación arquitectónica útiles.

Se pueden desarrollar modelos más específicos de la estructura qué muestren cómo los subsistemas comparten datos, cómo están distribuidos y cómo se conectan entre ellos. En esta sección se discuten tres de esos modelos estándar: el modelo de depósito, el modelo cliente- servidor y el modelo de máquina abstracta.

CONCLUSIÓN

Como pudimos notar en el contenido y desarrollo de los diferentes temas, se explico detalladamente cada uno de los puntos a tratar y encontramos sus diferentes características que hacen cada uno ellos, la arquitectura de Software han estado implícitas bien como accidentes en la implementación, bien como sistemas legados del pasado los buenos desarrolladores de software han adoptado, a menudo, uno o varios patrones arquitectónicos como estrategias de organización del sistema, pero utilizaban estos patrones de modo informal y no tenían ningún interés en hacerlos explícitos en el sistema resultante.

BIBLIOGRAFÍA

BibliografíaLarman, C. (2003). UML y patrones. Ed. Pearson.

Rumbaugh, G. B.-J. (2000). El lenguaje unificado de modelado. Addison Wesley .