1 Memoria

DOCUMENTO I. MEMORIA

1

ÍNDICE DOCUMENTO I. MEMORIA................................................................................... .1 1 INTRODUCCIÓN.......................................................................... ........................5 1.1 Identificación del proyecto................................................................. .............5 1.2 Visión general del documento................................................... .....................5 2 DESCRIPCIÓN DEL CONTEXTO........................................................................ 6 3 DESCRIPCIÓN DEL PROBLEMA............................................................... .........7 3.1 Herramienta Stochan 0.4............................................................................... .7 3.2 Necesidades................................................................................................ ...8 3.3 Soluciones............................................................................................ ........12 4 DESCRIPCIÓN DEL PROYECTO............................................... .......................13 4.1 Objetivos.............................................................................. ........................13 4.2 Capacidades del producto.................................................................... ........13 4.3 Entorno de implantación........................................................................ .......15 4.3.1 Entorno hardware..................................................................... .............15 4.3.2 Entorno software........................................................... ........................15 4.4 Usuarios del producto.................................................................................. .16 5 ESTRUCTURA DE LA DOCUMENTACIÓN................................... ....................17 6 INFORMACIÓN ADICIONAL.................................................................... ..........18 6.1 Metodología para el desarrollo del proyecto............................................... ..18 6.1.1 Elección de la metodología........................................ ...........................18 6.1.2 Adaptación de la metodología elegida a este proyecto.........................18 6.1.3 Métrica V3....................................................................... ......................19 6.1.4 Notación UML.................................................................................. ......23 6.2 Entorno de desarrollo de la metodología............................................... .......25 6.2.1 Rational Rose............................................................................ ............25 6.3 La Plataforma Java.......................................................... ............................28 6.3.1 Tecnologías Java.......................................................................... .........29 6.3.2 Java Runtime Environment........................................ ...........................29 6.3.3 Máquina Virtual de Java....................................................... .................29 6.3.4 Librerías de Java...................................................................... .............30 6.4 Tecnologías y entorno de desarrollo del software: NetBeans.......................31 7 POSIBLES AMPLIACIONES.................................................................... ..........33 8 GLOSARIO DE TÉRMINOS........................................................ .......................34

2

9 BIBLIOGRAFÍA EMPLEADA.................................................. ...........................36 10 ANEXO I: DOCUMENTACIÓN DE LA HERRAMIENTA STOCHAN 0.4..........37

3

ÍNDICE DE ILUSTRACIONES ILUSTRACIÓN 1: APLICACIÓN STOCHAN 0.4......................................... ............8 ILUSTRACIÓN 2: SYSTEM.TXT........................................................... ..................9 ILUSTRACIÓN 3: PROGRESS.TXT................................................................... ...10 ILUSTRACIÓN 4: FICHEROS DE RESULTADO EN HEXADECIMAL (.DAT)......11 ILUSTRACIÓN 5: CREACIÓN DEL FICHERO DE DEFINICIÓN DEL SISTEMA. 13 ILUSTRACIÓN 6: CONFIGURACIÓN DE LAS OPCIONES.................................14 ILUSTRACIÓN 7: VISUALIZACIÓN DEL PROGRESO........................................14 ILUSTRACIÓN 8: GRÁFICAS BDIFF Y RDIFF................................................. ....14 ILUSTRACIÓN 9: GRÁFICAS DE PROBABILIDAD........................................... ..15 ILUSTRACIÓN 10: PROCESO DE MÉTRICA V3.................................................20 ILUSTRACIÓN 11: SÍMBOLO DE UML...................................... ..........................23 ILUSTRACIÓN 12: LOGOTIPO DE RATIONAL ROSE....................................... ..26 ILUSTRACIÓN 13: LOGOTIPO DE RATIONAL ROSE....................................... ..28

4

1 Introducción 1.1 Identificación del proyecto

Titulo:

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

Director:

real 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 pretende dar una visión general del proyecto a desarrollar, concretando cuáles han sido los motivos o problemas por los que ha surgido, cuál es el ámbito en el que se encuentra y cuáles son sus principales características. Para concluir describe la metodología empleada y el entorno de desarrollo elegido.

5

2

Descripción del contexto El presente proyecto se encuadra dentro de la materia de Investigación

