Ingeniería del Software de Gestión. Tema 4

tema 4 – diseño del software

enrique barreiro
departamento de informática
universidade de vigo

escuela superior de ingeniería informática
ingeniería del software de gestión

introducción y objetivos del diseño

diseño de sistemas: transformación del modelo de
análisis en un modelo de diseño del sistema
se definen los objetivos de diseño del proyecto
se descompone el sistema en subsistemas más pequeños
que pueden ser realizados por diferentes equipos
Ingeniería de
se seleccionan estrategias para la construcción del
requerimientos
sistema
plataforma de hardware y software en la que se ejecutará
Modelo de casos
el sistema
de uso
estrategia de almacenamiento de datos persistentes
:Modelo
arquitectura estructural del sistema
flujo de control global
Análisis
política de control de acceso
Modelo de condiciones de interfaz
análisis
...
:Modelo
resultado del diseño: modelo de diseño
descripción clara de las estrategias
Diseño
descomposición en subsistemas
diagramas que muestran la correspondencia entre
Modelo de
hardware y software
diseño
modelo de objetos que describe la realización física de los
:Modelo
casos de uso
muestra el impacto en el sistema de requisitos funcionales,
no funcionales y restricciones
sirve de abstracción de la implementación del sistema,
convirtiéndose en el input fundamental de las actividades
de implementación

© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 125

evolución del diseño de software

proceso continuo durante tres décadas
criterios de desarrollo de programas modulares
refinamiento de arquitectura software top-down
programación estructurada
diseño estructurado
diseño orientado a objetos


calidad y diseño del software

El principio de la sabiduría de un ingeniero del software
El principio de la sabiduría de un ingeniero del software
es reconocer la diferencia entre conseguir que funcione
es reconocer la diferencia entre conseguir que funcione
un programa, y hacerlo bien.
un programa, y hacerlo bien.
M.A. Jackson, 1975
M.A. Jackson, 1975

concepto clave: CALIDAD
un diseño de calidad:
proporciona representaciones del software en las que se puede evaluar la calidad
permite una “traducción” correcta de los requisitos en un programa
sirve como fundamento para las actividades posteriores (implementación, prueba
y mantenimiento)


calidad y diseño del software

Sin diseño de calidad:
Dificultades de gestión (el “destino cósmico” de los proyectos)
Sistemas poco satisfactorios e improductivos
45% del tiempo en pruebas y corrección
Myers: se intenta resolver el problema apurando en el proceso de diseño
para dejar tiempo suficiente al final del proyecto para corregir los errores
cometidos por apurar en el proceso de diseño.
Sistemas poco fiables: pruebas poco fiables (“parece que funciona”) y
sistemas que escapan al control de sus creadores.
Sistemas ineficientes: un buen diseño garantiza que se mantendrá el
rendimiento a pesar de las modificaciones que se realicen.
Sistemas poco flexibles y difíciles de mantener:
70% del coste en mantenimiento
El mantenimiento es caro:
1) Entender cómo funciona el sistema (o por qué no funciona)
Los tres primeros casos se
Los tres primeros casos se
agravan con un mal diseño 2) Diseñar la modificación
agravan con un mal diseño
3) Verificar el impacto
4) Realizar la modificación
5) Probar el sistema modificado
6) Planificar, organizar, coordinar, medir y documentar estas
actividades


conceptos esenciales del diseño

principios básicos para el proceso de diseño (Davis, 1995)
1. Usar enfoques alternativos
2. Rastrear los requisitos en el diseño
3. Reutilizar si es posible
4. Representar la estructura del dominio del problema
5. Presentación uniforme e integrada
6. Estructurado para permitir cambios
7. Estructurado para degradarse poco a poco ante errores o
circunstancias inusuales
8. Evaluación de la calidad del diseño mientras se realiza



REFINAMIENTO
REFINAMIENTO

