MARÍA DE LOS ÁNGELES MARTÍNEZ MORALES

TRABAJO: INVESTIGACION APLICACIONES DEL MODELADO

FLORES PÈREZ JORGE ELIECER

Algunas de las debilidades de muchos métodos están contextualizadas en etapas tempranas

del desarrollo de software. Uno de los problemas derivado de estas debilidades

metodológicas tiene que ver con la dificultad de determinar si el modelo conceptual del

sistema de software representa fiel y completamente los requisitos de los usuarios.

Casi siempre estos requisitos son expresados de forma escasamente estructurada sin

establecer ninguna correspondencia entre éstos y los elementos del modelo conceptual. Más

aún, generalmente estos métodos carecen de directrices adecuadas para el desarrollo de

modelos conceptuales derivados de las especificaciones y posteriormente de código que sea

funcionalmente equivalente a dichos modelos conceptuales.

Es importante partir de manera correcta desde el primer punto a la hora de crear o

desarrollar un sistema o software. Después de haber realizado algunos estudios y tareas de

requerimientos es primordial elaborar un diagrama de CASO DE USO (requisitos

funcionales) que específica a detalle todas las partes y procesos de nuestro sistema, y así

como también los objetivos que pretende alcanzar este mismo.

Este enfoque pretende mejorar la calidad del proceso de producción de software:

Proporcionando predictibilidad mediante la construcción de un modelo conceptual

como una precisa, estructurada y bien definida representación de los requisitos de los

usuarios.

Aumentando la productividad al establecer vínculos precisos entre el modelo

conceptual y los requisitos de los usuarios. Esto facilitará la incorporación en el

modelo conceptual de cambios en los requisitos. En consecuencia, tales

modificaciones quedarán reflejadas también en el sistema de software desarrollado.

Para lograr esto, el enfoque propuesto define un Modelo de Requisitos que captura los

aspectos funcionales del sistema mediante la aplicación de tres técnicas complementarias

entre sí: la definición de la Misión del sistema, la construcción del Árbol de Refinamiento de

Funciones y el desarrollo del Modelo de Casos de Uso.

Adicionalmente, se introduce el Proceso de Análisis de Requisitos que permite traducir el

Modelo de Requisitos en el Modelo Conceptual manteniendo la trazabilidad entre ambos

modelos. Este proceso garantiza que cada elemento del modelo de requisitos tenga una

representación en el modelo conceptual.

FASE DE MODELADO DE REQUISITOS.

El propósito del Modelo de Requisitos es capturar precisa y fielmente las principales

características del sistema software que se desea construir. Este modelo permite representar

los requisitos del sistema de manera que cualquiera de sus potenciales usuarios pueda

revisarlo y comprenderlo, sin que para esto necesite un entrenamiento especial. No obstante,

la notación utilizada en tal representación es lo suficientemente precisa para que pueda

servir de base a la fase de modelado conceptual.

Las técnicas propuestas para el desarrollo del Modelo de Requisitos intentan superar estos

problemas. La determinación del propósito del sistema (Misión) y la descomposición de sus

interacciones externas en funciones (Árbol de Refinamiento de Funciones) conjuntamente

con una estructurada especificación de las funcionalidades (Modelo de Casos de Uso),

constituyen la clave para el establecimiento del nivel de abstracción adecuado de los casos

de uso.

El Proceso de Análisis de Requisitos, por su parte, considera los aspectos relativos al

análisis de estas funcionalidades y a su traducción al Modelo Conceptual OO-Method. En las

próximas secciones se describen las tres técnicas que permiten generar el Modelo de

Requisitos.

MISION DEL SISTEMA

Describe el propósito del sistema, sus responsabilidades y alcance. A través de la definición

de su misión es posible determinar con precisión, aunque sea en términos generales, qué

hará y qué no hará el sistema.

Aunque sea una técnica relativamente sencilla, es de vital importancia consensuar desde el

principio con los usuarios el objetivo del sistema y tenerlo presente durante todas las fases

del proceso de desarrollo del sistema.

ARBOL DE REFINAMIENTO DE FUNCIONES

Descompone el sistema en interacciones externas, de acuerdo a algún criterio preestablecido

