Capitulo 2

Diseño de Arquitectura de
Software
 Diseño de AS
• “la actividad más compleja durante el desarrollo
de una aplicación es la transformación de las
especificaciones de los requerimientos en una
arquitectura para el sistema”
• Otras actividades “menos complejas”:
– El diseño y la implementación son mejor entendidos
– Existen mejores metodologías para el diseño y la
implementación que las existentes para la arquitectura.
– El diseño de la arquitectura es mas un arte que una
disciplina de ingeniería.
 Diseño de AS

Q.A.S.A.R
Quality Atribute-oriented Software
Architecture design method
 Diseño de AS
• Evolución del producto
– Clientes, mercadotecnia e ingenieros especifican
características
• Desarrollo iterativo del producto
– Descubrimiento de requerimientos en iteraciones y
desarrollo de prototipos
• Selección de requerimientos
– Inserción de requisitos en cada iteración
• Diseño, evaluación y transformación de la AS
– Diseño de la AS basado en RF, evaluación y
transformación de la AS
– Ver figura 6 del texto.
 Artefactos producidos por
QASAR
• Los artefactos producidos por QASAR se
muestran en la figura 7.
• Los artefactos caen en dos categorías:
– La especificación de requerimientos
– La arquitectura del software
 Especificación de Arquitectura de
Requerimientos Software

Diagrama de
Interfase
Requerimientos Contexto
Funcionales

Arquetipos Relación

Prioridad
Estructura

Componentes
Requerimientos de
Calidad
Relación

Expediente Decisión de
de escenarios Diseño

Resultados de
Evaluación
 Requerimientos
• La comunidad OO (UML específicamente) usa los
Casos de Uso para capturar y especificar los
requerimientos funcionales.
• Se usaran Expedientes de Uso para capturar y
especificar requerimientos de calidad (así como
requerimientos funcionales).
• Los Expedientes de Uso servirán para evaluar en
que grado la arquitectura cumple con los
requerimientos de calidad.
 Importancia del Diseño de AS
• El diseño OO se enfoca en la funcionalidad.
• Con el uso de estos métodos para diseñar la
arquitectura se lograra en el sistema:
– Reuso
– Flexibilidad
– Mantenibilidad
 Importancia del Diseño de AS
• El proceso típico es construir el sistema de
acuerdo a los requerimientos funcionales y
posteriormente “afinar” el sistema para
agregar los requerimientos de calidad.
• Problema:
– Muchos sistemas no pueden ser “afinados” lo
que genera costos muy elevados, en algunos
casos es necesario iniciar de nuevo el proceso.
• Estos problemas pueden no estar
presentes cuando el personal de
una compañía puede considerarse
experto en el dominio del sistema.
 Pero…
• Si los expertos NO DOCUMENTAN cuando éstos se van
la compañía se debilita pues no tiene el conocimiento.
• Cuando la compañía inicia el desarrollo de un software en
un nuevo ámbito, esencialmente se inicia de nuevo el
proceso.
• La arquitectura no puede ser evaluada explícitamente.
• La educación se complica pues no existe conocimiento
para ser enseñado. Los estudiantes deben hacerse de este
conocimiento por experiencia propia.
 El método a usar
Diseño de Arq.
Especificación de
Basado en
Requerimientos
Funcionalidad

Arquitectura de la
Aplicación

Transformación No Estimación de
de Arquitectura ok Atributos de Calidad

ok
QA. Soluciones-
Optimizaciones
 Paso 1.
• Diseño de la arquitectura basado en la
funcionalidad.
– Desarrollar una arquitectura basándose en los
requisitos funcionales.
• Identificar las principales abstracciones (arquetipos)
• Determinar la interacción entre los arquetipos.
 Paso 2.
• Evaluar atributos de calidad.
– Evaluación basada en escenarios.
• Un conjunto para el diseño (casos de uso)
• Un conjunto para la evaluación
– Simulación y/o elaboración de prototipo
• Bueno para atributos de calidad operacionales
– Creación de modelo matemático
• Bueno para atributos de calidad operacionales
– Evaluación basada en experiencia
 Paso 3.
• Transformación de la arquitectura
– Imponer un estilo arquitectónico
• Las capas incrementan flexibilidad pero decrementan
rendimiento
– Imponer un patrón arquitectónico
• Afecta la arquitectura en general
– Distribuir los requerimientos
• Rendimiento y Confiabilidad
 Requerimientos
• Requerimientos de Software:
– Requerimientos funcionales.- Aquellos relacionados
con la funcionalidad de la aplicación.
– Requerimientos de calidad.-
• De Desarrollo.- mantenibilidad, reusabilidad, flexibilidad
• Operacionales.- rendimiento, confiabilidad, tolerancia a fallas.
– Los requerimientos funcionales pueden dirigirse a
partes especificas del software, pero los requerimientos
de calidad no son fácilmente ubicados en partes
específicas.
 Requisitos