La arquitectura de un programa se
La arquitectura de un programa se
ABSTRACCIÓN
ABSTRACCIÓN desarrolla refinando sucesivamente
desarrolla refinando sucesivamente
niveles de detalle procedimental.
niveles de detalle procedimental.
-- Procedimental Conceptos complementarios
Procedimental Se desarrolla una jerarquía
Se desarrolla una jerarquía
-- De datos
De datos descomponiendo una abstracción
descomponiendo una abstracción
-- De control
De control procedimental para, paso a paso,
procedimental para, paso a paso,
llegar a los enunciados del
llegar a los enunciados del
lenguaje de programación
lenguaje de programación
La abstracción permite especificar
La abstracción permite especificar
procedimientos y datos suprimiendo detalles de
procedimientos y datos suprimiendo detalles de
bajo nivel.
bajo nivel.
El refinamiento ayuda a revelar detalles de bajo
El refinamiento ayuda a revelar detalles de bajo
nivel a medida que progresa el diseño.
nivel a medida que progresa el diseño.

- Requisitos familiares en el ámbito del
problema
abstracción
niveles de

- Diseño arquitectónico

- Diseño procedimental

- Código



MODULARIDAD
MODULARIDAD
-- Componentes identificables y tratables
Componentes identificables y tratables
por separado
por separado
-- Permite a un programa ser manejable
Permite a un programa ser manejable
intelectualmente
intelectualmente
-- Criterios que permiten evaluar un
Criterios que permiten evaluar un
método de diseño con respecto a su
método de diseño con respecto a su
capacidad de definir un sistema modular
capacidad de definir un sistema modular
eficaz:
eficaz:
Capacidad de descomposición
Capacidad de descomposición
modular
modular
Capacidad de empleo de
Capacidad de empleo de
Costes totales
componentes modulares
componentes modulares del software
(reutilización)
(reutilización)

Costes o esfuerzo
Coste de
Capacidad de comprensión
Capacidad de comprensión integración
modular (entender un módulo sin M
modular (entender un módulo sin
referencias a otros, o con las menos
referencias a otros, o con las menos Región de
posibles)
posibles) costes
mínimos
Continuidad modular (cambios en
Continuidad modular (cambios en Coste/módulo
módulos y con poco impacto)
módulos y con poco impacto)
Protección modular
Protección modular Fuente: Ingeniería del Software. Un enfoque práctico. R. S. Pressman

Número de módulos


ACOPLAMIENTO
INDEPENDENCIA FUNCIONAL
INDEPENDENCIA FUNCIONAL

• • Consecuencia de la aplicación de conceptos Medida de la interdependencia relativa entre componentes,
Consecuencia de la aplicación de conceptos
como la modularidad, la abstracción y la y depende de la interfaz entre éstos, es decir, de la
como la modularidad, la abstracción y la
ocultación de la información cantidad y tipo de datos que comparten.
ocultación de la información
• • Componentes con “función única” y poca
Componentes con “función única” y poca
interacción con otros Objetivo durante el diseño: minimizar el acoplamiento
interacción con otros
• Más fáciles de mantener y probar utilizando conexiones sencillas entre los módulos.
• Más fáciles de mantener y probar
• Menos efectos secundarios por
• Menos efectos secundarios por
modificaciones Formas de reducir el acoplamiento:
modificaciones
• • Reducida propagación de errores • Eliminando relaciones innecesarias
Reducida propagación de errores
• • Facilita la reutilización • Reduciendo las relaciones necesarias
Facilita la reutilización

Beneficios de un bajo acoplamiento:
• Menor transmisión de defectos (efectos secundarios)
• Posibilidad de cambiar un componente (clase, subsistema,
COHESIÓN módulo,...) sin incidir sobre otros
• En el mantenimiento de un componente no hay que tener
Medida del grado de “fuerza funcional” de un en cuenta el contenido de otros
componente: cuanto menor sea el número de tareas
(elementos de procesamiento) que realiza un
componente, mayor será su cohesión. Conceptos complementarios
Conceptos complementarios
Diferentes grados de cohesión: Maximizar la cohesión es casi
Maximizar la cohesión es casi
lo mismo que minimizar el
lo mismo que minimizar el
COMPONENTE CON DIVERSAS
acoplamiento
COMPONENTE CON
acoplamiento
TAREAS POCO O NADA
TAREA SIMPLE
RELACIONADAS


