• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

A02 sad

on

  • 296 views

Documento de Diseño

Documento de Diseño

Statistics

Views

Total Views
296
Views on SlideShare
296
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    A02 sad A02 sad Presentation Transcript

    • Software Architecture Description Daniel Perovich Auxiliar 3 [email_address] 03/04 Fuente: Contenido basado en el curso Arquitectura de Software, Daniel Perovich y Andrés Vignaga, Centro de Postgrado y Actualización Profesional, Instituto de Computación, Facultad de Ingeniería, Universidad de la República, Uruguay, 2005.
    • Agenda
      • Vista de la Arquitectura
      • Representación de la Arquitectura
      • SAD
      • Estructura y contenido
    • Vista de la Arquitectura
      • La vista de la arquitectura comprende diferentes intereses (que determinan su contenido!)
      • Al igual que el modelo del sistema
        • Se organiza en vistas más específicas
        • Cada vista ataca cada uno de esos intereses
      • Creación de la vista
        • Se utilizan varios de los modelos del sistema
        • No todos los modelos contienen elementos de interés
      • Correspondencia intuitiva de vistas hacia modelos
    • Vista de la Arquitectura Modelo 4+1
      • Propuesto por Kruchten – Rational, 1995
      • Tiene como objetivo organizar la vista de la arquitectura
      • Propone cuatro vistas diferentes para organizar los diferentes elementos
      • Éstas se ilustran mediante un subconjunto de casos de uso o escenarios clave
        • Éstos se convierten en la “quinta vista”
    • Vista de la Arquitectura Modelo 4+1 Logical View Implementation View Process View Deployment View Use-Case View vocabulario funcionalidad comportamiento performance escalabilidad ensamblado del sistema gestión de configuración topología distribución instalación
    • Vista de la Arquitectura Use-Case View
      • Presenta un subconjunto del Use-Case Model
      • Describe los escenarios o casos de uso que representan una funcionalidad central o que abarca gran parte de la arquitectura
      • Inicialmente estos casos de uso son utilizados para descubrir y diseñar la arquitectura
      • Después serán usadas para validar otras vistas
      • Estos pocos escenarios ilustran en la arquitectura de software como trabajan las otras vistas
    • Vista de la Arquitectura Logical View
      • Ataca los requerimientos del sistema desde un punto de vista lógico
      • Identifica los packages, subsistemas y clases de mayor relevancia del diseño
      • Describe la estructura lógica
        • En un nivel alto de abstracción: del sistema completo
        • En un nivel bajo de abstracción: de la realización de los casos de uso en la Use-Case View
    • Vista de la Arquitectura Process View
      • Se enfoca en las construcciones básicas de concurrencia (thread, process) y sus interacciones
      • Abarca los elementos incluidos en la Logical View
      • Permite comprender el tratamiento general dado a aspectos tales como
        • Concurrencia y paralelismo
        • Inicialización y terminación
        • Tolerancia a fallas
        • Distribución de objetos
      • Representa un mecanismo para razonar acerca de deadlocks, tiempos de respuesta, aislamiento de funcionalidades, y fallas
    • Vista de la Arquitectura Implementation View
      • Tiene como propósito capturar las decisiones arquitectónicas de implementación
      • Describe la organización estática de los componentes de deployment implementados a partir de los elementos de diseño en la Logical View
      • Esta organización es realizada en términos de subsistemas de implementación, y en términos del manejo de configuraciones
      • Los componentes implementan los Processes y Threads del Process View
    • Vista de la Arquitectura Deployment View
      • Es el mecanismo para comprender la distribución física (topología) del conjunto de nodos del sistema
      • También ilustra la distribución de procesamiento a lo largo de dichos nodos, en correspondencia con los elementos del Process View
      • Muestra además la ubicación física de las instancias de componentes del Implementation View en la infraestructura concreta de producción
      • Comúnmente abarca la infraestructura informática completa de la organización
    • Representación
      • La arquitectura se representa mediante el Software Architecture Document (SAD)
      • Es un artefacto que provee una vista global de la arquitectura de un sistema
      • Sirve como medio de comunicación entre el arquitecto y el resto del equipo de desarrollo
      • Utiliza diferentes vistas para ilustrar diferentes aspectos de la arquitectura
      • Estas vistas están basadas en el modelo 4+1
    • Software Architecture Document
      • La estructura y contenido del SAD debe adaptarse a la naturaleza del proyecto en el cual se usa
      • Cada sistema tiene una vista que mejor lo describe por lo que dicha vista será la más completa
      • Algunas vistas pueden ser irrelevantes
        • La Deployment View no es necesaria en sistemas para un solo procesador
        • La Process View no es necesaria en sistemas con un único hilo de control (sin clases activas)
    • SAD (2)
      • Algunas vistas particulares pueden ser necesarias
        • La Data View puede ser necesaria en sistemas en que la persistencia es un aspecto importante o cuado el mecanismo de persistencia requiere un mapeo entre datos persistentes y no persistentes
        • La Service View cuando la arquitectura está principalmente orientada a servicios
    • SAD (3)
      • Algunos aspectos del software pueden requerir su propia sección
        • Administración de los datos, usabilidad
      • Puede incluirse apéndices adicionales para explicar ciertos aspectos
        • Decisiones críticas tomadas
        • Soluciones descartadas
        • Principios generales de diseño
      • El orden de las secciones puede variar
    • Estructura y Contenido Introducción
      • Contextualiza al sistema
      • Provee un overview del documento completo
      • Sub-secciones
        • Propósito
          • Describe el propósito en el contexto del conjunto de la documentación del proyecto
          • Describe brevemente la estructura
          • Debe identificar la audiencia esperada e indicar como se espera que éstos lo utilicen
    • Estructura y Contenido Introducción (2)
      • Sub-secciones (cont.)
        • Alcance
          • Una breve descripción sobre qué aplica este documento, qué esta influenciado o afectado por este documento
        • Definiciones, acrónimos y abreviaciones
          • Provee la definición de todos los términos, acrónimos y abreviaciones requeridos para interpretar correctamente el documento
          • Puede incluir simplemente una referencia al glosario del proyecto
    • Estructura y Contenido Introducción (3)
      • Sub-secciones (cont.)
        • Referencias
          • Provee una lista completa de todos los documentos referenciados
          • Cada documento debe estar identificado por su título, fecha y la organización que lo publica
          • Especifica las fuentes de donde pueden obtenerse las referencias
          • Esta información puede proveerse haciendo referencia a un apéndice o a otro documento
    • Estructura y Contenido Introducción (4)
      • Sub-secciones (cont.)
        • Overview
          • Describe que contiene el resto del documento
          • Explica cómo está organizado
    • Estructura y Contenido Representación de la Arquitectura
      • Describe como está representada la arquitectura del sistema
      • Enumera qué vistas son necesarias para representarla
      • Para cada vista, indica qué tipos de Model Elements se incluyen en su contenido
    • Estructura y Contenido Objetivos y Restricciones
      • Describe los objetivos y los requerimientos del software que tienen impacto significativo en la arquitectura
        • Seguridad, privacidad, productos off-the-shelf, portabilidad, distribución, reuso
      • Captura restricciones especiales
        • Estrategias de diseño e implementación, herramientas, estructura del equipo, código legado, tiempos, etc.
    • Estructura y Contenido Use-Case View
      • Describe los escenarios o casos de uso que representan una funcionalidad central o que abarca gran parte de la arquitectura
      • Utiliza la misma organización en Use-Case-packages que el Use-Case Model
      • Los casos de uso aquí incluidos serán utilizados para ilustrar el resto de las vistas
    • Estructura y Contenido Use-Case View (2)
      • Para cada caso de uso incluye
        • Nombre, descripción y actores
        • Flujo de eventos del caso de uso
          • Puede ser todos los escenarios, algunos, o incluso partes de algunos escenarios
        • Descripción de requerimientos especiales
          • Por ej. requerimientos no-funcionales asociados al caso de uso
    • Estructura y Contenido Use-Case View (3)
      • Para cada caso de uso incluye (cont.)
        • Descripción de las relaciones del caso de uso con otros casos de uso
        • Imágenes de la interfaz de usuario que ayuden a clarificar el caso de uso
        • La realizaciones de los caso de uso
      • Las relaciones entre casos de uso, entre éstos y los actores y la organización en packages puede mostrarse con un diagrama