UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INGENIERA INFORMTICA

INGENIERA EN INFORMTICA

PROYECTO FIN DE CARRERA

COLA-CASE: POTENCIANDO EL MODELADO CONCEPTUAL CON PATRONES
DE COLABORACIN

FELICIDAD PADILLA LPEZ

JUNIO, 2008

UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INGENIERA INFORMTICA

INGENIERA EN INFORMTICA

PROYECTO FIN DE CARRERA

COLA-CASE: POTENCIANDO EL MODELADO CONCEPTUAL CON PATRONES
DE COLABORACIN

AUTORA: FELICIDAD PADILLA LPEZ DIRECTOR: FRANCISCO MONTERO SIMARRO

JUNIO, 2008

RESUMEN

Dentro del proceso de desarrollo de software, con el tiempo, se han demostrado cada vez ms importantes las primeras fases del desarrollo del mismo. Concretamente, con el tiempo las labores de programacin dejaron paso a las de diseo y, an as, fruto de sntomas claros de una aparentemente dolencia crnica denominada crisis del software se recurri a potenciar las fases de ingeniera de requisitos. De una u otra manera, son en estas fases en las que se llevan a cabo labores de ingeniera de sistemas y de informacin, la planificacin del proyecto, la ingeniera de requisitos y el modelado de sistemas a diferentes niveles de abstraccin de una forma cada vez ms sistemtica. Posteriormente, en el resto de fases que caracterizan el proceso de desarrollo se llevarn a cabo el diseo del software, la generacin de cdigo, las pruebas de software en la fase de desarrollo, y los cambios necesarios de correccin, de adaptacin, de mejora y de prevencin en la fase de mantenimiento. Todas estas otras fases y labores son igualmente importantes pero quedan o se muestran determinadas en tiempo y coste por las fases inciales. En las fases de anlisis de los requisitos y el proceso de diseo, entre otras, una tarea se ha demostrado especialmente interesante y reveladora para el xito posterior del desarrollo. Dicha tarea es la relacionada con el modelado conceptual, que se aborda tanto en la fase de anlisis de requisitos como en el diseo. Para abordar dicha labor la experiencia se presenta determinante y dicha experiencia no est siempre disponible en los equipos de desarrollo a los que se les encomienda la produccin de software. En este sentido, un concepto, el de patrn, se ha demostrado til para abordar tareas de diseo, ejemplo revelador lo constituyen los patrones de diseo (Gamma et al., 1994), que aportan conocimiento til para poner en prctica muchas de las facilidades que permiten el paradigma orientado a objetos. En lo que respecta al modelado conceptual existe tambin experiencia en ese contexto concreto, son los patrones de colaboracin (Nicola et al., 2001) que vienen derivado de trabajos previos de Peter Coad (Coad, 1997).

En este proyecto final de carrera se pretende facilitar el uso de esta experiencia documentada y disponible que facilita labores de modelado conceptual. Para ello se han estudiado y documentado de forma activa los patrones de colaboracin y se ha trabajado en el desarrollo de un entorno, Cola-CASE, que permite el uso reiterado y sistemtico de los mismos. Las ventajas que este entorno provee se traducen en un soporte al modelado conceptual, actividad habitual en el desarrollo de software producido en estos momentos.

AGRADECIMIENTOS Y DEDICATORIAS

NDICE

Resumen.................................................................................................................................. i Agradecimientos Y Dedicatorias ..........................................................................................iii ndice ..................................................................................................................................... v ndice De Figuras ................................................................................................................. vii ndice De Tablas ................................................................................................................... ix Captulo 1 . Introduccin ....................................................................................................... 1 1.1 Especificacin e implementacin de software ........................................................ 1 1.2 Motivacin y justificacin....................................................................................... 4 1.3 Objetivos ................................................................................................................. 4 1.4 Estructura del documento ........................................................................................ 6 Captulo 2 . La importancia creciente de la especificacin frente a la implementacin ........ 9 2.1 Evolucin histrica del desarrollo de software ....................................................... 9 2.1.1 La crisis del software ..................................................................................... 12 2.1.2 Ciclo de vida del software ............................................................................. 17 2.2 El proceso de desarrollo de un sistema software .................................................. 19 2.2.1 Fundamentos del anlisis de requisitos .......................................................... 19 2.2.2 Metodologas de desarrollo del software ....................................................... 20 2.2.3 Desarrollo dirigido por modelos .................................................................... 26 2.2.4 El proceso unificado ...................................................................................... 27 2.2.5 Fases del proceso de desarrollo ..................................................................... 28 2.2.6 El proceso de desarrollo definido en Rational (RUP).................................... 29 2.3 Lenguajes y notaciones de programacin y de diseo .......................................... 31 2.3.1 Lenguajes de programacin ........................................................................... 31 2.3.2 Lenguaje unificado de modelado (UML) ...................................................... 33 2.4 Herramientas para el desarrollo del software ........................................................ 36 2.4.1 CASE ............................................................................................................. 37 2.5 La utilizacin de la experiencia............................................................................. 40 2.6 Los patrones .......................................................................................................... 41 2.6.1 Tipos de patrones ........................................................................................... 44 2.6.2 Antipatrones ................................................................................................... 45 2.6.3 Los patrones de colaboracin ........................................................................ 45 2.6.4 Formatos de los patrones disponibles ............................................................ 49 2.7 Anlisis y conclusiones ......................................................................................... 50 Captulo 3 . Integracin de los patrones de colaboracin en el proceso de desarrollo ........ 53 3.1 Introduccin .......................................................................................................... 53 3.2 Documentacin y especificacin de la aplicacin desarrollada ............................ 54 3.2.1 Objetivos ........................................................................................................ 54 3.2.2 Requisitos funcionales ................................................................................... 56 3.2.3 Requisitos no funcionales .............................................................................. 70 3.2.4 Modelado conceptual ..................................................................................... 73

3.2.5 Diagramas de secuencia ................................................................................. 78 3.3 Descripcin y almacenamiento de los patrones de colaboracin en XML ........... 81 3.4 Descripcin del entorno elaborado........................................................................ 83 3.5 Anlisis y discusin............................................................................................. 105 Captulo 4 . Caso de estudio: utilizacin del entorno facilitado ........................................ 107 4.1 Descripcin del caso de estudio .......................................................................... 107 4.2 La especificacin grfica..................................................................................... 109 4.3 La generacin de cdigo ..................................................................................... 119 4.4 Las aportaciones educativas del producto software desarrollado ....................... 125 4.5 Anlisis y discusin............................................................................................. 128 Captulo 5 . Conclusiones y Trabajo Futuro ...................................................................... 129 5.1 Conclusiones ....................................................................................................... 129 5.2 Trabajo Futuro ..................................................................................................... 130 Bibliografa ........................................................................................................................ 131 Apndice A ........................................................................................................................ 133 Patrones de Colaboracin .............................................................................................. 133

NDICE DE FIGURAS

Figura 2-1. Capas en la Ingeniera del Software .................................................................. 12 Figura 2-2. Los problemas de comunicacin y el desarrollo del software .......................... 14 Figura 2-3. Elementos del ciclo de vida de un producto software ....................................... 18 Figura 2-4. Esquema general de operacin de una fase ....................................................... 18 Figura 2-5. La metodologa es lo que posibilita la asociacin entre una solucin y un problema .............................................................................................................................. 21 Figura 2-6. Metodologas de desarrollo ............................................................................... 23 Figura 2-7. Perfil de Proyecto Tpico .................................................................................. 29 Figura 2-8. Fases e iteraciones en la metodologa RUP ...................................................... 31 Figura 2-9. Patrones de colaboracin (Nicola et al., 2001) ................................................. 47 Figura 3-1. Esquema bsico de la funcionalidad de la herramienta .................................... 55 Figura 3-2. Diagrama de casos de uso de la herramienta .................................................... 57 Figura 3-3. Diagrama de actividades para la elaboracin de un diagrama de clases ........... 58 Figura 3-4. Diagrama de paquetes ....................................................................................... 73 Figura 3-5. Diagrama de clases de la aplicacin ................................................................. 75 Figura 3-6. Diagrama de secuencia para insertar patrn sustituyendo clases ...................... 79 Figura 3-7. Diagrama de secuencia para insertar patrn sin sustituir clases ....................... 80 Figura 3-8. Modelo de dominio de clases ............................................................................ 82 Figura 3-9. Patrn Actor-Role ............................................................................................. 83 Figura 3-10. Interfaz de la aplicacin .................................................................................. 84 Figura 3-11. Partes de una clase .......................................................................................... 87 Figura 3-12. Caractersticas de una clase............................................................................. 87 Figura 3-13. Cambio de nombre no permitido para una clase ............................................. 88 Figura 3-14. Cambio de nombre duplicado para una clase.................................................. 89 Figura 3-15. Mensaje de confirmacin para eliminar una clase .......................................... 89 Figura 3-16. Propiedades de un atributo .............................................................................. 90 Figura 3-17. Men de acciones para un atributo ................................................................. 91 Figura 3-18. Propiedades de un mtodo .............................................................................. 91 Figura 3-19. Men de acciones para un mtodo .................................................................. 92 Figura 3-20. Men de acciones para una clase .................................................................... 93 Figura 3-21. Men de acciones para una relacin ............................................................... 94 Figura 3-22. Tablas de las propiedades para cada uno de los tipos de relaciones posibles . 95 Figura 3-23. Mensaje de confirmacin para eliminar una relacin ..................................... 95 Figura 3-24. Utilizar patrn ................................................................................................. 98 Figura 3-25. Nombres de las clases de los patrones ............................................................ 99 Figura 3-26. Cambio de color de una clase ....................................................................... 100

Figura 3-27. Ventana para guardar el cdigo del diagrama de clases ............................... 101 Figura 3-28. Ventana para guardar la imagen del diagrama de clases .............................. 102 Figura 3-29. Cdigo UsiXML para un diagrama de clases ............................................... 103 Figura 3-30. Ventana para imprimir un diagrama de clases .............................................. 104 Figura 3-31. About us... de la aplicacin ....................................................................... 105 Figura 4-1. Clase compaa ............................................................................................... 110 Figura 4-2. Clase trayecto .................................................................................................. 111 Figura 4-3. Clase autobs .................................................................................................. 111 Figura 4-4. Clase persona .................................................................................................. 112 Figura 4-5. Clase empleado ............................................................................................... 112 Figura 4-6. Clase pasajero ................................................................................................. 113 Figura 4-7. Clase reserva ................................................................................................... 114 Figura 4-8. Relaciones de herencia en el diagrama ........................................................... 114 Figura 4-9. Patrn Item-SpecificItem para la relacin entre compaa y trayecto ........ 115 Figura 4-10. Patrn Group-Member para la relacin entre compaa y autobs .......... 115 Figura 4-11. Patrn Group-Member para la relacin entre compaa y empleado........ 116 Figura 4-12. Patrn SpecificItem-LineItem para la relacin entre trayecto y reserva... 116 Figura 4-13. Patrn Role-Transaction para la relacin entre pasajero y reserva. ......... 117 Figura 4-14. Relacin entre compaa y pasajero ............................................................. 117 Figura 4-15. Relacin entre trayecto y pasajero ............................................................... 118 Figura 4-16. Relacin entre autobs y trayecto ................................................................. 118 Figura 4-17. Diagrama de clases del caso de estudio: empresa de autobuses ................... 119 Figura 4-18. Generacin de cdigo Java en el directorio autobuses. ................................ 121 Figura 4-19. autobs.java................................................................................................... 121 Figura 4-20. compaa.java ............................................................................................... 122 Figura 4-21. empleado.java ............................................................................................... 122 Figura 4-22. pasajero.java .................................................................................................. 123 Figura 4-23. persona.java................................................................................................... 123 Figura 4-24. reserva.java ................................................................................................... 124 Figura 4-25. trayecto.java .................................................................................................. 124

NDICE DE TABLAS

Tabla 2-1. Diferencias entre metodologas tradicionales y giles ....................................... 25 Tabla 2-2. Comparativa herramientas CASE ...................................................................... 39 Tabla 2-3. Elementos de los patrones .................................................................................. 46 Tabla 2-4. Plantilla de un patrn segn Christopher Alexander .......................................... 49 Tabla 3-1. Caso de uso Aadir Clase ............................................................................... 59 Tabla 3-2. Caso de uso Eliminar Clase ............................................................................ 60 Tabla 3-3. Caso de uso Consultar Clase ........................................................................... 61 Tabla 3-4. Caso de uso Modificar Clase .......................................................................... 63 Tabla 3-5. Caso de uso Aadir Relacin .......................................................................... 64 Tabla 3-6. Caso de uso Eliminar Relacin ....................................................................... 64 Tabla 3-7. Caso de uso Consultar Relacin ..................................................................... 65 Tabla 3-8. Caso de uso Modificar Relacin ..................................................................... 66 Tabla 3-9. Caso de uso Utilizar Patrn ............................................................................ 67 Tabla 3-10. Caso de uso Aadir Patrn............................................................................ 68 Tabla 3-11. Caso de uso Eliminar Patrn ......................................................................... 68 Tabla 3-12. Caso de uso Modificar Patrn ....................................................................... 69 Tabla 3-13. Actor-Role.usi .................................................................................................. 83 Tabla 3-14. Iconos de la barra de herramientas del panel ................................................... 85

Captulo 1. Introduccin

1.1 Especificacin e implementacin de software

Para entender el contexto en el que se ha hecho este proyecto final de carrera hay que tener presente una serie de conceptos que vienen determinados de la evolucin histrica que ha sufrido el proceso de desarrollo del software. En el ao 1968 se habl por primera vez de crisis del software, y se acu este trmino; desde entonces y hasta nuestros das se buscan soluciones para intentar solventar este problema que acompaa al desarrollo del software. Los principales indicios que llegan a pensar en crisis del software son que los proyectos no terminan en el plazo estimado, ni se ajustan al presupuesto inicial, generando software de baja calidad, que en ocasiones no cumple con los requisitos del cliente. Y todo para obtener proyectos, muchas veces, con un cdigo de difcil mantenimiento. Las posibles causas de esta crisis pueden ser, entre otras, la complejidad que supone la tarea de programar y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios. Adems, las aplicaciones actuales son programas muy complejos, inabordables por una sola persona y no es posible estimar de una manera exacta, antes de comenzar un proyecto, cunto tiempo llevar desarrollar un programa ni cunto personal har falta. La ingeniera del software, para tratar de facilitar el proceso de desarrollo del software, realiza diagramas que describen la forma de cmo hacer las cosas, lo que ha ocasionado que surjan distintas metodologas de Anlisis y Diseo Orientadas a Objetos y herramientas CASE para facilitar la utilizacin y documentacin de estos diagramas o modelos. A mediados de los ochenta, ya exista una gran variedad de estos mtodos, lo que supona que los mismos conceptos de un diagrama tenan distinta notacin segn el mtodo del que se tratara, provocando esto una situacin de confusin y un problema de estandarizacin. Para mitigar la situacin de confusin ante los distintos mtodos existentes para el anlisis y diseo de los requisitos surge el Unified Modeling Language o Lenguaje Unificado

de Modelado (UML), que es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad, adems de estar respaldado por el OMG. Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema de software, desde una perspectiva orientada a objetos. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes de software reutilizables. UML es el lenguaje en el que est descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodologa de desarrollo de software, tal como el RUP, pero no especifica en s mismo qu metodologa o proceso usar. A medida que UML va sacando nuevas versiones, incluye nuevos diagramas para poder representar el modelo en funcin de las necesidades de cada uno. No obstante, para realizar un modelado en el anlisis del entorno que sea de utilidad para la posterior implementacin y dems fases del desarrollo, se ha considerado especialmente interesante los diagramas de clases y la especificacin conceptual. Este tipo de diagrama permite visualizar las relaciones entre las clases que involucran el sistema, y a travs de las clases modelar el entorno en estudio, describiendo la estructura del sistema. De esta manera, una clase ser la unidad bsica que encapsule toda la informacin de un objeto, sus atributos representarn alguna propiedad de la clase y sus mtodos las funciones o transformaciones que se apliquen a todos los objetos de una clase particular. Por otro lado, la orientacin a objetos, que puede describirse como el conjunto de disciplinas que desarrollan y modelan software, facilita la construccin de sistemas complejos a partir de componentes (objetos). Siguiendo este principio, surge la Programacin Orientada a Objetos (POO), que aumenta considerablemente la velocidad de desarrollo de los programas gracias a la reutilizacin de los objetos. Puede encontrarse una estrecha relacin entre las clases del modelado conceptual de UML con los objetos de la POO. En este sentido, sera ms sencillo en el momento de programar si cada escenario est plasmado en su correspondiente diagrama de clases, ya que ser inmediato identificar los objetos necesarios. As mismo, el Proceso Unificado Racional o Rational Unified Process (RUP) es un proceso de desarrollo de software, y junto con el Lenguaje Unificado de Modelado UML,

constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Hoy por hoy se tiene como objetivo aumentar la productividad y la calidad del software y para desarrollar productos de calidad se recurre a la ingeniera del software, cuya evolucin histrica ha llevado a la Model Driven Architecture (MDA), propuesta por el Object Management Group (OMG), que est siendo cada vez mas utilizada en el desarrollo de software. Con la MDA, se promueve la idea de modelos, que tanta importancia han adquirido tras el xito cosechado por UML, y de esta forma se consigue portabilidad, interoperabilidad y reusabilidad, produciendo, por tanto, software de calidad. Se conoce que uno de los factores de xito ms relevantes en el desarrollo de los proyectos software es que stos sean capaces de satisfacer las necesidades y expectativas de los usuarios. Por eso es por lo que la recogida, anlisis y definicin de las necesidades de los clientes y las caractersticas del sistema, realizadas en las primeras fases del desarrollo, cobren ms importancia que el mero hecho de la implementacin. Debido a la complejidad que supone todo el proceso de desarrollo, y en especial las fases de anlisis y diseo, se considera imprescindible la aplicacin de la experiencia para que el proyecto siga delante de una forma adecuada. Ha sido la experiencia de desarrolladores la que ha llevado a comprender que hay estructuras dentro del modelado que se repiten, que son los patrones. Para facilitar la tarea de modelado del negocio se propone recurrir al uso de estos patrones, ya que se pueden encontrar habitualmente en cualquier tipo de situacin. Una posible definicin de patrn es un modelo que se puede seguir para realizar algo. Los patrones surgen de la experiencia de los seres humanos al tratar de lograr ciertos objetivos y capturan la experiencia existente y probada promoviendo y documentando buenas prcticas. Segn el arquitecto Christopher Alexander, cada patrn describe un problema que ocurre infinidad de veces en nuestro entorno, as como la solucin al mismo, de tal modo que podemos utilizar esta solucin un milln de veces ms adelante sin tener que volver a pensarla otra vez. El uso de patrones es beneficioso en la mayora de situaciones que se dan en

cualquier proyecto medianamente complejo, ya que un sistema bien estructurado est lleno de patrones. Aun cuando, en un principio, el uso de determinados patrones de software pueda parecer una carga de trabajo adicional, la ganancia en mantenibilidad del software merece la pena. En la mayor parte de los casos, implementar las cosas bien, pensando en adoptar un patrn adaptable que permita expandir el programa mas adelante facilitar las cosas en el momento de cambiar o quitar partes del proyecto. Ms concretamente, en este proyecto se plantea el uso de patrones de colaboracin. Estos patrones son la representacin de personas, lugares, cosas y eventos; ilustrando de forma grfica concisa y no ambigua la interaccin entre dos objetos. Por otro lado, existen diversas herramientas CASE para el modelado basadas en UML pero se ha echado en falta la posibilidad de aadir la experiencia existente en el desarrollo de software a este modelado.

1.2 Motivacin y justificacin

La motivacin que lleva a la realizacin de este proyecto es la falta de consideracin observada de la experiencia relacionada con el modelado conceptual y disponible en diversos documentos disponibles, as como de un entorno de diseo para ese mismo modelado conceptual, que permita recoger el conocimiento especfico acumulado por la experiencia, en forma de patrones de colaboracin, y la opcin de poder disponer de estos patrones sistemticamente en nuestros anlisis y diseos.

1.3 Objetivos
Los principales objetivos investigados en este proyecto final de carrera son los siguientes: Justificacin documentada de la importancia del modelado conceptual e identificacin de los mecanismos que permiten llevarlo a cabo.

