Your SlideShare is downloading. ×
A02 sad
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A02 sad

208

Published on

Documento de Diseño

Documento de Diseño

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
208
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Architecture Description Daniel Perovich Auxiliar 3 dperovic@dcc.uchile.cl 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.
  • 2. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 2 Agenda  Vista de la Arquitectura  Representación de la Arquitectura  SAD  Estructura y contenido
  • 3. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 3 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
  • 4. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 4 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”
  • 5. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 5 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
  • 6. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 6 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
  • 7. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 7 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
  • 8. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 8 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
  • 9. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 9 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
  • 10. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 10 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
  • 11. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 11 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
  • 12. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 12 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)
  • 13. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 13 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
  • 14. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 14 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
  • 15. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 15 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
  • 16. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 16 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
  • 17. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 17 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
  • 18. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 18 Estructura y Contenido Introducción (4)  Sub-secciones (cont.)  Overview  Describe que contiene el resto del documento  Explica cómo está organizado
  • 19. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 19 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
  • 20. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 20 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.
  • 21. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 21 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
  • 22. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 22 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
  • 23. Arquitectura de Software | Software Architecture Description Otoño 2007 | DCC - UdeChile | 23 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

×