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