Estudiar y caracterizar la constante crisis que est sufriendo el desarrollo de software a causa de los grandes avances que se dan en la tecnologa hardware frente a la lenta evolucin del software. Conocer y profundizar en el Desarrollo de Software Dirigido por Modelos (DSDM) y ms concretamente la propuesta MDA (Model Driven Architecture) de OMG, que constituyen una aproximacin para el desarrollo de sistemas software, basada en la separacin entre la especificacin de la funcionalidad esencial del sistema y la implementacin de dicha funcionalidad usando plataformas de implementacin especficas. Corroborar la necesidad de una metodologa en el desarrollo de software que ofrezca un marco y un vocabulario comn para el equipo de trabajo que sirva de gua y ayude a comprobar la calidad del producto final y al seguimiento de los proyectos. Complementar UML (Lenguaje de Modelado Unificado), que es el estndar que se utiliza para el anlisis y el diseo y que apoya el uso de los modelos para obtener software de calidad, con el uso de experiencia documentada y disponible en el mbito del modelado conceptual. Identificar y caracterizar las principales herramientas CASE (Computer Aided Software

Engineering, bajo el prisma de la consideracin de la experiencia.

Justificar adecuadamente un factor clave en el desarrollo de software como es la necesidad de aportar la experiencia que el desarrollador haya adquirido a su proyecto. Identificar, estudiar y caracterizar los patrones disponibles en el mbito del modelado conceptual. Documentar los patrones encontrados de forma que puedan utilizarse de forma sistemtica desde una herramienta CASE. Contemplar la posibilidad de documentar los patrones de colaboracin utilizando un lenguaje basado en XML. Ofrecer un entorno que permita utilizar, gestionar y aprovechar la experiencia disponible en forma de patrones de colaboracin.

1.4 Estructura del documento

La memoria asociada a este proyecto se compone de los cinco captulos en los que se ha dividido el documento. En el captulo 1, el cual nos ocupa, se hace una introduccin a lo que se ver ms adelante. En primer lugar se hace un prembulo muy general a lo que es la especificacin e implementacin del software, seguido de la motivacin que ha llevado a la elaboracin del presente proyecto y los objetivos que se tendrn en cuenta para su desarrollo. En el captulo 2 se discute la creciente importancia de la especificacin frente a la implementacin. Se hace un repaso histrico de las tendencias que ha seguido el desarrollo de software, ante la bsqueda de software de calidad, desde las metodologas tradicionales hasta la programacin estructurada, con la creciente tendencia actual de la arquitectura dirigida por modelos, utilizando para ello UML y programacin orientada a objetos. Se presentan los patrones de colaboracin y se describe lo que estos nos pueden aportar en el modelado del dominio. Se hace un estudio de las herramientas CASE de las que se dispone actualmente y se subraya la idea de que, aunque ocasionalmente se ha empezado a introducir los patrones de diseo, en ningn caso se ofrece la posibilidad de introducir la experiencia que los patrones de colaboracin aportan en el uso de estas herramientas, a pesar de las ventajas que esto supondra en el diseo. En el captulo 3 se describe cmo los patrones de colaboracin pueden integrarse en el proceso de desarrollo, mediante la herramienta que se presenta. Se hace un anlisis de los requisitos necesarios para abordar el desarrollo de dicha herramienta, un diseo y una implementacin de sta, conjuntamente con la descripcin del entorno. Adems, se describe cmo se han documentado los patrones de colaboracin de Nicola et al. para poder ser utilizados de forma sistemtica por el entorno facilitado. En el captulo 4 se hace una presentacin dinmica de la herramienta desarrollada, describiendo su funcionalidad, con la ayuda de algn ejemplo, y las aportaciones que sta puede ofrecer a nivel educativo. En el captulo 5 se recogen las conclusiones obtenidas tras la elaboracin del presente proyecto, y se proponen posibles trabajos futuros en este sentido. Se resalta, una vez ms, la necesidad de incluir los patrones en el desarrollo del software, ya que eso permite facilitar la tarea mediante la recogida de la experiencia que se tiene en los distintos contextos que pueden

presentarse; en este caso, se repasan los beneficios que la inclusin de los patrones de colaboracin en el modelado del dominio nos han proporcionado tras el desarrollo de la herramienta propuesta.

Captulo 2. La importancia creciente de la especificacin frente a la implementacin

En este captulo se estudiar la evolucin histrica del desarrollo del software y se resaltar la importancia que el modelado conceptual tiene en el proceso de desarrollo. Esta actividad de modelado puede verse favorecida, como todo proceso emprico, por la experiencia de la que haga gala el analista o diseador del software. En este sentido, en este proyecto final de carrera se apuesta por complementar la experiencia del diseador con experiencia disponible y documentada en forma de patrones. Concretamente, los patrones de colaboracin (Nicola et al., 2001) se identifican como una herramienta til y perfectamente aprovechable de una forma mucho ms sistemtica.

2.1 Evolucin histrica del desarrollo de software

El desarrollo de software ha ido pasando por diversos esquemas de ciclo de vida, desde los artesanales de sus inicios hasta los altamente estructurados. Por eso los desarrolladores han tenido que ir adaptndose a estos cambios. En los primeros desarrollos de software, el ingeniero solamente necesitaba conocer un modelo de ciclo de vida del software, manejar una tecnologa y ser capaz de construir una aplicacin para resolver un problema. Actualmente, el ingeniero del software debe poder integrarse en grandes equipos de desarrollo, debe tener una visin amplia de las tecnologas disponibles, debe ser capaz de comunicarse de manera eficaz con los clientes y debe entender el medio empresarial en el que ocurren los problemas que va a ayudar a resolver. Con este aumento de la complejidad en el desempeo del desarrollo, han ido apareciendo diversas propuestas que han tenido mayor o menor xito, segn el modelo elegido y el rea de aplicacin: prueba y error, cascada, prototipos evolutivos, espiral, entrega por etapas... Esta diversidad expresa una respuesta lgica a la complejidad de la actividad de desarrollo de software; complejidad que, a pesar de contar con un vasto arsenal de herramientas y conocimientos disponibles, no deja de crecer.

La evolucin de la disciplina de ingeniera de software ha trado consigo propuestas diferentes para mejorar los resultados del proceso de construccin. Una posible definicin de ingeniera de software es la disciplina del desarrollo y mantenimiento de sistemas computacionales que se comportan de manera confiable y eficiente y que su costo de desarrollo y mantenimiento puede ser pagado. Otras definiciones de este concepto que se han hecho a lo largo de los aos son las siguientes (Pressman, R., 2007): Bauer, 1972: La Ingeniera del Software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje en mquinas reales. Bohem, 1976: Ingeniera del Software es la aplicacin prctica del conocimiento cientfico en el diseo y construccin de programas de computadora y la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software. Zelkovitz, 1978: Ingeniera del Software es el estudio de los principios y metodologas para desarrollo y mantenimiento de sistemas de software. Mills, 1980: La Ingeniera del Software tiene como uno de sus principales objetivos la produccin de programas que cumplan las especificaciones, y que se demuestren correctos, producidos en el plazo y coste adecuados. Meyer, 1988: La Ingeniera del Software es la produccin de software de calidad. Ford, 1990: Ingeniera de Software es una forma de ingeniera que aplica los principios de la ciencia de los computadores y matemticas para conseguir soluciones a los problemas del software de forma efectiva y econmica. IEEE, 1993: Ingeniera de software es la aplicacin de un mtodo sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software. Sommerville, 2001: Es una disciplina que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste despus de que se utiliza. La ingeniera del software se puede ver como la composicin de cuatro partes:

Procesos de software y garanta de calidad: Los procesos de software comprenden el conjunto de actividades, tanto tcnicas como administrativas, que son necesarias para la fabricacin de un sistema de software. Estas actividades son el anlisis de los requisitos, la implantacin, la administracin de configuraciones, las pruebas, la evolucin o el mantenimiento del software etc. Un proceso adecuado ha de estar bien definido y ha de servir para lo que se especific. Si el proceso es adecuado, la probabilidad de producir un producto de buena calidad es ms alta. Arquitecturas de software y elementos estructurados: A partir de la seleccin de los elementos que van a definir la estructura de una aplicacin, hay que definir el proceso de construccin, la metodologa, la tecnologa y las herramientas. En las dcadas de los 60 y 70 era natural estructurar una aplicacin en trminos de los servicios funcionales que sta deba proveer. De hecho, las metodologas como el anlisis y diseo estructurado partan de una descomposicin funcional jerrquica que luego se transformaba en procedimientos dentro de la aplicacin. Con el aumento de la complejidad de las aplicaciones y la necesidad de hacerlas evolucionar, este enfoque no fue suficiente. En los 80 y 90 se populariz el desarrollo de software orientado a objetos que buscaba, entre otros objetivos, permitir la construccin de aplicaciones ms fciles de mantener. Hoy parecen no ser suficiente los objetos, no porque hayan dejado de ser buenos, sino porque el problema ha cambiado. Se necesita contar con arquitecturas flexibles y lo ms independientes posibles de las herramientas que se utilicen. Tecnologas de informacin: Aqu se hace referencia tanto a elementos de hardware que afectan a los sistemas de software como a los lenguajes concretos de modelado y de programacin, y a las plataformas para la construccin de algn tipo de componente software. Esta es la dimensin de la ingeniera de software que ms rpido cambia. Es la evolucin de la tecnologa lo que ha hecho que las expectativas con respecto al software cambien y sean ms exigentes. A medida que los requisitos no funcionales han ido tomando importancia, la integracin de la tecnologa se debe hacer desde las primeras etapas de diseo, y obliga al ingeniero de software a ampliar su dominio de competencias. Metodologas y tcnicas de desarrollo: Dan soporte a las actividades de anlisis, diseo, programacin, elaboracin de pruebas, administracin de riesgos, etc. Debe contar con descripciones claras sobre la manera de llevar a cabo el trabajo, de evaluar

el avance, de verificar la calidad del resultado y de validar si se produjo lo que se esperaba. Recientemente, el tema que ha despertado gran inters es el de los patrones de diseo, que son soluciones probadas a problemas particulares en contextos especficos. Si bien no son metodologas completas, son elementos claves que permiten, por un lado, manejar un vocabulario comn entre los diseadores y, adems, ofrecen elementos objetivos para justificar una decisin.

Figura 2-1. Capas en la Ingeniera del Software

La Figura 2.1 muestra un esquema con las capas que intervienen en la ingeniera del software, donde cada una de estas capas afecta al resto. De esta manera, los mtodos indican cmo construir el software, las herramientas suministran un soporte automtico para los mtodos y los procedimientos son lo que une los mtodos y las herramientas. Todo esto sin olvidar que el principal objetivo en la ingeniera del software es producir software de calidad, por lo que se aplicar la garanta de calidad del software a todo el proceso de desarrollo.

2.1.1 La crisis del software

Tradicionalmente, la Ingeniera del Software adolece de una enfermedad crnica conocida como crisis del software. ste trmino se acu en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software; y con l se etiquetaron a los problemas que surgan en el desarrollo de sistemas de software. Es el hecho de que el software que se construye no solamente no satisface los requisitos ni las necesidades pedidos por el cliente, sino que adems excede los presupuestos y los horarios de tiempos. Actualmente, las aplicaciones tpicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software. El trmino crisis

del software fue usado, desde los primeros das de la ingeniera del software, para referirse a los rpidos incrementos de la tecnologa en la computacin y la complejidad de los problemas a los cuales pudieran enfrentarse. Uno de los principales problemas en el desarrollo de software de hoy en da es que muchos proyectos empiezan la programacin tan pronto se definen y concentran mucho de su esfuerzo en la escritura de cdigo. No se debe de olvidar que la programacin es solamente una parte en el desarrollo de software, habiendo otras tareas dentro del proceso de suma importancia. ltimamente el desarrollo de software se ha ralentizado. Hay varias razones que pueden ser propuestas como causa de la crisis, las cuales no son mutuamente excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en comn que son causadas por el mtodo de valorar los avances cientficos y el mecanismo actual de financiacin de la actividad cientfica. Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa inmadurez de la ingeniera de software como una profesin. Algunos sntomas que indican que el software se encuentra en un periodo de crisis son la baja calidad del software, tiempo y presupuesto excedido, confiabilidad cuestionable y altos requisitos de personal para desarrollo y mantenimiento. Algunos de los factores que han hecho pensar que el desarrollo del software est en crisis, respecto a otras etapas de su corta historia, son el aumento del poder computacional, la reduccin del costo del hardware, la rpida obsolescencia de hardware y software, la creciente aceptacin de la computarizacin en las empresas, el incremento en el nmero de usuarios de los sistemas de software, la existencia de un tipo de usuario no homogneo en sistemas hechos a la medida y el diferente personal de desarrollado y mantenimiento. Factores tambin importantes son los cambios tecnolgicos (Internet, redes, ERP o Enterprise Resource Planning, CRM o Customer Relationship Management, SCM o Supply Chain Management), econmicos (crisis econmicas, globalizacin, etc.) y sociales (nuevas necesidades, nuevas costumbres, etc.) que se producen en el entorno. Debido a la falta de comunicacin y de entendimiento, con frecuencia, los distintos componentes del equipo de desarrollo, tienen distintos puntos de vista sobre el trabajo que deben desarrollar, y de esta manera, es difcil que lleguen a un acuerdo. Un ejemplo grfico y

con un toque de humor de las distintas formas de ver las cosas que tiene cada uno de los involucrados en el proceso de desarrollo del software se muestra en la Figura 2-2.

Figura 2-2. Los problemas de comunicacin y el desarrollo del software

Esta falta de entendimiento entre unos y otros podra solucionarse sustancialmente si al principio del desarrollo se lleva a cabo una especificacin exhaustiva de los requisitos que se esperan de la herramienta. Tambin es interesante que la especificacin se complete con un modelado donde se plasmen grficamente estos requisitos, con lo que se aadir una semntica ms difcil de explicar mediante texto y que permitir asimilar de un vistazo las condiciones de inters del proyecto, incluyendo toda la informacin que ha de manejar el sistema. Es mas, si el modelo refleja la forma en que las actividades del proyecto influirn sobre la condicin de inters, entonces la implementacin del proyecto conducir a los resultados deseados. Por otro lado, cualquier cambio relativo a requisitos u otras fuentes de informacin se podr afrontar de manera ms eficaz, haciendo ms cmodo el mantenimiento.

Este mal endmico que sufre la industria del software desde sus orgenes no parece tener una solucin definitiva hasta ahora, aunque ha habido muchas iniciativas para atenuar los efectos de esta crisis. Una de las ms importantes es la aplicacin de sistemas de aseguramientos de calidad al desarrollo de software, los que se basan sobre las siguientes ideas: El software debe ser pensado, diseado y desarrollo como un producto sujeto a normas de calidad. El software es un producto desarrollado por grupos de personas cuya interaccin debe ser gestionada. El nfasis en el proceso de desarrollo asegura un producto adecuado a los requisitos de los clientes. La solucin a la crisis del software pasa por un cambio de mentalidad de los protagonistas de su desarrollo: jefes de proyecto, analistas, programadores, usuarios, etc. Esto conduce a una idea que cada vez encuentra ms fundamentos y adherentes; la crisis del software puede ser reducida a travs de la educacin, es decir educando adecuadamente la prxima generacin de profesionales del software, de modo que ellos sean naturales e inmediatos aplicando conceptos como calidad y desarrollo en equipo. En lo concerniente al desarrollo de software se debe incentivar la planificacin, realizacin, medicin, seguimiento y mejora continua mediante la incorporacin de estndares y procedimientos que complementen el mtodo de desarrollo utilizado, haciendo nfasis en los sistemas de gestin de la calidad que pueden ayudar a las organizaciones a aumentar la satisfaccin del cliente. Los clientes necesitan productos con caractersticas que satisfagan sus necesidades y expectativas. Estas necesidades y expectativas se expresan en la especificacin del producto y son generalmente denominadas como requisitos del cliente. Los requisitos del cliente pueden estar especificados por el cliente de forma contractual o pueden ser determinados por la propia organizacin. En cualquier caso, es finalmente el cliente quien determina la aceptabilidad del producto. Dado que las necesidades y expectativas de los clientes son cambiantes y debido a las presiones competitivas y a los avances tcnicos, las organizaciones deben mejorar continuamente.

La aportacin que se hizo ante esta situacin fue el planteamiento de aplicar mtodos cientficos y rigurosos al proceso de desarrollo de programas, apareciendo en escena la Ingeniera del Software y la Ingeniera de Requisitos. No han solucionado el problema, pero algo han aportado. Hasta ahora la mejor forma que funciona para afrontar de forma seria el desarrollo de una aplicacin es realizar: anlisis y requisitos + programacin + ciclo de pruebas. Pero esto tiene dos inconvenientes: el primero es que es muy difcil hacer un buen anlisis que sepa abarcar todas las necesidades del cliente antes de que ste vea el producto final (entre otras cosas porque el cliente no sabe lo que quiere); el segundo es que nadie hace el esfuerzo de analizar y especificar requisitos, teniendo dicha parte el menor peso especfico dentro de todo el desarrollo. Se ha probado que las metodologas mejoran la calidad del software, al ser estas un proceso estudiado y probado, que indica los pasos a seguir durante el proceso de desarrollo, por eso es aconsejable su utilizacin. Actualmente los nuevos sistemas de informacin son costosos en tiempos y recursos, la solucin moderna de los actuales sistemas exigen nuevas herramientas y metodologas para poder resolver, de forma rpida, econmica y eficiente los problemas de informacin planteados por algunas empresas. Debemos de reconocer los problemas y causas para llegar a solucionarlos mediante la combinacin de mtodos completos para todas las fases del desarrollo del software, con ayuda de las tcnicas que actualmente existen como la re-ingeniera de software, la programacin orientada a objetos y lo que es UML, inclusive el uso de herramientas CASE. En definitiva, para tratar de paliar los efectos de la crisis, el proceso de desarrollo del software se vera favorecido por la presencia de tres elementos clave que se conforman en la siguiente tupla: <notacin, proceso, herramientas>. Una notacin extendida y aceptada que permita documentar, visualizar, especificar y discutir a un nivel de abstraccin suficiente que posibilite las contribuciones de los diferentes roles involucrados en el proceso de desarrollo. Un proceso sistemtico, iterativo, incremental, trazable y dirigido por modelos que posibilite abordar el desarrollo del software con ciertas garantas. Finalmente, un conjunto de herramientas que soporten tanto las notaciones disponibles como los procesos empleados, siendo especialmente

importantes la flexibilidad de las mismas para poder utilizar y reutilizar la experiencia reunida por los desarrolladores fruto de su bagaje como desarrollador.

2.1.2 Ciclo de vida del software

Todo proyecto de ingeniera tiene unos fines ligados a la obtencin de un producto, proceso o servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestin del proyecto. Al conjunto de las fases empleadas se le denomina ciclo de vida. Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologas empleadas. La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamao, con lo que rpidamente se hara inabordable si no fuera por la vieja tctica de divide y vencers. De esta forma la divisin de los proyectos en fases sucesivas es un primer paso para la reduccin de su complejidad, tratndose de escoger las partes de manera que sus relaciones entre s sean lo ms simples posibles. La definicin de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratacin de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad tambin se ve facilitado si la separacin entre fases se hace corresponder con puntos en los que sta deba verificarse, mediante comprobaciones sobre los productos parciales obtenidos. De la misma forma, la prctica acumulada en el diseo de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor se adapte a nuestros requisitos. Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Segn el modelo de ciclo de vida, la sucesin de fases puede ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se considera una misma fase

se pueda ejecutar ms de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecucin aportaciones de los resultados intermedios que se van produciendo (realimentacin).

Figura 2-3. Elementos del ciclo de vida de un producto software

Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.

Figura 2-4. Esquema general de operacin de una fase

Las principales diferencias entre distintos ciclos de vida radican en el alcance del ciclo dependiendo de hasta dnde llegue el proyecto correspondiente, las caractersticas de las fases en que dividen el ciclo y en la estructura de la sucesin de las fases que puede ser lineal, con prototipado, o en espiral.

2.2 El proceso de desarrollo de un sistema software

El proceso de desarrollo del software es la base para que todo proyecto, independientemente de cual sea su porte, se realice de forma correcta y entendible. Este proceso contempla el ciclo de vida de desarrollo completo, abarcando desde la entrega de las especificaciones por parte del cliente, hasta la estabilizacin y aceptacin del producto por el equipo de desarrollo.

2.2.1 Fundamentos del anlisis de requisitos

Antes de involucrarse en el proceso de desarrollo propiamente dicho, se ha de hacer la definicin del proceso, esto es un anlisis detallado de los requisitos del sistema para que este pueda llegar a tener las caractersticas deseadas. El anlisis de los requisitos es el conjunto de tcnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es la etapa ms crucial del desarrollo, ya que de esta depende que el resto del proceso sea correcto o no. La tarea de anlisis de los requisitos es un proceso de descubrimiento y refinamiento, dnde el mbito del programa, establecido inicialmente durante la ingeniera del sistema, es refinado en detalle. En esta parte del desarrollo se analizan y asignan a los distintos elementos del programa las soluciones alternativas. El IEEE (Instituto de Ingenieros Elctricos y Electrnicos) divide los requisitos en funcionales y no funcionales. Siendo los requisitos funcionales la condicin o capacidad de un sistema requerida por el usuario para resolver un problema o alcanzar un objetivo; y los requisitos no funcionales la condicin o capacidad que debe poseer un sistema para satisfacer un contrato, un estndar, una especificacin u otro documento formalmente impuesto.

Para realizar bien el desarrollo de software es esencial realizar una especificacin completa de los requisitos para el software final. Independientemente de lo bien diseado o codificado que est, un programa pobremente especificado decepcionar al usuario y har fracasar el desarrollo. Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificacin de requisitos. El cliente intenta reformular su concepto, algo nebuloso, de la funcin y comportamiento de los programas en detalles concretos y el desarrollador acta como interrogador, consultor y el que resuelve los problemas. Esta fase debe incorporar una tarea de especificacin conceptual donde a partir de la descripcin de los requisitos de usuario, se intenta obtener un esquema conceptual que represente una solucin al problema. Ser una representacin grfica de las entidades y relaciones que participan en el sistema. Estos diagramas, que inicialmente se hacan generalmente mediante una notacin propia, se realizan, desde los inicios de UML con este lenguaje, lo que facilita la comunicacin al poder entender cualquier persona su significado. Estos modelos conceptuales son independientes del sistema de gestin de bases de datos, tienen un mayor nivel de abstraccin que el texto, mayor capacidad semntica y estn ms enfocados al diseo de alto nivel. El anlisis y especificacin de requisitos puede parecer una tarea relativamente sencilla, pero no lo es tanto. Puesto que el contenido de comunicacin es muy alto, abundan los cambios por mala interpretacin o falta de informacin. El dilema con el que se enfrenta un ingeniero de software puede ser comprendido repitiendo la sentencia de un cliente annimo: S que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creste or sea lo que yo quise decir.

2.2.2 Metodologas de desarrollo del software

El desarrollo de un programa que resuelva un problema dado es una tarea compleja, ya que es necesario tener en cuenta de manera simultnea muchos elementos. Por lo tanto, es indispensable usar una metodologa de programacin. Para ello, antes de escribir cdigo y ms cdigo es necesario haber planificado cada parte del proceso.

Una metodologa indica cmo seguir uno o varios ciclos de vida y para ello define las tcnicas, entre las que estn los modelos y los procedimientos, a utilizar para cada tarea y las entradas y salidas que tiene cada tarea. Una metodologa de programacin es un conjunto o sistema de mtodos, principios y reglas que permiten enfrentar de manera sistemtica el desarrollo de un programa que resuelve un problema algortmico. Estas metodologas generalmente se estructuran como una secuencia de pasos que parten de la definicin del problema y culminan con un programa que lo resuelve.

Figura 2-5. La metodologa es lo que posibilita la asociacin entre una solucin y un problema

Dentro del marco global de un proceso de desarrollo, las metodologas y tcnicas dan soporte a las actividades de anlisis, diseo, programacin, elaboracin de pruebas, administracin de riesgos, etc. Las metodologas y tcnicas precisan el cmo hacer dentro de las actividades concretas de un proceso. Debe contar con descripciones claras sobre la manera de llevar a cabo el trabajo, de evaluar el avance, de verificar la calidad del resultado y de validar si se produjo lo que se esperaba. Los pasos de una metodologa, de una manera general, son los siguientes: El dilogo: Con el cual se busca comprender totalmente el problema a resolver. La especificacin: Con la cual se establece de manera precisa las entradas, salidas y las condiciones que se deben cumplir. Diseo: En esta etapa se construye un algoritmo que cumpla con la especificacin. Codificacin: Se traduce el algoritmo a un lenguaje de programacin. Pruebas y verificacin: Se realizan pruebas del programa implementado para determinar su validez en la resolucin del problema.

Una metodologa ofrece un marco y un vocabulario comn para el equipo de trabajo, sirve de gua en la utilizacin de las distintas tcnicas y herramientas, ayuda a comprobar la calidad del producto final y el seguimiento de los proyectos, incorpora los enfoques globales que se necesitan para solucionar los problemas de los sistemas de informacin de una empresa y resuelve muchos de los problemas y necesidades actuales existentes en el desarrollo de aplicaciones. Una metodologa debe cumplir las siguientes caractersticas: Completa: debe de tener un entorno de trabajo que aporte soluciones a las necesidades de un sistema de informacin durante todas las etapas de su ciclo de vida. Flexible: debe ser adaptable a las necesidades de cada proyecto y poder ser utilizado por todas las organizaciones, independientemente de su tamao, nivel de automatizacin y naturaleza del proyecto. Facilitar la comunicacin y documentacin del sistema: debe de proporcionar un lenguaje comn, estandarizar el vocabulario y las definiciones utilizadas y utilizar tcnicas de diagramacin. Accesible y clara: debe de ser fcil de aprender y de usar y debe de especificar los pasos a seguir en el desarrollo. Adaptable a la evolucin: debe facilitar las modificaciones y definir invariantes que aseguren puntos de referencia durante la evolucin del sistema. Que permita un control de calidad y gestin de proyectos: integrando tcnicas que faciliten la planificacin. En un principio, cuando empez el desarrollo de software, no se utilizaba ninguna metodologa, ya que los proyectos eran de poca envergadura y era suficiente con un desarrollo artesanal, pero con el aumento de la complejidad del software se hizo indispensable la utilizacin de nuevos mtodos que ayudaran y pusieran un poco de orden en el desarrollo. Las metodologas de desarrollo y mantenimiento de sistemas de informacin las podemos clasificar, atendiendo a los diferentes enfoques. Las metodologas estructuradas surgen a finales de los aos 70, fruto de la ampliacin de una serie de criterios de la programacin estructurada a otras etapas del ciclo de

vida. Intentan solucionar problemas tcnicos para obtener un sistema mecanizado. Se apoya generalmente en el ciclo de vida clsico en cascada y se diferencia de esta en el nmero de etapas que soporta cada una. La historia de las metodologas orientadas a objetos va unida a la evolucin de los lenguajes de programacin orientada a objeto. A fines de los 80s comenzaron a consolidarse algunos mtodos Orientados a Objeto. En 1995 aparece el Mtodo Unificado, que posteriormente se reorienta para dar lugar al UML, la notacin orientada a objetos ms popular en la actualidad, de la cul se hablar en un prximo apartado. Una de las metodologas orientadas a objetos basadas en UML ms importantes es RUP, de la cul se hablar tambin mas adelante. La Figura 2-6 muestra los principales representantes de las metodologas tradicionales, adems de las dos alternativas posibles, MDD y metodologas giles, que a continuacin se comentan.

Figura 2-6. Metodologas de desarrollo

Las metodologas tradicionales se caracterizan por exponer procesos basados en planificacin exhaustiva. Esta planificacin se realiza esperando que el resultado de cada proceso sea determinante y predecible. La experiencia ha mostrado que, como consecuencia de las caractersticas del software, los resultados de los procesos no son siempre predecibles y sobre todo, es difcil prever desde el comienzo del proyecto cada resultado.

Una posible mejora a las metodologas tradicionales es incluir en los procesos de desarrollo ms actividades, ms artefactos y ms restricciones, basndose en los puntos dbiles detectados. Sin embargo, el resultado final sera un proceso de desarrollo ms complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. La solucin a algunos de los problemas presentados por las metodologas tradicionales se logra con una gran evolucin del modelo en espiral. El proceso unificado propone la elaboracin de varios ciclos de desarrollo, donde cada uno finaliza con la entrega al cliente de un producto terminado. Otra aproximacin es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofa de las metodologas giles, cuyos objetivos son: valorar al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas; desarrollar software que funciona ms que conseguir una buena documentacin; valorar la colaboracin con el cliente ms que la negociacin de un contrato; responder a los cambios ms que seguir estrictamente un plan. Este enfoque est mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologas giles estn revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes, por escepticismo o convencimiento, no las ven como alternativa para las metodologas tradicionales. En la tabla 2.1 se resumen las diferencias entre las metodologas clsicas y las metodologas giles. La diferencia fundamental radica en que, para los clsicos, el paradigma se basa en la predecibilidad, mientras que en los giles, se basa en la adaptabilidad. No hay una regla determinante para la eleccin del mtodo, ni siquiera del tipo de mtodo. Metodologas tradicionales Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo Cierta resistencia a los cambios Impuestas externamente Metodologas giles Basadas en heursticas provenientes de prcticas de produccin de cdigo Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo)

Proceso mucho mas controlado, con numerosas polticas y normas Existe un contrato prefijado El cliente interacta con el equipo de desarrollo mediante reuniones Grupos grandes y posiblemente distribuidos Ms artefactos Ms roles La arquitectura del software es esencial y se expresa mediante modelos

Proceso menos controlado, con pocos principios No existe contrato tradicional o al menos es bastante flexible El cliente es parte del equipo de desarrollo Grupos pequeos (<10 integrantes) y trabajando en el mismo sitio Pocos artefactos Pocos roles Menos nfasis en la arquitectura del software

Tabla 2-1. Diferencias entre metodologas tradicionales y giles

Resumiendo, mientras que las metodologas tradicionales se centran especialmente en el control del proceso, mediante una rigurosa definicin de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentacin detallada, las metodologas giles dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del software con iteraciones muy cortas, con cortos documentos centrados en lo esencial. Y entre tantas diferencias entre unos tipos de metodologas y otros, se encuentra una necesidad comn: la de analizar los requisitos que tendr la herramienta. El primer paso a realizar en el desarrollo, tanto si se sigue una u otra metodologa, ser, obviamente, estudiar cules son las necesidades que se quieren cubrir con la herramienta a desarrollar. Una forma interesante de documentar estos requisitos es mediante una especificacin conceptual donde se resaltar la funcionalidad requerida del sistema. Adems, con la elaboracin de los diagramas de clases correspondientes se permite visualizar rpidamente cules son los elementos que incluir la herramienta, y sus relaciones. De esta forma, pueden modificarse los requisitos del sistema de una forma fcil y rpida, obteniendo una documentacin clara, concisa y fcil de realizar, caracterstica especialmente interesante dentro de las metodologas giles, donde no se quiere perder el tiempo con documentacin.

