Arquitectura del Sistema de Software

SISTEMAS DE INFORMACIÓN IITEORÍA

CONTENIDO:ARQUITECTURA DEL SISTEMA DE SOFTWARE

NIVELES DE DISEÑO DE LOS SISTEMAS DE SOFTWARECUALIDADES DE LAS ARQUITECTURAS

ESTILOS Y PATRONES - ESTILOS ARQUITECTÓNICO - PATRÓN ARQUITECTÓNICO

FRAMEWORK – PATRONES DE DISEÑOEL MODELO DE ARQUITECTURA 4+1 VISTAS

UNIVERSIDAD SIMÓN BOLÍVARDEPARTAMENTO DE PROCESOS Y SISTEMAS

Material diseñado y elaborado por:Prof. María A. Pérez de OvallesProf. Luis Eduardo Mendoza M.

SISTEMAS DE INFORMACIÓN II TEORÍA


ARQUITECTURA DEL SISTEMA DE SOFTWARESe obtiene mediante un proceso de partición que relaciona los ele-mentos de una solución de software con partes de un problema deldel mundo real definido implícitamente durante el análisis de losrequisitos. La solución aparece cuando cada parte del problema estáresuelta mediante uno o más elementos de software.

• El diseño y la especificación completa de la estructura de los sistemas de software, según Shaw y Garlan (Shaw y Garlan, 1996), se está transformando en un aspecto de más importancia que la escogencia de los algoritmos y las estructuras de datos, en virtud del tamaño y la complejidad de estos es la actualidad

• Diseñar la arquitectura del software, según estos mismos autores, es definir los aspectos estructurales como una composición de componentes, las estructuras globales de control, los protocolos de comunicación, la sincronización y acceso a los datos, la asignación de la funcionalidad a los elementos del diseño, la composición de estos elementos, su distribución física, su escalabilidad y su desempeño.



ARQUITECTURA DEL SISTEMA DE SOFTWAREDefine al sistema en términos de elementos computacionales yde las interacciones entre ellos. La arquitectura muestra la co-rrespondencia entre los requerimientos de sistemas y los elemen-tos del sistema construido, proveyendo así una exposición racio-nal para las decisiones de diseño.• ELEMENTOS COMPUTACIONALES. Son entidades tales como

clientes, servidores, bases de datos, filtros y capas de un sistema jerárquico. Son además, una parte encapsulada del sistema de software, donde cada uno tiene una interfaz.

• INTERACCIONES. Ocurren entre los elementos a nivel de diseño, puediendo ser tan simples como las llamadas a procedimientos o variables de acceso, o tan complejas y semánticamente ricas como los protocolos del modelo cliente/servidor, los protocolos de acceso a las bases de datos,la difusión de ls eventos asincrónicos y las ráfagas (stream) de los pipes. (Shaw y Garlan, 1996).



ARQUITECTURA DEL SISTEMA DE SOFTWARE

• Una relación, además denota una conexión entre los componentes. Una relación puede ser estática o dinámica.

– Relaciones estáticas. Se muestran en el código fuente, ellas reflejan la colocación de los componentes dentro de la arquitectura.

– Relaciones dinámicas. tratan con las conexiones temporales y las interacciones dinámicas entre los componentes. Ellas no son fácilmente visibles a partir del código fuente.

• PROPIEDAD FUNCIONAL. Tiene que ver con un aspecto de la funcionalidad del sistema, como su nombre lo indica. Está usualmente relacionada con un requerimiento.

• PROPIEDAD NO FUNCIONAL. Trata de una característica del sistema que no está cubierta en la descripción funcional del mismo. Típicamente se refiere a aspectos tales como confiabilidad, compatibilidad, costo, facilidad de uso , etc.



NIVELES DE DISEÑO DE LOSSISTEMAS DE SOFTWARE

• ARQUITECTURA. Los aspectos de diseño involucran la asociación de la capacidad de todo el sistema con componentes. Los componentes son módulos y la interconexión entre los módulos se maneja de maneras diferentes. La composición está orienta hacia subsistemas.

• CÓDIGO. El diseño involucra algoritmos y estructuras de datos. Los componentes son primitivas de lenguajes de programación, tales como números, caracteres, etc. Los mecanismos de composición son arreglos, registros, procedimientos, etc.

• EJECUTABLE. El diseño involucra mapas de memoria, arreglos de datos, asignaciones de registros, etc. Los componentes son patrones de bits soportados por el hardware y las composiciones se escriben en lenguaje de máquina.



