Teoría PS6116 Arq. de Software PDF

UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
SISTEMAS DE INFORMACIÓN II
TEORÍA
CONTENIDO:
ARQUITECTURA DEL SISTEMA DE SOFTWARE
NIVELES DE DISEÑO DE LOS SISTEMAS DE SOFTWARE
CUALIDADES DE LAS ARQUITECTURAS
ESTILOS Y PATRONES - ESTILOS ARQUITECTÓNICO - PATRÓN
ARQUITECTÓNICO
FRAMEWORK – PATRONES DE DISEÑO
EL MODELO DE ARQUITECTURA 4+1 VISTAS
Material diseñado y elaborado por:

Prof. María A. Pérez de Ovalles
Prof. Luis Eduardo Mendoza M.

Se obtiene mediante un proceso de partición que relaciona los ele-
mentos de una solución de software con partes de un problema del
del mundo real definido implícitamente durante el análisis de los
requisitos. 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.
SISTEMAS DE INFORMACIÓN II TEORÍA

Define al sistema en términos de elementos computacionales y
de 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).

• 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 LOS

SISTEMAS 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.


• 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 debe
acomodar 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 hacer
cambios 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 parte
correspondiente 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
Identificación de los componentes con las funciones
Exactitud
responsables de los cálculos
Funcionalidad
Identificación de conectores de comunicación con
Interoperabilidad
sistemas externos
Mecanismos o dispositivos que realizan explícitamente
Seguridad
la tarea
Existencia de mecanismos o dispositivos de software
Tolerancia a fallas
para manejar excepciones
Confiabilidad Existencia de mecanismos o dispositivos de software
Recuperabilidad para reestablecer el nivel de desempeño y recuperar
datos
Componentes involucrados en un flujo de ejecución
Desempeño
para una funcionalidad
Eficiencia
Utilización de Relación de los componentes en términos de espacio y
recursos tiempo
Acoplamiento Interacciones entre componentes
Mantenibilidad
Número de componentes que dependen de un
Modularidad
componente
Adaptabilidad Presencia de mecanismos de adaptación
Instalabilidad Presencia de mecanismos de instalación
Portabilidad
Coexistencia Presencia de mecanismos que faciliten la coexistencia
Lista de componentes reemplazables para cada
Reemplazabilidad
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.

PIPES and FILTERS (Tuberías y filtros)
Cada componente tiene un conjunto de entradas y un conjunto

de salidas. Filters
(Filtros)
Pipes
(Tuberías)
• 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.
ORGANIZACIONES POR TIPOS DE DATOS ABSTRACTOS Y O-O
La representación de los datos y sus operaciones primitivas se
encapsulan en Tipos de Datos Abstractos (TDA) u objetos.
Manejador obj op op
(TDA) op obj
op
op
obj op
obj op op
Llamada de Nota: obj es un manejador
op obj op es una invocación
un proceso 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 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.
BASADOS 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 la
integración entre ellos se logra a través de la invocación explícita
de éstos. En este estilo, se considera una técnica de integración
conocida 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, las
aplicaciones 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 servicios

a la capa superior y es cliente de la capa inferior.
Sistemas útiles Llamadas usuales

de procedimientos
Servicio base
Nivel
central
Composición de
varios elementos
Usuarios
• Los componentes implementan un máquina virtual en alguna capa de

la 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.
REPOSITORIOS
Consta de dos (2) tipos de componentes: una estructura central de datos
que refleja el estado actual y una colección independiente de compo-
nentes que operan sobre el almacén central.
Computación
fc1 fc2
fc8 fc3
Blackboard
Acceso (datos
directo Memoria
compartidos)
fc7 fc4
Nota:
fc es una fuente de conocimiento
fc6 fc5
• 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.
INTÉ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.
Memoria
Programa a ser
Entradas Datos interpretado
(programa)
Computación
(máquina)
Motor de Estado
Salidas Instrucción seleccionada
interpretación interno del
Datos seleccionados
simulado interpretador
Acceso a datos
(búsqueda/almacenamiento)
• 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.
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.

Patrón
Descripción
Arquitectónico
Consiste en estructurar aplicaciones que
pueden ser descompuestas en grupos de
Layers
subtareas, las cuales se clasifican de acuerdo a
un nivel particular de abstracción.
Provee una estructura para los sistemas que
procesan un flujo de datos. Cada paso de
Pipes and Filters procesamiento está encapsulado en un
componente filtro (filter). El dato pasa a través
de conexiones (pipes), entre filtros adyacentes.
Aplica para problemas cuya solución utiliza
estrategias no determinísticas. Varios
Blackboard subsistemas ensamblan su conocimiento para
construir una posible solución parcial ó
aproximada.
Puede ser usado para estructurar sistemas de
software distribuido con componentes
desacoplados que interactúan por invocaciones
a servicios remotos. Un componente broker es
Broker
responsable de coordinar la comunicación,
como el reenvío de solicitudes, así como
también la transmisión de resultados y
excepciones.
Divide una aplicación interactiva en tres
componentes. El modelo (model) contiene la
información central y los datos. Las vistas
Model-View-
(view) despliegan información al usuario. Los
Controler
controladores (controlers) capturan la entrada
del usuario. Las vistas y los controladores
constituyen la interfaz del usuario.