UML, al no ser un mtodo de desarrollo es independiente del ciclo de desarrollo a seguir, puede encajar en un tradicional ciclo en cascada, en uno evolutivo, en un ciclo en espiral o incluso en los mtodos giles de desarrollo. Cualquier centro de desarrollo puede montar su metodologa, aunque esta alternativa implica disponer del tiempo necesario para el desarrollo de la nueva metodologa; por lo tanto, lo ms prctico es seguir los mtodos que ya han demostrado su validez y son de aplicacin universal. Una buena metodologa expresa la experiencia de otros para realizar una tarea: sta es el fruto de la experiencia. Se requiere tiempo de utilizarla, evaluarla, mejorarla, volverla a utilizar, adaptarla, etc. El ciclo de aceptacin es largo y requiere tiempo. Sin embargo, la velocidad a la que las tecnologas cambian, no ha permitido que estos ciclos se completen adecuadamente. Esto explica por qu ha habido tan pocos avances metodolgicos en el rea de construccin de software o por qu este eje va ms lentamente. Recientemente, el tema que ha despertado gran inters es el de los patrones de diseo. Estos son soluciones probadas a problemas particulares en contextos especficos. Si bien no son metodologas completas, son elementos claves que permiten, por un lado, manejar un vocabulario comn entre los diseadores y, adems, ofrecen elementos objetivos para justificar una decisin.

2.2.3 Desarrollo dirigido por modelos

El Desarrollo de Software Dirigido por Modelos (DSDM), y en particular la propuesta MDA (Model Driven Architecture) de OMG, constituyen una aproximacin para el desarrollo de sistemas software basada en la separacin entre la especificacin de la funcionalidad esencial del sistema y la implementacin de dicha funcionalidad, permitiendo elevar el nivel de abstraccin, y dndole una mayor importancia al modelado conceptual y al papel de los modelos y las transformaciones entre ellos, en el desarrollo de software. Se trata de un nuevo paradigma de desarrollo, no centrado en el cdigo sino en los modelos. Con esta nueva visin se puede obtener cdigo a partir de modelos centrados en el dominio del problema e independientes de cualquier aspecto relacionado con la plataforma, mediante transformaciones de modelos. El lenguaje utilizado para la elaboracin de estos

modelos es el Lenguaje Unificado de Modelado, o UML, que ser presentado en el prximo apartado de este captulo. El desarrollo de sistemas dirigido por modelos ha demostrado, desde hace tiempo, su eficacia en el desarrollo de complejos sistemas hardware, y su aplicacin crece continuamente en el desarrollo de sistemas software (o combinaciones hardware-software), a medida que surgen metodologas y herramientas disponibles para manipular modelos software. El Desarrollo Dirigido por Modelos (MDD) se ha convertido en un nuevo paradigma de desarrollo software que promete una mejora de la productividad y de la calidad del software a travs de un proceso guiado por modelos y soportado por potentes herramientas que generan cdigo a partir de modelos.

2.2.4 El proceso unificado

Para el desarrollo de un sistema es necesario un proceso que proporcione una gua para ordenar las actividades del equipo, que dirija las tareas de los desarrolladores individuales y al equipo como un todo, que especifique qu artefactos deben desarrollarse y que ofrezca criterios para monitorear y medir las actividades y productos de un proyecto. Por lo tanto, puede decirse que el proceso de desarrollo es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software. Un proceso de desarrollo software es el Proceso Unificado (PU), que es un marco de trabajo de proceso genrico que puede especializarse para cada clase de sistemas de software, y para diferentes reas de aplicacin, tipo de organizaciones, niveles de competencia y tamaos de proyecto. El PU est basado en componentes, y esto significa que est hecho de componentes de software interconectados con interfaces. Adems, el PU usa el UML, que como se ha comentado anteriormente, ser presentado en el siguiente apartado. El PU se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso.

2.2.5 Fases del proceso de desarrollo

El PU se repite sobre una serie de ciclos que hacen la vida de un sistema. Cada ciclo consiste en: inicio, elaboracin, construccin y transicin y concluye con una release del producto, que es un producto listo para entregar.

Fase de inicio En esta fase, la meta principal es establecer el caso de negocio, es decir, estudiar la

viabilidad del desarrollo del proyecto. Para ello se delimita el alcance del sistema propuesto, se describe la arquitectura candidata del sistema, se identifican los riesgos crticos (aquellos que afectan la capacidad de construir el sistema) y se determina si hay manera de mitigarlos y se demuestra si el sistema es capaz de resolver el problema o soportar el objetivo de negocio construyendo una prueba de negocio.

Fase de elaboracin El producto principal de esta fase es una arquitectura estable para guiar el sistema por

su vida futura y la planificacin de la fase de construccin con fidelidad. Para conseguirlo, se crea una arquitectura que cubre la funcionalidad y caractersticas importantes del sistema, se identifican los riesgos significativos que pueden afectar a planes, costos y programas de fases, se especifican niveles para lograr atributos de calidad y tiempos de respuesta y se captura el 80% de los casos de uso, que son suficientes para planear la construccin.

Fase de construccin El objetivo general de esta fase es obtener la capacidad operacional inicial en un

producto listo para prueba beta. Para ello, se extiende la identificacin, descripcin y realizacin de los casos de uso; se termina el anlisis, diseo, implementacin y prueba del producto; se mantiene la integridad de la arquitectura y se monitorizan los riesgos crticos y significativos de las fases anteriores y, en caso de que se presenten, se mitigan.

Fase de transicin Esta fase empieza con la liberacin beta del producto. En ella se prepara la instalacin;

se advierte al cliente sobre actualizaciones de SO, hardware, protocolos de comunicaciones,

etc.; se preparan manuales y documentacin; se ajusta el software para operar bajo parmetros actuales del ambiente del usuario; se corrigen defectos despus de pruebas beta y se modifica el software en caso de que se presenten problemas no previstos.

Figura 2-7. Perfil de Proyecto Tpico

En la Figura 2-7 se observa la relacin que hay entre tiempo y recursos necesarios en cada una de las fases expuestas. El producto final consiste de cdigo fuente incluido en componentes que se puede compilar y ejecutar, ms manuales y entregables asociados. Adems, tiene que satisfacer las necesidades no slo de usuarios, sino de toda la gente que trabajar con el producto. El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba, la arquitectura y modelos visuales, que estos sern artefactos modelados con UML. Aun si los componentes ejecutables son los artefactos ms importantes, por si solos no son suficientes porque el ambiente cambia (sistema operativo, sistemas de bases de datos, avance tecnolgico,...).

2.2.6 El proceso de desarrollo definido en Rational (RUP)

En los ltimos aos se han definido numerosos procesos que se ajustan a los principios del proceso unificado. El proceso ms extendido ha sido el RUP (Rational Unified

Process), que puede ser una buena metodologa de desarrollo a tener en cuenta para proyectos medianos y grandes, adems de ser el ejemplo por excelencia de metodologa orientada a objetos. El RUP es un proceso de desarrollo de software que junto con el UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. Se caracteriza por la forma disciplinada de asignar tareas y responsabilidades y pretende implementar el desarrollo iterativo, la administracin de requisitos, el uso de arquitectura basada en componentes, el control de cambios, el modelado visual del software y la verificacin de la calidad del software. El RUP es un producto de Rational (IBM). Incluye artefactos, que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.; y roles, que es el papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso. RUP est basado en el seguimiento de una serie de normas o mejores prcticas aplicadas a cuatro etapas o ciclos en las diversas iteraciones del desarrollo: Inicio, Elaboracin, Construccin y Transicin. Cada ciclo se divide en fases que finalizan con un hito donde se debe tomar una decisin importante: Inicio: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Elaboracin: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos. Construccin: se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario. Transicin: se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.

Figura 2-8. Fases e iteraciones en la metodologa RUP

2.3 Lenguajes y notaciones de programacin y de diseo

Existen muchas notaciones para representar los artefactos del diseo del software. Algunas se utilizan principalmente para describir la organizacin estructural de un diseo, otras para representar comportamiento del software. Ciertas notaciones se utilizan sobre todo durante el diseo arquitectnico y otros principalmente durante el diseo detallado, aunque algunas notaciones se pueden utilizar en ambos pasos.

2.3.1 Lenguajes de programacin

Un paradigma de programacin representa un enfoque particular o filosofa para la construccin del software. Diferentes paradigmas resultan en diferentes estilos de programacin y en diferentes formas de pensar la solucin de problemas. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas. Tambin hay situaciones donde un paradigma resulta ms apropiado que otro. Segn el paradigma de programacin que utilizan, se pueden clasificar los siguientes lenguajes:

Lenguajes Imperativos: La programacin imperativa describe la programacin en trminos del estado del programa y una secuencia de sentencias que cambian dicho estado. Los programas imperativos son un conjunto de instrucciones que le indican al computador cmo realizar una tarea. El cdigo mquina en general est basado en el paradigma imperativo. Lenguaje Estructurado: La programacin se divide en bloques (procedimientos y funciones) que pueden o no comunicarse entre s. Adems, la programacin se controla con secuencia, seleccin e iteracin. Permite reutilizar cdigo programado y otorga una mejor compresin de la programacin. Es simplemente un bloque, como por ejemplo, los archivos batch (.bat). Lenguaje Lgico: Se basa en la definicin de reglas lgicas para luego, a travs de un motor de inferencias lgicas, responder preguntas planteadas al sistema y as resolver los problemas. Comprende dos paradigmas de programacin: la programacin declarativa y la programacin funcional. La programacin declarativa gira en torno al concepto de predicado, o relacin entre elementos. La programacin funcional se basa en el concepto de funcin, de corte ms matemtico. Lenguaje Declarativo: Se enfoca en describir las propiedades de la solucin buscada, dejando indeterminado el algoritmo usado para encontrar esa solucin. Es ms complicado de implementar que el paradigma imperativo, tiene desventajas en la eficiencia, pero ventajas en la solucin de determinados problemas. Lenguajes Funcionales: Basado en la utilizacin de funciones matemticas, para conseguir lenguajes expresivos y matemticamente elegantes, en los que no sea necesario bajar al nivel de la mquina para describir el proceso llevado a cabo por el programa, y evitando el concepto de estado del cmputo. Lenguajes Orientados a Objetos: Define los programas en trminos de "clases de objetos". Estos objetos son entidades que combinan estado, comportamiento e identidad. El estado est compuesto de datos, y el comportamiento por procedimientos o mtodos. La identidad es una propiedad de un objeto que lo diferencia del resto. La programacin orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y mdulos ms fciles de escribir, mantener y reutilizar.

Su principal ventaja es la reutilizacin de cdigo y su facilidad para pensar soluciones a determinados problemas. Aunque hay que tener en cuenta que la programacin es solo una pequea parte de todo lo que conlleva la ingeniera del software. Debe quedar claro y patente que el paradigma orientado a objetos ha supuesto un cambio radical y un punto de inflexin en la evolucin y disponibilidad de propuestas de desarrollo del software y gracias a este punto de apoyo otras propuestas posteriores han sido posibles.

2.3.2 Lenguaje unificado de modelado (UML)

Se necesita de una metodologa de trabajo para que todo el mundo, desde un principio, genere una documentacin escasa y til. Tambin hace falta que, cuando las aplicaciones estn construidas, se establezcan unos procedimientos sencillos para que, a medida que se van produciendo mejoras, se vaya generando o completando la documentacin deficiente. Realizar un buen anlisis o reingeniera requiere de tcnica. A menudo no se tiene un procedimiento estructurado que haga predecible tal anlisis y se tiende a pensar que las herramientas solucionarn los problemas. Las herramientas son solo el soporte y debemos basarnos en un hbito en el trabajo. Sin mtodo y disciplina, la cosa no mejorar. El nico modo de resolver el problema es a travs de la formacin personalizada y la implantacin de buenos hbitos y tcnicas sobre: direccin moderna de proyectos informticos, estimacin rpida de proyectos, gestin eficaz del tiempo, motivacin de equipos, anlisis y diseo orientado a objeto, UML y modelado de datos y tcnicas avanzadas de diseo (patrones). Una vez que ya han sido recopilados, clasificados y alojados en el nivel de jerarqua que les corresponde, hay que poner por escrito los requisitos del sistema. El lenguaje de especificacin o modelado representa el vehculo indispensable para la comunicacin entre los participantes y para la representacin de conceptos a lo largo de todo el proyecto, utilizando una semntica comn. Por eso, desde mediados de los 70 hasta finales los 80 aparecieron una serie lenguajes orientados a la modelacin de programas orientados a objetos, ya para mediados de los 90

haba mas de 50 lenguajes y metodologas que satisfacan caractersticas muy especificas de modelado, provocando que los usuarios tuviesen problemas para satisfacer sus necesidades con una u otra metodologa. Se necesitaba, por tanto, un lenguaje no slo para comunicar las ideas a otros desarrolladores sino tambin para servir de apoyo en los procesos de anlisis de un problema. Con este objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). En 1994 el desarrollo de UML fue iniciado por Grady Booch y Jim Rumbaugh de Rational Software Corporation, con la unificacin de las metodologas Booch y OMT (Object Modeling Technique), en el otoo del 95 Ivar Jacobson se uni junto con su compaa Objetory a Rational, con la finalidad de unificar esfuerzos, integrando la metodologa OOSE (ObjectOriented Software Engineering). UML se convirti en ese estndar tan anhelado para representar y modelar la informacin con la que se trabaja en las fases de anlisis y, especialmente, de diseo. Actualmente, UML es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; adems de ser un estndar, est apoyado en gran manera por el OMG (Object Management Group), grupo que gestiona estndares relacionados con la tecnologa orientada a objetos, del cual forman parte las empresas ms importantes que se dedican al desarrollo de software. La ltima versin aprobada es la UML 2.0. En estos momentos se estn desarrollando actualizaciones a esta versin en la que se incluirn cambios importantes, principalmente, aadir nuevos diagramas. Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estndar para describir un plano del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes de software reutilizables. UML ha sido diseado para modelar cualquier tipo de proyectos, tanto informticos como de arquitectura, o de cualquier otro ramo. La aparicin de UML supuso el reconocimiento de la actividad del modelado (diseo basado en modelos) como una actividad clave para producir software de calidad.

Los objetivos que pretende cumplir UML son los siguientes: UML es un lenguaje de modelado de propsito general que pueden usar todos los modeladores. No tiene propietario y est basado en el comn acuerdo de gran parte de la comunidad informtica. UML no pretende ser un mtodo de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una slida arquitectura para resolver requisitos dirigidos por casos de uso. Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo suficientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribucin, as como tambin los mecanismos de la ingeniera de software, como son la encapsulacin y componentes. Debe ser un lenguaje universal, como cualquier lenguaje de propsito general. Imponer un estndar mundial. A pesar de su status de estndar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva. Otro problema que tiene UML es que no se presta con facilidad al diseo de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisin, serializacin, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para sealar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecucin del sistema analizado. Otra de las crticas que se han comentado de UML es la carencia de patrones integrados con el lenguaje. Los patrones hacen ms fcil y rpido el modelado, pero UML no dispone de ellos. Con UML, lo que se pretende es lograr que los lenguajes que se aplican siguiendo los mtodos ms utilizados sigan evolucionando en conjunto y no por separado. Y adems, unificar las perspectivas entre diferentes tipos de sistemas (no slo software, sino tambin en

el mbito de los negocios), al aclarar las fases de desarrollo, los requisitos de anlisis, el diseo, la implementacin y los conceptos internos de la OO. En resumen, UML resuelve de forma bastante satisfactoria un viejo problema del desarrollo de software como es su modelado grfico. Adems, se ha llegado a una solucin unificada basada en lo mejor que haba hasta el momento, lo cual lo hace todava ms excepcional. Es importante remarcar que UML es un lenguaje para especificar y no un mtodo o un proceso, se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir, ya que es el lenguaje en el que est descrito el modelo. Se puede aplicar en una gran variedad de formas para soportar una metodologa de desarrollo de software (tal como el Proceso Unificado de Rational) pero no especifica en s mismo qu metodologa o proceso usar.

2.4 Herramientas para el desarrollo del software

Adems de la aproximacin metodolgica y el lenguaje, uno de los factores determinantes en el xito de un proyecto de software, lo constituye la acertada seleccin de las herramientas de trabajo que se utilizarn durante su desarrollo. Es por eso que, en la actualidad, la administracin de proyectos atiende cuidadosamente la designacin de herramientas como una tarea de vital importancia. A medida que los sistemas que se construyen se tornan ms y ms complejos, las herramientas de modelado con UML ofrecen muchos beneficios para todos los involucrados en un proyecto, por ejemplo, administrador del proyecto, analistas, diseadores, arquitectos, desarrolladores y otros. Las herramientas CASE de modelado con UML nos permiten aplicar la metodologa de anlisis y diseo orientados a objetos y abstraernos del cdigo fuente, en un nivel donde la arquitectura y el diseo se tornan ms obvios y ms fciles de entender y modificar. Cuanto ms grande es un proyecto, es ms importante utilizar una herramienta CASE.

2.4.1 CASE
Las herramientas CASE surgen a principios de la dcada de los 80, pero pronto se extendieron a la mayor parte de las fases y actividades involucradas en el desarrollo de software. Las herramientas CASE estn tomando cada vez mas relevancia en la planificacin y ejecucin de proyectos que involucren sistemas de informacin, pues suelen inducir a sus usuarios a la correcta utilizacin de metodologas que le ayudan a llegar con facilidad a los productos de software construidos. Las Herramientas CASE (Computer Aided Software Engineering - Ingeniera del Software Asistida por Ordenador) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos 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 diseo del proyecto, clculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. Todas las herramientas CASE prestan soporte a un lenguaje de modelado para acompaar la metodologa y es lgico suponer que un alto porcentaje de ellas soportan UML, teniendo en cuenta la amplia aceptacin de este lenguaje y el valor conceptual y visual que proporciona y su facilidad para extender el lenguaje para representar elementos particulares a determinados tipos de aplicaciones. Evidentemente, debido a la popularidad que han ido adquiriendo UML y MDA en los ltimos aos, existe en el mercado una gran variedad de herramientas de modelado de diagramas UML. Las herramientas CASE son una combinacin de herramientas de software y metodologas estructuradas de desarrollo que han surgido para dar solucin a varios problemas inherentes al software, pero principalmente nacen para solucionar el problema de la mejora de la calidad del desarrollo de sistemas de mediano y gran tamao, y en segundo lugar, por el aumento de la productividad. La mejora de la calidad se logra al reducir sustancialmente muchos de los problemas de anlisis y diseo relacionados con los proyectos, como la lgica en el diseo y la coherencia

entre mdulos, entre otros. Simultneamente, la mejora de la productividad se consigue a travs de la automatizacin de tareas, como la generacin y reutilizacin de cdigo, que son puntos importantes a considerar en una herramienta CASE. Los objetivos que siguen las herramientas CASE son: Mejorar la productividad en el desarrollo y mantenimiento del software. Aumentar la calidad del software. Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos. Mejorar la planificacin de un proyecto Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. Automatizar, desarrollo del software, documentacin, generacin de cdigo, pruebas de errores y gestin del proyecto. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la documentacin Gestin global en todas las fases de desarrollo de software con una misma herramienta. Facilitar el uso de las distintas metodologas propias de la ingeniera del software. En este proyecto se da mucha importancia a la experiencia y, concretamente, a la disponible para elaborar especificaciones conceptuales, cosa que, como puede apreciarse en la Tabla 2-2, dnde se ha hecho una comparativa de algunas de las herramientas CASE ms relevantes, atendiendo a las caractersticas ms destacables a tener en cuenta, no es muy habitual su consideracin. Se ha observado que en alguna de las herramientas que se utilizan con objetivo ms profesional s incluye la utilizacin de patrones. No obstante, solamente se contemplan los patrones de diseo.

PROPIEDADES Web Observaciones generales

ARGOUML argouml.tigris.org Navega de acuerdo con diferentes perspectivas de modelado y de metodologa de desarrollo

RATIONAL ROSE www.rational.com Provee productos de UML para los lenguajes comunes de la industria para especificacin, visualizacin, construccin y documentacin de los artefactos de los sistemas software

WITHCLASS www.microgold.com Utiliza perspectiva objeto relacional con diferentes metodologas de desarrollo y modelado

TOGETHER www.borland.com Robusta y slida plataforma de Borland fcilmente integrable a JBuilder. Usa refactoring y patrones. Apoya procesos de testing a travs de un marco apropiado. Es extensible a necesidades de estndar de la organizacin

mbito de utilizacin

Plataforma

Apoyo metodolgico

Sus caractersticas se ajustan a Se enmarca dentro del Sus caractersticas se apoyan proyectos acadmicos y de desarrollo de modelado para en el desarrollo orientado a investigacin fines acadmicos y objetos para proyectos comerciales acadmicos, investigativos y de comercializacin Independiente de la Sistema Operativo Windows Sistema Operativo Windows Plataforma. Requiere Mquina Virtual Java 1.3 o superior No apoya una metodologa UML, Booch y OOSE; todas OMT, UML, Booch, Martinespecfica ellas apoyadas en RUP. Odell, Coad-Yourdon. Soporta MVC.

Se ajusta a grandes proyectos de ingeniera de software en los que la confiabilidad y administracin de la informacin sean relevantes Funciona sobre una mquina virtual Java Refactoring, testing Framework, desarrollo de plantillas y patrones. Apoya el desarrollo de Web Aplication Wservice. utilizacin

POSEIDON www.gentleware.com Herramienta de Gentleware que genera cdigo en Java usando plantillas, realiza ingeniera inversa y sincronizacin de cdigo en Java. Se puede considerar la versin comercial y mejorada de ArgoUML. Apoya el proceso de documentacin de diagramas con UML.doc Sus caractersticas se apoyan en el desarrollo orientado a objetos para proyectos acadmicos, investigativos y de comercializacin Independiente de la Plataforma. Requiere Mquina Virtual Java 1.3 o superior No apoya una metodologa especfica. A travs del browser sugiere cierta organizacin de proyecto.

Mtricas

No hay mtricas

Apoya la mtricas

utilizacin

de Apoya la mtricas

utilizacin

de Apoya la mtricas

de No hay mtricas

Autogeneracin

Java, C++, PHP

Edicin de cdigo

Java

Java, J2EE, ANSI, C++, C++, C#, Java, Delphi, VB, VB, VB.NET, CORBA IDL, Java, HTML, C++ y XML. Visual C++, VB, CORBA VB.NET C++ Plugins para C#, CORBA IDL IDL, MIDL y XML Visual Basic, Java Add-in para otros editores Java Eclipse y JBuilder OCL para JAVA

Tabla 2-2. Comparativa herramientas CASE

Adems de las herramientas CASE ms comunes, comentadas en la tabla, cabe comentar la existencia de Hypermodel, una herramienta basada en Eclipse, que sirve para el diseo dirigido por modelos de esquemas XML y SOA. Es una herramienta de anlisis y diseo que trabaja bien en combinacin con otras herramientas UML2, como Rational, y ofrece modelos UML y diagramas de cualquier esquema XML, permitiendo transiciones automticas de uno a otro formato.

2.5 La utilizacin de la experiencia

En el libro "The Knowledge-Creating Company", de Ikujiro Nonaka y Hirotaka Takeuchi, se plantea la diferencia entre aprender y generar conocimiento, y revalora la importancia del conocimiento tcito y su papel en la generacin de conocimiento. Sus autores aseguran que El aprendizaje ms importante proviene de la experiencia directa. Anteriormente se ha hablado de la importancia de la experiencia adquirida en otros proyectos para poder utilizar el enfoque que mejor se adapte a los requisitos, en cuanto al ciclo de vida del software. Pero para obtener experiencia hay que practicar. Por eso se pretende poder aprovechar la experiencia obtenida por desarrolladores cultivados para que pueda ser aplicada por los desarrolladores noveles. Tambin se comentaba en apartados anteriores que una buena metodologa expresa la experiencia de otros para realizar una tarea. Esta es una parte donde se utiliza el conocimiento adquirido por gente especializada en el desarrollo del software. Adems se hablaba del inters que estn adquiriendo los patrones de diseo como elementos clave dentro de la metodologa utilizada. La forma en que un programador experto y uno novato se enfrentan a un sistema complejo es distinta, sobretodo, porque la forma en que un individuo resuelve un problema se ve claramente influenciada por la experiencia adquirida al trabajar situaciones ms o menos parecidas. Desde el principio qued patente que sera un gran avance poder capturar esa experiencia, de modo que la forma correcta de resolver un problema dado pudiera ser transmitida a individuos que todava no se han topado con el. La idea es que si ya se ha solucionado un problema dado, esa misma solucin podra servir para problemas parecidos.

2.6 Los patrones