Operativa. La investigación operativa (también conocida como Investigación de Operaciones), es una rama de las Matemáticas consistente en el uso de modelos matemáticos, estadística y algoritmos con objeto de realizar un proceso de toma de decisiones. Frecuentemente, trata el estudio de complejos sistemas reales, con la finalidad de mejorar (u optimizar) el funcionamiento del mismo. Es una moderna disciplina científica que se caracteriza por la aplicación de teoría, métodos y técnicas especiales, para buscar la solución de problemas de administración, organización y control que se producen en los diversos sistemas que existen en la naturaleza y los creados por el ser humano, tales como las organizaciones diversas a las que identifica como sistemas organizados, sistemas físicos, económicos, ecológicos, educacionales, de servicio social, etc. El objetivo más importante de la aplicación de la Investigación Operativa es apoyar en la “toma óptima de decisiones” en los sistemas y en la planificación de sus actividades. El enfoque fundamental de la Investigación Operativa es el enfoque de sistemas, por el cual, a diferencia del enfoque tradicional, se estudia el comportamiento de todo un conjunto de partes o subsistemas que interaccionan entre sí, se identifica el problema y se analizan sus repercusiones, buscándose soluciones integrales que beneficien al sistema como un todo. Para hallar la solución, la Investigación Operativa generalmente representa el problema como un modelo matemático, que es analizado y evaluado previamente. En el caso que nos ocupa, se aplica esta materia, más concretamente el análisis estocástico, al análisis de sistemas en tiempo real.

6

3 Descripción del problema 3.1 Herramienta Stochan 0.4 La herramienta Stochan 0.4 es una aplicación software portable dirigida a investigadores y desarrolladores de sistemas en tiempo real que desean aplicar el análisis estocástico a un sistema en tiempo real. Actualmente, muchos sistemas en tiempo real son diseñados y teóricamente testeados usando el peor caso posible en el tiempo de ejecución de las tareas, con lo que introducen el mayor grado de pesimismo. Como resultado, la implementación final resulta excesivamente pesada (robusta), lo que incrementa el coste. El análisis estocástico de sistemas en tiempo real es una nueva técnica de análisis que usa modelos de tiempo de computación como variables aleatorias, mejorando enormemente el clásico análisis de los sistemas en tiempo real que consideran el tiempo de ejecución como una única variable (el tiempo de ejecución en el peor caso). No obstante, el análisis estocástico sugiere dos problemas: •

Requiere distribuciones aleatorias de tiempo de ejecución de tareas, que son difíciles de obtener en la práctica.

•

El análisis estocástico cuando se aplica a problemas no triviales es tedioso y propenso a errores, incluso con la ayuda de paquetes de propósito matemático.

Stochan 0.4 es 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. Ha sido diseñado para que el análisis pueda ser interrumpido y poder continuarlo en cualquier momento., puesto que el análisis estocástico de sistemas complejos en tiempo real puede requerir varias horas, o incluso días. Gracias a esta característica es posible comenzar un análisis, interrumpirlo y observar los resultados iniciales y cambiar algún parámetro sin perder el tiempo de análisis.

7

La versión actual de Stochan es 0.4, la cual básicamente implementa el análisis de tareas independientes y periódicas programadas usando principalmente EDF y/o prioridades organizadas (fixed priorities) en monoprocesadores. Además, cubre extensiones típicas tales como recursos compartidos, secciones no preferentes, retraso variable en la activación y tareas esporádicas.

3.2 Necesidades Tras el análisis cuidadoso de la aplicación se han detectado las siguientes necesidades: 

Ejecución de la aplicación incómoda: al tratarse de una aplicación en línea de comandos, se han de escribir los parámetros adecuados para indicar el directorio de trabajo, el modo de depuración, el rango de tareas a analizar, etc. Existe la posibilidad de interrumpir proceso con CTRL + C, y posteriormente reanudarlo.

(pantalla con la consola y el Stochan) Ilustración 1: Aplicación Stochan 0.4



Definición del sistema a analizar poco intuitiva y sensible a errores: la aplicación Stochan 0.4 inicialmente recibe la entrada de un archivo llamado system.txt, que ha de ser creado manualmente de forma independiente del programa. Cualquier mínimo error en el fichero provoca un error.

8

Ilustración 2: System.txt



Seguimiento del progreso del análisis: si se desea visualizar el proceso de análisis se debe recurrir al archivo progress.txt correspondiente y abrirlo con un editor de textos. La información mostrada no es muy clara y se puede tardar mucho en discernir qué es lo que esta ocurriendo en ese instante. Además no se puede obtener una imagen de la evolución real del progreso. Tampoco es posible saber si la aplicación está realmente trabajando o se encuentra bloqueada.

9

Ilustración 3: Progress.txt



