Teoría PS6116 Arq. de Software

UNIVERSIDAD SIMN BOLVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
SISTEMAS DE INFORMACIN II TEORA

CONTENIDO: ARQUITECTURA DEL SISTEMA DE SOFTWARE NIVELES DE DISEO DE LOS SISTEMAS DE SOFTWARE CUALIDADES DE LAS ARQUITECTURAS ESTILOS Y PATRONES - ESTILOS ARQUITECTNICO - PATRN ARQUITECTNICO FRAMEWORK PATRONES DE DISEO EL MODELO DE ARQUITECTURA 4+1 VISTAS
Material diseado y elaborado por: Prof. Mara A. Prez de Ovalles Prof. Luis Eduardo Mendoza M.

ARQUITECTURA DEL SISTEMA DE SOFTWARE

Se obtiene mediante un proceso de particin que relaciona los elementos de una solucin de software con partes de un problema del del mundo real definido implcitamente durante el anlisis de los requisitos. La solucin aparece cuando cada parte del problema est resuelta mediante uno o ms elementos de software. El diseo y la especificacin completa de la estructura de los sistemas de software, segn Shaw y Garlan (Shaw y Garlan, 1996), se est transformando en un aspecto de ms importancia que la escogencia de los algoritmos y las estructuras de datos, en virtud del tamao y la complejidad de estos es la actualidad Disear la arquitectura del software, segn estos mismos autores, es definir los aspectos estructurales como una composicin de componentes, las estructuras globales de control, los protocolos de comunicacin, la sincronizacin y acceso a los datos, la asignacin de la funcionalidad a los elementos del diseo, la composicin de estos elementos, su distribucin fsica, su escalabilidad y su desempeo.


Define al sistema en trminos de elementos computacionales y de las interacciones entre ellos. La arquitectura muestra la correspondencia entre los requerimientos de sistemas y los elementos del sistema construido, proveyendo as una exposicin racional para las decisiones de diseo. ELEMENTOS COMPUTACIONALES. Son entidades tales como clientes, servidores, bases de datos, filtros y capas de un sistema jerrquico. Son adems, una parte encapsulada del sistema de software, donde cada uno tiene una interfaz. INTERACCIONES. Ocurren entre los elementos a nivel de diseo, puediendo ser tan simples como las llamadas a procedimientos o variables de acceso, o tan complejas y semnticamente ricas como los protocolos del modelo cliente/servidor, los protocolos de acceso a las bases de datos, la difusin de ls eventos asincrnicos y las rfagas (stream) de los pipes. (Shaw y Garlan, 1996).


Una relacin, adems denota una conexin entre componentes. Una relacin puede ser esttica o dinmica. los
Relaciones estticas. Se muestran en el cdigo fuente, ellas reflejan la colocacin de los componentes dentro de la arquitectura. Relaciones dinmicas. tratan con las conexiones temporales y las interacciones dinmicas entre los componentes. Ellas no son fcilmente visibles a partir del cdigo 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 caracterstica del sistema que no est cubierta en la descripcin funcional del mismo. Tpicamente se refiere a aspectos tales como confiabilidad, compatibilidad, costo, facilidad de uso , etc.

NIVELES DE DISEO DE LOS SISTEMAS DE SOFTWARE

ARQUITECTURA. Los aspectos de diseo involucran la asociacin de la capacidad de todo el sistema con componentes. Los componentes son mdulos y la interconexin entre los mdulos se maneja de maneras diferentes. La composicin est orienta hacia subsistemas. CDIGO. El diseo involucra algoritmos y estructuras de datos. Los componentes son primitivas de lenguajes de programacin, tales como nmeros, caracteres, etc. Los mecanismos de composicin son arreglos, registros, procedimientos, etc. EJECUTABLE. El diseo 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 mquina.

CUALIDADES DE LAS ARQUITECTURAS