Este planteamiento de formalizar soluciones a distintas situaciones, de modo que puedan ser entendidas por otros profesionales, es lo que se llama patrones. Por tanto, un patrn no es ms que la descripcin detallada de una solucin adecuada a un problema concreto; o, dicho de otra forma, un modelo que podemos seguir para realizar algo. El objetivo bsico que se persigue con la idea de patrn es aprovechar lo que ya ha sido utilizado con xito anteriormente, en casos similares al nuestro, y adaptarlo a nuestras condiciones para obtener la solucin ms fcilmente. Los patrones surgen de la experiencia de los seres humanos al tratar de lograr ciertos objetivos y capturan la experiencia existente y probada para promover buenas prcticas. Fueron inicialmente concebidos por el arquitecto Christopher Alexander como una manera de formalizar la solucin a problemas comunes a muchos proyectos de arquitectura. Este arquitecto escribi dos libros revolucionarios que describan patrones en arquitectura de construccin y planificacin urbana (Alexander, 77) y (Alexander, 79). Segn Alexander, el lenguaje de patrones brinda a todo el que lo utilice el poder de crear una infinita variedad de construcciones nuevas y nicas, de la misma forma que el lenguaje comn brinda el poder de crear una infinita variedad de oraciones. Ms tarde, vista la eficacia de los patrones en el campo de la arquitectura, otras disciplinas los aadieron a su repertorio de herramientas y las ideas presentadas en estos libros son aplicadas a varios campos adems de la arquitectura, incluyendo el software. Christopher Alexander crea que muchos procesos implicados en el diseo de estructuras fsicas eran variables, pero que exista un invariante comn, que defina los principios generales del diseo y construccin. El descubrimiento de las invariantes aplicables al diseo de software es hoy el objetivo de los desarrolladores de software, pues proporcionan un marco comn de conocimiento y soluciones. Se necesita de aos de experiencia adquirir el conocimiento necesario para lidiar con los requisitos cambiantes de los proyectos. Los patrones son la forma de difundir ese conocimiento, evitando la demora necesaria para que un experto instruya a otros.

La adaptacin de este concepto a la ingeniera del software ha dado lugar a lo que conocemos como patrones software. Estos patrones capturan soluciones a situaciones de especial inters, bien por ser muy comunes, bien por ser especialmente complejas. En 1987, Ward Cunningham y Kent Beck usaron algunas de las ideas de Alexander y desarrollaron cinco patrones para el diseo de interfaces de usuario, que publicaron en un artculo llamado Using Pattern Languages for Object-Oriented Programs. En 1994 Erich Gamma, Richard Helm, John Vlissides y Ralph Jonson, conocidos por la Banda de los Cuatro, o Gang of Tour (GoF), publicaron uno de los libros ms influyentes de esta dcada: Design Patterns (Gamma et al., 1995), que populariz la idea de patrones. La reaccin a este libro fue universalmente positiva y se convirti en una obra fundamental en la materia. Muchos arquitectos reconocieron en las soluciones propuestas descripciones a las que ellos mismos haban llegado independientemente. Se organizaron grupos de estudio sobre patrones y aparecieron consultoras que proporcionaban aprendizaje sobre el tema. Los patrones describen un problema que ocurre repetidas veces en algn contexto determinado del proceso de desarrollo de software, y entregan una buena solucin ya probada. La utilizacin de patrones de software facilita las cuestiones que anteriormente se comentaban como causantes de la crisis del software y es un apoyo para crear software de calidad, ya que ayuda a disear software correctamente en menos tiempo, ayuda a construir problemas reutilizables y extensibles, y facilita la documentacin y la comunicacin con otros miembros del equipo de desarrollo. La llegada de los patrones al mundo de la construccin de sistemas software ha sido una aportacin fundamental, llevando a esta disciplina a abandonar su tradicional status de artesana y acercndola al nivel de sistematizacin y robustez del que gozan otras ingenieras. Parte del inters en los patrones viene de observar que los proyectos fracasan a pesar de que se utilizan las ltimas tecnologas cuando no hay soluciones comunes. Los patrones proporcionan una manera de organizar y nombrar esas soluciones comunes para hacer ms fcil su utilizacin a la gente. Documentar buenos patrones puede ser una tarea muy difcil. Las caractersticas que ha de tener un buen patrn, segn Coplien, son las siguientes:

Resuelve un problema: Los patrones capturan soluciones, no principios o estrategias abstractas. Es un concepto probado: Capturan soluciones, no teoras o especulaciones. La solucin no es obvia: Muchas tcnicas de resolucin de problemas, como los paradigmas o mtodos de diseo de software, intentan derivar soluciones desde principios bsicos. Los mejores patrones generan una solucin a un problema indirectamente, un enfoque necesario para los problemas de diseo ms difciles. Describe una relacin: Los patrones no describen mdulos sino estructuras y mecanismos. Tiene un componente humano significante: El software sirve a las personas. Los mejores patrones se aplican a la esttica y a las utilidades. Un lenguaje de patrones contiene un amplio conjunto de patrones, cuyas combinaciones conforman su gramtica. Un sistema de patrones mantiene unidos a sus patrones. Describe la forma en que se conectan y cmo se complementan entre ellos. Un sistema de patrones facilita el uso eficaz de los patrones en el desarrollo de software. Por lo tanto, podemos decir que un sistema de patrones es una coleccin de patrones, junto con las guas para su implementacin, combinacin y uso prctico en el desarrollo de software. Los patrones no son siempre la solucin adecuada o mejor para un problema. Si bien aaden flexibilidad, tambin aaden complejidad. Es por esto que se debe ser cuidadoso al momento de seleccionar patrones. Siempre hay que recordar que los patrones son un punto de partida y que no son dogmas incuestionables. El uso de patrones es beneficioso en la mayora de situaciones que se dan en cualquier proyecto medio complejo. An cuando, en un principio, el uso de determinados patrones de software pueda suponer una carga de trabajo adicional, la ganancia que se adquiere al incorporarlos en mantenimiento del software es favorable.

2.6.1 Tipos de patrones

La mayora de referencias a patrones suelen referirse a los patrones de diseo. Sin embargo hay otros mbitos de la ingeniera del software donde se puede aplicar el concepto genrico de patrn: Patrones de diseo (Gamma et al., 1995): Describen la conducta, estructura, y colaboracin de objetos dentro de un subsistema de la aplicacin. Patrones de arquitectura (Buschmann et al., 1996): Describen la estructura general de un sistema. Identifica sus mdulos, responsabilidades, y la colaboracin entre dichos mdulos. Patrones de anlisis (Fowler, 2002): Describen un conjunto de prcticas destinadas a elaborar el modelo y solucin de un problema. Patrones de procesos o de organizacin (Coplien & Schmidt, 1995): Describen la estructura y prcticas de las organizaciones humanas, especialmente las productoras de software. Patrones de programacin idioms (Coplien, 1991): Un idiom es un patrn que describe cmo implementar ciertas tareas usando un lenguaje de programacin concreto. Patrones de colaboracin: son el tipo de patrones en el que se centra este proyecto y, por considerarlos en este caso de mayor importancia, se contemplan ms adelante, en un apartado completo. Actualmente, hay disponible una amplia literatura sobre patrones. De hecho, las principales casas de software tienen sus publicaciones sobre patrones que pueden implantarse directamente sobre sus tecnologas. Modelar con patrones tiene importantes ventajas, la ms obvia es la rapidez. Una vez que se identifica una relacin con el mundo real, sta puede sustituirse rpidamente por el modelo de dominio correspondiente a su patrn especfico de objetos. De esta manera, los patrones no solo construyen el modelo de objetos conectando objetos conocidos, tambin ayudan a encontrar nuevos objetos necesarios para rellenar un patrn identificado. Aunque, de la misma forma que utilizar patrones puede suponer un beneficio, se puede obtener el resultado contrario al utilizarlos inadecuadamente.

2.6.2 Antipatrones
Los antipatrones son soluciones negativas que presentan ms problemas que los que solucionan. Son una extensin natural a los patrones de diseo. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores ms comunes relacionados con la industria del software. En 1996 Michael Akroyd formaliza el concepto de antipatrn en su presentacin (Akroyd, 1996) centrndose en identificar errores comunes cometidos en proyectos de software. Aunque la obra de referencia ms destacada en este campo es AntiPatterns: Refactoring Software, Architectures and Projects in Crisis (Brown et al., 1998). Un antipatrn no es una mala prctica, sino la reflexin consciente sobre esa mala prctica. Su conocimiento es til porque ayuda a reconocer, corregir, y prevenir un problema. Hay dos tipos de antipatrones: aquellos que describen una mala solucin a un problema y aquellos que describen como llegar a una solucin desde un problema. Segn James Coplien, un antipatrn es algo que se ve como una buena idea, pero que falla malamente cuando se la implementa. Un buen antipatrn explica por qu la solucin original parece atractiva, por qu se vuelve negativa y cmo recuperarse de los problemas que sta genera.

2.6.3 Los patrones de colaboracin

Para abordar el modelado del dominio, Peter Coad propona sus patrones conceptuales, que fueron posteriormente adaptados a UML por Jill Nicola, Mark Mayfield y Mike Abney en sus patrones de colaboracin. Con estos patrones se permite la especificacin y el modelado de objetos en el modelado del dominio. Los patrones de colaboracin son la representacin de los componentes o pattern players: personas, lugares, cosas y eventos. Mientras el objeto describe el significado y la relevancia de los objetos, el patrn de colaboracin, con su formato grfico conciso y no ambiguo, ilustra la interaccin entre dos objetos. Por lo que exponen los grficos, y revelan los

objetos, los patrones de colaboracin dejan claro los principios de cmo trabajar juntos para crear el modelo de objetos. Personas Actor Role Place Outer Place Item Specific Item Assembly Part Container Content Group Member Transaction Composite Transaction Line Item Follow-up Transaction
Tabla 2-3. Elementos de los patrones

Lugares

Cosas

Eventos

Los patrones de colaboracin no son patrones de diseo. Los patrones de diseo se enfocan en la eficiencia, la reusabilidad, y la conectabilidad, y mientras estas son las metas importantes, se preocupan ms de cmo efectuar una interaccin que de qu es lo que debe relacionar en ella. Los patrones de colaboracin describen el qu de una interaccin, los objetos involucrados y las reglas que rigen estas interacciones. Los patrones de colaboracin son, por definicin, patrones que involucran dos de los pattern players descritos en la Tabla 2-3. Surgen patrones mayores cuando dos colaboraciones se juntan para compartir un pattern player, o cuando las colaboraciones se combinan compartiendo un objeto que acta como varios pattern players. En la Figura 2-9 se muestran los patrones de colaboracin propuestos por (Nicola et al., 2001). A continuacin se describe cada patrn de colaboracin indicando lo que representa su pattern player y cuales son sus responsabilidades. Igual de importante son las reglas que rigen las interacciones entre dos pattern players, las cules pueden consultarse en este libro.

Algunos de los patrones de colaboracin descritos a continuacin son los mismos o se derivan de los patrones descritos en el libro Objects Models: Strategies, Patterns, & Aplications de Peter Coad, David North y Mark Mayfield (Coad et al., 1997). Aunque Coad utiliz una nomenclatura propia para definirlos y Nicola los adapt a UML, pudiendo ser, de esta forma, comprensibles mas fcilmente para todo el mundo, al describirse en un lenguaje estndar.

Figura 2-9. Patrones de colaboracin (Nicola et al., 2001)

En el Apndice A se ha incluido la relacin de patrones descrita por (Nicolla et al, 2001) con ms detalle, y se recomienda, si se desea tener mas informacin acerca de ellos, consultar el libro de referencia.

Como ejemplo ms completo, se ver un poco ms a fondo el patrn Actor-Role, que es uno de los patrones propuestos. Un ejemplo de patrn de colaboracin que puede considerarse para verse en detalle, segn la descripcin que hizo (Nicola et al., 2001), es el patrn Actor-Role. El patrn actor role modela las entidades que interactan en contextos mltiples. Lo ms frecuente es aplicarlo a personas, pero tambin se puede aplicar a lugares y a cosas. Este patrn se presenta en la gente, el contexto y los principios de role que sugieren dos objetos, uno describe la persona u organizacin (actor), y el segundo describe la persona u organizacin dentro de un contexto (role). Para cada contexto, se crea un nuevo role. El patrn actor role mostrado en la figura, se usa para modelar personas, lugares o cosas que participan en uno o mas contextos. Un actor puede tener mltiples roles, pero solo uno de cada tipo. El actor es responsable de conocer informacin (propiedades, servicios y colaboraciones) que son relevantes a travs de todo el contexto. EJEMPLO- En una aplicacin de comercio electrnico se rastrean personas que pueden ser clientes, empleados o agentes de bolsa. Un role conoce solo a un actor, y sin este actor, el role no es vlido. Los cambios en el actor (nuevos valores de las caractersticas o nuevas colaboraciones) pueden afectar tambin al role. Esta dependencia que sigue un actor es porque un role es una descripcin individualizada de un actor, la apariencia de un actor dentro de un contexto. Si se disuelve la colaboracin, entonces el role debe de ser destruido, porque un actor diferente no puede reutilizar un role; por ejemplo, el papel de un cliente no puede transferirse de una persona a otra. Un role tambin conoce el tipo de actors con los que puede colaborar; algunos roles trabajan solamente con los actors de la organizacin. EJEMPLO- En una aplicacin de cadenas de suministros, una compaa puede ser a la vez un proveedor de gnero y servicios y un distribuidor al que compran los proveedores. A veces, un role tiene doble funcin como actor para otro role.

EJEMPLO- Un equipo de proyecto colabora en lnea. Dentro del equipo hay dos papeles especializados: administradores y presidentes del equipo. Una persona puede ser miembro del equipo. Por otro lado, al estar estos papeles adicionales por encima de los miembros del equipo, el papel de miembro de equipo se hace el actor para ellos.

2.6.4 Formatos de los patrones disponibles

No existe un estndar para documentar los patrones. El formato ms usado incluye algunos de estos apartados: nombre, clasificacin, resumen, problema, contexto, fuerzas que intervienen, solucin, ejemplo, patrones relacionados, exposicin razonada, y usos comunes. La inclusin o no de todos ellos se rige por el sentido comn. El objetivo no es ajustarse a un formato rgido, sino comunicar informacin til. El primero en identificar el concepto general de patrn y formular una plantilla fue Christopher Alexander. Su formato propuesto era similar al contenido en la tabla 2-4:

IF you find yourself in CONTEXT for example EXAMPLES, with PROBLEM, entailing FORCES THEN for some REASONS, apply DESIGN FORM AND/OR RULE to construct SOLUTION leading to NEW CONTEXT and OTHER PATTERNS Tabla 2-4. Plantilla de un patrn segn Christopher Alexander

La mayora de los patrones se escriben utilizando un formulario regular. Si se comparan dos conjuntos de patrones, casi nunca dos autores utilizan el mismo formulario. Las diferentes formas de los patrones tienen cualidades particulares y cualquier autor de patrones tendr una forma de seleccin para trabajar con sus preferencias. A pesar de estar expresados de distintas formas, la mayora de patrones tienen elementos comunes: Los patrones son soluciones: El propsito de escribir un patrn es describir una solucin til y recurrente. El xito estar en que otros puedan duplicar esta solucin cuando sea apropiada. Todo lo dems es secundario, lo que significa que

independientemente de la forma que se elija para escribir un patrn, la solucin es lo que cuenta. Un nombre significativo: La eleccin de nombres es muy difcil. Dado que van a ser un vocabulario, es importante poner todos los esfuerzos en conseguir buenos nombres. El nombre debe ser corto y ajustado. Normalmente, un patrn est compuesto por el enunciado del problema y una o varias propuestas de solucin. Para formalizar estas soluciones, se necesita una notacin expresiva y rica en semntica que permita plasmar eficientemente los atributos de las mismas. Adems esta notacin ha de ser fcil de entender e interpretar. La notacin ms extendida es UML, que permite capturar con precisin las soluciones a problemas de todo tipo. Los patrones de (Gamma et al., 1995), que realmente lanz los patrones en el mundo del software, tienen una forma muy estructurada, rompiendo el patrn en muchos ttulos: Intencin, motivacin, aplicacin, estructura, participantes, colaboraciones, consecuencias, implementacin, cdigo de ejemplo, usos conocidos, y patrones relacionados

2.7 Anlisis y conclusiones

Se deca anteriormente que los patrones de colaboracin describen qu es lo que interacciona, los objetos involucrados y las reglas que rigen estas interacciones. Todos estos puntos se han de conocer ya en las primeras fases de desarrollo del software, junto con la recogida de los requisitos y se han de hacer constar en su modelado. Por eso los patrones de colaboracin aparecen en esta primera parte del desarrollo. Se ha hablado tambin de la importancia que tiene la experiencia en el proceso de desarrollo, que va a ser decisiva en el momento de tomar decisiones durante todo el proceso y en el resultado obtenido. En cualquier diagrama de clases pueden reconocerse fcilmente alguno de los patrones de colaboracin propuestos, siendo rara la vez que esto no ocurre. Es, por estos motivos, por los que la utilizacin de los patrones de colaboracin va a aportar unos beneficios en el modelado del negocio, ya que los patrones sern muy probablemente partes de este modelado, por lo que se podran incluir directamente, en lugar de ir aadiendo los objetos uno por uno, lo que facilitara la tarea del modelado.

Cabe la posibilidad de utilizar la experiencia recurriendo al concepto de modelo y para ello podemos documentar habitualmente estos modelos en lenguajes UML e integrarlos en cualquiera de los procesos de desarrollo. En funcin de esa importancia que tiene la experiencia, lo que se pretende en este PFC, como se indica en la motivacin, es desarrollar un entorno en el que se pueda utilizar la experiencia, y concretamente, la experiencia relacionada con el modelado del dominio. Para ello se ha localizado la experiencia disponible, que es lo que se ha comentado en este captulo, en los patrones de colaboracin. Esto se abordar en el tercer captulo y ms tarde, en el cuarto captulo, se pondrn algunos casos de ejemplo. Sera interesante disponer de una notacin capaz de especificar la esencia de un patrn de forma clara, sencilla y precisa, as como de herramientas que faciliten la definicin, aplicacin semi o automtica y validacin de stos en diferentes contextos. Sin embargo, esta labor es compleja y no se ha avanzado apenas, ya que no est claro qu se debera especificar y cmo especificarlo. Siendo tan tiles los patrones de colaboracin, lamentablemente, no se ha encontrado ninguna herramienta CASE que recoja este tipo de patrones y permita incluirlos en el modelado del negocio.

Captulo 3. Integracin de los patrones de colaboracin en el proceso de desarrollo

En este captulo se analizan los requisitos necesarios que ha de tener la herramienta propuesta para aadir patrones de colaboracin en los diagramas de clases, para facilitar el modelado del dominio. Para la descripcin del trabajo realizado se hace un anlisis, un diseo y una implementacin de la herramienta desarrollada y, posteriormente, se describe el entorno resultante. Asimismo, y habindole otorgado una importancia singular a los patrones de colaboracin (Nicola et al., 2001) se comentar cmo se ha hecho la descripcin de dichos patrones para facilitar su utilizacin y la manera en que se han almacenado.

3.1 Introduccin
Se ha comprobado la importancia que tienen las primeras fases en el desarrollo del software, donde la recoleccin y modelado de los requisitos puede ser decisivo para que la posterior implementacin sea la esperada. Y teniendo en cuenta que utilizar la experiencia, recogida por los expertos, puede ser de suma utilidad para este modelado, este proyecto final de carrera propone el desarrollo de una herramienta que permita la utilizacin de patrones de colaboracin directamente sobre el modelado. Esta herramienta est especialmente indicada para facilitar los primeros modelados en el proceso de desarrollo, tiene propsito didctico y se considera til porque con ella, los estudiantes y futuros desarrolladores pueden tomar un primer contacto con el modelado de los requisitos, beneficindose de la utilizacin de experiencia que no es propia. Labor que, por un lado facilita este modelado, y por otro lado, hace que el usuario se acostumbre a adaptar especificaciones ya elaboradas en su trabajo, lo que es sumamente importante para el trabajo en equipo, pudiendo adaptar posteriormente estas partes a sus necesidades. Se ha pensado principalmente en los patrones de colaboracin (Nicola et al., 2001) porque son los utilizados en las primeras etapas del desarrollo, donde el aprendiz tiene probablemente menos habilidad para desenvolverse. Adicionalmente, se le permite aadir

nuevos patrones, propios o de otras colecciones, para hacerle lo ms fcil posible la tarea del modelado, que tanto cuesta llevar a cabo al principio a un ingeniero del software.

3.2 Documentacin desarrollada

especificacin

de

la

aplicacin

En este apartado se contempla la especificacin de la herramienta propuesta para este proyecto. Para ello se hace un estudio de los requisitos funcionales y no funcionales que la herramienta ha de cumplir, por medio de diagramas de casos de uso y la correspondiente especificacin de cada uno de ellos, se muestra un modelado conceptual, con las clases que se utilizan para la implementacin y se comentan los paquetes de los que se compone la aplicacin. Por ltimo, se analizan los pasos que se han de dar para llevar a cabo algunas de las acciones ms significativas, a travs de los diagramas de secuencia correspondientes.

3.2.1 Objetivos
Se ha pensado desarrollar una herramienta de fcil utilizacin y muy intuitiva con la cual los estudiantes de ingeniera del software puedan familiarizarse con el modelado del dominio. Lo particular de esta aplicacin es que permitir a sus usuarios la inclusin directa de patrones en su modelo. Para ello, se facilita con la herramienta la coleccin de patrones de colaboracin de (Nicola et al, 2001), los cuales el usuario podr modificar en base a sus necesidades. La eleccin de este conjunto de patrones viene dada por su especial importancia, ya que se consideran muy tiles en esta parte del desarrollo y es muy comn identificar alguno de estos patrones en cualquier tipo de modelado. No obstante, el usuario podr modificar estos patrones o completar la coleccin facilitada con patrones propios o de otras colecciones en base a sus necesidades. Se ha tenido en cuenta que cuando al usuario, en este caso, al estudiante de informtica, se le presentan los patrones de colaboracin y este se habita con ellos, ser muy fcil para l identificarlos en cualquier diagrama de clases con el que trabaje, ya que son patrones muy comunes y fcilmente reconocibles. Los objetivos que se han tenido presentes en el desarrollo de la herramienta que se pretende implementar para este proyecto se dividen en dos partes.

Por un lado, esta herramienta trata de ser una primera toma de contacto para el usuario en cuanto al modelado de clases, por lo que ha de cumplir con la funcionalidad relacionada al respecto, como es la gestin y edicin de diagramas de clases. Habr que tener en cuenta que las clases constarn de mtodos y atributos, y que habr relaciones entre ellas. Dichas relaciones tendrn una clase origen y una clase destino y podrn ser de distintos tipos: dependencia, generalizacin, asociacin, agregacin o composicin. Por otro lado, se pretende que el usuario pueda incluir directamente patrones en su diagrama. De esta forma, el usuario no tendr que dibujar cada una de las clases que componen el patrn, sus caractersticas y las relaciones entre ellas, sino que todo esto estar almacenado en un fichero y se podr aadir el patrn completo al modelo. Cuando el usuario pretenda incorporar un patrn, el sistema le permitir sustituir, si lo desea, las clases del patrn por las que tenga ya definidas en el diagrama. En principio, la herramienta dispondr de la coleccin de patrones de colaboracin de (Nicola et al, 2001) en su repositorio, pero este podr ser completado por el usuario con nuevos patrones. Para ello se podr dibujar el nuevo patrn con el editor de clases y, una vez representadas sus clases, relaciones y propiedades, guardarlo en el repositorio como un patrn ms. En una primera aproximacin, la funcionalidad que deber ofrecer la herramienta ser la sealada en la Figura 3-1.

Figura 3-1. Esquema bsico de la funcionalidad de la herramienta

La herramienta, adems de lo comentado, tambin permitir acciones a las que se les ha dado menor importancia en este proyecto, para facilitar el uso al diseador. De esta manera, podr guardarse el diagrama de clases diseado, simplemente como diagrama de clases, o como un nuevo patrn, en cuyo caso se aadir al repositorio correspondiente de patrones disponibles y podr ser reutilizado posteriormente de manera conjunta a los patrones

de colaboracin que en principio se facilitan, y por los que especialmente se ha creado esta herramienta. De igual forma, podr abrirse un diagrama de clases definido y guardado anteriormente con formato UsiXML (Limbourg et al., 2004), podr verse el cdigo XML asociado al diagrama sobre el que se est trabajando, y tambin podr guardarse el diagrama como grfico, en formato jpg e imprimirlo.

3.2.2 Requisitos funcionales

En este apartado se pretende recoger, analizar y definir las necesidades de alto nivel y las caractersticas del sistema de gestin de la herramienta. Para ello se representarn los requisitos como casos de uso, realizando una vista general de la arquitectura del software que se desarrollar. Con los casos de uso (Jacobson et al., 1999) se trata de modelar y organizar el comportamiento del sistema. Por lo tanto, se clasificarn y detallarn los casos de uso necesarios para llevar a cabo el desarrollo. El objetivo es delimitar el alcance del sistema para comprender qu es lo que se debe cubrir con el proyecto de desarrollo. La herramienta asociada a este proyecto final de carrera est diseada para el modelado de sistemas, y est especialmente indicada para estudiantes de informtica, inicindose en el desarrollo y modelado del dominio, por lo que los usuarios que interacten con ella estarn acostumbrados a utilizar programas informticos, pero no de modelado. El diagrama que representa la funcionalidad de esta herramienta puede observarse en la Figura 3-2, con los principales casos de uso involucrados, donde se distinguen dos partes, por un lado lo referente a la gestin de patrones y por otro lado, a la edicin de diagramas de clases.

Figura 3-2. Diagrama de casos de uso de la herramienta

