A02 sad

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.

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

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

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”

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

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

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

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

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

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

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

Introducción (3)
 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

Introducción (4)
 Overview
 Describe que contiene el resto del
documento
 Explica cómo está organizado

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

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.

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

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

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

A02 sad

Más contenido relacionado

La actualidad más candente

Destacado

Similar a A02 sad

A02 sad