proceso del diseño

fuente: Ingeniería de Software, I. Sommerville


proceso del diseño

Diseño arquitectónico
Identificación y documentación de los subsistemas que
forman el sistema y sus relaciones
Especificación abstracta
Especificación de servicios y restricciones bajo los que
funcionará cada subsistema
Diseño de la interfaz
Diseño y documentación de la interfaz de cada subsistema
con otros subsistemas
Diseño de componentes
Asignación de servicios a los componentes y diseño de sus
interfaces
Diseño de la estructura de datos
Diseño de algoritmos


diseño arquitectónico

Los grandes sistemas
se descomponen en <<subsistema>>
Sistema de
subsistemas que visión
proporcionan <<subsistema>>
conjuntos de
servicios relacionados <<subsistema>> <<subsistema>>
Controlador del Co ntrolador del
brazo asidero
<<subsistema>>
Sistema d e i dentificaci ón
de objetos

<<subsistema>>
<<subsistema>>
<<subsistema>>
Contro lado r de cinta
<<subsistema>>
Sistema de selección
transportadora
Sistema de
de embalajes
embalaje



proceso inicial del diseño para identificar los subsistemas y
establecer un marco de trabajo para el control y comunicación
entre ellos
actividades principales
Estructuración
del sistema
estructuración del sistema en varios subsistemas principales
modelado del control entre las partes del sistema
descomposición modular: cada subsistema se descompone en
módulos interconectados
Modelado del
salida del diseño arquitectónico: documento con diversas
control
perspectivas de la arquitectura
modelo estructural estático: subsistemas o componentes a
desarrollar como unidades separadas
Des compos ición
modelo de proceso dinámico: organización del sistema en tiempo
modular
de ejecución, y que puede ser distinto al modelo estático
modelo de interfaz: definición de los servicios ofrecidos por cada
subsistema a través de su interfaz pública
modelos de relación: relaciones de, por ejemplo, el flujo de
datos entre subsistemas
modelo de distribución: cómo se distribuyen los subsistemas
entre los componentes físicos del sistema (computadores, nodos
de red,…)


diseño arquitectónico y requisitos no funcionales
la arquitectura puede estar en función de requisitos no
funcionales (rendimiento, robustez, mantenibilidad, etc)
necesarios para el sistema y que en ocasiones pueden exigir
arquitecturas contradictorias
rendimiento: si se necesita un elevado rendimiento se
utilizarán pocos subsistemas con poca comunicación
seguridad: las aplicaciones con elevado nivel de seguridad
necesitarán estructurarse en capas con los recursos críticos
protegidos en las capas más internas, que contarán con
elevados nivel de validación
disponibilidad: puede obligar a incluir componentes
redundantes que puedan reemplazarse y actualizarse sin
detener el sistema
mantenibilidad: mejora cuando se utilizan componentes más
pequeños, que pueden intercambiarse con facilidad


diseño arquitectónico: arquitectura
diseño arquitectónico > arquitectura

arquitectura o estructuración:
identificación de subsistemas o capas clave
a desarrollar de forma independiente
identificación de las relaciones entre
Estructuración
del sistema
subsistemas
efectivo para la comunicación entre los
participantes en el proyecto y el reparto de
tareas entre distintos grupos
Modelado del
control
modelos específicos de arquitectura
modelo de depósito o repositorio
modelo cliente/servidor
Des compos ición
modelo de máquina abstracta o en capas
modular


modelo de repositorio
diseño arquitectónico > arquitectura > modelo de depósito