CUALIDADES DE LAS ARQUITECTURAS

• CONFORMIDAD FUNCIONAL. Según Pressman (Pressman, 1998) una arquitectura de calidad debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debeacomodar todos los requisitos implícitos que desea el cliente. Además, debe proporcionar una idea completa de que es el software, enfocando los dominios de los datos, las funciones y los comportamientos. Según Lawrence (Lawrence, 1998) la arquitectura del software le dice a los usuarios exactamente lo que el sistema de software hará.

• ADAPTABILIDAD. Esta característica la propone Sommerville (Sommerville, 1998) al señalar que ella mide cuan fácil es hacercambios en una arquitectura; de seguro, esto implica componentes poco acoplados. En su opinión, un sistema de software adaptable tiene una alta trazabilidad; esto quiere decir, que hay una relación clara entre los diferentes niveles de abstracción.




• MODULARIDAD. Sin considerar el enfoque de diseño utilizado (estilo arquitectural) (Lawrence, 1998), el proceso de descomposición separa el diseño en partes que lo componen, llamadas módulos o componentes. Se dice que un sistema es modular cuando cada actividad del sistema de software es ejecutada exactamente por un componente y cuando las entradas y las salidas de los componentes están bien definidas. Los módulos se organizan jerárquicamente como resultado de la descomposición. En la opinión de Pressman (Pressman, 1998), estos módulos se integrarán para satisfacer los requisitos del sistema. Para este autor modularidad es el atributo del software que permite a un sistema ser manejable intelectualmente. Lawrence (Lawrence, 1998) además agrega que los módulos encapsulan información; la ventaja de esta característica es que el diseño interno de cada componente está oculto para el resto de los otros componentes.




• NIVELES DE ABSTRACCIÓN. Según Lawrence (Lawrence, 1998), estos módulos se estructuran según niveles de abstracción. Estos niveles de abstracción ayudan a entender el problema a ser resuelto por el sistema y la solución propuesta. Según Pressman (Pressman, 1998), cuando se plantea una solución modular se pueden presentar muchos niveles de abstracción. Cada fase del proceso de diseño es un refinamiento en el nivel de abstracción. Pressman (Pressman, 1998) propone tres (3) niveles de abstracción:

– Abstracción procedimental. Es una secuencia dada de instrucciones que tiene una función específica y limitada.

– Abstracción de datos. Es una colección determinada de datos que describen un objeto de datos.

– Abstracción de control. Implica un mecanismo de control del programa sin especificar detalles internos.




• ENTENDIBLE. Sommerville (Sommerville, 1998) señala que un sistema antes de hacerle un cambio debe ser entendido. En su opinión este entendimiento estará afectado por: La cohesión, el acoplamiento, la nominación, la documentación y la complejidad; inclusive, señala que la complejidad tiene una relación directa con su fácil entendimiento.

• COHESIÓN. Es una consecuencia del ocultamiento de la informa-ción. Un módulo con cohesión (Pressman, 1998) realiza solamente una tarea, requiriendo poca interacción con el resto de los procedimientos que se realizan en el resto del sistema de software. Según Sommerville (Sommerville, 1998) la cohesión es deseable debido a que una unidad (componente) representa una parte simple de solución. Si es necesario cambiar el sistema, la partecorrespondiente está en un solo lugar y lo que se desee hacer con él estará encapsulado en él. Según Lawrence (Lawrence, 1998) la meta es hacer que los componentes sean lo más cohesivos posible.




• ACOPLAMIENTO. Está relacionado con la cohesión. Es un indicador de la fuerza de interconexión entre los componentes o elementos de la arquitectura (Sommerville, 1998). Sistemas altamente acoplados tienen una fuerte interconexión, lo que se refleja en una gran dependencia entre los componentes. Los sistemas poco acoplados, por otro lado, tienen poca relación entre sus componentes o elementos. La meta (Lawrence, 1998) es mantener el acoplamiento en el nivel más bajo posible; la conectividad sencilla entre módulos da como resultado un software que es más fácil de comprender y menos propenso al “efecto onda” (Stevens et al., 1975) producido cuando los errores aparecen en una posición y se propagan a lo largo del sistema. Pressman (Pressman, 1998) agrega que el acoplamiento depende de la complejidad de las interfaces entre los módulos, del punto en el que se hace una entrada o referencia a un módulo y de los datos pasan a través de esa interfaz.



ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE LOS SISTEMAS