Consulta de resultados: una vez concluido el análisis si se desea conocer los resultados del mismo, es preciso dirigirse a la carpeta de trabajo, y consultar los ficheros de extensión .dat generados, con formato binario que aparecen a continuación. Los dos últimos solamente son generados en caso de que el análisis haya sido interrumpido mediante CTRL+C. Estos ficheros no son editables, es preciso o bien abrirlos con un editor hexadecimal y traducir los valores en punto flotante (norma IEEE-754) o bien implementar un lector que lea los archivos binarios. Evidentemente es una tarea muy costosa de cualquiera de las dos maneras y es una desventaja enorme no poder consultar los resultados obtenidos de forma directa se esté donde se esté. Además, los datos se proporcionan en forma de tabla, con lo que es muy complicado sacar conclusiones de los resultados. 10

-

prob_miss_deadline-task.dat para cada tarea.

-

avrg_response_task.dat para cada tarea.

-

backlog_task.dat para cada tarea.

-

response_task.dat para cada tarea.

-

avrg_response_curr_task.dat para cada tarea.

Ilustración 4: Ficheros de resultado en hexadecimal (.dat)

11

3.3 Soluciones Tras las necesidades detectadas con el uso de la aplicación, se han encontrado las siguientes soluciones: 

Creación de un interfaz gráfico que permita lanzar la aplicación e introducir los parámetros de ejecución de manera visual a través de un formulario. La ejecución debe poder ser detenida también. La opción de borrar los datos del análisis, por si queremos reiniciarlo, también se implementara en la interfaz, librando así al usuario de recurrir a la utilidad incluida en el Stochan 0.4 rmanl.



Posibilidad de crear el archivo de definición del sistema de manera intuitiva mediante un formulario, evitando de esta manera errores y además facilitando la tarea al usuario.



Para facilitar la comprensión y visionado del progreso del análisis la interfaz mostrará una ventana con barras de progreso y varias gráficas, que ayudaran a comprender como va el análisis, y así ver si se quiere cambiar algún parámetro, para lo cual se pararía el análisis.



Finalmente, para facilitar la consulta de resultados, la interfaz creará una serie de ventanas que presentarán la información de forma clara y concisa, mediante gráficas de probabilidad.

12

4 Descripción del proyecto 4.1 Objetivos El presente proyecto surge de la necesidad de dotar a la aplicación Stochan 0.4 de un interfaz gráfico que permita la ejecución del análisis de manera cómoda. Los objetivos podrían resumirse en los siguientes: •

Para empezar, se debe permitir ejecutar y detención de 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.

•

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 pausarse en cualquier momento y ser retomado posteriormente de manera sencilla.

•

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

4.2 Capacidades del producto A continuación se enumeran las capacidades del presente proyecto: 

Posibilidad de lanzar la aplicación Stochan 0.4 y de detenerla.

•

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

(pantalla del formulario para crear) Ilustración 5: Creación del fichero de definición del sistema

13

•

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 la interfaz.

•

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.

(pantalla de opciones) Ilustración 6: Configuración de las opciones

•

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

•

Posibilidad de pausar el análisis.

•

Posibilidad de reanudar el análisis.

•

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

(pantalla de progreso) Ilustración 7: Visualización del progreso

•

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).

(graficas) Ilustración 8: Gráficas Bdiff y Rdiff

14

•

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.

(graficas) Ilustración 9: Gráficas de probabilidad

.

4.3 Entorno de implantación 4.3.1 Entorno 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.

4.3.2 Entorno 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.

15

4.4 Usuarios del producto Esta aplicación está orientada principalmente a investigadores y desarrolladores de sistemas en tiempo real que quieran utilizar el análisis estocástico para el estudio de sistemas en tiempo real.

16

5 Estructura de la documentación La documentación del proyecto está estructurada de la siguiente manera: en primer lugar, el presente documento, Memoria, resume brevemente los objetivos del proyecto, las capacidades del producto a desarrollar, y proporciona información adicional para la comprensión del resto de documentos y del contexto del problema. En segundo lugar, en el documento Presupuesto se detallan los gastos de desarrollo e implantación del presente proyecto. En tercer lugar, se encuentra el Estudio de Viabilidad del Sistema, donde se evalúan los requerimientos del producto. A continuación, en el Análisis del Sistema de Información, se planifica la estructura de la aplicación a partir del estudio de los casos de uso. En el documento Diseño del Sistema de Información se especifica el diseño de dichos casos de uso y se desarrolla un plan de pruebas. Finalmente, como productos del proceso de construcción del sistema de información se ha redactado un Manual del Usuario y se incluye el Código Fuente íntegro del programa.

17

6 Información adicional 6.1 Metodología para el desarrollo del proyecto 6.1.1 Elección de la metodología La metodología elegida para el desarrollo de este proyecto ha sido Métrica Versión 3 en su vertiente orientada a objetos, que utiliza Unified Modeling Language (UML) para modelar el diseño de aplicaciones. Se ha elegido esta metodología debido a su amplia utilización y su flexibilidad y por ser una metodología válida para proyectos basados en programación orientada a objetos.

6.1.2 Adaptación de la metodología elegida a este proyecto Una de las partes más importantes de la metodología es precisamente el cómo adaptarla al proyecto en cuestión ya que se trata de una metodología genérica y cada proyecto tiene sus particularidades. Métrica V3 está metodología pensada para poder ser implantada en grandes empresas con multitud de proyectos, multitud de analistas, programadores, testadores, directores de proyectos, etc. Por tanto, se debe hacer un estudio de las características de este proyecto y la metodología debe adaptarse a su •

Una única persona ejercerá las funciones de analista y programador.

•

Una única persona ejercerá las funciones de dirección del proyecto y esta persona no podrá dedicarse a tiempo completo a esta tarea.

•

Se trata de un proyecto de tamaño pequeño.

Con todo ello se llega a la conclusión de que se necesita simplificar toda la metodología Métrica V3 eliminando pasos, etapas, documentos, etc. que no harían sino complicar inútilmente el desarrollo del proyecto. Ante todo se busca una metodología efectiva. Para realizar esta simplificación ha sido necesario sin embargo, llegar a conocer con detenimiento la metodología en su totalidad. A continuación se hará un resumen de las principales características de Métrica V3.

18

6.1.3 Métrica V3 Se trata de una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de información promovida por el Ministerio de Administraciones Públicas del gobierno español para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el Modelo de Procesos del Ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination) Pretende establecer un conjunto de tareas a realizar, técnicas y productos a obtener para desarrollar sistemas de información con una mayor calidad, productividad y satisfacción de los usuarios y para facilitar su mantenimiento posterior.

6.1.3.1 Procesos principales de Métrica V3 Al igual que ISO/IEC 12207, MÉTRICA está orientada al proceso y, en su versión 3, estos procesos son: •

Planificación de Sistemas de Información (PSI).

•

Desarrollo de Sistemas de Información (DSI). Debido a su complejidad, está a su vez dividido en cinco procesos:

•

o

Estudio de Viabilidad del Sistema (EVS).

o

Análisis del Sistema de Información (ASI).

o

Diseño del Sistema de Información (DSI).

o

Construcción del Sistema de Información (CSI).

o

Implantación y aceptación del Sistema (IAS).

Mantenimiento de Sistemas de Información (MSI).

19

Ilustración 10: Proceso de Métrica V3

6.1.3.2 PSI (Plan de Sistemas de Información) Objetivo: obtener un marco de referencia para el desarrollo de SI que responda a los objetivos estratégicos de la organización: •

Descripción crítica de la situación actual

•

Arquitectura de la información de alto nivel

•

Propuesta de proyectos (con prioridades)

•

Propuesta de calendario y estimación de recursos

Para ello se llevan a cabo las siguientes tareas: •

Se estudian las necesidades de información de los procesos de la organización

•

Se definen los requisitos generales

•

Se obtienen modelos conceptuales de información y de SI

•

Se evalúan las opciones tecnológicas y se propone un entorno 20

•

Se elabora un calendario de proyectos

•

Se planifican en detalle los proyectos más próximos

•

Se mantiene actualizado el PSI

6.1.3.3 EVS (Estudio de Viabilidad del Sistema) El objetivo de este documento es analizar las necesidades y proponer una solución a corto plazo, basada en criterios económicos, técnicos, legales y operativos. La solución consiste en definir uno o varios proyectos que afectan a uno o varios SI ya existentes o nuevos. •

Se identifican los requisitos que se han de satisfacer.

•

Se estudian los requisitos que se han de satisfacer y, si procede, la situación actual.

•

Se plantean alternativas de solución: soluciones a medida, soluciones basadas en productos software del mercado o soluciones mixtas.

•

Para cada alternativa se debe valorar impacto en la organización, la inversión a realizar, y los riesgos asociados

•

Evaluar las distintas alternativas y seleccionar la solución más adecuada

Si la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y existe una alternativa clara, este proceso se orienta a la especificación de requisitos, descripción del nuevo sistema y planificación.

6.1.3.4 ASI (Análisis del Sistema de Información) El objetivo de este documento es obtener una especificación detallada del SI, y de sus interfaces con otros sistemas, que satisfaga las necesidades de información de los usuarios y sirva de base para el diseño. •

Integra las actividades de análisis estructurado y OO.

•

Se refinan los productos obtenidos en el proceso EVS.

21

