Embed Size (px)
Citation preview
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INGENIERÍA
INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
COLA-CASE: POTENCIANDO EL MODELADO CONCEPTUAL CON PATRONES
DE COLABORACIÓN
FELICIDAD PADILLA LÓPEZ
JUNIO, 2008
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INGENIERÍA
INFORMÁTICA
INGENIERÍA
EN INFORMÁTICA
PROYECTO FIN DE CARRERA
COLA-CASE: POTENCIANDO EL MODELADO CONCEPTUAL CON PATRONES
DE COLABORACIÓN
AUTORA: FELICIDAD PADILLA LÓPEZ
DIRECTOR: FRANCISCO MONTERO SIMARRO
JUNIO, 2008
RESUMEN
Dentro del proceso de desarrollo de software, con el tiempo, se han demostrado cada
vez más importantes las primeras fases del desarrollo del mismo. Concretamente, con el
tiempo las labores de programación dejaron paso a las de diseño y, aún así, fruto de síntomas
claros de una aparentemente dolencia crónica denominada crisis del software se recurrió a
potenciar las fases de ingeniería de requisitos. De una u otra manera, son en estas fases en las
que se llevan a cabo labores de ingeniería de sistemas y de información, la planificación del
proyecto, la ingeniería de requisitos y el modelado de sistemas a diferentes niveles de
abstracción de una forma cada vez más sistemática.
Posteriormente, en el resto de fases que caracterizan el proceso de desarrollo se
llevarán a cabo el diseño del software, la generación de código, las pruebas de software en la
fase de desarrollo, y los cambios necesarios de corrección, de adaptación, de mejora y de
prevención 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 iníciales.
En las fases de análisis de los requisitos y el proceso de diseño, 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
análisis de requisitos como en el diseño. 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 producción de software.
En este sentido, un concepto, el de patrón, se ha demostrado útil para abordar tareas
de diseño, ejemplo revelador lo constituyen los patrones de diseño (Gamma et al., 1994), que
aportan conocimiento útil para poner en práctica muchas de las facilidades que permiten el
paradigma orientado a objetos. En lo que respecta al modelado conceptual existe también
experiencia en ese contexto concreto, son los patrones de colaboración (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 colaboración y se ha trabajado en el
desarrollo de un entorno, Cola-CASE, que permite el uso reiterado y sistemático 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
Capítulo 1 . Introducción ....................................................................................................... 1
1.1 Especificación e implementación de software ........................................................ 1
1.2 Motivación y justificación ....................................................................................... 4
1.3 Objetivos ................................................................................................................. 4
1.4 Estructura del documento ........................................................................................ 6
Capítulo 2 . La importancia creciente de la especificación frente a la implementación ........ 9
2.1 Evolución histórica 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 análisis de requisitos .......................................................... 19
2.2.2 Metodologías 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 programación y de diseño .......................................... 31
2.3.1 Lenguajes de programación ........................................................................... 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 utilización 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 colaboración ........................................................................ 45
2.6.4 Formatos de los patrones disponibles ............................................................ 49
2.7 Análisis y conclusiones ......................................................................................... 50
Capítulo 3 . Integración de los patrones de colaboración en el proceso de desarrollo ........ 53
3.1 Introducción .......................................................................................................... 53
3.2 Documentación y especificación de la aplicación 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 Descripción y almacenamiento de los patrones de colaboración en XML ........... 81
3.4 Descripción del entorno elaborado ........................................................................ 83
3.5 Análisis y discusión ............................................................................................. 105
Capítulo 4 . Caso de estudio: utilización del entorno facilitado ........................................ 107
4.1 Descripción del caso de estudio .......................................................................... 107
4.2 La especificación gráfica ..................................................................................... 109
4.3 La generación de código ..................................................................................... 119
4.4 Las aportaciones educativas del producto software desarrollado ....................... 125
4.5 Análisis y discusión ............................................................................................. 128
Capítulo 5 . Conclusiones y Trabajo Futuro ...................................................................... 129
5.1 Conclusiones ....................................................................................................... 129
5.2 Trabajo Futuro ..................................................................................................... 130
Bibliografía ........................................................................................................................ 131
Apéndice A ........................................................................................................................ 133
Patrones de Colaboración .............................................................................................. 133
ÍNDICE DE FIGURAS
Figura 2-1. Capas en la Ingeniería del Software .................................................................. 12
Figura 2-2. Los problemas de comunicación 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 operación de una fase ....................................................... 18
Figura 2-5. La metodología es lo que posibilita la asociación entre una solución y un
problema .............................................................................................................................. 21
Figura 2-6. Metodologías de desarrollo ............................................................................... 23
Figura 2-7. Perfil de Proyecto Típico .................................................................................. 29
Figura 2-8. Fases e iteraciones en la metodología RUP ...................................................... 31
Figura 2-9. Patrones de colaboración (Nicola et al., 2001) ................................................. 47
Figura 3-1. Esquema básico 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 elaboración de un diagrama de clases ........... 58
Figura 3-4. Diagrama de paquetes ....................................................................................... 73
Figura 3-5. Diagrama de clases de la aplicación ................................................................. 75
Figura 3-6. Diagrama de secuencia para insertar patrón sustituyendo clases ...................... 79
Figura 3-7. Diagrama de secuencia para insertar patrón sin sustituir clases ....................... 80
Figura 3-8. Modelo de dominio de clases ............................................................................ 82
Figura 3-9. Patrón Actor-Role ............................................................................................. 83
Figura 3-10. Interfaz de la aplicación .................................................................................. 84
Figura 3-11. Partes de una clase .......................................................................................... 87
Figura 3-12. Características 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 confirmación 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 método .............................................................................. 91
Figura 3-19. Menú de acciones para un método .................................................................. 92
Figura 3-20. Menú de acciones para una clase .................................................................... 93
Figura 3-21. Menú de acciones para una relación ............................................................... 94
Figura 3-22. Tablas de las propiedades para cada uno de los tipos de relaciones posibles . 95
Figura 3-23. Mensaje de confirmación para eliminar una relación ..................................... 95
Figura 3-24. Utilizar patrón ................................................................................................. 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 código del diagrama de clases ............................... 101
Figura 3-28. Ventana para guardar la imagen del diagrama de clases .............................. 102
Figura 3-29. Código 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 aplicación ....................................................................... 105
Figura 4-1. Clase compañía ............................................................................................... 110
Figura 4-2. Clase trayecto .................................................................................................. 111
Figura 4-3. Clase autobús .................................................................................................. 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. Patrón “Item-SpecificItem” para la relación entre compañía y trayecto ........ 115
Figura 4-10. Patrón “Group-Member” para la relación entre compañía y autobús .......... 115
Figura 4-11. Patrón “Group-Member” para la relación entre compañía y empleado ........ 116
Figura 4-12. Patrón “SpecificItem-LineItem” para la relación entre trayecto y reserva... 116
Figura 4-13. Patrón “Role-Transaction” para la relación entre pasajero y reserva. ......... 117
Figura 4-14. Relación entre compañía y pasajero ............................................................. 117
Figura 4-15. Relación entre trayecto y pasajero ............................................................... 118
Figura 4-16. Relación entre autobús y trayecto ................................................................. 118
Figura 4-17. Diagrama de clases del caso de estudio: empresa de autobuses ................... 119
Figura 4-18. Generación de código Java en el directorio autobuses. ................................ 121
Figura 4-19. autobús.java ................................................................................................... 121
Figura 4-20. compañía.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 metodologías 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 patrón según Christopher Alexander .......................................... 49
Tabla 3-1. Caso de uso “Añadir 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 “Añadir Relación” .......................................................................... 64
Tabla 3-6. Caso de uso “Eliminar Relación” ....................................................................... 64
Tabla 3-7. Caso de uso “Consultar Relación” ..................................................................... 65
Tabla 3-8. Caso de uso “Modificar Relación” ..................................................................... 66
Tabla 3-9. Caso de uso “Utilizar Patrón” ............................................................................ 67
Tabla 3-10. Caso de uso “Añadir Patrón” ............................................................................ 68
Tabla 3-11. Caso de uso “Eliminar Patrón” ......................................................................... 68
Tabla 3-12. Caso de uso “Modificar Patrón” ....................................................................... 69
Tabla 3-13. Actor-Role.usi .................................................................................................. 83
Tabla 3-14. Iconos de la barra de herramientas del panel ................................................... 85
Capítulo 1. Introducción
1.1 Especificación e implementación 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 evolución histórica que
ha sufrido el proceso de desarrollo del software. En el año 1968 se habló por primera vez de
crisis del software, y se acuñó este término; desde entonces y hasta nuestros días se buscan
soluciones para intentar solventar este problema que acompaña 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 código de difícil 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. Además, 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, cuánto tiempo llevará desarrollar un
programa ni cuánto personal hará falta.
La ingeniería del software, para tratar de facilitar el proceso de desarrollo del software,
realiza diagramas que describen la forma de cómo hacer las cosas, lo que ha ocasionado que
surjan distintas metodologías de Análisis y Diseño Orientadas a Objetos y herramientas CASE
para facilitar la utilización y documentación de estos diagramas o modelos. A mediados de los
ochenta, ya existía una gran variedad de estos métodos, lo que suponía que los mismos
conceptos de un diagrama tenían distinta notación según el método del que se tratara,
provocando esto una situación de confusión y un problema de estandarización.
Para mitigar la situación de confusión ante los distintos métodos existentes para el
análisis y diseño de los requisitos surge el Unified Modeling Language o Lenguaje Unificado
de Modelado (UML), que es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad, además de estar respaldado por el OMG. Es un lenguaje gráfico para
visualizar, especificar, construir y documentar un sistema de software, desde una perspectiva
orientada a objetos. UML ofrece un estándar 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 programación, 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 metodología de desarrollo de software, tal como el
RUP, pero no especifica en sí mismo qué metodología o proceso usar.
A medida que UML va sacando nuevas versiones, incluye nuevos diagramas para
poder representar el modelo en función de las necesidades de cada uno. No obstante, para
realizar un modelado en el análisis del entorno que sea de utilidad para la posterior
implementación y demás fases del desarrollo, se ha considerado especialmente interesante los
diagramas de clases y la especificación conceptual. Este tipo de diagrama permite visualizar las
relaciones entre las clases que involucran el sistema, y a través de las clases modelar el entorno
en estudio, describiendo la estructura del sistema. De esta manera, una clase será la unidad
básica que encapsule toda la información de un objeto, sus atributos representarán alguna
propiedad de la clase y sus métodos las funciones o transformaciones que se apliquen a todos
los objetos de una clase particular.
Por otro lado, la orientación a objetos, que puede describirse como el conjunto de
disciplinas que desarrollan y modelan software, facilita la construcción de sistemas complejos a
partir de componentes (objetos). Siguiendo este principio, surge la Programación Orientada a
Objetos (POO), que aumenta considerablemente la velocidad de desarrollo de los programas
gracias a la reutilización de los objetos.
Puede encontrarse una estrecha relación entre las clases del modelado conceptual de
UML con los objetos de la POO. En este sentido, sería más 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 metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos. RUP no es un sistema con pasos firmemente
establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada
organización.
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 ingeniería del software, cuya
evolución histórica 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 más 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,
análisis y definición de las necesidades de los clientes y las características del sistema, realizadas
en las primeras fases del desarrollo, cobren más importancia que el mero hecho de la
implementación.
Debido a la complejidad que supone todo el proceso de desarrollo, y en especial las
fases de análisis y diseño, se considera imprescindible la aplicación 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 situación. Una
posible definición de patrón 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 prácticas.
Según el arquitecto Christopher Alexander, “cada patrón describe un problema que
ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que
podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla
otra vez.” El uso de patrones es beneficioso en la mayoría 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
patrón adaptable que permita expandir el programa mas adelante facilitará las cosas en el
momento de cambiar o quitar partes del proyecto.
Más concretamente, en este proyecto se plantea el uso de patrones de colaboración.
Estos patrones son la representación de personas, lugares, cosas y eventos; ilustrando de
forma gráfica concisa y no ambigua la interacción 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 añadir la experiencia existente en el desarrollo de
software a este modelado.
1.2 Motivación y justificación
La motivación que lleva a la realización de este proyecto es la falta de consideración
observada de la experiencia relacionada con el modelado conceptual y disponible en
diversos documentos disponibles, así como de un entorno de diseño para ese mismo
modelado conceptual, que permita recoger el conocimiento específico acumulado por
la experiencia, en forma de patrones de colaboración, y la opción de poder disponer de estos
patrones sistemáticamente en nuestros análisis y diseños.
1.3 Objetivos
Los principales objetivos investigados en este proyecto final de carrera son los
siguientes:
Justificación documentada de la importancia del modelado conceptual e identificación
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 tecnología hardware frente a la lenta
evolución del software.
Conocer y profundizar en el Desarrollo de Software Dirigido por Modelos (DSDM) y
más concretamente la propuesta MDA (Model Driven Architecture) de OMG, que
constituyen una aproximación para el desarrollo de sistemas software, basada en la
separación entre la especificación de la funcionalidad esencial del sistema y la
implementación de dicha funcionalidad usando plataformas de implementación
específicas.
Corroborar la necesidad de una metodología en el desarrollo de software que ofrezca
un marco y un vocabulario común para el equipo de trabajo que sirva de guía y ayude a
comprobar la calidad del producto final y al seguimiento de los proyectos.
Complementar UML (Lenguaje de Modelado Unificado), que es el estándar que se
utiliza para el análisis y el diseño 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 consideración 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
sistemática desde una herramienta CASE.
Contemplar la posibilidad de documentar los patrones de colaboración utilizando un
lenguaje basado en XML.
Ofrecer un entorno que permita utilizar, gestionar y aprovechar la experiencia
disponible en forma de patrones de colaboración.
1.4 Estructura del documento
La memoria asociada a este proyecto se compone de los cinco capítulos en los que se
ha dividido el documento.
En el capítulo 1, el cual nos ocupa, se hace una introducción a lo que se verá más
adelante. En primer lugar se hace un preámbulo muy general a lo que es la especificación e
implementación del software, seguido de la motivación que ha llevado a la elaboración del
presente proyecto y los objetivos que se tendrán en cuenta para su desarrollo.
En el capítulo 2 se discute la creciente importancia de la especificación frente a la
implementación. Se hace un repaso histórico de las tendencias que ha seguido el desarrollo de
software, ante la búsqueda de software de calidad, desde las metodologías tradicionales hasta la
programación estructurada, con la creciente tendencia actual de la arquitectura dirigida por
modelos, utilizando para ello UML y programación orientada a objetos. Se presentan los
patrones de colaboración 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
diseño, en ningún caso se ofrece la posibilidad de introducir la experiencia que los patrones de
colaboración aportan en el uso de estas herramientas, a pesar de las ventajas que esto
supondría en el diseño.
En el capítulo 3 se describe cómo los patrones de colaboración pueden integrarse en el
proceso de desarrollo, mediante la herramienta que se presenta. Se hace un análisis de los
requisitos necesarios para abordar el desarrollo de dicha herramienta, un diseño y una
implementación de ésta, conjuntamente con la descripción del entorno. Además, se describe
cómo se han documentado los patrones de colaboración de Nicola et al. para poder ser
utilizados de forma sistemática por el entorno facilitado.
En el capítulo 4 se hace una presentación dinámica de la herramienta desarrollada,
describiendo su funcionalidad, con la ayuda de algún ejemplo, y las aportaciones que ésta
puede ofrecer a nivel educativo.
En el capítulo 5 se recogen las conclusiones obtenidas tras la elaboración del presente
proyecto, y se proponen posibles trabajos futuros en este sentido. Se resalta, una vez más, 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 inclusión de los patrones de
colaboración en el modelado del dominio nos han proporcionado tras el desarrollo de la
herramienta propuesta.
Capítulo 2. La importancia creciente de la especificación frente a la implementación
En este capítulo se estudiará la evolución histórica 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 empírico, por la
experiencia de la que haga gala el analista o diseñador del software. En este sentido, en este
proyecto final de carrera se apuesta por complementar la experiencia del diseñador con
experiencia disponible y documentada en forma de patrones. Concretamente, los patrones de
colaboración (Nicola et al., 2001) se identifican como una herramienta útil y perfectamente
aprovechable de una forma mucho más sistemática.
2.1 Evolución histórica 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 adaptándose a estos cambios.
En los primeros desarrollos de software, el ingeniero solamente necesitaba conocer un
modelo de ciclo de vida del software, manejar una tecnología y ser capaz de construir una
aplicación para resolver un problema. Actualmente, el ingeniero del software debe poder
integrarse en grandes equipos de desarrollo, debe tener una visión amplia de las tecnologías
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 desempeño del desarrollo, han ido
apareciendo diversas propuestas que han tenido mayor o menor éxito, según el modelo
elegido y el área de aplicación: prueba y error, cascada, prototipos evolutivos, espiral, entrega
por etapas... Esta diversidad expresa una respuesta lógica 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 evolución de la disciplina de ingeniería de software ha traído consigo propuestas
diferentes para mejorar los resultados del proceso de construcción.
Una posible definición de ingeniería 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 años son las
siguientes (Pressman, R., 2007):
Bauer, 1972: “La Ingeniería del Software trata del establecimiento de los principios y métodos de la
ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales”.
Bohem, 1976: “Ingeniería del Software es la aplicación práctica del conocimiento científico en el
diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar,
operar y mantenerlos. Se conoce también como desarrollo de software o producción de software.”
Zelkovitz, 1978: “Ingeniería del Software es el estudio de los principios y metodologías para
desarrollo y mantenimiento de sistemas de software.”
Mills, 1980: “La Ingeniería del Software tiene como uno de sus principales objetivos la producción de
programas que cumplan las especificaciones, y que se demuestren correctos, producidos en el plazo y coste
adecuados.”
Meyer, 1988: “La Ingeniería del Software es la producción de software de calidad.”
Ford, 1990: “Ingeniería de Software es una forma de ingeniería que aplica los principios de la ciencia
de los computadores y matemáticas para conseguir soluciones a los problemas del software de forma efectiva y
económica.”
IEEE, 1993: “Ingeniería de software es la aplicación de un método sistemático, disciplinado y
cuantificable al desarrollo, operación y mantenimiento de software.”
Sommerville, 2001: “Es una disciplina que comprende todos los aspectos de la producción de
software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que
se utiliza.”
La ingeniería del software se puede ver como la composición de cuatro partes:
Procesos de software y garantía de calidad: Los procesos de software comprenden
el conjunto de actividades, tanto técnicas como administrativas, que son necesarias
para la fabricación de un sistema de software. Estas actividades son el análisis de los
requisitos, la implantación, la administración de configuraciones, las pruebas, la
evolución 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 más alta.
Arquitecturas de software y elementos estructurados: A partir de la selección de
los elementos que van a definir la estructura de una aplicación, hay que definir el
proceso de construcción, la metodología, la tecnología y las herramientas. En las
décadas de los 60 y 70 era natural estructurar una aplicación en términos de los
servicios funcionales que ésta debía proveer. De hecho, las metodologías como el
análisis y diseño estructurado partían de una descomposición funcional jerárquica que
luego se transformaba en procedimientos dentro de la aplicación. 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 construcción de aplicaciones
más fáciles 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 más independientes posibles de las herramientas que se
utilicen.
Tecnologías de información: 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 programación, y a las plataformas para la construcción de algún tipo de
componente software. Esta es la dimensión de la ingeniería de software que más
rápido cambia. Es la evolución de la tecnología lo que ha hecho que las expectativas
con respecto al software cambien y sean más exigentes. A medida que los requisitos no
funcionales han ido tomando importancia, la integración de la tecnología se debe hacer
desde las primeras etapas de diseño, y obliga al ingeniero de software a ampliar su
dominio de competencias.
Metodologías y técnicas de desarrollo: Dan soporte a las actividades de análisis,
diseño, programación, elaboración de pruebas, administración 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 interés es el de los patrones
de diseño, que son soluciones probadas a problemas particulares en contextos
específicos. Si bien no son metodologías completas, son elementos claves que
permiten, por un lado, manejar un vocabulario común entre los diseñadores y, además,
ofrecen elementos objetivos para justificar una decisión.
Figura 2-1. Capas en la Ingeniería del Software
La Figura 2.1 muestra un esquema con las capas que intervienen en la ingeniería del
software, donde cada una de estas capas afecta al resto. De esta manera, los métodos indican
cómo construir el software, las herramientas suministran un soporte automático para los
métodos y los procedimientos son lo que une los métodos y las herramientas. Todo esto sin
olvidar que el principal objetivo en la ingeniería del software es producir software de calidad,
por lo que se aplicará la garantía de calidad del software a todo el proceso de desarrollo.
2.1.1 La crisis del software
Tradicionalmente, la Ingeniería del Software adolece de una enfermedad crónica
conocida como “crisis del software”. Éste término 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 surgían 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 además excede los presupuestos y
los horarios de tiempos.
Actualmente, las aplicaciones típicas son muy grandes y complejas para que un
individuo las entienda y, por ello, lleva gran tiempo implementar software. El término “crisis
del software” fue usado, desde los primeros días de la ingeniería del software, para referirse a
los rápidos incrementos de la tecnología en la computación y la complejidad de los problemas
a los cuales pudieran enfrentarse.
Uno de los principales problemas en el desarrollo de software de hoy en día es que
muchos proyectos empiezan la programación tan pronto se definen y concentran mucho de su
esfuerzo en la escritura de código. No se debe de olvidar que la programación 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 común que son causadas por el método de valorar
los avances científicos y el mecanismo actual de financiación de la actividad científica. 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 ingeniería de software como una profesión.
Algunos “síntomas” 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
reducción del costo del hardware, la rápida obsolescencia de hardware y software, la creciente
aceptación de la computarización en las empresas, el incremento en el número de usuarios de
los sistemas de software, la existencia de un tipo de usuario no homogéneo en sistemas hechos
a la medida y el diferente personal de desarrollado y mantenimiento.
Factores también importantes son los cambios tecnológicos (Internet, redes, ERP o
Enterprise Resource Planning, CRM o Customer Relationship Management, SCM o Supply Chain
Management), económicos (crisis económicas, globalización, etc.) y sociales (nuevas
necesidades, nuevas costumbres, etc.) que se producen en el entorno.
Debido a la falta de comunicación 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 difícil que lleguen a un acuerdo. Un ejemplo gráfico 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 comunicación y el desarrollo del software
Esta falta de entendimiento entre unos y otros podría solucionarse sustancialmente si
al principio del desarrollo se lleva a cabo una especificación exhaustiva de los requisitos que se
esperan de la herramienta. También es interesante que la especificación se complete con un
modelado donde se plasmen gráficamente estos requisitos, con lo que se añadirá una
semántica más difícil de explicar mediante texto y que permitirá asimilar de un vistazo las
condiciones de interés del proyecto, incluyendo toda la información que ha de manejar el
sistema.
Es mas, si el modelo refleja la forma en que las actividades del proyecto influirán sobre
la condición de interés, entonces la implementación del proyecto conducirá a los resultados
deseados. Por otro lado, cualquier cambio relativo a requisitos u otras fuentes de información
se podrá afrontar de manera más eficaz, haciendo más cómodo el mantenimiento.
Este mal endémico que sufre la industria del software desde sus orígenes no parece
tener una solución definitiva hasta ahora, aunque ha habido muchas iniciativas para atenuar los
efectos de esta crisis. Una de las más importantes es la aplicación de sistemas de
aseguramientos de calidad al desarrollo de software, los que se basan sobre las siguientes ideas:
El software debe ser pensado, diseñado y desarrollo como un producto sujeto a
normas de calidad.
El software es un producto desarrollado por grupos de personas cuya interacción debe
ser gestionada.
El énfasis en el proceso de desarrollo asegura un producto adecuado a los requisitos de
los clientes.
La solución 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 más fundamentos y adherentes; la crisis del
software puede ser reducida a través de la educación, es decir educando adecuadamente la
próxima generación 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 planificación,
realización, medición, seguimiento y mejora continua mediante la incorporación de estándares
y procedimientos que complementen el método de desarrollo utilizado, haciendo énfasis en
los sistemas de gestión de la calidad que pueden ayudar a las organizaciones a aumentar la
satisfacción del cliente.
Los clientes necesitan productos con características que satisfagan sus necesidades y
expectativas. Estas necesidades y expectativas se expresan en la especificación 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 organización. 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 técnicos, las organizaciones
deben mejorar continuamente.
La aportación que se hizo ante esta situación fue el planteamiento de aplicar métodos
científicos y rigurosos al proceso de desarrollo de programas, apareciendo en escena la
Ingeniería del Software y la Ingeniería 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 aplicación es realizar: análisis y requisitos + programación + ciclo de pruebas. Pero esto
tiene dos inconvenientes: el primero es que es muy difícil hacer un buen análisis 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 específico dentro de todo
el desarrollo.
Se ha probado que las metodologías 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 utilización.
Actualmente los nuevos sistemas de información son costosos en tiempos y recursos,
la solución moderna de los actuales sistemas exigen nuevas herramientas y metodologías para
poder resolver, de forma rápida, económica y eficiente los problemas de información
planteados por algunas empresas.
Debemos de reconocer los problemas y causas para llegar a solucionarlos mediante la
combinación de métodos completos para todas las fases del desarrollo del software, con ayuda
de las técnicas que actualmente existen como la re-ingeniería de software, la programación
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 vería favorecido por la presencia de tres elementos clave que se conforman en la
siguiente tupla: <notación, proceso, herramientas>. Una notación extendida y aceptada que permita
documentar, visualizar, especificar y discutir a un nivel de abstracción suficiente que posibilite
las contribuciones de los diferentes roles involucrados en el proceso de desarrollo. Un proceso
sistemático, iterativo, incremental, trazable y dirigido por modelos que posibilite abordar el
desarrollo del software con ciertas garantías. 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 ingeniería tiene unos fines ligados a la obtención de un producto,
proceso o servicio que es necesario generar a través 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 gestión 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 tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece exponencialmente
con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de
“divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer
paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus
relaciones entre sí sean lo más simples posibles.
La definición 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 subcontratación 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 también se ve facilitado si la separación 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 práctica acumulada en el diseño 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. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con
bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase
se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de
ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
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 operación de una fase
Las principales diferencias entre distintos ciclos de vida radican en el alcance del ciclo
dependiendo de hasta dónde llegue el proyecto correspondiente, las características de las fases
en que dividen el ciclo y en la estructura de la sucesión 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 estabilización y aceptación del producto por el
equipo de desarrollo.
2.2.1 Fundamentos del análisis de requisitos
Antes de involucrarse en el proceso de desarrollo propiamente dicho, se ha de hacer la
definición del proceso, esto es un análisis detallado de los requisitos del sistema para que este
pueda llegar a tener las características deseadas.
El análisis de los requisitos es el conjunto de técnicas y procedimientos que nos
permiten conocer los elementos necesarios para definir un proyecto de software. Es la etapa
más crucial del desarrollo, ya que de esta depende que el resto del proceso sea correcto o no.
La tarea de análisis de los requisitos es un proceso de descubrimiento y refinamiento,
dónde el ámbito del programa, establecido inicialmente durante la ingeniería 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 Eléctricos y Electrónicos) divide los requisitos en
funcionales y no funcionales. Siendo los requisitos funcionales la condición o capacidad de un
sistema requerida por el usuario para resolver un problema o alcanzar un objetivo; y los
requisitos no funcionales la condición o capacidad que debe poseer un sistema para satisfacer
un contrato, un estándar, una especificación u otro documento formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificación
completa de los requisitos para el software final. Independientemente de lo bien diseñado 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
especificación de requisitos. El cliente intenta reformular su concepto, algo nebuloso, de la
función y comportamiento de los programas en detalles concretos y el desarrollador actúa
como interrogador, consultor y el que resuelve los problemas.
Esta fase debe incorporar una tarea de especificación conceptual donde a partir de la
descripción de los requisitos de usuario, se intenta obtener un esquema conceptual que
represente una solución al problema. Será una representación gráfica de las entidades y
relaciones que participan en el sistema. Estos diagramas, que inicialmente se hacían
generalmente mediante una notación propia, se realizan, desde los inicios de UML con este
lenguaje, lo que facilita la comunicación al poder entender cualquier persona su significado.
Estos modelos conceptuales son independientes del sistema de gestión de bases de
datos, tienen un mayor nivel de abstracción que el texto, mayor capacidad semántica y están
más enfocados al diseño de alto nivel.
El análisis y especificación de requisitos puede parecer una tarea relativamente sencilla,
pero no lo es tanto. Puesto que el contenido de comunicación es muy alto, abundan los
cambios por mala interpretación o falta de información. El dilema con el que se enfrenta un
ingeniero de software puede ser comprendido repitiendo la sentencia de un cliente anónimo:
“Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo
que creíste oír sea lo que yo quise decir”.
2.2.2 Metodologías 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 simultánea muchos elementos. Por lo tanto, es
indispensable usar una metodología de programación. Para ello, antes de escribir código y más
código es necesario haber planificado cada parte del proceso.
Una metodología indica cómo seguir uno o varios ciclos de vida y para ello define las
técnicas, entre las que están los modelos y los procedimientos, a utilizar para cada tarea y las
entradas y salidas que tiene cada tarea.
Una metodología de programación es un conjunto o sistema de métodos, principios y
reglas que permiten enfrentar de manera sistemática el desarrollo de un programa que resuelve
un problema algorítmico. Estas metodologías generalmente se estructuran como una
secuencia de pasos que parten de la definición del problema y culminan con un programa que
lo resuelve.
Figura 2-5. La metodología es lo que posibilita la asociación entre una solución y un problema
Dentro del marco global de un proceso de desarrollo, las metodologías y técnicas dan
soporte a las actividades de análisis, diseño, programación, elaboración de pruebas,
administración de riesgos, etc. Las metodologías y técnicas precisan el cómo 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 metodología, de una manera general, son los siguientes:
El diálogo: Con el cual se busca comprender totalmente el problema a resolver.
La especificación: Con la cual se establece de manera precisa las entradas, salidas y
las condiciones que se deben cumplir.
Diseño: En esta etapa se construye un algoritmo que cumpla con la especificación.
Codificación: Se traduce el algoritmo a un lenguaje de programación.
Pruebas y verificación: Se realizan pruebas del programa implementado para
determinar su validez en la resolución del problema.
Una metodología ofrece un marco y un vocabulario común para el equipo de trabajo,
sirve de guía en la utilización de las distintas técnicas 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 información de una empresa
y resuelve muchos de los problemas y necesidades actuales existentes en el desarrollo de
aplicaciones.
Una metodología debe cumplir las siguientes características:
Completa: debe de tener un entorno de trabajo que aporte soluciones a las
necesidades de un sistema de información 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 tamaño, nivel de
automatización y naturaleza del proyecto.
Facilitar la comunicación y documentación del sistema: debe de proporcionar un
lenguaje común, estandarizar el vocabulario y las definiciones utilizadas y utilizar
técnicas de diagramación.
Accesible y clara: debe de ser fácil de aprender y de usar y debe de especificar los
pasos a seguir en el desarrollo.
Adaptable a la evolución: debe facilitar las modificaciones y definir invariantes que
aseguren puntos de referencia durante la evolución del sistema.
Que permita un control de calidad y gestión de proyectos: integrando técnicas
que faciliten la planificación.
En un principio, cuando empezó el desarrollo de software, no se utilizaba ninguna
metodología, 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
utilización de nuevos métodos que ayudaran y pusieran un poco de orden en el desarrollo.
Las metodologías de desarrollo y mantenimiento de sistemas de información las
podemos clasificar, atendiendo a los diferentes enfoques.
Las metodologías estructuradas surgen a finales de los años 70, fruto de la
ampliación de una serie de criterios de la programación estructurada a otras etapas del ciclo de
vida. Intentan solucionar problemas técnicos para obtener un sistema mecanizado. Se apoya
generalmente en el ciclo de vida clásico en cascada y se diferencia de esta en el número de
etapas que soporta cada una.
La historia de las metodologías orientadas a objetos va unida a la evolución de los
lenguajes de programación orientada a objeto. A fines de los 80’s comenzaron a consolidarse
algunos métodos Orientados a Objeto.
En 1995 aparece el Método Unificado, que posteriormente se reorienta para dar lugar
al UML, la notación orientada a objetos más popular en la actualidad, de la cuál se hablará en
un próximo apartado. Una de las metodologías orientadas a objetos basadas en UML más
importantes es RUP, de la cuál se hablará también mas adelante.
La Figura 2-6 muestra los principales representantes de las metodologías tradicionales,
además de las dos alternativas posibles, MDD y metodologías ágiles, que a continuación se
comentan.
Figura 2-6. Metodologías de desarrollo
Las metodologías tradicionales se caracterizan por exponer procesos basados en
planificación exhaustiva. Esta planificación se realiza esperando que el resultado de cada
proceso sea determinante y predecible. La experiencia ha mostrado que, como consecuencia
de las características del software, los resultados de los procesos no son siempre predecibles y
sobre todo, es difícil prever desde el comienzo del proyecto cada resultado.
Una posible mejora a las metodologías tradicionales es incluir en los procesos de
desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles
detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que
puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto.
La solución a algunos de los problemas presentados por las metodologías tradicionales
se logra con una gran evolución del modelo en espiral. El proceso unificado propone la
elaboración de varios ciclos de desarrollo, donde cada uno finaliza con la entrega al cliente de
un producto terminado.
Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor
humano o el producto software. Esta es la filosofía de las metodologías ágiles, cuyos
objetivos son: valorar al individuo y las interacciones del equipo de desarrollo sobre el proceso
y las herramientas; desarrollar software que funciona más que conseguir una buena
documentación; valorar la colaboración con el cliente más que la negociación de un contrato;
responder a los cambios más que seguir estrictamente un plan. Este enfoque está mostrando
su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir
drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías
ágiles están 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 metodologías tradicionales.
En la tabla 2.1 se resumen las diferencias entre las metodologías clásicas y las
metodologías ágiles. La diferencia fundamental radica en que, para los clásicos, el paradigma se
basa en la “predecibilidad”, mientras que en los ágiles, se basa en la “adaptabilidad”. No hay
una regla determinante para la elección del método, ni siquiera del tipo de método.
Metodologías tradicionales Metodologías ágiles
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo
Basadas en heurísticas provenientes de
prácticas de producción de código
Cierta resistencia a los cambios Especialmente preparados para cambios
durante el proyecto
Impuestas externamente Impuestas internamente (por el equipo)
Proceso mucho mas controlado, con
numerosas políticas y normas
Proceso menos controlado, con pocos
principios
Existe un contrato prefijado No existe contrato tradicional o al menos es
bastante flexible
El cliente interactúa con el equipo de
desarrollo mediante reuniones El cliente es parte del equipo de desarrollo
Grupos grandes y posiblemente distribuidos Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio
Más artefactos Pocos artefactos
Más roles Pocos roles
La arquitectura del software es esencial y se
expresa mediante modelos Menos énfasis en la arquitectura del software
Tabla 2-1. Diferencias entre metodologías tradicionales y ágiles
Resumiendo, mientras que las metodologías tradicionales se centran especialmente en
el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos,
herramientas y notaciones para el modelado y documentación detallada, las metodologías
ágiles dan mayor valor al individuo, a la colaboración 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 metodologías y otros, se encuentra una necesidad
común: la de analizar los requisitos que tendrá la herramienta.
El primer paso a realizar en el desarrollo, tanto si se sigue una u otra metodología, será,
obviamente, estudiar cuáles son las necesidades que se quieren cubrir con la herramienta a
desarrollar. Una forma interesante de documentar estos requisitos es mediante una
especificación conceptual donde se resaltará la funcionalidad requerida del sistema. Además,
con la elaboración de los diagramas de clases correspondientes se permite visualizar
rápidamente cuáles son los elementos que incluirá la herramienta, y sus relaciones. De esta
forma, pueden modificarse los requisitos del sistema de una forma fácil y rápida, obteniendo
una documentación clara, concisa y fácil de realizar, característica especialmente interesante
dentro de las metodologías ágiles, donde no se quiere “perder el tiempo” con documentación.
UML, al no ser un método 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 métodos ágiles de desarrollo.
Cualquier centro de desarrollo puede montar su metodología, aunque esta alternativa
implica disponer del tiempo necesario para el desarrollo de la nueva metodología; por lo tanto,
lo más práctico es seguir los métodos que ya han demostrado su validez y son de aplicación
universal.
Una buena metodología 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 aceptación es largo y requiere tiempo. Sin embargo, la
velocidad a la que las tecnologías cambian, no ha permitido que estos ciclos se completen
adecuadamente. Esto explica por qué ha habido tan pocos avances metodológicos en el área
de construcción de software o por qué este eje va más lentamente.
Recientemente, el tema que ha despertado gran interés es el de los patrones de diseño.
Estos son soluciones probadas a problemas particulares en contextos específicos. Si bien no
son metodologías completas, son elementos claves que permiten, por un lado, manejar un
vocabulario común entre los diseñadores y, además, ofrecen elementos objetivos para
justificar una decisión.
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 aproximación para el desarrollo
de sistemas software basada en la separación entre la especificación de la funcionalidad
esencial del sistema y la implementación de dicha funcionalidad, permitiendo elevar el nivel de
abstracción, y dándole 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 código sino en los modelos.
Con esta nueva visión se puede obtener código 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 elaboración de estos
modelos es el Lenguaje Unificado de Modelado, o UML, que será presentado en el próximo
apartado de este capítulo.
El desarrollo de sistemas dirigido por modelos ha demostrado, desde hace tiempo, su
eficacia en el desarrollo de complejos sistemas hardware, y su aplicación crece continuamente
en el desarrollo de sistemas software (o combinaciones hardware-software), a medida que
surgen metodologías 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 través de un proceso guiado por modelos y soportado por potentes herramientas que
generan código a partir de modelos.
2.2.4 El proceso unificado
Para el desarrollo de un sistema es necesario un proceso que proporcione una guía
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 genérico que puede especializarse para cada clase de sistemas de software, y
para diferentes áreas de aplicación, tipo de organizaciones, niveles de competencia y tamaños
de proyecto. El PU está basado en componentes, y esto significa que está hecho de
componentes de software interconectados con interfaces. Además, 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, elaboración, construcción y transición 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 críticos (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 elaboración
El producto principal de esta fase es una arquitectura estable para guiar el sistema por
su vida futura y la planificación de la fase de construcción con fidelidad.
Para conseguirlo, se crea una arquitectura que cubre la funcionalidad y características
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
construcción.
Fase de construcción
El objetivo general de esta fase es obtener la capacidad operacional inicial en un
producto listo para prueba beta. Para ello, se extiende la identificación, descripción y
realización de los casos de uso; se termina el análisis, diseño, implementación y prueba del
producto; se mantiene la integridad de la arquitectura y se monitorizan los riesgos críticos y
significativos de las fases anteriores y, en caso de que se presenten, se mitigan.
Fase de transición
Esta fase empieza con la liberación beta del producto. En ella se prepara la instalación;
se advierte al cliente sobre actualizaciones de SO, hardware, protocolos de comunicaciones,
etc.; se preparan manuales y documentación; se ajusta el software para operar bajo parámetros
actuales del ambiente del usuario; se corrigen defectos después de pruebas beta y se modifica
el software en caso de que se presenten problemas no previstos.
Figura 2-7. Perfil de Proyecto Típico
En la Figura 2-7 se observa la relación que hay entre tiempo y recursos necesarios en
cada una de las fases expuestas.
El producto final consiste de código fuente incluido en componentes que se puede
compilar y ejecutar, más manuales y entregables asociados. Además, tiene que satisfacer las
necesidades no sólo 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 serán artefactos
modelados con UML. Aun si los componentes ejecutables son los artefactos más importantes,
por si solos no son suficientes porque el ambiente cambia (sistema operativo, sistemas de
bases de datos, avance tecnológico,...).
2.2.6 El proceso de desarrollo definido en Rational (RUP)
En los últimos años se han definido numerosos procesos que se ajustan a los
principios del proceso unificado. El proceso más extendido ha sido el RUP (Rational Unified
Process), que puede ser una buena metodología de desarrollo a tener en cuenta para proyectos
medianos y grandes, además de ser el ejemplo por excelencia de metodología orientada a
objetos.
El RUP es un proceso de desarrollo de software que junto con el UML, constituye la
metodología estándar más utilizada para el análisis, implementación y documentación de
sistemas orientados a objetos. Se caracteriza por la forma disciplinada de asignar tareas y
responsabilidades y pretende implementar el desarrollo iterativo, la administración de
requisitos, el uso de arquitectura basada en componentes, el control de cambios, el modelado
visual del software y la verificación 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 código fuente, etc.; y
roles, que es el papel que desempeña una persona en un determinado momento, una persona
puede desempeñar distintos roles a lo largo del proceso.
RUP está basado en el seguimiento de una serie de normas o “mejores prácticas”
aplicadas a cuatro etapas o ciclos en las diversas iteraciones del desarrollo: Inicio, Elaboración,
Construcción y Transición. Cada ciclo se divide en fases que finalizan con un hito donde se
debe tomar una decisión importante:
Inicio: se hace un plan de fases, se identifican los principales casos de uso y se
identifican los riesgos.
Elaboración: se hace un plan de proyecto, se completan los casos de uso y se
eliminan los riesgos.
Construcción: se concentra en la elaboración de un producto totalmente operativo y
eficiente y el manual de usuario.
Transición: 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 metodología RUP
2.3 Lenguajes y notaciones de programación y de diseño
Existen muchas notaciones para representar los artefactos del diseño del software.
Algunas se utilizan principalmente para describir la organización estructural de un diseño,
otras para representar comportamiento del software. Ciertas notaciones se utilizan sobre todo
durante el diseño arquitectónico y otros principalmente durante el diseño detallado, aunque
algunas notaciones se pueden utilizar en ambos pasos.
2.3.1 Lenguajes de programación
Un paradigma de programación representa un enfoque particular o filosofía para la
construcción del software. Diferentes paradigmas resultan en diferentes estilos de
programación y en diferentes formas de pensar la solución de problemas. No es mejor uno
que otro sino que cada uno tiene ventajas y desventajas. También hay situaciones donde un
paradigma resulta más apropiado que otro.
Según el paradigma de programación que utilizan, se pueden clasificar los siguientes
lenguajes:
Lenguajes Imperativos: La programación imperativa describe la programación en
términos 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 cómo realizar una tarea. El código máquina en general está basado en el
paradigma imperativo.
Lenguaje Estructurado: La programación se divide en bloques (procedimientos y
funciones) que pueden o no comunicarse entre sí. Además, la programación se
controla con secuencia, selección e iteración. Permite reutilizar código programado y
otorga una mejor compresión de la programación. Es simplemente un “bloque”, como
por ejemplo, los archivos batch (.bat).
Lenguaje Lógico: Se basa en la definición de reglas lógicas para luego, a través de un
motor de inferencias lógicas, responder preguntas planteadas al sistema y así resolver
los problemas. Comprende dos paradigmas de programación: la programación
declarativa y la programación funcional. La programación declarativa gira en torno al
concepto de predicado, o relación entre elementos. La programación funcional se
basa en el concepto de función, de corte más matemático.
Lenguaje Declarativo: Se enfoca en describir las propiedades de la solución buscada,
dejando indeterminado el algoritmo usado para encontrar esa solución. Es más
complicado de implementar que el paradigma imperativo, tiene desventajas en la
eficiencia, pero ventajas en la solución de determinados problemas.
Lenguajes Funcionales: Basado en la utilización de funciones matemáticas, para
conseguir lenguajes expresivos y matemáticamente elegantes, en los que no sea
necesario bajar al nivel de la máquina para describir el proceso llevado a cabo por el
programa, y evitando el concepto de estado del cómputo.
Lenguajes Orientados a Objetos: Define los programas en términos 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 métodos. La identidad es una propiedad de un objeto que lo
diferencia del resto. La programación 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 módulos más fáciles de escribir, mantener y reutilizar.
Su principal ventaja es la reutilización de código y su facilidad para pensar soluciones a
determinados problemas.
Aunque hay que tener en cuenta que la programación es solo una pequeña parte de
todo lo que conlleva la ingeniería del software. Debe quedar claro y patente que el paradigma
orientado a objetos ha supuesto un cambio radical y un punto de inflexión en la evolución 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 metodología de trabajo para que todo el mundo, desde un principio,
genere una documentación escasa y útil. También hace falta que, cuando las aplicaciones estén
construidas, se establezcan unos procedimientos sencillos para que, a medida que se van
produciendo mejoras, se vaya generando o completando la documentación deficiente.
Realizar un buen análisis o reingeniería requiere de técnica. A menudo no se tiene un
procedimiento estructurado que haga predecible tal análisis y se tiende a pensar que las
herramientas solucionarán los problemas. Las herramientas son solo el soporte y debemos
basarnos en un hábito en el trabajo. Sin método y disciplina, la cosa no mejorará.
El único modo de resolver el problema es a través de la formación personalizada y la
implantación de buenos hábitos y técnicas sobre: dirección moderna de proyectos
informáticos, estimación rápida de proyectos, gestión eficaz del tiempo, motivación de
equipos, análisis y diseño orientado a objeto, UML y modelado de datos y técnicas avanzadas
de diseño (patrones).
Una vez que ya han sido recopilados, clasificados y alojados en el nivel de jerarquía que
les corresponde, hay que poner por escrito los requisitos del sistema.
El lenguaje de especificación o modelado representa el vehículo indispensable para la
comunicación entre los participantes y para la representación de conceptos a lo largo de todo
el proyecto, utilizando una semántica común.
Por eso, desde mediados de los 70 hasta finales los 80 aparecieron una serie lenguajes
orientados a la modelación de programas orientados a objetos, ya para mediados de los 90
había mas de 50 lenguajes y metodologías que satisfacían características muy especificas de
modelado, provocando que los usuarios tuviesen problemas para satisfacer sus necesidades
con una u otra metodología.
Se necesitaba, por tanto, un lenguaje no sólo para comunicar las ideas a otros
desarrolladores sino también para servir de apoyo en los procesos de análisis 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 unificación de las metodologías Booch y OMT (Object
Modeling Technique), en el otoño del 95 Ivar Jacobson se unió junto con su compañía Objetory a
Rational, con la finalidad de unificar esfuerzos, integrando la metodología OOSE (Object-
Oriented Software Engineering).
UML se convirtió en ese estándar tan anhelado para representar y modelar la
información con la que se trabaja en las fases de análisis y, especialmente, de
diseño. Actualmente, UML es el lenguaje de modelado de sistemas de software más conocido
y utilizado en la actualidad; además de ser un estándar, está apoyado en gran manera por el
OMG (Object Management Group), grupo que gestiona estándares relacionados con la tecnología
orientada a objetos, del cual forman parte las empresas más importantes que se dedican al
desarrollo de software.
La última versión aprobada es la UML 2.0. En estos momentos se están desarrollando
actualizaciones a esta versión en la que se incluirán cambios importantes, principalmente,
añadir nuevos diagramas.
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema
de software. UML ofrece un estándar 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 programación, esquemas de bases de
datos y componentes de software reutilizables. UML ha sido diseñado para modelar cualquier
tipo de proyectos, tanto informáticos como de arquitectura, o de cualquier otro ramo.
La aparición de UML supuso el reconocimiento de la actividad del modelado (diseño
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 propósito general que pueden usar todos los
modeladores. No tiene propietario y está basado en el común acuerdo de gran parte de
la comunidad informática.
UML no pretende ser un método 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 sólida 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 distribución, así como también los mecanismos de la
ingeniería de software, como son la encapsulación y componentes.
Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
Imponer un estándar mundial.
A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha
sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la
interpretación de un modelo UML no pueda ser objetiva. Otro problema que tiene UML es
que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran
importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con
maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un
objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es
compartido entre varias instancias de ejecución del sistema analizado.
Otra de las críticas que se han comentado de UML es la carencia de patrones
integrados con el lenguaje. Los patrones hacen más fácil y rápido el modelado, pero UML no
dispone de ellos.
Con UML, lo que se pretende es lograr que los lenguajes que se aplican siguiendo los
métodos más utilizados sigan evolucionando en conjunto y no por separado. Y además,
unificar las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en
el ámbito de los negocios), al aclarar las fases de desarrollo, los requisitos de análisis, el diseño,
la implementación 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 gráfico. Además, se ha llegado a una solución
unificada basada en lo mejor que había hasta el momento, lo cual lo hace todavía más
excepcional.
Es importante remarcar que UML es un “lenguaje” para especificar y no un método 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 metodología de desarrollo
de software (tal como el Proceso Unificado de Rational) pero no especifica en sí mismo qué
metodología o proceso usar.
2.4 Herramientas para el desarrollo del software
Además de la aproximación metodológica y el lenguaje, uno de los factores
determinantes en el éxito de un proyecto de software, lo constituye la acertada selección de las
herramientas de trabajo que se utilizarán durante su desarrollo. Es por eso que, en la
actualidad, la administración de proyectos atiende cuidadosamente la designación de
herramientas como una tarea de vital importancia.
A medida que los sistemas que se construyen se tornan más y más complejos, las
herramientas de modelado con UML ofrecen muchos beneficios para todos los involucrados
en un proyecto, por ejemplo, administrador del proyecto, analistas, diseñadores, arquitectos,
desarrolladores y otros. Las herramientas CASE de modelado con UML nos permiten aplicar
la metodología de análisis y diseño orientados a objetos y abstraernos del código fuente, en un
nivel donde la arquitectura y el diseño se tornan más obvios y más fáciles de entender y
modificar. Cuanto más grande es un proyecto, es más importante utilizar una herramienta
CASE.
2.4.1 CASE
Las herramientas CASE surgen a principios de la década 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 están tomando cada vez mas relevancia en la planificación y
ejecución de proyectos que involucren sistemas de información, pues suelen inducir a sus
usuarios a la correcta utilización de metodologías que le ayudan a llegar con facilidad a los
productos de software construidos.
Las Herramientas CASE (Computer Aided Software Engineering - Ingeniería del Software
Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la
productividad en el desarrollo de software reduciendo el coste de las mismas en términos de
tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de
vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto,
cálculo de costes, implementación de parte del código automáticamente con el diseño dado,
compilación automática, documentación o detección de errores entre otras.
Todas las herramientas CASE prestan soporte a un lenguaje de modelado para
acompañar la metodología y es lógico suponer que un alto porcentaje de ellas soportan UML,
teniendo en cuenta la amplia aceptación 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 años, existe en el mercado una gran variedad de herramientas de modelado de
diagramas UML.
Las herramientas CASE son una combinación de herramientas de software y
metodologías estructuradas de desarrollo que han surgido para dar solución 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 tamaño, 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
análisis y diseño relacionados con los proyectos, como la lógica en el diseño y la coherencia
entre módulos, entre otros. Simultáneamente, la mejora de la productividad se consigue a
través de la automatización de tareas, como la generación y reutilización de código, 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 informáticos.
Mejorar la planificación de un proyecto
Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la
búsqueda de soluciones para los requisitos.
Automatizar, desarrollo del software, documentación, generación de código, pruebas
de errores y gestión del proyecto.
Ayuda a la reutilización del software, portabilidad y estandarización de la
documentación
Gestión global en todas las fases de desarrollo de software con una misma
herramienta.
Facilitar el uso de las distintas metodologías propias de la ingeniería 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, dónde se ha hecho una comparativa de algunas de las herramientas CASE más
relevantes, atendiendo a las características más destacables a tener en cuenta, no es muy
habitual su consideración.
Se ha observado que en alguna de las herramientas que se utilizan con objetivo más
profesional sí incluye la utilización de patrones. No obstante, solamente se contemplan los
patrones de diseño.
PROPIEDADES ARGOUML RATIONAL ROSE WITHCLASS TOGETHER POSEIDON
Web argouml.tigris.org www.rational.com www.microgold.com www.borland.com www.gentleware.com
Observaciones generales Navega de acuerdo con
diferentes perspectivas de
modelado y de metodología
de desarrollo
Provee productos de UML
para los lenguajes comunes de
la industria para
especificación, visualización,
construcción y documentación
de los artefactos de los
sistemas software
Utiliza perspectiva objeto
relacional con diferentes
metodologías de desarrollo y
modelado
Robusta y sólida plataforma
de Borland fácilmente
integrable a JBuilder. Usa
refactoring y patrones. Apoya
procesos de testing a través de
un marco apropiado. Es
extensible a necesidades de
estándar de la organización
Herramienta de Gentleware
que genera código en Java
usando plantillas, realiza
ingeniería inversa y
sincronización de código en
Java. Se puede considerar la
versión comercial y mejorada
de ArgoUML. Apoya el
proceso de documentación de
diagramas con UML.doc
Ámbito de utilización Sus características se ajustan a
proyectos académicos y de
investigación
Se enmarca dentro del
desarrollo de modelado para
fines académicos y
comerciales
Sus características se apoyan
en el desarrollo orientado a
objetos para proyectos
académicos, investigativos y
de comercialización
Se ajusta a grandes proyectos
de ingeniería de software en
los que la confiabilidad y
administración de la
información sean relevantes
Sus características se apoyan
en el desarrollo orientado a
objetos para proyectos
académicos, investigativos y
de comercialización
Plataforma Independiente de la
Plataforma. Requiere Máquina
Virtual Java 1.3 o superior
Sistema Operativo Windows Sistema Operativo Windows Funciona sobre una máquina
virtual Java
Independiente de la
Plataforma. Requiere Máquina
Virtual Java 1.3 o superior
Apoyo metodológico No apoya una metodología
específica
UML, Booch y OOSE; todas
ellas apoyadas en RUP.
Soporta MVC.
OMT, UML, Booch, Martin-
Odell, Coad-Yourdon.
Refactoring, testing
Framework, desarrollo de
plantillas y patrones. Apoya el
desarrollo de Web Aplication
Wservice.
No apoya una metodología
específica. A través del
browser sugiere cierta
organización de proyecto.
Métricas No hay métricas Apoya la utilización de
métricas
Apoya la utilización de
métricas
Apoya la utilización de
métricas
No hay métricas
Autogeneración Java, C++, PHP Java, J2EE, ANSI, C++,
Visual C++, VB, CORBA
IDL, MIDL y XML
C++, C#, Java, Delphi, VB,
VB.NET
VB, VB.NET, CORBA IDL,
C++
Java, HTML, C++ y XML.
Plugins para C#, CORBA IDL
Edición de código Java Visual Basic, Java Add-in para otros editores Java Eclipse y JBuilder OCL para JAVA
Tabla 2-2. Comparativa herramientas CASE
Además de las herramientas CASE más comunes, comentadas en la tabla, cabe
comentar la existencia de Hypermodel, una herramienta basada en Eclipse, que sirve para el
diseño dirigido por modelos de esquemas XML y SOA. Es una herramienta de análisis y
diseño que trabaja bien en combinación con otras herramientas UML2, como Rational, y
ofrece modelos UML y diagramas de cualquier esquema XML, permitiendo transiciones
automáticas de uno a otro formato.
2.5 La utilización 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 tácito y su papel en la generación de conocimiento. Sus autores
aseguran que “El aprendizaje más 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.
También se comentaba en apartados anteriores que una buena metodología 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. Además se hablaba del interés
que están adquiriendo los patrones de diseño como elementos clave dentro de la metodología
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 más o menos
parecidas. Desde el principio quedó patente que sería un gran avance poder “capturar” esa
experiencia, de modo que la forma correcta de resolver un problema dado pudiera ser
transmitida a individuos que todavía no se han topado con el. La idea es que si ya se ha
solucionado un problema dado, esa misma solución podría 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
patrón no es más que la descripción detallada de una solución adecuada a un problema
concreto; o, dicho de otra forma, un modelo que podemos seguir para realizar algo. El
objetivo básico que se persigue con la idea de patrón es aprovechar lo que ya ha sido utilizado
con éxito anteriormente, en casos similares al nuestro, y adaptarlo a nuestras condiciones para
obtener la solución más fácilmente.
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 prácticas.
Fueron inicialmente concebidos por el arquitecto Christopher Alexander como una manera de
formalizar la solución a problemas comunes a muchos proyectos de arquitectura. Este
arquitecto escribió dos libros revolucionarios que describían patrones en arquitectura de
construcción y planificación urbana (Alexander, 77) y (Alexander, 79).
Según 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 común brinda el poder de crear una infinita variedad de oraciones.”
Más tarde, vista la eficacia de los patrones en el campo de la arquitectura, otras
disciplinas los añadieron a su repertorio de herramientas y las ideas presentadas en estos libros
son aplicadas a varios campos además de la arquitectura, incluyendo el software.
Christopher Alexander creía que muchos procesos implicados en el diseño de
estructuras físicas eran variables, pero que existía un invariante común, que definía los
principios generales del diseño y construcción. El descubrimiento de las invariantes aplicables
al diseño de software es hoy el objetivo de los desarrolladores de software, pues proporcionan
un marco común de conocimiento y soluciones.
Se necesita de años 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 adaptación de este concepto a la ingeniería del software ha dado lugar a lo que
conocemos como patrones software. Estos patrones capturan soluciones a situaciones de
especial interés, 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 diseño de interfaces de usuario, que publicaron en un
artículo 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 más influyentes de esta década:
“Design Patterns” (Gamma et al., 1995), que popularizó la idea de patrones. La reacción 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 habían 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 algún contexto
determinado del proceso de desarrollo de software, y entregan una buena solución ya probada.
La utilización 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 diseñar software correctamente en menos tiempo, ayuda a construir problemas
reutilizables y extensibles, y facilita la documentación y la comunicación con otros miembros
del equipo de desarrollo.
La llegada de los patrones al mundo de la construcción de sistemas software ha sido
una aportación fundamental, llevando a esta disciplina a abandonar su tradicional status de
artesanía y acercándola al nivel de sistematización y robustez del que gozan otras ingenierías.
Parte del interés en los patrones viene de observar que los proyectos fracasan a pesar
de que se utilizan las últimas tecnologías cuando no hay soluciones comunes. Los patrones
proporcionan una manera de organizar y nombrar esas soluciones comunes para hacer más
fácil su utilización a la gente.
Documentar buenos patrones puede ser una tarea muy difícil. Las características que
ha de tener un buen patrón, según Coplien, son las siguientes:
Resuelve un problema: Los patrones capturan soluciones, no principios o estrategias
abstractas.
Es un concepto probado: Capturan soluciones, no teorías o especulaciones.
La solución no es obvia: Muchas técnicas de resolución de problemas, como los
paradigmas o métodos de diseño de software, intentan derivar soluciones desde
principios básicos. Los mejores patrones generan una solución a un problema
indirectamente, un enfoque necesario para los problemas de diseño más difíciles.
Describe una relación: Los patrones no describen módulos sino estructuras y
mecanismos.
Tiene un componente humano significante: El software sirve a las personas. Los
mejores patrones se aplican a la estética y a las utilidades.
Un lenguaje de patrones contiene un amplio conjunto de patrones, cuyas
combinaciones conforman su gramática.
Un sistema de patrones mantiene unidos a sus patrones. Describe la forma en que se
conectan y cómo 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 colección de patrones, junto con las guías para su implementación,
combinación y uso práctico en el desarrollo de software.
Los patrones no son siempre la solución adecuada o mejor para un problema. Si bien
añaden flexibilidad, también añaden 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 mayoría de situaciones que se dan en cualquier
proyecto medio complejo. Aún 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 mayoría de referencias a patrones suelen referirse a los patrones de diseño. Sin
embargo hay otros ámbitos de la ingeniería del software donde se puede aplicar el concepto
genérico de patrón:
Patrones de diseño (Gamma et al., 1995): Describen la conducta, estructura, y
colaboración de objetos dentro de un subsistema de la aplicación.
Patrones de arquitectura (Buschmann et al., 1996): Describen la estructura general
de un sistema. Identifica sus módulos, responsabilidades, y la colaboración entre
dichos módulos.
Patrones de análisis (Fowler, 2002): Describen un conjunto de prácticas destinadas a
elaborar el modelo y solución de un problema.
Patrones de procesos o de organización (Coplien & Schmidt, 1995): Describen la
estructura y prácticas de las organizaciones humanas, especialmente las productoras de
software.
Patrones de programación idioms (Coplien, 1991): Un idiom es un patrón que
describe cómo implementar ciertas tareas usando un lenguaje de programación
concreto.
Patrones de colaboración: son el tipo de patrones en el que se centra este proyecto
y, por considerarlos en este caso de mayor importancia, se contemplan más 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 tecnologías.
Modelar con patrones tiene importantes ventajas, la más obvia es la rapidez. Una vez
que se identifica una relación con el mundo real, ésta puede sustituirse rápidamente por el
modelo de dominio correspondiente a su patrón específico de objetos. De esta manera, los
patrones no solo construyen el modelo de objetos conectando objetos conocidos, también
ayudan a encontrar nuevos objetos necesarios para rellenar un patrón 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 más problemas que los que
solucionan. Son una extensión natural a los patrones de diseño. Comprender los antipatrones
provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los
antipatrones permite conocer los errores más comunes relacionados con la industria del
software. En 1996 Michael Akroyd formaliza el concepto de antipatrón en su presentación
(Akroyd, 1996) centrándose en identificar errores comunes cometidos en proyectos de
software. Aunque la obra de referencia más destacada en este campo es “AntiPatterns:
Refactoring Software, Architectures and Projects in Crisis” (Brown et al., 1998).
Un antipatrón no es una mala práctica, sino la reflexión consciente sobre esa mala
práctica. Su conocimiento es útil porque ayuda a reconocer, corregir, y prevenir un problema.
Hay dos tipos de antipatrones: aquellos que describen una mala solución a un problema y
aquellos que describen como llegar a una solución desde un problema.
Según James Coplien, un antipatrón es “algo que se ve como una buena idea, pero que falla
malamente cuando se la implementa.”
Un buen antipatrón explica por qué la solución original parece atractiva, por qué se
vuelve negativa y cómo recuperarse de los problemas que ésta genera.
2.6.3 Los patrones de colaboración
Para abordar el modelado del dominio, Peter Coad proponía sus patrones
conceptuales, que fueron posteriormente adaptados a UML por Jill Nicola, Mark Mayfield y
Mike Abney en sus patrones de colaboración. Con estos patrones se permite la especificación
y el modelado de objetos en el modelado del dominio.
Los patrones de colaboración son la representación de los componentes o “pattern
players”: personas, lugares, cosas y eventos. Mientras el objeto describe el significado y la
relevancia de los objetos, el patrón de colaboración, con su formato gráfico conciso y no
ambiguo, ilustra la interacción entre dos objetos. Por lo que exponen los gráficos, y revelan los
objetos, los patrones de colaboración dejan claro los principios de cómo trabajar juntos para
crear el modelo de objetos.
Personas Actor
Role
Lugares Place
Outer Place
Cosas Item
Specific Item
Assembly
Part
Container
Content
Group
Member
Eventos Transaction
Composite Transaction
Line Item
Follow-up Transaction
Tabla 2-3. Elementos de los patrones
Los patrones de colaboración no son patrones de diseño. Los patrones de diseño se
enfocan en la eficiencia, la reusabilidad, y la conectabilidad, y mientras estas son las metas
importantes, se preocupan más de “cómo” efectuar una interacción que de “qué” es lo que
debe relacionar en ella. Los patrones de colaboración describen el “qué” de una interacción,
los objetos involucrados y las reglas que rigen estas interacciones.
Los patrones de colaboración son, por definición, 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 actúa como varios “pattern players”.
En la Figura 2-9 se muestran los patrones de colaboración propuestos por (Nicola et
al., 2001). A continuación se describe cada patrón de colaboración 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 cuáles pueden consultarse en este libro.
Algunos de los patrones de colaboración descritos a continuación 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 fácilmente para todo el mundo, al describirse en un lenguaje
estándar.
Figura 2-9. Patrones de colaboración (Nicola et al., 2001)
En el Apéndice A se ha incluido la relación de patrones descrita por (Nicolla et al,
2001) con más detalle, y se recomienda, si se desea tener mas información acerca de ellos,
consultar el libro de referencia.
Como ejemplo más completo, se verá un poco más a fondo el patrón Actor-Role, que
es uno de los patrones propuestos.
Un ejemplo de patrón de colaboración que puede considerarse para verse en detalle,
según la descripción que hizo (Nicola et al., 2001), es el patrón Actor-Role.
El patrón actor – role modela las entidades que interactúan en contextos múltiples. Lo
más frecuente es aplicarlo a personas, pero también se puede aplicar a lugares y a cosas. Este
patrón se presenta en la gente, el contexto y los principios de role que sugieren dos objetos,
uno describe la persona u organización (actor), y el segundo describe la persona u organización
dentro de un contexto (role). Para cada contexto, se crea un nuevo role.
El patrón 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 múltiples roles, pero solo uno de cada tipo. El actor es responsable
de conocer información (propiedades, servicios y colaboraciones) que son relevantes a través
de todo el contexto.
EJEMPLO- En una aplicación de comercio electrónico 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 válido. Los cambios en el
actor (nuevos valores de las características o nuevas colaboraciones) pueden afectar también al
role. Esta dependencia que sigue un actor es porque un role es una descripción individualizada de
un actor, la apariencia de un actor dentro de un contexto. Si se disuelve la colaboración,
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 también
conoce el tipo de actors con los que puede colaborar; algunos roles trabajan solamente con los
actors de la organización.
EJEMPLO- En una aplicación de cadenas de suministros, una compañía puede ser a la vez un
proveedor de género y servicios y un distribuidor al que compran los proveedores.
A veces, un role tiene doble función como actor para otro role.
EJEMPLO- Un equipo de proyecto colabora en línea. 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 estándar para documentar los patrones. El formato más usado incluye
algunos de estos apartados: nombre, clasificación, resumen, problema, contexto, fuerzas que
intervienen, solución, ejemplo, patrones relacionados, exposición razonada, y usos comunes.
La inclusión o no de todos ellos se rige por el sentido común. El objetivo no es ajustarse a un
formato rígido, sino comunicar información útil.
El primero en identificar el concepto general de patrón 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 patrón según Christopher Alexander
La mayoría 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 selección para trabajar con sus preferencias.
A pesar de estar expresados de distintas formas, la mayoría de patrones tienen
elementos comunes:
Los patrones son soluciones: El propósito de escribir un patrón es describir una
solución útil y recurrente. El éxito estará en que otros puedan duplicar esta solución
cuando sea apropiada. Todo lo demás es secundario, lo que significa que
independientemente de la forma que se elija para escribir un patrón, la solución es lo
que cuenta.
Un nombre significativo: La elección de nombres es muy difícil. 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 patrón está compuesto por el enunciado del problema y una o varias
propuestas de solución. Para formalizar estas soluciones, se necesita una notación expresiva y
rica en semántica que permita plasmar eficientemente los atributos de las mismas. Además esta
notación ha de ser fácil de entender e interpretar. La notación más extendida es UML, que
permite capturar con precisión 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 patrón en muchos títulos:
Intención, motivación, aplicación, estructura, participantes, colaboraciones, consecuencias,
implementación, código de ejemplo, usos conocidos, y patrones relacionados
2.7 Análisis y conclusiones
Se decía anteriormente que los patrones de colaboración 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
colaboración aparecen en esta primera parte del desarrollo.
Se ha hablado también 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 fácilmente alguno de los patrones
de colaboración propuestos, siendo rara la vez que esto no ocurre. Es, por estos motivos, por
los que la utilización de los patrones de colaboración va a aportar unos beneficios en el
modelado del negocio, ya que los patrones serán muy probablemente partes de este modelado,
por lo que se podrían incluir directamente, en lugar de ir añadiendo los objetos uno por uno,
lo que facilitaría 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 función de esa importancia que tiene la experiencia, lo que se pretende en este
PFC, como se indica en la motivación, 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 capítulo,
en los patrones de colaboración. Esto se abordará en el tercer capítulo y más tarde, en el
cuarto capítulo, se pondrán algunos casos de ejemplo.
Sería interesante disponer de una notación capaz de especificar la esencia de un patrón
de forma clara, sencilla y precisa, así como de herramientas que faciliten la definición,
aplicación semi o automática y validación de éstos en diferentes contextos. Sin embargo, esta
labor es compleja y no se ha avanzado apenas, ya que no está claro qué se debería especificar y
cómo especificarlo.
Siendo tan útiles los patrones de colaboración, lamentablemente, no se ha encontrado
ninguna herramienta CASE que recoja este tipo de patrones y permita incluirlos en el
modelado del negocio.
Capítulo 3. Integración de los patrones de colaboración en el proceso de desarrollo
En este capítulo se analizan los requisitos necesarios que ha de tener la herramienta
propuesta para añadir patrones de colaboración en los diagramas de clases, para facilitar el
modelado del dominio. Para la descripción del trabajo realizado se hace un análisis, un diseño
y una implementación de la herramienta desarrollada y, posteriormente, se describe el entorno
resultante. Asimismo, y habiéndole otorgado una importancia singular a los patrones de
colaboración (Nicola et al., 2001) se comentará cómo se ha hecho la descripción de dichos
patrones para facilitar su utilización y la manera en que se han almacenado.
3.1 Introducción
Se ha comprobado la importancia que tienen las primeras fases en el desarrollo del
software, donde la recolección y modelado de los requisitos puede ser decisivo para que la
posterior implementación 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 utilización de patrones de
colaboración directamente sobre el modelado.
Esta herramienta está especialmente indicada para facilitar los primeros modelados en
el proceso de desarrollo, tiene propósito didáctico y se considera útil porque con ella, los
estudiantes y futuros desarrolladores pueden tomar un primer contacto con el modelado de
los requisitos, beneficiándose de la utilización 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 colaboración (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 añadir
nuevos patrones, propios o de otras colecciones, para hacerle lo más fácil posible la tarea del
modelado, que tanto cuesta llevar a cabo al principio a un ingeniero del software.
3.2 Documentación y especificación de la aplicación desarrollada
En este apartado se contempla la especificación 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
especificación de cada uno de ellos, se muestra un modelado conceptual, con las clases que se
utilizan para la implementación y se comentan los paquetes de los que se compone la
aplicación. Por último, se analizan los pasos que se han de dar para llevar a cabo algunas de las
acciones más significativas, a través de los diagramas de secuencia correspondientes.
3.2.1 Objetivos
Se ha pensado desarrollar una herramienta de fácil utilización y muy intuitiva con la
cual los estudiantes de ingeniería del software puedan familiarizarse con el modelado del
dominio. Lo particular de esta aplicación es que permitirá a sus usuarios la inclusión directa de
patrones en su modelo. Para ello, se facilita con la herramienta la colección de patrones de
colaboración de (Nicola et al, 2001), los cuales el usuario podrá modificar en base a sus
necesidades. La elección 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 común identificar alguno
de estos patrones en cualquier tipo de modelado. No obstante, el usuario podrá modificar
estos patrones o completar la colección 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
informática, se le presentan los patrones de colaboración y este se habitúa con ellos, será muy
fácil para él identificarlos en cualquier diagrama de clases con el que trabaje, ya que son
patrones muy comunes y fácilmente 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 gestión y edición de diagramas de clases. Habrá que tener
en cuenta que las clases constarán de métodos y atributos, y que habrá relaciones entre ellas.
Dichas relaciones tendrán una clase origen y una clase destino y podrán ser de distintos tipos:
dependencia, generalización, asociación, agregación o composición.
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 patrón, sus características y las relaciones entre ellas, sino que todo esto estará
almacenado en un fichero y se podrá añadir el patrón completo al modelo. Cuando el usuario
pretenda incorporar un patrón, el sistema le permitirá sustituir, si lo desea, las clases del patrón
por las que tenga ya definidas en el diagrama.
En principio, la herramienta dispondrá de la colección de patrones de colaboración 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 patrón con el editor de clases y, una vez
representadas sus clases, relaciones y propiedades, guardarlo en el repositorio como un patrón
más.
En una primera aproximación, la funcionalidad que deberá ofrecer la herramienta será
la señalada en la Figura 3-1.
Figura 3-1. Esquema básico de la funcionalidad de la herramienta
La herramienta, además de lo comentado, también permitirá acciones a las que se les
ha dado menor importancia en este proyecto, para facilitar el uso al diseñador. De esta
manera, podrá guardarse el diagrama de clases diseñado, simplemente como diagrama de
clases, o como un nuevo patrón, en cuyo caso se añadirá al repositorio correspondiente de
patrones disponibles y podrá ser reutilizado posteriormente de manera conjunta a los patrones
de colaboración 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 código XML
asociado al diagrama sobre el que se está trabajando, y también podrá guardarse el diagrama
como gráfico, 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 características del sistema de gestión de la herramienta. Para ello se representarán 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 clasificarán y detallarán 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á diseñada para el modelado
de sistemas, y está especialmente indicada para estudiantes de informática, iniciándose en el
desarrollo y modelado del dominio, por lo que los usuarios que interactúen con ella estarán
acostumbrados a utilizar programas informáticos, 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 gestión de patrones y por otro lado, a la edición de diagramas de
clases.
Figura 3-2. Diagrama de casos de uso de la herramienta
Respecto a la gestión de patrones, habrá un repositorio donde estén almacenados los
patrones de colaboración, en un principio, pero que el usuario podrá completar añadiendo
nuevos patrones a este repositorio, eliminar patrones de los existentes o modificarlos según
sus necesidades.
Para añadir un nuevo patrón, el diseñador ha de elaborar el correspondiente diagrama
de clases y guardarlo en el repositorio, para así poder ser utilizado como patrón, junto con los
ya establecidos patrones de colaboración.
Los patrones se guardarán en un fichero, por lo que para modificar un patrón
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 elaboración de diagramas de clases, al usuario se le permite añadir
nuevas clases y relaciones, pudiendo para ello utilizar los patrones disponibles en el
repositorio. En este caso, se añadirían las nuevas clases que forman el patrón. El usuario
tendrá la opción de elegir si quiere que las clases del patrón coincidan con alguna de las que ya
tiene en su diagrama, y si es así, se sustituirá y se añadirán únicamente las relaciones necesarias
y las clases que no estén ya representadas.
Además, el usuario podrá eliminar clases y relaciones del diagrama, al igual que
consultarlas y modificarlas para representar su modelo.
Una vista muy básica de las actividades necesarias que se tendrán que llevar a cabo con
la herramienta propuesta para la realización de un diagrama de clases, en general, viene
representada en la Figura 3-3, aunque la aplicación ofrecerá mucha más funcionalidad que para
este diagrama no se ha tenido en cuenta.
Figura 3-3. Diagrama de actividades para la elaboración de un diagrama de clases
A continuación se especifican, mediante tablas y siguiendo la metodología propuesta
por Amador Durán (Durán & Bernárdez, 2002), los distintos casos de uso que va a tener la
herramienta desarrollada en este proyecto para que cumpla con las especificaciones deseadas.
Según los autores, “El objetivo de esta metodología es la definición de las tareas a realizar, los productos a
obtener y las técnicas a emplear durante la actividad de elicitación de requisitos de la fase de ingeniería de
requisitos del desarrollo de software.”
Caso de Uso “Añadir Clase”
Descripción En este caso de uso, el diseñador dibuja una nueva clase en el diagrama. Esto podrá hacerse de dos formas distintas: directamente, o a través de un patrón. En el caso de que sea el diseñador el que elija la opción de añadir 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 también podrá ser añadida a través de un patrón. Es decir, cuando se de el caso de uso “Utilizar Patrón”, directamente se añadirán las clases de las que se componga dicho patrón al diagrama. De esta forma, la clase tendrá asociadas aquellas propiedades que tuviera la misma en el patrón.
Precondiciones
Flujo de eventos Flujo básico
El diseñador selecciona la opción de añadir una nueva clase en el diagrama.
El diseñador 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 unánime.
Inicialmente, la nueva clase no tendrá atributos ni métodos asociados.
Flujo alternativo
El diseñador utiliza un patrón del repositorio.
Las clases que componen el patrón, y que el diseñador no haya seleccionado para que sean sustituidas por alguna de las ya existentes, se añaden automáticamente al diagrama.
Las nuevas clases añadidas tendrán las mismas propiedades, atributos y métodos que tuviera la clase a la que representan en el patrón.
Poscondiciones La nueva clase dibujada queda registrada de forma unívoca mediante un identificador que el usuario no podrá modificar. Opcionalmente, el diseñador podrá cambiar las características de la clase, añadir nuevos atributos o métodos o asociar esta clase a otras mediante relaciones.
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Utilizar patrón Tabla 3-1. Caso de uso “Añadir Clase”
Caso de Uso “Eliminar Clase”
Descripción En este caso de uso, el diseñador 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 también se eliminarán.
Precondiciones La clase tiene que estar en el diagrama para que pueda eliminarse.
Flujo de eventos Flujo básico
El diseñador selecciona una clase de su diagrama.
El diseñador selecciona la opción de eliminar la clase.
El sistema le pregunta si realmente desea eliminar la clase del diagrama.
El diseñador confirma que desea eliminar la clase.
La clase desaparece del diagrama y también cualquier referencia a ella.
Si había relaciones en las que la clase era el origen o el destino, también se eliminarán junto con la clase.
Flujo alternativo
El diseñador se ha equivocado al seleccionar la opción de eliminar la clase.
Cuando el sistema muestra el mensaje para que el usuario confirme si desea eliminar la clase, éste deniega la opción.
El mensaje desaparece y la clase sigue estando como antes.
Poscondiciones La clase ha dejado de existir en el sistema, por lo que no podrán hacerse referencias a ella. Las relaciones en las que la clase estuviera implicada se eliminarán junto a la clase.
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Eliminar Relación Tabla 3-2. Caso de uso “Eliminar Clase”
Caso de Uso “Consultar Clase”
Descripción En este caso de uso, el diseñador puede visualizar el identificador y nombre de la clase, al igual que los atributos y métodos que tiene asociados. Puesto que la representación gráfica de una clase está representada con un cuadrado con tres secciones, dependiendo de la sección 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 mínima, cardinalidad máxima y nivel de acceso del atributo (friendly, private, protected, public). En la parte de abajo aparecen los métodos, y sus propiedades son identificador, nombre, valor devuelto (void, boolean, date, int, float, double, string), nivel de acceso del método (friendly, private, protected, public) y parámetros que se le pasan.
Los identificadores de las clases, de los atributos y de los métodos son valores que asigna el sistema automáticamente a las clases, atributos o métodos respectivamente en el momento en que estos se añaden al diagrama. Estos valores no podrán 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 están los atributos relacionados con esa clase, y en la parte de abajo están los métodos.
Flujo de eventos Flujo básico
El diseñador selecciona una de las clases del diagrama.
Si el diseñador selecciona la parte de arriba del cuadro que representa la clase, se mostrarán las propiedades de la clase.
Si el diseñador selecciona uno de los atributos, situados en la parte central del cuadro que representa la clase, se mostrarán las propiedades de ese atributo.
Si el diseñador selecciona uno de los métodos, situados en la parte de abajo del cuadro que representa la clase, se mostrarán las propiedades del método.
Flujo alternativo
Si no hay ningún atributo asignado a la clase seleccionada, en el momento en el que el diseñador selecciona esta parte, se crea un nuevo atributo y se visualizarán sus propiedades, que inicialmente estarán todas en blanco, excepto el identificador, que será el que le haya otorgado el sistema y no podrá ser modificado.
Si no hay ningún método asignado a la clase seleccionada, en el momento en el que el diseñador selecciona esta parte, se crea un nuevo método y se visualizarán sus propiedades, que inicialmente estarán 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 ningún atributo / método asignado a la clase seleccionada, en el momento en el que el diseñador selecciona esta parte, se crea un nuevo atributo / método, y se abre la ventana donde aparecen sus propiedades, que inicialmente estarán todas en blanco y el diseñador podrá modificarlas en la ventana que se abre. De la misma manera, al igual que se puede seleccionar uno de los atributos o métodos existentes para ver sus propiedades, también se puede añadir uno nuevo.
Relaciones Actores Diseñador
Inclusiones Es utilizado por “Modificar Clase”
Extensiones Tabla 3-3. Caso de uso “Consultar Clase”
Caso de Uso “Modificar Clase”
Descripción En este caso de uso, el usuario puede modificar el nombre de la clase. También podrá añadir nuevos atributos y métodos, eliminarlos y cambiar sus propiedades.
Precondiciones
El diseñador ha consultado la clase y tiene visibles las propiedades de la clase o de sus atributos o métodos. Como este caso de uso tiene varias partes, dependiendo de la que se vaya a usar, deberán darse unas precondiciones u otras. Si se desea modificar el nombre de la clase, se deberá tener visible las características de la clase; si se desea cambiar las propiedades de un atributo, serán estas las que deberán estar visibles; si lo que se desea variar son las propiedades de un método, serán las propiedades de este las que deberán estar a la vista. Si se desea añadir o eliminar un atributo o un método, no será necesario utilizar previamente el caso de uso “consultar clase”.
Flujo de eventos Flujo básico
El diseñador selecciona la propiedad que desea modificar de entre los campos existentes para la clase, atributo o método seleccionado.
Para las propiedades de la clase, el diseñador 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 diseñador 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 métodos, el diseñador elegirá una de las opciones posibles de entre la lista que se ofrece para los casos de tipo devuelto y nivel de acceso del método. En el resto de propiedades escribirá su valor en el campo correspondiente.
Se guardarán automáticamente los cambios realizados en cualquiera de las propiedades y se visualizarán en la representación gráfica de la clase.
Flujo alternativo
Si el usuario desea añadir 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 mostrarán 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 opción de eliminarlo de la clase. El atributo desaparecerá con las características que conlleve.
Si el usuario desea añadir un método a una clase, seleccionará la parte de los métodos, dentro de la clase. El sistema creará un nuevo método para esta clase, al que asignará un identificador único y se mostrarán sus propiedades para que el usuario pueda dar los datos que le interesen.
Si el usuario desea eliminar un método de la clase, seleccionará este método e indicará la opción de eliminarlo de la clase. El método desaparecerá con las características que conlleve.
Poscondiciones En el cuadro que representa la clase aparecen los nombres de la clase, de los atributos y de los métodos, cada uno en su lugar correspondiente. Para cada atributo aparecerá su nivel de acceso, su tipo del atributo y su nombre. Para cada método aparecerá su nivel de acceso, el tipo que devuelve este método, su nombre y los parámetros que recibe entre paréntesis y escritos de la misma manera que lo hizo el usuario. Cada atributo y cada método estarán en una línea distinta dentro de la parte correspondiente en la clase y terminarán con un punto y coma.
Excepciones Los identificadores de clase, de atributo y de método no pueden modificarse, son datos que asigna el sistema automáticamente 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 válido para la clase.
Relaciones Actores Diseñador
Inclusiones Utiliza “Consultar Clase”
Extensiones Tabla 3-4. Caso de uso “Modificar Clase”
Caso de Uso “Añadir Relación”
Descripción En este caso de uso, el diseñador establece una relación entre dos de las clases existentes en el diagrama. Otra alternativa es que se establezca una relación entre una misma clase, aunque este caso no tendrá mucho sentido dependiendo del tipo de relación, esta opción está incluida entre las posibles y será elección del diseñador utilizarla o no. Las relaciones podrán ser de varios tipos: de dependencia, de generalización, de asociación, de agregación y de composición. Cada tipo de relación se representa de distinta manera, siguiendo el formato establecido en el UML.
Precondiciones Las clases deben estar incluidas en el diagrama para poder añadir la relación entre ellas.
Flujo de eventos Flujo básico
El diseñador selecciona el tipo de relación que quiere añadir al diagrama.
El diseñador selecciona la primera clase, que será el origen de la relación.
El diseñador selecciona la segunda clase, que será el destino de la relación.
La relación entre las dos clases indicadas aparece dibujada en el diagrama.
Flujo alternativo
Si el diseñador necesita una relación dentro de la misma clase, selecciona dos veces la misma clase: como origen y como destino.
Se incluye en el diagrama una relación sobre la misma clase.
Poscondiciones La nueva relación lleva asociado un identificador único dentro del diagrama de clases que el sistema le asignará en el momento de su creación. Además de este, otros campos de las propiedades que tiene la relación las fijará el sistema. Estos campos serán las clase origen y destino y el role de cada una de ellas. Sus valores no podrán ser modificados por el usuario. El diseñador podrá modificar el resto de valores que lleva asociados la relación.
Excepciones Entre dos clases determinadas podrá haber varias relaciones siempre que estas sean de distinto tipo. De esta forma, si ya existe una relación 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 Diseñador
Inclusiones
Extensiones Utilizar Patrón Tabla 3-5. Caso de uso “Añadir Relación”
Caso de Uso “Eliminar Relación”
Descripción En este caso de uso, el diseñador elimina una relación de las existentes en el diagrama de clases.
Precondiciones
Flujo de eventos
Flujo básico
El diseñador selecciona una determinada relación representada en el diagrama de clases.
El diseñador selecciona la opción de eliminar la relación.
El sistema le pregunta si realmente desea eliminar la relación del diagrama.
El diseñador confirma que desea eliminar la relación.
La relación desaparece del diagrama.
Flujo alternativo
El diseñador deniega que desee eliminar la relación.
El mensaje desaparece y la clase sigue estando como antes.
Poscondiciones La relación deja de existir en el diagrama y las clases afectadas pierden la dependencia que las unía.
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Tabla 3-6. Caso de uso “Eliminar Relación”
Caso de Uso “Consultar Relación”
Descripción En este caso de uso, el diseñador consulta los datos concernientes a la relación marcada. Dependiendo del tipo de relación que sea, las propiedades que se tendrán serán unas u otras. De esta manera, si la relación es de asociación, de agregación o de composición, los
datos que se podrán consultar asociados a la relación son el identificador y nombre de la relación, los identificadores de las clases origen y destino y los roles que tienen en la relación y la cardinalidad en cada extremo de la relación. Si la relación es de dependencia, se podrán consultar el identificador y el nombre de la relación, los identificadores de las clases origen y destino, el role de cada una de las clases y la cardinalidad en cada extremo de la relación. Si la relación es de generalización, solamente se guardarán los campos de identificador y nombre de la relación, los identificadores de las clases origen y destino y el role que tiene la clase origen respecto a la destino.
Precondiciones La relación que se pretende consultar ha sido establecida con anterioridad en el diagrama.
Flujo de eventos Flujo básico
El diseñador selecciona la relación de la cual desea consultar los datos.
El diseñador selecciona la opción de visualizar las propiedades asociadas a la relación marcada.
El sistema muestra los campos asociados a las propiedades de la relación elegida y sus valores correspondientes.
Flujo alternativo
Poscondiciones
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Tabla 3-7. Caso de uso “Consultar Relación”
Caso de Uso “Modificar Relación”
Descripción En este caso de uso, el diseñador completa o modifica los datos que lleva asociados una relación 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 relación ha sido establecida en el diagrama de clases y están visibles las propiedades de esta.
Flujo de eventos Flujo básico
El diseñador selecciona la propiedad de la relación que desea modificar.
El diseñador podrá otorgar libremente un nombre a la relación.
El diseñador 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 relación.
Flujo alternativo
En caso de que la relación sea de generalización, el usuario solo podrá modificar el nombre, ya que esta relación no tendrá definidos los campos de cardinalidad.
Solo en caso de que la relación sea de dependencia, además de los campos comentados, el usuario podrá modificar los campos de instanciación para cada una de las clases “roleAInstantiedCard”, ya que esta propiedad es particular de este tipo de relación.
Poscondiciones Los valores otorgados a cada propiedad modificada se guardan automáticamente. El nombre de la relación aparecerá en el diagrama, sobre la relación y en la parte central. La multiplicidad de cada clase que une la relación se verá a cada lado de la clase que afecta.
Excepciones Los campos de identificador de la relación, 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 función de la manera en que el diseñador ha creado la relación en el diagrama.
Relaciones Actores Diseñador
Inclusiones
Extensiones Tabla 3-8. Caso de uso “Modificar Relación”
Caso de Uso “Utilizar Patrón”
Descripción En este caso de uso, el diseñador utiliza uno de los patrones existentes para añadirlo en su diagrama de clases. Para ello buscará el nombre del patrón 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á opción a sustituir las clases de las que se compone el patrón por las que ya tiene representadas en su diagrama. En este caso, la clase que se sustituye pasará a tener las características y relaciones asociadas que tiene la del patrón. En caso de que no sustituya una clase, se añadirá una nueva al diagrama, con las características que tenga en el patrón. En este caso de uso se añaden al diagrama tanto las clases como las relaciones implicadas en el patrón seleccionado.
Precondiciones
Flujo de eventos Flujo básico
El diseñador selecciona el nombre del patrón que quiere utilizar entre los que hay en el árbol, que serán los que están disponibles en el repositorio de patrones.
El diseñador arrastra el patrón 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 patrón y permite, para cada una de ellas, asociarla con alguna de las clases que hay en el diagrama de clases en ese momento.
El diseñador selecciona una clase de las ya existentes para ser sustituida por la del patrón.
El diseñador acepta y se cierra la ventana.
El patrón se dibuja en el área del diagrama.
De forma similar a como estaban en el patrón, se añadirán las clases y relaciones entre ellas.
Las clases sustituidas tendrán las relaciones que tenían las originales en el patrón.
Las clases que no han sido sustituidas, además de las relaciones en las que están implicadas, incluirán las mismas propiedades, atributos y métodos que las del patrón.
Flujo alternativo
Si antes de arrastrar el patrón, no había 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 patrón por las existentes, independientemente de lo que el diseñador hubiera seleccionado.
Poscondiciones
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Tabla 3-9. Caso de uso “Utilizar Patrón”
Caso de Uso “Añadir Patrón”
Descripción En este caso de uso, el usuario añade un nuevo patrón al repositorio para que luego pueda utilizarlo al igual que los patrones de colaboración proporcionados. El patrón añadido puede pertenecer a una colección reconocida o ser propio del diseñador. Para añadir el patrón, el diseñador 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 básico
El diseñador dibuja el diagrama de clases correspondiente al patrón que quiere añadir, utilizando para ello los casos de uso relativos a la elaboración de diagramas de clases.
Una vez completo el diagrama, el diseñador selecciona la opción 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 estén todos los patrones.
El diseñador da un nombre al patrón y lo guarda.
El diseñador cierra la ventana.
Flujo alternativo
Poscondiciones El diagrama guardado en el directorio donde están los patrones podrá ser añadido, como otro patrón más, en el diagrama de clases.
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Tabla 3-10. Caso de uso “Añadir Patrón”
Caso de Uso “Eliminar Patrón”
Descripción En este caso de uso, el diseñador elimina uno de los patrones existentes del repositorio.
Precondiciones Este caso de uso se lleva a cabo sin necesidad de estar ejecutándose la aplicación, ya que su eliminación se hace desde el directorio donde está ubicado su fichero asociado.
Flujo de eventos Flujo básico
El usuario va al directorio donde están guardados todos los patrones.
El usuario selecciona el fichero correspondiente al patrón que desea eliminar y lo elimina.
Flujo alternativo
Poscondiciones El patrón eliminado ya no saldrá en el árbol de patrones disponibles ni podrá ser utilizado por la aplicación.
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Tabla 3-11. Caso de uso “Eliminar Patrón”
Caso de Uso “Modificar Patrón”
Descripción En este caso de uso, el diseñador modifica un patrón existente en el repositorio.
Precondiciones El patrón está incluido con anterioridad en el repositorio de los patrones disponibles.
Flujo de eventos Flujo básico
El diagrama de clases utilizado está vacío.
El diseñador realiza el caso de uso “Utilizar Patrón” con el patrón que desea modificar.
El diseñador modifica el diagrama de clases asociado al patrón utilizando para ello los casos de uso necesarios relativos a la elaboración de diagramas de clases.
Una vez completo el diagrama, el diseñador selecciona la opción 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 estén todos los patrones.
El diseñador selecciona el patrón que abrió anteriormente para modificarlo y lo guarda.
El diseñador cierra la ventana.
Flujo alternativo
Para abrir el diagrama de clases correspondiente al patrón que se quiere modificar, también se puede abrir directamente:
El diseñador selecciona la opción de abrir un diagrama de clases existente.
El diseñador indica el directorio donde está el repositorio de los patrones y el nombre del fichero que tiene el patrón que desea modificar y abre su diagrama de clases asociado.
A continuación, el diseñador puede modificar el diagrama de clases y seguir con el flujo básico de ejecución para terminar de modificar el patrón.
Poscondiciones El patrón con un determinado nombre que estará disponible será el que tenga los últimos cambios, es decir, al guardarlo con el mismo nombre. La versión anterior del patrón se pierde y es sobrescrito por el diagrama modificado.
Excepciones
Relaciones Actores Diseñador
Inclusiones
Extensiones Tabla 3-12. Caso de uso “Modificar Patrón”
Para la especificación de los requisitos que se acaba de realizar se ha tenido en cuenta
únicamente la funcionalidad que se considera más 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 diseñador, pero que no se ha considerado en
esta especificación por tratarse de casos de uso que no reflejan la esencia que se quiere resaltar
de esta aplicación, como es lo relacionado con la gestión de los patrones y la elaboración de
diagramas de clases.
3.2.3 Requisitos no funcionales
El sistema desarrollado ha de ser fácil de usar. Está especialmente dedicado a
desarrolladores y estudiantes, con experiencia en informática y que estarán 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 carecerán de práctica. Por eso se pretende que su diseño no ofrezca ninguna
dificultad para su utilización, ya que con ella se pretende facilitarles las cosas, en lugar de
entorpecerlas con una herramienta que no sepan cómo 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 ofertarán los patrones de colaboración que pueden
utilizarse, y en la otra habrá un panel para la especificación de diagramas de clases.
En la parte superior de la interfaz se dispondrá de un menú con las acciones que
pueden hacerse. Cada acción tendrá un nombre significativo y llevará asociado un icono cuya
forma es característica 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 añadir clases y distintos
tipos de relaciones sobre el diagrama, con dibujos en sus iconos similares a los que se obtienen
a través de ellos. Además, cuando se pase el puntero del ratón por cada uno de los botones,
aparecerá un texto con la función que tiene.
También se cuidará y se incluirá el control de errores que puedan producirse durante
su ejecución y se le advertirá al usuario si está haciendo algo no permitido, o si algo no
funciona como debería. Para ello, se considerará la situación 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 patrón que se
desee incorporar al diagrama. En estos dos casos, el sistema mostrará un mensaje de error
avisando de la excepción producida.
Otra característica que se tendrá en cuenta en la implementación 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 patrón 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
todavía no ha sido incorporada se le añadirá, directamente, un número que la haga única. De
manera que cuando el patrón se represente en el diagrama ya esté correctamente, haciéndose
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 través de un
mensaje indicando la situación y pidiendo al usuario que de otro nombre que sea válido 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 tenía anteriormente, que será el asignado inicialmente por el sistema, si el
usuario no lo ha modificado anteriormente.
Asimismo, cuando el usuario añada 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 número que irá incrementando en función de las clases que existan en el
diagrama.
Para comprobar los nombres no se distinguirá entre mayúsculas y minúsculas y se
eliminarán los espacios antes del primer carácter del nombre y después del último.
Las clases, al igual que los atributos y métodos que estas tengan, llevarán asignados un
identificador, que el sistema les proporcionará desde el momento de su creación hasta que se
eliminen del diagrama. Estos identificadores serán los que se tendrán en cuenta a la hora de
trabajar con estos elementos y no podrán ser modificados en ningún momento.
El identificador de una clase será una cadena de caracteres que comience por “idc”,
seguido del número de clases que se hayan añadido en el diagrama en el momento de su
creación. En el momento de añadir 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 número de atributos
que se le hayan incluido a la clase hasta ese momento. De igual forma será asignado el
identificador de un método, con la excepción de que en lugar de una “a” después del
identificador de la clase, en este caso llevará una “m”, para distinguir entre atributos y
métodos.
Si una clase hubiese sido incluida y posteriormente se hubiera borrado, su identificador
ya no volvería a utilizarse. Lo mismo pasaría con los atributos y los métodos, que los
identificadores no se repetirán en el caso de que se eliminen de la clase.
De forma similar, las relaciones también llevarán asociado un identificador que el
sistema les proporciona de forma automática en el momento de su inclusión en el diagrama.
En este caso será un valor que comenzará por “idr”, seguido del número de relaciones que se
han añadido en el diagrama hasta ese momento. Igual que en los casos anteriores, los
identificadores no se repetirán, ni en el caso de que se elimine la relación del diagrama.
Además del identificador, el sistema dará valores a las clases origen y destino de la relación, en
función de las clases que el usuario haya unido, y a los roles de estas, en función del tipo de
relación del que se trate.
Por otro lado, cuando el usuario seleccione la opción de eliminar una clase o una
relación, el sistema mostrará un mensaje que le preguntará si realmente quiere eliminarla del
diagrama, pudiendo el usuario revocar la selección, sin que realmente llegue a eliminarse, o
seguir adelante y borrarla del diagrama.
Los mensajes que el sistema muestra al usuario con información o avisos estarán
convenientemente cuidados y se mostrarán en el momento justo que el usuario los necesite.
Además, 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 análisis del modelado conceptual que se seguirá en el
momento de realizar el diseño de la aplicación.
Una visión básica de conjunto de la arquitectura del sistema es la ofrecida en la Figura
3-4, donde puede observarse que, básicamente, la aplicación tiene tres módulos diferenciados
por su funcionalidad y comunicados entre sí mediante las relaciones que existen ente los
distintos componentes. Por un lado está la gestión de patrones, por otro lado el editor de
clases y, entre estas dos partes está la aplicación en si, que es la que une las dos funcionalidades
incluyendo características propias necesarias para la interacción entre las partes.
Figura 3-4. Diagrama de paquetes
Un diseño más elaborado de este modelado conceptual, que será la base para la
elaboración del sistema, se representa mediante el diagrama de la Figura 3-5, en la cuál se ha
incorporado un nuevo módulo a los ya mencionados, que está relacionado con el editor de
clases de la aplicación, y es el encargado de ofrecer unas características y un código XML para
sus elementos.
Por otro lado, relacionado con la gestión de patrones habrá un repositorio con los
patrones de colaboración, en un principio. Aunque, como se ha comentado en otras
ocasiones, este repositorio puede ser modificado por el usuario, haciéndolo más afín a sus
necesidades.
Figura 3-5. Diagrama de clases de la aplicación
Para entender el diagrama de clases de la aplicación, 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 aplicación, sobre las que se
apoya el resto. Es la base para las demás clases del sistema.
Estará compuesto por las clases:
JInternalFrame: Es la clase que contiene la interfaz principal de la aplicación. Será el
soporte para la clase MyInternalFrame, que a su vez, contendrá las clases más
significativas de la aplicación. La interfaz principal tendrá un menú desde el que se
podrán desplegar nuevas clases MyInternalFrame, lo cuál permitirá trabajar sobre más 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 utilización
en el diagrama.
JTreeFrame: Esta clase es la que corresponde al árbol de los patrones y sobre ella se
sostiene lo relativo a la gestión de patrones.
ClassFrame: Esta clase sirve de base para todo el soporte en lo referente a la edición
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 añadirse al diagrama,
comunicándose 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. Además, dan la opción de sustituir
clases de los patrones por clases incluidas ya en el diagrama, a través de un menú intermedio.
Así mismo, este paquete está relacionado con el directorio donde están almacenados
los ficheros de los patrones, para poder acceder a ellos, mostrar los nombres y, en el caso de
que el usuario lo seleccione, añadir 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 están los patrones
disponibles que el usuario puede utilizar. Se hace un recorrido por el directorio donde
están ubicados los patrones y va rellenando un árbol con los nombres de los ficheros
donde están almacenados los patrones que encuentra. Desde este árbol, el usuario
podrá seleccionar un patrón y, a través de la clase TransferableDataItem, arrastrarlo
hasta el diagrama, incorporándolo así al conjunto de sus clases.
TransferableDataItem: Es la clase que permite arrastrar un patrón al diagrama de
clases. Para ello se selecciona el nombre del patrón del árbol de patrones y lo que se
arrastra es el fichero al que corresponde ese patrón, de manera que al dibujar el patrón
en el diagrama, accederá al fichero al que se hace referencia, a través del patrón 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 patrón por una de
las existentes, en el momento de dibujar el patrón se hará el cambio.
3.2.4.3 El paquete “Editor de Clases”
Este paquete va a tener las clases necesarias para la edición de los diagramas de clases.
Como base habrá una paleta de dibujo, sobre la que se podrán dibujar clases, pudiendo tener
atributos y métodos asociadas. También podrán dibujarse relaciones entre dos clases, que
podrán 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 más significativas de este paquete son las que se indican a continuación:
Paleta: Es la clase a través de la cuál se relaciona el paquete de edición de clases con el
de la aplicación y con el de la gestión de patrones. A su vez, es la que contendrá las
clases que permiten la edición de los diagramas, siendo el fondo sobre el que sustentan
el resto de clases de este paquete. Esta clase es probablemente la más importante del
paquete, conteniendo un panel donde se dibujarán 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 más funcional su edición.
Clase: Es la que contiene información sobre cada clase de las que se dibuja en el
diagrama. Con ella se gestionan las características de cada clase, su identificador, su
nombre, sus atributos, sus métodos, las relaciones a las que está unida y las
dimensiones dentro del diagrama, además de la funcionalidad necesaria para
relacionarse con el paquete de las propiedades.
Atributos: Se encarga de la gestión de los atributos dentro de las clases que están
incluidas en el diagrama. Así llevará un control del número de atributos que tiene
asignada una clase, sus nombres y tipo.
Métodos: De forma similar a la anterior, es la encargada de gestionar los atributos que
hay en las clases.
Relación: Controla el dibujado y la información de las relaciones en el diagrama.
Origen y Destino: Hace referencia a las clases que actúan como origen y destino,
respectivamente, dentro de las propiedades de las relaciones.
Generalización, AdHoc y Agregación: 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 añade algunas características al diagrama de clases. Para ello, tiene dos
clases básicas asociadas:
Propiedades: En esta clase se incluyen características que tendrán las clases y las
relaciones que se incluyan en el diagrama de clases modelado.
ViewCode: Esta clase representará el código 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 interactúan para llevar a cabo cada una de
las actividades, se representarán los diagramas de secuencia correspondientes a cada una de
estas acciones.
Probablemente, la actividad más importante que cabe destacar en esta sección es la
secuencia de acciones que se llevan a cabo para incorporar un patrón al diagrama de clases en
uso.
A la hora de trabajar con patrones, se podrán tener dos situaciones: que las clases que
se quieren insertar del patrón estén en el diagrama o que todavía no hayan sido añadidas. Para
cada uno de los casos se analizará a continuación las acciones que habrá que realizar para
incorporar el patrón al panel en el que las clases están siendo dibujadas.
En el caso de insertar un patrón sustituyendo sus clases, la situación es que se tienen ya
dibujadas una serie de clases y posibles relaciones en el diagrama. Se selecciona un patrón para
arrastrarlo al panel, pero las clases que se quieren del patrón ya están en el diagrama de clases,
de forma que se quiere sustituir alguna de las clases del patrón por otras de las que ya se han
incluido anteriormente. De esta forma, el diagrama de secuencia correspondiente a este
escenario, sería el representado en la Figura 3-6.
Figura 3-6. Diagrama de secuencia para insertar patrón sustituyendo clases
En el caso de insertar un patrón sin sustituir sus clases, se arrastra un patrón desde el
árbol hasta el panel de dibujo y se quiere que las clases sean las mismas que tiene el patrón. Es
decir, se pretende dejar las clases que ya hay dibujadas como están y añadir el patrón
seleccionado tal cual.
Para este escenario, las acciones que habría 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 patrón sin sustituir clases
En este diagrama se ha tenido en cuenta que ya había alguna clase en el panel de dibujo
cuando se ha arrastrado el patrón. De no ser así, no aparecería el mensaje que se muestra al
usuario para que pueda sustituir las clases del patrón por las ya representadas. Las demás
acciones que se llevarían a cabo son las que se representan en este diagrama, con la única
excepción que se ha comentado. Cuando se reconoce que no hay clases dibujadas en el
diagrama, directamente se dibuja el patrón que el diseñador ha arrastrado hasta el panel.
3.3 Descripción y almacenamiento de los patrones de colaboración en XML
Se ha querido proporcionar un repositorio donde tener almacenados los patrones de
colaboración, en un principio, y, posteriormente, todos los patrones que el usuario añada o
modifique. Este repositorio estará en el directorio patrones que acompaña al ejecutable
facilitado en este proyecto final de carrera.
Los patrones se almacenaran en ficheros, dentro del directorio especificado, utilizando
para su especificación el lenguaje UsiXML.
UsiXML (User Interface eXtensible Markup Language) (http://www.usixml.org) es un
lenguaje de descripción de interfaces de usuario, es declarativo y captura la esencia de lo que es
una interfaz de usuario independiente de las características físicas. Está basado en XML.
Puede describir interfaces para múltiples contextos de uso, con independencia del dispositivo,
de la plataforma y de la modalidad de interacción. Está basado en los principios de modelado
MDA. Además, UsiXML permite la reutilización 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 simplificación y adaptación del SGML y permite definir la gramática de
lenguajes específicos. Por lo tanto, XML es una manera de definir lenguajes para diferentes
necesidades.
XML, además de su aplicación en Internet, se propone como un estándar para el
intercambio de información estructurada entre diferentes plataformas.
XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y
la hacen mucho más 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
información de una manera segura, fiable y fácil.
Por todas estas razones se he elegido este lenguaje para la definición de los patrones.
Para la especificación 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 diseño que se
ha seguido es el recogido en la Figura 3-8, donde se muestran, además de las clases, los
atributos y los métodos 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 representación de diagramas
de clases del proyecto, hecho que es lógico si se tiene en cuenta que los patrones son, en
definitiva, diagramas de clases que podemos diseñar 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 mostrarán en el caso que el usuario edite una clase, un atributo, un método, etc.
Además, estas propiedades también se verán reflejadas en el código XML asociado al
diagrama, para poder posteriormente recuperar el diagrama a través de este código.
Como ejemplo, se verá el patrón Actor-Role, descrito en el capítulo anterior. Se
recuerda que la apariencia que tiene este patrón es la reflejada en la Figura 3-9.
Figura 3-9. Patrón Actor-Role
La descripción en UsiXML de este patrón sería 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 descripción de los patrones no se han añadido atributos ni métodos adicionales a
las clases para que el usuario pueda adaptarlos a sus necesidades, añadiendo él mismo los que
crea más convenientes.
3.4 Descripción del entorno elaborado
En este apartado se analizará el entorno de la aplicación y se distinguirán las opciones
posibles para su ejecución. 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 irán añadiendo vistas de la aplicación en los distintos casos y se
explicará cómo llegar a cada situación.
La interfaz principal de la aplicación está compuesta por:
una barra de título, donde aparece el nombre de la aplicación
una barra de menús, 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 diseñarse el diagrama de clases.
Tanto la ventana principal como cada una de las dos ventanas internas pueden
minimizarse, maximizarse y cerrarse. Estas opciones vienen señaladas con un dibujo intuitivo
en el botón correspondiente
Más adelante se analizará en detalle cada una de las distintas partes de las que se
compone esta aplicación, explicando cómo 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 aplicación
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 colaboración, de la colección de (Nicola et al., 2001), aunque en un futuro esta
lista de patrones puede completarse y hacerse más compleja con los patrones que el diseñador
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 diseñador creará su
diagrama. En la parte superior dispone de una barra de herramientas a través de la cuál podrá
ir diseñando el diagrama, con la introducción de las clases o relaciones que necesite, sin más
que seleccionar la clase o relación con el ratón, y situar posteriormente el puntero en la zona
del panel donde quiere añadir la figura.
La barra de herramientas del panel consta de unos iconos bastante intuitivos, cuya
funcionalidad se describe brevemente al pasar el ratón por sus iconos. En la tabla 3-14 se
identifican estos iconos y se da una breve explicación de su funcionalidad.
Figura Nombre Descripción
Puntero en modo selección
Selecciona la clase para añadir al diagrama
Selecciona la relación de dependencia
Selecciona la relación de generalización
Selecciona la relación de asociación
Selecciona la relación de agregación
Selecciona la relación de composición
Tabla 3-14. Iconos de la barra de herramientas del panel
Estos iconos se utilizan para el diseño del diagrama. Al posicionar el puntero del ratón
sobre estos iconos, aparece una breve explicación emergente de este botón, que nos indica su
significado. Además, se indica una combinación de teclas cuyo uso tiene la misma acción que
si se pulsa este botón.
El modelado del diagrama de clases se hace según 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 añadir una clase al diagrama, habrá que seleccionar el botón “class” y a
continuación indicar con el ratón 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 número de
clases que se han añadido al diagrama hasta el momento en que se ha puesto esta clase.
La representación de una clase será un recuadro que consta de tres partes: en la parte
superior se verá el nombre de la clase. Además, si una clase determinada estaba en el diagrama
y, al arrastrar un nuevo patrón, se ha sustituido esta clase por una de las del patrón, 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 patrón que sustituye.
En la parte central aparecerán los atributos que tiene asociados la clase. Cada atributo
aparecerá en una línea 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 mostrarán los métodos que tenga asociados la clase,
de modo que se verá el modo de acceso, el tipo que devuelve el método y su nombre, seguido
de los parámetros que haya que pasársele, entre paréntesis, y punto y coma. Igual que en el
caso de los atributos, los métodos se mostrarán cada uno en una línea distinta dentro de la
clase.
Figura 3-11. Partes de una clase
Para modificar el nombre de una clase, se hará clic con botón derecho del ratón sobre
la parte de arriba en la representación 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 características de la clase, que serán 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. Características 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 válido, y que no esté repetido en el diagrama.
Nombre de clase
<< Estereotipo>>
Atributos de la clase
Métodos de la clase
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 válido
a la clase. En el caso de que se cierre esta ventana sin que el nombre que se le haya indicado
sea válido, la clase seguirá llamándose “idc0”.
Figura 3-13. Cambio de nombre no permitido para una clase
Por otro lado, si se intenta modificar el nombre de una clase, asignándole otro nombre
que ya está siendo utilizado por alguna clase en el diagrama, el sistema le informará de la
situación 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 válido.
De no ser así, se mantendrá el nombre que tenía asignado la clase antes de intentar
cambiárselo.
Para comprobar que no haya nombres repetidos, no se tendrá en cuenta si está en
mayúsculas o minúsculas 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 opción de eliminar la clase, el sistema preguntará al
usuario si realmente quiere seguir adelante con esa opción porque de ser así no solo se
eliminará la clase, sino que también se eliminarán del diagrama las relaciones que tengan a esta
clase como origen o como destino. Además, no habrá forma de recuperarlas una vez
eliminadas, sin otra opción que volver a incorporarlas al diagrama desde el principio.
Figura 3-15. Mensaje de confirmación para eliminar una clase
Para añadir un nuevo atributo a al clase seleccionada, se hará clic con el botón
izquierdo del ratón 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 aplicación asigna
automáticamente en el momento de añadir 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 número de atributos que se le han añadido a la clase hasta el
momento. Además, 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 mínima del atributo, donde el usuario podrá darle un valor entre 0,
0..1, 0..n, 1, 1..n, n o dejarlo sin especificar
cardinalidad máxima 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 botón izquierdo del
ratón sobre ese atributo en lugar del dibujo que se ha indicado antes, o bien pinchando con el
botón derecho sobre el atributo, entonces saldrá un menú donde habrá que seleccionar la
opción “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
podrán cambiar las propiedades del atributo seleccionado.
Figura 3-17. Menú de acciones para un atributo
Si lo que se quiere añadir es un nuevo método a una clase, se hará clic con el botón
izquierdo del ratón sobre el dibujo que aparece en la parte inferior, destinada a los métodos,
dentro de la clase a la que se le desee incorporar el nuevo método. De forma semejante al caso
de los atributos, se abre una ventana que permite dar valores a las propiedades del método.
Figura 3-18. Propiedades de un método
La primera propiedad de un método, cuyo valor asigna la aplicación automáticamente
en el momento de añadirlo, es el identificador. Su valor es un string que empieza por el
identificador de la clase, seguido de una “m” y el número de métodos que se han añadido a la
clase anteriormente, y no podrá ser modificado. Conjuntamente, cada método tendrá otras
propiedades que el usuario podrá modificar:
el nombre del método, para el cuál, el usuario podrá asignar cualquier cadena
el tipo del valor que devuelve el método, 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 método, donde el usuario podrá elegir un valor entre friendly,
private, protected y public
parámetros: este campo lo podrá rellenar el usuario como desee y en la clases se
verá este valor entre paréntesis, al lado del nombre del método
Para modificar los valores de las propiedades de un método, se hará clic con el botón
izquierdo del ratón sobre el método deseado, en lugar del dibujo que se ha comentado, con el
fin de abrir nuevamente la ventana de las propiedades del método con los valores dados hasta
ese momento. Otra forma de acceder a esta ventana es haciendo clic con el botón derecho del
ratón sobre el método deseado, y seleccionando “edit method” del menú que se despliega. Aquí
podrán modificarse estos valores nuevamente.
Figura 3-19. Menú de acciones para un método
La segunda opción de las posibles que aparecen al hacer clic con el botón derecho del
ratón sobre un atributo o sobre un método, es “delete attribute” o “delete method”,
respectivamente. Si el usuario selecciona esta opción, el sistema mostrará un mensaje
informativo, similar al que abrirá cuando se selecciona la opción de eliminar una clase, para
que se confirme si realmente se desea eliminar el atributo o método seleccionado. En este caso
tendrá dos opciones: confirmar o denegar. Si se pulsa “si”, se borrará el atributo o método
seleccionado y si se pulsa “no”, se quedará como estaba.
Las siguientes opciones que aparecen al hacer clic con el botón derecho del ratón
sobre una clase, independientemente de la parte sobre la que se sitúe, afectan a la clase y no
solo a los atributos o los métodos 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 generalización, de
asociación, de agregación o de composición. Según se trate de un tipo relación u otro, tendrá
un aspecto distinto. En los botones que añaden 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 añadir una relación al diagrama, primero se seleccionará el botón perteneciente al
tipo de relación que se quiere, en la barra de herramientas situada en la parte superior del panel
de dibujo. A continuación se marcará con el ratón la clase que se quiere como origen de la
relación y después la clase que se quiere que sea el destino. De esta manera, se dibuja la
relación entre estas dos clases.
En el momento en que se crea una relación, el sistema le asocia un identificador que el
usuario no podrá modificar. Este dato será un string que empezará por “idr”, seguido del
número de relaciones que se han añadido 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, además del identificador,
los siguientes:
nombre de la relación: es un dato de tipo string que podrá proporcionar el usuario.
Su valor aparecerá en el centro de la línea que representa gráficamente la relación
en el diagrama.
identificador de la clase origen de la relación. Su valor lo asigna directamente la
aplicación a la relación cuando esta se crea, tendiendo en cuenta la primera clase
que conecta.
identificador de la clase destino de la relación. Al igual que en el anterior, será un
valor que proporciona la aplicación que en este caso corresponderá con la segunda
clase que una la relación.
Otra propiedad de las relaciones es el role que desempeñan cada clase dentro de la
relación. En todos los tipos de relación 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 aplicación a cada relación en el momento de
añadirla, y variarán teniendo en cuenta la naturaleza de cada relación.
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 relación 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, además 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 relación, en el lado de la clase que corresponda.
Además, si se trata de una relación de dependencia, se añadirán dos campos que
reflejarán roleAInstanciatedCard.
Para ver y poder modificar los valores que tiene una relación asociados se hará clic con
el botón derecho del ratón sobre la relación, saliendo el menú que se muestra en la Figura 3-
21, y a continuación se seleccionará “edit relationship”.
Figura 3-21. Menú de acciones para una relación
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
aplicación. Los valores que vienen dados son los que asigna la herramienta automáticamente 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 podrán ejecutar sobre una relación serán editarla o borrarla. Si se
selecciona la opción de eliminar una relación, el sistema mostrará al usuario un mensaje para
que confirme si realmente desea borrarla del diagrama de forma permanente.
Figura 3-23. Mensaje de confirmación para eliminar una relación
El primer botón que aparece en la barra de herramientas del panel, y el único que
queda por comentar es el de la flecha. Este botón lo que hará es darle al puntero del ratón la
función de seleccionar. Se marcará cuando se tenga seleccionado el de la clase o el de una
relación y el usuario no quiera incorporar esta al diagrama.
La funcionalidad más 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 diseño y la hace más rápida y eficaz.
Para añadir un patrón, se selecciona con el ratón 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 patrón se dibuja directamente, con las clases y
relaciones que se incluyen en él.
Si al arrastrar el patrón 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 patrón
en el lado izquierdo, y en el lado derecho un menú despegable por cada una de las clases del
patrón, con los nombres de las clases que ya están 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 patrón. Así la del patrón será sustituida por la ya existente y debajo de su nombre se
mostrará entre los signos “<<” y “>>” el nombre de la clase del patrón que representa.
Si, por el contrario, el usuario deja seleccionada la opción “ninguno” del menú, y pulsa
“Ok”, se añadirán nuevas clases para representar el patrón arrastrado. Ocurrirá lo mismo si
después de seleccionar cualquier opción en los menús despegables, el usuario pulsa la opción
“Cancel” o cierra la ventana.
Las relaciones del patrón también serán representadas en el diagrama entre las clases
originales del patrón o entre las que el usuario haya elegido como sustitutas de estas. De esta
forma también se verá representado su nombre y la multiplicidad entre las clases vinculadas.
Una restricción dentro de los diagramas es que no va a poder haber más de una
relación del mismo tipo entre dos clases, de manera que si existe una relación determinada
entre dos clases y se intenta añadir una del mismo tipo con las mismas clases origen y destino,
esta segunda relación 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 patrón al diagrama. Puede
observarse la apariencia de la aplicación y el mensaje intermedio para que el usuario pueda
sustituir las clases del patrón por las que ya tiene dibujadas.
Para este caso se supone que hay representada una clase “libro”, con sus atributos y
métodos. En el árbol de patrones donde se indican los patrones que hay disponibles en el
repositorio, se buscaría el patrón “Assembly-Part” y se arrastraría desde este árbol hasta el panel
del diagrama de clases.
A continuación se abrirá una ventana dónde indicará que se seleccionen las clases que
se quieren cambiar. Para cada clase que contiene el patrón se podrá asociar una de las clases
que ya están representadas, para ser sustituidas por estas últimas. En este caso, se sustituirá la
clase “Assembly” del patrón por la clase “libro”, que ya está dibujada en el diagrama.
Al acabar la selección de las clases para la sustitución dentro del patrón, se pulsará el
botón Ok y esta ventana se cerrará.
De esta manera, solo se añadiría una nueva clase al diagrama, que sería la clase “Part”,
perteneciente al patrón, y la relación existente entre ambas. Echo esto, solo faltaría añadir los
atributos o métodos que se deseen a la nueva clase.
Como la clase libro es parte del patrón y ha pasado a desempeñar la función de la clase
“Assembly”, esto se indicará mediante el estereotipo, de manera que la clase a la que sustituye
dentro del patrón aparece debajo del nombre de la propia clase, entre los signos “<<” y
“>>”.
Si más tarde, esta clase volviera a sustituir a otra de un patrón que se añada, el
estereotipo se modificará de forma que siempre tendrá la última clase del patrón que haya
sustituido.
Figura 3-24. Utilizar patrón
En el caso de que haya en el panel una clase con el mismo nombre que alguna de las
contenidas en el patrón que se va a utilizar, y esta segunda clase no es sustituida por ninguna
otra, al representarse en el panel, su nombre se verá modificado de forma que lo haga único en
el diagrama. Para ello se le añadirá un número al valor que ya tiene.
Como ejemplo, puede tenerse en el panel una clase cuyo nombre sea “Actor” y a
continuación, el usuario utiliza el patrón de colaboración “actor-role”, sin sustituir ninguna
clase por otra. El resultado sería el mostrado en la Figura 3-25.
Figura 3-25. Nombres de las clases de los patrones
El color con el que se dibujarán 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 podrían simularse distintos paquetes,
representando las clases que pertenecen a uno u a otro de un color distinto. De igual forma,
podría cambiarse el color a algunas clases que se consideren especiales, dependiendo de las
necesidades o gustos del usuario.
Esta funcionalidad se obtiene mediante la opción “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 botón derecho del ratón sobre cualquier parte de la
clase, apareciendo un menú donde estará incluida esta opción. 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 menús, 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 continuación.
Figura 3-26. Cambio de color de una clase
La elección 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 extensión .usi y con extensión .jpg. Además, también puede
imprimirse.
Si se desea guardar el diagrama en código UsiXML, lo que hará es convertir cada dato
del diagrama en este lenguaje. Para ello se seleccionará de la barra de menú la opción “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 extensión .usi.
También 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 imágenes 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 código 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 código, 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
aplicación, de forma que aparecerá en el panel de dibujo como se había guardado,
manteniendo las mismas clases, relaciones y propiedades.
Habrá dos formas para abrir un archivo con extensión .usi: seleccionando del menú la
opción “File > Open”, o pulsando la combinación de teclas Alt+O. Ambas opciones abrirán
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 vacío, deberá seleccionar del menú
la opción “File” y después “New”, o con la combinación de teclas Alt+N.
Si en el panel actual hay algo dibujado, tanto si se cierra este panel, como si se
selecciona la opción de abrir un archivo existente o un nuevo panel vacío, el sistema
preguntará al usuario si desea guardar el diagrama en el que está y le dará la opción de
seleccionar el directorio y el nombre que desee para ello.
El diagrama dibujado en el panel tiene un código XML asociado, que será similar al
que se guarda con la opción de guardar con extensión .usi y que el usuario puede visualizar en
cualquier momento. Para ello seleccionará del menú la opción “Window > XML”, o pulsará la
combinación de teclas ALT+X. En ambos casos se abrirá una nueva ventana donde aparece el
código 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 explicación
del proceso a seguir para añadir un patrón al diagrama, se obtendría el código mostrado en la
Figura 3-29.
Figura 3-29. Código 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 opción es con la combinación de teclas ALT+P o
ALT+D respectivamente. Estas opciones no estarán disponibles si las ventanas ya están
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 aplicación también 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 aplicación en la opción “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 aplicación.
El “acerca de” de la aplicación puede consultarse en la opción “Help > About us...” del
menú, o con la combinación de teclas ALT+A. Así se abrirá una ventana con información de
la aplicación como la versión y los autores de esta, como se indica en la Figura 3-31.
Figura 3-31. “About us...” de la aplicación
Para cerrar la aplicación puede pulsarse con el ratón en la cruz de la esquina superior
derecha o mediante la opción “File” y “Quit” del menú, o mediante la combinación de teclas
ALT+Q. De esta forma, la ventana principal de la aplicación se cerrará sin más.
3.5 Análisis y discusión
Siguiendo la trayectoria que ha llevado la Ingeniería del Software desde los tiempos de
su aparición, 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 más por las metodologías ágiles. Por eso se considera interesante que existiera algún tipo
de metodología ágil con modelado.
La herramienta propuesta puede ser una buena elección 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 más rápida al estar el diseñador
familiarizado con el término y los distintos patrones que pueden incluirse.
Capítulo 4. Caso de estudio: utilización del entorno facilitado
El tipo de herramienta propuesta en este proyecto final de carrera puede resultar de
gran utilidad en determinadas asignaturas de Ingeniería del Software, en los estudios de
Ingeniería Informática.
Su principal importancia reside en la facilidad con la que puede ser tratado el
modelado del dominio gracias a ella y la fácil inclusión de los patrones en el diagrama. Por eso
se cree que su utilización 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 Descripción del caso de estudio
Para probar la herramienta, se mostrará su utilización para el modelado de un ejemplo
concreto. Para ello se describirá el problema y a continuación se hará el correspondiente
diagrama de clases con la aplicación desarrollada.
De esta forma, se identificarán y utilizarán los patrones de colaboración que se
encuentren en el modelo y se irán 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 continuación. Para ello debe tenerse en cuenta cada una de las
características reseñadas.
Se desea diseñar un modelo de representación de compañías de
autobuses que sea capaz de gestionar las reservas que los clientes de la
compañía deseen realizar sobre los diferentes trayectos que ésta realiza. El
modelo debe cumplir los siguientes requisitos:
Las compañías de autobuses realizan trayectos entre dos ciudades
(origen y destino), con un número, 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 máxima que admiten.
Las personas que participan en el modelo tienen todas: nombre, DNI,
dirección, número de teléfono y edad, y serán empleados o pasajeros.
Los empleados tienen un número de seguridad social y se conoce su
antigüedad en la empresa.
Los pasajeros tienen un código de cliente.
Los autobuses sólo realizan un trayecto y un trayecto sólo lo realiza un
autobús.
Para que un pasajero pueda viajar en un autobús debe hacer una
reserva sobre un determinado trayecto. Las reservas tienen un precio y
un número de asiento en el autobús.
4.2 La especificación gráfica
Para la elaboración 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. Además, habrá que conocer las características que tendrá cada
entidad encontrada, que serán los atributos que habrá de tener la clase. Todos los atributos de
todas las clases serán privados, para que únicamente pueda accederse a ellos a través de los
métodos 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 gestión de esta empresa de autobuses.
Estas acciones serán los métodos que llevará asociados cada una de las clases, los cuales habrá
que identificar.
A continuación se muestran las clases que habrá que considerar en el modelo, junto
con sus atributos y los métodos que llevará asociados cada una de ellas.
COMPAÑÍA: Son cada una de las compañías de autobuses que se contemplan.
Para diferenciarlas entre sí tendrán asociado un atributo que es el nombre de la
compañía. Sus métodos son:
- altaEmpleado(string, string, int): void → da de alta a un nuevo empleado
en la base de datos de la compañía. Necesita como parámetros el nombre,
el DNI y el número 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 compañía. Necesita conocer el nombre y el DNI
del pasajero.
- altaAutobús(string, string, int): void → da de alta en la base de datos un
nuevo autobús que tendrá la compañía a su servicio. Recibe como
parámetros el modelo y la matrícula del nuevo autobús y el número de
plazas del que dispondrá.
- altaTrayecto(string, string, autobús): void → da de alta un nuevo trayecto
que contemplará la compañía. Necesita saber el lugar de origen y de
destino de dicho trayecto y el autobús que lo cubrirá.
- buscarTrayecto(string, string, date) : trayecto → busca en la base de datos
de la compañía un trayecto que cumpla con los requisitos indicados. Coge
como parámetros 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
compañía con estas características.
- addPasajero(pasajero): void → añade un pasajero a los atendidos por la
compañía. Recibe como parámetro dicho pasajero.
- addEmpleado(empleado): void → añade un nuevo empleado contratado
por la compañía. Necesita como parámetro dicho empleado.
- addAutobús(autobús): void → añade, a los que ya tiene la compañía, un
nuevo autobús, el cual necesitará como parámetro.
Para que en el modelo, la clase compañía ofrezca toda esta información descrita,
deberá aparecer como se muestra en la Figura 4-1.
Figura 4-1. Clase compañía
TRAYECTO: Es cada uno de los viajes que ofrecerá la compañía. Cada trayecto
llevará asociado un número, que será el que lo identifique entre el resto de
trayectos existentes. Además, 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 métodos:
- trayecto(): trayecto → crea un nuevo trayecto.
- solicitarPlaza(): reserva → se solicita una plaza para el trayecto y devuelve
una reserva para este.
- addReserva(reserva): void → añade una reserva a las ya gestionadas.
Necesita como parámetro 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
AUTOBÚS: Es cada uno de los autobuses que tiene la compañía y que se dedicará
a cubrir los trayectos ofrecidos por esta. De cada autobús se conocerá el modelo y
matrícula del vehículo y la capacidad máxima de viajeros que admite. Los métodos
de los que dispondrá son los siguientes:
- Autobús(string, string, int): autobús → es un constructor de autobús, al
que se le pasarán como parámetros el modelo, la matrícula y la capacidad y
devolverá el propio autobús.
La representación gráfica de esta clase se muestra en la figura 4-3.
Figura 4-3. Clase autobús
PERSONA: Son las personas que van a formar parte del modelo. Se dividirán en
empleados o pasajeros. Cada persona tendrá un nombre, una dirección, un DNI,
un teléfono y una edad. Necesitará disponer de los métodos 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 compañía. De ellos se
conocerá el número de seguridad social (NSS) y su antigüedad dentro de la
empresa. Los métodos 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 representación gráfica que tendrá esta clase en el
modelo.
Figura 4-5. Clase empleado
PASAJERO: Son las personas que viajan con la compañía. Estos quedarán
registrados cuando hagan algún trayecto en alguno de los autobuses de la
compañía. Para ello se conocerá su código de cliente, y los métodos que necesitará
esta clase para la gestión 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á.
- añadirReserva(reserva): void → se le añade una reserva al pasajero en su
lista de reservas.
Gráficamente, la representación 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 autobús de la compañía. De cada reserva se conocerá su
precio y el número de asiento dentro del autobús. Tiene asociados los siguientes
métodos:
- reserva(): reserva → Crea una nueva reserva.
- setTrayecto(trayecto): void → Añade un nuevo trayecto a la base de datos
para la reserva.
- setPasajero(pasajero): void → Añade un nuevo pasajero a la base de datos
para la reserva.
En la Figura 4-7 se muestra la clase gráficamente, 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 podrán ser empleados o pasajeros. De esta forma,
pasajero y empleado heredan los atributos de persona. La relación entre estas tres clases será como
la indicada en la Figura 4-8.
Figura 4-8. Relaciones de herencia en el diagrama
Además, entre las clases que se han distinguido pueden apreciarse una serie de
relaciones que se identifican con algunos de los patrones de colaboración que nos ofrece la
herramienta. Por lo que la inclusión de estas clases y relaciones al diagrama puede hacerse de
una forma inmediata, arrastrando el patrón correspondiente e identificando las clases del
patrón con las que ya estén representadas, en el caso de que lo estén, y completando
posteriormente lo que falte.
Se conoce que las compañías realizan trayectos, por lo que habrá una relación entre
estas dos clases. La relación será de asociación y una compañía podrá ofrecer varios trayectos.
Esta relación puede representarse mediante el patrón Item-SpecificItem, y la representación en el
diagrama será similar a la indicada en la Figura 4-9.
Figura 4-9. Patrón “Item-SpecificItem” para la relación entre compañía y trayecto
Por otro lado, cada compañía deberá tener una serie de autobuses para poder
proporcionar sus servicios, por lo que habrá otra relación entre estas dos clases. Tal relación
podrá ser de composición o de agregación, mas se considerará de composición puesto que la
compañía dejaría de tener sentido si no tuviera ningún autobús. Esta relación, así descrita se
asemeja al patrón “Group-Member”, donde el grupo sería la compañía y los miembros de esta
serían los autobuses que posee. De esta forma, esta parte del modelo puede representarse en
el diagrama con la inserción de este patrón, quedando como se indica en la Figura 4-10.
Figura 4-10. Patrón “Group-Member” para la relación entre compañía y autobús
De forma paralela, habrá una relación similar entre compañía y empleado. Una
compañía tendrá contratados una serie de empleados para que realicen el trabajo que da la
empresa. Igual que pasaba en el caso anterior, la compañía dejará de tener sentido si no hay
ningún empleado trabajando para ella. De esta forma, la relación existente entre estas dos
clases será otra vez de composición y volverá a repetirse el patrón que se utilizaba
anteriormente, de “Group-Member”. Igual que antes, la compañía se identificará con el grupo,
siendo esta vez cada uno de los empleados los miembros de este grupo.
La realización del diagrama de clases para esta parte, utilizando el patrón indicado tiene
como resultado la Figura 4.11.
Figura 4-11. Patrón “Group-Member” para la relación entre compañía y empleado
Otra relación observada en este caso es la existente entre trayecto y reserva. Una
reserva se hará para un solo trayecto pero un trayecto incluirá múltiples reservas. Así puede
identificarse una vez más otro patrón de colaboración, 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 representación gráfica que se obtendría en el
diagrama es la reflejada en la Figura 4-12.
Figura 4-12. Patrón “SpecificItem-LineItem” para la relación entre trayecto y reserva.
Por otro lado, un pasajero podrá hacer las reservas que desee en la compañía de
autobuses, pero una reserva solo la podrá hacer un único pasajero, puesto que es para un
número de asiento concreto. La relación entre las clases pasajero y reserva, vista de esta forma,
correspondería con el patrón “Role-Transaction”, donde el pasajero cumple el papel de Role y
la reserva el de Transaction. Esta relación dibujada en el modelo, con la utilización de este
patrón tendría la apariencia que se refleja en la Figura 4-13.
Figura 4-13. Patrón “Role-Transaction” para la relación entre pasajero y reserva.
Cabe comentar que para la utilización 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 métodos, y después se ha arrastrado el patrón correspondiente,
sustituyendo en él las clases que ya estaban incluidas en el diagrama por las que se
contemplaban en el patrón. De esta manera, no se han añadido nuevas clases con el patrón,
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 patrón. Si una clase sustituye a otra perteneciente a un
patrón en más de una ocasión, el estereotipo que queda visible es el del último patrón que fue
añadido.
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 colaboración, no
obstante, existen otros tipos de relaciones entre las clases.
Una de estas relaciones es la existente entre compañía y pasajero. La compañía atenderá a
todos los pasajeros que viajen a través de ella. Esta será una relación de asociación y su
representación se observa en la Figura 4- 14.
Figura 4-14. Relación entre compañía y pasajero
Otra relación 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 compañía. Una vez más, se trata de una asociación y, por lo tanto, la relación
que habrá que representar es la indicada en la Figura 4-15.
Figura 4-15. Relación entre trayecto y pasajero
Finalmente, la última relación encontrada en el caso en estudio es la que hay entre
autobús y trayecto. Los autobuses sólo realizarán un trayecto y un trayecto solo lo realizará un
autobús. Luego, la relación que une estas clases será de asociación, como la reflejada en la
Figura 4-16.
Figura 4-16. Relación entre autobús y trayecto
Una vez consideradas todas las clases con sus atributos y métodos, 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, podría 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 generación de código
Una utilidad complementaria que ofrece la herramienta diseñada en este proyecto final
de carrera es la de generar código java.
Se ha decidido que el código generado sea java por las múltiples características
positivas que este ofrece. La principal es que se trata de un lenguaje portable, independiente de
la plataforma en la que se ejecute.
Además, al tratarse de un lenguaje orientado a objetos, cada objeto puede verse como
un paquete que contiene el “comportamiento” (el código) y el “estado” (datos). Esta
representación hace que la transformación del diagrama de clases a este lenguaje pueda hacerse
de una forma muy simple. Como resultado quedará un código claramente estructurado y muy
fácil de leer.
Por otro lado, java es un lenguaje simple, fácil de aprender. Característica esta muy
importante si se tiene en cuenta que la herramienta va especialmente dirigida a estudiantes de
ingeniería del software.
Para que el usuario pueda generar el código java correspondiente a su diagrama de
clases, lo podrá hacer a través del menú File > JAVA Code Generation o pulsando la
combinación 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 código. Podrá desplazarse por las carpetas de su
equipo y escribir el nombre para el nuevo directorio.
Obviamente, antes de generar el código, tendrá que estar dibujado el diagrama de
clases en el panel correspondiente, en caso de que no hubiese nada representado, la generación
de código tendrá como resultado un directorio vacío.
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, métodos y relaciones que tenga la clase.
Este código generado será un esqueleto que el usuario podrá completar en la medida
de sus necesidades.
Se ha generado el código para el diagrama de clases de la Figura 4-17. Se le ha indicado
al sistema que guarde el código 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. Generación de código Java en el directorio autobuses.
A continuación se mostrará el contenido de cada uno de esos ficheros, en las Figuras
que van desde la 4-19 a la 4-25. El código se ha abierto con la aplicación JBuilder para que se
vea más claramente cada parte del código, al distinguirse con colores.
Figura 4-19. autobús.java
Figura 4-20. compañía.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 código, 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 generación de código para una clase determinada se ha obtenido un fichero con
el mismo nombre que la clase, con extensión .java. Cada clase se ha considerado un objeto, de
manera que el fichero tiene la descripción 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 métodos que lleva asociados.
Además se tienen en cuenta las relaciones que tiene la clase para generar su código. De
esta manera, si la clase para la que se genera el código es el origen de una asociación, una
agregación o una composición, se creará en ella un objeto del tipo de la clase destino de la
relación.
Si una clase tiene una relación de herencia con otra, en el código 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 más de una clase. En este caso, al generar el código se mostrará un mensaje de
“Warning” al usuario, puesto que Java no permite herencia múltiple. No obstante, en el código
generado se indicará que la clase extiende de todas las que es destino en las relaciones de
herencia, aunque esto daría un error al compilar el código, como ya se le ha indicado al
usuario.
4.4 Las aportaciones educativas del producto software desarrollado
Desde el primer capítulo 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 capítulo que son capitales en el desarrollo de software y que
progresivamente han ido adquiriendo cada vez más importancia.
En este mismo sentido y volviendo a resaltar la importancia de las actividades
mencionadas, en la actualidad, en el contexto educativo y en función de las nuevas
metodologías de enseñanza y aprendizaje, una serie de competencias se están asociando a los
diferentes títulos universitarios ofrecidos por las universidades españolas. Estas competencias
pueden consultarse en los correspondientes Libros Blancos, disponibles en la página web de la
Agencia Nacional de Evaluación de la Calidad y Acreditación (ANECA).
En este proyecto final de carrera se han tenido también en cuenta las competencias
mencionadas. En la Tabla 4-1 se recogen las competencias específicas del Título de Grado de
Ingeniería Informática, para el perfil de desarrollo del software. Entre ellas cabe destacar
algunas especialmente reseñables 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 través de su identificador numérico, 2, 11, 12, 13, 16 y 24.
Competencias específicas 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 análisis funcional, orgánico y programación, asegurando la adecuada explotación de las aplicaciones.
2. Dominar todas las etapas de la vida de un proyecto (análisis de concepción, análisis técnico, programación, pruebas, documentación y formación de usuarios).
3. Dirigir el equipo de trabajo compuesto por Analistas Funcionales, Analistas de aplicaciones, Programadores.
4. Control y seguimiento de plazos, indicadores económicos y de calidad.
5. Supervisar y coordinar el desarrollo completo de aplicaciones y administrar la introducción de los sistemas de gestión.
6. Controlar las aplicaciones en explotación, minimizando las consecuencias negativas sobre las operaciones en producción y desarrollo de aplicaciones.
7. Analizar y recoger nuevas técnicas y herramientas del mercado estudiando su viabilidad y necesidad.
8. Posibilidad de contratar recursos externos.
9. Control y Gestión del Desarrollo del Proyecto Informático.
10. Redacción, para la Dirección de Informática y para la Dirección del Proyecto de los informes que se precisan para el seguimiento del proyecto.
11. Interpretar las especificaciones funcionales encaminadas al desarrollo de las aplicaciones informáticas.
12. Realizar el análisis y el diseño detallado de las aplicaciones informáticas.
13. Definir la estructura modular y de datos para llevar a cabo las aplicaciones informáticas que cumplan con las especificaciones funcionales y restricciones del lenguaje de programación.
14. Definición y descripción 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 informáticas.
16. Elaborar y mantener documentación descriptiva de la génesis, producción y operatividad de las aplicaciones informáticas.
17. Diseñar servicios de presentación que faciliten la explotación 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 diseño de nuevos sistemas informáticos como consecuencia de la informatización de áreas de la empresa que utilizan para el desarrollo de sus tareas métodos y procesos manuales.
20. Integrar sistemas informáticos existentes susceptibles de inter-relacionarse.
21. Escuchar y asesorar a los Usuarios en la resolución de los problemas que se les plantean con el uso de los sistemas informáticos.
22. Asesorar a los programadores en los problemas que se les plantean con la programación de los sistemas.
23. Colaborar con los responsables de Estudios y Explotación en la resolución de los fallos que se originen en los Sistemas en Producción.
24. Mantenerse al día en Técnicas, Métodos y Herramientas de Análisis y Diseño.
Tabla 4-1. Competencias específicas del título de grado en Ingeniería Informática perfil Desarrollo del
Software
En definitiva, en este proyecto final de carrera se ha contribuido a la elaboración de
una herramienta que posibilite la utilización de una experiencia útil en la elaboración de
especificaciones conceptuales, como es la disponible a través de los patrones de colaboración,
y, gracias al entorno facilitado, el ingeniero del software en formación puede realizar labores
de análisis y diseño de soluciones software reutilizando dicha experiencia.
4.5 Análisis y discusión
Con el ejemplo utilizado en este capítulo se ha pretendido demostrar de forma práctica
la potencialidad de la herramienta desarrollada en este proyecto final de carrera y contribuir a
presentar cómo se utiliza. Un estudio más detallado de las facilidades que ofrece podría
realizarse a través de la consideración de su uso en distintas asignaturas disponibles en el actual
plan de estudios de la Escuela Superior de Ingeniería Informática. Estas asignaturas pueden
ser las correspondientes a los primeros cursos de las actuales titulaciones de Ingeniería
Informática, Ingeniería Técnica de Sistemas y de Gestión, concretamente aquellas asignaturas
en las que al alumnado se les presenten conceptos relacionados con programación orientado a
objetos.
Cola-CASE facilita un entorno muy intuitivo y flexible en el que los patrones están
disponibles en una carpeta que acompaña al ejecutable facilitado. El usuario puede definir sus
propios patrones e incluirlos en la carpeta mencionada. También distintos usuarios pueden
compartir sus patrones propios sin más que a través 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 colaboración. Es posible también incorporar el catálogo de
patrones más conocido y utilizado como es el catálogo de patrones de diseño de (Gamma et
al., 1995).
Capítulo 5. Conclusiones y Trabajo Futuro
Este capítulo tiene como único cometido recoger las conclusiones que pueden
obtenerse tras la realización 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 metodología que pueda utilizar todo el equipo de
trabajo y que puedan seguir como guía y ayude a comprobar la calidad del producto final. Esta
idea podría 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
implementación de dicha funcionalidad, dándole 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 análisis de los requisitos es la etapa más crucial del desarrollo de un
proyecto de software, debiendo especificar estos requisitos de alguna manera. Para ello, la
elaboración de modelos resulta de gran utilidad puesto que de un vistazo más o menos simple
se puede comprender fácilmente 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 diseño.
Se ha comprobado la necesidad de aportar experiencia a los proyectos, pudiendo ir
más allá de la propia del desarrollador, utilizando para ello los patrones de colaboración,
disponibles en el ámbito del modelado conceptual. Estos patrones están sobradamente
probados y son una sólida base para la búsqueda 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 añadir a este los patrones de colaboración que sean necesarios,
disponibles en el repositorio facilitado. Y con la posibilidad de modificar o añadir nuevos
patrones.
El entorno desarrollado permite centrarse en el análisis y el diseño más que en la
implementación. 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 utilización en los modelos del negocio.
Además, desde el primer momento se ha tenido en mente que esta herramienta
estuviera destinada para el uso de estudiantes de ingeniería del software, por lo que la sencillez
de esta se ha hecho patente desde el principio. Con lo que conlleva su fácil utilización.
5.2 Trabajo Futuro
Con la herramienta desarrollada, se pretende abrir paso a otras herramientas que
faciliten la utilización de patrones en el modelado, para que el usuario pueda disponer de las
estructuras asociadas con cada patrón sin tener que realizar el diseño desde cero de cada uno
de los patrones.
Esta es una primera versión de la herramienta, por lo que puede mejorarse en algunos
aspectos. Por un lado, podrían hacerse una mejora en cuanto a la usabilidad, haciendo para
ello más flexibles las asociaciones y mejorarse el aspecto de la interfaz y de los diagramas, para
que resultara más atractivo al usuario, al igual que podría incluirse un pequeño gráfico de cada
patrón antes de ser arrastrado, para que el usuario pudiera recordar su apariencia antes de
utilizarlo.
También podría añadírsele funcionalidad, por ejemplo, posibilitando la realización de
otro tipo de diagramas, además de los de clases, y generando código en otro tipo de lenguajes,
además de Java. Por otro lado, podría añadir el uso de otro tipo de patrones, como los de
(Gamma et al., 1995), que se utilizan para un diseño detallado.
Bibliografía
(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.,
1996)
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal,
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,
1995)
James O. Coplien y Douglas C. Schmidt, Pattern Languages of
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.
(Durán & Bernárdez,
2002)
Durán, A., Bernárdez, B. Metodología para la Elicitación de
Requisitos de Sistemas Software. Sevilla, 2002. (artículo)
(Pressman, R., 2007) Pressman, R. Ingeniería del Software: Un Enfoque Práctico.
McGraw-Hill, 2007.
(UML, 2007) Lenguaje Unificado de Modelado. http://www.omg.org
http://www.uml.org
http://martinfowler.com/
Metodologías Ágiles en el Desarrollo de Software.
http://www.willydev.net/descargas/prev/TodoAgil.Pdf
Programación extrema. http://www.extremeprogramming.org
Programación 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
Página web de UsiXML: http://www.usixml.org
Página de XML: http://www.w3.org/XML/
Apéndice A
Patrones de Colaboración
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 place’s 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 item’s 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 item’s 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 item’s 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.
