PDF de programación - Capitulo 2. Diseño de sistemas en tiempo real

CAPÍTULO 2. DISEÑO DE SISTEMAS EN TIEMPO REAL



2.1
2.2
2.3

2.3.1
2.3.2
2.3.3

2 Diseño de sistemas en tiempo real............................................................................ 2
Niveles de notación. ......................................................................................... 2
Especificación de requisitos. ............................................................................ 3
Actividades de diseño....................................................................................... 3
Encapsulamiento....................................................................................... 4
Cohesión y acoplamiento. ........................................................................ 4
Aproximaciones formales......................................................................... 4
2.4 Métodos de diseño............................................................................................ 5
2.4.1
JSD. .......................................................................................................... 6
2.4.2 Mascot3. ................................................................................................... 7
HRT-HOOD. ............................................................................................ 8
2.4.3
2.4.4
El lenguaje unificado de modelado (UML).............................................. 9
Implementación. ............................................................................................. 10
Ensamblador. .......................................................................................... 10
Lenguajes de implementación de sistemas secuenciales........................ 10
Lenguajes de programación concurrente de alto nivel. .......................... 11
Criterios generales de diseño de lenguajes............................................. 11
Prueba y gestión del diseño. ........................................................................... 12
Simuladores. ........................................................................................... 12
Prototipado. .................................................................................................... 13
Interacción hombre-máquina y gestión del diseño......................................... 13
Gestión del diseño. ......................................................................................... 14

2.5.1
2.5.2
2.5.3
2.5.4

2.5

2.6

2.7
2.8
2.9

2.6.1



Rafael Álvarez García
Última revisión 29-10-07
[email protected]



Nota importante:

Este documento no pretende reemplazar al material propuesto por la UNED
para la asignatura Sistemas en Tiempo Real.

Cualquier sugerencia, comentario o corrección sobre este documento,
envíelo a [email protected] para poder realizar los cambios
necesarios.



1




2 Diseño de sistemas en tiempo real.


Obviamente, la etapa más importante del desarrollo de cualquier sistema de tiempo real es
la generación de un diseño consistente que satisfaga una especificación acreditada de los
requisitos. En esto, los sistemas de tiempo real no difieren de las dermis aplicaciones, aunque
su escala en conjunto conlleva problemas de diseño fundamentales.


En esencia, todos los métodos de diseño incluyen una secuencia de transformaciones
desde el estado de los requisitos iniciales hasta el código ejecutable. Este capítulo proporciona
una visión general de algunas de las fases habituales por las que transcurre esta ruta, es decir:


• Especificación de requisitos.
• Diseño arquitectónico.
• Diseño detallado.
Implementación.
•
• Prueba,


También veremos otras actividades importantes.


• Prototipado previo a la implementación final
• Diseño de la interfaz hombre-maquina.
• Criterios para la evaluación de los lenguajes de implementación.

Puesto que son actividades aisladas, se necesita cierla notation que permita documentar



cada etapa.


2.1 Niveles de notación.


Hay varios modos de clasificar las formas de notación (o representación). McDermid

(1989) proporciona una útil descomposición para nuestros fines y destaca tres técnicas:



•

Informal

• Estructurada
• Formal

Los métodos informales suelen hacer uso del lenguaje natural y de diversos tipos de
diagramas imprecisos. Cuentan con la ventaja de que estas notaciones son legibles para un
gran numero de personas (todos aquellos que conozcan dicho lenguaje natural). Es bien
sabido, sin embargo, que las frases en ingles, por poner un caso, pueden interpretarse de
formas diversas.


Los métodos estructurados suelen emplear notación grafica, pero a diferencia de los
diagramas informales estos gráficos están bien definidos. Dichos esquemas se construyen a
partir de un pequeño numero de componentes predefinidas que pueden conectarse de una



2

forma controlada. La forma grafica puede tener también una representación sintáctica en
algún lenguaje bien definido.


