Herramientas CASE para UML

Debido a la popularidad que han ido adquiriendo UML (Unified Modeling Language) y MDA (Model Driven Architecture) en los últimos años, existe en el mercado una gran variedad de herramientas de modelado de diagramas UML.  Con lo cual, seleccionar una herramienta CASE (Computer-Aided Software Engineering) para UML se ha convertido en una tarea ardua.

¿Qué podemos esperar de una herramienta CASE (Computer-Aided Software Engineering) para UML? lo primero que podemos esperar de una herramienta es que facilite la tarea de dibujar diagramas, su corrección sintáctica, y la coherencia entre los distintos diagramas. Esta tarea se ve obstaculizada desde el primer momento por los problemas que presenta el mismo estándar de UML, que no habiendo alcanzado su plena madurez, presenta todavía inconsistencias y lagunas importantes

Herramientas UML

Herramientas gráficas. Las herramientas meramente gráficas son aquéllas que proporcionan algún tipo de ayuda para dibujar diagramas UML Herramientas sintácticas. Las herramientas sintácticas son aquéllas que, en general, sólo permiten dibujar diagramas correctos según las reglas notacionales de UML (o al menos lo intentan). Por tanto, suponen una ayuda mayor para el usuario respecto a las herramientas meramente gráficas. Herramientas semánticas. El tercer grupo lo constituyen las herramientas semánticas, es decir, aquellas que tratan de garantizar la construcción de un modelo que esté correctamente expresado en diagramas que además sean coherentes entre sí. Aunque en algunos casos la puntuación pueda ser inferior a la obtenida por herramientas

de los otros grupos, es dentro de esta categoría donde encontramos las que con propiedad pueden llamarse herramientas CASE para UML.

Dimensiones considerables con respecto a las herramientas CASE

Integración con herramientas ofimáticas (como copiar y pegar los diagramas en documentos de texto).

·         Posibilidad de trabajo multiusuario (para que los diversos implicados en un proyecto puedan acceder simultáneamente a distintas partes de un modelo).

·         Exportación en formato XMI (XML Metadata Interchange).

·         Integración dentro del entero proceso de desarrollo de software, desde la obtención de requisitos de usuario hasta la generación automática de código, estimación de esfuerzo necesario para acometer la implementación de un modelo dado, planificación, mantenimiento, pruebas, etc.

·         Reutilización de todo tipo de artefactos software (no sólo código fuente o ejecutable, sino también modelos de análisis o diseño, definición de pruebas, etc., e incluso requisitos).

Algunas Herramientas CASE son las siguientes:

Rational Rose 2002 Enterp. Ed.

Visible Analyst

Argo UML

Objecteering Personal Ed.

Visual UML Standard Ed.

Poseidon for UML

Visual Paradigm for UML Comm. Ed.

Object Domain R3 Eval. Ed.

Together Designer Comm. Ed.

seCAKE

Enterprise Architect

Visio 2003 Profesional

MagicDraw UML Enterp. Ed.

Recuperado de:

Gonzalo Génova Fuster, José Miguel Fuentes Torres, María Cruz Valiente Blázquez (mayo-junio 2006). Tecnología de objetos secciones técnicas. Evaluación comparativa de herramientas CASE para UML desde el punto de vista notacional Obtenido en octubre, 2011, de Depto. de informática, Universidad Carlos III de Madrid

UML Lenguaje Unificado de Modelado

Tratamiento de Requisitos en Propuestas para la Web

El desarrollo de sistemas web agrupa una serie de características que lo hacen diferente del desarrollo de otros sistemas (Koch, 2001). Por un lado, hay que tener en cuenta que roles muy diferentes de desarrolladores participan en el proceso: analistas, clientes, usuarios, diseñadores gráficos, expertos en multimedia y seguridad, etc. Por otro lado, la existencia en estos sistemas de una importante estructura de navegación obliga a un desarrollo preciso de este aspecto que garantice que el usuario no se “pierde en el espacio navegacional del sistema” (Olsina, 1999). Estas ideas unidas al hecho que los sistemas web suelen tratar con múltiples medios y es esencial que ofrezcan una interfaz adecuada en cada momento, obligan a que estos aspectos propios de la web deban ser tratados de una forma especial en el proceso de desarrollo.

UML-Based Web Engineering

UML-Based Web Engineering (UWE) es una propuesta metodológica basada en el Proceso Unificado (Jacobson, Booch & Rumbaugh, 1999) y UML para el desarrollo de aplicationes web (Hennicker & Koch, 2000, Koch, 2001). UWE cubre todo el ciclo de vida de este tipo de aplicaciones, centrando además su atención en aplicaciones personalizadas (adaptivas). Para este trabajo, nos interesa principalmente analizar la propuesta de captura de requisitos de UWE. Esta metodología distingue entre la tarea de enlistar requisitos, definir y validar los requisitos. El resultado final de la captura de requisitos en UWE es un modelo de casos de uso acompañado de documentación que describe los usuarios del sistema, las reglas de adaptación, los casos de uso y la interfaz. UWE clasifica los requisitos en dos grandes grupos: funcionales y no funcionales. Los requisitos funcionales tratados por UWE son:

