Análisis

Metodología

Para realizar el análisis del proyecto, se utiliza UML (Unified Modeling Language).

UML nació de la fusión de las tres principales metodologías de modelización de objetos a mediados de los años 90: OMT (Object Modeling Technique) de James Rumbaugh, Booch de Grady Booch y OOSE (Object-Oriented Software Engineering) de Ivar Jacobson. No se trata sin embargo de una metodología pura sino de un lenguaje gráfico de modelización de sistemas de información, dicho de otro modo de notación o representación gráfica del dominio que se desea modelizar. Esto es tan cierto como que UML no precisa las etapas a seguir, sino cómo realizarlas para pasar de las necesidades de los usuarios al código fuente.

La modelización UML se elabora con un formalismo gráfico y se apoya actualmente en catorce diagramas UML versión 2.4.1. Estos últimos no se utilizan, generalmente, en su totalidad. Su empleo depende del tamaño, la naturaleza y la complejidad del proyecto. Usaremos un número restringido de diagramas para construir la aplicación Oxygen que es un proyecto pequeño clásico de gestión tal y como se definió en el capítulo Presentación del proyecto.

Generalmente, se considera el diagrama de clases como el más importante. Es por lo tanto habitualmente el primer diagrama que los creadores...

Diagrama de casos de uso

Se describen brevemente los diagramas elegidos para el proyecto. Para un estudio más profundo, consulte los libros de tratan sobre UML. Aquí se explica la realización de los mismos con el plug-in Papyrus.

Como se ha subrayado en la sección Metodología, el diagrama de casos de uso es a la vez uno de los más sencillos y uno de los menos utilizados. Numerosos desarrolladores le dan todavía poca importancia. Esto es quizás debido a la herencia de Merise y de la mayor parte de las primeras metodologías de modelización de objetos (antes de la fusión de OMT, OOSE y Booch) para los cuales no existe un equivalente y cuyo elemento principal en cuanto a Merise es el modelo conceptual de los datos, modelo que presenta similitudes con el diagrama de clases.

Se trata con el diagrama de casos de uso de definir las funcionalidades y el comportamiento de la futura aplicación de cara al usuario o de su entorno (otros usuarios, sistemas informáticos externos a la aplicación, autómatas,...). Permite una comprensión común entre el conocimiento del dominio y el conocimiento de realización, dicho de otra forma entre el cliente, ya sea simple usuario o experto, y el desarrollador.

Los casos de uso describen únicamente las interactuaciones...

Diagrama de secuencia

El diagrama de secuencia persigue modelizar el aspecto dinámico del sistema. Se le puede comparar a una storyboard que evidencia las interacciones existentes entre los objetos del sistema. Se pone el acento sobre el orden cronológico de los mensajes emitidos, siendo el eje de tiempo el eje vertical de este diagrama y siendo los primeros mensajes emitidos los situados gráficamente más arriba en el diagrama.

Para cada acción del usuario definida en el diagrama de casos de uso, es conveniente establecer un diagrama de secuencia. Utilizamos la función de lectura de todos los clientes como ejemplo.

Diagrama de clases

Se utiliza el diagrama de clases para modelizar el aspecto estático de un sistema. Pone en evidencia las clases y las relaciones que estas tienen entre ellas: dependencia, asociación, generalización,... Según la importancia del sistema a modelizar, se pueden utilizar diagramas de clases intermediarios, particularmente los diagramas de clases participantes que describen para cada caso de uso las tres principales clases de análisis y sus relaciones (consulte la sección Metodología).

Según la metodología elegida, es (por fin) posible llegados a este punto construir el diagrama de clases. Debe contener las clases puestas en evidencia por los objetos presentes en los diagrama de secuencia y de comunicación así como las que eventualmente faltan, necesarias para el funcionamiento de las maquetas (consulte el capítulo Maquetas).

En función de las necesidades, otras clases pueden aparecer desde el análisis y/o al realizar el primer juego de maquetas. Por ejemplo se puede añadir una clase gráfica adicional surgida de las maquetas si se desea mostrar el conjunto de registros a guardar de una consulta SQL en una nueva ventana. Maquetas y diagramas pueden así interactuar para llegar lo antes posible a lo esencial de las clases...