DISEÑO DE LA

ARQUITECTURA DEL
SOFTWARE
UNIDAD 2
TEMA 2.4.
Ing. Rosa Imelda
García Chi
 Diseño de software:
 Eldiseño se ha descrito como un
proceso multifase en el que se sintetizan
representaciones de la estructura de los
datos, la estructura del programa, las
características de la interfaz y los
detalles procedimentales desde los
requisitos de la información.
 Según Freeman, el diseño
es…
 ...una actividad en la que se toman
decisiones importantes, frecuentemente
de naturaleza estructural. Comparte con
la programación un interés por la
abstracción de la representación de la
información y de las secuencias de
procesamiento, pero el nivel de detalle
es muy diferente en ambos casos.
Según Freeman …
 Eldiseño construye
representaciones coherentes
y bien planificadas de los
programas, concentrándose
en las interrelaciones de los
componentes de mayor nivel
y en las operaciones lógicas
implicadas en los niveles
inferiores.. .
Se considera que …
 El diseño está dirigido por la información.
 Los métodos de diseño del software se
obtienen del estudio de cada uno de los tres
dominios del modelo de análisis:
• El dominio de los datos,
• el funcional y
• el de comportamiento
sirven de directriz para la creación del diseño.
¿Qué es el diseño arquitectónico?

 El diseño arquitectónico representa la

estructura de los datos y los
componentes del programa que se
requieren para construir un sistema de
computadora.
 Constituye el estilo arquitectónico que
tendrá el sistema, las estructuras de
datos y las propiedades de los
componentes y la interrelación que tiene
con otros componentes arquitectónicos
del sistema.
¿Quién lo hace?
 Lo puede llevar a cabo el ingeniero de
software…
 Aunque se recomienda que…
 El diseño de la base de datos la lleve a cabo el
diseñador de base de datos o almacén de
datos y
 Que el arquitecto del sistema seleccione el
estilo de arquitectura a utilizar, según los
requisitos recolectados en el análisis. (esto
tiene que ver con el modelo de desarrollo de
software mas conveniente a utilizar)
 ¿Por qué es importante?
 Proporciona los detalles completos de
todo el software que se va a construir.
 Se aprecia cada uno de los detalles con
conformarán la software.
 Asegura que la construcción sea
correcta y completa.
¿Cuáles son los pasos?
 Eldiseño arquitectónico comienza con el
diseño de datos y después procede a la
derivación de una o mas
representaciones de la estructura
arquitectónica del sistema.
Arquitectura de Software
 Para poder entender el diseño, es
necesario comprender que es la
arquitectura de software.
Arquitectura de software
 La arquitectura de software de un
sistema de programa o computación es
la estructura de las estructuras del
sistema, la cual comprende los
componentes del software, las
propiedades de esos componentes
visibles externamente, y las relaciones
entre ellos.
La arquitectura no es el
software operacional.
Más bien, es la representación que capacita al
ingeniero del software para:
 (1) analizar la efectividad del diseño para la
consecución de los requisitos fijados,
 (2) considerar las alternativas arquitectónicas
en una etapa en la cual hacer cambios en el
diseño es relativamente fácil, y
 (3) reducir los riesgos asociados a la
construcción del software.
En el contexto del diseño
arquitectónico,
 uncomponente del software puede ser
tan simple como un módulo de
programa, pero también puede ser algo
tan complicado como incluir bases de
datos y software intermedio
«middleware») que permiten la
configuración de una red de clientes y
servidores.
Propiedades de los componentes
 Las propiedades de los componentes
son aquellas características necesarias
para entender cómo los componentes
interactúan con otros componentes.
 A nivel arquitectónico, no se especifican
las propiedades internas (por ejemplo,
detalles de un algoritmo).
Relaciones entre los
componentes
 Las relaciones entre los componentes
pueden ser tan sencillas como una
llamada de procedimiento de un módulo
a otro, o tan complicadas como el
protocolo de acceso a bases de datos.
El diseño de la arquitectura de
software tiene en cuenta dos niveles
de la pirámide del diseño