Respecto a la gestin de patrones, habr un repositorio donde estn almacenados los patrones de colaboracin, en un principio, pero que el usuario podr completar aadiendo nuevos patrones a este repositorio, eliminar patrones de los existentes o modificarlos segn sus necesidades. Para aadir un nuevo patrn, el diseador ha de elaborar el correspondiente diagrama de clases y guardarlo en el repositorio, para as poder ser utilizado como patrn, junto con los ya establecidos patrones de colaboracin. Los patrones se guardarn en un fichero, por lo que para modificar un patrn determinado, habr que abrir ese fichero, cambiar lo que sea necesario y volver a guardarlo con el mismo nombre, para que se vea reformado. En lo referente a la elaboracin de diagramas de clases, al usuario se le permite aadir nuevas clases y relaciones, pudiendo para ello utilizar los patrones disponibles en el repositorio. En este caso, se aadiran las nuevas clases que forman el patrn. El usuario tendr la opcin de elegir si quiere que las clases del patrn coincidan con alguna de las que ya

tiene en su diagrama, y si es as, se sustituir y se aadirn nicamente las relaciones necesarias y las clases que no estn ya representadas. Adems, el usuario podr eliminar clases y relaciones del diagrama, al igual que consultarlas y modificarlas para representar su modelo. Una vista muy bsica de las actividades necesarias que se tendrn que llevar a cabo con la herramienta propuesta para la realizacin de un diagrama de clases, en general, viene representada en la Figura 3-3, aunque la aplicacin ofrecer mucha ms funcionalidad que para este diagrama no se ha tenido en cuenta.

Figura 3-3. Diagrama de actividades para la elaboracin de un diagrama de clases

A continuacin se especifican, mediante tablas y siguiendo la metodologa propuesta por Amador Durn (Durn & Bernrdez, 2002), los distintos casos de uso que va a tener la herramienta desarrollada en este proyecto para que cumpla con las especificaciones deseadas. Segn los autores, El objetivo de esta metodologa es la definicin de las tareas a realizar, los productos a

obtener y las tcnicas a emplear durante la actividad de elicitacin de requisitos de la fase de ingeniera de requisitos del desarrollo de software.

Caso de Uso Aadir Clase Descripcin En este caso de uso, el diseador dibuja una nueva clase en el diagrama. Esto podr hacerse de dos formas distintas: directamente, o a travs de un patrn. En el caso de que sea el diseador el que elija la opcin de aadir la clase, esta se incluir en el diagrama con un identificador que la har nica para poder ser reconocida en el diagrama posteriormente y solo se le asociar en principio este dato y un nombre, que ser igual que el identificador. La clase tambin podr ser aadida a travs de un patrn. Es decir, cuando se de el caso de uso Utilizar Patrn, directamente se aadirn las clases de las que se componga dicho patrn al diagrama. De esta forma, la clase tendr asociadas aquellas propiedades que tuviera la misma en el patrn. Precondiciones Flujo de eventos Flujo bsico El diseador selecciona la opcin de aadir una nueva clase en el diagrama. El diseador especifica el punto, dentro del rea de dibujo, donde quiere que aparezca la clase. La nueva clase aparece en el diagrama, con un nombre por defecto y un identificador nico en el diagrama para que pueda ser reconocida de forma unnime. Inicialmente, la nueva clase no tendr atributos ni mtodos asociados. Flujo alternativo El diseador utiliza un patrn del repositorio. Las clases que componen el patrn, y que el diseador no haya seleccionado para que sean sustituidas por alguna de las ya existentes, se aaden automticamente al diagrama. Las nuevas clases aadidas tendrn las mismas propiedades, atributos y mtodos que tuviera la clase a la que representan en el patrn. Poscondiciones La nueva clase dibujada queda registrada de forma unvoca mediante un identificador que el usuario no podr modificar. Opcionalmente, el diseador podr cambiar las caractersticas de la clase, aadir nuevos atributos o mtodos o asociar esta clase a otras mediante relaciones. Excepciones Relaciones Actores Diseador Inclusiones Extensiones Utilizar patrn
Tabla 3-1. Caso de uso Aadir Clase

Caso de Uso Eliminar Clase Descripcin En este caso de uso, el diseador selecciona una clase de las que hay en el diagrama sobre el que est trabajando y le indicar al sistema que la elimine de l, de forma que la clase deja de existir. Por consiguiente, las relaciones en las que la clase eliminada fuera origen o destino tambin se eliminarn. Precondiciones La clase tiene que estar en el diagrama para que pueda eliminarse. Flujo de eventos Flujo bsico El diseador selecciona una clase de su diagrama. El diseador selecciona la opcin de eliminar la clase. El sistema le pregunta si realmente desea eliminar la clase del diagrama. El diseador confirma que desea eliminar la clase. La clase desaparece del diagrama y tambin cualquier referencia a ella. Si haba relaciones en las que la clase era el origen o el destino, tambin se eliminarn junto con la clase. Flujo alternativo El diseador se ha equivocado al seleccionar la opcin de eliminar la clase. Cuando el sistema muestra el mensaje para que el usuario confirme si desea eliminar la clase, ste deniega la opcin. El mensaje desaparece y la clase sigue estando como antes. Poscondiciones La clase ha dejado de existir en el sistema, por lo que no podrn hacerse referencias a ella. Las relaciones en las que la clase estuviera implicada se eliminarn junto a la clase. Excepciones Relaciones Actores Diseador Inclusiones Extensiones Eliminar Relacin
Tabla 3-2. Caso de uso Eliminar Clase

Caso de Uso Consultar Clase Descripcin En este caso de uso, el diseador puede visualizar el identificador y nombre de la clase, al igual que los atributos y mtodos que tiene asociados. Puesto que la representacin grfica de una clase est representada con un cuadrado con tres secciones, dependiendo de la seccin que el usuario seleccione visualizar unos datos u otros. De esta manera, en la parte de arriba aparece el nombre de la clase, y las propiedades de esta son su nombre e identificador. En la parte central aparecen los atributos, y sus propiedades son identificador del atributo, nombre, tipo de dato (void, boolean, date, int, float, double, string), cardinalidad mnima, cardinalidad mxima y nivel de acceso del atributo (friendly, private, protected, public). En la parte de abajo aparecen los mtodos, y sus propiedades son identificador, nombre, valor devuelto (void, boolean, date, int, float, double, string), nivel de acceso del mtodo (friendly, private, protected, public) y parmetros que se le pasan.

Los identificadores de las clases, de los atributos y de los mtodos son valores que asigna el sistema automticamente a las clases, atributos o mtodos respectivamente en el momento en que estos se aaden al diagrama. Estos valores no podrn modificarse por el usuario. Precondiciones En la parte de arriba del cuadro que representa una clase est el nombre de la clase, en la parte central estn los atributos relacionados con esa clase, y en la parte de abajo estn los mtodos. Flujo de eventos Flujo bsico El diseador selecciona una de las clases del diagrama. Si el diseador selecciona la parte de arriba del cuadro que representa la clase, se mostrarn las propiedades de la clase. Si el diseador selecciona uno de los atributos, situados en la parte central del cuadro que representa la clase, se mostrarn las propiedades de ese atributo. Si el diseador selecciona uno de los mtodos, situados en la parte de abajo del cuadro que representa la clase, se mostrarn las propiedades del mtodo. Flujo alternativo Si no hay ningn atributo asignado a la clase seleccionada, en el momento en el que el diseador selecciona esta parte, se crea un nuevo atributo y se visualizarn sus propiedades, que inicialmente estarn todas en blanco, excepto el identificador, que ser el que le haya otorgado el sistema y no podr ser modificado. Si no hay ningn mtodo asignado a la clase seleccionada, en el momento en el que el diseador selecciona esta parte, se crea un nuevo mtodo y se visualizarn sus propiedades, que inicialmente estarn todas en blanco, excepto el identificador, que ser el que le haya otorgado el sistema y no podr ser modificado. Poscondiciones Excepciones Si no hay ningn atributo / mtodo asignado a la clase seleccionada, en el momento en el que el diseador selecciona esta parte, se crea un nuevo atributo / mtodo, y se abre la ventana donde aparecen sus propiedades, que inicialmente estarn todas en blanco y el diseador podr modificarlas en la ventana que se abre. De la misma manera, al igual que se puede seleccionar uno de los atributos o mtodos existentes para ver sus propiedades, tambin se puede aadir uno nuevo. Relaciones Actores Diseador Inclusiones Es utilizado por Modificar Clase Extensiones
Tabla 3-3. Caso de uso Consultar Clase

Caso de Uso Modificar Clase Descripcin En este caso de uso, el usuario puede modificar el nombre de la clase. Tambin podr aadir nuevos atributos y mtodos, eliminarlos y cambiar sus propiedades. Precondiciones

El diseador ha consultado la clase y tiene visibles las propiedades de la clase o de sus atributos o mtodos. Como este caso de uso tiene varias partes, dependiendo de la que se vaya a usar, debern darse unas precondiciones u otras. Si se desea modificar el nombre de la clase, se deber tener visible las caractersticas de la clase; si se desea cambiar las propiedades de un atributo, sern estas las que debern estar visibles; si lo que se desea variar son las propiedades de un mtodo, sern las propiedades de este las que debern estar a la vista. Si se desea aadir o eliminar un atributo o un mtodo, no ser necesario utilizar previamente el caso de uso consultar clase. Flujo de eventos Flujo bsico El diseador selecciona la propiedad que desea modificar de entre los campos existentes para la clase, atributo o mtodo seleccionado. Para las propiedades de la clase, el diseador podr cambiar el nombre a la clase, siendo necesario que ste sea nico en el diagrama de clases. Para las propiedades de los atributos, el diseador elegir una de las opciones posibles de entre la lista que se ofrece para los casos de tipo de dato y nivel de acceso del atributo. En el resto de propiedades escribir su valor en el campo correspondiente Para las propiedades de los mtodos, el diseador elegir una de las opciones posibles de entre la lista que se ofrece para los casos de tipo devuelto y nivel de acceso del mtodo. En el resto de propiedades escribir su valor en el campo correspondiente. Se guardarn automticamente los cambios realizados en cualquiera de las propiedades y se visualizarn en la representacin grfica de la clase. Flujo alternativo Si el usuario desea aadir un atributo a una clase, seleccionar la parte de los atributos, dentro de la clase. El sistema crear un nuevo atributo para esta clase, al que asignar un identificador nico y se mostrarn sus propiedades para que el usuario pueda dar los datos que le interesen. Si el usuario desea eliminar un atributo de la clase, seleccionar este atributo e indicar la opcin de eliminarlo de la clase. El atributo desaparecer con las caractersticas que conlleve. Si el usuario desea aadir un mtodo a una clase, seleccionar la parte de los mtodos, dentro de la clase. El sistema crear un nuevo mtodo para esta clase, al que asignar un identificador nico y se mostrarn sus propiedades para que el usuario pueda dar los datos que le interesen. Si el usuario desea eliminar un mtodo de la clase, seleccionar este mtodo e indicar la opcin de eliminarlo de la clase. El mtodo desaparecer con las caractersticas que conlleve.

Poscondiciones En el cuadro que representa la clase aparecen los nombres de la clase, de los atributos y de los mtodos, cada uno en su lugar correspondiente. Para cada atributo aparecer su nivel de acceso, su tipo del atributo y su nombre. Para cada mtodo aparecer su nivel de acceso, el tipo que devuelve este mtodo, su nombre y los parmetros que recibe entre parntesis y escritos de la misma manera que lo hizo el usuario. Cada atributo y cada mtodo estarn en una lnea distinta dentro de la parte correspondiente en la clase y terminarn con un punto y coma. Excepciones Los identificadores de clase, de atributo y de mtodo no pueden modificarse, son datos que asigna el sistema automticamente cuando se crean. A una clase no se le puede asignar un nombre que ya est siendo utilizado por otra clase en el diagrama. Si se intenta hacer esto, el sistema mostrar un mensaje de error y pedir que se d un nuevo nombre vlido para la clase. Relaciones Actores Diseador Inclusiones Utiliza Consultar Clase Extensiones
Tabla 3-4. Caso de uso Modificar Clase

Caso de Uso Aadir Relacin Descripcin En este caso de uso, el diseador establece una relacin entre dos de las clases existentes en el diagrama. Otra alternativa es que se establezca una relacin entre una misma clase, aunque este caso no tendr mucho sentido dependiendo del tipo de relacin, esta opcin est incluida entre las posibles y ser eleccin del diseador utilizarla o no. Las relaciones podrn ser de varios tipos: de dependencia, de generalizacin, de asociacin, de agregacin y de composicin. Cada tipo de relacin se representa de distinta manera, siguiendo el formato establecido en el UML. Precondiciones Las clases deben estar incluidas en el diagrama para poder aadir la relacin entre ellas. Flujo de eventos Flujo bsico El diseador selecciona el tipo de relacin que quiere aadir al diagrama. El diseador selecciona la primera clase, que ser el origen de la relacin. El diseador selecciona la segunda clase, que ser el destino de la relacin. La relacin entre las dos clases indicadas aparece dibujada en el diagrama. Flujo alternativo Si el diseador necesita una relacin dentro de la misma clase, selecciona dos veces la misma clase: como origen y como destino. Se incluye en el diagrama una relacin sobre la misma clase.

Poscondiciones La nueva relacin lleva asociado un identificador nico dentro del diagrama de clases que el sistema le asignar en el momento de su creacin. Adems de este, otros campos de las propiedades que tiene la relacin las fijar el sistema. Estos campos sern las clase origen y destino y el role de cada una de ellas. Sus valores no podrn ser modificados por el usuario. El diseador podr modificar el resto de valores que lleva asociados la relacin. Excepciones Entre dos clases determinadas podr haber varias relaciones siempre que estas sean de distinto tipo. De esta forma, si ya existe una relacin de un tipo concreto, y el usuario pretende establecer otra del mismo tipo, esto no ser posible y se mantendr nicamente la primera. Relaciones Actores Diseador Inclusiones Extensiones Utilizar Patrn
Tabla 3-5. Caso de uso Aadir Relacin

Caso de Uso Eliminar Relacin Descripcin En este caso de uso, el diseador elimina una relacin de las existentes en el diagrama de clases. Precondiciones Flujo de eventos Flujo bsico El diseador selecciona una determinada relacin representada en el diagrama de clases. El diseador selecciona la opcin de eliminar la relacin. El sistema le pregunta si realmente desea eliminar la relacin del diagrama. El diseador confirma que desea eliminar la relacin. La relacin desaparece del diagrama. Flujo alternativo El diseador deniega que desee eliminar la relacin. El mensaje desaparece y la clase sigue estando como antes. Poscondiciones La relacin deja de existir en el diagrama y las clases afectadas pierden la dependencia que las una. Excepciones Relaciones Actores Diseador Inclusiones Extensiones
Tabla 3-6. Caso de uso Eliminar Relacin

Caso de Uso Consultar Relacin Descripcin En este caso de uso, el diseador consulta los datos concernientes a la relacin marcada. Dependiendo del tipo de relacin que sea, las propiedades que se tendrn sern unas u otras. De esta manera, si la relacin es de asociacin, de agregacin o de composicin, los

datos que se podrn consultar asociados a la relacin son el identificador y nombre de la relacin, los identificadores de las clases origen y destino y los roles que tienen en la relacin y la cardinalidad en cada extremo de la relacin. Si la relacin es de dependencia, se podrn consultar el identificador y el nombre de la relacin, los identificadores de las clases origen y destino, el role de cada una de las clases y la cardinalidad en cada extremo de la relacin. Si la relacin es de generalizacin, solamente se guardarn los campos de identificador y nombre de la relacin, los identificadores de las clases origen y destino y el role que tiene la clase origen respecto a la destino. Precondiciones La relacin que se pretende consultar ha sido establecida con anterioridad en el diagrama. Flujo de eventos Flujo bsico El diseador selecciona la relacin de la cual desea consultar los datos. El diseador selecciona la opcin de visualizar las propiedades asociadas a la relacin marcada. El sistema muestra los campos asociados a las propiedades de la relacin elegida y sus valores correspondientes. Flujo alternativo Poscondiciones Excepciones Relaciones Actores Inclusiones Extensiones Diseador

Tabla 3-7. Caso de uso Consultar Relacin

Caso de Uso Modificar Relacin Descripcin En este caso de uso, el diseador completa o modifica los datos que lleva asociados una relacin previamente establecida en el diagrama de clases. De las propiedades que tenga, habr algunas que el usuario no pueda modificar y otras que si. Precondiciones La relacin ha sido establecida en el diagrama de clases y estn visibles las propiedades de esta. Flujo de eventos Flujo bsico El diseador selecciona la propiedad de la relacin que desea modificar. El diseador podr otorgar libremente un nombre a la relacin. El diseador podr dar un valor entre 0, 0..1, 0..n, 1, 1..n o n a la cardinalidad de las clases que son afectadas por la relacin.

Flujo alternativo En caso de que la relacin sea de generalizacin, el usuario solo podr modificar el nombre, ya que esta relacin no tendr definidos los campos de cardinalidad. Solo en caso de que la relacin sea de dependencia, adems de los campos comentados, el usuario podr modificar los campos de instanciacin para cada una de las clases roleAInstantiedCard, ya que esta propiedad es particular de este tipo de relacin. Poscondiciones Los valores otorgados a cada propiedad modificada se guardan automticamente. El nombre de la relacin aparecer en el diagrama, sobre la relacin y en la parte central. La multiplicidad de cada clase que une la relacin se ver a cada lado de la clase que afecta. Excepciones Los campos de identificador de la relacin, las clases origen y destino y el role de cada una de ellas no pueden ser modificados por el usuario ya que los establece el sistema en funcin de la manera en que el diseador ha creado la relacin en el diagrama. Relaciones Actores Diseador Inclusiones Extensiones
Tabla 3-8. Caso de uso Modificar Relacin

Caso de Uso Utilizar Patrn Descripcin En este caso de uso, el diseador utiliza uno de los patrones existentes para aadirlo en su diagrama de clases. Para ello buscar el nombre del patrn entre la lista que tendr de los disponibles en el rbol del repositorio y lo arrastrar hasta el rea de dibujo. El sistema le dar opcin a sustituir las clases de las que se compone el patrn por las que ya tiene representadas en su diagrama. En este caso, la clase que se sustituye pasar a tener las caractersticas y relaciones asociadas que tiene la del patrn. En caso de que no sustituya una clase, se aadir una nueva al diagrama, con las caractersticas que tenga en el patrn. En este caso de uso se aaden al diagrama tanto las clases como las relaciones implicadas en el patrn seleccionado. Precondiciones

Flujo de eventos Flujo bsico El diseador selecciona el nombre del patrn que quiere utilizar entre los que hay en el rbol, que sern los que estn disponibles en el repositorio de patrones. El diseador arrastra el patrn a su diagrama de clases. Si el diagrama ya tiene alguna clase representada, el sistema mostrar en un mensaje cada una de las clases por las que est compuesto el patrn y permite, para cada una de ellas, asociarla con alguna de las clases que hay en el diagrama de clases en ese momento. El diseador selecciona una clase de las ya existentes para ser sustituida por la del patrn. El diseador acepta y se cierra la ventana. El patrn se dibuja en el rea del diagrama. De forma similar a como estaban en el patrn, se aadirn las clases y relaciones entre ellas. Las clases sustituidas tendrn las relaciones que tenan las originales en el patrn. Las clases que no han sido sustituidas, adems de las relaciones en las que estn implicadas, incluirn las mismas propiedades, atributos y mtodos que las del patrn. Flujo alternativo Si antes de arrastrar el patrn, no haba ninguna clase en el diagrama, no se podr sustituir ninguna clase, por lo que no se mostrar el mensaje intermedio. Si en lugar de aceptar, se cancela o cierra la ventana intermedia, no se sustituir ninguna clase del patrn por las existentes, independientemente de lo que el diseador hubiera seleccionado. Poscondiciones Excepciones Relaciones Actores Inclusiones Extensiones Diseador
Tabla 3-9. Caso de uso Utilizar Patrn

Caso de Uso Aadir Patrn Descripcin En este caso de uso, el usuario aade un nuevo patrn al repositorio para que luego pueda utilizarlo al igual que los patrones de colaboracin proporcionados. El patrn aadido puede pertenecer a una coleccin reconocida o ser propio del diseador. Para aadir el patrn, el diseador dibujar el diagrama de clases que lo representa y lo guardar en el directorio donde est el repositorio de los patrones. Precondiciones

Flujo de eventos Flujo bsico El diseador dibuja el diagrama de clases correspondiente al patrn que quiere aadir, utilizando para ello los casos de uso relativos a la elaboracin de diagramas de clases. Una vez completo el diagrama, el diseador selecciona la opcin de guardar el proyecto. Se abre una ventana donde el usuario ha de seleccionar el directorio donde quiere guardarlo que, en este caso, tendr que ser donde estn todos los patrones. El diseador da un nombre al patrn y lo guarda. El diseador cierra la ventana. Flujo alternativo Poscondiciones El diagrama guardado en el directorio donde estn los patrones podr ser aadido, como otro patrn ms, en el diagrama de clases. Excepciones Relaciones Actores Diseador Inclusiones Extensiones
Tabla 3-10. Caso de uso Aadir Patrn

Caso de Uso Eliminar Patrn Descripcin En este caso de uso, el diseador elimina uno de los patrones existentes del repositorio. Precondiciones Este caso de uso se lleva a cabo sin necesidad de estar ejecutndose la aplicacin, ya que su eliminacin se hace desde el directorio donde est ubicado su fichero asociado. Flujo de eventos Flujo bsico El usuario va al directorio donde estn guardados todos los patrones. El usuario selecciona el fichero correspondiente al patrn que desea eliminar y lo elimina. Flujo alternativo Poscondiciones El patrn eliminado ya no saldr en el rbol de patrones disponibles ni podr ser utilizado por la aplicacin. Excepciones Relaciones Actores Diseador Inclusiones Extensiones
Tabla 3-11. Caso de uso Eliminar Patrn

Caso de Uso Modificar Patrn Descripcin En este caso de uso, el diseador modifica un patrn existente en el repositorio.

Precondiciones El patrn est incluido con anterioridad en el repositorio de los patrones disponibles. Flujo de eventos Flujo bsico El diagrama de clases utilizado est vaco. El diseador realiza el caso de uso Utilizar Patrn con el patrn que desea modificar. El diseador modifica el diagrama de clases asociado al patrn utilizando para ello los casos de uso necesarios relativos a la elaboracin de diagramas de clases. Una vez completo el diagrama, el diseador selecciona la opcin de guardar el proyecto. Se abre una ventana donde el usuario ha de seleccionar la carpeta donde quiere guardarlo que, en este caso, tendr que ser donde estn todos los patrones. El diseador selecciona el patrn que abri anteriormente para modificarlo y lo guarda. El diseador cierra la ventana. Flujo alternativo Para abrir el diagrama de clases correspondiente al patrn que se quiere modificar, tambin se puede abrir directamente: El diseador selecciona la opcin de abrir un diagrama de clases existente. El diseador indica el directorio donde est el repositorio de los patrones y el nombre del fichero que tiene el patrn que desea modificar y abre su diagrama de clases asociado. A continuacin, el diseador puede modificar el diagrama de clases y seguir con el flujo bsico de ejecucin para terminar de modificar el patrn. Poscondiciones El patrn con un determinado nombre que estar disponible ser el que tenga los ltimos cambios, es decir, al guardarlo con el mismo nombre. La versin anterior del patrn se pierde y es sobrescrito por el diagrama modificado. Excepciones Relaciones Actores Inclusiones Extensiones Diseador

Tabla 3-12. Caso de uso Modificar Patrn

Para la especificacin de los requisitos que se acaba de realizar se ha tenido en cuenta nicamente la funcionalidad que se considera ms importante de la herramienta y los casos de uso principales. Como se ha comentado anteriormente, la herramienta dispondr de cierta funcionalidad adicional para facilitar su uso al diseador, pero que no se ha considerado en

esta especificacin por tratarse de casos de uso que no reflejan la esencia que se quiere resaltar de esta aplicacin, como es lo relacionado con la gestin de los patrones y la elaboracin de diagramas de clases.

3.2.3 Requisitos no funcionales

El sistema desarrollado ha de ser fcil de usar. Est especialmente dedicado a desarrolladores y estudiantes, con experiencia en informtica y que estarn muy acostumbrados a tratar con distintas aplicaciones software. Sin embargo, al estar la herramienta enfocada al modelado del dominio, sta ser una tarea en la que los supuestos estudiantes carecern de prctica. Por eso se pretende que su diseo no ofrezca ninguna dificultad para su utilizacin, ya que con ella se pretende facilitarles las cosas, en lugar de entorpecerlas con una herramienta que no sepan cmo manejar. Por lo tanto, su interfaz ha de ser muy intuitiva. La ventana principal estar claramente dividida en dos partes distintas, cada una con su funcionalidad. As, en una parte se ofertarn los patrones de colaboracin que pueden utilizarse, y en la otra habr un panel para la especificacin de diagramas de clases. En la parte superior de la interfaz se dispondr de un men con las acciones que pueden hacerse. Cada accin tendr un nombre significativo y llevar asociado un icono cuya forma es caracterstica respecto a la funcionalidad que ofrece. Situada en la parte superior del panel de dibujo habr una barra de herramientas que actuar sobre el diagrama y que contendr los botones necesarios para aadir clases y distintos tipos de relaciones sobre el diagrama, con dibujos en sus iconos similares a los que se obtienen a travs de ellos. Adems, cuando se pase el puntero del ratn por cada uno de los botones, aparecer un texto con la funcin que tiene. Tambin se cuidar y se incluir el control de errores que puedan producirse durante su ejecucin y se le advertir al usuario si est haciendo algo no permitido, o si algo no funciona como debera. Para ello, se considerar la situacin de que el programa no pueda abrir un fichero que el usuario le haya indicado. Este fichero podr ser el correspondiente a un diagrama de clases que se quiera abrir directamente o el correspondiente a un patrn que se