• Usualmente los requisitos de calidad no pueden
ser medidos cuantitativamente de tal forma que no
pueden o no ser aprobados.
• Ejemplos:
– “El sistema debe tener un grado de mantenibilidad tan
bueno como sea posible.”
– “El rendimiento debe ser satisfactorio para un usuario
promedio.”
– “Las GUI deben ser fáciles de usar.”
 Tipos de requisitos
Funcionales: Características y capacidades relacionadas
con el dominio del problema, que el sistema debe
solventar. – Casos de Uso -

No Funcionales (Atributos de calidad):

Usability (Usabilidad): Factores Humanos, Ayudas, documentación.
Realiability(Confiabilidad): Frecuencia de fallo, Capacidad de recuperación,
etc.
Performance(Desempeño): Tiempo de respuesta, Exactitud, capacidad, uso de
recursos.
Supportability(Capacidad de soporte): adaptabilidad, mantenimiento,
internacionalización, Configurabilidad.

- Especificación Suplementaria --
 Requisitos No Funcionales
Los requisitos no funcionales tienen una
fuerte influencia en la arquitectura del
sistema.
 Casos de Uso: Captando requisitos
funcionales.
El principio fundamental de esta tarea es escribir
historias de uso del sistema (del futuro sistema).

Pemiten entender, descubrir y registrar los

requisitos funcionales.

UP define el Modelo de casos de uso dentro de la

disciplina de Requisitos. Es un modelo de la
funcionalidad del sistema y su ambiente.
Los clientes y usuarios finales tienen propósitos o
necesidades (goals o needs) y desean que los
sistemas computarizados les ayuden a lograrlos.

Los UC son historias de uso del sistema que le

permiten a los usuarios lograr sus propósitos (o
satisfacer sus necesidades-alcanzar sus goals).
 El sistema FURPS+ para
clasificar requisitos.

FURPS
Supportability
Performance
Reliability
Usability
Functionality.
FURPS+: Requisitos Funcionales
Estos requisitos representan las características
principales que un sistema debe cumplir.
Por ejemplo en un sistema de almacén un
requerimiento funcional puede ser:

El procesamiento de ordenes de entrada/salida.

Control de Stock.
FURPS+: Requisitos Funcionales
Sin embargo, los requisitos funcionales no
siempre son específicos del dominio, por
ejemplo:

Proveer capacidades de impresión

Es un requisito funcional, no especifico del

dominio con alto impacto arquitectónico.
 Requerimientos funcionales
arquitectónicamente significativos

Función Descripción
Auditoria Proporciona información de los cambios realizados en el sistema.
Licenciamiento Proporciona servicios para seguimiento, instalación y monitoreo del uso
de licencias de software.
Localización Soportar múltiples idiomas.
Correo Proporcionar servicios para enviar/recibir correo electronico.
Impresión Proporcionar facilidades de impresión (Gráfica, Texto, Etc.)
Reporteo Soporte para reporteo y análisis de información.
Seguridad Proteger los recursos de sistema.
 Casos de Uso y Valor Agregado
Actor: Algunas veces tiene comportamiento, como
una persona, un sistema computacional, o
organización, Ejemplo Cliente.
Esenario: Especifica una secuencia de acciones
entre el sistema y actores.
Caso de uso: Una colección relacionada de esenarios
satisfactorios y con fallas que describe los actores
usando un sistema que cumple con el objetivo.
 Plantilla de Casos de Uso 1
UC0001 Cobrar cuotas mensuales
Actor Primario: Administrador

Stakeholders e Intereses:  Administrador: Desea capturar los pago de manera ágil y sin
errores. Asimismo que los pagos actualicen el saldo de la cuenta.
 Condómino: Desea un trámite sencillo y obtener un comprobante de
pago.

Precondiciones: El Administrador es identificado y autorizado por el sistema.

Poscondiciones: El Pago de mensualidad es registrado. Comprobante de pago es impreso.

Frecuencia de uso Muy Comunmente

 Plantilla de casos de uso 2
Happy Path
Escenario Principal:
1. Este caso de uso inicia cuando el Condómino acude a la oficina del
Administrador a pagar su cuota.
2. El Administrador introduce el código del condómino en el sistema.
3. El sistema despliega los datos del condómino y el importe de la
cuota a pagar.
4. El administrador informa al Condómino y este ultimo paga.
5. El Administrador captura en el sistema el importe del pago del
condómino.
6. El Sistema actualiza el saldo del condominio e imprime recibo de
pago.
7. Administrador entrega recibo al Condómino.
8. Fin de Caso de uso.
Extensiones: *a. En cualquier momento
1a El Administrador cancela pago de cuota.
- El Administrador cancela pago de cuota en el sistema.
- Sistema confirma cancelación de pago y regresa al estado normal.
2a. Código de Condómino inválido (no se encuentra en el sistema)
- Administrador pide nombre a Condómino.
- Administrador ejecuta Buscar Condómino para obtener el código
correcto.
4a. El recibo se atascó en la impresora.
- Administrador inserta otro recibo en la impresora.
- Administrador ejecuta Reimpresión de Recibos para entregarlo a
Condómino.
 Requisitos Usabilidad, Fiabilidad, Desempeño , y