Diseño de datos
y
Diseño arquitectónico
Diseño de datos y
Diseño Arquitectónico
 En este sentido, el diseño de datos nos
facilita la representación de los
componentes de datos de la
arquitectura.

 Eldiseño arquitectónico se centra en la

representación de la estructura de los
componentes del software, sus
propiedades e interacciones.
¿Por qué es importante la
arquitectura?
 Las representaciones de la arquitectura
de software facilitan la comunicación
entre todas las partes (partícipes)
interesadas en el desarrollo de un
sistema basado en computadora;
La arquitectura …
 la arquitectura destaca decisiones
tempranas de diseño que tendrán un
profundo impacto en todo el trabajo de
ingeniería del software que sigue, y es tan
importante en el éxito final del sistema como
una entidad operacional;

 la arquitectura «constituye un modelo

relativamente pequeño e intelectualmente
comprensible de cómo está estructurado el
sistema y de cómo trabajan juntos sus
componentes».
La arquitectura…
 El modelo de diseño arquitectónico y los
patrones arquitectónicos contenidos dentro
son transferibles.

 Esto es, los estilos y patrones de arquitectura

pueden ser aplicados en el diseño de otros
sistemas y representados a través de un
conjunto de abstracciones que facilitan a los
ingenieros del software la descripción de la
arquitectura de un modo predecible.
DISEÑO DE DATOS
 Eldiseño de datos (a veces llamado
arquitectura de datos) crea un modelo
de datos y/o información que se
representa con un alto nivel de
Abstracción (la visión de datos del
cliente/usuario).
Modelo de datos
 Este modelo de datos, es entonces refinado
en progresivas representaciones especificas
de la implementación, que pueden ser
procesadas por un sistema basado en
computadora.

 En muchas aplicaciones de software, la

arquitectura de datos tendrá una gran
influencia sobre la arquitectura del software
que debe procesarlo
Estructura de datos
 Laestructura de datos ha sido siempre
una parte importante del diseño de
software. Al nivel de los componentes
del programa, el diseño de las
estructuras de datos y de los algoritmos
asociados requeridos para su
manipulación, son la parte esencial en la
creación de aplicaciones de alta calidad
Modelo de datos
A nivel de aplicación, la traducción de un
modelo de datos (derivado como parte
de la ingeniería de requisitos) en una
base de datos es el punto clave para
alcanzar los objetivos de negocio del
sistema.
Modelo de datos
 A nivel de negocios, el conjunto de
información almacenada en las diferentes
bases de datos y reorganizada en el almacén
de datos facilita la minería de datos o el
descubrimiento de conocimiento que puede
influir en el propio éxito del negocio.
 De cualquier modo, el diseño de datos juega
un papel muy importante.
Modelado de datos, estructuras de
datos, bases de datos y
almacén de datos

 Losobjetos de datos definidos durante el

análisis de Requisitos del software son
modelados utilizando diagramas de
entidad-relación y el diccionario de datos
Del diseño de datos a
estructuras de componentes
 Laactividad de diseño de datos traduce
esos elementos del modelo de requisitos
en estructuras de datos a nivel de los
componentes del software y, cuando es
necesario, a arquitectura de base de
datos a nivel de aplicación.
La arquitectura de datos
 Durante muchos años, la arquitectura de
datos estuvo limitada, generalmente, a
las estructuras de datos a nivel del
programa y a las bases de datos a nivel
de aplicación.
 Pero hoy, las empresas grandes y
pequeñas están inundadas de datos.
Las empresas y
las bases de datos
 No es inusual, incluso para una mediana
empresa, tener docenas de bases de datos
sirviendo diferentes aplicaciones de cientos de
gigabytes de datos.

 El desafío de las empresas ha sido extraer

información útil de su entorno de datos,
particularmente cuando la información deseada
está funcionalmente interrelacionada (por
ejemplo, información que sólo puede obtenerse
si los datos de marketing específicos se cruzan
con los datos de la ingeniería del producto).
Desafío de TI
 Para resolver este desafío, la comunidad