desee incorporar al diagrama. En estos dos casos, el sistema mostrar un mensaje de error avisando de la excepcin producida. Otra caracterstica que se tendr en cuenta en la implementacin de la herramienta es que no se permita duplicar los nombres de las clases. Para cumplir con este objetivo se llevar un control de esta propiedad de las clases a lo largo de todo su uso. Se controlar en el momento de abrir un nuevo diagrama y cuando se modifique el nombre de alguna de las clases ya existentes. En el caso de que se arrastre un patrn y ste incluya una clase cuyo nombre ya est siendo utilizado en alguna de las clases que consten en el diagrama, al nombre de la clase que todava no ha sido incorporada se le aadir, directamente, un nmero que la haga nica. De manera que cuando el patrn se represente en el diagrama ya est correctamente, hacindose de forma transparente al usuario. Cuando sea el usuario el que intente modificar el nombre a alguna de las clases que ya existen, y el nuevo nombre coincida con otro ya utilizado, el sistema le avisar a travs de un mensaje indicando la situacin y pidiendo al usuario que de otro nombre que sea vlido para la clase, porque el indicado no lo es. En el caso de que el usuario no lo haga, la clase quedar con el nombre que tena anteriormente, que ser el asignado inicialmente por el sistema, si el usuario no lo ha modificado anteriormente. Asimismo, cuando el usuario aada una clase al diagrama, esta clase tendr inicialmente el mismo valor para su nombre que para su identificador, por lo que no se permitir asignarle un nombre que empiece por idc y no se corresponda con su identificador. Para ello cabe indicar que el identificador asociado a una clase nueva ser idc seguido de un nmero que ir incrementando en funcin de las clases que existan en el diagrama. Para comprobar los nombres no se distinguir entre maysculas y minsculas y se eliminarn los espacios antes del primer carcter del nombre y despus del ltimo. Las clases, al igual que los atributos y mtodos que estas tengan, llevarn asignados un identificador, que el sistema les proporcionar desde el momento de su creacin hasta que se eliminen del diagrama. Estos identificadores sern los que se tendrn en cuenta a la hora de trabajar con estos elementos y no podrn ser modificados en ningn momento.

El identificador de una clase ser una cadena de caracteres que comience por idc, seguido del nmero de clases que se hayan aadido en el diagrama en el momento de su creacin. En el momento de aadir una nueva clase al diagrama, el nombre tendr el mismo valor que su identificador, hasta que el usuario lo modifique. As mismo, el identificador de un atributo ser una cadena de caracteres que comience por el identificador de la clase a la que pertenece, seguido de una a y el nmero de atributos que se le hayan incluido a la clase hasta ese momento. De igual forma ser asignado el identificador de un mtodo, con la excepcin de que en lugar de una a despus del identificador de la clase, en este caso llevar una m, para distinguir entre atributos y mtodos. Si una clase hubiese sido incluida y posteriormente se hubiera borrado, su identificador ya no volvera a utilizarse. Lo mismo pasara con los atributos y los mtodos, que los identificadores no se repetirn en el caso de que se eliminen de la clase. De forma similar, las relaciones tambin llevarn asociado un identificador que el sistema les proporciona de forma automtica en el momento de su inclusin en el diagrama. En este caso ser un valor que comenzar por idr, seguido del nmero de relaciones que se han aadido en el diagrama hasta ese momento. Igual que en los casos anteriores, los identificadores no se repetirn, ni en el caso de que se elimine la relacin del diagrama. Adems del identificador, el sistema dar valores a las clases origen y destino de la relacin, en funcin de las clases que el usuario haya unido, y a los roles de estas, en funcin del tipo de relacin del que se trate. Por otro lado, cuando el usuario seleccione la opcin de eliminar una clase o una relacin, el sistema mostrar un mensaje que le preguntar si realmente quiere eliminarla del diagrama, pudiendo el usuario revocar la seleccin, sin que realmente llegue a eliminarse, o seguir adelante y borrarla del diagrama. Los mensajes que el sistema muestra al usuario con informacin o avisos estarn convenientemente cuidados y se mostrarn en el momento justo que el usuario los necesite. Adems, se tratar de que el sistema sea eficiente y haga lo que debe de hacer correctamente.

3.2.4 Modelado conceptual

En este apartado se har un anlisis del modelado conceptual que se seguir en el momento de realizar el diseo de la aplicacin. Una visin bsica de conjunto de la arquitectura del sistema es la ofrecida en la Figura 3-4, donde puede observarse que, bsicamente, la aplicacin tiene tres mdulos diferenciados por su funcionalidad y comunicados entre s mediante las relaciones que existen ente los distintos componentes. Por un lado est la gestin de patrones, por otro lado el editor de clases y, entre estas dos partes est la aplicacin en si, que es la que une las dos funcionalidades incluyendo caractersticas propias necesarias para la interaccin entre las partes.

Figura 3-4. Diagrama de paquetes

Un diseo ms elaborado de este modelado conceptual, que ser la base para la elaboracin del sistema, se representa mediante el diagrama de la Figura 3-5, en la cul se ha incorporado un nuevo mdulo a los ya mencionados, que est relacionado con el editor de clases de la aplicacin, y es el encargado de ofrecer unas caractersticas y un cdigo XML para sus elementos. Por otro lado, relacionado con la gestin de patrones habr un repositorio con los patrones de colaboracin, en un principio. Aunque, como se ha comentado en otras ocasiones, este repositorio puede ser modificado por el usuario, hacindolo ms afn a sus necesidades.

Figura 3-5. Diagrama de clases de la aplicacin

Para entender el diagrama de clases de la aplicacin, se observar por separado el conjunto de las clases pertenecientes a cada uno de los distintos paquetes, analizando as en detalle la funcionalidad que aporta cada paquete y las clases por las que est compuesto cada uno de ellos.

3.2.4.1 El paquete APP

El paquete APP es el que encapsula las clases propias de la aplicacin, sobre las que se apoya el resto. Es la base para las dems clases del sistema. Estar compuesto por las clases: JInternalFrame: Es la clase que contiene la interfaz principal de la aplicacin. Ser el soporte para la clase MyInternalFrame, que a su vez, contendr las clases ms significativas de la aplicacin. La interfaz principal tendr un men desde el que se

podrn desplegar nuevas clases MyInternalFrame, lo cul permitir trabajar sobre ms de un diagrama de clases a la vez. MyInternalFrame: Esta clase estar compuesta por dos ventanas internas. Una de ellas, ClassFrame, ser la que se utilizar para realizar el diagrama de las clases y la otra, JTreeFrame, ser el rbol relativo a los patrones que hay disponibles para su utilizacin en el diagrama. JTreeFrame: Esta clase es la que corresponde al rbol de los patrones y sobre ella se sostiene lo relativo a la gestin de patrones. ClassFrame: Esta clase sirve de base para todo el soporte en lo referente a la edicin de clases en el diagrama.

3.2.4.2 El paquete Gestor de Patrones

El paquete Gestor de Patrones es el que contiene las clases necesarias para que los patrones puedan gestionarse de una forma eficiente y puedan aadirse al diagrama, comunicndose para ello con el paquete Editor de Clases. De esta manera, el paquete est compuesto por las clases DraggableTree, TransferableDataItem y Mensaje. Estas clases recogen los patrones que hay disponibles y le permiten al usuario utilizarlos en el diagrama de clases. Adems, dan la opcin de sustituir clases de los patrones por clases incluidas ya en el diagrama, a travs de un men intermedio. As mismo, este paquete est relacionado con el directorio donde estn almacenados los ficheros de los patrones, para poder acceder a ellos, mostrar los nombres y, en el caso de que el usuario lo seleccione, aadir estos patrones al diagrama de clases que est editando. Algunas de las clases contenidas en este paquete son las siguientes: DraggableTree: Esta clase corresponde a un rbol donde estn los patrones disponibles que el usuario puede utilizar. Se hace un recorrido por el directorio donde estn ubicados los patrones y va rellenando un rbol con los nombres de los ficheros donde estn almacenados los patrones que encuentra. Desde este rbol, el usuario podr seleccionar un patrn y, a travs de la clase TransferableDataItem, arrastrarlo hasta el diagrama, incorporndolo as al conjunto de sus clases.

TransferableDataItem: Es la clase que permite arrastrar un patrn al diagrama de clases. Para ello se selecciona el nombre del patrn del rbol de patrones y lo que se arrastra es el fichero al que corresponde ese patrn, de manera que al dibujar el patrn en el diagrama, acceder al fichero al que se hace referencia, a travs del patrn del rbol, y dibujar lo que se indique en el fichero. Mensaje: Esta clase relaciona el paquete Gestor de Patrones con el paquete Editor de Clases. Para ello toma como referencia las clases que hay dentro del fichero que se est arrastrando a la paleta de dibujo y permite sustituirlas por las clases que ya hay dibujadas en esta paleta. Si el usuario decide sustituir una de las del patrn por una de las existentes, en el momento de dibujar el patrn se har el cambio.

3.2.4.3 El paquete Editor de Clases

Este paquete va a tener las clases necesarias para la edicin de los diagramas de clases. Como base habr una paleta de dibujo, sobre la que se podrn dibujar clases, pudiendo tener atributos y mtodos asociadas. Tambin podrn dibujarse relaciones entre dos clases, que podrn ser de distintos tipos. Las clases contenidas en este paquete se ocupan de hacer posible que estas acciones se lleven a cabo de forma correcta. Las clases ms significativas de este paquete son las que se indican a continuacin: Paleta: Es la clase a travs de la cul se relaciona el paquete de edicin de clases con el de la aplicacin y con el de la gestin de patrones. A su vez, es la que contendr las clases que permiten la edicin de los diagramas, siendo el fondo sobre el que sustentan el resto de clases de este paquete. Esta clase es probablemente la ms importante del paquete, conteniendo un panel donde se dibujarn las clases y relaciones entre ellas, y una barra de herramientas cuyos botones permiten realizar las acciones necesarias sobre el diagrama de clases, para hacer ms funcional su edicin. Clase: Es la que contiene informacin sobre cada clase de las que se dibuja en el diagrama. Con ella se gestionan las caractersticas de cada clase, su identificador, su nombre, sus atributos, sus mtodos, las relaciones a las que est unida y las dimensiones dentro del diagrama, adems de la funcionalidad necesaria para relacionarse con el paquete de las propiedades.

Atributos: Se encarga de la gestin de los atributos dentro de las clases que estn incluidas en el diagrama. As llevar un control del nmero de atributos que tiene asignada una clase, sus nombres y tipo. Mtodos: De forma similar a la anterior, es la encargada de gestionar los atributos que hay en las clases. Relacin: Controla el dibujado y la informacin de las relaciones en el diagrama. Origen y Destino: Hace referencia a las clases que actan como origen y destino, respectivamente, dentro de las propiedades de las relaciones. Generalizacin, AdHoc y Agregacin: Corresponden a las distintas relaciones que se permiten en el diagrama de clases y cada una de ellas tiene las propiedades que le afectan asociadas.

3.2.4.4 El paquete Propiedades de los Elementos

Este paquete aade algunas caractersticas al diagrama de clases. Para ello, tiene dos clases bsicas asociadas: Propiedades: En esta clase se incluyen caractersticas que tendrn las clases y las relaciones que se incluyan en el diagrama de clases modelado. ViewCode: Esta clase representar el cdigo UsiXML asociado al diagrama de clases que haya dibujado en el panel.

3.2.5 Diagramas de secuencia

Para mostrar la forma en la que los objetos interactan para llevar a cabo cada una de las actividades, se representarn los diagramas de secuencia correspondientes a cada una de estas acciones. Probablemente, la actividad ms importante que cabe destacar en esta seccin es la secuencia de acciones que se llevan a cabo para incorporar un patrn al diagrama de clases en uso. A la hora de trabajar con patrones, se podrn tener dos situaciones: que las clases que se quieren insertar del patrn estn en el diagrama o que todava no hayan sido aadidas. Para

cada uno de los casos se analizar a continuacin las acciones que habr que realizar para incorporar el patrn al panel en el que las clases estn siendo dibujadas.

En el caso de insertar un patrn sustituyendo sus clases, la situacin es que se tienen ya dibujadas una serie de clases y posibles relaciones en el diagrama. Se selecciona un patrn para arrastrarlo al panel, pero las clases que se quieren del patrn ya estn en el diagrama de clases, de forma que se quiere sustituir alguna de las clases del patrn por otras de las que ya se han incluido anteriormente. De esta forma, el diagrama de secuencia correspondiente a este escenario, sera el representado en la Figura 3-6.

Figura 3-6. Diagrama de secuencia para insertar patrn sustituyendo clases

En el caso de insertar un patrn sin sustituir sus clases, se arrastra un patrn desde el rbol hasta el panel de dibujo y se quiere que las clases sean las mismas que tiene el patrn. Es decir, se pretende dejar las clases que ya hay dibujadas como estn y aadir el patrn seleccionado tal cual. Para este escenario, las acciones que habra que llevar a cabo son las representadas en el diagrama de secuencia de la Figura 3-7.

Figura 3-7. Diagrama de secuencia para insertar patrn sin sustituir clases

En este diagrama se ha tenido en cuenta que ya haba alguna clase en el panel de dibujo cuando se ha arrastrado el patrn. De no ser as, no aparecera el mensaje que se muestra al usuario para que pueda sustituir las clases del patrn por las ya representadas. Las dems acciones que se llevaran a cabo son las que se representan en este diagrama, con la nica

excepcin que se ha comentado. Cuando se reconoce que no hay clases dibujadas en el diagrama, directamente se dibuja el patrn que el diseador ha arrastrado hasta el panel.

3.3 Descripcin y almacenamiento colaboracin en XML

de

los

patrones

de

