Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 2K vistas

    Diseño Arquitectónico Del Software

    Cargado por

    Rino Tovar Abreu

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Descargue como PPT, PDF, TXT o lea en línea desde Scribd

    Diseño Arquitectónico Del Software

    Cargado por

    Rino Tovar Abreu
    2K vistas17 páginas

    Título original

    Diseño Arquitectónico del Software

    Derechos de autor

    © Attribution Non-Commercial (BY-NC)

    Formatos disponibles

    PPT, PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Descargue como PPT, PDF, TXT o lea en línea desde Scribd
    Descargar como ppt, pdf o txt
    2K vistas17 páginas

    Diseño Arquitectónico Del Software

    Cargado por

    Rino Tovar Abreu

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Descargue como PPT, PDF, TXT o lea en línea desde Scribd
    Descargar como ppt, pdf o txt
    de 17

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

    También podría gustarte