DOCUMENTO III.

ESTUDIO DE VIABILIDAD
DEL SISTEMA

ÍNDICE

1
DOCUMENTO III. ESTUDIO DE VIABILIDAD DEL SISTEMA.......................................... ..........1

HISTORIA................................................................................................................. ....................5

1 INTRODUCCIÓN................................................................................................ ........................6
1.1 Identificación del proyecto................................................................. ............................6
1.2 Visión general del documento.......................................................................... ..............6

2 ÁMBITO Y ALCANCE DEL PROYECTO.......................................................... .........................7

2.1 Descripción General del Sistema......................................................................... ..........7
2.1.1 Contexto.......................................................................................... ....................7
2.2 Catálogo de Objetivos del EVS................................................................................. .....7
2.3 Catálogo de Requisitos Preliminares.......................................................... ...................8
2.3.1 Requisitos funcionales................................................................................. ........8
2.3.2 Requisitos no funcionales........................................................................... .........8
2.3.3 Prioridades.......................................................................................................... .9

3 LISTA DE USUARIOS PARTICIPANTES...................................................................... .............10

4 DESCRIPCIÓN DEL SISTEMA ACTUAL......................................................................... ..........11

4.1 Modelo Físico....................................................................................................... ..........11
4.1.1 Descripción del diagrama físico......................................................................... ..13
4.1.2 Ficheros utilizados.................................................................................... ...........14
4.2 Problemas..................................................................................................... .................18

5 CATÁLOGO DE REQUISITOS DEL SISTEMA Y PRIORIDADES........................................... ..19

5.1 Requisitos funcionales.......................................................................... .........................19
5.2 Requisitos no funcionales.................................................................... ..........................20
5.2.1 Rendimiento............................................................................... .........................20
5.2.2 Frecuencia de tratamiento........................................................................... ........20
5.2.3 Requisitos de seguridad............................................................. .........................20
5.2.4 Requisitos especiales....................................................................... ...................20
5.3 Requisitos relativos al entorno tecnológico.......................................................... ..........20
5.3.1 Requisitos hardware........................................................................ ....................20
5.3.2 Requisitos software.............................................................................................. 20

6 ANÁLISIS DE ALTERNATIVAS................................................................................ ..................21

6.1 Descripción de Alternativas..................................................................................... .......21
6.1.1 Alternativas de Solución....................................................................... ...............21
6.2 Valoración de Alternativas........................................................................................ ......21
6.3 Descripción de la Alternativa Seleccionada................................................... ................22
6.3.1 Alternativa escogida..................................................................... .......................22
6.3.2 Características............................................................................................. ........22
6.3.3 Entorno de Desarrollo................................................................................ ..........23
6.3.4 Elección y valoración de alternativas................................................. .................23

2
 ÍNDICE DE ILUSTRACIONES
FIGURA 1: USUARIOS PARTICIPANTES Y ESQUEMA DE TAREAS
.............................................................................................................................. .........................10

FIGURA 2: DIAGRAMA FÍSICO DEL SISTEMA ACTUAL

.............................................................................................................................. .........................11

FIGURA 3: FICHERO SYSTEM.TXT

.............................................................................................................................. .........................14

FIGURA 4: FICHERO PROGRESS.TXT

.............................................................................................................................. .........................15

FIGURA 5: FICHERO LOG.TXT

.............................................................................................................................. .........................16

3
 HISTORIA

Versión Fecha Cambios introducidos

0.1 20/08/06 Interfaz de control del progreso

0.2 05/10/06 Interfaz de definición del sistema

0.3 30/10/06 Interfaz de representación de resultados

1 05/11/06 Integración de los subsistemas

4
1 Introducción

1.1 Identificación del proyecto

Titulo Interfaz gráfica para un analizador estocástico de sistemas en tiempo real

Director José María López… Ingeniero…

Autor: David Sánchez Barbosa

Fecha: Diciembre de 2006

1.2 Visión general del documento

En este documento se estudia la viabilidad del sistema a desarrollar, mostrando el estado
actual del sistema y posteriormente analizando sus deficiencias. A continuación se confecciona
un catálogo de requisitos y se plantean diversas alternativas para solucionar el problema
planteado. Finalmente, se elige de manera razonada una de las soluciones propuestas.