de empresas de TI ha desarrollado las
técnicas de minería de datos, también
llamadas
“descubrimiento de conocimiento en
bases de datos” (DCBC),
que navegan a través de las bases de
datos en un intento por extraer el nivel
de información de negocio apropiado.
Múltiples Bases de Datos
 Sin embargo, la existencia de múltiples bases
de datos, sus diferentes estructuras, el grado
de detalle contenido en las bases de datos, y
muchos otros factores hacen difícil la minería
de datos dentro de un entorno con bases de
datos existentes.

 Una solución alternativa, llamada

almacén de datos,
añade una capa adicional a
la arquitectura de datos.
Almacén de datos
 Un almacén de datos es un entorno de
datos separado, que no está
directamente integrado con las
aplicaciones del día a día, pero que
abarca todos los datos utilizados por una
empresa
Almacén de datos
 En cierto sentido, un almacén de datos
es una gran base de datos
independiente, que contiene algunos,
pero no todos los datos almacenados en
las bases de datos que sirven al
conjunto de aplicaciones requeridas en
un negocio.
Sin embargo, hay muchas características
diferenciales entre un almacén de datos y
una base de datos típica

Orientación por materia.

Integración.

Restricciones de tiempo.
No volatilidad.
Orientación por materia.
 Un almacén de datos está organizado
por las materias importantes del
negocio, más que por los procesos o
funciones del negocio.
 Esto nos lleva a una exclusión de datos
que podrían ser necesarios para una
función particular del negocio, pero que
generalmente no son necesarios para la
minería de datos.
Integración.
 Sintener en cuenta la fuente de datos,
da consistencia nombrar convenciones,
unidades y medidas, estructuras de
codificación y atributos físicos incluso
cuando la inconsistencia existe a través
de las diferentes bases de datos
orientadas a aplicaciones.
 Restricciones de tiempo.
 Para un entorno de aplicación orientado a
transacción, los datos son precisos en el momento
del acceso y por un periodo de tiempo relativamente
pequeño (normalmente de 60 a 90 días) antes del
acceso.
 Sin embargo, en un almacén de datos, se accede a
los datos en un momento específico del tiempo (por
ejemplo, los clientes con los que se ha contactado el
mismo día que el nuevo producto ha sido anunciado
en la prensa comercial).
 El horizonte típico de tiempo de un almacén de datos
es de 5 a 10 años.
No volatilidad.
A diferencia de las típicas bases de
datos de aplicaciones de negocios que
atraviesan una continua corriente de
cambios (insertar, borrar, actualizar), en
el almacén de datos los datos se cargan,
pero después de la primera
transferencia, los datos no cambian.
Diseño de datos a nivel de
componentes
 Eldiseño de datos a nivel de
componentes se centra en la
representación de estructuras de datos a
las que se accede directamente a través
de uno o más componentes del
software.
Análisis de requisitos y diseño
 Recordando que el análisis de requisitos
y el diseño a menudo se solapan,
consideramos el siguiente conjunto de
principios para la especificación de
datos:
 Principios para especificaciones
1. Los principios del análisis sistemático
aplicados a la función y al
comportamiento deberían aplicarse
también a los datos.
 Invertimos mucho tiempo y esfuerzo
en obtener, revisar y especificar los
requisitos funcionales y el diseño
preliminar.
 Principios para especificaciones
 Las representaciones de flujo de
datos y contenido deberían
desarrollarse y revisarse, las de
objetos de datos deberían
identificarse, se deberían estudiar las
organizaciones alternativas de datos y
debería evaluarse el impacto del
modelado de datos sobre el diseño
del software.
Principios
2. Todas las estructuras de datos y las
operaciones a llevar a cabo en cada una de
ellas deberían estar claramente identificadas.
 El diseño de una estructura de datos eficaz
debe tener en cuenta las operaciones que se
van a llevar a cabo sobre dicha estructura de
datos
 La especificación de los tipos de datos
abstractos puede simplificar
considerablemente el diseño del software.
Principios
3. Se debería establecer un diccionario de datos
y usarlo para definir el diseño de los datos y
del programa.
 Un diccionario de datos representa
explícitamente las relaciones entre los objetos
de datos y las restricciones de los elementos
de una estructura de datos.
 Los algoritmos que deben aprovecharse de
estas relaciones específicas pueden definirse
más fácilmente si existe una especificación de
datos tipo diccionario.
Principios
4. Las decisiones de diseño de datos de bajo
nivel deberían dejarse para el final del
proceso de diseño.
 Se puede usar un proceso de refinamiento
paso a paso para el diseño de datos. Es
decir, la organización general de datos
puede definirse durante el análisis de
requisitos; refinarse durante los trabajos de
diseño de datos y especificarse en detalle
durante el diseño a nivel de componentes.
Principios
4…
 El enfoque descendente del diseño de data
proporciona ventajas análogas al enfoque
descendente del diseño de software: se
diseñan y evalúan primeramente los
atributos estructurales principales de manera
que se pueda establecer la arquitectura de
los datos.
Principios
5. La representación de las estructuras de
datos deberían conocerla sólo aquellos
módulos que deban hacer uso directo de
los datos contenidos dentro de la
estructura.
 Principios
6. Debería desarrollarse una biblioteca de
estructuras de datos útiles y de las operaciones
que se les pueden aplicar. Las estructuras de
datos y las operaciones deberían considerarse
como recursos para el diseño del software.
 Las estructuras de datos pueden diseñarse
para que se puedan reutilizar.
 Una biblioteca de plantillas de estructuras de
datos (tipos abstractos de datos) puede reducir
el esfuerzo del diseño y de la especificación de
datos.
Principios
7. Un diseño del software y un lenguaje de
programación debería soportar la
especificación y realización de los tipos
abstractos de datos.
 La implementación de una estructura de datos
sofisticada puede hacerse excesivamente
difícil si no existen los medios de
especificación directa de la estructura en el
lenguaje de programación escogido para dicha
implementación.
 Principios

 Los principios descritos anteriormente

forman una base para un enfoque de
diseño de datos a nivel de componentes
que puede integrarse en las fases de
análisis y diseño.
Estilos arquitectónicos
 Elsoftware construido para
sistemas basados en computadoras
también cuenta con diversos
estilos arquitectónicos:
 Estilos arquitectónicos o
patrones
 Cada estilo describe una categoría del sistema que
contiene:
(1) un conjunto de componentes (por ejemplo, una base de
datos, módulos computacionales) que realizan una
función requerida por el sistema;
(2) un conjunto de conectores que posibilitan la
«comunicación, la coordinación y la cooperación» entre
los componentes;
(3) restricciones que definen cómo se pueden integrar los
componentes que forman el sistema; y
(4) Modelos semánticos que permiten al diseñador entender
las propiedades globales de un sistema para analizar las
propiedades conocidas de sus partes constituyentes.
Una breve taxonomía de estilos
y patrones
 Cientosde miles de sistemas
basados en computadora, la gran
mayoría pueden ser clasificados
dentro de uno de los estilos
arquitectónicos siguientes:
Estilos Arquitectónicos:
 Arquitecturas centradas de datos.
 Arquitecturas de flujo de datos.

 Arquitecturas de llamada y retorno.

 Arquitecturas orientadas a objetos.

 Arquitecturas estratificadas.
Arquitecturas centradas de
datos
 En el centro de esta arquitectura se
encuentra un almacén de datos (por
ejemplo, un documento o una base de
datos) al que otros componentes
acceden con frecuencia para actualizar,
añadir, borrar o bien modificar los datos
del almacén.
Arquitecturas de flujo de datos.
 Estaarquitectura se aplica cuando los
datos de entrada son transformados a
través de una serie de componentes
computacionales o manipulativos en los
datos de salida.
Arquitecturas de llamada y
retorno.
 Este estilo arquitectónico permite al
diseñador del software (arquitecto del
sistema) construir una estructura de
programa relativamente fácil de
modificar y ajustar a escala.
 Existen dos subestilos dentro de esta
categoría:
Arquitecturas de llamadas de
retorno:

 arquitecturas de programa principal.

 arquitecturas
