MODELO DE REQUISITOS Y CASOS DE USO.

EQUIPO 4.

Introducción

El Modelo de Requisitos tiene como objetivo ofrecer una serie de técnicas y métodos para capturar los requisitos de los usuarios de una manera estructurada, así como facilitar la transición al Esquema Conceptual manteniendo la trazabilidad. Para conseguirlo, el modelo emplea una aproximación basada en los casos de uso, la cual se usa ampliamente en entornos de ingeniería de requisitos, con la diferencia de que la información recolectada se orienta de cara a generar el esquema conceptual.

La finalidad del modelo de requisitos es capturar de una manera precisa lo que el cliente quiere que se construya. Además, el propósito es modelar los requisitos de tal manera que personas que no estén familiarizadas con la notación empleada puedan entenderlos y revisarlos. La notación es lo suficientemente precisa para que pueda servir de base para la fase de modelado conceptual. Los conceptos básicos de los que se hace uso son los actores y los casos de uso. Debido a que los casos de uso son simples y a que las descripciones de los casos de uso se fundamentan en conceptos naturales que pueden

encontrarse en el espacio del problema, los clientes y los usuarios finales pueden participar activamente en el modelado de requisitos. A pesar de estas ventajas, existen dos inconvenientes principales:

Es difícil encontrar el nivel de abstracción correcto para especificar los casos de uso (lo que en realidad es un caso de uso)

También es complicado encontrar un proceso para analizar y traducir las especificaciones de los casos de uso en un modelo conceptual.

Las técnicas que se utilizan en el modelo de requisitos presentado para solucionar estos problemas son las siguientes:

Misión del Sistema (2.1.1): describe la finalidad del sistema en una o dos frases. También describe las responsabilidades más significativas así como una lista de características que el sistema no va a hacer.

Árbol de Refinamiento de Funciones (2.1.2): asociado al particionamiento de las interacciones externas de acuerdo a diferentes áreas del negocio u objetivos del negocio.

Modelo de Casos de Uso (2.2): incluye las especificaciones de Casos de Uso para especificar la composición de las interacciones externas y el Diagrama de Casos de Uso para mostrar la comunicación entre el entorno (actores) y el sistema.

El objetivo fundamental del Modelo de Casos de Uso es la especificación de actores y casos de uso y el establecimiento de las relaciones que entre ellos se producen. 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 [Jac&Al 92][UML Web Site].

La combinación de Casos de Uso se modela estableciendo relaciones entre ellos. Con esta finalidad, se utilizan las relaciones de extensión e inclusión. La forma de representar estas relaciones de extensión e inclusión habrán de adecuarse a la forma en la que se especifican los Casos de Uso y en la que se modelan los Diagramas de Secuencia ya que estas dos herramientas son esenciales para conseguir la trazabilidad deseada entre el Modelo de Requisito y del Modelo Conceptual.

Modelo de Requisitos El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por

lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo. El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso. Actualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y se resume aquí:

Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.

Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.

Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.

Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.

Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.

Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.

El diagrama de la Figura ilustra los distintos modelos.

El propósito del modelo de requisitos es comprender completamente el problema y sus implicaciones. Todos los modelos no solamente se verifican contra el modelo de

requisitos, sino que también se desarrollan directamente de él. El modelo de requisitos sirve también como base para el desarrollo de las instrucciones operacionales y los manuales ya que todo lo que el sistema deba hacer se describe aquí desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecánico, el analista debe interactuar constantemente con el cliente para completar la información faltante, y así clarificar ambigüedades e inconsistencias. El analista debe separar entre los requisitos verdaderos y las decisiones relacionadas con el diseño e implementación. Se debe indicar cuales aspectos son obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la implementación. Durante el diseño se debe extender el modelo de requisitos con especificaciones de rendimiento y protocolos de interacción con sistemas externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseño, como el uso de lenguajes de programación particulares. En la metodología de Objectory, el modelo de requisitos consiste de tres modelos principales, visualmente representado por un diagrama de tres dimensiones como se muestra en la Figura.

El modelo de comportamiento, basado directamente en el modelo de casos de uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del usuario. Este modelo utiliza dos conceptos claves: actores para representar los

distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso para representar qué pueden hacer los actores con respecto al sistema

El modelo de presentación o modelo de interfaces o borde especifica cómo interactúa el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de información ricos en interacción con el usuario, especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad ofrecerá cada una de ellas.

El modelo de información o modelo del dominio del problema especifica los aspectos estructurales del sistema.

Este modelo conceptualiza el sistema según los objetos que representan las entidades básicas de la aplicación. Aunque en muchas metodologías se permite especificar la funcionalidad completa del sistema utilizando el modelo del dominio del problema, incluyendo operaciones formales sobre los objetos correspondientes a un modelo de requisitos expresado sin casos de uso, el modelo del dominio del problema será de mucha más ayuda como apoyo al modelo de casos de uso y no como una entidad totalmente independiente. Es importante resaltar que esta separación en tres ejes de modelado independientes es la base para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos.

CASOS DE USO.Los casos de uso describen una interacción típica entre un usuario (actores) y un sistema de cómputo. Es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje Produce algo de valor para algún actor como el cálculo de algún resultado Describe qué hace un sistema pero no especifica cómo lo hace El caso de uso capta alguna función visible para el usuario. El caso de uso puede ser pequeño o grande. El caso de uso logra un objetivo discreto para el usuario. Un caso de uso debe ser simple, claro y conciso.Los casos de uso sirven para capturar el comportamiento deseado del sistema sin tener que especificar cómo se implementa ese comportamiento Como medio de comprensión del sistema para desarrolladores, usuarios finales y expertos del dominio, ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este.