5
2 Ámbito y Alcance del Proyecto.

6
 En este documento se estudia la necesidad planteada para el presente proyecto,
concretamente en dotar a la aplicación Stochan 0.4 de un interfaz gráfico intuitivo, funcional y
portable para facilitar su utilización por parte del usuario

2.1 Descripción General del Sistema.

En este apartado se pasa a describir el contexto en el que va a operar el interfaz requerido y
una descripción general de la aplicación Stochan 0.4

2.1.1 Contexto.
El presente proyecto se encuadra dentro del marco de la Investigación Operativa. Más
concretamente en la parte de análisis estocástico de sistemas en tiempo real. Se trata de un
analizador estocástico de línea de comandos preferentemente de sistemas en tiempo real
ejecutándose sobre monoprocesador, que resuelve el último problema. Proporciona una
información completa acerca de probabilidades sobre missing deadlines, distribución de tiempo
de respuesta, distribuciones backlog, e incluso resultados intermedios del análisis usando sus
opciones de depuración.

Las tareas de ejecución con parámetros, definición del sistema a analizar, supervisión del
análisis y observación de resultados se llevan a cabo respectivamente vía línea de comandos, a
través de la edición de un fichero de texto, o, en los dos últimos casos mediante la consulta de
ficheros de texto y de formato binario. Son métodos poco intuitivos, incómodos, susceptibles a
errores y poco claros.

La aplicación Stochan 0.4 está desarrollada para entornos Windows y Linux en 32 bits.

2.2 Catálogo de Objetivos del EVS.

Estos objetivos dan una visión global de lo que se pretende con el presente proyecto. Para
una especificación más concreta de los requisitos que debe cumplir obligatoriamente este
proyecto se debe acudir al apartado correspondiente de definición de requisitos (Apartado 4).

• En primer lugar se debe permitir ejecutar la aplicación Stochan 0.4 desde el interfaz
con los parámetros deseados.

• El interfaz debe permitir configurar un nuevo sistema para el análisis de manera

cómoda y clara.

7
 • Se debe mantener actualizada la información sobre el progreso del análisis en una
representación gráfica intuitiva.

• El análisis debe poder detenerse en cualquier momento.

• Finalmente, los resultados obtenidos al término del análisis deberán mostrarse por
pantalla también mediante gráficas de probabilidad.

2.3 Catálogo de Requisitos Preliminares.

A continuación se especifican unos requisitos preliminares acerca de la aplicación a
desarrollar. Estos requisitos indicarán los aspectos que el sistema debe cumplir obligatoriamente.

2.3.1 Requisitos funcionales.

• Creación de un fichero de definición del sistema desde la misma interfaz.

• Creación de un fichero de definición del sistema desde un editor de textos escogido

anteriormente.

• Edición del fichero de definición del sistema desde el editor de textos.

• Opción de configurar los parámetros de ejecución de Stochan 0.4.

• Almacenamiento de los parámetros para próximas ejecuciones.

• Posibilidad de ejecutar la aplicación Stochan 0.4 con los parámetros deseados.

• Posibilidad de detener la aplicación.

• Representación gráfica del porcentaje de análisis completado hasta el momento.

• Información acerca de la tarea en curso: tarea actual, hyperperiodo, bdiff, rdiff, maxbdiff,
maxrdiff, operación actual, “current time”, “current job release time”, “current job absolute
deadline”.

• Gráficas de evolución de “Current task backlog difference” (bdiff) y “Current task response
time difference” (rdiff).

• Visualizar durante el transcurso del análisis los parámetros elegidos en la ejecución del
programa Stochan 0.4.

• Representación de los resultados del análisis mediante gráficas de probabilidad.

2.3.2 Requisitos no funcionales.

2.3.2.1 Rendimiento.

• No se especificaron detalles.

8
2.3.2.2 Frecuencia de tratamiento.

• Frecuencia de actualización del análisis adecuada con la evolución del proceso

• No se especificaron más detalles.

2.3.2.3 Requisitos de seguridad.

• No se han especificado.

2.3.2.4 Requisitos especiales

• La aplicación debe ser portable.