• Bass et al. (2000) establecen que para alcanzar un atributo específico, es necesario tomar decisiones de diseño arquitectónico que requieren un pequeño conocimiento de funcionalidad

• Bass et al. (2000) afirman que cada decisión incorporada en una arquitectura de software puede afectar potencialmente los atributos de calidad.

• Sin embargo, esto no es evidente, porque:– Existen atributos de calidad que, luego de ser estudiados durante

años, poseen definiciones generalmente aceptadas– Los atributos no están aislados ni son independientes entre sí.– El análisis de atributos no se presta a estandarizaciones.– Las técnicas de análisis son específicas para un atributo en

particular.• La arquitectura es un artefacto que determina atributos de

calidad del sistema.



ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE LOS SISTEMAS

Característica Subcaracterística Elementos de tipo arquitectónico Adecuación Refinamiento de los diagramas de secuencia

Exactitud Identificación de los componentes con las funciones responsables de los cálculos

Interoperabilidad Identificación de conectores de comunicación con sistemas externos

Funcionalidad

Seguridad Mecanismos o dispositivos que realizan explícitamente la tarea

Tolerancia a fallas Existencia de mecanismos o dispositivos de software para manejar excepciones

Confiabilidad Recuperabilidad

Existencia de mecanismos o dispositivos de software para reestablecer el nivel de desempeño y recuperar datos

Desempeño Componentes involucrados en un flujo de ejecución para una funcionalidad Eficiencia

Utilización de recursos

Relación de los componentes en términos de espacio y tiempo

Acoplamiento Interacciones entre componentes Mantenibilidad

Modularidad Número de componentes que dependen de un componente

Adaptabilidad Presencia de mecanismos de adaptación

Instalabilidad Presencia de mecanismos de instalación

Coexistencia Presencia de mecanismos que faciliten la coexistencia Portabilidad

Reemplazabilidad Lista de componentes reemplazables para cada componente



ESTILOS Y PATRONES

• Bosch (2000) establece que la imposición de ciertos estilos arquitectónicos mejora o disminuye las posibilidades de satisfacción de ciertos atributos de calidad del sistema

• Cada estilo propicia atributos de calidad, y la decisión de implementar alguno de los existentes depende de los requerimientos de calidad del sistema.

• Buschmann et al. (1996) afirman que un criterio importante del éxito de los patrones es la forma en que estos alcanzan de manera satisfactoria los objetivos de la ingeniería de software.



ESTILOS ARQUITECTÓNICOS

Un estilo arquitectónico define una familia de sistemas de software en términos de su organización estructural. Un estilo arquitectónico representa los componentes y las relaciones entre ellos con las restricciones de su aplicación y las asociaciones y reglas de diseño para su construcción. Shaw y Garlan (Shaw y Garlan, 1996) precisan además, que un estilo arquitectónico define un vocabulario de componentes y tipos de conectores.



ESTILOS ARQUITECTÓNICOSPIPES and FILTERS (Tuberías y filtros)

Cada componente tiene un conjunto de entradas y un conjuntode salidas.

• Un componente lee la ráfaga (stream) de datos en sus entradas y produce una ráfaga de datos en sus salidas.

• Los componentes se conocen como filtros y son independientes.• Los conectores se comportan como conductores de las ráfagas,

transmitiendo salidas de un componente hacia entradas de otro.• El mejor ejemplo de este estilo son los programas escritos en el Shell

de Unix (Bach, 1986). Otros ejemplos se observan en el área de procesamiento de señales, programación paralela y sistemas distribuidos.

Filters(Filtros)

Pipes(Tuberías)



ESTILOS ARQUITECTÓNICOSORGANIZACIONES POR TIPOS DE DATOS ABSTRACTOS Y O-O

La representación de los datos y sus operaciones primitivas seencapsulan en Tipos de Datos Abstractos (TDA) u objetos.

• Los componentes son objetos (o instancias de tipos de datos abstractos). Los objetos son ejemplos de un tipo de componente llamado manejador porque es el responsable de preservar la integridad de un recurso

• Los objetos interactúan a través de invocaciones a funciones y procedimientos.

• La implementación de las funciones y procedimientos está oculta para el objeto cliente, lo cual permite hacer las modificaciones fácilmente.

• Para hacer uso de un servicio se hace necesario conocer la identidad del objeto; al hacer un cambio en un objeto es necesario modificar todos los objetos que lo invocan.