modelo de repositorio (o depósito)
arquitectura en la que todos los datos compartidos se ubican en una
base de datos central a la que acceden todos los subsistemas
útil en sistemas que utilizan grandes cantidades de datos, generados
por un subsistema y utilizados por otro
sistemas de información corporativa
sistemas CAD y CASE
sistemas de control de procesos
...

generador
generador
editor de diseño de código
editor de diseño de código

traductor editor de
traductor editor de
Depósito de proyectos
de diseño programas
de diseño programas

arquitectura de un conjunto integrado de
herramientas CASE conjunto integrado de
arquitectura de un
herramientas CASE
analizador generador fuente: Ingeniería de Software, I. Sommerville,
analizador degenerador
de diseño informes fuente: Ingeniería de Software, I. Sommerville,
de diseño de informes


modelo de repositorio
diseño arquitectónico > arquitectura > modelo de depósito

Ventajas Inconvenientes
los subsistemas deben estar acordes al
modelo de depósito de datos, lo que lleva
a un compromiso entre las necesidades
compartición eficiente de grandes específicas de cada herramienta, lo que
cantidades de datos, sin necesidad de puede afectar a cuestiones como el
transmitir datos explícitamente de un rendimiento.
subsistema a otro.
difícil o imposible integrar subsistemas
cuyos modelos de datos no se ajusten al
esquema.
los subsistemas que producen datos no
genera un gran volumen de información y
necesitan saber cómo son utilizados por
es difícil hacer evolucionar el sistema.
otros subsistemas.
diferentes subsistemas pueden tener
centralización de actividades de
diferentes requerimientos de políticas de
administración del depósito: respaldo,
seguridad, recuperación y respaldo. El
seguridad, control de acceso y
modelo de depósito impone la misma
recuperación de errores.
política a todos los subsistemas.
las herramientas compatibles con el difícil distribuir el depósito en varias
modelo de datos se integran máquinas (problemas de inconsistencia y
directamente redundancia de los datos)


diseño arquitectónico > arquitectura > modelo cliente / servidor

modelo de sistemas distribuido que muestra cómo datos
y procesamiento se distribuyen a lo largo de varios
procesadores
componentes
conjunto de servidores independientes que ofrecen
servicios a otros subsistemas
servidores de impresión
servidores de administración de archivos
servidores de bases de datos
...
conjunto de clientes
invocan los servicios ofrecidos por los servidores mediante un
protocolo de petición-respuesta (por ejemplo, http en la WWW)
existen varias instancias de un programa cliente que se ejecuta
de forma concurrente
tienen que conocer los nombres de los servidores disponibles y
los servicios que suministran, pero los servidores no conocen a
los clientes
una red que permite a los clientes acceder a los servicios
no existe una relación 1:1 entre procesos y
procesadores: un computador servidor puede ejecutar
varios procesos servidores (confusión entre servidor-
proceso y servidor-computador)



Servidor de
catálogosde
Servidor
catálogos
Cliente 1
Catálogo Cliente 1
Catálogo

Servidor de vídeos
Servidor de vídeos

Cliente 2
Cliente 2
Archivos de vídeos
Archivos de vídeos

INTERNET
Servidor de
imágenesde
Servidor
imágenes
Cliente 3
Cliente 3
Fotografías
Fotografías
digitalizadas
digitalizadas

Servidor web
Servidor web
Cliente 4
Cliente 4
Páginas web
Páginas web

Cliente 1
Cliente 1



distintas arquitecturas cliente/servidor
tres capas lógicas
capa de presentación: se encarga de mostrar
la información e interactuar con el usuario.
capa de procesamiento de la aplicación:
implementa la lógica de la aplicación
Capa de
presentación
capa de administración de datos: se refiere a
todas las operaciones de la base de datos
modelo en dos capas físicas:
la arquitectura más simple. La aplicación se
Capa de organiza como un servidor (o varios
procesamiento de idénticos) y un conjunto de clientes
la aplicación
modelo de “cliente delgado”
todo el procesamiento de la aplicación y la
administración de datos se realiza en el servidor
el cliente únicamente ejecuta el software
Capa de
administración de
modelo de “cliente grueso”
datos
el servidor sólo es responsable de la
administración de datos
el software del cliente implementa toda o gran
parte de la lógica de la aplicación y las
interacciones del usuario con el sistema


diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente delgado

modelo de cliente delgado
utilizado cuando los sistemas heredados centralizados (p.ejemplo,
sistemas basados en mainframes – grandes servidores corporativos)
evolucionan a una arquitectura cliente/servidor
la interfaz migra a los PCs, estaciones de trabajo o a dispositivos de red
sencillos
sistemas basados en tecnologías web: los dispositivos de red ejecutan un
navegador, que implementa la interfaz de usuario
la aplicación misma actúa como servidor y maneja todo el procesamiento
de la aplicación y administración de datos
desventajas
implica una gran carga de procesamiento en el servidor
el servidor realiza todos los cálculos, lo que provoca tráfico en la red
entre cliente y servidor
desaprovecha la capacidad de cálculo de equipos como los PCs

Servidor
Servidor
Presentación
Cliente
Cliente Administrador de datos
Administrador de datos
Procesamiento de la
Procesamiento de la
aplicación
aplicación


diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente grueso

modelo de cliente grueso
distribuye al cliente procesamiento
lógico de la aplicación y la presentación
Cliente
Cliente Servidor aprovecha la capacidad de
Servidor
Procesamiento de las
Procesamiento de las
procesamiento disponible en los
aplicaciones y presentación
aplicaciones y presentación Administrador de datos
Administrador de datos
clientes
ejemplo: sistemas bancarios ATM
(cajeros automáticos)
los ATM no se conectan directamente a
la base de datos del cliente sino al
gestor de transacciones
gestor de transacciones: sistema
middleware que
organiza las comunicaciones con
los clientes remotos
Servidor
coloca en serie las transacciones
de cuentas
de los clientes para ser
ATM
procesadas por la base de datos,
ATM
lo que permite al sistema
Monitor de Base de recuperarse de fallos sin
teleprocesa- datos de corromper los datos
miento cuentas
inconvenientes
administración del sistema más
compleja al distribuirse la
ATM
ATM
funcionalidad de la aplicación en
diferentes computadores
mantenimiento: reinstalación en cada
computador cliente si cambia la
aplicación
ATM
ATM



problemas del enfoque de dos capas físicas
las tres capas lógicas (presentación,
Servidor
de cuentas procesamiento y administración de datos) deben
asociarse a dos sistemas de cómputo
problemas de escalabilidad y rendimiento en el
Base de
modelo de cliente delgado
SQL datos de
cuentas problemas de administración del sistema en el
modelo de cliente grueso
alternativa: utilizar tres capas físicas
Consultas SQL
las tres capas lógicas son procesos separados
lógicamente
no implica la existencia de tres sistemas de
Servidor Servidor
cómputo conectados a la red pero si es necesario
web web
se pueden separar fácilmente y ejecutar en
procesadores separados
son más escalables que las arquitecturas de dos
Provisión del servicio Provisión del servicio
niveles
de la cuenta de la cuenta

ejemplo: sistema bancario en Internet:
administración de datos: suministrado por la base
de datos del banco (normalmente en un
Interacción HTTP
mainframe)
servicios de aplicación (transferencias, consulta de
movimientos, pago de facturas,...) suministrados
por un servidor Web
presentación: el cliente es el computador del
usuario con un navegador web
sistema escalable: se pueden añadir fácilmente
servidores web cuando aumenta el número de
clientes
Clientes web
Clientes web



Código móvil: applets de Java y
controles ActiveX
permiten implementar un modelo
cliente/servidor a medio camino entre los
Servidor
de cliente delgado y grueso
web

