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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (16)

Ähnlich wie A02 sad

Ähnlich wie A02 sad (20)

A02 sad