Diseo arquitectnico

Objetivos
El objetivo de este captulo es introducir los conceptos de Arquitectura de
Software y diseo arquitectnico.
Cuando haya ledo el captulo, vas a:
entender por qu el diseo de la arquitectura de software es importante;
entender las decisiones que tienen que hacerse sobre el sistema arquitectura
durante el proceso de diseo arquitectnico;
se han introducido a la idea de los patrones arquitectnicos, de eficacia
probada formas de organizar las arquitecturas de sistemas, que pueden ser
reutilizados en diseos de sistemas;
conocer los patrones arquitectnicos que se utilizan a menudo en diferentes
tipos del sistema de aplicacin, incluidos los sistemas de procesamiento de
transacciones y sistemas de procesamiento del lenguaje.

Contenido
6.1 decisiones de diseo arquitectnico
6.2 puntos de vista de arquitectura
6.3 Los patrones arquitectnicos
6.4 arquitecturas de aplicaciones

El diseo arquitectnico se refiere a la comprensin de cmo debera ser un

sistema organizada y el diseo de la estructura general de ese sistema. En el
modelo del software proceso de desarrollo, como se muestra en el captulo 2, el
diseo arquitectnico es la primera etapa en el proceso de diseo de software.
Es el vnculo crtico entre el diseo y ingeniera de requisitos, ya que identifica
los principales componentes estructurales en un sistema y las relaciones entre
ellos. La salida del proceso de diseo arquitectnico es un modelo
arquitectnico que describe cmo el sistema se organiza como un conjunto de
la comunicacin componentes.
En los procesos giles, es generalmente aceptado que una etapa temprana del
desarrollo proceso debe estar preocupado con el establecimiento de una
arquitectura general del sistema.
El desarrollo incremental de arquitecturas no suele tener xito. Mientras
refactorizacin componentes en respuesta a los cambios suele ser
relativamente fcil, refactorizacin un sistema arquitectura es probable que
sea caro.
Para ayudarle a entender lo que quiero decir con la arquitectura del sistema,
considero Figura 6.1.
Esto muestra un modelo abstracto de la arquitectura de un sistema de robot de
embalaje que muestra los componentes que tienen que ser desarrollado. Este
sistema robtico puede embalar
diferente tipo de objeto. Se utiliza un
componente de la visin de seleccionar objetos en una cinta transportadora,
identificar el tipo de objeto, y seleccione el tipo de embalaje. El sistema
entonces mueve los objetos de la cinta transportadora de entrega a envasar.
Coloca objetos embalados en otro transportador. El modelo arquitectnico
muestra estos componentes y los enlaces entre ellos.
En la prctica, existe una superposicin significativa entre los procesos de los
requisitos ingeniera y diseo arquitectnico. Idealmente, una especificacin
del sistema no debe incluir cualquier informacin de diseo. Esto no es realista
excepto para sistemas muy pequeos.
Descomposicin arquitectnica general es necesario estructurar y organizar la
especificacin.
Por lo tanto, como parte del proceso de ingeniera de requisitos, es posible
proponer una arquitectura de sistema abstracto donde relacionamos grupos de
funciones del sistema o cuenta con componentes de gran escala o
subsistemas.
A continuacin, puede utilizar este descomposicin para discutir los requisitos
y caractersticas del sistema con las partes interesadas.
Usted puede disear arquitecturas de software en dos niveles de abstraccin,
que llamo arquitectura en la pequea y la arquitectura en la gran:

1. Arquitectura en el pequeo tiene que ver con la arquitectura de los

programas individuales.
En este nivel, estamos preocupados por la forma en que un programa
individual se descompone en componentes. Este captulo se refiere sobre todo
con el programa arquitecturas.
2. Arquitectura de la grande tiene que ver con la arquitectura de empresa
compleja sistemas que incluyen otros sistemas, programas y componentes del
programa.

Estos sistemas empresariales estn distribuidas en diferentes ordenadores, que

pueden ser propiedad y gestionados por diferentes empresas. Cubro
arquitectura en el gran en los captulos 18 y 19, donde discutir sistemas

distribuidos arquitecturas.

Usted puede disear arquitecturas de software en dos niveles de abstraccin,

que llamo arquitectura en la pequea y la arquitectura en la gran:
1. Arquitectura en el pequeo tiene que ver con la arquitectura de los
programas individuales.
En este nivel, estamos preocupados por la forma en que un programa
individual se descompone en componentes. Este captulo se refiere sobre todo
con el programa arquitecturas.

2. Arquitectura de la grande tiene que ver con la arquitectura de empresa

compleja sistemas que incluyen otros sistemas, programas y componentes del
programa.
Estos sistemas empresariales estn distribuidas en diferentes ordenadores, que
pueden ser propiedad y gestionados por diferentes empresas. Cubro
arquitectura en el gran en los captulos 18 y 19, donde discutir sistemas
distribuidos arquitecturas.
Hofmeister et al. (2000) proponen que una arquitectura de software puede
servir en primer lugar como un plan de diseo para la negociacin de los
requisitos del sistema, y en segundo lugar como medio de discusiones de
estructuracin con clientes, desarrolladores y administradores. Tambin
sugieren que es una herramienta esencial para la gestin de la complejidad.
Oculta los detalles y permite que el los diseadores se centran en las
abstracciones clave del sistema.
Arquitecturas de sistema son con frecuencia modelaron usando diagramas de
bloques simples, como en la Figura 6.1.

Cada caja en el diagrama representa un componente. Las casillas de cajas

indican que el componente se ha descompuesto a los sub-componentes. Las
flechas significan que los datos y ni control seales se pasan de componente a
componente en la direccin de las flechas. Usted puede ver muchos ejemplos
de este tipo de modelo de arquitectura en la arquitectura de software de Booch
catlogo (Booch, 2009).
Los diagramas de bloques presentan un cuadro de alto nivel de la estructura
del sistema, lo que la gente desde diferentes disciplinas, que estn
involucrados en el proceso de desarrollo del sistema, puede entender
fcilmente. Sin embargo, a pesar de su uso generalizado, Bass et al. (2003) No
me gusta diagramas de bloques informales para describir una arquitectura.
Afirman que estos diagramas informales son pobres representaciones
arquitectnicas, ya que muestran ni el tipo de las relaciones entre los
componentes del sistema ni los componentes 'externamente propiedades
visibles.

Los diagramas de bloques son una forma adecuada de describir la arquitectura

del sistema durante el proceso de diseo, ya que son una buena manera de
apoyar las comunicaciones entre las personas involucradas en el proceso. En
muchos proyectos, stos son a menudo el nica documentacin arquitectnica
que existe. Sin embargo, si la arquitectura de un sistema de ha de ser
minuciosamente documentado, entonces es mejor usar una notacin con bien
definido semntica para descripcin arquitectnica. Sin embargo, como se
discute en la Seccin 6.2, algunos la gente piensa que la documentacin
detallada es ni til, ni realmente vale la pena el costo de su desarrollo.