Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Temario
Definiciones
Requisitos Funcionales y No Funcionales
Tipos de Requisitos
Ingeniera de Requisitos
Proceso de los Requisitos
Metodologas de Desarrollo
Especificacin Formal - Z
Bibliografa
Pfleeger: Captulo 4
Ingeniera de SW - Sommerville (7ma. edicin): Captulos
6 Requisitos del software
7 Procesos de la Ing. de Requisitos
10 Especificacin formal
UML:
http://www.uml.org/
Artculos en la pgina:
Introduccin a UML - Artculo de la revista Rational Edge
Diagramas de Actividad - Artculo de la revista Rational Edge
Motivacin
Definiciones
Requisitos:
Descripcin de los servicios que debe brindar un
sistema y sus restricciones.
Ingeniera de Requisitos
Proceso de descubrir, analizar, documentar y verificar
esos servicios y restricciones.
Definiciones
Sistema
Incluye hardware, software, firmware, personas,
informacin, tcnicas, servicios, y otros elementos de
soporte
Causas
Causas
%
Respuestas
Requisitos incompletos
13.10%
Falta de involucramiento de
usuarios
12.40%
Falta de Recursos
10.60%
Expectativas no realistas
9.90%
9.30%
Requisitos y Especificaciones
cambiantes
8.70%
Falta de planificacin
8.10%
Sistema no se precisaba ms
7.50%
No-funcional:
Restricciones a los servicios o funciones ofrecidos por
el sistema
Describen restricciones que limitan las elecciones para
construir una solucin
Ejemplos:
Las consultas deben resolverse en menos de 3 segundos
El lenguaje de programacin debe ser Java
10
Requisitos No Funcionales
Del Producto: Especifican restricciones al
comportamiento del producto
Ejemplos: desempeo, confiabilidad, portabilidad, usabilidad
11
Interfaces
Entrada de 1 o + sistemas, Salida a 1 o + sistemas,
restricciones de formato, soporte
12
Datos
formatos E/S, frecuencia, fuentes, destinos, calidad
requerida, precisin en clculos, flujo en el sistema
Recursos
materiales, personal y otros para construir, usar y
mantener el sistema, habilidades de los
desarrolladores, necesidades de espacio y
ambientales, calendario prescrito, limitaciones en
presupuesto
13
Aseguramiento de la Calidad
Confiabilidad tiempo medio entre fallas, robustez, tolerancia a
fallas
Disponibilidad - tiempo para estar operativo luego de fallamantenimiento estando activo- tiempo mximo de no
disponibilidad
Mantenibilidad
Seguridad
Portabilidad
14
Ingeniera de Requisitos
Ingeniera de Requisitos
Ingeniera de Requisitos
Obtencin
Obtencin
Anlisis
Anlisis
Especificacin
Especificacin
Verificacin
Verificacin
Validacin
Validacin
Lnea Base de
Requisitos
Planificacin
Planificacin
Planificacin
Planificacin
Trazabilidad
Trazabilidad
Lnea base
actual
SCM
Cambios en
requisitos
Administracin
Administracin
del
del Cambio
Cambio
Cambios
16
en el proyecto
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
17
Participantes en el Proceso de
Requisitos
Cliente y Usuarios
Requisitos adecuados a sus necesidades
Diseadores
Comprenderlos para lograr diseo que los satisfaga
Verificadores
Comprenderlos para poder verificar si el sistema los
satisface
18
Obtencin de Requisitos
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
20
Requisitos - Fuentes
Necesidades del cliente, usuario, otros
interesados
Modelos del dominio
Revisar la situacin actual
Organizacin actual y sistemas
Versin actual del sistema
Desarrolladores de versin anterior
Documentos existentes (antecedentes)
Sistemas anlogos ya existentes (antecedentes)
21
22
Segn usuarios,
los desarrolladores...
quieren todo ya
23
Clasificacin y
Organizacin
de Requisitos
Relevamiento
de Requisitos
Priorizacin y
negociacin de
requisitos
Documentacin
de Requisitos
24
Qu relevar
Requerimientos del negocio:
Objetivos del negocio de alto nivel. Responden a la pregunta:
cmo ser el mundo mejor para una determinada comunidad?
Categoras:
beneficios financieros
mejora de las operaciones de negocio
posicionamiento estratgico / competitivo
adoptar una nueva ley
nivelado / desarrollo tecnolgico.
25
Qu relevar
Reglas de negocio. - Existen independientemente del
software. Aplican aunque se haga manualmente.
polticas de la organizacin
estndares
algoritmos
leyes y regulaciones
Requisitos funcionales
Requisitos no funcionales:
atributos de Q
interfaces externas
restricciones
26
Obtencin de Requisitos
Tcnicas
Investigar antecedentes
Entrevistas individuales/grupales
Encuestas/Cuestionarios
Tormenta de ideas
Workshop
Casos de Uso
Observacin/Participacin
Prototipado
27
Investigar antecedentes
Estudio, muestreo, visitas,
Buena forma de comenzar un proyecto
Interna: estructura de la organizacin, polticas y
procedimientos, formularios e informes, documentacin
de sistemas
Externa: publicaciones de la industria y comercio,
Encuentros profesionales, visitas, literatura y
presentaciones de vendedores
Ventajas
Ahorra tiempo de otros
Prepara para otros
enfoques
Puede llevarse a cabo
fuera de la organizacin
Desventajas
Perspectiva limitada
Desactualizado
Demasiado genrico
28
Ventajas
Orientado a las personas
Interactivo/flexible
Rico
Desventajas
Costoso
Depende de las habilidades
interpersonales
Seleccionar participantes
Aprender tanto como sea
posible de antemano
Preparar la entrevista
Utilizar un patrn de
estructura
Conducirla
Apertura, desarrollo,
conclusin
29
30
Otros
Existen requisitos legales, regulatorios u otros estndares que deban
ser tenidos en cuenta?
Tener en cuenta:
Si el entrevistado comienza a hablar sobre los problemas existentes, no
cortarlo con una prxima pregunta
Luego de la entrevista y mientras los datos an estn en mente, resumir
los principales req. (aprox. 3) de este entrevistado
31
Encuesta / Cuestionario
No substituye la entrevista
Antes de usar el enfoque:
Determinar la informacin que se precisa
Determinar el enfoque ms adecuado:
Abierto, cerrado, combinado
Mltiple opcin, valor en escala, orden relativo
Desarrollar cuestionario
Probarlo con perfil tpico
Analizar resultado de las pruebas
Menos rico
Problemas por norespuesta
Esfuerzo de desarrollo
32
Observacin / Participacin
Poco utilizado
Antes de usarlo
Ventajas
Confiable
Muy rico
Desarrolla empata
Desventajas
Efecto Hawthorne
Cuidado con generalizar
demasiado (sesgo
particular/local)
33
Agrupamiento de ideas
Nombrar los grupos
Definicin
Se escribe una breve descripcin de lo que la idea significa para
la persona que la escribi
Ayuda a tener un entendimiento comn del requerimiento
Lleva unos minutos por idea
Priorizacin (opcional)
Test de los $100: Cada persona tiene dinero para comprar
ideas, se ordena segn ideas ms compradas
Solo se puede hacer una vez
Se debe limitar la cantidad a gastar en 1 sola idea
36
Organizar la Agenda
Introduccin
Tormenta de ideas generacin
Tormenta de ideas reduccin
Priorizacin
Resumen
37
Casos de Uso
Formato simple y estructurado donde los usuarios y
desarrolladores pueden trabajar juntos
No son de gran ayuda para identificar aspectos no
funcionales
Mientras se definen los casos de uso, puede ser un buen
momento para definir pantallas u otros objetos con los
que el usuario interacta
Pueden ser usados en el diseo y en el testing del
sistema
Usarlo
Cuando el sistema est
orientado a la
funcionalidad, con varios
tipos de usuarios
Cuando la
implementacin se va a
No son la mejor
eleccin:
Prototipado
Implementacin parcial, permite a los desarrolladores y
usuarios:
entender mejor los requisitos
cules son necesarios, deseables
acotar riesgos
39
____
mes:
____
da:
____
Julio 1998
1998
1
Ene
2025
31
Dic
Martes 16 Oct. 2002
40
Anlisis de Requisitos
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
42
Anlisis de Requisitos
43
Clientes:
Definir responsable de:
resolucin de conflictos
validacin
Planificar reuniones de
revisin de avance con el
responsable.
Definir proceso de resolucin
de conflictos pe. en alcance.
Usuarios:
dividirlos en clases
definir representantes
definir prototipos
acordar responsabilidades y
estrategias de colaboracin
con representantes
44
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
45
Diagramas UML
UML
47
Tablas de Decisin
Descripcin dinmica
Conjunto de condiciones posibles en un cierto instante
Estados donde se verifica una combinacin determinada
de las condiciones
Estados
Acciones a tomar
Condicion
es
Acciones
Buenos Antecedentes
Ya oper antes
Autorizar Crdito
Analizar antecedentes
X
X
Redes de Petri
Descripcin dinmica
Permiten describir:
Concurrencia
Sincronizacin
49
L2 -Lugar
Significado:
Transiciones: Modelan
eventos o acciones
Lugares con marca:
Cumplimiento de una
condicin
Transicin activada:
Ocurrencia del evento o
ejecucin de la accin
50
Existe al menos un
token en cada uno de
sus lugares de entrada
L1
L2
L2
T1
L3
L4
L5
L3
L4
L5
51
L4
Secuencia
T3
T1
Conflicto
T4
T6
T5
L8
L9
L10
L2
L5
L6
L7
T2
L3
T7
T8
Concurrencia
T9
T10
L11
Sincronizacin
52
Redes de Petri
T2- rechaza
moneda
T3- acepta
moneda
L3- pronto para
dispensar
53
Elementos
Proceso
54
DFD - Ejemplo
Experiencia y
conocimiento
Mdico
Sntomas
Examen
Diagnstico
Medicacin
Lista de exmenes y
servicios brindados
Diagnstico
Contabilidad
Factura
Exmenes y
Precios
Paciente
Registro Contable
55
DFD
Permite visualizar cmo fluye la informacin por el sistema
est asociado a una realizacin particular del sistema
El diagrama no es suficiente para precisar el comportamiento:
por un flujo que entra a un proceso desde un archivo,
fluye un
registro o todo el archivo?
No estipula sincronizacin, un flujo llega a una entidad externa y otro sale
Estn relacionados? Uno es respuesta del otro?
56
Casos de Uso
Tcnica para entender y describir requisitos
Los casos de uso son requisitos, describen
requisitos funcionales
Pone el acento en el uso del producto
Describen como el sistema debe comportarse
desde el punto de vista del usuario
Casos de Uso como caja negra: Especifican que
es lo que el sistema debe hacer sin especificar
cmo debe hacerlo
Se describen mediante documentos de texto
Introducido por Ivar Jacobson (1992)
57
Actor
Entidad externa que interacta con el sistema
(persona identificada por un rol o sistema externo)
Actor principal: Sus objetivos son cumplidos al realizar
el caso de uso
Los actores son externos al sistema que vamos a
desarrollar.
Al identificar actores estamos delimitando el sistema
Usuario: persona que cuando usa el sistema, asume
un rol.
<<actor>>
Sistema
Actor
58
Cliente
Retirar
Servicio de
Cajeros
Caso de Uso
Caso de Uso
Escenario:
Secuencia de acciones e interacciones entre los
actores y el sistema, dando un resultado de valor
observable para un actor particular
Tambin se conoce como instancia de caso de uso
Es una forma particular de usar el sistema, un camino
a travs de un caso de uso.
61
Sistema
Servicio de Cajeros
62
Casos de Uso
Forma de encontrarlos: Mirar cada uno de los actores
del sistema y preguntarse que es lo que buscan
cuando usan el sistema.
Recomendacin: Identificarlos con un verbo.
Cada caso de uso modela partes de la dinmica.
Diagrama de Casos de Uso descripcin esttica.
Los casos de uso son independientes del mtodo de
diseo que se utilice, y por lo tanto del mtodo de
programacin, no son parte del anlisis OO, pero son
una excelente entrada para ello.
Los casos de uso pueden dirigir el proceso de
desarrollo. Guan el diseo, la implementacin y la
prueba del sistema.
63
65
66
Retirar
Cliente
Depositar
Transferir
Servicio de Cajeros
67
68
<<include>>
<<include>>
Retirar
Transferir
Depositar
69
Flujo Principal:
1.
2.
3.
4.
5.
6.
Flujos Alternativos:
2A. La tarjeta no es vlida
1. El CA devuelve la tarjeta con el mensaje tarjeta no vlida
2. Fin CU
6A. PIN invlido y menos de 3 intentos
El Cliente puede realizar tres intentos para ingresar el PIN vlido. Sino, el CA retiene la tarjeta.
1. El SC contesta indicando PIN invlido
2. El CA muestra el mensaje PIN incorrecto
3. Sigue en punto 3
6B. PIN invlido y 3 intentos
El CA debe retener la tarjeta
1. El SC contesta indicando PIN invlido
2. El CA muestra el mensaje Se le retiene la tarjeta
3. Fin CU
71
Extend - Ejemplo
El cliente puede querer retirar monedas adems
de billetes
<<include>>
Identificar Cliente
Retirar
<<extend>>
Retirar Monedas
73
Puntos de Extensin:
Retiro de Monedas: En el punto 8 del flujo principal
74
Flujos Alternativos:
3A El cliente puede querer cambiar la seleccin, se vuelve a 1
G1 El cliente cancela el retiro de monedas. Fin CU Retirar Monedas
75
Validar Cliente
76
Actividades
77
UML
Unified Modeling Language
Objetivo: Proveer un lenguaje comn que puede ser
usado para el desarrollo de software
Lenguaje que permite:
Visualizar: La comunicacin es a travs de grficos
Especificar: construyendo modelos para el anlisis, diseo,
implementacin
Construir: Permite la generacin de cdigo a partir de un modelo
UML, y la construccin de un modelo a partir del cdigo
(ingeniera reversa)
Documentar: Permite la documentacin completa de todo el
sistema
Diagramas en UML
80
Tipos de Diagramas
Modelo Esttico
Construye y documenta los aspectos estticos de un sistema.
Refleja la estructura bsica y estable de un sistema software.
Crea una representacin de los principales elementos del dominio
del problema
Modelo Dinmico
Crea los diagramas que muestran el comportamiento de un
sistema
Para requisitos se utilizan los siguientes diagramas:
81
82
<<extend>>
Retirar Monedas
<<include>>
Retirar
Cliente
Depositar
<<include>>
Validar con Scaner de Retina
Transferir
83
Diagrama de Clases
Nombre Clase
Atributos
Operaciones
Atributos
Operaciones
Relaciones
Semntica
84
usa
0..1
0..n
Tarjeta
Nmero
PIN
Banco
Nombre
expide
n
tiene
0..1
0..n
1
n
Cuenta
saldo
Retiro.
Cajero.
saldo
1
realiza
n
Transaccin
monto
Depsito.
Transferencia.
85
Diagrama de Actividad
Se construye para modelar el flujo del control (workflow)
Elementos:
Estado de Actividad (o de Accin)
Estado Inicial
Estado Final
Transiciones
Actividades concurrentes
Bifurcaciones
Condiciones de la bifurcacin
[ guarda ]
Andariveles
86
Se abren
Flujos
Paralelos
Sincronizaci
n
87
Diagrama de Estados
Muestra el comportamiento de un objeto representando
los estados en que se puede encontrar y los eventos
que le hace pasar de uno a otro.
Se utiliza para:
Modelar el estado interno de una entidad
Modelar el estado de un caso de uso
88
Esperar
Tarjeta
ingreso tarjeta
Pedir PIN
Seleccionar
cuenta y monto
Verificar
fondos
fondos insuficientes
Devolver
Tarjeta
retiro de tarjeta
dinero suficiente
Dispensar
89
90
91
Especificacin de Requisitos
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
93
Lenguajes de Notacin
Lenguaje Natural
94
Notaciones Especiales
Grficas vs. Basadas en texto
Estticas vs. Dinmicas
Descripciones Estticas
Se especifican entidades y sus atributos, los requisitos se
pueden ver como las relaciones entre las entidades.
No describe como cambian las relaciones con el tiempo
Descripciones Dinmicas
Especifican estados y las transiciones entre estados en el
tiempo
95
Documentacin de requisitos
Qu documentar:
lo que hace el sistema actual
lo que el cliente pide
lo que el sistema va a hacer
criterios de aceptacin
criterios de verificacin
Recomendaciones:
agrupar por temas
formular los reqs como reqs positivos y no negativos
expresarlos en voz activa y no pasiva
indicar si se est documentando solo lo que va en el alcance o todo lo
que se pidi.
representar reqs. con mltiples vistas (ejemplo de los ciegos y el
elefante).
96
Documentos de Requisitos
97
Definicin de Requisitos
Especificacin de Requisitos
Mdulos de Diseo
Cdigo que implementa los mdulos
Pruebas para verificar la funcionalidad
Documentos que describen el sistema
98
Completa: Incluye:
Todos los requisitos asociados con funcionalidad, desempeo,
restricciones de diseo, atributos o interfaces externas.
Definicin de respuestas del sw a todo posible datos de entrada
(vlidos o invlidos) en toda clase de situaciones realizables.
No hay referencias sin definir en la especificacin.
La frase a determinar indica SRS no completa. Ocasionalmente
necesaria; describir:
condiciones que causan que no se sepa an.
qu se debe hacer para determinar lo que falta, quin y cundo.
100
101
102
Realistas / Factibles
Ej.: tiempo de respuesta local=remoto
Ej.: El cliente quiere adelantarse a la tecnologa
Verificacin de Requisitos
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
105
Verificacin de Requisitos
Se verifica en el documento de requisitos:
Consistencia: que no haya contradicciones
Completitud: que no falte nada. Chequear por:
Omisiones. Hacer rboles de decisin para ver que estn todas las
opciones detalladas.
Lmites. Ms claro con tabla, ah se ve que no falta ninguno.
Necesidad
Ambigedades
Realismo o Factibilidad: que se puedan implementar con la
tecnologa, presupuesto y calendario existentes.
Verificabilidad: que se pueda disear conjunto de pruebas para
demostrar que el sistema cumple esos requisitos. Cuidado con
adjetivos y adverbios.
Comprensibilidad: que los usuarios finales lo entiendan
Adaptabilidad: que el requisito se pueda cambiar sin afectar a
otros.
Trazabilidad: que est establecido el origen. Incluye verificar
trazabilidad entre la especific. y el doc. de requisitos.
106
Medida
Rapidez
Tamao
KB
Fiabilidad
Portabilidad
Facilidad de uso
Tiempo de capacitacin
107
Verificacin de requisitos
Definir quines, cmo, cundo.
Cmo:
revisiones formales (en grupo)
revisiones por pares
listas de comprobacin
108
Validacin de Requisitos
Proceso de Requisitos
Actividad
es
Planificacin
Obtencin
Anlisis
Especificacin
Verificacin
Validacin
Artefacto
s
Documento
de
Visin
Documento
de
Requisitos
Modelo del
Sistema
Especificaci
n de
Requisitos
110
Validacin de Requisitos
Proceso por el cual se determina si la
especificacin es consistente con las
necesidades del cliente
Se verifica en el documento de requisitos:
Validez: que el usuario valide qu es lo que
quiere
Planificar quin (qu stakeholder) va a validar qu
artefacto cmo (tcnica).
Ejecutar
Registrar Reporte de validacin / Firma
111
Validacin de Requisitos
Tcnicas de Validacin:
Manuales
Automatizadas
Referencias cruzadas automticas: Si los requisitos se expresan
formalmente, las herramientas CASE verifican su consistencia
Ejecucin de Modelos
Construccin de Prototipos
112
Revisin de Requisitos
Proceso manual. Se revisa el documento de requisitos buscando
anomalas y omisiones:
Revisiones informales: discusin informal
Revisiones formales: se hace una recorrida del doc de req con el cliente,
explicando implicancias de cada requisito.
Participan representantes:
del cliente: operadores, quienes realicen entradas, utilicen salidas, y sus
gerentes
del equipo de desarrollo: analistas de requisitos, diseadores, encargados
de pruebas y gestin de configuracin
Incluye:
113
Ingeniera de Requisitos
Ingeniera de Requisitos
Obtencin
Obtencin
Anlisis
Anlisis
Especificacin
Especificacin
Verificacin
Verificacin
Validacin
Validacin
Lnea Base de
Requisitos
Planificacin
Planificacin
Planificacin
Planificacin
Trazabilidad
Trazabilidad
Lnea base
actual
SCM
Cambios en
requisitos
Administracin
Administracin
del
del Cambio
Cambio
Cambios
114
en el proyecto
115
Planificacin
Muchas actividades son tomadas de las tcnicas de SCM
Se debe decidir sobre:
Identificacin de Requisitos: Cada requisito debe identificarse en
forma nica, para poder ser referenciado por otros.
Ejemplo:
<Tipo> < nro> donde Tipo: F Funcional, D- Datos, etc.
Ejemplo: F12
116
Trazabilidad
Informacin de rastreo que se debe mantener
La fuente: Quin propuso el requerimiento y porqu
Requisitos dependientes: Vincula los requisitos
dependientes entre s, se usa para el anlisis del
cambio
Trazabilidad entre artefactos distintos, qu versin
se corresponde con cul. Pe.:
Rastreo reqs - CU
Rastreo al diseo: Vincula el req con los mdulos de diseo
que lo implementan
El cambio va a ocurrir.
Objetivos del control de cambios:
relevamiento incompleto/inefectivo
o acuerdo prematuro
118
119
120
121
122
Proceso
actividades,...
Recursos
personas, equipos, tiempo, dinero,...
123
# Cambios introducidos
Requisitos Agregados, Modificados, Desechados en el tiempo
Estabilidad
# Requisitos validados
124
Metodologas de Desarrollo
Metodologas de Desarrollo
Los mtodos giles fueron desarrollados en
respuesta a la necesidad de tener una
alternativa a los procesos de desarrollo de
software pesados, guiados por documentos
(AgileAlliance 2002)
Cada metodologa trata distinto los requisitos
Ejemplo de metodologa gil: eXtreme
Programming (XP)
Ejemplo de metodologa pesada: Rational
Unified Process
126
eXtreme Programming
Cliente en el lugar
Un cliente real debe sentarse en el lugar, disponible para escribir
historias, contestar preguntas, resolver disputas y prioridades de
pequea escala.
Historias de usuario
Su propsito es anlogo al de los casos de uso
Son escritas por el cliente, son las cosas que el sistema debe hacer
No son casos de uso, pero describen escenarios
Su formato son tres sentencias de texto escritas por el cliente, en su
terminologa sin sintaxis tcnica.
Cuando llega el momento de implementarla, los dasarrolladores van
con el cliente y reciben una descripcin detallada de los requisitos,
cara a cara
Se usan para planificar el proyecto: se estiman y el cliente las
prioriza definiendo el alcance
127
128
129
Especificacin Formal
Ventajas:
Permite detectar omisiones e inconsistencias en los
requisitos
Deteccin temprana de defectos
Necesario para demostrar que un programa es
correcto
Desventajas:
Exige entrenamiento
En general no es comprensible para el cliente
Funcionan bien en escalas reducidas, pero se
complican a medida que crece la escala del producto
Bombea insulina
del depsito a la
aguja
Depsito
aguj
a
Sensor
Mide nivel
de azcar
en la sangre
Controla todo
el sistema
bomba
Controlador
reloj
Alarma
Suena en caso
de problemas
Pantalla
Fuente de Energa
Muestra la ultima
lectura de azcar
y mensajes de
estado
132
Concepto de Operacin
A partir de la lectura del sensor, el sistema evala el nivel
de glucosa en sangre del paciente
El sistema compara lecturas consecutivas para detectar
una posible tendencia al crecimiento del nivel. En este caso
inyecta insulina para actuar en contra de esa tendencia
La situacin ideal es que el nivel de azcar se encuentre
sistemticamente en la banda de seguridad
Niveles de azcar en sangre:
Inseguro menos de 3 unidades (posible coma)
Seguro- entre 3 y 7 unidades
No deseable (ms de 7 unidades)
133
Inyeccin de Insulina
Segn nivel de azcar, tendencia e inyecciones anteriores
Escenarios relativos al nivel de azcar en sangre:
en la banda insegura
No inyectar
Alarma para el paciente
estable
En banda segura no inyectar
En banda no deseable inyectar de acuerdo a lo indeseado del
nivel
creciendo
En la banda segura inyectar si tasa de crecimiento constante o
creciente
En banda no deseable inyectar de acuerdo a la tasa de
crecimiento
134
Lenguaje de Especificacin Z
Se han desarrollado diversos lenguajes y herramientas
para la especificacin (y verificacin) de software.
Z (Hayes 87, Spivey 92) est basado en la teora de
conjuntos tipados
modela un sistema en base a conjuntos y sus relaciones
introduce elementos que facilitan la especificacin de pre y post
condiciones asociadas a estados
los modelos se construyen a partir de esquemas
135
Lenguaje de Especificacin Z
Schema
name
Schema
signature
Schema
predicate
Container
contents:
capacity:
contents <= capacity
Schema signature:
Declara nombres y tipos de las entidades
Schema predicate:
Define relaciones entre las entidades de la signature
mediante expresiones lgicas que deben ser
verdaderas (invariantes)
136
Lenguaje de Especificacin Z
Nombres seguidos por ? son entradas y por ! ,
salidas
Nombre seguido por significa el valor despus
de la operacin
precediendo a un nombre significa que los
valores no son cambiados por la operacin
precediendo a un nombre significa que los
valores son cambiados por la operacin
Incluir el esquema A en el esquema B significa
que B hereda los nombres y predicados de A
137
138
139
Clculo de la dosis
DOSAGE
Insulin_Pump
(
dose = 0
(
r1>=r0) ( r2 = r1))
(( r1 > r0) (r2<= r1))
(( r1 < r0) ((r1-r2) > (r0-r1)))
)
dose = 4
(
(( r1<=r0) (r2=r1))
(( r1 < r0) ((r1-r2) <=(r0-r1)))
)
dose =(r2 -r1) * 4
(
(( r1<=r0) (r2 > r1))
(( r1 > r0) ((r2 - r1) >=(r1 - r0)))
)
)
capacity ' =capacity - dose
cumulative_dose' = cumulative_dose + dose
r0' = r1 r1' = r2
El programa:
Compara el valor actual
del nivel de azcar con
los dos anteriores
si est subiendo, la
bomba inyecta insulina
mantiene total de
insulina inyectada para
controlar el mximo
seguro
140
Esquemas de Salida
Modelan lo que despliega el sistema:
La pantalla muestra la dosis calculada y un mensaje de advertencia
La alarma suena si el azcar en la sangre es muy baja -debe ingerir azcar
DISPLAY
Insulin_Pump
display2!' = Nat_to_string (dose)
(reading? < 3 display1! ' = "Azcar baja
reading? > 30 display1! ' = "Azcar muy baja
reading? >=3 and reading?<=30 display1!' = "OK")
ALARM
Insulin_Pump
( re ading? < 3 re ading? > 30 ) alarm!' = on
reading? >= 3 reading?<=30 ) alarm!' = off
141