CONFORMIDAD FUNCIONAL. Segn Pressman (Pressman, 1998) una arquitectura de calidad debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acomodar todos los requisitos implcitos que desea el cliente. Adems, debe proporcionar una idea completa de que es el software, enfocando los dominios de los datos, las funciones y los comportamientos. Segn Lawrence (Lawrence, 1998) la arquitectura del software le dice a los usuarios exactamente lo que el sistema de software har. ADAPTABILIDAD. Esta caracterstica la propone Sommerville (Sommerville, 1998) al sealar que ella mide cuan fcil es hacer cambios en una arquitectura; de seguro, esto implica componentes poco acoplados. En su opinin, un sistema de software adaptable tiene una alta trazabilidad; esto quiere decir, que hay una relacin clara entre los diferentes niveles de abstraccin.


MODULARIDAD. Sin considerar el enfoque de diseo utilizado (estilo arquitectural) (Lawrence, 1998), el proceso de descomposicin separa el diseo en partes que lo componen, llamadas mdulos 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 estn bien definidas. Los mdulos se organizan jerrquicamente como resultado de la descomposicin. En la opinin de Pressman (Pressman, 1998), estos mdulos se integrarn 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) adems agrega que los mdulos encapsulan informacin; la ventaja de esta caracterstica es que el diseo interno de cada componente est oculto para el resto de los otros componentes.


NIVELES DE ABSTRACCIN. Segn Lawrence (Lawrence, 1998), estos mdulos se estructuran segn niveles de abstraccin. Estos niveles de abstraccin ayudan a entender el problema a ser resuelto por el sistema y la solucin propuesta. Segn Pressman (Pressman, 1998), cuando se plantea una solucin modular se pueden presentar muchos niveles de abstraccin. Cada fase del proceso de diseo es un refinamiento en el nivel de abstraccin. Pressman (Pressman, 1998) propone tres (3) niveles de abstraccin:
Abstraccin procedimental. Es una secuencia dada instrucciones que tiene una funcin especfica y limitada. de
Abstraccin de datos. Es una coleccin determinada de datos que describen un objeto de datos. Abstraccin de control. Implica un mecanismo de control del programa sin especificar detalles internos.


ENTENDIBLE. Sommerville (Sommerville, 1998) seala que un sistema antes de hacerle un cambio debe ser entendido. En su opinin este entendimiento estar afectado por: La cohesin, el acoplamiento, la nominacin, la documentacin y la complejidad; inclusive, seala que la complejidad tiene una relacin directa con su fcil entendimiento. COHESIN. Es una consecuencia del ocultamiento de la informacin. Un mdulo con cohesin (Pressman, 1998) realiza solamente una tarea, requiriendo poca interaccin con el resto de los procedimientos que se realizan en el resto del sistema de software. Segn Sommerville (Sommerville, 1998) la cohesin es deseable debido a que una unidad (componente) representa una parte simple de solucin. Si es necesario cambiar el sistema, la parte correspondiente est en un solo lugar y lo que se desee hacer con l estar encapsulado en l. Segn Lawrence (Lawrence, 1998) la meta es hacer que los componentes sean lo ms cohesivos posible.


ACOPLAMIENTO. Est relacionado con la cohesin. Es un indicador de la fuerza de interconexin entre los componentes o elementos de la arquitectura (Sommerville, 1998). Sistemas altamente acoplados tienen una fuerte interconexin, lo que se refleja en una gran dependencia entre los componentes. Los sistemas poco acoplados, por otro lado, tienen poca relacin entre sus componentes o elementos. La meta (Lawrence, 1998) es mantener el acoplamiento en el nivel ms bajo posible; la conectividad sencilla entre mdulos da como resultado un software que es ms fcil de comprender y menos propenso al efecto onda (Stevens et al., 1975) producido cuando los errores aparecen en una posicin y se propagan a lo largo del sistema. Pressman (Pressman, 1998) agrega que el acoplamiento depende de la complejidad de las interfaces entre los mdulos, del punto en el que se hace una entrada o referencia a un mdulo y de los datos pasan a travs de esa interfaz.

ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE LOS SISTEMAS

Bass et al. (2000) establecen que para alcanzar un atributo especfico, es necesario tomar decisiones de diseo arquitectnico que requieren un pequeo conocimiento de funcionalidad Bass et al. (2000) afirman que cada decisin 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 aos, poseen definiciones generalmente aceptadas Los atributos no estn aislados ni son independientes entre s. El anlisis de atributos no se presta a estandarizaciones. Las tcnicas de anlisis son especficas 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

