Un Ejemplo fábrica de productos químicos

Una planta química está equipado con una serie de sensores que son capaces de aumentar las
alarmas en respuesta a las condiciones de la planta. Cuando se emite una alarma, un experto
debe ser llamado a la escena. Los expertos tienen diferentes requisitos para hacer frente a
diferentes tipos de alarma. Los requisitos individuales están etiquetados R1-R8 para referencia.

R1 Un sistema basado en computadora se va a desarrollar para gestionar las alarmas de esta

planta.

R2) se necesitan cuatro tipos de cualificación para hacer frente a las alarmas. Estos son
eléctrica, mecánica, biológica y química.

R3 Tiene que ser expertos en servicio durante todos los períodos asignados en el sistema.

R4 Cada experto puede tener una lista de las cualificaciones.

R5 Cada alarma informado de que el sistema tiene un título asociado a él junto con

una descripción de la alarma que puede ser entendido por el experto.

R6 Siempre que se recibe una alarma por el sistema experto de la ronda clasificatoria

debe ser encontrado para que él o ella puede ser paginado.

R7 Los expertos deben ser capaces de utilizar la base de datos del sistema para comprobar
cuándo van a estar en servicio.

R8 Debe ser posible evaluar el número de expertos en servicio

Alarma: se requiere cualificación y la descripción

• Planta

• Calificación (eléctricos, mecánicos, biológicos, químicos)

• Experto: lista de calificaciones

• Período

• Sistema y base de datos del sistema? Probablemente se trata de un tipo de horario.

Después de haber creado un directorio que ahora es necesario explicar cuál es la diferencia
entre una clase y un tipo. En OO pura se acerca no hay distinción y esto tiene la consecuencia
de que a menudo se obtiene una colección muy grande de las clases y, por tanto, pueden
tener dificultades en el dominio de la complejidad debido al número de clases. En VDM ++
existe una distinción entre las clases y tipos y deseamos usar esto para reducir el número de
clases de nuestro modelo. tipos términos generales corresponden a lo que se conoce como
clases de contenedores en los enfoques convencionales OO. Estas son las clases que
simplemente tienen una serie de atributos que los usuarios de la clase puede leer y escribir.

Directriz 1: Los nombres de un directorio deben ser modelado como tipos si no tienen

"Real" funcionalidad (además de lectura / escritura) con respecto a la finalidad de la

modelo.

Calificación del diccionario anterior es un ejemplo de un nombre que es mejor modelada como
un tipo. La clasificación es un tipo de enumeración, ya que sólo tiene capacidad para cuatro
valores posibles y no tiene ninguna funcionalidad obvia. Si el propósito de nuestro modelo
incluyó los diferentes tipos de acciones diferentes expertos podrían llevar a cabo en función de
su calificación, que habría sido más natural para modelar la calificación como una clase.

Consideremos ahora la alarma y experto del diccionario. Ambos corresponden a agrupaciones

de objetos reales en el mundo físico de nuestro ejemplo, que co-existir y actuar de forma
independiente.

Por lo tanto, vamos a modelar tanto de éstos como las clases:

Alarma es una clase con atributos requeridos cualificación y la descripción. La descripción es

una cadena que puede ser considerado como un tipo de la misma manera como Calificación
(ver

Figura 1).

Expert es una clase con calificaciones como un atributo. Los requisitos establecen que hay una
lista de calificaciones. La lista de palabras implica implícitamente algún tipo de ordenamiento,
pero no sabemos de los requisitos nada acerca de cómo este ordenamiento debe ser.
Tenemos que tener presente aclaró con nuestro "cliente", pero por el momento, vamos a
suponer que no hay una ordenación específica que tiene importancia para la funcionalidad
deseada. Esto se muestra en la Figura 2.

De alguna manera tenemos que hacer alguna conexión con las alarmas asociados y un horario
de expertos. Con el fin de ser capaz de expresar las limitaciones precisas en el / la metodología
UML VDM ++ para este tipo de conexiones que suelen recomendar la creación de una clase
principal, que contiene las asociaciones a las otras clases.

En nuestro ejemplo, la clase principal será la planta. Recordemos que el objetivo de nuestro
modelo es aclarar las normas relativas al horario de trabajo y la convocatoria de expertos para
hacer frente a las alarmas. Elegimos la planta como una clase para modelar una perspectiva
abstracta centrarse en este objetivo. Por lo tanto, dos aspectos de la "planta" son importantes:
el horario de expertos en servicio y la recolección de (registrados) posibles alarmas.
Consideremos primero las alarmas. Necesitamos tener una asociación de la clase de las plantas
a la clase de alarma y puesto que podemos tener más de una alarma en nuestro sistema
tenemos que utilizar una multiplicidad con esta asociación. A esto le llamamos alarmas de
asociación (véase el gráfico a continuación).

Directriz 3: Cada vez que se introduce una asociación se debe considerar la multiplicidad de
ella y darle un nombre de función en la dirección en la que se desea utilizar la asociación.

Consideremos ahora el horario que debe contener un número de expertos asignados a