de llamada de
procedimiento remoto.
Arquitecturas orientadas a
objetos.
 Los componentes de un sistema
encapsulan los datos y las operaciones
que se deben realizar para manipular los
datos.
 La comunicación y la coordinación entre
componentes se consigue a través del
paso de mensajes.
 Arquitecturas estratificadas.
 La estructura básica de una arquitectura
estratificada se representa en la Figura14.3. Se
crean diferentes capas y cada una realiza
operaciones que progresivamente se aproximan
más al cuadro de instrucciones de la máquina.
 En la capa externa, los componentes sirven a
las operaciones de interfaz de usuario.
 En la capa interna, los componentes realizan
operaciones de interfaz del sistema. Las capas
intermedias proporcionan servicios de utilidad y
funciones del software de aplicaciones.
 Estilos Arquitectónicos
 Los estilos arquitectónicos citados anteriormente son
sólo una pequeña parte de los que dispone el
diseñador de software .
 Una vez que la ingeniería de requisitos define las
características y las restricciones del sistema que ha de
ser construido, se escoge el patrón arquitectónico
(estilo) o la combinación de patrones (estilos) que mejor
encajan con las características y restricciones.
 En muchos casos, puede ser apropiado más de un
patrón y se podrían diseñar y evaluar estilos
arquitectónicos alternativos.
Un mé todo de an ális is de
com pr omis o p ar a l a
Ar qu it ectura

El Instituto de Ingeniería de Software (SEI) ha

desarrollado un Método de análisis de
compromiso para la arquitectura (MACA) que
establece un proceso de evaluación iterativo
para las arquitecturas de software.
Las actividades de análisis de diseño
mencionadas abajo se realizan iterativamente:
 MACA
1. Recopilación de escenarios.
2. Elicitación de requisitos.
3. Describir los patroneslestilos arquitectónicos escogidos
para derivar los escenarios y requisitos.
4. Evaluar los atributos de calidad considerando cada
atributo de forma aislada.
5.Identificar la sensibilidad de los atributos de calidad
con los diferentes atributos arquitectónicos en
un estilo arquitectónico específico.
6. Análisis de las arquitecturas candidatas (desarrolladas
en el paso 3) utilizando el análisis de sensibilidad
del paso 5.
 CONCLUSIONES
 La arquitectura del software nos
proporciona una visión global del
sistema a construir.
 CONCLUSIONES
 Describe la estructura y la organización
de los componentes del software, sus
propiedades y las conexiones entre
ellos.
 Los componentes del software incluyen
módulos de programas y varias
representaciones de datos que son
manipulados por el programa.
 CONCLUSIONES
 Además, el diseño de datos es una parte
integral para la derivación de la
arquitectura del software.
 La arquitectura marca decisiones de
diseño
tempranas y proporciona el mecanismo
para evaluar los beneficios de las
estructuras de sistema alternativas.
 CONCLUSIONES
 El diseño de datos traduce los objetos de
datos definidos en el modelo de análisis, en
estructuras de datos que residen dentro del
software.
 Los atributos que describe el objeto, las
relaciones entre los objetos de datos y su uso
dentro del programa influyen en la elección de
la estructura de datos. A mayor nivel de
abstracción, el diseño de datos conducirá a lo
que se define como una arquitectura para una
base de datos o un almacén de datos.
 CONCLUSIONES
 El ingeniero del software cuenta con diferentes
estilos y patrones arquitectónicos.
 Cada estilo describe una categoría de sistema
que abarca un conjunto de componentes que
realizan una función requerida por el sistema, un
conjunto de conectores que posibilitan la
comunicación, la coordinación y cooperación
entre los componentes, las restricciones que
definen cómo se integran los componentes para
conformar el sistema, y los modelos semánticos
que facilitan al diseñador el entendimiento de
todas las partes del sistema.
 CONCLUSIONES
 Eldiseño arquitectónico agrupa un grupo
inicial de actividades de diseño que
conducen a un modelo completo del
diseño del software.
Gracias …

¿dudas?