6.1.3.5 DSI (Diseño del Sistema de Información) Se busca el objetivo de obtener una especificación de la construcción del sistema: •

Definición de la arquitectura del sistema

•

Definición del entorno tecnológico

•

Especificación detallada de los componentes del SI

•

Especificación técnica del plan de pruebas

•

Definición de los requisitos de implantación

•

Diseño de los procedimientos de migración y carga inicial (cuando proceda)

6.1.3.6 CSI (Construcción del Sistema de Información) El objetivo es codificar y probar los componentes del SI, y escribir los manuales de usuario y de explotación. •

Se realizan las pruebas unitarias, de integración y de sistema.

•

Todavía faltan las de implantación y aceptación

•

Se construyen los procedimientos de migración y carga inicial de datos, si procede.

6.1.3.7 IAS (Implantación y Aceptación del Sistema) El objetivo es la entrega y aceptación del sistema en su totalidad y la realización de las actividades necesarias para el paso a producción: •

Se prepara el entorno de explotación

•

Se instalan los componentes

•

Se activan los procedimientos manuales y automáticos 22

•

Se realiza la migración o carga inicial de datos

•

Se realiza la prueba de implantación

•

Se realiza la prueba de aceptación

•

Se prepara el mantenimiento.

•

Es muy común que desarrollo y mantenimiento sean realizados por grupos distintos

6.1.3.8 MSI (Mantenimiento del Sistema de Información) El objetivo es obtener una nueva versión de un SI a partir de las peticiones de mantenimiento de los usuarios.

6.1.4 Notación UML El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; aún cuando todavía no es un estándar oficial, está apoyado en gran manera por el OMG (Object Management Group).

Ilustración 11: Símbolo de UML

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

23

El punto importante para notar aquí es que UML es un "lenguaje" para especificar y no un método o un proceso. UML se usa para definir un sistema de software; para detallar los artefactos en el sistema; para documentar y construir -es el lenguaje en el que está descrito el modelo. UML se puede usar en una gran variedad de formas para soportar una metodología de desarrollo de software (tal como el Proceso Unificado de Rational) -pero no especifica en sí mismo qué metodología o proceso usar. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. En UML 2.0 hay 13 tipos de diagramas. Para comprenderlos, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha. Diagramas de estructura enfatizan en los elementos que deben existir en el sistema modelado: •

Diagrama de clases

•

Diagrama de componentes

•

Diagrama de objetos

•

Diagrama de estructura compuesta (UML 2.0)

•

Diagrama de despliegue

•

Diagrama de paquetes

Diagramas de comportamiento enfatizan en lo que debe suceder en el sistema modelado: •

Diagrama de actividades

•

Diagrama de casos de uso

•

Diagrama de estados

Diagramas de Interacción, un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: •

Diagrama de secuencia 24

•

Diagrama de comunicación

•

Diagrama de tiempos (UML 2.0)

•

Diagrama de vista de interacción (UML 2.0)

A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente, o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado...

Modelo E/R Vistas Externas DFD DFI HVE Diagrama de Clases Casos de uso Diagramas de colaboración

X X

M. Dinámico

M. Estático

Unified

OMT/OORAAM

Técnica o artefacto

Métrica OO

Merise

SSADM

Método

Elementos utilizados en los métodos

X X

X

X X X

X X X X X

X X X

X X X

X X X

Tabla 1: Comparativa de metodologías

6.2 Entorno de desarrollo de la metodología 6.2.1 Rational Rose Rational Rose 2001 Enterprise pertenece a la familia de productos Rational. Esta familia ofrece al desarrollador de software un conjunto de herramientas para el modelado visual en entornos cliente-servidor, aplicaciones distribuidas (CORBA, RMI, DCOM), entornos con bases de datos y entornos en tiempo real.

25

Ilustración 12: Logotipo de Rational Rose

Rational Rose 2001 Enterprise permite al desarrollador de software crear los gráficos que definen la arquitectura del sistema recogida en el documento SAD. Divide el modelo en las siguientes vistas: •

Vista de Casos de Uso. Define el comportamiento del sistema en términos funcionales, es decir, qué hace el sistema. Emplea los siguientes diagramas: o

Diagrama de casos de uso. Define a los actores, los casos de uso y sus relaciones.

o

Diagrama de actividades. Define las actividades que se llevan a cabo dentro de cada caso de uso para conseguir la funcionalidad que ofrecen a los actores. También son utilizados para explotar actividades en otras actividades más simples y así definir mejor su funcionalidad.

•

Vista Lógica. Define los objetos, su estructura y sus relaciones con el resto de objetos. De esta forma se explica cómo se realizan las funcionalidades descritas en la vista de casos de uso llevadas a cabo por medio de objetos. Emplea los siguientes diagramas: o

