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