2.3.3 Prioridades.
Es importante que el sistema muestre la información lo más actualizada posible, tanto en la
representación de la evolución del proceso como en las gráficas.

9
3 Lista de Usuarios Participantes.

En el presente proyecto se distingue un actor que va a interactuar con la aplicación. Se trata

del usuario que hace uso de la aplicación Stochan 0.4 a través de los ficheros que ésta usa y
genera. Por otra parte aparece la aplicación propiamente dicha.

Creación nuevo sistema

Ejecución y detención del

Stochan 0.4
análisis
Usuario
Consulta de la evolución del
análisis

Consulta de resultados

Figura 1: Usuarios Participantes y Esquema de Tareas

10
4 Descripción del Sistema Actual.

En este apartado se pasa a detallar la situación del sistema en la actualidad.

4.1 Modelo Físico.

Consulta de
resultados

Consulta del
progreso del
análisis

Ejecución de la
Definición del herramienta
sistema

C:> stochan –
dir=”C:\System1”

C:> |

Análisis

Finalización

Figura 2: Diagrama Físico del Sistema Actual

11
12
4.1.1 Descripción del diagrama físico.
En el sistema actual, la aplicación Stochan 0.4 no dispone de interfaz gráfica. Se trata de
una aplicación de consola que dispone de versión para Windows y para Linux.

En el momento de realizar un nuevo análisis, es preciso editar un fichero de texto con las
características del sistema a analizar. Este proceso hay que realizarlo a mano, con el riesgo de
cometer errores introduciendo las variables y los datos.

Una vez establecido el sistema, la ejecución de la aplicación requiere una serie de

parámetros, tanto para la versión para Windows como la versión para Linux. Éstos deben ser
introducidos a mano también por el usuario en el momento de su ejecución por la línea de
comandos.

Cuando la aplicación se pone en marcha, el usuario no tiene constancia de su actividad, ni

del porcentaje de proceso llevado a cabo, ni siquiera de si el analizador está realizando su
trabajo o está bloqueado. Como se explica más a fondo en el anexo, los cálculos realizados por
Stochan 0.4 pueden llevar muchas horas de trabajo.

Periódicamente, la aplicación sobrescribe un fichero de progreso con información acerca de

la evolución del análisis, tarea a tarea. Para consultar la evolución es preciso editar este fichero,
pero solamente es posible obtener una instantánea del progreso del análisis y no una imagen del
proceso global.

Se genera un fichero .log, en el directorio de trabajo, en el que la aplicación va registrando

las actividades que tienen lugar. Desde actividades propias del análisis, hasta eventos de
detención y reanulación del proceso por parte del usuario.

Finalmente, los resultados quedan registrados en los ficheros .dat, en formato binario, que
contienen las tablas-resumen. Para una información más detallada, acudir a la documentación
sobre Stochan 0.4 en el anexo.

13
4.1.2 Ficheros utilizados.
1. system.txt.

Fichero de definición del sistema. Se pueden configurar el número de tareas, la prioridad, el

período, etc.

ntasks = 2

priority = 1
period = 40
phase = 16
maxjitter = 1
deadline = 30
maxbdiff = 1e-4
maxrdiff = 1e-10
exectime =
1 0.5
2 0.5
blocktime =
1 0.25
2 0.75

Figura 3: Fichero system.txt

 ntasks: numero de tareas que componen el sistema.

 priority: prioridad de la tarea.

 period: periodo de la tarea.

 phase: tarea periódica/esporádica.

 maxjitter: jitter máximo de la tarea

 deadline: deadline relativo de la tarea

 maxbdiff: error máximo en el calculo de “steady-state backlog” de la tarea.

 maxrdiff: error máximo en el calculo de “steady-state average response

time” de la tarea.

 exectime: tiempo aleatorio de ejecución de la tarea

 blocktime: tiempo aleatorio de bloqueo de la tarea

14
 2. progress.txt

Fichero de progreso. Durante el análisis este fichero es sobrescrito por Stochan 0.4 con los
valores instantáneos del análisis.

Current analysis = 1; EDF analysis