funcionamiento
parte del software de procesamiento se
Administración datos
descarga en el cliente como applet,
Procesamiento
aplicación
aligerando la carga del servidor
la interfaz de usuario se construye
utilizando un navegador Web que ejecuta
los applets o los controles ActiveX
Interacción HTTP

problemas
diferencias en las implementaciones de
Java en navegadores de distintos
Cliente fabricantes
web
necesidad de una velocidad de
transmisión aceptable para descargar los
applets
Presentación
problemas de seguridad
Ejecución applets
libertad de configuración por el usuario



Arquitectura Aplicaciones
Aplicaciones de sistemas heredados donde no es práctico
separar el procesamiento de las aplicaciones y la
administración de datos.
C/S de dos capas con
Aplicaciones computacionalmente intensivas como los
clientes delgados
compiladores con poca o ninguna administración de datos.
Aplicaciones intensivas en datos (navegar y consultar) con
poco o ningún procesamiento de la aplicación.
Aplicaciones con procesamiento de datos computacionalmente
intensivo (por ejemplo, visualización de datos, animaciones
gráficas,...)
C/S de dos capas con
clientes gruesos Aplicaciones con funcionalidad para el usuario final
relativamente estable utilizadas en un entorno con
administración de sistemas bien establecido.
Aplicaciones de gran escala con cientos o miles de clientes.
C/S de tres capas o Aplicaciones donde tanto los datos como la aplicación son
múltiples capas volátiles.
Aplicaciones donde se integran datos de diversas fuentes.


modelo en capas
diseño arquitectónico > arquitectura > modelo en estratos

modelo en capas o de máquina
abstracta
modela la interacción entre los
subsistemas organizando un sistema en
Usuarios
una serie de capas
cada capa presta servicios a la capa
Gestión de configuraciones del sistema
inmediatamente superior y actúa como
cliente de la que queda encerrada
Gestión de objetos del sistema
el diseño incluye los protocolos que
establecen cómo interactuará cada par
Base de datos del sistema
de capas
arquitectura cambiable y portable:
Sistema
preservando la interfaz, una capa se
operativo
puede reemplazar por otra
cuando cambian las interfaces de las
capas sólo afecta a la capa adyacente
desventajas
difícil estructurar los sistemas pues es
posible que el usuario requiera acceso a
capas internas (p.ej., bases de datos) lo
que subvierte el modelo
Modelo de capas de un sistema de gestión de versiones.
Fuente: Ingeniería del Software, I. Sommerville
el rendimiento puede resultar afectado
por los múltiples niveles de
interpretación de órdenes que se
requieren a veces


modelo en capas: ejemplos
diseño arquitectónico > arquitectura > modelo en estratos

Arquitectura de red OSI
Aplicación Aplicación

Transferencia de información de
Presentación Presentación
las aplicaciones
Sesión Sesión
Transferencia de datos
Transporte Transporte

Red Red Red

Enlace de datos Enlace de datos Enlace de datos Interconexión física

Física Física Física

MEDIOS DE COMUNICACIÓN

Arquitectura de red TCP/IP

Aplicación TELNET FTP SMTP DNS

Transporte TCP UDP

Interred IP

Host a red ARPANET INTERNET SATNET LAN


diseño arquitectónico: modelado del control
diseño arquitectónico > modelado del control

modelos de control
representan la forma en que los
subsistemas se controlan para que sus
servicios se entreguen en el lugar correcto y
en el momento justo
Estructuración
del sistema
el arquitecto organiza los subsistemas
acorde a un modelo de control
dos modelos de control genéricos:
control centralizado: un subsistema es el
Modelado del
responsable de controlar, iniciar y detener
control
otros subsistemas. También puede pasar el
control a otros subsistemas, pero espera
que se le devuelva esa responsabilidad de
control.
Des compos ición
control basado en eventos: cada subsistema
modular
puede responder a eventos generados en el
exterior, provenientes de otros subsistemas
o del entorno del sistema
complementan los modelos estructurales, y
todos éstos se pueden llevar a cabo
utilizando un control centralizado u
orientado a eventos