• Requisitos relacionados con el contenido
• Requisitos relacionados con la estructura
• Requisitos relacionados con la presentación
• Requisitos relacionados con la adaptación

Requisitos relacionados con los usuarios. Además, UWE propone como técnicas apropiadas para la captura de los requisitos de un sistema web las entrevistas, los cuestionarios y los checklists y los casos de uso, los escenarios y el glosario para la definición de requisitos. Para la validación propone walk- hroughs, auditorías y prototipos.

W2000

W2000 (Baresi, Garzotto & Paolini, 2001) supone una propuesta que amplía la notación de UML con conceptos para modelar elementos de multimedia heredados de la propuesta HDM (Hypermedia Design Model) (Garzotto, Schwabe & Paolini, 1993). El proceso de desarrollo de W2000 se divide en tres etapas: análisis de requisitos, diseño de hipermedia y diseño funcional. El primero de ellos es el que resulta interesante para este trabajo. La especificación de requisitos en W2000 se divide en dos subactividades: análisis de requisitos funcionales y análisis de requisitos navegacionales. La especificación de requisitos comienza haciendo un estudio de los diferentes roles de usuario que van a interactuar con el sistema. Cada actor potencialmente distinto tendrá su modelo de requisitos de navegación y de requisitos funcionales. El modelo de requisitos funcionales es representado como un modelo de casos de uso tal y como se propone en UML. En él se representa la funcionalidad principal asociada a cada rol y las interacciones que se producen entre el sistema y cada rol. El segundo modelo consiste en otro diagrama de casos de uso pero que no representa funcionalidad sino posibilidades de navegación de cada actor. La representación gráfica es realizada con una extensión de UML.

Recuperado de:

Escuela Técnica Superior de Ingeniería Informática (2002). Ingeniería de Requisitos en Aplicaciones para la Web – Un estudio comparativo: Universidad de Sevilla. Sevilla: Autor.

Ingeniería de requisitos

Proceso de desarrollo de un sistema, sea o no para la web, el equipo de desarrollo se enfrenta al problema de la identificación de requisitos. La definición de las necesidades del sistema es un proceso complejo, pues en él hay que identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios finales y de los clientes. El proceso de especificación de requisitos se puede dividir en tres grandes actividades (Lowe & Hall, 1999):

1- captura de requisitos

2- definición de requisitos

3- validación de requisitos

Captura de requisitos

Actividad mediante la que el equipo de desarrollo de un sistema de software extrae, de cualquier fuente de información disponible, las necesidades que debe cubrir dicho sistema (Díez, 2001). Técnicas que de forma clásica han sido utilizadas para esta actividad en el proceso de desarrollo de todo tipo de software:

• Entrevistas: le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada.
• JAD (Joint Application Development/Desarrollo conjunto de aplicaciones): Práctica de grupo que se desarrolla durante varios días y en la que participan analistas, usuarios, administradores del sistema y clientes (IBM, 1997).
• Brainstorming (Tormenta de ideas): Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas. El grupo de personas que participa en estas reuniones no debe ser muy numeroso (máximo 10 personas), una de ellas debe asumir el rol de moderador de la sesión, pero sin carácter de controlador.
• Concept Mapping: Los concept maps (Pan, Zhu & Johnson, 2001) son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos.
• Sketches y Storyboards: Consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches).
• Casos de Uso: Aunque inicialmente se desarrollaron como técnica para la definición de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como técnica para la captura de requisitos (Pan, Zhu & Johnson, 2001 y Liu & Yu, 200).
• Cuestionarios y Checklists: Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas opciones en el propio cuestionario (Checklist).
• Comparación de terminología: Uno de los problemas que surge durante la definición de requisitos es que usuarios y expertos no llegan a entenderse debido a problemas de terminología.

Definición de requisitos

• Lenguaje natural: Resulta una técnica muy ambigua para la definición de los requisitos. Consiste en definir los requisitos en lenguaje natural sin usar reglas para ello.
• Glosario y ontologías: La diversidad de personas que forman parte de un proyecto software hace que sea necesario establecer un marco de terminología común.
• Escenarios: La técnica de los escenarios consiste en describir las características del sistema a desarrollar mediante una secuencia de pasos (Liu & Yu, 2001).
• Casos de uso: Como técnica de definición de requisitos es como más ampliamente han sido aceptados los casos de uso. Actualmente se ha propuesto como técnica básica del proceso RUP (Kruchten, 1998).
• Lenguajes Formales: Otro grupo de técnicas que merece la pena resaltar como extremo opuesto al lenguaje natural, es la utilización de lenguajes formales para describir los requisitos de un sistema.

La validación de requisitos

Tiene como misión demostrar que la definición de los requisitos define realmente el sistema que el usuario necesita o el cliente desea (Lowe & Hall, 1999).

• Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la completa documentación o modelado de la definición de requisitos. Con ello solamente se puede validar la correcta interpretación de la información transmitida.
• Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir sólo una muestra es revisada.
• Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo (Durán, Bernáldez, Ruíz & Toro, 1999).
• Prototipos: Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario (Olsina, 1999).

Recuperado de:

Escuela Técnica Superior de Ingeniería Informática (2002). Ingeniería de Requisitos en Aplicaciones para la Web – Un estudio comparativo: Universidad de Sevilla. Sevilla: Autor.

Comparación entre Dia2Code, Umbrello y ArgoUML

El análisis y diseño de software juega un papel crucial en cualquier desarrollo, pero es en la programación orientada a objeto donde las actividades relacionadas con esta fase de un proyecto han alcanzado sus cotas más altas de sofisticación. Es, además, un área donde continuamente se producen avances y nuevas propuestas.

Aunque la mayoría de los diagramas de UML nos permiten mejorar la comunicación con el cliente en las fases iniciales, así como documentar y explorar funcionalidades y aspectos concretos de las clases de nuestro sistema durante su análisis y diseño, UML puede ayudarnos en las fases de desarrollo e implantación.

Se escogió la generación de código mediante tres herramientas de código abierto de las cuales se hacemos una comparación en la siguiente tabla.

Cuadro comparativo herramientas para la generación de código

Dada la información anterior, y con fines de aprovechamiento de recursos en la ejecución del proyecto, se ha escogido usar el software ArgoUML para la generación de código, los diagramas que se presentan a continuación fueron generados con ésta herramienta.

Las herramientas anteriormente mencionadas pueden encontrarse en las siguientes ligas

http://www.gnome.org/       Dia2Code

http://uml.sourceforge.net/ Umbrello              

http://argouml.tigris.org/      ArgoUML

Diagrama de casos de uso

Los casos de uso son una herramienta esencial en la toma de requisitos del sistema. Nos permiten expresar gráficamente las relaciones entre los diferentes usos del mismo y sus participantes o actores. El resultado es un conjunto de diagramas muy fácilmente entendibles tanto por el cliente, como por los analistas del proyecto. No definen todos los requisitos (por ejemplo, tipos de datos, interfaces externas, rendimiento, etc.) pero sí que representan el hilo conductor que los vincula a todos con los actores del sistema.

Se componen de los siguientes elementos:

• Actores: representan los roles que juegan los usuarios u otros sistemas en el sistema del problema.
• Caso de uso: son las acciones que pueden tener lugar en el sistema que queremos modelar.
• Relaciones: indican actividad o flujo de información.
• Límite del sistema: define el ámbito donde se produce el caso de uso que estamos representando y que va a ser tratado por el sistema.

El diagrama de casos de uso que propongo para el proyecto de simulador de conducción vehicular es el siguiente

Diagrama de casos de uso

Diagrama de clases

La realización de un diagrama de clases está en la frontera entre el análisis y el diseño. Probablemente es el diagrama UML más conocido y nos permite identificar la estructura de clases del sistema incluyendo las propiedades y métodos de cada clase.

Los elementos presentes en este diagrama son únicamente las clases, y sus relaciones:

• Clase: se representa mediante un rectángulo dividido en tres secciones. En la parte superior deberemos indicar su nombre, a continuación sus propiedades o atributos y en la tercera sección sus métodos.
• Asociación: representa una relación genérica entre dos clases, y su notación es simplemente una línea que las une, donde se puede indicar la multiplicidad de la relación en cada extremo (uno a uno, uno a n, n a m).
• Composición, agregación: Si una clase está compuesta de otras, donde estas otras no pueden existir sin la primera, tendrán una relación de composición con la clase padre. Cuando simplemente una clase incluye a otra, pero la incluida tiene entidad en sí misma es agregación.
• Dependencia: cuando una clase depende de otra en el sentido de que la usa como atributo o parámetro de algún método, puede expresarse mediante una relación de dependencia.
• Generalización: es el equivalente a la herencia o extensión.

El diagrama de clases para el software simulador de conducción vehicular es el siguiente



Diagrama de clases



Diagrama de actividades

Son el equivalente orientado a objeto de los diagramas de flujo y los DFD del desarrollo estructurado. Su uso es principalmente la exploración y representación de la lógica comprendida en operaciones complejas, reglas de negocio, casos de uso o procesos software.

De forma similar a los tradicionales diagramas de flujo, todo diagrama de actividades tiene un punto de partida y un final. Las actividades representarán cada paso importante que se produce en el proceso que estamos modelando (puede representar un caso de uso o bien un conjunto de ellos).

A continuación el diagrama de actividades referente a este proyecto



Diagrama de actividades