Number of analyzed tasks = 4
Current task = 3
Current hyperperiod = 7
Current operation = -1 ; Calculation of the
job response time
Current job release time = -1
Current task deadline = -1
Current time = 0
Current task backlog difference = 5.27206e-014
Current task response time difference =
2.65899e-013
Hyperperiod length = 200
Maximum task backlog difference = 2
Maximum task response time difference = 1e-012
First task to analyze = 1
Last task to analyze = 4
Maximum number of hyperperiods = 10
Round mode = 0 ; The analysis is pessimistic
Lowest pessimim = 0
Long double floating point numbers = 0
Number of probability points = 5401216

Figura 4: Fichero progress.txt

 Current análisis: Tipo de análisis.

 Number of analyzed tasks: Numero de tareas analizadas.

 Current task: Tarea actual.

 Current hyperperiod: Hyperperiodo actual.

 Current operation: Operación actual.

 Current job release time: “release time” del trabajo en curso.

 Current task deadline: “deadline” relativo del trabajo actual.

 Current time: tiempo transcurrido del análisis, de acuerdo con el comienzo

del hyperperiodo.

 Current task backlog difference: diferencia entre el “backlog” del comienzo

de este hyperperiodo y del anterior.

15
  Current task response time difference: diferencia entre el tiempo de
respuesta de la tarea en este hyperperiodo y del anterior.

 Hyperperiod length: longitud del hyperperiodo.

 Maximum task backlog difference: parámetro maxbdiff.

 Maximum task response time difference: parámetro maxrdiff

 First task to analyze: primera tarea a analizar.

 Last task to analyze: última tarea a analizar.

 Maximum number of hyperperiods: parámetro nhyper.

 Round mode: parámetro round.

 Lowest pessimim : parámetro lpess.

 Long double floating point numbers: parámetro ldouble.

 Number of probability points: parámetro npoints.

3. log.txt

Fichero de log. En él se escriben los eventos que tienen lugar en la aplicación Stochan 0.4
con su fecha y hora.

The analysis is pessimistic

W and R have 4135168 points available each
(About 50 % of current free memory altogether)
08-31-2006,03:11; The analysis of task 2 starts (2 jobs)
- Umean = 0.7000, Umax = 1.0600
- Number of jobs per hyperperiod = 7
- Average number of execution time points = 6
- Calculating the steady-state backlog
08-31-2006,03:11; * Hyperperiod 0, Bdiff = 6.671239E-001
08-31-2006,03:11; * Hyperperiod 1, Bdiff = 2.847604E-004
- Calculating R
08-31-2006,03:11; * Hyperperiod 6, Rdiff = 2.00E+000
08-31-2006,03:11; * Hyperperiod 7, Rdiff = 1.89E-015
08-31-2006,03:11; The analysis of task 4 starts (1 job)
- Umean = 0.4333, Umax = 0.7000
- Number of jobs per hyperperiod = 1

Figura 5: Fichero log.txt

•Fecha y hora.

•Evento.

16
 4. Ficheros de probabilidad .dat

Ficheros binarios con las tablas de probabilidades que representan los resultados del
análisis. Tienen la siguiente estructura:

 Tamaño de los números en punto flotante.

 Current hyperperiod.

 High priority task.

 High priority job.

 Latest deadline from the hyperperiod start.

 Time from the hyperperiod start.

 Task being processed.

 Job being processed.

 Minimum time.

 Maximum time.

 Truncation.

 Difference.

 Array de probabilidades.

Los ficheros generados tienen el siguiente nombre (donde task es tarea). Para más
información acerca de su contenido, dirigirse al Anexo del documento Memoria.

o prob_miss_deadline-task.dat
o avrg_response_task.dat .
o backlog_task.dat
o response_task.dat
o avrg_response_curr_task.dat

17
4.2 Problemas
A continuación se enumeran los problemas y necesidades encontrados en el sistema actual.

•Ejecución de la aplicación incómoda por tener que introducir parámetros en línea de

comandos.

•Definición del sistema mediante edición de un fichero de texto y susceptible a

errores.

•Imposibilidad de almacenar las opciones para próximas ejecuciones.

•Falta de control sobre la evolución temporal del análisis y sobre la actividad de la

aplicación.

•Ausencia de representaciones gráficas de las variables del análisis durante el

proceso.

•Ausencia de representación gráfica de los resultados, los resultados deben ser

consultados en diversos ficheros binarios a mano.