por ejemplo, las áreas u objetivos organizacionales, los actores y sus responsabilidades, etc.

Las interacciones externas son organizadas en funciones que forman una jerarquía a manera

de árbol, en cuyo nivel más alto (raíz) se ubica la misión del sistema.

Esta Misión del Sistema es refinada hasta obtener otras funciones elementales

representadas en la jerarquía a través de los nodos hoja. Este proceso descendente de

refinamiento funcional puede generar distintos niveles de nodos. Aquellos que están entre la

raíz y los nodos hoja son denominados nodos intermedios. Un nodo intermedio es un

sumario de funciones elementales.

En general, una rama completa de nodos con origen en la raíz del árbol, representa toda la

funcionalidad relativa a un área o actividad de la organización, según el criterio de

descomposición utilizado. Distinguir entre nodos hoja y nodos intermedios no es una tarea

trivial. Una función es considerada como elemental si es activada por un evento enviado por

un usuario del sistema (actor) o por la ocurrencia de un evento temporal.

MODELO DE CASOS DE USO

El modelado de requisitos utiliza los elementos del Modelo de Casos de Uso propuesto por

Jacobson, bajo el esquema conceptual y notacional definido en UML. De esta forma, la

especificación de actores y casos de uso así como el establecimiento de las relaciones entre

éstos, constituye el objetivo fundamental del Modelo de Casos de Uso.

El principal insumo requerido para el desarrollo de este modelo son las funciones

elementales identificadas como nodos hoja en el Árbol de Refinamiento Funcional del

sistema. Cada una de estas funciones elementales es considerada en el modelo como un

caso de uso.

Luego de identificar sus actores, la especificación de los casos de uso describe en lenguaje

natural la secuencia completa y ordenada de las acciones que el sistema debe ejecutar,

incluyendo todas sus posibles variantes, al interactuar con los actores para la satisfacción de

los requisitos.

Representación Gráfica:

A continuación se muestran algunos ejemplos de requerimientos que tiene un sistema,

mediante el uso de los diagramas de CASO DE USO.

PROCESO DE ANALISIS DE REQUISITOS

El propósito principal de este proceso es identificar las responsabilidades más significativas

del sistema en desarrollo. Una responsabilidad es una obligación que tiene un objeto con

respecto a su propio comportamiento.

Las responsabilidades conllevan a la definición de operaciones, esto es, a la especificación

de los servicios de una clase. Utilizando terminología OO-Method, las responsabilidades

resultan en especificaciones de eventos (unidades atómicas de ejecución) o de

transacciones (unidades moleculares de ejecución). Con el propósito de describir las

responsabilidades detectadas en el contexto de un Caso de Uso se utilizan Diagramas de

Secuencia con notación UML.

En estos diagramas se representan las responsabilidades, identificando el objeto que la

invoca (objeto cliente) y el objeto al que ésta pertenece (objeto servidor).

Para mostrar las decisiones sobre asignación de responsabilidades entre los objetos, el

Proceso de Análisis de requisitos prevé la especificación de Diagramas de Secuencia pero a

muy alto nivel y como herramienta para representar estas responsabilidades.

CONCLUSION

Podemos decir que parte vital en el desarrollo del sistema car sobre el modelado del mismo

mediante el uso de diagramas de CASO DE USO.

Ya que en él se describe de manera clara, detallada, precisa y gráficamente los procesos a

desarrollarse en él, así como los actores o partes principales del mismo.

Un buen diagrama de CASO DE USO facilita demasiado el entendimiento del sistema tanto

para el desarrollador como para el cliente. Así en un futuro si el sistema llegara a presentar

algún error o se le quisiera hacer alguna actualización o modificación se resolvería

específicamente está localizándola en el diagrama sin tener que se requiera revisar todo el

código del sistema.

REFERENCIAS

http://escolar.ittux.edu.mx/file.php/340/lecturas/Modelado_de_requisitos_2.pdf

http://escolar.ittux.edu.mx/file.php/340/lecturas/Modelado_de_requisitos.pdf

http://www.mcu.es/archivos/docs/moreq.pdf

www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r88021.PDF