Patrón
Descripción
Arquitectónico
Define una estructura para sistemas de
software interactivos de agentes de cooperación
Presentation- organizados de forma jerárquica. Cada agente
Abstraction- es responsable de un aspecto específico de la
Control funcionalidad de la aplicación y consiste de tres
componentes: presentación, abstracción y
control.
Aplica para sistemas de software que deben
estar en capacidad de adaptar los
requerimientos de cambio del sistema. Separa
Microkernel
un núcleo funcional mínimo del resto de la
funcionalidad y de partes específicas
pertenecientes al cliente.
Provee un mecanismo para sistemas cuya
estructura y comportamiento cambia
Reflection 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

Existen en varios rangos de escala,
Sólo describe el esqueleto estructural y
comenzando con patrones que definen la
general para aplicaciones
estructura básica de una aplicación
Partiendo de la definición de patrón, requieren
Son independientes del contexto al que
de la especificación de un contexto del
puedan ser aplicados
problema
Depende de patrones más pequeños que
Cada estilo es independiente de los otros contiene, patrones con los que interactúa, o de
patrones que lo contengan
Expresa un problema recurrente de diseño
Expresan técnicas de diseño desde una
muy específico, y presenta una solución para
perspectiva que es independiente de la
él, desde el punto de vista del contexto en el
situación actual de diseño
que se presenta
Son soluciones generales a problemas
Son una categorización de sistemas
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 and
Schmucker, 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 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 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 patrones
de 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


Usuarios finales Programadores
• funcionalidad • gerencia del software
VistaLógica
Vista Lógica Vistade
Vista deDesarrollo
Desarrollo
Escenarios
Escenarios
Vistade
Vista deProceso
Proceso VistaFísica
Vista Física
Integradores de sistemas Ingenieros de sistemas

• desempeño • topología del sistema
• escalabilidad • entregas
• rendimiento • instalación
• telecomunicación
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Ó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
Lógica 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.

Teoría PS6116 Arq. de Software PDF

Cargado por

Información del documento

Título original

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 PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SIMÓN BOLÍVAR

DEPARTAMENTO DE PROCESOS Y SISTEMAS

Material diseñado y elaborado por:

ARQUITECTURA DEL SISTEMA DE SOFTWARE

ARQUITECTURA DEL SISTEMA DE SOFTWARE

ARQUITECTURA DEL SISTEMA DE SOFTWARE

SISTEMAS DE INFORMACIÓN II TEORÍA

NIVELES DE DISEÑO DE LOS

SISTEMAS DE INFORMACIÓN II TEORÍA

CUALIDADES DE LAS ARQUITECTURAS

CUALIDADES DE LAS ARQUITECTURAS

SISTEMAS DE INFORMACIÓN II TEORÍA

CUALIDADES DE LAS ARQUITECTURAS

SISTEMAS DE INFORMACIÓN II TEORÍA

CUALIDADES DE LAS ARQUITECTURAS

• COHESIÓN. Es una consecuencia del ocultamiento de la informa-

SISTEMAS DE INFORMACIÓN II TEORÍA

CUALIDADES DE LAS ARQUITECTURAS

SISTEMAS DE INFORMACIÓN II TEORÍA

ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE

SISTEMAS DE INFORMACIÓN II TEORÍA

ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE

SISTEMAS DE INFORMACIÓN II TEORÍA

• Bosch (2000) establece que la imposición de ciertos

SISTEMAS DE INFORMACIÓN II TEORÍA

Un estilo arquitectónico define una familia de sistemas de

SISTEMAS DE INFORMACIÓN II TEORÍA

Cada componente tiene un conjunto de entradas y un conjunto

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

SISTEMAS DE INFORMACIÓN II TEORÍA

Están organizados jerárquicamente; cada capa le presta servicios

Sistemas útiles Llamadas usuales

• Los componentes implementan un máquina virtual en alguna capa de

• Los intérpretes son a menudo usados para construir maquinas

• Buschmann et al. (1996) define patrón como una regla que

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA

ESTILOS Y PATRONES ARQUITECTÓNICOS

Estilo Arquitectónico Patrón Arquitectónico

SISTEMAS DE INFORMACIÓN II TEORÍA

• Un framework es más que una jerarquía de clases. Es una

• Los framework son componentes en el sentido que los

• El desarrollo de aplicaciones estará fuertemente basado en la

• Un patrón describe un problema a ser resuelto, una solución y

SISTEMAS DE INFORMACIÓN II TEORÍA

• De acuerdo a Coad, los patrones de diseño son identificados al

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA

ESTILOS Y PATRONES ARQUITECTÓNICOS Y DE

SISTEMAS DE INFORMACIÓN II TEORÍA

EL MODELO DE ARQUITECTURA 4+1 VISTAS

Integradores de sistemas Ingenieros de sistemas

El Modelo 4+1 Vistas organiza la descripción de la arquitectura

EL MODELO DE ARQUITECTURA 4+1 VISTAS

INTERDEPENDENCIA ENTRE VISTAS

Lógica Procesos Se identifican características

Lógica Desarrollo Una clase se puede

SISTEMAS DE INFORMACIÓN II TEORÍA

También podría gustarte