ACTORES.

Representa un conjunto de roles que los usuarios de los casos de uso juegan al interactuar con éstos.

Representa un rol que es jugado por una persona, un dispositivo hardware u otro sistema que interactúe con nuestro sistema.

Se puede definir categorías generales de actores (como cliente) y especializarlos (como ClienteComercial) a través de relaciones de generalización Cliente Cliente Comercial actor actor generalización

Un actor y un caso de uso se pueden comunicar a través de una asociación en donde cada uno de ellos pueden enviar y recibir mensaje.

¿COMO SE DEBE CREAR UN CASO DE USO?

Tras localizar los actores, procede el describirlos

especificar describiendo un flujo de eventos

Los actores sólo pueden conectar a los casos de uso a través de asociaciones

Generalmente hay pocos actores asociados a cada Caso de Uso

Preguntas clave:

¿cuáles son las tareas del actor?

¿qué información crea, guarda, modifica, destruye o lee el actor?

¿debe el actor notificar al sistema los cambios externos?

¿debe el sistema informar al actor de los cambios internos?

LA DESCRIPCIÓN DE LOS CASOS DE USO COMPRENDEN:

el inicio: cuándo y qué actor lo produce?

el fin: cuándo se produce y qué valor devuelve?

la interacción actor-caso de uso: qué mensajes intercambian ambos?

Objetivo del caso de uso:

¿qué intenta el caso de uso? cronología y origen de las informaciones repeticiones de comportamiento:

¿qué operaciones son iteradas?

situaciones opcionales:

¿qué ejecuciones alternativas se presentan en el caso de uso?

MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN

Modelo de Proceso de Software IEEE.

Análisis de requerimientos

Extraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requerimientos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de requerimientos, por ejemplo en dos capítulos del libro de Sommerville "Ingeniería del software" titulados "Requerimientos del software" y "Procesos de la Ingeniería de Requerimientos".

La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requerimientos de software (Software Requirements Specification).

Especificación

La especificación de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

Caso de uso ,

Historias de usuario ,

Siendo los primeros más rigurosos y formales, los segundas más ágiles e informales.

Arquitectura

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto.

El arquitecto de software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas.

La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de software.

La arquitectura de software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases

Diagramas de base de datos

Diagrama de despliegue

Diagrama de secuencia

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar.

Las herramientas para el diseño y modelado de software se denominan CASE, (Computer Aided Software Engineering) entre las cuales se encuentran:

Enterprise Architect

Microsoft Visio for Enterprise Architects

Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y

que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales técnicos, etc. todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto2 está dedicado a su mantenimiento. Una pequeña parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.

Modelos y filosofías de desarrollo de software

La ingeniería de software dispone de varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya para la construcción del software, entre ellos se puede citar:

Modelo en cascada o Clásico (modelo tradicional)

Modelo de prototipos

Modelo en espiral

Desarrollo por etapas

Desarrollo iterativo y creciente o Iterativo e Incremental

RAD (Rapid Application Development)

Desarrollo concurrente

Proceso Unificado

RUP (Proceso Unificado de Rational)

Naturaleza de la IS

La ingeniería de software tiene que ver con varios campos en diferentes formas:

Matemáticas

Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.

Creación

Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que se encuentran en la IS.

Gestión de Proyectos

El desarrollo de software de gran porte requiere una adecuada gestión del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su administración se debe tener una clara visión y capacitación en Gestión de Proyectos.

Arte

Los programas contienen muchos elementos artísticos. Las interfaces de usuario, la codificación, etc. Incluso la decisión para un nombre de una variable o una clase. Donald Knuth es famoso por argumentar a la programación como un arte.

3.6. HERRAMIENTAS CASE.

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar

un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos

1. Mejorar la productividad en el desarrollo y mantenimiento del software.

2. Aumentar la calidad del software.

3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.

4. Mejorar la planificación de un proyecto

5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.

6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.

7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación

8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.

9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Clasificación

Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

1. Las plataformas que soportan.

2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.

3. La arquitectura de las aplicaciones que producen.

4. Su funcionalidad.

La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.

Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre sí, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.

MetaCASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.

CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software

.

IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración activa.

Por funcionalidad podríamos diferenciar algunas como:

Herramientas de generación semiautomática de código.

Editores UML.

Herramientas de Refactorización de código.

Herramientas de mantenimiento como los sistemas de control de versiones.

Case mas utilizada: CASE ERWIN:

Es una herramienta de diseño de base de datos. Brinda productividad, en diseño, generación y mantenimiento de aplicaciones. Permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos. Genera automáticamente las tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos. ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidad- relación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas lasentidades, atributos, relaciones, y llaves importantes.

ERwin establece una conexión entre una base de datos diseñada y una base de datos, permitiendo transferencia entre ambas y la aplicación de ingeniería reversa. Usando esta conexión, Erwin genera automáticamente tablas, vistas, índices, reglas de integridad referencial (llaves primarias, llaves foraneas), valores por defecto y restricciones de campos ydominios.

44. ERwin soporta principalmente bases de datos relacionales SQL y bases de datos que incluyen Oracle, Microsoft SQL Server, Sybase, DB2, e Informix. El mismo modelo puede ser usado para generar múltiples bases de datos, o convertir una aplicación de unaplataforma de base de datos a otra.