Transcript requisitos funcionales

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
Requerimientos
Arquitectura de
Software
Diagrama de
Contexto
Requerimientos
Funcionales
Arquetipos
Prioridad
Relación
Estructura
Componentes
Requerimientos de
Calidad
Relación
Expediente
de escenarios
Decisión de
Diseño
Resultados de
Evaluación
Interfase
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.
Basado en
Funcionalidad
Arquitectura de la
Aplicación
Transformación
de Arquitectura
No
ok
Estimación de
Atributos de Calidad
ok
QA. SolucionesOptimizaciones
Especificación de
Requerimientos
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.
2.
3.
4.
5.
6.
7.
8.
Extensiones:
Este caso de uso inicia cuando el Condómino acude a la oficina del
Administrador a pagar su cuota.
El Administrador introduce el código del condómino en el sistema.
El sistema despliega los datos del condómino y el importe de la
cuota a pagar.
El administrador informa al Condómino y este ultimo paga.
El Administrador captura en el sistema el importe del pago del
condómino.
El Sistema actualiza el saldo del condominio e imprime recibo de
pago.
Administrador entrega recibo al Condómino.
Fin de Caso de uso.
*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
(Aspecto Independiente
Implementación)
Design Mechanism
(Algunos detalles de
Implementación)
Implementation Mechanism
(depende de la
Implementación)
Persistence
RDBMS
Oracle
Ingres
Communication
OODBMS
ObjectStore
Object request broker
Orbix
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.
2.
3.
4.
5.
Mantener una lista completa de requerimientos
arquitectónicos.
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.
Asiste a los stakeholder para que vea el impacto
potencial de responder las preguntas de una forma u de
otra.
Captura las respuestas de tus Stakeholders a cada una de
las preguntas.
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
Licensing
(Cuestionario completo)
Will the system, or parts of the
system, be licensed?
Are there any constraints on the
mechanism used to provide
licensing capability?
Impact
support
Priority
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.
The higher the
Availability Are there any requirements
regarding system "up time"?
availability, the longer
This may be specified in terms
the time to market.
of Mean Time Between Failures
(MTBF).
Platform
Answers
What platforms must the system Development for a single
support?
platform shortens the
time to market. It also
allows closer integration
with platform features.
Development for multiple
platforms lengthens the
time to market. Close
integration with platform
features is lessened,
increasing the
maintenance of the
system.
Availability is a key product
feature. The product must have
an MTBF of 60 days.
High
The product will be released on
the following UNIX platforms:
High
Sun Solaris
IBM AIX
HPUX