obj

obj

obj

objobj

op

op

op

opop

op

op

op

op

op

Nota: obj es un manejadorop es una invocación

Manejador(TDA)

Llamada deun proceso



ESTILOS ARQUITECTÓNICOSBASADOS EN EVENTOS, INVOCACIÓN IMPLÍCITA

En el estilo anterior, la interfaz de los componentes (objetos)cuentan con una colección de procedimientos y funciones, y laintegración entre ellos se logra a través de la invocación explícitade éstos. En este estilo, se considera una técnica de integraciónconocida como invocación implícita.

• Los componentes son módulos cuyas interfaces proveen una colección de procedimientos y un conjunto de eventos. Los procedimientos se llaman de la manera usual pero el componente también puede activar algunos de sus procedimientos con los eventos del sistema. Esto hará que estos procedimientos sean invocados cuando los eventos ocurren en tiempo de ejecución.

• Los generadores de eventos no saben cuales componentes se afectarán por el evento. Ejemplos de este estilo son los sistemas de gestión de bases de datos cuando aseguran la consistencia de los datos, lasaplicaciones con interfaces de usuarios al separar la representación de los datos de las aplicaciones que las gerencian.



SISTEMAS EN CAPAS

Están organizados jerárquicamente; cada capa le presta serviciosa la capa superior y es cliente de la capa inferior.

• Los componentes implementan un máquina virtual en alguna capa dela jerarquía.

• Los conectores están definidos en los protocolos que determinan cómo las capas interactúan.

• Los ejemplos más conocidos de este estilo arquitectural son los protocolos de comunicación.

ESTILOS ARQUITECTÓNICOS

Usuarios

Nivelcentral

Servicio base

Sistemas útiles

Composición devarios elementos

Llamadas usualesde procedimientos



ESTILOS ARQUITECTÓNICOSREPOSITORIOS

Consta de dos (2) tipos de componentes: una estructura central de datosque refleja el estado actual y una colección independiente de compo-nentes que operan sobre el almacén central.

• Las interacciones entre los componentes pueden variar significativamente. El tipo de control seleccionado puede llevar a dos categorías:

– Si el tipo de transacción es una entrada que dispara la selección del proceso a ejecutarse, se está hablando de las tradicionales bases de datos.

– Si el estado actual de la estructura central de datos es el principal activador de los procesos a ejecutarse, se habla de un estilo de repositorio tipo pizarrón (blackboard). Son muy utilizados para aplicaciones que requieren interpretaciones complejas de procesamiento de señales, tales como reconocimiento del habla y de patrones.

Nota:fc es una fuente de conocimiento

Blackboard(datos

compartidos)

fc2fc1

fc5fc6

fc8

fc7

fc3

fc4

Accesodirecto

Computación

Memoria



ESTILOS ARQUITECTÓNICOSINTÉRPRETES

En una organización intérprete,una maquina virtual es produci-da en software. Un intérprete incluye el pseudoprograma inter-pretado y la máquina de interpretación misma.

• Los intérpretes son a menudo usados para construir maquinas virtuales que enlazan la máquina de computación esperada por la semántica y la máquina de computación disponible en el hardware.

Programa a serinterpretado

Estadointerno del

interpretador

Motor deinterpretación

simulado

Datos(programa)

Memoria

Entradas

Salidas Instrucción seleccionadaDatos seleccionados

Acceso a datos(búsqueda/almacenamiento)

Computación(máquina)



PATRONES ARQUITECTÓNICOS

• Buschmann et al. (1996) define patrón como una regla que consta de tres partes, la cual expresa una relación entre un contexto, un problema y una solución

• Estas son:– Contexto. Es una situación de diseño en la que aparece un

problema de diseño.– Problema. Es un conjunto de fuerzas que aparecen repetidamente

en el contexto.– Solución. Es una configuración que equilibra estas fuerzas.

• Para Buschmann et al. (1996) son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicación y tienen un impacto en la arquitectura de subsistemas.

• La selección de un patrón arquitectónico es, por tanto, una decisión fundamental de diseño en el desarrollo de un sistema de software.



PATRONES ARQUITECTÓNICOSPatrón

Arquitectónico Descripción

Layers

Consiste en estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas, las cuales se clasifican de acuerdo a un nivel particular de abstracción.

Pipes and Filters