18
5 Catálogo de Requisitos del Sistema y Prioridades.

5.1 Requisitos funcionales.

Identificador Prioridad Descripción

1.1 1 Creación del fichero de definición del sistema desde la interfaz

mediante un formulario.

1.2 1 Creación del fichero de definición del sistema desde la interfaz

mediante un editor de textos.

1.3 1 Edición del fichero de definición del sistema desde la interfaz.

1.4 1 Edición del fichero de definición del sistema desde un editor de

textos.

1.5 1 Posibilidad de configurar el editor de textos que se desee

1.6 1 Opción de configurar los parámetros de ejecución de Stochan

0.4 de manera visual.

1.7 2 Almacenamiento de los parámetros para próximas ejecuciones

en un fichero de texto.

1.8 1 Posibilidad de ejecutar el análisis desde el interfaz.

1.9 5 Posibilidad de pausar el análisis desde el interfaz.

1.10 1 Posibilidad de detener la aplicación Stochan 0.4

1.11 1 Representación gráfica del porcentaje de análisis completado

hasta el momento.

1.12 1 Información acerca de la tarea en curso: Tarea actual,

hyperperiodo, bdiff, rdiff, maxbdiff, maxrdiff, operación actual,
“current time”, “current job release time”, “current job absolute
deadline”,

1.13 1 Gráficas de evolución de “Current task backlog difference”

(bdiff) y “Current task response time difference” (rdiff).

1.14 1 Visualizar durante el transcurso del análisis los parámetros

elegidos en la ejecución del programa Stochan 0.4

1.15 1 Representación de los resultados del análisis mediante gráficas

de probabilidad.

1.16 1 Posibilidad de ampliar una zona de la gráfica de probabilidad.

19
5.2 Requisitos no funcionales.

5.2.1 Rendimiento.
• No se especificaron detalles.

5.2.2 Frecuencia de tratamiento.

• Frecuencia de actualización del análisis adecuada con la evolución del proceso

• No se especificaron más detalles.

5.2.3 Requisitos de seguridad.

• No se han especificado.

5.2.4 Requisitos especiales

• La aplicación debe ser portable.

5.3 Requisitos relativos al entorno tecnológico.

La aplicación tiene los siguientes requerimientos tecnológicos:

5.3.1 Requisitos hardware.

• Ordenador con arquitectura x86.

• Teclado y ratón.

• Monitor Color SVGA 15’’.

• Tarjeta de vídeo SVGA con 2MB de RAM.

• 5 MB de espacio libre en el disco duro.

5.3.2 Requisitos software.

• Programa Stochan versión 0.4

• Java(TM) 2 Runtime Environment, Standard Edition versión 1.5.0

• Sistema operativo Windows 9X/XP ó Linux.

20
6 Análisis de Alternativas.

6.1 Descripción de Alternativas.

En función de los requisitos planteados y el estudio de la situación actual, se proponen
diversas alternativas de solución. Sobre ellas se valorará cuál es la solución óptima, en base al
impacto de carácter tecnológico y de operación que cada medida supone, así como al contraste
entre costes y beneficios.

6.1.1 Alternativas de Solución.

Se describen a continuación las alternativas de solución propuestas para el presente
proyecto.

Los requerimientos se han especificado de manera muy concreta, el único aspecto en el que
pueden aparecer diferentes alternativas es en el lenguaje de programación en el que se va a
implementar el interfaz gráfico para la aplicación Stochan 0.4.

Alternativas estudiadas:

6.1.1.1 Java

6.1.1.2 C++

6.1.1.3 Phyton

6.1.1.4 C#

6.2 Valoración de Alternativas.

A continuación se evalúan las alternativas descritas en el apartado anterior:

Java es portable, interpretado y orientado a objetos. Es muy sencillo, ya que omite muchas
características complejas como los punteros y la liberación de memoria. Lleva mucho tiempo en
circulación y tiene mucha documentación y librerías ya escritas. Sun proporciona una amplia
documentación sobre todos los paquetes java, además de tutoriales gratuitos.

21
 C++ no es portable, y sí orientado a objetos. Existe código y documentación abundante,