Caracterstica Subcaracterstica
Adecuacin Exactitud Funcionalidad Interoperabilidad Seguridad Tolerancia a fallas Confiabilidad Recuperabilidad Desempeo Utilizacin de recursos Acoplamiento Modularidad Adaptabilidad Portabilidad Instalabilidad Coexistencia Reemplazabilidad
Elementos de tipo arquitectnico

Refinamiento de los diagramas de secuencia Identificacin de los componentes con las funciones responsables de los clculos Identificacin de conectores de comunicacin con sistemas externos Mecanismos o dispositivos que realizan explcitamente la tarea Existencia de mecanismos o dispositivos de software para manejar excepciones Existencia de mecanismos o dispositivos de software para reestablecer el nivel de desempeo y recuperar datos Componentes involucrados en un flujo de ejecucin para una funcionalidad Relacin de los componentes en trminos de espacio y tiempo Interacciones entre componentes Nmero de componentes que dependen de un componente Presencia de mecanismos de adaptacin Presencia de mecanismos de instalacin Presencia de mecanismos que faciliten la coexistencia Lista de componentes reemplazables para cada componente
Eficiencia
Mantenibilidad
SISTEMAS DE INFORMACIN II
TEORA

ESTILOS Y PATRONES Bosch (2000) establece que la imposicin de ciertos estilos arquitectnicos mejora o disminuye las posibilidades de satisfaccin de ciertos atributos de calidad del sistema Cada estilo propicia atributos de calidad, y la decisin 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 ingeniera de software.

ESTILOS ARQUITECTNICOS
Un estilo arquitectnico define una familia de sistemas de software en trminos de su organizacin estructural. Un estilo arquitectnico representa los componentes y las relaciones entre ellos con las restricciones de su aplicacin y las asociaciones y reglas de diseo para su construccin. Shaw y Garlan (Shaw y Garlan, 1996) precisan adems, que un estilo arquitectnico define un vocabulario de componentes y tipos de conectores.
TEORA

PIPES and FILTERS (Tuberas y filtros)
Cada componente tiene un conjunto de entradas y un conjunto de salidas. Filters

(Filtros)
Pipes (Tuberas)
Un componente lee la rfaga (stream) de datos en sus entradas y produce una rfaga de datos en sus salidas. Los componentes se conocen como filtros y son independientes. Los conectores se comportan como conductores de las rfagas, 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 seales, programacin paralela y sistemas distribuidos.

ORGANIZACIONES POR TIPOS DE DATOS ABSTRACTOS Y O-O
La representacin de los datos y sus operaciones primitivas se encapsulan en Tipos de Datos Abstractos (TDA) u objetos.
Manejador (TDA) obj op op obj Llamada de un proceso op op obj op op obj op
Nota: obj es un manejador op es una invocacin
op
op obj
op
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 interactan a travs de invocaciones a funciones y procedimientos. La implementacin de las funciones y procedimientos est oculta para el objeto cliente, lo cual permite hacer las modificaciones fcilmente. 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.

BASADOS EN EVENTOS, INVOCACIN IMPLCITA
En el estilo anterior, la interfaz de los componentes (objetos) cuentan con una coleccin de procedimientos y funciones, y la integracin entre ellos se logra a travs de la invocacin explcita de stos. En este estilo, se considera una tcnica de integracin conocida como invocacin implcita.
Los componentes son mdulos cuyas interfaces proveen una coleccin de procedimientos y un conjunto de eventos. Los procedimientos se llaman de la manera usual pero el componente tambin 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 ejecucin. Los generadores de eventos no saben cuales componentes se afectarn por el evento. Ejemplos de este estilo son los sistemas de gestin de bases de datos cuando aseguran la consistencia de los datos, las aplicaciones con interfaces de usuarios al separar la representacin de los datos de las aplicaciones que las gerencian.