Provee una estructura para los sistemas que procesan un flujo de datos. Cada paso de procesamiento está encapsulado en un componente filtro (filter). El dato pasa a través de conexiones (pipes), entre filtros adyacentes.

Blackboard

Aplica para problemas cuya solución utiliza estrategias no determinísticas. Varios subsistemas ensamblan su conocimiento para construir una posible solución parcial ó aproximada.

Broker

Puede ser usado para estructurar sistemas de software distribuido con componentes desacoplados que interactúan por invocaciones a servicios remotos. Un componente broker es responsable de coordinar la comunicación, como el reenvío de solicitudes, así como también la transmisión de resultados y excepciones.

Model-View-Controler

Divide una aplicación interactiva en tres componentes. El modelo (model) contiene la información central y los datos. Las vistas (view) despliegan información al usuario. Los controladores (controlers) capturan la entrada del usuario. Las vistas y los controladores constituyen la interfaz del usuario.



PATRONES ARQUITECTÓNICOS

Patrón Arquitectónico Descripción

Presentation-Abstraction-

Control

Define una estructura para sistemas de software interactivos de agentes de cooperación organizados de forma jerárquica. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y consiste de tres componentes: presentación, abstracción y control.

Microkernel

Aplica para sistemas de software que deben estar en capacidad de adaptar los requerimientos de cambio del sistema. Separa un núcleo funcional mínimo del resto de la funcionalidad y de partes específicas pertenecientes al cliente.

Reflection

Provee un mecanismo para sistemas cuya estructura y comportamiento cambia dinámicamente. Soporta la modificación de aspectos fundamentales como estructuras tipo y mecanismos de llamadas a funciones.



ESTILOS Y PATRONES ARQUITECTÓNICOS

Estilo Arquitectónico Patrón Arquitectónico

Sólo describe el esqueleto estructural y general para aplicaciones

Existen en varios rangos de escala, comenzando con patrones que definen la

estructura básica de una aplicación

Son independientes del contexto al que puedan ser aplicados

Partiendo de la definición de patrón, requieren de la especificación de un contexto del

problema

Cada estilo es independiente de los otros Depende de patrones más pequeños que

contiene, patrones con los que interactúa, o de patrones que lo contengan

Expresan técnicas de diseño desde una perspectiva que es independiente de la

situación actual de diseño

Expresa un problema recurrente de diseño muy específico, y presenta una solución para él, desde el punto de vista del contexto en el

que se presenta

Son una categorización de sistemas Son soluciones generales a problemas comunes



FRAMEWORK

• Un framework es más que una jerarquía de clases. Es una jerarquía de clases más un modelo de interacción entre los objetos instanciados a partir del framework. (Levis, Rosenstein, Pree, Weinand, Gamma, Calder, Andert, Vlissides andSchmucker, 1995)

• Un framework es una técnica de reuso (Johnson, 1997)

• Un framework es un diseño reusable de todo o partes del sistema que esta representado por un conjunto de clases abstractas y la forma como sus instancias interactúan.

• Un framework es un esqueleto de una aplicación que puede ser personalizado por un desarrollador de aplicaciones (Johnson, 1997).

• Un componente representa reuso de código. Los framework son una forma de reuso de diseño (Johnson, 1997).



FRAMEWORK

• Los framework son componentes en el sentido que los vendedores los venden como productos y porque una aplicación puede usar varios framework. Pero los framework son más personalizables que los componentes y tiene interfaces más complejas. (Johnson, 1997)

• Los framework son una clase de arquitectura de dominio específico. La diferencia principal es que un framework es un diseño orientado a objeto mientras que una arquitectura de un dominio específico puede no serlo (Johnson, 1997).

• Un framework es reusable, una aplicación semi completa que puede ser especializada para producir aplicaciones personalizadas. (Johnson y Foote, 1998; Fayad, Schmith y Johnson, 1997)

• En contraste con las técnicas de reuso OO iniciales basadas en librerías, los framework están orientados a unidades del negocio particulares y a dominios de aplicación. (Fayad y Schmith, 97)



FRAMEWORK

• El desarrollo de aplicaciones estará fuertemente basado en la integración de múltiples framework.

• Clasificando los framework por su alcance, tenemos:– Infraestructura de Sistemas: simplifican el desarrollo de

infraestructuras de sistemas eficientes y portables tales como sistemas operativos, de comunicación y herramientas de interfaces de usuarios y procesamiento de lenguajes