control centralizado
diseño arquitectónico > modelado del control > control centralizado

sistemas de control centralizado
un subsistema tiene la responsabilidad de controlar
el sistema y administrar la ejecución de otros
programa
programa
subsistemas
principal
principal
dos clases, según se ejecuten secuencialmente o en
paralelo
rutina 1 rutina 2 rutina 3
modelo de llamada-retorno (ejecución secuencial):
rutina 1 rutina 2 rutina 3
el control se inicia en la parte superior de una jerarquía y
por medio de llamadas a subrutinas pasa a los niveles del
árbol
rutina 1.1 rutina 1.2 rutina 3.1 rutina 3.2 no es un modelo estructural, por lo que no es necesario,
rutina 1.1 rutina 1.2 rutina 3.1 rutina 3.2
por ejemplo, que la Rutina 1.1. forme parte de la Rutina 1
sólo se aplica a sistemas secuenciales
utilizado por lenguajes de programación como Ada, Pascal
y C, aunque también en lenguajes OO.
ventaja: es relativamente sencillo analizar los flujos de
control y conocer cómo responderá el sistema a cierto tipo
procesos procesos de entradas
del sensor del actuador
inconveniente: las excepciones a operaciones normales
son complicadas de gestionar
modelo del administrador:
se aplica a los modelos concurrentes
controlador
controlador un componente del sistema se designa como
sistema
sistema administrador y controla el inicio, detención y coordinación
del sistema según las variables de estado del sistema.
Verifica si otros procesos han producido información para
procesar o si ha que pasarles información para el
procesos interfaz de controlador procesamiento.
interfaz de controlador
de cálculo usuario de fallos un proceso es un subsistema o módulo que se ejecuta en
usuario de fallos
paralelo con otros procesos
utilizado en sistemas de tiempo real “suaves” (con
restricciones de tiempo no muy estrictas)


control centralizado: ejemplo
diseño arquitectónico > modelado del control > control centralizado

Ejemplo del modelo del administrador centralizado
400 Hz 100 Hz
60 Hz