SISTEMAS EN CAPAS
Estn organizados jerrquicamente; cada capa le presta servicios a la capa superior y es cliente de la capa inferior.
Sistemas tiles Servicio base Nivel central Composicin de varios elementos Llamadas usuales de procedimientos
Usuarios
Los componentes implementan un mquina virtual en alguna capa de la jerarqua. Los conectores estn definidos en los protocolos que determinan cmo las capas interactan. Los ejemplos ms conocidos de este estilo arquitectural son los protocolos de comunicacin.

REPOSITORIOS Consta de dos (2) tipos de componentes: una estructura central de datos que refleja el estado actual y una coleccin independiente de componentes que operan sobre el almacn central.
Computacin fc1 fc8 Acceso directo fc7
Nota: fc es una fuente de conocimiento
fc2 Blackboard (datos compartidos) fc3 Memoria fc4 fc5
fc6
Las interacciones entre los componentes pueden variar significativamente. El tipo de control seleccionado puede llevar a dos categoras: Si el tipo de transaccin es una entrada que dispara la seleccin 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 pizarrn (blackboard). Son muy utilizados para aplicaciones que requieren interpretaciones complejas de procesamiento de seales, tales como reconocimiento del habla y de patrones.

INTRPRETES
En una organizacin intrprete,una maquina virtual es producida en software. Un intrprete incluye el pseudoprograma interpretado y la mquina de interpretacin misma.
Memoria Entradas Computacin (mquina) Salidas Motor de interpretacin simulado Instruccin seleccionada Datos seleccionados Acceso a datos (bsqueda/almacenamiento) Estado interno del interpretador Datos (programa) Programa a ser interpretado
Los intrpretes son a menudo usados para construir maquinas virtuales que enlazan la mquina de computacin esperada por la semntica y la mquina de computacin disponible en el hardware.

PATRONES ARQUITECTNICOS
Buschmann et al. (1996) define patrn como una regla que consta de tres partes, la cual expresa una relacin entre un contexto, un problema y una solucin Estas son:
Contexto. Es una situacin de diseo en la que aparece un problema de diseo. Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto. Solucin. Es una configuracin que equilibra estas fuerzas.
Para Buschmann et al. (1996) son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicacin y tienen un impacto en la arquitectura de subsistemas. La seleccin de un patrn arquitectnico es, por tanto, una decisin fundamental de diseo en el desarrollo de un sistema de software.

Patrn Arquitectnico
Layers
Descripcin
Consiste en estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas, las cuales se clasifican de acuerdo a un nivel particular de abstraccin. 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 travs de conexiones (pipes), entre filtros adyacentes. Aplica para problemas cuya solucin utiliza estrategias no determinsticas. Varios subsistemas ensamblan su conocimiento para construir una posible solucin parcial aproximada. Puede ser usado para estructurar sistemas de software distribuido con componentes desacoplados que interactan por invocaciones a servicios remotos. Un componente broker es responsable de coordinar la comunicacin, como el reenvo de solicitudes, as como tambin la transmisin de resultados y excepciones. Divide una aplicacin interactiva en tres componentes. El modelo (model) contiene la informacin central y los datos. Las vistas (view) despliegan informacin al usuario. Los controladores (controlers) capturan la entrada del usuario. Las vistas y los controladores constituyen la interfaz del usuario.
Pipes and Filters
Blackboard
Broker
Model-ViewControler
TEORA

Patrn Arquitectnico
PresentationAbstractionControl
Descripcin
Define una estructura para sistemas de software interactivos de agentes de cooperacin organizados de forma jerrquica. Cada agente es responsable de un aspecto especfico de la funcionalidad de la aplicacin y consiste de tres componentes: presentacin, abstraccin y control. Aplica para sistemas de software que deben estar en capacidad de adaptar los requerimientos de cambio del sistema. Separa un ncleo funcional mnimo del resto de la funcionalidad y de partes especficas pertenecientes al cliente. Provee un mecanismo para sistemas cuya estructura y comportamiento cambia dinmicamente. Soporta la modificacin de aspectos fundamentales como estructuras tipo y mecanismos de llamadas a funciones.
Microkernel
Reflection
TEORA