Se ha querido proporcionar un repositorio donde tener almacenados los patrones de colaboracin, en un principio, y, posteriormente, todos los patrones que el usuario aada o modifique. Este repositorio estar en el directorio patrones que acompaa al ejecutable facilitado en este proyecto final de carrera. Los patrones se almacenaran en ficheros, dentro del directorio especificado, utilizando para su especificacin el lenguaje UsiXML. UsiXML (User Interface eXtensible Markup Language) (http://www.usixml.org) es un lenguaje de descripcin de interfaces de usuario, es declarativo y captura la esencia de lo que es una interfaz de usuario independiente de las caractersticas fsicas. Est basado en XML. Puede describir interfaces para mltiples contextos de uso, con independencia del dispositivo, de la plataforma y de la modalidad de interaccin. Est basado en los principios de modelado MDA. Adems, UsiXML permite la reutilizacin de las especificaciones de interfaz de usuario realizadas con anterioridad. Por otro lado, XML (eXtensible Markup Language) (http://www.w3.org/XML/) es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificacin y adaptacin del SGML y permite definir la gramtica de lenguajes especficos. Por lo tanto, XML es una manera de definir lenguajes para diferentes necesidades. XML, adems de su aplicacin en Internet, se propone como un estndar para el intercambio de informacin estructurada entre diferentes plataformas. XML es una tecnologa sencilla que tiene a su alrededor otras que la complementan y la hacen mucho ms grande y con unas posibilidades mucho mayores. Tiene un papel muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la informacin de una manera segura, fiable y fcil.

Por todas estas razones se he elegido este lenguaje para la definicin de los patrones. Para la especificacin de los patrones en UsiXML se ha tenido en cuenta la estructura para el modelado del dominio, donde se representan las clases y relaciones. El diseo que se ha seguido es el recogido en la Figura 3-8, donde se muestran, adems de las clases, los atributos y los mtodos que cada una de ellas tendr asociados y las relaciones que pueden incluirse entre ellas. Se observa que este modelo es similar al utilizado para la representacin de diagramas de clases del proyecto, hecho que es lgico si se tiene en cuenta que los patrones son, en definitiva, diagramas de clases que podemos disear directamente desde esta herramienta.

Figura 3-8. Modelo de dominio de clases

En este modelo se han incluido las propiedades de cada una de las clases. Estas son las que se mostrarn en el caso que el usuario edite una clase, un atributo, un mtodo, etc. Adems, estas propiedades tambin se vern reflejadas en el cdigo XML asociado al diagrama, para poder posteriormente recuperar el diagrama a travs de este cdigo.

Como ejemplo, se ver el patrn Actor-Role, descrito en el captulo anterior. Se recuerda que la apariencia que tiene este patrn es la reflejada en la Figura 3-9.

Figura 3-9. Patrn Actor-Role

La descripcin en UsiXML de este patrn sera la indicada en la Tabla 3-13.

<?xml version="1.0" encoding="UTF-8"?> <domainModel xmlns:ipo="http://www.usiXML.org" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.usiXML.org C:\Ejemplo\usiXML-domain.xsd" id="dm0" name="domainmodel" creationDate="2004-06-04T16:20:40.12+01:00" schemaVersion=""> <version modifDate="2004-06-04T16:20:40.12+01:00"/> <authorName/> <comment/> <domainClass id="idc0" name="Actor"> </domainClass> <domainClass id="idc1" name="Role"> </domainClass> <association id="idr0" name="" sourceId="idc0" targetId="idc1" roleAName="has" roleBName="had" cardRoleA="1" cardRoleB="0..n" /> </domainModel> Tabla 3-13. Actor-Role.usi

En la descripcin de los patrones no se han aadido atributos ni mtodos adicionales a las clases para que el usuario pueda adaptarlos a sus necesidades, aadiendo l mismo los que crea ms convenientes.

3.4 Descripcin del entorno elaborado

En este apartado se analizar el entorno de la aplicacin y se distinguirn las opciones posibles para su ejecucin. Para ello se ver detenidamente la funcionalidad que la herramienta presenta, y los pasos que habr que seguir hasta llegar al resultado deseado. Para comprender mejor el procedimiento, se irn aadiendo vistas de la aplicacin en los distintos casos y se explicar cmo llegar a cada situacin.

La interfaz principal de la aplicacin est compuesta por: una barra de ttulo, donde aparece el nombre de la aplicacin una barra de mens, compuesta por File, Edit, Window y Help una ventana interna, donde aparecen los patrones que hay disponibles para poder ser reutilizados otra ventana interna donde puede disearse el diagrama de clases. Tanto la ventana principal como cada una de las dos ventanas internas pueden minimizarse, maximizarse y cerrarse. Estas opciones vienen sealadas con un dibujo intuitivo en el botn correspondiente Ms adelante se analizar en detalle cada una de las distintas partes de las que se compone esta aplicacin, explicando cmo funcionan y las posibilidades que ofrecen. En la Figura 3-10 puede observarse la apariencia que tiene la ventana principal inicialmente, y en ella se diferencian claramente las partes que la componen, que se comentaban anteriormente.

Figura 3-10. Interfaz de la aplicacin

Cabe destacar de esta interfaz su sencillez. En la parte izquierda se observa el rbol de los patrones que hay disponibles en el momento. En un principio solamente contendr los patrones de colaboracin, de la coleccin de (Nicola et al., 2001), aunque en un futuro esta lista de patrones puede completarse y hacerse ms compleja con los patrones que el diseador incluya en el repositorio, en el caso de que lo estime oportuno, y dependiendo de sus necesidades en el momento de representar los diagramas de clases en el panel. En la parte derecha se observa el panel de dibujo donde el diseador crear su diagrama. En la parte superior dispone de una barra de herramientas a travs de la cul podr ir diseando el diagrama, con la introduccin de las clases o relaciones que necesite, sin ms que seleccionar la clase o relacin con el ratn, y situar posteriormente el puntero en la zona del panel donde quiere aadir la figura. La barra de herramientas del panel consta de unos iconos bastante intuitivos, cuya funcionalidad se describe brevemente al pasar el ratn por sus iconos. En la tabla 3-14 se identifican estos iconos y se da una breve explicacin de su funcionalidad.

Figura

Nombre

Descripcin Puntero en modo seleccin Selecciona la clase para aadir al diagrama Selecciona la relacin de dependencia Selecciona la relacin de generalizacin Selecciona la relacin de asociacin Selecciona la relacin de agregacin Selecciona la relacin de composicin

Tabla 3-14. Iconos de la barra de herramientas del panel

Estos iconos se utilizan para el diseo del diagrama. Al posicionar el puntero del ratn sobre estos iconos, aparece una breve explicacin emergente de este botn, que nos indica su

significado. Adems, se indica una combinacin de teclas cuyo uso tiene la misma accin que si se pulsa este botn. El modelado del diagrama de clases se hace segn el UML, especificado en http://www.uml.org/. De esta manera, en un diagrama de clases podr haber clases y relaciones de los distintos tipos que se han comentado. Para aadir una clase al diagrama, habr que seleccionar el botn class y a continuacin indicar con el ratn el punto del diagrama sobre el que quiere representarse la clase. Inicialmente esta nueva clase tendr el mismo nombre que el identificador que le pertenezca. Este identificador ser un nombre que comience por idc, seguido del nmero de clases que se han aadido al diagrama hasta el momento en que se ha puesto esta clase. La representacin de una clase ser un recuadro que consta de tres partes: en la parte superior se ver el nombre de la clase. Adems, si una clase determinada estaba en el diagrama y, al arrastrar un nuevo patrn, se ha sustituido esta clase por una de las del patrn, debajo del nombre de la clase aparecer entre los signos << y >> el estereotipo, o lo que es lo mismo, el nombre de la clase del patrn que sustituye. En la parte central aparecern los atributos que tiene asociados la clase. Cada atributo aparecer en una lnea distinta, indicando el modo de acceso, el tipo y el nombre de cada uno y finalizando con punto y coma. En la parte inferior de la clase se mostrarn los mtodos que tenga asociados la clase, de modo que se ver el modo de acceso, el tipo que devuelve el mtodo y su nombre, seguido de los parmetros que haya que pasrsele, entre parntesis, y punto y coma. Igual que en el caso de los atributos, los mtodos se mostrarn cada uno en una lnea distinta dentro de la clase.

Nombre de clase << Estereotipo>> Atributos de la clase Mtodos de la clase

Figura 3-11. Partes de una clase

Para modificar el nombre de una clase, se har clic con botn derecho del ratn sobre la parte de arriba en la representacin de la clase en el diagrama, donde aparece el nombre. Aparecer un men con varias opciones donde habr que elegir edit class para que se abra una ventana donde se indican las caractersticas de la clase, que sern identificador y nombre y ste ltimo valor podr modificarse si se desea. En la Figura 3-12 se observa el men de las acciones que pueden ejecutarse sobre una clase y la ventana que aparece cuando la editamos. En esta ventana hay una tabla donde en el nico campo que el usuario podr escribir para modificarlo ser en el nombre de la clase.

Figura 3-12. Caractersticas de una clase

El usuario no podr dar a la clase un nombre que empiece por las letras idc, para que no haya conflictos con los nombres al crear nuevas clases. En el caso de que el usuario intente dar un nombre as, el sistema mostrar un mensaje indicando que esto no puede hacerse. Asimismo, el nombre de la clase no se ver modificado a no ser que el usuario le asigne un nombre vlido, y que no est repetido en el diagrama.

En la Figura 3-13, hay una clase en el diagrama a la que se le intenta cambiar el nombre por idc1. En este caso, el sistema muestra el mensaje de error que aparece en la figura y sigue abierta la ventana de las propiedades de la clase, donde el usuario podr dar un nombre vlido a la clase. En el caso de que se cierre esta ventana sin que el nombre que se le haya indicado sea vlido, la clase seguir llamndose idc0.

Figura 3-13. Cambio de nombre no permitido para una clase

Por otro lado, si se intenta modificar el nombre de una clase, asignndole otro nombre que ya est siendo utilizado por alguna clase en el diagrama, el sistema le informar de la situacin mediante un mensaje y no se lo permitir. Por ejemplo, si hay una clase en el diagrama con nombre usuario y se intenta cambiar el nombre de una segunda clase para asignarle este mismo nombre, el sistema sacar por pantalla el mensaje mostrado en la Figura 3-14 y dejar abierta la ventana de las propiedades para que lo intente con otro nombre vlido. De no ser as, se mantendr el nombre que tena asignado la clase antes de intentar cambirselo. Para comprobar que no haya nombres repetidos, no se tendr en cuenta si est en maysculas o minsculas o si hay espacios al principio o al final del nombre.

Figura 3-14. Cambio de nombre duplicado para una clase

Por otro lado, si se selecciona la opcin de eliminar la clase, el sistema preguntar al usuario si realmente quiere seguir adelante con esa opcin porque de ser as no solo se eliminar la clase, sino que tambin se eliminarn del diagrama las relaciones que tengan a esta clase como origen o como destino. Adems, no habr forma de recuperarlas una vez eliminadas, sin otra opcin que volver a incorporarlas al diagrama desde el principio.

Figura 3-15. Mensaje de confirmacin para eliminar una clase

Para aadir un nuevo atributo a al clase seleccionada, se har clic con el botn izquierdo del ratn sobre el dibujo que aparece en la parte central, destinada a los atributos, en la clase. Se trata del dibujo marcado en la Figura 3.16. De esta manera, se abre una ventana que permite otorgar de una serie de propiedades al atributo.

Figura 3-16. Propiedades de un atributo

Entre las propiedades del atributo est un identificador, que la aplicacin asigna automticamente en el momento de aadir un nuevo atributo a la clase, y cuyo valor no puede modificarse por el usuario. Este valor ser un string que empieza por el identificador de la clase, seguido de una a y el nmero de atributos que se le han aadido a la clase hasta el momento. Adems, cada atributo tendr: un nombre, que ser una cadena que el usuario podr darle libremente el tipo de dato del atributo, para lo que el usuario podr darle un valor entre void, boolean, date, int, float, double, string, o cada uno de los nombres que tienen las clases que existen en el diagrama cardinalidad mnima del atributo, donde el usuario podr darle un valor entre 0, 0..1, 0..n, 1, 1..n, n o dejarlo sin especificar cardinalidad mxima del atributo, donde, al igual que en caso anterior, el usuario podr darle cualquiera de esos valores el modo de acceso del atributo, donde el usuario podr elegir un valor para cada atributo entre friendly, private, protected y public En caso de que se desee modificar alguno de los valores para las propiedades de un atributo ya definido, habr dos formas de hacerlo: bien pinchando con el botn izquierdo del

ratn sobre ese atributo en lugar del dibujo que se ha indicado antes, o bien pinchando con el botn derecho sobre el atributo, entonces saldr un men donde habr que seleccionar la opcin edit atributte. De esta manera, aparecer nuevamente la ventana que acaba de describirse, de las propiedades del atributo, con los valores dados hasta el momento, y donde podrn cambiar las propiedades del atributo seleccionado.

Figura 3-17. Men de acciones para un atributo

Si lo que se quiere aadir es un nuevo mtodo a una clase, se har clic con el botn izquierdo del ratn sobre el dibujo que aparece en la parte inferior, destinada a los mtodos, dentro de la clase a la que se le desee incorporar el nuevo mtodo. De forma semejante al caso de los atributos, se abre una ventana que permite dar valores a las propiedades del mtodo.

Figura 3-18. Propiedades de un mtodo

La primera propiedad de un mtodo, cuyo valor asigna la aplicacin automticamente en el momento de aadirlo, es el identificador. Su valor es un string que empieza por el identificador de la clase, seguido de una m y el nmero de mtodos que se han aadido a la clase anteriormente, y no podr ser modificado. Conjuntamente, cada mtodo tendr otras propiedades que el usuario podr modificar: el nombre del mtodo, para el cul, el usuario podr asignar cualquier cadena

el tipo del valor que devuelve el mtodo, donde el usuario podr seleccionar el tipo que desee entre void, boolean, date, int, float, double, string, y cada uno de los nombres que les ha dado a las clases que ha creado en el diagrama el modo de acceso del mtodo, donde el usuario podr elegir un valor entre friendly, private, protected y public parmetros: este campo lo podr rellenar el usuario como desee y en la clases se ver este valor entre parntesis, al lado del nombre del mtodo Para modificar los valores de las propiedades de un mtodo, se har clic con el botn izquierdo del ratn sobre el mtodo deseado, en lugar del dibujo que se ha comentado, con el fin de abrir nuevamente la ventana de las propiedades del mtodo con los valores dados hasta ese momento. Otra forma de acceder a esta ventana es haciendo clic con el botn derecho del ratn sobre el mtodo deseado, y seleccionando edit method del men que se despliega. Aqu podrn modificarse estos valores nuevamente.

Figura 3-19. Men de acciones para un mtodo

La segunda opcin de las posibles que aparecen al hacer clic con el botn derecho del ratn sobre un atributo o sobre un mtodo, es delete attribute o delete method, respectivamente. Si el usuario selecciona esta opcin, el sistema mostrar un mensaje informativo, similar al que abrir cuando se selecciona la opcin de eliminar una clase, para que se confirme si realmente se desea eliminar el atributo o mtodo seleccionado. En este caso tendr dos opciones: confirmar o denegar. Si se pulsa si, se borrar el atributo o mtodo seleccionado y si se pulsa no, se quedar como estaba. Las siguientes opciones que aparecen al hacer clic con el botn derecho del ratn sobre una clase, independientemente de la parte sobre la que se site, afectan a la clase y no solo a los atributos o los mtodos de esta. Estas opciones son para cambiar el color de una clase, y para moverla al frente o al fondo, si est solapada con otras.

Figura 3-20. Men de acciones para una clase

Las relaciones entre las clases pueden ser de dependencia, de generalizacin, de asociacin, de agregacin o de composicin. Segn se trate de un tipo relacin u otro, tendr un aspecto distinto. En los botones que aaden las relaciones al diagrama aparece esta apariencia de cada una de las relaciones para que el usuario pueda seleccionarla a la hora de incorporarla en el panel. Para aadir una relacin al diagrama, primero se seleccionar el botn perteneciente al tipo de relacin que se quiere, en la barra de herramientas situada en la parte superior del panel de dibujo. A continuacin se marcar con el ratn la clase que se quiere como origen de la relacin y despus la clase que se quiere que sea el destino. De esta manera, se dibuja la relacin entre estas dos clases. En el momento en que se crea una relacin, el sistema le asocia un identificador que el usuario no podr modificar. Este dato ser un string que empezar por idr, seguido del nmero de relaciones que se han aadido al diagrama antes que ella. Todas las relaciones tienen asociados una serie de datos que son comunes independientemente del tipo que tengan. Estos datos comunes son, adems del identificador, los siguientes: nombre de la relacin: es un dato de tipo string que podr proporcionar el usuario. Su valor aparecer en el centro de la lnea que representa grficamente la relacin en el diagrama. identificador de la clase origen de la relacin. Su valor lo asigna directamente la aplicacin a la relacin cuando esta se crea, tendiendo en cuenta la primera clase que conecta.

identificador de la clase destino de la relacin. Al igual que en el anterior, ser un valor que proporciona la aplicacin que en este caso corresponder con la segunda clase que una la relacin. Otra propiedad de las relaciones es el role que desempean cada clase dentro de la relacin. En todos los tipos de relacin se proporciona un role a la clase origen y otro a la clase destino, excepto en las relaciones de herencia, que solo se contemplar el role del origen. Estos roles son valores que proporciona la aplicacin a cada relacin en el momento de aadirla, y variarn teniendo en cuenta la naturaleza de cada relacin. En todos los tipos de relaciones, excepto en las de herencia, hay dos valores que el usuario puede elegir entre una serie de opciones. Estos valores se refieren a la multiplicidad que tiene la relacin y se dar un valor para la cardinalidad que podr tener el role origen y otro valor para la cardinalidad que podr tener el role destino. Los valores que podr tomar este campo son: 0, 0..1, 0..n, 1, 1..n y n, adems de poder dejarlo sin especificar. En caso de que el usuario d uno de estos valores concretos a la multiplicidad, este se ver representado en la relacin, en el lado de la clase que corresponda. Adems, si se trata de una relacin de dependencia, se aadirn dos campos que reflejarn roleAInstanciatedCard. Para ver y poder modificar los valores que tiene una relacin asociados se har clic con el botn derecho del ratn sobre la relacin, saliendo el men que se muestra en la Figura 321, y a continuacin se seleccionar edit relationship.

Figura 3-21. Men de acciones para una relacin

En la Figura 3-22 se observa cada uno de estos campos para las propiedades de los cinco tipos de relaciones que pueden representarse en un diagrama de clases con esta aplicacin. Los valores que vienen dados son los que asigna la herramienta automticamente y que el usuario no puede modificar.

Figura 3-22. Tablas de las propiedades para cada uno de los tipos de relaciones posibles

Las acciones que se podrn ejecutar sobre una relacin sern editarla o borrarla. Si se selecciona la opcin de eliminar una relacin, el sistema mostrar al usuario un mensaje para que confirme si realmente desea borrarla del diagrama de forma permanente.

Figura 3-23. Mensaje de confirmacin para eliminar una relacin

El primer botn que aparece en la barra de herramientas del panel, y el nico que queda por comentar es el de la flecha. Este botn lo que har es darle al puntero del ratn la

funcin de seleccionar. Se marcar cuando se tenga seleccionado el de la clase o el de una relacin y el usuario no quiera incorporar esta al diagrama. La funcionalidad ms importante que se ha incluido en esta herramienta es la de incorporar patrones, previamente establecidos, en el diagrama de clases que se est realizando, sin tener que ir incluyendo cada una de sus clases y relaciones uno a uno. Esto facilita la labor del diseo y la hace ms rpida y eficaz. Para aadir un patrn, se selecciona con el ratn el que le interese al usuario, de entre los disponibles en el rbol que aparece en la ventana de la izquierda en la interfaz, y se arrastrar hasta el panel de dibujo donde se est representando el diagrama. Si hasta ese momento no hay ninguna clase incluida, el patrn se dibuja directamente, con las clases y relaciones que se incluyen en l. Si al arrastrar el patrn al panel de dibujo, hay alguna clase ya dibujada, el sistema muestra al usuario una ventana. En esta aparecen los nombres de las clases que tiene el patrn en el lado izquierdo, y en el lado derecho un men despegable por cada una de las clases del patrn, con los nombres de las clases que ya estn dibujadas en el diagrama en ese momento. El usuario puede asociar una clase de las ya existentes para que ocupe el lugar de la que forma parte del patrn. As la del patrn ser sustituida por la ya existente y debajo de su nombre se mostrar entre los signos << y >> el nombre de la clase del patrn que representa. Si, por el contrario, el usuario deja seleccionada la opcin ninguno del men, y pulsa Ok, se aadirn nuevas clases para representar el patrn arrastrado. Ocurrir lo mismo si despus de seleccionar cualquier opcin en los mens despegables, el usuario pulsa la opcin Cancel o cierra la ventana. Las relaciones del patrn tambin sern representadas en el diagrama entre las clases originales del patrn o entre las que el usuario haya elegido como sustitutas de estas. De esta forma tambin se ver representado su nombre y la multiplicidad entre las clases vinculadas. Una restriccin dentro de los diagramas es que no va a poder haber ms de una relacin del mismo tipo entre dos clases, de manera que si existe una relacin determinada entre dos clases y se intenta aadir una del mismo tipo con las mismas clases origen y destino, esta segunda relacin no se incorporar al diagrama, permaneciendo en l la primera, aunque el nombre o la multiplicidad de cada una sean distintas.

En la Figura 3-24 se muestra el proceso para incorporar un patrn al diagrama. Puede observarse la apariencia de la aplicacin y el mensaje intermedio para que el usuario pueda sustituir las clases del patrn por las que ya tiene dibujadas. Para este caso se supone que hay representada una clase libro, con sus atributos y mtodos. En el rbol de patrones donde se indican los patrones que hay disponibles en el repositorio, se buscara el patrn Assembly-Part y se arrastrara desde este rbol hasta el panel del diagrama de clases. A continuacin se abrir una ventana dnde indicar que se seleccionen las clases que se quieren cambiar. Para cada clase que contiene el patrn se podr asociar una de las clases que ya estn representadas, para ser sustituidas por estas ltimas. En este caso, se sustituir la clase Assembly del patrn por la clase libro, que ya est dibujada en el diagrama. Al acabar la seleccin de las clases para la sustitucin dentro del patrn, se pulsar el botn Ok y esta ventana se cerrar. De esta manera, solo se aadira una nueva clase al diagrama, que sera la clase Part, perteneciente al patrn, y la relacin existente entre ambas. Echo esto, solo faltara aadir los atributos o mtodos que se deseen a la nueva clase. Como la clase libro es parte del patrn y ha pasado a desempear la funcin de la clase Assembly, esto se indicar mediante el estereotipo, de manera que la clase a la que sustituye dentro del patrn aparece debajo del nombre de la propia clase, entre los signos << y >>. Si ms tarde, esta clase volviera a sustituir a otra de un patrn que se aada, el estereotipo se modificar de forma que siempre tendr la ltima clase del patrn que haya sustituido.

En el caso de que haya en el panel una clase con el mismo nombre que alguna de las contenidas en el patrn que se va a utilizar, y esta segunda clase no es sustituida por ninguna

Figura 3-24. Utilizar patrn

otra, al representarse en el panel, su nombre se ver modificado de forma que lo haga nico en el diagrama. Para ello se le aadir un nmero al valor que ya tiene. Como ejemplo, puede tenerse en el panel una clase cuyo nombre sea Actor y a continuacin, el usuario utiliza el patrn de colaboracin actor-role, sin sustituir ninguna clase por otra. El resultado sera el mostrado en la Figura 3-25.

Figura 3-25. Nombres de las clases de los patrones

El color con el que se dibujarn las clases en el diagrama, en un principio, y a no ser que el usuario indique otra cosa, es blanco, igual que el fondo del panel de dibujo. Pero existe la posibilidad de modificar este color, de modo que podran simularse distintos paquetes, representando las clases que pertenecen a uno u a otro de un color distinto. De igual forma, podra cambiarse el color a algunas clases que se consideren especiales, dependiendo de las necesidades o gustos del usuario. Esta funcionalidad se obtiene mediante la opcin set color, que est en dos sitios. Por un lado, si se tiene una clase ya representada en el diagrama, y se desea darle un color distinto, se seleccionar la clase y se har clic con el botn derecho del ratn sobre cualquier parte de la

clase, apareciendo un men donde estar incluida esta opcin. Si se selecciona set color, se abrir una nueva ventana donde el usuario podr elegir el color deseado para la clase seleccionada. Por otro lado, si en la barra de mens, el usuario selecciona Edit > Set Color, saldr la misma ventana donde se le permitir al usuario optar por el color que prefiera. Pero en este caso, el color afectar a las clases que dibuje a continuacin.

Figura 3-26. Cambio de color de una clase

La eleccin de distintos colores facilita distinguir de un vistazo los diferentes tipos de clases representadas. Una vez que se ha realizado el diagrama de clases deseado, ste puede guardarse en dos formatos distintos: con extensin .usi y con extensin .jpg. Adems, tambin puede imprimirse. Si se desea guardar el diagrama en cdigo UsiXML, lo que har es convertir cada dato del diagrama en este lenguaje. Para ello se seleccionar de la barra de men la opcin File > Save, con lo cual se abre una ventana donde podr escogerse el directorio donde guardar el archivo y el nombre con el que desea guardarse, con extensin .usi.

Tambin puede guardarse el dibujo del diagrama representado, para ello se seleccionar Save Graphics en lugar de Save y se abrir una ventana semejante a la de antes, donde se ha de elegir el directorio y nombre con el que se guardar la figura, con formato .jpg. De esta forma, podr abrirse posteriormente con cualquier visor de imgenes que permita este formato. Las ventanas que se abren para seleccionar el nombre y directorio en ambos casos quedan representadas en la Figura 3-27 y 3-28 respectivamente.

Figura 3-27. Ventana para guardar el cdigo del diagrama de clases

Figura 3-28. Ventana para guardar la imagen del diagrama de clases

Otras opciones para guardar el diagrama es mediante las combinaciones de teclas Alt+S, si se desea guardar el cdigo, o Alt+G, si lo que se quiere guardar es la imagen. En ambos casos se abren las mismas ventanas que se comentaban anteriormente para seleccionar el directorio y el nombre con el que desea guardarse. Un diagrama anteriormente guardado con formato UsiXML, puede abrirse desde la aplicacin, de forma que aparecer en el panel de dibujo como se haba guardado, manteniendo las mismas clases, relaciones y propiedades. Habr dos formas para abrir un archivo con extensin .usi: seleccionando del men la opcin File > Open, o pulsando la combinacin de teclas Alt+O. Ambas opciones abrirn una nueva ventana donde el usuario podr navegar entre las carpetas de su ordenador para acceder al archivo que desea abrir.

Si el usuario desea abrir un nuevo panel de dibujo vaco, deber seleccionar del men la opcin File y despus New, o con la combinacin de teclas Alt+N. Si en el panel actual hay algo dibujado, tanto si se cierra este panel, como si se selecciona la opcin de abrir un archivo existente o un nuevo panel vaco, el sistema preguntar al usuario si desea guardar el diagrama en el que est y le dar la opcin de seleccionar el directorio y el nombre que desee para ello. El diagrama dibujado en el panel tiene un cdigo XML asociado, que ser similar al que se guarda con la opcin de guardar con extensin .usi y que el usuario puede visualizar en cualquier momento. Para ello seleccionar del men la opcin Window > XML, o pulsar la combinacin de teclas ALT+X. En ambos casos se abrir una nueva ventana donde aparece el cdigo XML que corresponde al diagrama representado en el panel del dibujo en ese momento. Con el ejemplo del libro mostrado anteriormente, en la Figura 3-24, con la explicacin del proceso a seguir para aadir un patrn al diagrama, se obtendra el cdigo mostrado en la Figura 3-29.

Figura 3-29. Cdigo UsiXML para un diagrama de clases

Si el usuario cierra la ventana del rbol de los patrones o la del editor de clases, podr abrirlas nuevamente simplemente seleccionando del men Window > Patterns o Window >

Diagram editor para abrir una u otra. Otra opcin es con la combinacin de teclas ALT+P o ALT+D respectivamente. Estas opciones no estarn disponibles si las ventanas ya estn abiertas. El usuario tendr distintas formas de organizar estas ventanas, dentro del men Window, con las opciones Next, Cascade y Tile, o con las combinaciones de teclas ALT+N, ALT+C y ALT+T respectivamente. La aplicacin tambin ofrece la posibilidad de imprimir el diagrama que hay representado en el editor. Para ello, el usuario seleccionar del men las opciones File > Print, y se abrir una ventana representada en la Figura 3-30, para seleccionar la impresora y algunas opciones.

Figura 3-30. Ventana para imprimir un diagrama de clases

El usuario puede examinar la ayuda de la aplicacin en la opcin Help del men o con las teclas ALT+H. De este modo se abrir una nueva ventana donde se podr acceder a un manual de esta aplicacin.

El acerca de de la aplicacin puede consultarse en la opcin Help > About us... del men, o con la combinacin de teclas ALT+A. As se abrir una ventana con informacin de la aplicacin como la versin y los autores de esta, como se indica en la Figura 3-31.

Figura 3-31. About us... de la aplicacin

Para cerrar la aplicacin puede pulsarse con el ratn en la cruz de la esquina superior derecha o mediante la opcin File y Quit del men, o mediante la combinacin de teclas ALT+Q. De esta forma, la ventana principal de la aplicacin se cerrar sin ms.

3.5 Anlisis y discusin

Siguiendo la trayectoria que ha llevado la Ingeniera del Software desde los tiempos de su aparicin, se observa una tendencia al modelado, y por eso UML y MDD tienen una importancia tan grande en el desarrollo. Por otro lado, en los ltimos tiempos se apuesta cada vez ms por las metodologas giles. Por eso se considera interesante que existiera algn tipo de metodologa gil con modelado. La herramienta propuesta puede ser una buena eleccin para realizar ese modelado debido a su sencillez de uso y eficiencia, al poder incluir directamente patrones en el diagrama, lo que hace que la tarea del modelado se realice de una manera ms rpida al estar el diseador familiarizado con el trmino y los distintos patrones que pueden incluirse.

Captulo 4. Caso de estudio: utilizacin del entorno facilitado

El tipo de herramienta propuesta en este proyecto final de carrera puede resultar de gran utilidad en determinadas asignaturas de Ingeniera del Software, en los estudios de Ingeniera Informtica. Su principal importancia reside en la facilidad con la que puede ser tratado el modelado del dominio gracias a ella y la fcil inclusin de los patrones en el diagrama. Por eso se cree que su utilizacin en la primera toma de contacto con el modelado puede facilitar la manera de modelar para los estudiantes inexpertos, al poder utilizar la experiencia de otros en sus propios trabajos.

4.1 Descripcin del caso de estudio

Para probar la herramienta, se mostrar su utilizacin para el modelado de un ejemplo concreto. Para ello se describir el problema y a continuacin se har el correspondiente diagrama de clases con la aplicacin desarrollada. De esta forma, se identificarn y utilizarn los patrones de colaboracin que se encuentren en el modelo y se irn explicando los pasos a llevar a cabo. En primer lugar, se explicar en lo que consiste el caso de estudio que se ha considerado. Se trata de proponer un diagrama de clases para gestionar una empresa de autobuses como la descrita a continuacin. Para ello debe tenerse en cuenta cada una de las caractersticas reseadas.

Se desea disear un modelo de representacin de compaas de autobuses que sea capaz de gestionar las reservas que los clientes de la compaa deseen realizar sobre los diferentes trayectos que sta realiza. El modelo debe cumplir los siguientes requisitos: Las compaas de autobuses realizan trayectos entre dos ciudades (origen y destino), con un nmero, una fecha y una hora de salida y otra de llegada. Los trayectos se realizan en autobuses que tienen un modelo, una matricula y la capacidad mxima que admiten. Las personas que participan en el modelo tienen todas: nombre, DNI, direccin, nmero de telfono y edad, y sern empleados o pasajeros. Los empleados tienen un nmero de seguridad social y se conoce su antigedad en la empresa. Los pasajeros tienen un cdigo de cliente. Los autobuses slo realizan un trayecto y un trayecto slo lo realiza un autobs. Para que un pasajero pueda viajar en un autobs debe hacer una reserva sobre un determinado trayecto. Las reservas tienen un precio y un nmero de asiento en el autobs.

4.2 La especificacin grfica

Para la elaboracin del diagrama de clases, lo primero que habr que hacer es identificar las entidades existentes en el caso de estudio. Cada entidad se corresponder con una nueva clase en el diagrama. Adems, habr que conocer las caractersticas que tendr cada entidad encontrada, que sern los atributos que habr de tener la clase. Todos los atributos de todas las clases sern privados, para que nicamente pueda accederse a ellos a travs de los mtodos permitidos. Por otro lado, ser necesaria la posibilidad de realizar una serie de acciones sobre cada una de estas entidades con el fin de poder controlar la gestin de esta empresa de autobuses. Estas acciones sern los mtodos que llevar asociados cada una de las clases, los cuales habr que identificar. A continuacin se muestran las clases que habr que considerar en el modelo, junto con sus atributos y los mtodos que llevar asociados cada una de ellas. COMPAA: Son cada una de las compaas de autobuses que se contemplan. Para diferenciarlas entre s tendrn asociado un atributo que es el nombre de la compaa. Sus mtodos son: altaEmpleado(string, string, int): void da de alta a un nuevo empleado en la base de datos de la compaa. Necesita como parmetros el nombre, el DNI y el nmero de la seguridad social del empleado. altaPasajero(string, string): void da de alta en la base de datos un nuevo pasajero que viaja con la compaa. Necesita conocer el nombre y el DNI del pasajero. altaAutobs(string, string, int): void da de alta en la base de datos un nuevo autobs que tendr la compaa a su servicio. Recibe como parmetros el modelo y la matrcula del nuevo autobs y el nmero de plazas del que dispondr. altaTrayecto(string, string, autobs): void da de alta un nuevo trayecto que contemplar la compaa. Necesita saber el lugar de origen y de destino de dicho trayecto y el autobs que lo cubrir. buscarTrayecto(string, string, date) : trayecto busca en la base de datos de la compaa un trayecto que cumpla con los requisitos indicados. Coge

como parmetros el lugar de origen y de destino y la fecha de salida que ha de tener el trayecto y devuelve el trayecto encontrado que ofrece la compaa con estas caractersticas. addPasajero(pasajero): void aade un pasajero a los atendidos por la compaa. Recibe como parmetro dicho pasajero. addEmpleado(empleado): void aade un nuevo empleado contratado por la compaa. Necesita como parmetro dicho empleado. addAutobs(autobs): void aade, a los que ya tiene la compaa, un nuevo autobs, el cual necesitar como parmetro. Para que en el modelo, la clase compaa ofrezca toda esta informacin descrita, deber aparecer como se muestra en la Figura 4-1.

Figura 4-1. Clase compaa

TRAYECTO: Es cada uno de los viajes que ofrecer la compaa. Cada trayecto llevar asociado un nmero, que ser el que lo identifique entre el resto de trayectos existentes. Adems, se identificar un origen y un destino, que son las ciudades entre las que estar el trayecto, y una hora de salida y de llegada. Necesita los siguientes mtodos: trayecto(): trayecto crea un nuevo trayecto. solicitarPlaza(): reserva se solicita una plaza para el trayecto y devuelve una reserva para este. addReserva(reserva): void aade una reserva a las ya gestionadas. Necesita como parmetro la reserva de la que se trata.

De esta forma, la clase trayecto tendr una apariencia similar a la reflejada en la Figura 4-2 en el modelo.

Figura 4-2. Clase trayecto

AUTOBS: Es cada uno de los autobuses que tiene la compaa y que se dedicar a cubrir los trayectos ofrecidos por esta. De cada autobs se conocer el modelo y matrcula del vehculo y la capacidad mxima de viajeros que admite. Los mtodos de los que dispondr son los siguientes: Autobs(string, string, int): autobs es un constructor de autobs, al que se le pasarn como parmetros el modelo, la matrcula y la capacidad y devolver el propio autobs. La representacin grfica de esta clase se muestra en la figura 4-3.

Figura 4-3. Clase autobs

PERSONA: Son las personas que van a formar parte del modelo. Se dividirn en empleados o pasajeros. Cada persona tendr un nombre, una direccin, un DNI, un telfono y una edad. Necesitar disponer de los mtodos siguientes: Persona(string, string): persona es un constructor que toma el nombre y el DNI y devuelve una persona con esos datos.

La apariencia que tendr esta clase en el modelo corresponde a la Figura 4-4.

Figura 4-4. Clase persona

EMPLEADO: Son las personas que trabajan dentro de la compaa. De ellos se conocer el nmero de seguridad social (NSS) y su antigedad dentro de la empresa. Los mtodos asociados a esta clase son los siguientes: empleado(string, string, int): empleado es un constructor al que se le indica el nombre, el DNI y el NSS devuelve un empleado con esos datos. La Figura 4-5 se muestra la representacin grfica que tendr esta clase en el modelo.

Figura 4-5. Clase empleado

PASAJERO: Son las personas que viajan con la compaa. Estos quedarn registrados cuando hagan algn trayecto en alguno de los autobuses de la compaa. Para ello se conocer su cdigo de cliente, y los mtodos que necesitar esta clase para la gestin son los siguientes: pasajero(string, string): pasajero es el constructor, al que se le pasa el nombre y DNI y devuelve un pasajero.

hacerReserva(string, string, date): reserva hace la reserva para un pasajero. Ha de conocer el origen y el destino del trayecto y la fecha en la que se realizar y devuelve la reserva realizada. cancelarReserva(string, string, date): void cancela la reserva realizada previamente por un pasajero. Habr que indicarle el origen y el destino del trayecto y la fecha en la que se realizar.

aadirReserva(reserva): void se le aade una reserva al pasajero en su lista de reservas.

Grficamente, la representacin que tendr esta clase en el diagrama es la de la Figura 4-6.

Figura 4-6. Clase pasajero

RESERVA: Un pasajero deber hacer una reserva sobre el trayecto que desee para que pueda viajar en un autobs de la compaa. De cada reserva se conocer su precio y el nmero de asiento dentro del autobs. Tiene asociados los siguientes mtodos: reserva(): reserva Crea una nueva reserva. setTrayecto(trayecto): void Aade un nuevo trayecto a la base de datos para la reserva. setPasajero(pasajero): void Aade un nuevo pasajero a la base de datos para la reserva. En la Figura 4-7 se muestra la clase grficamente, como aparecer en el diagrama.

Figura 4-7. Clase reserva

Entre las entidades encontradas, se distingue dos relaciones de herencia, ya que las personas que participan en el modelo podrn ser empleados o pasajeros. De esta forma, pasajero y empleado heredan los atributos de persona. La relacin entre estas tres clases ser como la indicada en la Figura 4-8.

Figura 4-8. Relaciones de herencia en el diagrama

Adems, entre las clases que se han distinguido pueden apreciarse una serie de relaciones que se identifican con algunos de los patrones de colaboracin que nos ofrece la herramienta. Por lo que la inclusin de estas clases y relaciones al diagrama puede hacerse de una forma inmediata, arrastrando el patrn correspondiente e identificando las clases del patrn con las que ya estn representadas, en el caso de que lo estn, y completando posteriormente lo que falte. Se conoce que las compaas realizan trayectos, por lo que habr una relacin entre estas dos clases. La relacin ser de asociacin y una compaa podr ofrecer varios trayectos.

Esta relacin puede representarse mediante el patrn Item-SpecificItem, y la representacin en el diagrama ser similar a la indicada en la Figura 4-9.

Figura 4-9. Patrn Item-SpecificItem para la relacin entre compaa y trayecto

Por otro lado, cada compaa deber tener una serie de autobuses para poder proporcionar sus servicios, por lo que habr otra relacin entre estas dos clases. Tal relacin podr ser de composicin o de agregacin, mas se considerar de composicin puesto que la compaa dejara de tener sentido si no tuviera ningn autobs. Esta relacin, as descrita se asemeja al patrn Group-Member, donde el grupo sera la compaa y los miembros de esta seran los autobuses que posee. De esta forma, esta parte del modelo puede representarse en el diagrama con la insercin de este patrn, quedando como se indica en la Figura 4-10.

Figura 4-10. Patrn Group-Member para la relacin entre compaa y autobs

De forma paralela, habr una relacin similar entre compaa y empleado. Una compaa tendr contratados una serie de empleados para que realicen el trabajo que da la empresa. Igual que pasaba en el caso anterior, la compaa dejar de tener sentido si no hay ningn empleado trabajando para ella. De esta forma, la relacin existente entre estas dos clases ser otra vez de composicin y volver a repetirse el patrn que se utilizaba anteriormente, de Group-Member. Igual que antes, la compaa se identificar con el grupo, siendo esta vez cada uno de los empleados los miembros de este grupo.

La realizacin del diagrama de clases para esta parte, utilizando el patrn indicado tiene como resultado la Figura 4.11.

Figura 4-11. Patrn Group-Member para la relacin entre compaa y empleado

Otra relacin observada en este caso es la existente entre trayecto y reserva. Una reserva se har para un solo trayecto pero un trayecto incluir mltiples reservas. As puede identificarse una vez ms otro patrn de colaboracin, esta vez el SpecificItem-Transaction, siendo la clase del trayecto la correspondiente al SpecificItem y las reservas, cada una de las transacciones que se hacen sobre el anterior. La representacin grfica que se obtendra en el diagrama es la reflejada en la Figura 4-12.

Figura 4-12. Patrn SpecificItem-LineItem para la relacin entre trayecto y reserva.

Por otro lado, un pasajero podr hacer las reservas que desee en la compaa de autobuses, pero una reserva solo la podr hacer un nico pasajero, puesto que es para un nmero de asiento concreto. La relacin entre las clases pasajero y reserva, vista de esta forma, correspondera con el patrn Role-Transaction, donde el pasajero cumple el papel de Role y la reserva el de Transaction. Esta relacin dibujada en el modelo, con la utilizacin de este patrn tendra la apariencia que se refleja en la Figura 4-13.

Figura 4-13. Patrn Role-Transaction para la relacin entre pasajero y reserva.

Cabe comentar que para la utilizacin de los patrones en los casos anteriores se han representado en el diagrama, en primer lugar, cada una de las clases que se iban a relacionar, con sus respectivos atributos y mtodos, y despus se ha arrastrado el patrn correspondiente, sustituyendo en l las clases que ya estaban incluidas en el diagrama por las que se contemplaban en el patrn. De esta manera, no se han aadido nuevas clases con el patrn, pero s las relaciones. Por eso, debajo del nombre de las clases que se han sustituido, aparece su estereotipo, entre los signos << y >>. El nombre que se ve entre estos signos es el de la clase que est sustituyendo, dentro del patrn. Si una clase sustituye a otra perteneciente a un patrn en ms de una ocasin, el estereotipo que queda visible es el del ltimo patrn que fue aadido. Analizando en detalle el caso de estudio que nos ocupa, con sus clases y las conexiones que las unen, no se han encontrado mas relaciones afines a los patrones de colaboracin, no obstante, existen otros tipos de relaciones entre las clases. Una de estas relaciones es la existente entre compaa y pasajero. La compaa atender a todos los pasajeros que viajen a travs de ella. Esta ser una relacin de asociacin y su representacin se observa en la Figura 4- 14.

Figura 4-14. Relacin entre compaa y pasajero

Otra relacin en este caso es la existente entre trayecto y pasajero. Habr varios pasajeros que hagan un mismo trayecto, y de forma paralela, un pasajero podr hacer varios trayectos con la compaa. Una vez ms, se trata de una asociacin y, por lo tanto, la relacin que habr que representar es la indicada en la Figura 4-15.

Figura 4-15. Relacin entre trayecto y pasajero

Finalmente, la ltima relacin encontrada en el caso en estudio es la que hay entre autobs y trayecto. Los autobuses slo realizarn un trayecto y un trayecto solo lo realizar un autobs. Luego, la relacin que une estas clases ser de asociacin, como la reflejada en la Figura 4-16.

Figura 4-16. Relacin entre autobs y trayecto

Una vez consideradas todas las clases con sus atributos y mtodos, y las relaciones que pueden identificarse entre ellas, habr que unir cada una de estas partes para obtener el diagrama de clases completo, que corresponder con el caso de la empresa de autobuses que se est analizando. De esta manera, un posible modelo para el caso de la empresa de autobuses que se est estudiando, podra ser como el representado en la Figura 4-17.

Figura 4-17. Diagrama de clases del caso de estudio: empresa de autobuses

4.3 La generacin de cdigo

Una utilidad complementaria que ofrece la herramienta diseada en este proyecto final de carrera es la de generar cdigo java. Se ha decidido que el cdigo generado sea java por las mltiples caractersticas positivas que este ofrece. La principal es que se trata de un lenguaje portable, independiente de la plataforma en la que se ejecute. Adems, al tratarse de un lenguaje orientado a objetos, cada objeto puede verse como un paquete que contiene el comportamiento (el cdigo) y el estado (datos). Esta representacin hace que la transformacin del diagrama de clases a este lenguaje pueda hacerse de una forma muy simple. Como resultado quedar un cdigo claramente estructurado y muy fcil de leer.

Por otro lado, java es un lenguaje simple, fcil de aprender. Caracterstica esta muy importante si se tiene en cuenta que la herramienta va especialmente dirigida a estudiantes de ingeniera del software. Para que el usuario pueda generar el cdigo java correspondiente a su diagrama de clases, lo podr hacer a travs del men File > JAVA Code Generation o pulsando la combinacin de teclas ALT + J. Cuando esto suceda, el sistema abrir una ventana donde el usuario deber indicarle el directorio donde quiere que se genere el cdigo. Podr desplazarse por las carpetas de su equipo y escribir el nombre para el nuevo directorio. Obviamente, antes de generar el cdigo, tendr que estar dibujado el diagrama de clases en el panel correspondiente, en caso de que no hubiese nada representado, la generacin de cdigo tendr como resultado un directorio vaco. Dentro del directorio creado se generar un fichero .java por cada clase que haya en el diagrama de clases. El nombre del directorio ser el mismo que el de la clase que representa y su contenido depender de los atributos, mtodos y relaciones que tenga la clase. Este cdigo generado ser un esqueleto que el usuario podr completar en la medida de sus necesidades. Se ha generado el cdigo para el diagrama de clases de la Figura 4-17. Se le ha indicado al sistema que guarde el cdigo en el directorio /autobuses, dentro de Mis documentos. Y se han generado los ficheros mostrados en la Figura 4-18, dentro de este directorio.

Figura 4-18. Generacin de cdigo Java en el directorio autobuses.

A continuacin se mostrar el contenido de cada uno de esos ficheros, en las Figuras que van desde la 4-19 a la 4-25. El cdigo se ha abierto con la aplicacin JBuilder para que se vea ms claramente cada parte del cdigo, al distinguirse con colores.

Figura 4-19. autobs.java

Figura 4-20. compaa.java

Figura 4-21. empleado.java

Figura 4-22. pasajero.java

Figura 4-23. persona.java

Figura 4-24. reserva.java

Figura 4-25. trayecto.java

El cdigo, en cada uno de los ficheros, puede ser modificado y completado por el usuario, siendo en cada caso nicamente una base sobre la que programar cada clase a la que se refiere el fichero. En la generacin de cdigo para una clase determinada se ha obtenido un fichero con el mismo nombre que la clase, con extensin .java. Cada clase se ha considerado un objeto, de manera que el fichero tiene la descripcin del objeto correspondiente. En primer lugar se declaran los atributos del objeto, se establece el cuerpo del constructor de ese objeto y se declaran los mtodos que lleva asociados. Adems se tienen en cuenta las relaciones que tiene la clase para generar su cdigo. De esta manera, si la clase para la que se genera el cdigo es el origen de una asociacin, una agregacin o una composicin, se crear en ella un objeto del tipo de la clase destino de la relacin. Si una clase tiene una relacin de herencia con otra, en el cdigo de la clase origen se indicar que extiende de la clase destino. Puede darse el caso de que en el diagrama de clases una misma clase tenga relaciones de herencia con ms de una clase. En este caso, al generar el cdigo se mostrar un mensaje de Warning al usuario, puesto que Java no permite herencia mltiple. No obstante, en el cdigo generado se indicar que la clase extiende de todas las que es destino en las relaciones de herencia, aunque esto dara un error al compilar el cdigo, como ya se le ha indicado al usuario.

4.4 Las aportaciones desarrollado

educativas

del

producto

software

Desde el primer captulo de este documento se ha querido resaltar la importancia que supone el hecho de que el alumno adquiera habilidades y destrezas en lo que al desarrollo de diagramas de clases y modelado conceptual se refiere. Estas mismas actividades se ha corroborado en el segundo captulo que son capitales en el desarrollo de software y que progresivamente han ido adquiriendo cada vez ms importancia.

En este mismo sentido y volviendo a resaltar la importancia de las actividades mencionadas, en la actualidad, en el contexto educativo y en funcin de las nuevas metodologas de enseanza y aprendizaje, una serie de competencias se estn asociando a los diferentes ttulos universitarios ofrecidos por las universidades espaolas. Estas competencias pueden consultarse en los correspondientes Libros Blancos, disponibles en la pgina web de la Agencia Nacional de Evaluacin de la Calidad y Acreditacin (ANECA). En este proyecto final de carrera se han tenido tambin en cuenta las competencias mencionadas. En la Tabla 4-1 se recogen las competencias especficas del Ttulo de Grado de Ingeniera Informtica, para el perfil de desarrollo del software. Entre ellas cabe destacar algunas especialmente reseables y relacionadas con el proyecto final de carrera realizado y la herramienta elaborad y descrita, por ejemplo, y haciendo referencia a la correspondiente competencia a travs de su identificador numrico, 2, 11, 12, 13, 16 y 24. Competencias especficas recogidas en el Libro Blanco para el perfil de desarrollo del software
1. Dirigir y coordinar el proyecto de desarrollo y mantenimiento de aplicaciones, supervisando las funciones y recursos de anlisis funcional, orgnico y programacin, asegurando la adecuada explotacin de las aplicaciones. 2. Dominar todas las etapas de la vida de un proyecto (anlisis de concepcin, anlisis tcnico, programacin, pruebas, documentacin y formacin de usuarios). 3. Dirigir el equipo de trabajo compuesto por Analistas Funcionales, Analistas de aplicaciones, Programadores. 4. Control y seguimiento de plazos, indicadores econmicos y de calidad. 5. Supervisar y coordinar el desarrollo completo de aplicaciones y administrar la introduccin de los sistemas de gestin. 6. Controlar las aplicaciones en explotacin, minimizando las consecuencias negativas sobre las operaciones en produccin y desarrollo de aplicaciones. 7. Analizar y recoger nuevas tcnicas y herramientas del mercado estudiando su viabilidad y necesidad. 8. Posibilidad de contratar recursos externos. 9. Control y Gestin del Desarrollo del Proyecto Informtico. 10. Redaccin, para la Direccin de Informtica y para la Direccin del Proyecto de los informes que se precisan para el seguimiento del proyecto.

11. Interpretar las especificaciones funcionales encaminadas al desarrollo de las aplicaciones informticas. 12. Realizar el anlisis y el diseo detallado de las aplicaciones informticas. 13. Definir la estructura modular y de datos para llevar a cabo las aplicaciones informticas que cumplan con las especificaciones funcionales y restricciones del lenguaje de programacin. 14. Definicin y descripcin de procedimientos e interfaz de usuario. 15. Realizar pruebas que verifiquen la validez funcional, la integridad de los datos y el rendimiento de las aplicaciones informticas. 16. Elaborar y mantener documentacin descriptiva de la gnesis, produccin y operatividad de las aplicaciones informticas. 17. Disear servicios de presentacin que faciliten la explotacin de las aplicaciones. 18. Estudiar el sistema actual existente y analizar e idear mejores medios para llevar a cabo los mismos objetivos u otros adicionales. 19. Participar en el diseo de nuevos sistemas informticos como consecuencia de la informatizacin de reas de la empresa que utilizan para el desarrollo de sus tareas mtodos y procesos manuales. 20. Integrar sistemas informticos existentes susceptibles de inter-relacionarse. 21. Escuchar y asesorar a los Usuarios en la resolucin de los problemas que se les plantean con el uso de los sistemas informticos. 22. Asesorar a los programadores en los problemas que se les plantean con la programacin de los sistemas. 23. Colaborar con los responsables de Estudios y Explotacin en la resolucin de los fallos que se originen en los Sistemas en Produccin. 24. Mantenerse al da en Tcnicas, Mtodos y Herramientas de Anlisis y Diseo.
Tabla 4-1. Competencias especficas del ttulo de grado en Ingeniera Informtica perfil Desarrollo del Software

En definitiva, en este proyecto final de carrera se ha contribuido a la elaboracin de una herramienta que posibilite la utilizacin de una experiencia til en la elaboracin de especificaciones conceptuales, como es la disponible a travs de los patrones de colaboracin, y, gracias al entorno facilitado, el ingeniero del software en formacin puede realizar labores de anlisis y diseo de soluciones software reutilizando dicha experiencia.

4.5 Anlisis y discusin

Con el ejemplo utilizado en este captulo se ha pretendido demostrar de forma prctica la potencialidad de la herramienta desarrollada en este proyecto final de carrera y contribuir a presentar cmo se utiliza. Un estudio ms detallado de las facilidades que ofrece podra realizarse a travs de la consideracin de su uso en distintas asignaturas disponibles en el actual plan de estudios de la Escuela Superior de Ingeniera Informtica. Estas asignaturas pueden ser las correspondientes a los primeros cursos de las actuales titulaciones de Ingeniera Informtica, Ingeniera Tcnica de Sistemas y de Gestin, concretamente aquellas asignaturas en las que al alumnado se les presenten conceptos relacionados con programacin orientado a objetos. Cola-CASE facilita un entorno muy intuitivo y flexible en el que los patrones estn disponibles en una carpeta que acompaa al ejecutable facilitado. El usuario puede definir sus propios patrones e incluirlos en la carpeta mencionada. Tambin distintos usuarios pueden compartir sus patrones propios sin ms que a travs de facilitar la carpeta o ficheros asociados a los patrones mencionados. En este ltimo sentido, cola-CASE puede albergar otros tipos de patrones y no se restringe a utilizar patrones de colaboracin. Es posible tambin incorporar el catlogo de patrones ms conocido y utilizado como es el catlogo de patrones de diseo de (Gamma et al., 1995).

Captulo 5. Conclusiones y Trabajo Futuro

Este captulo tiene como nico cometido recoger las conclusiones que pueden obtenerse tras la realizacin del presente proyecto final de carrera y proponer unas pautas para futuras investigaciones que tomen como base este proyecto.

5.1 Conclusiones
Se hace patente la necesidad de una metodologa que pueda utilizar todo el equipo de trabajo y que puedan seguir como gua y ayude a comprobar la calidad del producto final. Esta idea podra ayudar a paliar la continua crisis que sufre el desarrollo de software. El desarrollo dirigido por modelos separa la funcionalidad esencial del sistema y la implementacin de dicha funcionalidad, dndole una mayor importancia al modelado conceptual en el desarrollo de software. Este paradigma promete una mejora de la productividad y de la calidad del software. Por lo tanto, el anlisis de los requisitos es la etapa ms crucial del desarrollo de un proyecto de software, debiendo especificar estos requisitos de alguna manera. Para ello, la elaboracin de modelos resulta de gran utilidad puesto que de un vistazo ms o menos simple se puede comprender fcilmente la funcionalidad del sistema que se va a desarrollar. Se han estudiado las principales herramientas CASE y se ha observado que pocas de ellas consideran la experiencia en sus proyectos, y las que lo hacen nicamente contemplan los patrones de diseo. Se ha comprobado la necesidad de aportar experiencia a los proyectos, pudiendo ir ms all de la propia del desarrollador, utilizando para ello los patrones de colaboracin, disponibles en el mbito del modelado conceptual. Estos patrones estn sobradamente probados y son una slida base para la bsqueda de soluciones a problemas comunes en el desarrollo de aplicaciones.

Con la herramienta Cola-CASE se obtiene una alternativa a las potentes herramientas CASE disponibles, donde se permite el modelado del dominio de una forma simple e intuitiva, con la posibilidad de aadir a este los patrones de colaboracin que sean necesarios, disponibles en el repositorio facilitado. Y con la posibilidad de modificar o aadir nuevos patrones. El entorno desarrollado permite centrarse en el anlisis y el diseo ms que en la implementacin. Toma como base la experiencia proporcionada por Nicola, Mayfield, y Abney en su libro (Nicola et al., 2001), con sus patrones ya definidos y documentados y sirve de sustento para su utilizacin en los modelos del negocio. Adems, desde el primer momento se ha tenido en mente que esta herramienta estuviera destinada para el uso de estudiantes de ingeniera del software, por lo que la sencillez de esta se ha hecho patente desde el principio. Con lo que conlleva su fcil utilizacin.

5.2 Trabajo Futuro

Con la herramienta desarrollada, se pretende abrir paso a otras herramientas que faciliten la utilizacin de patrones en el modelado, para que el usuario pueda disponer de las estructuras asociadas con cada patrn sin tener que realizar el diseo desde cero de cada uno de los patrones. Esta es una primera versin de la herramienta, por lo que puede mejorarse en algunos aspectos. Por un lado, podran hacerse una mejora en cuanto a la usabilidad, haciendo para ello ms flexibles las asociaciones y mejorarse el aspecto de la interfaz y de los diagramas, para que resultara ms atractivo al usuario, al igual que podra incluirse un pequeo grfico de cada patrn antes de ser arrastrado, para que el usuario pudiera recordar su apariencia antes de utilizarlo. Tambin podra aadrsele funcionalidad, por ejemplo, posibilitando la realizacin de otro tipo de diagramas, adems de los de clases, y generando cdigo en otro tipo de lenguajes, adems de Java. Por otro lado, podra aadir el uso de otro tipo de patrones, como los de (Gamma et al., 1995), que se utilizan para un diseo detallado.

Bibliografa

(Nicola et al., 2001)

Nicola, J., Mayfield, M., Abney M. Streamlined Object Modeling. Patterns, Rules, and Implementation. The Coad Series. Prentice Hall, 2001. (Coad et al., 1997) Coad, P., North, D., Mayfield, M. Object Models. Strategies, Patterns & Applications. Yourdon Press Computing Series, 1997. (Buschmann et al., Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, 1996) M. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996. (Gamma et al., 1995) Gamma, E., Helm, R., Johnson, R., Vissides, J. Design Pattern: Elements of Reusable Object-Oriented Software. Addison Wesley. 1995. (Fowler, 2002) Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002. (Alexander, 1977) Alexander, Christopher. A Pattern Language: Towns, Buildings, Construction. 1977 (Alexander, 1979) Alexander, Christopher. The Timeless Way of Building. 1979 (Coplien, 1991) James O. Coplien. Advanced C++ Programming Styles and Idioms. Addison Wesley Professional. 1991. (Coplien & Schmidt, James O. Coplien y Douglas C. Schmidt, Pattern Languages of 1995) Program Design (A Generative Development-Process Pattern Language). Reading, Addison Wesley, 1995. (Brown et al., 1998) Brown, W. J., Malveau, R. C., Mowbray, T. J. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, 1998. (Akroyd, 1996) Akroyd, M. AntiPatterns: Vaccinations against Object Misuse. Object World West, 1996. (Jacobson et al., 2000) Jacobson, I., Booch, G. y Rumbaugh, J. El Proceso Unificado de Desarrollo de Software. Addison-Wesley, 2000. (Durn & Bernrdez, Durn, A., Bernrdez, B. Metodologa para la Elicitacin de 2002) Requisitos de Sistemas Software. Sevilla, 2002. (artculo) (Pressman, R., 2007) Pressman, R. Ingeniera del Software: Un Enfoque Prctico. McGraw-Hill, 2007.

(UML, 2007)

Lenguaje Unificado de Modelado. http://www.omg.org http://www.uml.org http://martinfowler.com/ Metodologas giles en el Desarrollo de Software. http://www.willydev.net/descargas/prev/TodoAgil.Pdf Programacin extrema. http://www.extremeprogramming.org

Programacin extrema. http://www.xprogramming.com HyperModel. http://www.xmlmodeling.com Christopher Alexander: An Introduction for Object-Oriented Designers. http://gee.cs.oswego.edu/dl/ca/ca/ca.html Patrones de Alexander. http://www.patternlanguage.com Pgina web de UsiXML: http://www.usixml.org Pgina de XML: http://www.w3.org/XML/

Apndice A

Patrones de Colaboracin

Use to model the participation of a person, organization, place, or thing in a context. An actor knows about zero to many roles, but typically takes on only one of each kind. A role represents a unique view of its actor within a context. The role depends on its actor and cannot exist without it.

Use to model a hierarchy of locations where events happen. An outer place is the container for zero or more places. A place knows at most one outer place. The places location depends on the location of its outer place.

Use to model a thing that exists in several distinct variations. An item is the common description for zero to many specific items. A specific item knows and depends on one item. The specific items property values distinguish it from other specific items described by the same item.

Use to model an ensemble of things. An assembly has one or more parts. Its parts determine its properties, and the assembly cannot exist without them. A part belongs to at most one assembly at a time. The part can exist on its own.

Use to model a receptacle for things. A container holds zero or more content objects. Unlike an assembly, it can be empty. A content object can be in at most one container at a time. The content object can exist on its own.

Use to model a classification of things. A group contains zero or more members. Groups are used to classify objects. A member, unlike a part or content objects, can belong to more than one group.

Use to record participants in events. A transaction knows one role, the doer of its interaction. A role knows about zero or more transactions. The role provides a contextual description of the person, organization, thing, or place involved in the transaction.

Use to record where an event happens. A transaction occurs at one place. A place knows about zero to many transactions. The transactions record the history of interactions at the place.

Use to record an event involving a single thing. A transaction knows about one specific item. A specific item can be involved in zero to many transactions. The transactions record the specific items history of interactions.

Use to record an event involving more than one thing. A composite transaction must contain at least one line item. A line item knows only one composite transaction. The line item depends on the composite transaction and cannot exist without it.

Use to record the particular involvement of a thing in an event involving multiple things. A specific item can be involved in zero to many line items. A line item knows exactly one specific item. The line item captures details about the specific items interaction with a composite transaction.

Use to record an event that occurs only after a previous event. A transaction knows about some number of follow-up transactions. A follow-up transaction follows and depends on exactly one previous transaction.