DISEÑO ARQUITECTÓNICO

DEL SOFTWARE
Por: José Perezalonso
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.

1) Reducir los riesgos asociados a la construcción del software.

No se especifican las propiedades internas (por ejemplo, detalles de un

algoritmo)
 Modelado, estructura y almacén de datos

• Se utilizan diagramas de entidad-relación para traducir esos

elementos en estructuras y datos a nivel de los componentes del
software.

• Se quiere llegar a que toda esa información no esté inundada de

datos que no sean relevantes.

• Lograr extraer información útil de su entorno de datos, cuando la

información deseada está funcionalmente interrelacionada.

• Guardar estos datos en un almacén de datos para poder usarlos

en momentos de perderse los datos que se están usando día a
día.
 Diseño de datos a nivel de componentes

• Representa estructuras de datos a las que se accede

directamente a través de uno o más componentes del software.

• Empieza durante la creación del modelo de análisis.

• Cuales componentes son los que van a interactuar, como se

relacionan entre si y que posiciones van a tomar en la estructura
del mismo.

• La representación de las estructuras de datos deberían

conocerla sólo aquellos módulos que deban hacer uso directo de
los datos.
 Clasificación de estilos y patrones
•Arquitecturas centradas de datos.
 Clasificación de estilos y patrones
•Arquitecturas de flujo de datos.
 Clasificación de estilos y patrones
•Arquitecturas de llamada y retorno.
 Clasificación de estilos y patrones
•Arquitecturas orientada a objetos (encapsulación de datos).
 Organización y refinamiento
Control:
¿Cómo se gestiona el control dentro de la arquitectura?
¿Existe una jerarquía de control diferente?
¿Cómo transfieren los componentes dentro del sistema?
¿Está el control sincronizado?
¿Cómo se evalúa un estilo arquitectónico que se ha derivado?
Datos:
¿Cómo se comunican los datos entre componentes?
¿El flujo de datos es continuo o pasan de un componente a otro?
¿Cómo interactúan las funciones con los componentes de datos?
¿Los componentes de datos son activos o pasivos?
¿Cómo interactúan los datos y el control dentro del sistema?
 Método de análisis para la arquitectura
•Recopilación de escenarios.

•Levantamiento de requisitos.

•Describir patrones de estilos.

•Vista de módulos.

•Vista de flujo de datos.

•Evaluar cada atributo de forma aislada.

•Identificar los puntos sensibles a través de cambios y ver los afectados.

•Analizar las arquitecturas que se cambiarán determinando las más sensibles.

 Complejidad arquitectónica (evaluación)
•Dependencia de compartimiento de datos.

•Dependencia de flujo de datos.

•Dependencia restrictiva. (no se pueden ejecutar al mismo tiempo)

Flujo de transformación de los datos
Flujo de transacción de los datos
Conversión del flujo transformación a una arquitectura
Conversión del flujo transacción a una arquitectura
 Después de haber desarrollado la estructura:

•Desarrollar una descripción de los procesos de cada módulo.

•Describir la interfaz para cada módulo.
•Definir las estructuras de datos generales y locales.
•Apuntar todas las limitaciones/restricciones del diseño.
•Llevar a cabo una revisión del diseño.
•Considerar un refinamiento (si es necesario y está justificado).