5.3.2.
El análisis según OMT
Una vez acabados los modelos, se contrastó con OMT los modelos realizados,
refinándolos hasta comprobar que todo el análisis estaba finalizado.
Con el modelo de objetos corresponden los siguientes diagramas UML:
- Diagramas de clases.
En él se muestran las clases y sus interrelaciones. Este diagrama se puede ver
en el apartado 3.6. Diagrama de clases del Anexo 2.
Este diagrama de clases se completa con un diccionario de datos que contiene
la descripción de las clases, atributos y métodos, que se puede ver en el
apartado 3.7. Descripción de clases, atributos y métodos del Anexo 2.
En segundo el modelo dinámico, modelado con UML:
- Diagramas de casos de uso
Modela el comportamiento esencial del sistema en términos de interacciones
de agentes externos (actores) que interactúan con el sistema.
Se identificaron distintos actores, según el acceso a los módulos del
programa. Son los siguientes:
Operador Contable Colegiado
Tabla 4: Identificación de actores.
La agrupación jerárquica y su funcionalidad se puede ver en el apartado 2.3.
Características del usuario del Anexo 2.
Los casos de uso se han descrito mediante el modelo propuesto por [Durán y
Bernárdez, 1998] que se puede ver en los apartados 3.1. Diagramas de casos
de uso y en un subapartado de éste Descripción de los casos de uso del Anexo
2.
- Storyboards
Diagramas que muestran las interfaces de aquellos casos de uso que no sean
suficientemente precisos en su representación diagramática.
En Coinfiti los requisitos definidos en listados con casos de uso se prestaban
a ser aclarados con los storyboards que se pueden ver en el apartado 3.3.
Storyboards del Anexo 2.
- Diagramas de secuencia
Muestran las reacciones internas del sistema a los diferentes casos de uso. Se
pueden ver en el apartado 3.5. Diagramas de secuencia del Anexo 2.
Se puede observar que no hay diagramas de estados, y en el diagrama de clases
no aparecen señales, dado que el control de software es dirigido por programa
(dirigido por llamadas a procedimientos).
Por último el modelo funcional, realizado mediante:
- Diagramas de actividad propuestos por UML.
Estos diagramas muestran los procesos computacionales (métodos de las
clases) en términos de actividades a desarrollar.
5.3.3. Aspectos más relevantes del análisis
El objetivo principal del apartado de análisis es la determinación de requisitos software.
Para que la aplicación logre cumplir los requisitos propuestos en análisis es necesario
haber construido un análisis robusto. Como se ha explicado al comienzo de este
apartado, se ha utilizado el lenguaje de modelado UML y la metodología OMT
combinada con [Schneider & Winters, 1999]. OMT se ha utilizado como guía
metodológica para comprobar el cumplimiento de la fase de análisis.
En este apartado no se pretende duplicar los diagramas que se encuentra en el Anexo 2,
sino reflejar la utilidad estos diagramas.
5.3.3.1. Diagramas de casos de uso
Una vez identificados los actores del sistema, y la jerarquía que forman, se observa que
éstos hacen su aparición en los diagramas de casos de uso.
Los diferentes tipos de caso de uso que se presentan en Coinfiti se pueden clasificar en
base a la siguiente topología:
- Casos de uso de mantenimiento. Se encargan de reflejar qué usuario tiene
acceso al alta, baja o modificación de datos de los distintos apartados de la
aplicación: colegiados, trabajos, personas de interés, usuarios y registro.
Este tipo de casos de uso presenta el siguiente aspecto:
Fig. 4: Ejemplo de caso de uso de mantenimiento
- Casos de uso de gestión de pagos. En estos diagramas se observa la
funcionalidad y dependencia (llamadas a otros módulos) que se producen
para obtener la información necesaria para la creación de recibos en soporte
magnético que sean válidos para la entidad bancaria que los trate.
Fig. 5: Ejemplo de caso de uso de gestión de pagos
- Casos de uso de listados. En este tipo de diagramas, como en todo caso de
uso, se muestra la interacción del sistema con el usuario. En este caso en
particular, se modela el proceso de elaboración de listados. Este proceso
(usuario-interfaz) es muy simple, y es el proceso interno el que lleva el mayor
peso.
Fig. 6: Ejemplo de caso de uso de listados
Como este tipo de casos de uso queda un poco oscuro para el cliente, se
realiza otro tipo de diagramas, los storyboards, que se explican a
continuación.
Si se desea ver todo el apartado de diagramas de casos de uso, véase apartado 3.1.
Diagramas de casos de uso del Anexo 2.
5.3.3.2. Storyboards
Como se acaba de comentar, los storyboards son un tipo de diagramas de interfaces que
ayudan a los casos de uso a mostrar al cliente la funcionalidad de la aplicación y por
tanto, ayudan a realizar la verificación de la validez de los requisitos capturados en un
primer momento.
Los storyboards presentan el siguiente aspecto:
Fig. 7: Ejemplo de storyboard
Si se desea ver todos los storyboards realizados, véase apartado 3.3. Storyboards del
Anexo 2.
5.3.3.3. Diagramas de actividad
Los diagramas de actividad definen las operaciones de las clases describiendo el
proceso computacional, es decir, las actividades que se llevan a cabo para realizar una
operación y el orden en el que ocurren.
Igual que ocurren con los diagramas de casos de uso, todos los diagramas de actividad
que tengan la misma semántica tendrán el mismo aspecto. Es decir, el diagrama de
actividad de alta de un colegiado tendrá el mismo aspecto que el diagrama de actividad
de alta de una persona o entidad de interés. Lo mismo ocurrirá con las bajas,
modificaciones, ...
Cabe destacar el diagrama de actividad de gestión de tasas y el de gestión de cuotas,
dado que son procesos computacionalmente complejos. Obsérvese que en la fase de
análisis ya se abordan estos problemas, aunque desde una perspectiva muy abstracta.
Fig. 8: Ejemplo de diagrama de actividad
Si se desea ver el apartado de diagramas de actividad, véase apartado 3.2. Diagramas de
actividad del Anexo 2.
5.3.3.4. Diagramas de secuencia
Los diagramas de secuencia son un tipo de diagramas de interacción en los que se
describe la ordenación temporal de las acciones. Se plantean los diferentes escenarios
que aparecen en los casos de uso indicando que acciones ocurren antes y cuales
después.
Todos los diagramas de secuencia tienen una importancia equiparable en el modelado
de la aplicación. A continuación se muestra un diagrama como ejemplo de su
funcionamiento.
Fig. 9: Ejemplo de diagrama de secuencia
Si se desea ver el apartado de diagramas de secuencia, véase apartado 3.5. Diagramas
de secuencia del Anexo 2.
5.3.3.5. Diagrama de clases
El diagrama de clases es un grafo bidimensional en el que se relacionan todos los
objetos modelados mediante la estructura de clases. Aparecen todas las características,
estructura y comportamiento, de cada clase, así como restricciones oportunas.
Modela, de este modo, las diferentes funcionalidades de la aplicación que le
corresponden a cada subsistema, así como las interrelaciones entre ellos. Además ayuda
a descomponer la complejidad estructural de la aplicación.
Fig. 10: Ejemplo de diagrama de clases total
La figura anterior sólo muestra las clases identificadas, para ver sus métodos y atributos
véase el apartado 3.6. Diagrama de clases del Anexo 2.