– Integración de middleware: Se usan comúnmente para integrar aplicaciones distribuidas y componentes. Se usan para mejorar la habilidad del desarrollador en modularidad, reuso y extensiones de software trabajando en un ambiente distribuido

– Aplicaciones de empresas: Dirigidos a dominios de aplicación amplios, tales como comunicaciones, manufactura, financieros, etc.



PATRONES DE DISEÑO

• Un patrón describe un problema a ser resuelto, una solución y el contexto en el cual la solución trabaja. Nomina una técnica ydescribe su costo y su beneficio

• Estos patrones fueron descubiertos al examinar varios framework y fueron seleccionados como representativos de software reusable.

• Un simple framework puede contener muchos patrones; es decir, estos patrones son más pequeños que los framework. Por lo tanto, los patrones son mas abstractos que los framework

• Los patrones de diseño son elementos microarquitectónicos de los framewrok.

• Aunque el término Patrón de Diseño no es usado explícitamente, los novatos obtienen ganancia de sus experiencias en el desarrollo de software OO al extraer patronesde diseño a partir de varios framework específicos (Pree, 1995)



PATRONES DE DISEÑO

• De acuerdo a Coad, los patrones de diseño son identificados al observar los bloques de construcción de más bajo nivel; esto es sus clases y objetos y las relaciones entre ellos (Pree, 1995).

• Clasificación:ALCANCE PROPOSITO

CLASE CREACIÓN ESTRUCTURAL COMPORTAMIENTO Factory Method Adapter Clss Interpreter OBJECT Abstract Factory Adapter Object Chain of

Responsibility Builder Bridge Command Protitype Composite Iterator Singleton Decorator Mediator Façade Memento Flyweight State Proxy Strategy Visitor



PATRONES DE DISEÑO

Documentación:• Nombre del patrón y su clasificación• Intención: ¿Qué hace? ¿Qué problema resuelve?• Alias o conocido también como• Motivación• Aplicabilidad• Estructura: representación gráfica de la jerarquía de clases y el

diagrama de interacción• Participantes: las clases que lo componen y sus responsabilidades• Consecuencias: trade-off de usar el patrón• Implementación: sugerencias y ayudas sobre la implementación, fallas

más comunes• Usos conocidos: ejemplos donde ha sido usado• Patrones relacionados: ¿Qué patrón se relacionan con él? ¿En qué se

diferencia de otros?



ESTILOS Y PATRONES ARQUITECTÓNICOS Y DE DISEÑO



EL MODELO DE ARQUITECTURA 4+1 VISTAS

El Modelo 4+1 Vistas organiza la descripción de la arquitectura de un software usando cinco (5) vistas concurrentes, cada una de las cuales está dirigida a un conjunto específico de conceptos. Los arquitectos exponen sus decisiones de diseño en cuatro (4) vistas y usan la quinta vista para ilustrar y validar dichas decisiones.

Vista LógicaVista Lógica

Vista de ProcesoVista de Proceso

Vista de DesarrolloVista de Desarrollo

Vista FísicaVista Física

EscenariosEscenarios

Programadores• gerencia del software

Ingenieros de sistemas• topología del sistema• entregas• instalación• telecomunicación

Integradores de sistemas• desempeño• escalabilidad• rendimiento

Usuarios finales• funcionalidad



EL MODELO DE ARQUITECTURA 4+1 VISTAS

• VISTA LÓGICA. Describe el modelo objeto del diseño cuando un método de diseño O-O es usado;se puede usar un enfoque alterno para desarrollar alguna otra forma de vista lógica

• VISTA DE PROCESO. Describe los aspectos de diseño relacionados con la concurrencia y la sincronización.

• VISTA FÍSICA. Describe el mapa del SW dentro del HW refleja los aspectos de distribución.

• VISTA DE DESARROLLO. Describe la organización estática del software en el ambiente de desarrollo.

• ESCENARIOS. Los diseñadores de software organizan la descripción de sus decisiones arquitecturales alrededor de estas cuatro (4) vistas, y las ilustran con una pequeña selección de casos de uso o escenarios, constituyendo así la quinta vista. La arquitectura está parcialmente producida por esos escenarios.



INTERDEPENDENCIA ENTRE VISTAS

Procesos Se identifican características tales como: Autonomía,quien invoca a quien. Persitencia. Distribución:desde donde son accesibles las operaciones.

Lógica Desarrollo Una clase se puede implementar en un módulo, paquete, etc.

Lógica

Documents

Arquitectura del Sistema de Software