capacidad de soporte

El resto de las categorías "URPS+" describe requerimientos no

funcionales que son arquitectónicamente significativos.

Usability (Usabilidad) Se refieren a características estéticas y de

consistencia en la interface de usuario.

Ejemplo:
•Estilo de interface Gráfica: Web, Windows, Consola.
•Estetica
•Accesibildad: Capacidad de uso para personas discapacitadas.
Reliability (Fiabilidad) trata sobre características
como:

Availability (la cantidad de tiempo que el sistema

debe estar disponible “up time").

Accuracy( Presición de los cálculos que realiza el

sistema)

Recover from failure(Capacidad que tiene el

sistema a sobreponerse a los fallos.
Performance(Desempeño) relacionado a propiedades tales como:
Throughput (rendimiento)
response time (El Tiempo que transcurre desde que el usuario solicita
algo al sistema y este de respuesta),
recovery time (Tiempo de recuperación)
start-up time and shutdown time.
 Soporte

Supportability se refiere a:

Capacidad de ser probado.

Adaptabilidad.
Mantenimiento:
Capacidad de configurarse
Escalabilidad
 Requisitos de diseño, de implementación e
interface
El "+" en el acrónimo FURPS+ es usado para identificar categorías adicionales que
generalmente representan restricciones.

Requerimiento de Diseño, comúnmente llamado restricción de diseño, especifica

las opciones para diseñar el Sistema.
Ej. Si tu especificas que la persistencia se llevara a través de una BD relacional,
es una restricción de diseño.

Requerimiento de implementación: Especifica el código o la construcción de un

sistema. Ej. Puede incluir los estándares requeridos, lenguajes de implementación, y
recursos limites.

Requerimiento de interface: Especifica un elemento externo con el cual el sistema

debe interactuar , o especificar los formatos y factores necesarios para esa iteración
 Ejemplos:
El producto debe soportar varios idiomas.
La persistencia debe ser manejada por una BD
Relacional.
La BD debe ser Oracle 8i.
El sistema debe correr 7d x 24hr durante 365 días.
El sistema de ayuda en línea es indispensable.
La capa de lógica debe ser escrita completamente en
Visual Basic.
 Mecanismos Arquitectónicos
Son usados frecuentemente para realizar
requerimientos arquitectónicos.

Analysis Mechanism Design Mechanism Implementation Mechanism

(Aspecto Independiente (Algunos detalles de (depende de la
Implementación) Implementación) Implementación)
Persistence RDBMS Oracle
Ingres
OODBMS ObjectStore

Communication Object request Orbix

broker
VisiBroker
Message queue MSMQ
MQSeries
Relación entre requerimientos y
mecanismos
Lista completa de mecanismos de
análisis
Mecanismos de analisis.doc|
 Conseguir requerimientos
arquitectónicos
Conseguir requerimientos arq. Significa adentrarse en un
territorio inexplorado (En contraste con req. Orientados al
dominio), por las siguientes razones:

En la mayoría de los sistemas, desde la perspectiva de usuario final,

los requerimientos del dominio son mas visibles que su contraparte
no funcional.

Stakeholders no están usualmente familiarizados con la mayoría de

los requerimientos arquitectónicos.

Técnicas para obtener requerimientos no funcionales son menos

conocidas que técnicas para obtener requerimientos específicos al
dominio.
 Metodo para obtener requisitos
arquitectonicos.
1. Mantener una lista completa de
requerimientos arquitectónicos.
2. Por cada req. Arquitectónico, formular una o más
preguntas, que puedan ayudar en el proceso de
especificación. Asegúrate que todos los stakeholders
puedan entender las preguntas.
3. Asiste a los stakeholder para que vea el impacto potencial
de responder las preguntas de una forma u de otra.
4. Captura las respuestas de tus Stakeholders a cada una de
las preguntas.
5. Asegúrate una vez que los usuarios además de responder
las preguntas asignen una prioridad o peso a cada
requerimiento.
 Ejemplo de un cuestionario
Requireme Questions
nt
(Cuestionario completo)
Impact Answers Priority

Licensing Will the system, or parts of the
system, be licensed?
Are there any constraints on the
mechanism used to provide
licensing capability?
The greater the The stock control module will be Medium
sophistication of the marketed as a separate
licensing mechanism, the component of the system and will
longer the time to market, require licensing. The FlexLM
and the greater the long- tool is used throughout our
term maintenance cost. organization to provide licensing
capability.

Availability Are there any requirements The higher the Availability is a key product High
regarding system "up time"? availability, the longer feature. The product must have
This may be specified in terms the time to market. an MTBF of 60 days.
of Mean Time Between Failures
(MTBF).

Platform What platforms must the system Development for a single The product will be released on High
support support? platform shortens the the following UNIX platforms:
time to market. It also
allows closer integration Sun Solaris
with platform features. IBM AIX
HPUX
Development for multiple
platforms lengthens the
time to market. Close
integration with platform
features is lessened,
increasing the
maintenance of the
system.