A pesar de que pueden idearse métodos estructurados muy rigurosos, no pueden, en si, ser
analizados o manipulados. Para poder efectuar este tipo de operaciones, la notación debe tener
una base matemática. Los métodos que presentan dichas propiedades matemáticas se conocen
como métodos formales. Estos tienen la ventaja evidente de que mediante estas notaciones es
posible realizar descripciones precisas. Además, es posible probar la existencia de ciertas
propiedades necesarias; por ejemplo, que el diseño de alto nivel satisface la especificación de
requisitos. Sin embargo, las técnicas formales son difíciles de comprender para aquellas
personas que no han recibido la formación necesaria o que son incapaces de adquirir una
suficiente familiaridad con la notación.



2.2 Especificación de requisitos.


Casi cualquier proyecto de aplicación arranca de una descripción informal de lo que se
desea. A ésta debería seguirle un análisis profundo de los requisitos. En esta etapa donde se
define la funcionalidad del sistema. En cuanto a los factores concretos de tiempo real, deberá
hacerse suficientemente explícito el comportamiento temporal del sistema, así como los
requisitos de fiabilidad y el comportamiento deseado del sistema en caso de fallos en los
componentes. La fase de requisitos deberá definir también el test de aceptación que se
aplicarán al software.


A parte del sistema en sí, es necesario construir un modelo del entorno de la aplicación.
Es característico de los sistemas de tiempo real presentar interacciones importantes con su
entorno. Por tanto, cuestiones como la tasa máxima de interrupciones, el número máximo de
objetos externos dinámicos (por ejemplo, las aeronaves en un sistema de control de tráfico
aéreo) y los modos, son importantes.



2.3 Actividades de diseño.


El diseño de un sistema embebido grande debe de estructurase de alguna manera.
Para gestionar el desarrollo de los sistemas de tiempo real complejos, se suelen emplear
dos aproximaciones complementarias.


• La descomposición, implica una participación sistemática del sistema complejo
en partes más pequeñas, hasta poder aislar componentes que puedan ser
comprendidos y diseñados por individuos o grupos pequeños. En cada nivel de
descomposición, deberá haber un nivel de descripción apropiado y un método
para expresar esta descripción.

• La abstracción permitirá posponer cualquier consideración referente a los

detalles, particularmente las concernientes a la implementación.


La utilización de la abstracción y la descomposición impregna todo el proceso de

ingeniería, y ha influido en el diseño de los lenguajes de programación de tiempo real.



3

2.3.1 Encapsulamiento.


El desarrollo jerárquico del software conduce a la especificación y subsiguiente desarrollo
de los subcomponentes del programa. Por la naturaleza de la abstracción, estos
subcomponentes deberán tener roles bien definidos, e interfaces y conexiones claras e
inequívocas. Cuando la especificación completa del sistema software puede verificarse
teniendo en cuenta únicamente la especificación de los subcomponentes inmediatos, se dice
que la descomposición es composicional. Esta es una propiedad importante cuando se trata
de analizar formalmente programas.

2.3.2 Cohesión y acoplamiento.


La cohesión y el acoplamiento son dos medidas que describen la vinculación entre

módulos.


La cohesión expresa el grado de unión de un modulo: su fuerza interna. Allworth y Zobel

(1987) indican seis medidas de cohesión que van desde la más débil a la mas fuerte:


Casual: los elementos del modulo mantienen tan solo vínculos muy superficiales; por

ejemplo, el haber sido escritos en el mismo mes.

Lógica: los elementos del modulo están relacionados desde el punto de vista del sistema
complete, pero no en términos reales de software; por ejemplo, todos los gestores de dis-
positivos de salida.

Temporal: los elementos del modulo se ejecutan en momentos similares; por ejemplo,

las rutinas de arranque.

Procedural: los elementos del modulo se emplean en la misma sección del programa;

por ejemplo, los componentes de la interfaz de usuario.

De comunicación (sic): los elementos del modulo operan sobre la misma estructura de

datos.

Funcional: los elementos del modulo operan conjuntamente para contribuir a la
ejecución de una única función del sistema; por ejemplo, proporcionar un sistema de archivos
distribuidos,


El acoplamiento, por otra parte, es una medida de la interdependenc