períodos. Para cada período podemos tener cero o más expertos en servicio. Por lo tanto
tenemos que utilizar una asociación que es calificado con punto y tiene una multiplicidad de
cero o más. Llamamos a este horario asociación

No se nos dice mucho acerca de los períodos en los requisitos, y que no necesitamos saber
mucho con el enfoque elegido del modelo. Podemos modelar periodo como un tipo, ya que no
contiene ninguna funcionalidad "real".

En este punto en el tiempo el diagrama de clases para nuestro sistema se puede extraer con
tres clases, como se muestra en la Figura 3.

Directriz 5: Uso VMtools para verificar la consistencia interna tan pronto como esqueletos de
clase se han completado (antes se ha introducido ninguna funcionalidad).

Usando VDMTools podemos tratar de escribir comprobar el modelo con el fin de asegurar su
coherencia interna, es decir, que todos los identificadores están bien definidos. Las tres clases
de arriba no son del tipo correcto, ya que hay tres identificadores que no están definidos:
Período, Cualificación y cadena (no integradas en VDM ++). Por lo tanto las siguientes tres
definiciones de tipos son insertado en las tres clases de VDM ++ respectivamente

3.3 El bosquejar firmas para las operaciones

Seguimos el desarrollo mediante la adición de las signaturas de operación en UML. Las tres
operaciones listadas en el directorio anterior pertenecen de forma natural en la planta de la
clase, ya que dependen de la horario que se asigna allí. Los diagramas de clases actualizadas
para la planta se muestra en la Figura 5.

Las firmas de las operaciones son sencillas. Por ejemplo, el ExpertToPage

operación toma una alarma y un período como entrada y devuelve un experto como resultado.

4 Making the Model More Precise

En esta etapa, es una buena idea revisar los requisitos para ver que nuestro modelo se aplique
a los individuales y satisfactoriamente. Es evidente que todavía no hemos considerado las
operaciones en detalle, por lo que R6-R8 no están cubiertos totalmente. De lo contrario los
requisitos parecen estar cubiertos razonablemente bien, excepto que no hemos documentado
requisito R3 en cualquier lugar:
R3 Tiene que ser expertos en servicio durante todos los períodos asignados en el sistema.

modelo Sin embargo, la gráfica y el tipo comprobado VDM ++anterior tiene cierta otra

supuestos ocultos y aspectos poco claros como veremos a continuación.

Normalmente, una persona implementar un modelo no lo hará, y no debe, hacer esto a partir
de los requerimientos originales directamente, pero el uso de modelos de análisis y diseño con
comentarios adjuntos. Esa es una finalidad de modelos. Por lo tanto, cuanto más precisa, sin
embargo, el resumen, se puede hacer este tipo de modelos de la menor es el riesgo de una
aplicación errónea, sin perjuicio de elección de implementación.

4.1 Adición de propiedades invariantes

Podemos formular requisito R3 de una manera precisa en el modelo de VDM ++. En primer
lugar, ¿qué significa que un período se asigna en el sistema? Esto es cuando se está en el
horario para los expertos en servicio, es decir, en el dominio de la instancia de programación
variable, que es una asignación de períodos a grupos de expertos.

A continuación, lo que significa que no son expertos en derecho por un período? Esto significa
que el valor del rango asociado con el período, es decir, un conjunto de expertos, no está vacía

En VDM ++, se añade este predicado como un invariante (inv abreviada) en la sección de
variables de instancia de la clase de plantas:

Directriz 7: Usted debe tratar de documentar propiedades importantes o limitaciones como

invariantes, porque una parte de un sistema puede suponer implícitamente alguna propiedad
invariante para sostener que las otras piezas deben tener en cuenta.

4.2 Finalización Definiciones de operación

A continuación tenemos en cuenta las condiciones asociadas a las operaciones, pre-

condiciones y post-condiciones, respectivamente. Una condición previa formaliza suposiciones
hechas por una operación, es decir, lo que debe contener de los parámetros y el estado del
objeto antes de ejecutar una operación. Una condición posterior declara lo que proporciona
una operación, es decir, lo que mantiene después de que haya sido ejecutado.

Así, el post-condición es una relación entre el estado inicial y los parámetros de objeto, por un
lado, y el estado final y el resultado en el otro. Por ejemplo, la operación

ExpertToPage toma una alarma y un período como entradas y devuelve un experto para
manejar la alarma. ¿Va a aceptar una alarma o periodo (condición previa) arbitraria? Y lo que
debe ser titular del experto (post-condición)?

ExpertToPage tiene la firma siguiente:

Sin embargo, como se indicó anteriormente, no puede tratar cualquier alarma y período. En
primer lugar, el período se debe conocer acerca de la programación, con el fin de asegurarse
de que no son expertos en servicio.

También parece obvio para exigir que la alarma ha sido registrado en el sistema, es decir, que
se encuentra entre las posibles alarmas que figuran en la instancia alarmas variables:

Por otra parte, la operación no debería devolver cualquier experto en servicio. El experto
deberá tener la calificación correcta de hacer frente a la alarma. Esto se documenta en la
condición post: