Detector - Informática y Sistemas de Computación

Download Report

Transcript Detector - Informática y Sistemas de Computación

Ingeniería en Sistemas Computacionales
Especialidad en Ingeniería de Software
Arquitectura de Software
Unidad 4
Diseño Arquitectónico
Basado en la Funcionalidad
• El diseño arquitectónico es un proceso de
conversión de requerimientos en una
arquitectura de software que cumple con los
requisitos funcionales.
RF
Diseño
Arquitectónico
AS
• La primera fase del proceso de diseño
basado en la funcionalidad es:
Determinar una arquitectura inicial que
capture los requerimientos funcionales
del sistema, sin ignorar los requisitos de
calidad.
Diseño Arquitectónico
Basado en la Funcionalidad
La primera fase se compone de cuatro pasos:
1. Definir el contexto del sistema
2. Identificar los arquetipos (un patrón o modelo
donde todas las cosas del mismo tipo son
representaciones o copias)
3. Descomponer la arquitectura en componentes
4. Describir instancias del sistema (verificación)
Contexto del Sistema
• Definir las interfaces del sistema con entidades externas.
• Identificar cada entidad externa a un nivel:
– Nivel superior. El sistema es usado por otros sistemas para un
comportamiento mas inteligente o completo.
– Nivel inferior. El sistema usa o depende de otros sistemas para su
funcionamiento. (interfaces de red, sensores, etc)
– Nivel igual al sistema. Sistemas en otro dominio que proporcionan
información para integración de requerimientos.
• Asociar requerimientos funcionales a cada interfaz.
• Los requerimientos de calidad tanto operacionales como de
desarrollo deben ser también asociados con interfaces.
Usado por
usa
Sistema
Depende de
usa
Contexto para Líneas de
Productos
• Para líneas de productos de software deben
identificarse y especificarse explícitamente
la variabilidad de las interfaces soportadas
por varios productos en la misma línea.
•
Ejemplo 1. Información del capitulo 3.
Sistema de Alarmas Contra
Incendio
Dominio
– Función Principal del sistema
• Monitorear un conjunto de detectores
• Cuando un detector se activa, enviar alguna salida
– Tipos de Salidas: Campanas, texto en pantallas, activar extinguidores,
avisar a bomberos, etc.
– Tipos de Detectores: medidor de temperatura, detector de humo
– Rango del sistema: Sistemas sensitivos, detectores avanzados de alta
velocidad, etc.
– Las alarmas están distribuidas físicamente en uno o más edificios
– Funcionalidad: monitoreo constante con activación de salidas
– Plataformas: microcontroladores de 8 o 16 bits
– Configuración: asignar nombres a dispositivos, localización física y
relaciones ente detectores y salidas
Sistema de Alarmas Contra
Incendio
• Estado Actual de Sistemas:
–
–
–
–
–
Sistemas con diferentes kernels en tiempo real
Diferente hardware
Diferentes lenguajes de programación
Diferentes idiomas
Funcionalidad específica para cada país
Sistema de Alarmas Contra
Incendio
• Requerimientos de Calidad
– Configurabilidad: simple de obtener instancias
– Demostrabilidad: simplificar pruebas y
facilitar la demostración de la confiabilidad
– Eficiencia: El sistema no debe ser mas lento
que un sistema actual (específico)
– Mantenibilidad: el sistema podrá incorporar
nuevos requerimientos
Sistema de Alarmas Contra
Incendio
• Configuración y mantenimiento son los
principales atributos
• Requerimientos potenciales:
– Cambios en tecnología (detectores/extinguidores)
– Compatibilidad con otros sistemas para compartir
información
– Hardware. Nuevo hardware podrá ser incorporado
– Interfaces Hombre-Máquina. Incorporar múltiples
interfaces (focos, botones, teclado, gráficas, audio, etc.)
– Instancias adaptadas al usuario. Se podrán incorporar
requerimientos específicos de un cliente.
Sistema de Alarmas Contra
Incendio
• Consideraciones:
– Son los detectores y alarmas (hardware) parte del
sistema o no?
– El sistema de comunicación es parte del sistema?
– Actividades del operador:
• Recibir alarmas
• Activar y desactivar partes del sistema
• Monitorear el comportamiento del sistema
– Interacción con otros sistemas automatizados del
edificio (desactivar control de puertas)
Diagrama de Contexto SACI
Sist. Autom.
edificio
Operador
interfaz
Asociar RF
con interfaces
interfaz
Sistema de Alarmas
Contra Incendio
interfaz
Detector
interfaz
Salida
Paso 2. Identificación de Arquetipos
• Los límites del sistema se establecen en la
primera etapa (definición del contexto)
• El objetivo de la segunda etapa es
identificar y definir los arquetipos.
• Actividad:
– Encontrar un conjunto pequeño de
entidades abstractas que al combinarlas sean
capaces de describir la mayor parte del
comportamiento del sistema.
Identificación de Arquetipos
• Entender el papel que representa el sistema en su contexto.
• Perspectiva holista del sistema (Top-Down), establecer
partes de la funcionalidad e integrarlas al sistema
completo. (proceso iterativo)
• Identificar candidatos (aparecen recurrentemente en las
instancias)
• De los candidatos, seleccionar un conjunto pequeño,
algunos podrán ser excluidos y otros compactados
• Identificar relaciones entre los arquetipos
Este es un proceso difícil que depende en gran parte
de la creatividad, intuición y experiencia del AS
Sistema de Alarmas Contra
Incendio (SACI)
• Arquetipos :Buscar las entidades abstractas
que capturan el comportamiento de diversas
entidades.
• Candidatos:
– Que requerimos para crear una instancia de un
SACI?
– Como podemos localizar alarmas y detectores?
– Como controlar a las alarmas y detectores?
Arquetipos
– Punto: Representa una abstracción dentro del dominio
del SACI. Lugar de ubicación de otras entidades.
– Detector: Captura la funcionalidad principal del equipo
de detección del sistema.
– Salida: Este arquetipo contiene funcionalidad de tipo
genérica en el sistema. (Cualquier dispositivo/proceso
de salida)
– Unidad de Control: La naturaleza del sistema es
distribuida. Una unidad de control controla a varios
puntos los cuales interactúan con detectores y salidas.
Sistema de Alarmas Contra
Incendio (SACI)
Unidad de Control
Punto
Se comunica con
Detector
Salida
Descomposición
• Los arquetipos capturan las abstracciones mas
importantes del sistema, pero no representan la
arquitectura del sistema.
• Una vez que se han identificado los componentes,
deben identificarse las relaciones (conectores)
entre estos.
• Pueden definirse varios niveles para representar
algunas partes críticas del sistema.
– Verificar que se cumplan los requerimientos
– Mantener la complejidad manejable
Paso 3. Identificar y Especificar
Componentes
• Interfaces del sistema. Cada interfaz debe estar
•
conectada a un componente.
Dominio. Asociar los dominios cubiertos por el
sistema con componentes.
– Dominio de la aplicación. Asociado al problema
– Dominio de Computación. Protocolos de
comunicación, procesos, etc.
• Capas de abstracción. Definir una serie de
capas que implementan la funcionalidad y simplifican
la especificación
Paso 3. Identificar y Especificar
Componentes
• Entidades de dominio. Identificar
componentes con entidades del dominio del
problema. Los expertos conocen el dominio
de la aplicación.
• Instancias de los arquetipos. Los
arquetipos identifican patrones que
aparecen constantemente en el sistema y
pueden representar componentes.
Componentes
• Dimensiones de descomposición
– Funcionalidad vs. Basado en entidades
– Dominio del Problema vs. Dominio de Solución
Dominio del Problema
Compiladores
Funcionalidad
(LP Pascal, C)
Sistemas de
información
(3 capas)
Teoría de
control
Entidad
(LP Java, C++)
GUIs
Dominio de Solución
Componentes y Relaciones
Una vez que se han identificado los componentes,
deben identificarse las relaciones entre estos.
• Componentes por capas de abstracción, las
relaciones se dan entre capas.
• Arquetipos, las relaciones entre componentes se
definen con las relaciones entre las instancias de los
arquetipos.
• Se pueden usar escenarios de uso para identificar las
relaciones entre componentes, i.e. Que componentes
se comunican con otros.
• Maximizar Cohesión – Minimizar Acoplamiento
Componentes de un Sistema de
Alarmas Contra Incendio
Entidad de dominio en SACI
Sección
Controlador y monitor
de puntos físicos
Puntos físicos
Instancia del arquetipo Punto
Comunicación
Componente basado en
El dominio de la solución
Instancias del Sistema
• Antes de evaluar la arquitectura diseñada,
deben crearse algunas instancias para
verificar que la arquitectura realmente
corresponde al sistema cumpliendo con los
requerimientos establecidos.
• Los componentes de la arquitectura del sistema
son recursivamente descompuestos en
componentes de nivel mas bajo.
• Cada componente contiene:
– instancias de arquetipos que proveen la funcionalidad
del sistema o
– se representa por un arquetipo individual
• Se verifican las relaciones genéricas entre las
instancias de los arquetipos y se evalúa la
compatibilidad entre las abstracciones que
componen al sistema.
• Se verifica que exista suficiente variabilidad
definiendo múltiples instancias que representen
varios productos.
Ver figura 18 de pag. 71
Detector de
Humo
Detector de
Humo
Detector de
Humo
Unidad de
Control
Detector de
Humo
Detector de
Humo
Alarma
Interfaz de
Usuario
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