ESTILOS Y PATRONES ARQUITECTNICOS
Estilo Arquitectnico Slo describe el esqueleto estructural y general para aplicaciones Son independientes del contexto al que puedan ser aplicados Cada estilo es independiente de los otros Expresan tcnicas de diseo desde una perspectiva que es independiente de la situacin actual de diseo Son una categorizacin de sistemas
Patrn Arquitectnico Existen en varios rangos de escala, comenzando con patrones que definen la estructura bsica de una aplicacin Partiendo de la definicin de patrn, requieren de la especificacin de un contexto del problema Depende de patrones ms pequeos que contiene, patrones con los que interacta, o de patrones que lo contengan Expresa un problema recurrente de diseo muy especfico, y presenta una solucin para l, desde el punto de vista del contexto en el que se presenta Son soluciones generales a problemas comunes
TEORA

FRAMEWORK
Un framework es ms que una jerarqua de clases. Es una jerarqua de clases ms un modelo de interaccin entre los objetos instanciados a partir del framework. (Levis, Rosenstein, Pree, Weinand, Gamma, Calder, Andert, Vlissides and Schmucker, 1995) Un framework es una tcnica de reuso (Johnson, 1997) Un framework es un diseo reusable de todo o partes del sistema que esta representado por un conjunto de clases abstractas y la forma como sus instancias interactan. Un framework es un esqueleto de una aplicacin que puede ser personalizado por un desarrollador de aplicaciones (Johnson, 1997). Un componente representa reuso de cdigo. Los framework son una forma de reuso de diseo (Johnson, 1997).

FRAMEWORK
Los framework son componentes en el sentido que los vendedores los venden como productos y porque una aplicacin puede usar varios framework. Pero los framework son ms personalizables que los componentes y tiene interfaces ms complejas. (Johnson, 1997) Los framework son una clase de arquitectura de dominio especfico. La diferencia principal es que un framework es un diseo orientado a objeto mientras que una arquitectura de un dominio especfico puede no serlo (Johnson, 1997). Un framework es reusable, una aplicacin semi completa que puede ser especializada para producir aplicaciones personalizadas. (Johnson y Foote, 1998; Fayad, Schmith y Johnson, 1997) En contraste con las tcnicas de reuso OO iniciales basadas en libreras, los framework estn orientados a unidades del negocio particulares y a dominios de aplicacin. (Fayad y Schmith, 97)

FRAMEWORK
El desarrollo de aplicaciones estar fuertemente basado en la integracin de mltiples 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 comunicacin y herramientas de interfaces de usuarios y procesamiento de lenguajes Integracin de middleware: Se usan comnmente 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 aplicacin amplios, tales como comunicaciones, manufactura, financieros, etc.

PATRONES DE DISEO
Un patrn describe un problema a ser resuelto, una solucin y el contexto en el cual la solucin trabaja. Nomina una tcnica y describe 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 ms pequeos que los framework. Por lo tanto, los patrones son mas abstractos que los framework Los patrones de diseo son elementos microarquitectnicos de los framewrok. Aunque el trmino Patrn de Diseo no es usado explcitamente, los novatos obtienen ganancia de sus experiencias en el desarrollo de software OO al extraer patrones de diseo a partir de varios framework especficos (Pree, 1995)

PATRONES DE DISEO
De acuerdo a Coad, los patrones de diseo son identificados al observar los bloques de construccin de ms bajo nivel; esto es sus clases y objetos y las relaciones entre ellos (Pree, 1995). Clasificacin:
ALCANCE CLASE OBJECT CREACIN Factory Method Abstract Factory Builder Protitype Singleton PROPOSITO ESTRUCTURAL Adapter Clss Adapter Object Bridge Composite Decorator Faade Flyweight Proxy COMPORTAMIENTO Interpreter Chain of Responsibility Command Iterator Mediator Memento State Strategy Visitor
TEORA

PATRONES DE DISEO
Documentacin: Nombre del patrn y su clasificacin Intencin: Qu hace? Qu problema resuelve? Alias o conocido tambin como Motivacin Aplicabilidad Estructura: representacin grfica de la jerarqua de clases y el diagrama de interaccin Participantes: las clases que lo componen y sus responsabilidades Consecuencias: trade-off de usar el patrn Implementacin: sugerencias y ayudas sobre la implementacin, fallas ms comunes Usos conocidos: ejemplos donde ha sido usado Patrones relacionados: Qu patrn se relacionan con l? En qu se diferencia de otros?