Diagramas de casos de uso. Definen la equivalencia entre los casos de uso de la vista de casos de uso y unos casos de uso especiales de esta vista lógica llamados realizaciones, que permitirán obtener los diagramas de interacción, definidos a continuación.

o

Diagramas de interacción. Se dividen en diagramas de secuencia y diagramas de colaboración. Los primeros muestran cómo los objetos se pasan mensajes respecto al tiempo y los segundos simplemente muestran el paso de mensajes en secuencia. Los mensajes se materializan en métodos de los objetos, luego aquí ya se empieza a diseñar el software. 26

o

Diagramas de estado. Definen los numerosos estados por los que pasa cada objeto en función de los mensajes que recibe. Se obtienen a partir de los diagramas de interacción definidos anteriormente.

o

Diagramas de clases. Definen las clases, su estructura (atributos y métodos) y sus relaciones con otros objetos. Los métodos y relaciones se obtienen de los diagramas de interacción.

•

Vista de Procesos. Muestra los componentes que funcionan en el sistema en tiempo de ejecución. Normalmente será un ejecutable (EXE) aunque puede haber librerías de enlace dinámico (DLLs), más ejecutables (EXEs), applets en Java o controles ActiveX (OCXs); dependiendo de la complejidad del sistema. Emplea el siguiente diagrama: o

Diagrama de componentes. Definen los componentes que existirán en el sistema en tiempo de ejecución, normalmente un ejecutable.

•

Vista de Implementación. Muestra la equivalencia entre los objetos y los ficheros de código que los implementen. Normalmente en C++ la equivalencia es una a una. Emplea el siguiente diagrama: o

Diagrama de componentes. Definen los componentes, que son la equivalencia a un fichero que implementa un determinado objeto.

•

Vista de Distribución. Muestra los elementos de proceso (procesadores) necesarios para ejecutar los componentes definidos en la vista de procesos, junto a los procesos que ejecutarán.

Rational Rose, a partir del modelo construido con las vistas anteriores que definen la arquitectura del software, es capaz de generar código Visual Basic, Visual C++, ANSI C++, IDL y DDL y hacer el proceso contrario o ingeniería inversa, para obtener el modelo a partir de código ya escrito

27

6.3 La Plataforma Java La plataforma Java es el nombre de un entorno o plataforma de computación originaria de Sun Microsystems, capaz de ejecutar aplicaciones desarrolladas usando el Lenguaje de programación Java y un conjunto de herramientas de desarrollo. En este caso, la plataforma no es un hardware específico o un sistema operativo, sino más bien una máquina virtual encargada de la ejecución, y un conjunto de librerías estándar que ofrecen funcionalidad común.

Ilustración 13: Logotipo de Rational Rose

La plataforma es así llamada la Plataforma Java (antes conocida como Plataforma Java 2[1]), e incluye: 1

Plataforma Java, Edición Estándar (Java Platform, Standard Edition), o Java SE (antes J2SE)

2

Plataforma Java, Edición Empresa (Java Platform, Enterprise Edition), o Java EE (antes J2EE)

3

Plataforma Java, Edición Micro (Java Platform, Micro Edition), o Java ME (antes J2ME) Desde 2006, la versión actual de la Plataforma Java se conoce tanto por versión

1.5 o versión 5, aunque todas las denominaciones se refieren a la misma versión. Sin embargo, se prefiere el término versión 5. Una visión general de la multitud de tecnologías que componen la Plataforma Java puede encontrarse en la página de documentación del JDK.

28

6.3.1 Tecnologías Java La Plataforma Java se compone de un amplio abanico de tecnologías, cada una de las cuales ofrece una parte del complejo de desarrollo o del entorno de ejecución en tiempo real. Por ejemplo, los usuarios finales suelen interactúan con la máquina virtual de Java y el conjunto estándar de librerías. Además, las aplicaciones Java pueden usarse de forma variada, como por ejemplo ser incrustadas en una página Web. Para el desarrollo de aplicaciones, se utiliza un conjunto de herramientas conocidas como JDK (Java Development Kit, o herramientas de desarrollo para Java).

6.3.2 Java Runtime Environment Un programa destinado a la Plataforma Java necesita dos componentes en el sistema donde se va a ejecutar: una máquina virtual de Java (JVM), y un conjunto de librerías para proporcionar los servicios que pueda necesitar la aplicación. La JVM que proporciona Sun Microsystems, junto con su implementación de las librerías estándar, se conocen como Java Runtime Environment (JRE) o Entorno en tiempo de ejecución para Java. El JRE es lo mínimo que debe contener un sistema para poder ejecutar una aplicación Java sobre el mismo. Para el desarrollo de programas se ofrece un paquete de utilidades y herramientas conocido como JSDK (Java Software Development Kit).