Proceso detector
Proceso detector Proceso sensor de Proceso sensor de
de movimiento Proceso sensor de Proceso sensor de
de movimiento puertas ventanas
puertas ventanas
class BuildingMOnitor extends Thread {
class BuildingMOnitor extends Thread {
Estado del detector
BuildingSensor win, door, move ;
Estado del sensor BuildingSensor win, door, move ;
560 Hz Estado del sensor
Siren siren = new Siren () ;
Lights lights = new Lights () ;;
Siren siren = new Siren ()
Lights lights = new Lights () ;
DoorSensors doors = new DoorSensors (30) ;
DoorSensors doors = new DoorSensors (30) ;
Proceso de
Proceso de
monitorización ( ... )
monitorización ( ... )
edificio
edificio
BuldingMonitor()
{ BuldingMonitor()
{
Número de habitación //inicializar sensores e iniciar procesos
( ... ) //inicializar sensores e iniciar procesos
} ( ... )
}
public void run ()
{ public void run ()
Proceso del {
Proceso del int room = 0 ;
sistema de alarma
while (true) 0 ;
int room =
sistema de alarma
{ while (true)
{
//sondear movimiento sensores (400Hz)
move = movements.getVal () ; (400Hz)
//sondear movimiento sensores
move = movements.getVal () ;
fuente: Ingeniería de Software, I. Sommerville ( ... )
( ... )
}
}


control dirigido por eventos
diseño arquitectónico > modelado del control > control dirigido por eventos

sistemas de control dirigido por eventos
se rigen por eventos generados en el exterior (señal de un
sensor, comando desde un menú,…)
diferentes tipos de sistemas dirigidos por eventos
hojas de cálculo (el valor cambiante de las celdas provoca que
otras se modifiquen)
sistemas de producción basados en reglas (por ejemplo, de
Inteligencia Artificial) en los que una condición que se
convierte en verdadera provoca que se dispare una acción
objetos activos, en los que el cambio de valor de un atributo
del objeto dispara algunas acciones
dos tipos de modelos principales
modelos de transmisión (broadcast): los subsistemas registran
un interés en eventos específicos y cuando ocurren el control
se transfiere al subsistema que puede manejar el evento
modelos dirigidos por interrupciones: especialmente útiles para
sistemas de tiempo real que necesitan manejar rápidamente
eventos generados en el exterior


control por eventos: modelos de transmisión
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión

modelos de transmisión
se diferencia del modelo del administrador en
que la política de control no está contenida en
el controlador de eventos y mensajes, sino
que los subsistemas deciden qué eventos
requieren y el controlador asegura que estos
eventos sean enviados a dichos subsistemas
efectivos para integrar subsistemas
distribuidos a lo largo de diferentes
computadores de una red
utilizados por los agentes de solicitud de
objetos (ORBs) para las comunicaciones de
objetos distribuidos
subsistema subsistema subsistema
ventajas:
subsistema subsistema subsistema
1 2 3
1 2 3 la evolución es relativamente sencilla pues se
pueden integrar nuevos subsistemas
registrando sus eventos en el controlador de
eventos
cualquier subsistema puede activar otros
subsistemas sin conocer su nombre o
Controlador de eventos y mensajes
ubicación
los subsistemas se pueden incrementar en
máquinas distribuidas, de forma transparente
para otros subsistemas
desventaja:
subsistema subsistema
subsistema subsistema los subsistemas no saben si los eventos se
4 5
4 5 manejarán ni cuando lo harán
cuando un subsistema genera un evento no
sabe qué otros subsistemas han registrado un
interés en ese evento


modelos de transmisión: objetos distribuidos
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos

modelos de transmisión: arquitecturas de objetos
distribuidos
consiste en eliminar la distinción entre cliente y servidor y
diseñar la arquitectura del sistema como una arquitectura de
objetos distribuidos
los componentes fundamentales son
objetos que proveen una interfaz a un conjunto de servicios que
suministran
otros objetos llaman a estos servicios sin ninguna distinción lógica
entre un cliente (receptor de un servicio) y un servidor (proveedor de
un servicio)
funcionamiento
o3
o1 o2
los objetos se distribuyen a lo largo de varios computadores sobre
una red
se comunican a través de middleware (una especie de “bus de
s(o3)
s(o1) s(o2) software” que provee un conjunto de servicios que permiten
comunicación, agregación y destrucción de objetos del sistema
middleware: agente de solicitud de objetos (ORB, Object Request
Broker) y provee una interfaz transparente entre objetos
ventajas
permite retrasar las decisiones sobre dónde y cómo se deben
ORB
suministrar los servicios pues los objetos proveedores de servicios se
pueden ejecutar en cualquier nodo de la red
arquitectura abierta: permite agregar nuevos recursos si es necesario
pues los estándares del ORB (p.ej., CORBA) se han desarrollado para
permitir la comunicación y servicios entre objetos escritos en
diferentes lenguajes
o5
o4
sistema flexible y escalable: se pueden crear diferentes instancias del
sistema con el mismo servicio suministrado por objetos diferentes o
por réplicas de objetos para hacer frente a diversas cargas del
sistema
s(o5)
s(o4)
desventajas
más complejas de diseñar que los sistemas cliente/servidor clásicos


Ingeniería del Software de Gestión. Tema 4

Ingeniería del Software de Gestión. Tema 4

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Ingeniería del Software de Gestión. Tema 4

Ähnlich wie Ingeniería del Software de Gestión. Tema 4 (20)

Mehr von Enrique Barreiro

Mehr von Enrique Barreiro (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

Ingeniería del Software de Gestión. Tema 4