Integración de UML en la
metodología MÉTRICA
Departamento de Ciencias de
la Computación, Universidad de Alcalá
{joser.hilera,
josej.martinez, salvador.oton, josea.gutierrez}@alcala.es
Resumen. Se propone una forma de integración de las técnicas de modelado orientado
a objetos establecidas por el estándar UML (Unified Modeling Language) en la
metodología estructurada MÉTRICA v2.1, sustituyendo los modelos estructurados
que exige realizar esta metodología por los de UML, con el objetivo de adaptar
MÉTRICA al enfoque de la orientación a objetos, y facilitar su aplicación en el
caso de proyectos de desarrollo de Sistemas de Información en los que se
utiliza un lenguaje de programación orientado a objetos como Java o C++. Esta
integración se realiza a nivel de actividades del ciclo de vida de la
metodología, y repercute en la estructura de la documentación que, según
MÉTRICA, debe generarse al final de cada fase.
1 Introducción
Desde mediados de los años
ochenta se ha venido imponiendo gradualmente la tecnología de objetos en el
ámbito de la producción de software, aplicándose primero el enfoque de la
orientación a objetos en la construcción de programas, e incorporándose después
en el resto de actividades del ciclo de vida del software, como la
planificación, el análisis o el diseño.
Esta tecnología permite
aumentar la productividad y mejorar la calidad del software, constituyendo, las
metodologías orientadas a objetos, un marco idóneo para abordar la complejidad
creciente en el desarrollo de software, gracias a sus modelos más realistas y
consistentes, dando lugar a productos más flexibles y fáciles de mantener y
reutilizar.
Actualmente existe una
multitud de métodos de desarrollo orientados a objetos, con la característica
común de basarse en los mismos conceptos fundamentales de esta tecnología, pero
con diferencias en la notación utilizada en los modelos de análisis y diseño
propuestos y en la forma de introducir la orientación a objetos en el ciclo de
vida del software.
Las razones del cambio
desde el enfoque estructurado al enfoque orientado a objetos (OO) se refieren
principalmente a la mejora de la productividad, de la calidad y del mantenimiento del software
desarrollado que ofrece esta nueva tecnología, y su mejor adaptación a las
nuevas características de las aplicaciones informáticas que requiere el
mercado, como las interfaces gráficas de usuario o el procesamiento distribuido
(por ejemplo, a través de Internet) basado en la filosofía cliente/servidor.
Otro aspecto del enfoque
OO que lo hace adecuado para garantizar la calidad de los productos si se
aplica desde las primeras fases de los proyectos es su capacidad para modelar
los requisitos de los usuarios de una forma muy intuitiva. En este sentido, la
gran ventaja que está suponiendo la OO como paradigma de ingeniería del
software es precisamente que este enfoque se aplica, tanto en las etapas de
análisis y diseño, como en la construcción o programación del software,
convirtiéndose el desarrollo en un proceso de refinamiento de los objetos
especificados durante el análisis.
En cuanto a las
metodologías OO existentes en la actualidad, aunque el número es muy elevado,
sólo unas pocas aportan alguna novedad significativa respecto a las otras, el
resto se derivan de éstas. En este sentido, hay que resaltar el interesante
esfuerzo de unificación de las notaciones utilizadas en los métodos con mayor implantación
del mercado, que ha dado origen, en 1997 al denominado Lenguaje de Modelado
Unificado (UML) [1,2].
Por otro lado, muchas
organizaciones públicas o privadas que habían establecido una metodología
propia estructurada están procediendo a su adaptación al enfoque OO, como, por
ejemplo, sucede en Francia, Gran Bretaña y España con los métodos públicos
MERISE, SSADM y MÉTRICA. En el caso de MÉTRICA [3], la versión 3 de esta
metodología incorporará precisamente este enfoque [4]. Ante el retraso en la
aparición de MÉTRICA v3, han empezado a aparecer propuestas para facilitar a
sus usuarios la transición desde el enfoque estructurado al enfoque orientado a
objetos [5]. El objetivo de este trabajo es tratar de aportar soluciones en
este sentido, proponiendo la sustitución de las técnicas de análisis y diseño
estructurado por las orientadas a objetos incluidas en el estándar UML, se
trata de los denominados Diagramas de Clases, Diagramas de Casos de Uso,
Diagramas de Interacción (en sus variantes conocidas como Diagramas de
Secuencia y Diagramas de Colaboración), Diagramas de Actividad, Diagramas de Estados,
Diagrama de Componentes y Diagramas de Despliegue.
2 Integración de UML en el ciclo de vida de
MÉTRICA
Como afirman sus autores, UML
es un lenguaje (notación) para el modelado de objetos y no una metodología de
desarrollo orientado a objetos; por lo tanto, ha sido concebida de manera que
sea indiferente al método OO que se utilice.
En el caso de MÉTRICA, al
no tratarse de una meotodología orientada a objetos, la aplicación de UML precisaría previamente la re-definición de
algunas de sus fases, módulos, actividades y tareas. En [5] se especifica con
detalle una posible modificación del ciclo de vida de MÉTRICA para convertirla
en una metodología OO, realizando el mínimo numero de cambios sobre el ciclo de
vida original, para evitar a los usuarios una transición traumática de uno a
otro enfoque. La mayor parte de los cambios propuestos se refieren a las
actividades de análisis y diseño indicadas en la tabla 1. Las técnicas de UML
que se utilizarían en estas actividades y tareas son las que se muestran en la
tabla 2.
Tabla 1. Principales actividades y tareas que se verían
afectadas
por la incorporación del enfoque OO en MÉTRICA [5]
|
Actividades y Tareas |
MÉTRICA v2.1 (Estructurada) |
MÉTRICA OO |
|
ARS 3.1 |
Construcción del Modelo
Lógico actual de Procesos |
Construcción del Modelo de
Comportamiento del Sistema actual |
|
ARS 3.2 |
Construcción del Modelo
Lógico actual de Datos |
Construcción del Modelo de
Estructura de Objetos del Sistema actual |
|
EFS 1 |
Construir el Modelo de
Procesos del nuevo Sistema |
Construir el Modelo de
Comportamiento del nuevo Sistema |
|
EFS 2 |
Construir el Esquema Lógico
de Datos del nuevo Sistema |
Construir el Modelo de
Estructura de Objetos del nuevo Sistema |
|
EFS 3.1 |
Construcción del Modelo Entidad-Evento |
Construcción de los Modelos
de Interacción y Estados |
|
EFS 3.2 |
Consolidación de los Modelos
de Datos y Procesos |
Consolidación de los Modelos
de Comportamiento y Estructura de Objetos |
|
DTS 1 |
Diseñar la Arquitectura
Física del Sistema |
Diseñar la Arquitectura
Lógica del Sistema |
|
DTS 2 |
Diseñar la Estructura Física
de Datos del Sistema |
Diseñar la Arquitectura
Física del Sistema |
Tabla 2. Integración de las técnicas de UML en las
actividades y tareas de MÉTRICA
(los símbolos [ ] indican que se trata de una actividad opcional)
|
Actividades y Tareas |
Técnicas de UML |
|
ARS 3.1 |
Diagrama de Casos de Uso,
[Diagrama de Interacción (Secuencia o Colaboración), Diagrama de Actividad,
Diagrama de Estados] |
|
ARS 3.2 |
Diagrama de Clases |
|
EFS 1 |
Diagrama de Casos de Uso,
[Diagrama de Interacción (Secuencia o Colaboración), Diagrama de Actividad,
Diagrama de Estados] |
|
EFS 2 |
Diagrama de Clases |
|
EFS 3.1 |
Diagrama de Interacción
(Secuencia o Colaboración), Diagrama de Estados |
|
EFS 3.2 |
Diagrama de Clases, Diagrama
de Interacción (Secuencia o Colaboración), Diagrama de Estados, [Diagrama de
Actividad] |
|
DTS 1 |
Diagrama de Clases, Diagrama
de Interacción (Secuencia o Colaboración), Diagrama de Estados, [Diagrama de
Actividad] |
|
DTS 2 |
Diagrama de Componentes,
Diagrama de Despliegue, Diagrama de Clases, Diagrama de Interacción
(Secuencia o Colaboración), Diagrama de Estados, [Diagrama de Actividad] |
3 Integración de UML en la documentación de
MÉTRICA
Al integrar UML en la
metodología MÉTRICA se produce una serie de cambios en la documentación que se
genera al final de cada fase como resultado de la realización de las distintas
actividades y tareas. Los documentos de MÉTRICA que se verán afectados en mayor
medida serán el Documento de Diseño Funcional (DDF), generado al final de la
fase de Análisis; y el Documento de Diseño Técnico (DDT), que se genera al
final de la fase de Diseño.
En las figuras 1 y 2 se
representa la estructura de estos documentos. Las diferencias con respecto a
los documentos originales de MÉTRICA se han resaltado como zonas sombreadas. En
el Documento de Diseño Funcional, son los apartados 2 y 3 los que deben sufrir
los mayores cambios; así, los apartados originales denominados “2.1 Modelo de
Procesos de cada Subsistema”, “2.2 Modelo de Procesos de las Funciones de cada
Subsistema” y “2.3 Modelo de Procesos de las Subfunciones de cada Función”, que
contenían los modelos funcionales en forma de Diagramas de Flujo de Datos, han
sido substituidos por un único apartado con el nombre de “2.1 Modelo de
Comportamiento de cada Subsistema”, que incluye Diagramas de Casos de Uso,
Diagramas de Interacción y Diagramas de Actividad establecidos por UML. También
el apartado “3. Modelo de Datos del Sistema” de MÉTRICA, que contenía Diagramas
de Entidad-Relación, ha sido substituido por el titulado “3. Modelo de
Estructura de Objetos del Sistema”, que incluye el diagrama, o diagramas, de
Clases del Sistema según la notación UML.
En el caso del Documento
de Diseño Técnico, la integración de UML supone una modificación substancial
del apartado “1. Diseño de la Arquitectura del Sistema”, ya que la técnica
utilizada en MÉTRICA, conocida como Diagrama de Estructura de Cuadros, basada
en un enfoque de diseño que considera una descomposición funcional, e
independiente de los datos, del Sistema de Información a construir, es substituida
por los Diagramas Clases, Diagramas de Componentes y Diagramas de Despliegue de
UML, basados en el enfoque de objetos que considera la integración de las
funciones del sistema en el interior de los objetos junto con los datos.
En este documento se
mantiene el modelo de clases del Sistema incluido en el Documento de Diseño
Funcional, que ha debido ser completado durante la fase de Diseño con clases de
interface, de gestión de datos, de gestión de procesos o tareas, y de utilidad;
asimismo, también se habrá refinado la especificación de las clases del dominio
del problema establecidas durante la fase de Análisis, ofreciendo este documento
toda la información necesaria para proceder a la construcción del Sistema.
Para finalizar, en las figuras
3 y 4 se muestran sendos diagramas de UML que podrían formar parte de los
apartados “2.1.3 Diagramas de Interacción de cada Caso de Uso” y “1.2.2
Diagramas de Interacción”, de los Documentos DDF y DDT respectivamente. El
primero es un Diagrama de Secuencia elaborado durante la fase de Análisis de un
hipotético Sistema de Gestión de un Negocio de reparación de automóviles,
mientras que el segundo es un refinamiento de aquél realizado durante la fase
de Diseño.
4 Conclusiones
La integración, en la metodología
estructurada MÉTRICA v2.1, de las técnicas de modelado orientado a objetos
establecidas por el estándar UML ha sido experimentada en la Universidad de
Alcalá desde el año 1997, tanto desde el punto de vista docente como de
desarrollo de aplicaciones informáticas comerciales. Esta integración ha
formado parte del contenido de las asignaturas “Ingeniería del Software” y
“Laboratorio de Ingeniería del Software”, durante los cursos académicos 1997-98
y 98-99. Como resultado de esta experiencia, los alumnos han asimilado los
conceptos de la aplicación de una metodología de desarrollo de software
orientada a objetos, que considera este enfoque tanto en el modelado realizado
durante las fases de análisis y diseño, como en la programación llevada a cabo
en la fase de construcción del software. También han podido experimentar esta
integración en las prácticas de laboratorio, utilizando una herramienta CASE
que permite la realización de los modelos UML y la generación parcial de código
en un lenguaje de programación orientada a objetos, como Java o C++.
En el ámbito comercial,
esta versión orientada a objetos de MÉTRICA que integra el estándar UML ya ha
sido aplicada con éxito en varios proyectos de desarrollo de software de
gestión que está operativo en diferentes organizaciones usuarias; y está siendo
utilizada actualmente para el desarrollo de otras aplicaciones de gestión
comerciales por parte de una empresa de software en colaboración con la Universidad
de Alcalá.
Referencias
1. Unified Modeling
Language Documentation. UML Resource Center (1999).
http://www.rational.com/uml/resources/documentation.
2. Booch, G., Rumbaugh, J., Jacobson, I. El Lenguaje Unificado de Modelado.
Addison Wesley, Madrid (1999)
3. Metodología de Planificación y Desarrollo de
Sistemas de Información. MÉTRICA Versión 2.1. Ministerio para las
Administraciones Públicas, Madrid (1995)
http://www.map.es/csi/pg5m40.htm.
4. Proyecto MÉTRICA Versión 3. Ministerio para
las Administraciones Públicas.
http://www.map.es/csi/pg5m42.htm.
5. Hilera, J.R.: Metodología MÉTRICA Orientada a
Objetos. NOVÁTICA. Próxima publicación.
|
|
DOCUMENTO
DE DISEÑO FUNCIONAL (DDF) |
|
|
|
1.
Especificación del Sistema Propuesto. 1.1 Diagrama de Casos de Uso del Sistema 1.2 Diseño de Subsistemas. 1.2.1 Diagramas de Casos de Uso 1.2.2 Descripción de los
Componentes. 2.
Especificación de Subsistemas. 2.1 Modelo de Comportamiento de cada
Subsistema. 2.1.1 Diagrama de Casos de Uso
(DCU) de cada Subsistema. 2.1.2 Descripción de los Componentes de los DCU. 2.1.3 Diagramas de Interacción
(DI) de cada Caso de Uso. 2.1.4 Diagrama de Actividad de cada
DI. 2.1.5 Descripción de los
Componentes de los DI. 3.
Modelo de Estructura de Objetos del Sistema. 3.1 Diagrama de Clases. 3.2 Descripción de Clases. 3.2.1 Atributos (descripción y
formato). 3.2.2 Operaciones (descripción). 3.2.3 Diagrama de Estados. 3.3 Descripción de relaciones. 4.
Interfaces de usuario. 4.1 Pantallas. 4.1.1 Diálogo de Pantallas. 4.1.2 Mapa de Pantallas. 4.1.3 Elementos asociados. 4.1.4 Identificación de diálogos críticos. 4.2 Informes. 4.2.1 Formato de Informe. 4.2.2 Elementos asociados. 5.
Otras Especificaciones no funcionales del Sistema. 5.1 Especificación de Requisitos de
Seguridad y Control. 5.2 Especificación de Requisitos de
Respaldo y Recuperación de Errores. 5.3 Especificación de Requisitos de
Rendimiento. 6.
Especificaciones de la Entrega. 6.1 Plan de Desarrollo y Entrega del
nuevo Sistema. 6.2 Revisión del Plan del Proyecto. 7.
Control de Calidad de la Especificación Funcional. 7.1 Validación del Modelo de
Comportamiento. 7.2 Validación del Modelo de Estructura
de Objetos. 7.3 Seguimiento de los Requisitos de
Usuario. |
|
Fig 1. Resultado de la integración de UML en el
Documento de Diseño Funcional
|
DOCUMENTO DE DISEÑO TÉCNICO (DDT) |
|
|
|
|
1. Diseño de la Arquitectura del Sistema. 1.1
Diagramas de Clases y Componentes del Sistema. 1.2 Diseño
del Componente del Dominio del Problema (CDP). 1.2.1 Diseño de cada Clase del CDP.
1.2.1.1 Atributos.
1.2.1.2 Especificación de Operaciones.
1.2.1.3 Pantallas e Informes asociados.
1.2.2.4 Diagrama de Estados. 1.2.2 Diagramas de Interacción. 1.3 Diseño
del Componente de Interface con el Usuario (CIU). 1.3.1
Diseño de cada Clase del CIU. 1.3.2
Diagramas de Interacción. 1.4 Diseño
del Componente de Interface con Sistemas Externos (CSE) 1.4.1
Diseño de cada Clase del CSE. 1.4.2
Diagramas de Interacción. 1.5 Diseño
del Componente de Gestión de Datos (CGD) 1.5.1
Diseño de cada Clase del CGD. 1.5.2
Diagramas de Interacción. 1.6 Diseño del
Componente de Gestión de Tareas (CGT). 1.6.1
Diseño de cada Clase del CGT. 1.6.2
Diagramas de Interacción. 1.7 Diseño
del Componente de Servicios de Utilidad (CSU). 1.7.1
Diseño de cada Clase del CSU. 1.7.2
Diagramas de Interacción. 1.8 Diseño
del Despliegue del Software en el Hardware. 2. Diseño Físico de Datos. 2.1
Estructura Física de la Base de Datos o de los Ficheros. 2.2
Estructura de Tablas y Vistas. 2.3 Ficheros
Auxiliares. 2.4 Descripción
de atributos. 3. Entorno Tecnológico del Sistema. 3.1
Especificaciones del Entorno Tecnológico. 3.1.1
Equipo Físico. 3.1.2
Equipo Lógico. 3.1.3
Comunicaciones 3.2
Restricciones Técnicas. 4. Especificación del Plan de Desarrollo e
Implantación. 5. Control de Calidad del diseño Técnico 5.1 Revisión
del Diseño Técnico. 5.1
Validación del Diseño Técnico. |
|
Fig. 2. Resultado de la integración de UML en el
Documento de Diseño Técnico
Fig. 3. Ejemplo de Diagrama de Interacción con notación UML incluido en un
Documento de Diseño Funcional
Fig. 4. Ejemplo de Diagrama de Interacción con notación UML incluido en un
Documento de Diseño Técnico.