pero su programación es mucho más compleja, ya que incorpora punteros, referencias,
redefinición de tipos, macros y la necesidad de liberar memoria. Al no ser portable habría que
realizar dos versiones compiladas, una para Windows y otra para Linux.

Phyton es un lenguaje portable, interpretado y orientado a objetos, pero mucho menos

potente y extendido que Java y C++. No esta pensado para usarse en grandes proyectos y se
pueden tener problemas a la hora de buscar documentación o código fuente.

C# es un lenguaje orientado a objetos, basado en C++, por lo que no portable. Simplifica el

uso de algunas características de C++ como la inclusión de un liberador de memoria
transparente al programador. El problema es que es muy reciente (2001), y apenas hay
documentación ni tutórales sobre un uso avanzado del mismo. Existiría el mismo problema que
con C++ respecto a su nula portabilidad.

6.3 Descripción de la Alternativa Seleccionada.

A continuación se presenta la solución adoptada para la resolución del problema planteado.
Para ello, se han estudiado, previamente a la resolución final, las valoraciones de las distintas
alternativas posibles. El factor determinante en dicha selección ha sido la evaluación de
prestaciones, la flexibilidad del lenguaje y el cumplimiento por completo de los requisitos
funcionales y no funcionales del sistema.

6.3.1 Alternativa escogida.

La alternativa escogida finalmente ha sido la Alternativa 1: Diseño de un interfaz gráfico
en Java

6.3.2 Características.
• Portabilidad: más allá de la portabilidad por ser de arquitectura independiente, Java
implementa otros estándares de portabilidad para facilitar el desarrollo. Por ejemplo,
los enteros son siempre enteros de 32 bits en complemento a 2. Además, Java
construye sus interfaces de usuario a través de un sistema abstracto de ventanas de
forma que éstas puedan ser implantadas en entornos Linux o Windows.

22
 • Orientado a objetos: Java implementa la tecnología básica de C++ con algunas
mejoras y elimina aspectos concretos para mantener la simplicidad del lenguaje. Java
trabaja con sus datos como objetos y con interfaces a esos objetos. Soporta las tres
características propias del paradigma de la orientación a objetos: encapsulación,
herencia y polimorfismo. Las plantillas de objetos son llamadas, como en C++ clases,
y sus copias, instancias. Estas instancias necesitan ser construidas y destruidas en
espacios de memoria

• Simplicidad: Java ofrece toda la funcionalidad de un lenguaje potente, pero sin las
características menos usadas y más confusas de éstos. Elimina muchas de las
características de otros lenguajes como C++, para mantener reducidas las
especificaciones del lenguaje y añadir características muy útiles como el “garbage
collector”. No es necesario liberar memoria y se limita la fragmentación de la
memoria. Se han eliminado además la aritmética de punteros, las referencias, los
registros, la definición de tipos y las macros.

• Interpretado: El intérprete Java puede ejecutar directamente el código objeto. Enlazar

un programa consume menos recursos que compilarlo. A pesar de que obviamente
Java es más lento que otros lenguajes de programación ejecutados, la situación se
acerca mucho a la de programas compilados, sobre todo en lo que a la rapidez en la
ejecución de código se refiere.

• Multitarea: Java permite realizar muchas actividades simultáneas en un programa (se

puede añadir mas)

6.3.3 Entorno de Desarrollo

Una vez fijado el lenguaje de programación a usar, debemos concretar que entorno de
desarrollo se usara. Alternativas estudiadas:

6.3.3.1 NetBeans

6.3.3.2 JBuilder

6.3.3.3 Eclipse

6.3.4 Elección y valoración de alternativas

23
 Los tres entornos integrados de desarrollo son muy completos y casi idénticos. Con la
salvedad de que el JBuilder es de pago, salvo la versión denominada Foundation, que es una
versión con capacidades básicas para iniciarse en el desarrollo de aplicaciones java y que de
momento es de libre uso. Como tenemos alternativas gratuitas y libres con la funcionalidad
plena, se descarta el JBuilder.

Entre el Eclipse y el NetBeans apenas hay diferencias, en la elección a este nivel ya se ha

de tener en cuenta los gustos del programador, así como su experiencia con los entornos.

En este caso se seleccionó el NetBeans por venir conjuntamente con el JDK de Java, y por
la amplia experiencia en este entorno.

24