6.3.3 Máquina Virtual de Java El corazón de la Plataforma Java es el concepto común de un procesador “virtual” que ejecuta programas escritos en el lenguaje de programación Java. En concreto, ejecuta el código resultante de la compilación del código fuente, conocido como bytecode. Este “procesador” es la máquina virtual de Java o JVM (Java Virtual Machine), que se encarga de traducir (interpretar o compilar al vuelo) el bytecode en instrucciones nativas de la plataforma destino. Esto permite que una misma aplicación Java pueda ser ejecutada en una gran variedad de sistemas con arquitecturas distintas, siempre que con una implementación adecuada de la JVM. Este hecho es lo que ha dado lugar a la famosa frase: “write once, run anywhere” (escribir una vez, ejecutar en cualquier parte).

29

Desde la versión 1.2 de JRE, la implementación de la máquina virtual de Sun incluye un compilador JIT (Just In Time). De esta forma, en vez de la tradicional interpretación del código bytecode, que da lugar a una ejecución lenta de las aplicaciones, el JIT convierte el bytecode a código nativo de la plataforma destino. Esta segunda compilación del código penaliza en cuanto a tiempo, pero el código nativo resultante se ejecuta de forma más eficaz y rápida que si fuera interpretado. Otras técnicas de compilación dinámica del código durante el tiempo de ejecución permiten optimizar más aún el código, dejando atrás la losa que sobre Java caía en cuanto a su lentitud. Sin embargo, no puede decirse que el resultado de la compilación de Java pueda compilar el código con un máximo de eficiencia, y aprovechar los beneficios en cuanto a velocidad de código máquina nativo. Aunque los compiladores cada vez son más avanzados, no todas las librerías de Java tienen asociado un código máquina equivalente que aprovechar. Por ejemplo, la librería “reflect”, que permite a los programadores de Java explorar instrucciones que sólo están disponibles en tiempo de ejecución, está pobremente representado por código máquina. Java no fue la primera plataforma basada en el concepto de una máquina virtual, aunque es la que de más amplia difusión ha gozado. El empleo de máquinas virtuales se había centrado principalmente en el uso de emuladores para ayudar al desarrollo de hardware en construcción o sistemas operativos, pero la JVM fue diseñada para ser implementada completamente en software, y al mismo tiempo hacer que fuera portable a todo tipo de hardware.

6.3.4 Librerías de Java En la mayoría de los sistemas operativos actuales, se ofrece una cantidad de código para simplificar la tarea de programación. Este código toma la forma, normalmente, de un conjunto de librerías dinámicas que las aplicaciones pueden llamar cuando lo necesiten. Pero la Plataforma Java está pensada para ser independiente del sistema operativo subyacente, por lo que las aplicaciones no pueden apoyarse en funciones dependientes de cada sistema en concreto. Lo que hace la Plataforma Java, es ofrecer un conjunto de librerías estándar, que contiene mucha de las funciones reutilizables disponibles en los sistemas operativos actuales.

30

Las librerías de Java tienen tres propósitos dentro de la Plataforma Java. Al igual que otras librarías estándar, ofrecen al programador un conjunto bien definido de funciones para realizar tareas comunes, como manejar listas de elementos u operar de forma sofisticada sobre cadenas de caracteres. Además, las librerías proporcionan una interfaz abstracta para tareas que son altamente dependientes del hardware de la plataforma destino y de su sistema operativo. Tareas tales como manejo de las funciones de red o acceso a ficheros, suelen depender fuertemente de la funcionalidad nativa de la plataforma destino. En el caso concreto anterior, las librerías java.net y java.io implementan el código nativo internamente, y ofrecen una interfaz estándar para que aplicaciones Java puedan ejecutar tales funciones. Finalmente, no todas las plataformas soportan todas las funciones que una aplicación Java espera. En estos casos, las librerías bien pueden emular esas funciones usando lo que esté disponible, o bien ofrecer un mecanismo para comprobar si una funcionalidad concreta está presente.

6.4 Tecnologías

y

entorno

de

desarrollo

del

software:

NetBeans NetBeans es una plataforma para el desarrollo de aplicaciones de escritorio usando Java y a un Entorno integrado de desarrollo (IDE) desarrollado usando la Plataforma NetBeans. La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de un conjunto de componentes de software llamados módulos. Un módulo es un archivo Java que contiene clases de java escritas para interactuar con las APIs de NetBeans y un archivo especial (manifest file) que lo identifica como módulo. Las aplicaciones construidas a partir de módulos pueden ser extendidas agregándole nuevos