ESTILOS Y PATRONES ARQUITECTNICOS Y DE DISEO
TEORA

EL MODELO DE ARQUITECTURA 4+1 VISTAS

Usuarios finales funcionalidad VistaLgica Lgica Vista Programadores gerencia del software Vistade deDesarrollo Desarrollo Vista Escenarios Escenarios Vistade deProceso Proceso Vista Integradores de sistemas desempeo escalabilidad rendimiento VistaFsica Fsica Vista Ingenieros de sistemas topologa del sistema entregas instalacin telecomunicacin
El Modelo 4+1 Vistas organiza la descripcin de la arquitectura de un software usando cinco (5) vistas concurrentes, cada una de las cuales est dirigida a un conjunto especfico de conceptos. Los arquitectos exponen sus decisiones de diseo en cuatro (4) vistas y usan la quinta vista para ilustrar y validar dichas decisiones.

EL MODELO DE ARQUITECTURA 4+1 VISTAS

VISTA LGICA. Describe el modelo objeto del diseo cuando un mtodo de diseo O-O es usado;se puede usar un enfoque alterno para desarrollar alguna otra forma de vista lgica VISTA DE PROCESO. Describe los aspectos de diseo relacionados con la concurrencia y la sincronizacin. VISTA FSICA. Describe el mapa del SW dentro del HW refleja los aspectos de distribucin. VISTA DE DESARROLLO. Describe la organizacin esttica del software en el ambiente de desarrollo. ESCENARIOS. Los diseadores de software organizan la descripcin de sus decisiones arquitecturales alrededor de estas cuatro (4) vistas, y las ilustran con una pequea seleccin de casos de uso o escenarios, constituyendo as la quinta vista. La arquitectura est parcialmente producida por esos escenarios.

INTERDEPENDENCIA ENTRE VISTAS
Lgica
Procesos
Se identifican caractersticas tales como: Autonoma, quien invoca a quien. Persitencia. Distribucin: desde donde son accesibles las operaciones. clase se puede implementar en un mdulo, paquete, etc.
Lgica
Desarrollo Una
TEORA

Teoría PS6116 Arq. de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Teoría PS6116 Arq. de Software

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SIMN BOLVAR

DEPARTAMENTO DE PROCESOS Y SISTEMAS

SISTEMAS DE INFORMACIN II TEORA

UNIVERSIDAD SIMN BOLVAR

ARQUITECTURA DEL SISTEMA DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

ARQUITECTURA DEL SISTEMA DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

ARQUITECTURA DEL SISTEMA DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

NIVELES DE DISEO DE LOS SISTEMAS DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CUALIDADES DE LAS ARQUITECTURAS

UNIVERSIDAD SIMN BOLVAR

CUALIDADES DE LAS ARQUITECTURAS

UNIVERSIDAD SIMN BOLVAR

CUALIDADES DE LAS ARQUITECTURAS

UNIVERSIDAD SIMN BOLVAR

CUALIDADES DE LAS ARQUITECTURAS

UNIVERSIDAD SIMN BOLVAR

CUALIDADES DE LAS ARQUITECTURAS

UNIVERSIDAD SIMN BOLVAR

ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE LOS SISTEMAS

La arquitectura es un artefacto que determina atributos de calidad del sistema.

UNIVERSIDAD SIMN BOLVAR

ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE LOS SISTEMAS

Elementos de tipo arquitectnico

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

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

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

fc2 Blackboard (datos compartidos) fc3 Memoria fc4 fc5

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

Pipes and Filters

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

ESTILOS Y PATRONES ARQUITECTNICOS

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

UNIVERSIDAD SIMN BOLVAR

ESTILOS Y PATRONES ARQUITECTNICOS Y DE DISEO

UNIVERSIDAD SIMN BOLVAR

EL MODELO DE ARQUITECTURA 4+1 VISTAS

UNIVERSIDAD SIMN BOLVAR

EL MODELO DE ARQUITECTURA 4+1 VISTAS

UNIVERSIDAD SIMN BOLVAR

INTERDEPENDENCIA ENTRE VISTAS

También podría gustarte