módulos.

Debido

a

que

los

módulos

pueden

ser

desarrollados

independientemente, las aplicaciones basadas en la plataforma NetBeans pueden ser extendidas fácilmente por otros desarrolladores de software. NetBeans comenzó en 1997 como Xelfi, un impresionante proyecto estudiantil bajo la tutoría de la Facultad de Matemáticas y Física en la Universidad de Charles en Praga. Una compañía fue formada posteriormente en torno al proyecto, la cual produjo versiones comerciales del IDE NetBeans hasta que fue comprado por Sun Microsystems en 1999. Sun dejó el proyecto como open-source en Junio del año siguiente. La comunidad de NetBeans desde ese año continuó creciendo, gracias a personas y compañías que usan y contribuyen al proyecto. 31

La Plataforma NetBeans es un framework reusable que simplifica el desarrollo de otras aplicaciones de escritorio. Cuando se ejecuta una aplicación basada en la Plataforma NetBeans, la plataforma ejecuta la clase Main. Los módulos disponibles están localizados y puestos en un registro en memoria, y son ejecutadas las tareas de inicialización de los módulos. Generalmente el código de un módulo es cargado en memoria solo cuando se necesita. La plataforma ofrece servicios comunes a las aplicaciones de escritorio, permitiéndole al desarrollador enfocarse en la lógica específica de su aplicación. Entre las características de la plataforma están: •

Administración de las interfases de usuario (Ej. menús y barras de herramientas)

•

Administración de las configuraciones del usuario

•

Administración del almacenamiento (guardando y cargando cualquier tipo de dato)

•

Administración de ventanas

•

Framework basado en asistentes (diálogos paso a paso)

El IDE NetBeans es un IDE escrito completamente en Java usando la plataforma NetBeans. La versión actual es NetBeans IDE 5.0, la cual fue lanzada en Febrero de 2006. Todas las funciones del IDE son provistas por módulos. Cada módulo provee una función bien definida, tales como el soporte de Java, edición, o soporte para el sistema de control de versiones. NetBeans contiene todos los módulos necesarios para el desarrollo de aplicaciones Java en una sola descarga, permitiéndole al usuario comenzar a trabajar inmediatamente. Sun Studio, Sun Java Studio Enterprise, y Sun Java Studio Creator de Sun Microsystems han sido todos basados en el IDE NetBeans. El IDE NetBeans está licenciado bajo la SPL (Sun Public Licence).

32

7 Posibles ampliaciones ¿?

33

8 Glosario de términos J2RE

Java 2 Runtime Environment

J2SE

Java 2 Standard Edition

J2EE

Java 2 Enterprise Edition

JSDK

Java Servlet Development Kit

JIT

Just In Time

JVM

Java Virtual Machine

JDK

Java Development Kit

IDE

Integrated Development Environment

SPL

Sun Public License

OO

Object Orientated

OMG

Object Management Group

SI

Sistema de Información

UML

Unified Modeling Language

PSI

Plan de Sistemas de Información

EVS

Estudio de Viabilidad del Sistema

ASI

Análisis del Sistema de Información

DSI

Diseño del Sistema de Información

CSI

Construcción del Sistema de Información 34

IAS

Implantación y Aceptación del Sistema

MSI

Mantenimiento del Sistema de Información

DFD

Data Flow Diagram

SSADM

Structured Systems Analysis & Design Methodology

OMT

Object Modeling Technique

CORBA

Common Object Request Broker Architecture

RMI

Remote Method Invocation

DCOM

Distributed Component Object Model (Microsoft)

DLL

Dynamic Link Library

EXE

Executable (File Name Extension)

OCXs

OLE Control Extension

35

9 Bibliografía empleada •

JAVA 2. MANUAL DE USUARIO Y TUTORIAL, 4ª EDICIÓN ACTUALIZADA A LA VERSIÓN J2SE 5. Froufe, Agustín. (Ra-ma)

•

PROGRAMACIÓN EN JAVA 2. SERIE SCHAUM Sánchez Allende, Jesús; Huecas Fernández-Toribio, Gabriel;Fernández Manjón, Baltasar & Moreno Díaz, Pilar (Editorial McGraw-Hill)

•

NetBeans: The Definitive Guideby Tim Boudreau, Jesse Glick, Simeon Greene, Vaughn Spurlin, Jack J. Woehr April, 2004

36

10 ANEXO I: Documentación de la herramienta Stochan 0.4

37