Roberto Corts Morales

INGENIERA DE SOFTWARE EFICAZ:

LA PERSPECTIVA DE PROCESO UNIFICADO A TRAVS DEL ANLISIS ORIENTADO A OBJETOS, USANDO UML
VERSIN PRELIMINAR

2008

Editora acadmica y asesora pedaggica: Stella Delolme Nossa Encargada de ctedra: Grethel Mena Araya

Este texto ha sido confeccionado por la UNED para ser utilizado en la asignatura Herramientas de Produccin Avanzada, cdigo 830 que se imparte en las carreras de Informtica Administrativa y Tcnico en Computacin e Informtica. Este material est dirigido a estudiantes de nivel avanzado en Anlisis y Diseo de Sistemas Orientado a objetos.

TABLA DE CONTENIDO
INTRODUCCIN CAPTULO 1. GENERALIDADES SOBRE EL PARADIGMA DE ORIENTACIN A OBJETOS, EL PROCESO UNIFICADO Y CASOS DE USO OBJETIVOS PARADIGMA DE ORIENTACIN A OBJETOS Pensar en objetos: la abstraccin del paradigma La clasificacin: una descripcin general de los objetos La Herencia: generalizar y especificar soluciones Distintas formas de hacer cosas parecidas: el polimorfismo EL PROCESO UNIFICADO Qu es el Proceso Unificado (UP)? El UP es orientado a casos de uso: historias del sistema El UP se centra en la arquitectura: dar sustento a los casos de uso El UP es iterativo e incremental: la convergencia a una solucin UML y el UP CASOS DE USO: LA GUA DEL PROCESO Cmo identificar los casos de uso de un sistema Los actores del sistema Casos de uso: cmo se visualizan Relaciones entre casos de uso Especificacin bsica de casos de uso Especificacin detallada de casos de uso Elementos de una especificacin detallada CAPTULO 2. EL MODELO CONCEPTUAL DE CLASES: LA EXPRESIN DE LOS CONCEPTOS DEL PROBLEMA 9

15 16 17 17 18 19 21 24 24 25 30 33 40 40 41 43 43 46 46 49 50 59 60 61 61 63 67 68

OBJETIVOS CONSIDERACIONES PRELIMINARES DEFINICIN DEL MODELO CONCEPTUAL Modelando los conceptos Categoras de clases conceptuales CASOS DE USO E IDENTIFICACIN DE CLASES CONCEPTUALES

DIFERENCIAR CONCEPTOS QUE SON CLASES Y CONCEPTOS QUE SON ATRIBUTO RELACIONES CONCEPTUALES ENTRE CLASES Cardinalidad de las relaciones Nombre de las relaciones Relaciones mltiples entre clases Relaciones hacia la misma clase Especificacin de conceptos en el modelo de clases AADIENDO ATRIBUTOS AL MODELO CONCEPTUAL DEFINIENDO OPERACIONES EN EL MODELO CAPTULO 3. DE CARA A LA IMPLEMENTACIN: EL MODELO DE CLASES DE DISEO OBJETIVOS CONSIDERACIONES PRELIMINARES LA TRANSICIN DEL ANLISIS AL DISEO: LA VENTAJA DEL A/DOO TARJETAS CRC: DOCUMENTAR Y EVALUAR LAS CLASES CONCEPTUALES LAS CLASES DE DISEO DEL NEGOCIO Refinamiento en la definicin de atributos y operaciones Constructores Tipo de datos de los atributos Tipos de retorno y parmetros de las operaciones Relaciones de asociacin y de composicin: las relaciones conceptuales vistas en la ptica del diseo Diferencia entre relaciones de asociacin y de composicin Apuntes sobre la jerarqua de herencia LOS GESTORES: QUIN DIRIGE LA ORQUESTA? Arquitectura en n-capas Definir clases de gestin CAPTULO 4. EL MODELO DE INTERACCIN Y LA ARQUITECTURA DEL SISTEMA OBJETIVOS CONSIDERACIONES PRELIMINARES DIAGRAMAS DE SECUENCIA: UN PRIMER ACERCAMIENTO Y SU UTILIDAD PARA DESCUBRIR LAS CLASES DE LA CAPA DE INTERFAZ Diagramas de secuencia de sistema Diagramas de secuencia: identificando la capa de interface

71 73 74 77 82 83 83 90 99 107 108 109 109 112 114 114 116 119 121 124 131 134 138 138 141 145 146 147 148 148 152

Interaccin entre capas: aadiendo la capa de gestin Cajas de activacin y su efecto en las operacionenes Visin del trabajo de los gestores en un diagrama de secuencia DIAGRAMAS DE ACTIVIDAD: APOYANDO LA ESPECIFICACIN DEL DISEO Elementos de un diagrama de actividad Especificacin de casos de uso y diagramas de actividad Especificacin de operaciones DIAGRAMAS DE ESTADOS Elementos de un diagrama de estados Elaboracin de un diagrama de estados CAPTULO 5. DE CARA A LA IMPLEMENTACIN OBJETIVOS CONSIDERACIONES PRELIMINARES LAS PRUEBAS EN LA INGENIERA DEL SOFTWARE De lo particular a lo integral Pruebas de unidad Pruebas de integracin y componentes DESPLEGANDO LA SOLUCIN Elementos de un diagrama de despliegue Construyendo un diagrama de despliegue COMPLETANDO EL PROCESO DE TRANSICIN CONCLUSIONES BIBLIOGRAFA

154 155 158 166 167 169 177 179 179 181 187 188 189 190 192 194 197 206 208 208 213 215 220

NDICE DE FIGURAS
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. La Clase Pelota Clase para cada tipo de cliente Superclase de cliente y clases derivadas por tipo de cliente Diagrama de casos de uso parcial de sistema de cajero automtico La conceptualizacin del UP Un diagrama de casos de uso Diagrama de casos de uso para la administracin de prstamos de la biblioteca universitaria Conceptos en un punto de venta de un supermercado Relaciones en el modelo conceptual Conceptos del Sistema de Prstamo Bibliotecario Diferencia entre clases conceptuales y atributos Definicin de primeras relaciones entre clases conceptuales para el 18 20 21 27 37 44 45 64 66 70 71 74 79 80 89 95 96 98 103 111 112 118 122 123 125 128 129 133 134 136 137

29.
30. 31.

Modelo de clases conceptuales para el Sistema de Prstamo Bibliotecario Modelo conceptual completo para el Sistema de Prstamo Bibliotecario Diferencias entre el diagrama del modelo conceptual inicial y el actual del Sistema de Prstamo Bibliotecario Visualizacin de las clases conceptuales y sus atributos Incorporacin del caso de uso de Pagar Prstamos Morosos al modelo conceptual de clases del Sistema de Prstamos Bibliotecarios Modelo conceptual de la Clase Material Bibliogrfico, definida por mecanismos de herencia Diagrama del modelo de clases conceptuales incorporando los mtodos u operaciones por cada clase Representaciones de la clase Prstamo y Copia en el modelo conceptual y en el modelo de diseo Representacin de la clase Prstamo en JAVA Diagrama modificado al incorporar la clase Detalla Prstamo Diagrama que muestra la clase Prstamo desde el punto de vista de diseo La clase de diseo Prstamo, vista en cdigo JAVA Diagrama de clases de diseo involucradas en el proceso del prstamo de libros Vista de una ventana de Power Designer para la clase Prstamo Diagrama de clases de diseo incorporando las asociaciones Diagrama que muestra la modificacin de la relacin entre la clase Prstamo y Detalle Prstamo Diagrama que muestra la jerarqua de herencia del concepto de Material Diagrama que muestra la clase abstracta Material y las clases derivadas especficas de cada material bibliogrfico Representacin en JAVA de la clase abstracta Material

Sistema de Prstamo Bibliotecario

Bibliogrfico

32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58.

Arquitectura en tres capas Arquitectura en n-capas Representacin de la interaccin entre el actor Bibliotecario y el Sistema de Prstamo Bibliotecario, mediante un diagrama de secuencia. Representacin del caso de uso Registrar Prstamo, mediante un diagrama de secuencia Representacin, en un diagrama de secuencia, del proceso Registrar Prstamo, usando las operaciones de la clase de diseo de la capa de interfaz Diagrama de la interaccin entre la capa de interfaz y de la capa de gestin Representacin de la composicin entre las clases de diseo de la capa de interfaz y de la capa de gestin Representacin de la creacin de objetos, a partir de la interaccin entre capas Representacin completa del proceso de Registrar Prstamo, en mltiples capas Visin parcial de la Figura 40, enfocada en la validacin del Usuario Representacin de la clase de diseo Detalle Prstamo, a partir de los descubrimientos derivados del diagrama de secuencia de la Figura 40 Smbolos usados en un diagrama de actividad Diagrama de actividad para un algoritmo, para calcular una suma de nmeros naturales Primera elaboracin del diagrama de actividad para el caso de uso de

139 140 149 151 153 155 157 160 162 163 164 167 168 171 172 174 176 177 178 180 183 185 190 193 196 198 198

Registrar Prstamo

Continuacin de la elaboracin del diagrama de actividad para el caso de uso de Registrar Prstamo Continuacin de la elaboracin del diagrama de actividad para el caso de uso de Registrar Prstamo Diagrama de actividad completo para el caso de uso de Registrar

Diagrama de secuencia de las clases de interfaz y gestin, para el caso de uso de Registrar Prstamo Diagrama de actividad para especificar la operacin TieneCopiaPrestada Smbolos utilizados en los diagramas de estados Diagrama parcial de la transicin de estados de la copia de un material bibliogrfico Diagrama de estado completo para la copia de un material bibliogrfico Las pruebas estn en todas las fases del Prstamo Unificado, pero aumentan en la fase de Transicin Operaciones involucradas en el caso de uso de Registrar Prstamo Especificacin de la operacin TieneCopiaPrestada Interfaz para Registrar Prstamo Cdigo en JAVA para interfaz IRegistrarPrstamo

Prstamo

59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72.

Cdigo en JAVA de clase RegistrarPrstamoInterfaz que implementa la

interfaz IRegistrarPrstamo. Componente AdministrarPrstamo en el Sistema Prstamo Bibliotecario

Asociacin de interfaces para un componente en Power Designer Asociacin de interfaces para un componente en Power Designer Clases resultantes del componente de Administrar Prstamo El componente Administrar Prstamo se acopla con el componente usuarios Diagrama de componentes que implementan el Sistema de Prstamo

199 200 200 201 203 203 205 207 208 209 210 211 212 213

Ambiente para creacin automtica de la documentacin tcnica del sistema en Power Designer Elementos de un diagrama de despliegue Equipo cliente del Sistema de Prstamo Bibliotecario Conexin hacia el servidor Web de la Biblioteca, desde Internet o Intranet Diagrama de despliegue del Sistema de Prstamo Bibliotecario Diagrama de despliegue del Sistema de Prstamo Bibliotecario integrando el Sistema Financiero Diagrama de despliegue del Sistema de Prstamo Bibliotecario completo

Bibliotecario

NDICE DE TABLAS
1. Posible marco de trabajo del sistema de cajero automtico en el marco del proceso unificado 2. Lista de categoras de clases conceptuales. Adaptado de Larman (2003) 3. Representacin de clases de la Figura 11 usando la regla de oro sugerida por Larman 4. Atributos potenciales de las clases conceptuales del Sistema de Prstamo 38 67 72 91 93 97 100 102 191 206 214

5. Actualizacin de los atributos de las clases conceptuales del Sistema de Prstamo Bibliotecario

Bibliotecario

6. Anlisis de atributos por cada uno de los tipos de materiales bibliogrficos 7. Mtodos identificados en cada una de las clases involucradas en el caso de uso de Registrar Prstamo 8. Actualizacin de los mtodos por cada clase en el Sistema de Prstamo 9. Clasificacin general de los tipos de pruebas en la Ingeniera de Software 10. Ejemplos de cmo aporta el UP usando el UML en la Ingeniera de Sistemas 11. Relacin entre los distintos tipos de pruebas y los mdulos creados en el desarrollo del sistema

Bibliotecario

INTRODUCCIN Existen varias formas de acercarse a cualquiera de las temticas que se abordan en la Ingeniera de Software para tratar de motivarlo a usted hacia ello. Podra escribir sobre la consistencia, las ventajas que se encuentran en el desarrollo de software usando UML apoyado por una herramienta pero creo que ello no sera suficiente para lograr entusiasmarlo por este tema. Sin embargo, usted me permitir que le cuente mi experiencia personal, o parte de esta, en el campo de la Ingeniera de Software, la cual me motiva grandemente a escribir este libro, esperando que encuentre en l, las bondades que yo he hallado para mi vida profesional, en el anlisis y diseo orientado a objetos, usando UML. Precisamente, puedo empezar mi historia a partir del momento en que comenc a llevar mis cursos orientados a la Ingeniera de Software. Por aquel entonces, iniciando los aos 90, hablar de la programacin orientada a objetos era una extravagancia digna de los cursos electivos de final de carrera. Mucho menos probable era poder intuir o encontrar algo consolidado en el campo del anlisis y diseo orientado a objetos. Por ese entonces, estudibamos el anlisis estructurado. Sin detallar de qu se trata este tipo de anlisis, para poder expresarlo grficamente haba que crear los diagramas de flujos de datos, o DFD. Este tipo de diagramas requera, en mucho, especificar procesos y flujos de datos, los cuales consistan, coloquialmente hablando, en hacer bolitas y flechas, respectivamente. Un primer problema al que nos enfrentbamos era que, al carecer de herramientas de software que pudieran, por ese entonces, apoyar las labores de modelado. Los estudiantes nos encontrbamos creando diagramas mediante la ayuda de monedas y reglas. La especificacin del llamado diccionario de datos, requerido por esa metodologa, era tambin complejo de realizar, puesto que tena que sistematizarse sin ningn apoyo automatizado. El cuidado de mantener los diagramas consistentes recaa, exclusivamente, en el cuidado que debamos tener en su elaboracin. Otro problema que encontrbamos era el hecho de tener que plasmar el conocimiento que adquiramos mediante el anlisis de requerimientos, a travs de la descomposicin en procesos. Esto significaba ver el problema de un sistema solo a travs de un comportamiento del flujo de datos a travs de dichos procesos. Por ejemplo, si topbamos con un problema referido a la administracin de prstamos de una biblioteca, su resolucin tena que irse

modelando con procesos que expresaban acciones como: verificar existencia, comprobar atraso, registrar prstamo, registrar devolucin, registrar multa, entre otros. No obstante, en el plano del modelo de la solucin, no podan visualizarse los conceptos puros del sistema: libro, revista, prstamo, entre otros, ni tampoco la posible relacin entre stos, sus datos y acciones caractersticas. Esto tena que hacerse en otro momento, por ejemplo, cuando se plasmara el modelo de la base de datos. As, el anlisis separaba completamente los momentos de resolucin de un problema, es decir, las funcionalidades por un lado, y los datos por otro. Por lo tanto, al entrar a realizar un anlisis de requerimientos para definir el componente de software de un sistema, rpidamente tenan que dejarse de lado los conceptos ms naturales involucrados en la solucin. Todo ello aumentaba el riesgo de no llegar a una solucin concordada, usando el anlisis estructurado, mxime porque era necesario que en grandes proyectos existieran equipos especializados de anlisis, de bases de datos, de diseo de mdulos, etc., lo cual implicaba esfuerzos de coordinacin muy precisos. Si bien hoy en da dicha coordinacin tambin se requiere, en aquel entonces la dificultad para lograrlo era mayor. Por otra parte, luego de un gran esfuerzo, nos encontrbamos con el resultado de tener muchos diagramas, quizs con gran nivel de detalle, que deban pasar a la fase de diseo. Cmo hacer tal paso? Tal transicin no era evidente ni simple. Deban buscarse los procesos de mayor nivel de refinamiento en los DFD, adems de tener que identificar el punto ms abstracto de entrada y el punto ms abstracto de salida, para luego formar una jerarqua de procedimientos de software. Les parece complejo? S, s lo era, pero no voy a detallar el proceso que segu para lograrlo. Quiero estar en paz con usted. Pero, en algunos cursos conoc las caractersticas del paradigma de orientacin a objetos y, una vez graduado, la vida me llev a enfrentar varios proyectos, varias herramientas de software, varios cambios en la historia de la tecnologa, en muy pocos aos. Pude comenzar a experimentar la utilizacin de protocolos de TCP/IP para ejecutar aplicaciones hechas en el sistema operativo DOS, de forma desconcentrada. Al poco tiempo comenc a trabajar en la transformacin de aplicaciones de software de un ambiente de main frame hacia cliente / servidor, bajo el ambiente de Windows. Posteriormente sobrevino el advenimiento de las tecnologas de Web y su expansin en Internet, la

10

consolidacin de las arquitecturas n-capas y la construccin de componentes. Todo ello en menos de 10 aos. Paralelo a todos esos cambios, el mundo de la Ingeniera de Software requera encontrar metodologas que facilitaran la especificacin y el desarrollo de aplicaciones, porque cada da aumenta la demanda de software por parte de las organizaciones, a la vez que crece su complejidad e importancia. Al toparme de nuevo con el paradigma de orientacin a objetos, mediante el anlisis y diseo (usando la notacin del Unified Model Lenguaje, UML dentro de una propuesta metodolgica, llamada el proceso unificado), me fue posible palpar muchas ventajas en cuanto a la utilizacin de esta herramienta. He de confesar que, conforme iba capacitndome en su utilizacin, me senta cada vez ms tentado a rehacer todo el software de un proyecto que coordinaba. Sin embargo, esto no era viable en ese momento, pero a todas luces poda palpar, casi ver, las posibilidades brindadas de obtener, de forma muy natural, los requerimientos de software. Esa forma de desarrollo me posibilitaba especificar tales requerimientos de forma que fuera fcil de comprobar su validez con los clientes, para luego trasladarlos de forma relativamente sencilla, a especificaciones tcnicas para desarrolladores. Una vez que profundic sobre el UML, me fue muy fcil llevar a cabo un nuevo proyecto, usando las posibilidades y ventajas dadas por esa metodologa. Con ella, usted se enfrentar a un panorama distinto, con una ingeniera mucho ms madura, donde todas las fases se entrelazan de forma suave y, gracias a la consolidacin del paradigma y los lenguajes de programacin orientados a objetos, a un entorno consistente en todas sus fases: desde el tratamiento del problema con los clientes, hasta la programacin e implantacin del sistema. Ahora bien, para aprender Anlisis y Diseo Orientado a Objetos, nos valdremos de algunos apoyos. Uno de ellos es una herramienta existente en el mercado llamada Power Designer, de la compaa Sybase, que nos va a ser til para ilustrar el desarrollo de los ejemplos. Adems, echaremos mano de uno de los lenguajes ms difundidos y consolidados en el entorno de los lenguajes de programacin orientados a objetos: JAVA de Sun Microsystems. En este momento es posible que usted tenga curiosidad por saber de qu va a tratar este texto. Seguidamente se lo contaremos. Si bien creemos que usted conoce algo sobre el paradigma de Orientacin a Objetos, comenzaremos con un breve repaso de ste paradigma que, incluso, nos ayudar a dar un primer encuentro con la notacin de UML.

11

Posteriormente, haremos una presentacin del Proceso Unificado y el UML. Para ello nos ayudaremos de un ejemplo que introducir muchos conceptos que, luego, se seguirn reforzando en los siguientes captulos. A continuacin, se abordar el tema de los casos de uso, como una forma de establecer los requerimientos fundamentales del software por construir, as como la forma de especificar dichos fundamentos. Seguidamente entraremos a estudiar el modelo de clases, considerando dos aspectos: en primer lugar, visualizando dicho modelo como la expresin de la arquitectura esttica de los casos de uso identificados. Para ello, se abordar un caso de uso particular. En segundo lugar, tambin analizaremos cmo impacta el modelo de clases, la incorporacin de otro caso de uso. Este punto es importante de considerar al tratarse el proceso unificado, como ya se ver en su momento, de un proceso iterativo de construccin de software. En este punto tambin abordaremos las principales relaciones que se dan entre las clases: asociacin, composicin y herencia. Definida la arquitectura esttica a travs de un modelo de clases, estudiaremos la arquitectura dinmica del software mediante diagramas de secuencia, de actividad y de estado. Este modelo permitir visualizar cmo interactan entre s, objetos provenientes del modelo de clases para implementar un caso de uso particular. Los apartados anteriores podran definir, en general, la fase de anlisis: encontrar los casos de uso del software por construir y expresarlos a travs de una arquitectura de elementos de software, visualizados mediante clases y objetos interactuando. Sin embargo, la resolucin del software por construir, como en toda metodologa, debe seguir una estrategia, de acuerdo al contexto tcnico donde se encuentre. Adems, debern seguirse criterios de diseo, los cuales no tienen que ver con requerimientos funcionales definidos por el cliente, sino con aspectos como: modularidad, rendimiento, reutilizacin y muchos otros aspectos en los cuales, los modelos definidos en el anlisis, se vern enriquecidos y modificados para cumplir con requerimientos de la fase de diseo. Mediante el conocimiento de estos aspectos, estaremos profundizando en el software que se usar para ilustrar los conceptos. Veremos cmo se modifican los diagramas del anlisis, en la medida que se especifican ms detalladamente, los modelos que se presentan a lo largo del libro.

12

Se agregarn algunos gestores, que son clases de diseo, que ayudan a proveer acciones que favorecen la creacin de objetos, y a coordinar acciones entre estos, as como a asumir algunas funciones de control, que no son propias de las clases identificadas en el anlisis. Tambin, dichos gestores son fundamentales en algunas propuestas, como la arquitectura de n-capas. Por ltimo, veremos cmo el proceso de anlisis y diseo puede culminar en la generacin del cdigo bsico de programacin, lo cual podr ilustrar la consistencia que puede encontrarse entre las fases. Sin embargo, para lograr con xito el estudio de este curso, usted debe dominar, como requisito previo, siguientes conocimientos: Principios de ingeniera de software. Conocimiento del proceso de anlisis de requisitos de software. Conocimientos de los principios tericos del diseo de software. Conocimiento en el paradigma de orientacin a objetos. Conocimiento en lenguajes de programacin, siendo deseable Java.

13

14

CAPTULO

GENERALIDADES SOBRE EL PARADIGMA DE ORIENTACIN A OBJETOS, EL PROCESO UNIFICADO Y CASOS DE USO

SUMARIO PARADIGMA DE ORIENTACIN A OBJETOS Pensar en objetos: la abstraccin del paradigma La clasificacin: una descripcin general de los objetos La Herencia: generalizar y especificar soluciones Distintas formas de hacer cosas parecidas: el polimorfismo EL PROCESO UNIFICADO Qu es el Proceso Unificado (UP)? El UP es orientado a casos de uso: historias del sistema El UP se centra en la arquitectura: dar sustento a los casos de uso El UP es iterativo e incremental: la convergencia a una solucin UML y el UP CASOS DE USO: LA GUA DEL PROCESO Cmo identificar los casos de uso de un sistema Los actores del sistema Casos de uso: cmo se visualizan Relaciones entre casos de uso Especificacin bsica de casos de uso Especificacin detallada de casos de uso

15

OBJETIVOS Una vez que usted estudie este captulo, podr llevar a cabo cada una de las siguientes actividades de aprendizaje, que le servirn para comprobar cunto ha aprendido de este tema. Enunciar el significado de abstraccin dentro del paradigma de orientacin a objetos e identificar atributos y comportamiento de los objetos, dando ejemplos que los ilustren y describiendo el significado de clase dentro del paradigma de orientacin a objetos. Dar ejemplos de clases haciendo evidentes el nombre, los atributos y las operaciones o mtodos, representndolos esquemticamente y explicar lo que se entiende por encapsulamiento. Dar ejemplos en donde se haga evidente el significado de polimorfismo en el paradigma de orientacin a objetos y explicar en qu consiste la herencia dentro del paradigma y cules son sus implicaciones, mediante un ejemplo concreto. Mediante un diagrama ilustrar qu se entiende por casos de uso dentro del Proceso Unificado, ayudndose de un ejemplo concreto. Explicar el significado e importancia de arquitectura dentro del contexto del Proceso Unificado. Enunciar qu se entiende por iteracin dentro del Proceso Unificado, justificando su importancia y describir las fases en las que suele dividirse. A partir de un ejemplo que se le suministra, elaborar un esquema en el que se observen claramente las diferentes fases, las actividades y los objetivos que persiguen en cada caso. Partiendo de un ejemplo cualquiera, definir los casos de uso, especificando lo que lleva a cabo cada uno dentro del sistema. A partir de un ejemplo, y utilizando la plantilla definida en el libro, elaborar el llamado curso normal de eventos o escenario del sistema.

16

PARADIGMA DE ORIENTACIN A OBJETOS Antes de entrar de lleno en el desarrollo de los temas del Anlisis y Diseo Orientado a Objetos (que en adelante denominaremos ADOO), es conveniente hacer un breve repaso del paradigma de orientacin a objetos. Este repaso no se har desde un punto de vista histrico, es decir, no nos detendremos en conocer cmo surge este paradigma, cmo se desarrolla o cmo se consolida. Ms bien se har desde el punto de vista de la utilidad que tendr para este texto, en la medida que es uno de los fundamentos de la metodologa y tcnicas que vamos a estudiar. De esta forma se revisarn las principales caractersticas que definen ste paradigma: la abstraccin que lo fundamentan, la clasificacin y el encapsulamiento de objetos, el polimorfismo y la herencia.

Pensar en objetos: la abstraccin del paradigma

El paradigma de orientacin a objetos es una abstraccin que busca representar, en el software, los conceptos del mundo real. De hecho, la palabra objeto refiere a algo que es palpable. Tales conceptos pueden ser algo muy concreto, como por ejemplo, estudiante, o algo abstracto, como decir matrcula. Los objetos contienen dos aspectos fundamentales: sus atributos y su comportamiento. Por ejemplo, si pensamos en un objeto simple, como una pelota, podramos definirla por algunos atributos, entre ellos: color, volumen, peso. De igual forma, las pelotas tienen algunos comportamientos, muy relacionados con sus atributos, como: hacerla_rodar, pintarla, pesarla, medirla. No todas, pero quizs algunas pudieran permitirse hacerla_rebotar. Los objetos tienen identidad, es decir, todo objeto es nico. Adems, presentan un estado, el cual se define por los valores que tienen sus atributos en un momento determinado. Es por ello que una pelota roja es distinta de otra pelota roja, aunque tengan el mismo color, peso y volumen, esto es, que aunque el estado de un objeto sea igual que el de otro objeto, nunca se tratar del mismo objeto. Piense usted en dos personas que sean mellizas. Reflexione en ello y ver con ms claridad el significado de lo anterior.

17

La clasificacin: una descripcin general de los objetos

A pesar que los objetos son independientes, pueden clasificarse de una forma general. Podemos decir que todas las facturas, o todas las pelotas pueden describirse de una forma general. Ya sabemos que los objetos tienen atributos y comportamiento. A partir de ello siempre trataremos de identificar, de forma general, cules atributos y qu comportamiento pueden tener todos los objetos de una clase particular. En este punto nos topamos con una palabra importante: la clase. La clase vendr a ser un concepto muy importante del paradigma de orientacin a objetos, pues a travs de stas clases lograremos describir todos los objetos pertenecientes a una misma clase. Grficamente, una clase consta de tres secciones: el nombre, los atributos y las operaciones o mtodos. Estos ltimos son los que tienen que ver con el comportamiento de los objetos. En la figura 1, podremos ver la clase Pelota, representando los objetos de este tipo. Nombre Atributos

Pelota - color : - peso : - volumen : + + + + Hacerla_rodar () Pintarla () Medirla () Pesarla ()

Operaciones

Figura 1. La clase Pelota.

En ella pueden notarse las tres secciones que mencionamos. Todas las pelotas que vayan a crearse a partir de esta clase, tendrn esos atributos y esas operaciones. Ac surge algo muy poderoso dentro de esta forma de visualizar nuestras abstracciones. Muchas cosas en el mundo las podemos representar as. Por ejemplo, si pensamos en algo como un libro, de igual forma podemos pensar en sus atributos y las operaciones que podemos hacer con ste.

18

Nombre de la clase Atributos Operaciones

Libro Autor, Nmero de pginas, Captulos, Anexos, ISBN, Resumen Consultar, Ver resumen, Obtener Autor, Pasar pgina, Pasar Captulo

Muchas veces, sin embargo, nos veremos obligados a modelar conceptos ms abstractos, como por ejemplo los que podamos hallar en el contexto de una organizacin. Piense en una orden de trabajo, que es una tarea o actividad que una persona debe hacer y a la cual se le debe dar un seguimiento. Nombre de la clase Atributos Orden de trabajo Usuario que origina, descripcin de trabajo, fecha de solicitud, encargado, estado de la orden (sin asignar, en proceso, cancelada, finalizada), fecha de asignacin, fecha de estado final Solicitar trabajo, asignar, cancelar, finalizar

Operaciones

La caracterstica de poder definir clases para los objetos, nos pone ante un panorama particular en el mbito del paradigma de orientacin a objetos: para definir los conceptos relevantes dentro del dominio de un problema por resolver, debe pensarse en sus atributos y comportamiento como un todo. Siendo muy prcticos, debemos pensar que los objetos sern parte de un cdigo de software. Y en ese tanto, tales objetos contendrn los datos que requieren (atributos) y sus procesos (operaciones) residiendo en el mismo espacio. A tal caracterstica la llamaremos encapsulamiento.

La Herencia: generalizar y especializar soluciones

Muchas veces en un problema de software podemos encontrar un concepto que tiene, por una parte, atributos o comportamientos comunes, pero de ese mismo problema, se derivan tambin algunos atributos o comportamientos que son especficos de ese problema en particular. En este caso, para resolver el problema debemos acudir a la capacidad de herencia que tiene este paradigma.

19

La herencia es un mecanismo muy poderoso que permite agrupar en una caracterstica llamada superclase, los atributos y operaciones que son comunes a una o varias clases derivadas, las cuales heredan la definicin de dicha superclases. Pongamos el ejemplo de una empresa que maneja clientes. Los clientes pueden ser de dos categoras: clientes fsicos (es decir, personas como usted o como yo) y clientes jurdicos (en este caso, organizaciones, empresas, corporaciones, entre otros). Para representar a los clientes de esta compaa, dentro del software, podramos recurrir a dos estrategias. La primera sera crear una clase para cada una de los tipos que describimos. En la siguiente figura encontramos una ilustracin de esta estrategia.
ClienteFsico + + + + + + + Identificacin Apellido Nombre DireccinPostal Telfono CorreoElectrnico : : : : : : + + + + + + + ClienteJurdico Identificacin Nombre TipoOrganizacin DireccinPostal Telfono CorreoElectrnico : : : : : :

ClienteFsico () ActualizarDireccin () ActualizarTelfono () ActualizarCorreo () ObtenerDireccin () ObtenerTelfono () ObtenerCorreo ()

ClienteJurdico () ActualizarDireccin () ActualizarTelfono () ActualizarCorreo () ObtenerDireccin () ObtenerTelfono () ObtenerCorreo ()

Figura 2. Clase para cada tipo de cliente.

Tal como se aprecia, cada una de las clases representadas, puede manejar los clientes fsicos o jurdicos en un contexto determinado. No obstante, puede notarse tambin que existen muchos atributos y operaciones comunes en ellos. Esto se debe a que, debido a que el concepto de cliente es un concepto general, por cada uno de los tipos de clientes que encontremos, tales caractersticas generales se repiten. Por lo tanto, otra estrategia que podemos realizar es crear una jerarqua donde una superclase llamada Cliente rena las caractersticas comunes a todos los clientes y dos clases derivadas, ClienteFsico y ClienteJurdico, que representen la especializacin para cada uno de estos. En la siguiente figura se representa esta jerarqua:

20

Cliente + + + + + + + Identificacin DireccinPostal Telfono CorreoElectrnico : : : :

Cliente () ActualizarDireccin () ActualizarTelfono () ActualizarCorreo () ObtenerDireccin () ObtenerTelfono () ObtenerCorreo ()

ClienteFsico - Apellido : - Nombre : + ClienteFsico ()

ClienteJurdico - Razn Social : - TipoOrganizacin : + ClienteJurdico ()

Figura 3. Superclase de Cliente y clases derivadas por tipo de cliente.

En ella vemos cmo la clase Cliente rene los atributos y operaciones que son comunes a todos los tipos de cliente que el software vaya a manejar. Para cada una de las clases derivadas, tal como se representan en las clases de ClienteFsico o ClienteJurdico, encontramos solamente los atributos y operaciones que son propios de cada uno de stos. La jerarqua debe indicarnos que cada una de las clases derivadas de la superclase tiene, tambin, TODOS los atributos y operaciones de esta superclase. Por ejemplo, todos los tipos de clientes tienen una identificacin (sea cdula de identidad o cdula jurdica), una direccin postal, un telfono o un correo electrnico. No obstante, solamente un cliente fsico tendr un apellido y nombre, contrario a un cliente jurdico que tendr una razn social y un tipo de organizacin (pblica, privada, entre otras). Adems, todas las operaciones que se definan para Cliente sern tambin operaciones para ClienteFsico o ClienteJurdico. Lo anterior nos da una ventaja de que por cada tipo de cliente que estemos encontrando, nos enfocaremos en identificar las diferencias, sin preocuparnos por detalles que ya la superclase ha resuelto.

21

Distintas formas de hacer cosas parecidas: el polimorfismo

Piense por un instante que muchas veces en la vida hacemos cosas que, como acciones expresadas en verbos, las llamamos de forma semejante, pero que pueden resultar con efectos u objetivos distintos. Por ejemplo, cada uno de nosotros tiene un ritmo natural y propio para caminar. Si salimos de nuestra casa para ir a algn lado, iremos caminando con esa forma propia de cada uno (no es extrao que alguien exprese algo como ese es el caminado de fulano de tal). Sin embargo, muchas veces tenemos que modificar la forma en que caminamos y, si bien se trata de caminar, ciertamente debemos tener en cuenta otros parmetros a la accin. Por ejemplo, frente a una situacin de peligro podramos caminar de forma precavida o bien acelerada. Dependiendo de algo en especial, como pasar por una vitrina y darnos cuenta que algo nos interes, podramos caminar hacia atrs para poder ver el objeto que llam nuestra atencin. Entonces, lograramos expresar la accin de caminar con distintos parmetros, y siempre nos estaramos refiriendo a una accin que se llama igual. En la siguiente tabla encontramos algunos ejemplos de ello.
Accin Caminar Caminar Caminar Caminar Parmetros Ninguno Velocidad Velocidad, Direccin Velocidad, Direccin, Forma Lo que expresa Nuestro caminar normal Caminar lenta o rpidamente Caminar con una velocidad determinada, hacia atrs o hacia delante Caminar con una velocidad y direccin determinadas, de forma normal o precavida

En el paradigma de orientacin a objetos, la caracterstica de que un objeto pueda realizar una determinada accin, llamada igual, pero que puede diferenciarse por un conjunto de parmetros distintivo, se llama polimorfismo. Por ejemplo, si viramos el ejemplo anterior en perspectiva de un lenguaje de programacin, podramos escribir un cdigo como el que sigue: persona.Caminar(); // Caminar de forma normal persona.Caminar(velocidad); // Caminar con una velocidad determinada

22

persona.Caminar(velocidad, direccin); // Caminar con una velocidad y direccin determinada persona.Caminar (velocidad,direccin,forma); // Lo anterior con una forma determinada Ac podemos notar cmo la accin se llama igual (caminar). No obstante, las distintas formas de caminar se distinguen por la cantidad de parmetros que acepte y el tipo de cada uno de stos. Esta forma de polimorfismo se denomina sobrecarga de operaciones. Otra forma de poder visualizar el polimorfismo es a travs de la herencia. Veamos el siguiente ejemplo. Suponga, en la Figura 3, que existen dos formas distintas para calcular impuestos para un cliente, segn el tipo que se trate: fsico o jurdico. La superclase Cliente, podra definir una operacin llamada CalcularImpuesto, la cual se dice, es una operacin abstracta. Esto ltimo significa que, si bien (por requerimientos de la solucin y por diseo de esta), se sabe que para cada tipo de cliente se debe calcular un impuesto (de venta o de valor agregado), tal operacin no puede implementarse en la superclase, porque dicha implementacin vara, como ya se mencion, de acuerdo al tipo de cliente. Por lo tanto, cada una de las clases derivadas, ClienteFsico y ClienteJurdico, debern implementar la operacin. Desde el punto de vista conceptual, al tratar con el concepto particular de Cliente, todo cliente jurdico es un cliente y todo cliente fsico es un cliente. La forma de verse y de hacer las cosas, como calcular impuesto, es distinta. Entonces, el cliente tiene muchas formas de verse en la solucin que se trata de realizar. Esto es polimorfismo. Quedan as expuestas las principales caractersticas del paradigma Orientado a Objetos. Recordemos que estas caractersticas incluyen: La abstraccin de que los elementos de software los podemos ver como objetos. La clasificacin que permite definir, de forma general, todos los objetos de una clase particular que tienen atributos y comportamiento propios. La encapsulacin, que ayuda a reunir, tanto datos, como operaciones, en un solo elemento de software. La herencia, que es un mecanismo que permite racionalizar una solucin a travs de la creacin de una jerarqua que distribuye de la parte superior a la inferior, las

23

caractersticas de atributos y operaciones comunes y que se complementa de forma importante con El polimorfismo que favorece que podamos definir para un mismo concepto, distintas formas de comportarse o verse, a travs de las operaciones o de la herencia. EL PROCESO UNIFICADO La disciplina de la Ingeniera de Software ha tratado siempre de proveer una serie de metodologas que puedan facilitar el proceso de construccin de una solucin. Ese proceso ha buscado adaptarse a la naturaleza cambiante de los proyectos y de las soluciones. Ciertamente nosotros podemos suponer que al inicio de un proyecto se tenga una idea un tanto vaga de lo que se quiere, aunque no se dude de la importancia de lo que desea obtenerse. De igual forma, el cliente podr saber, de forma muy general, qu solucin de software quiere desarrollarse, porque ella es fundamental para los objetivos de su organizacin. Un proceso de desarrollo que busque identificar los factores crticos, y por ende ms riesgosos, que permita ir en un proceso incremental de la solucin, es altamente deseable. Precisamente, el llamado Proceso Unificado es una forma de desarrollo de software que permite ir creando una solucin de forma robusta, con un adecuado manejo del riesgo y de forma incremental. En las siguientes pginas buscaremos revisar los conceptos fundamentales de esta forma de trabajo: los casos de uso como gua del proceso, la arquitectura como sustento de la solucin y el desarrollo iterativo e incremental, como una forma de realizar una solucin adecuada a los requerimientos del usuario. Se tomar un ejemplo que, se espera, contribuya a aclarar algunas de las bases importantes que se introducirn en este captulo. En los captulos siguientes, cuando se profundicen varios conceptos que seguidamente se introducen, se usar otro ejemplo.

Qu es el Proceso Unificado (UP)?

Larman (Larman, 2003) seala que, informalmente, un proceso de desarrollo de software es un enfoque para la construccin, desarrollo y mantenimiento de software. En ello, el Proceso Unificado (en adelante UP, por sus siglas en ingls), se presenta como uno de los procesos de desarrollo de software ms difundidos

24

hoy en da, que busca aprovechar las ventajas del paradigma de orientacin a objetos, en las disciplinas de Anlisis y Diseo (el cual llamaremos A/DOO, es decir Anlisis/Diseo Orientado a Objetos). Tres aspectos caracterizan al UP: Se orienta a casos de uso. Se centra en la arquitectura y Es iterativo e incremental.

Qu es cada uno de estos conceptos? Procederemos a aclararlos a continuacin. El UP es orientado a casos de uso: historias del sistema Vamos a entender, los casos de uso como la interaccin que tienen los usuarios del sistema con ste. Para identificar los casos de uso pueden enlistarse las funciones, actividades u objetivos que tiene un usuario particular en el sistema. Podramos decir, entonces, que los casos de uso pueden interpretarse como las tareas del sistema que se llevan a cabo, originadas por alguien. Quin es ese alguien? Ese alguien son los llamados actores en el sistema. Un actor corresponde a un perfil de usuario, el cual puede ser una persona u otros sistemas. El propsito de identificar actores obedece a que debemos saber quines son los usuarios del sistema y cmo vamos a categorizar a dichos usuarios. Un actor es todo aquel (personas) o aquello (sistemas, dispositivos) que usan el sistema, ya sea para alimentarlo o para recibir salidas de ste. Un actor, por lo tanto, lo podemos conceptualizar, ya sea que se trate de una persona, un dispositivo u otro sistema, como algo o alguien que usa o produce datos e informacin del o para el sistema. Podemos darnos un ejemplo clsico, como los cajeros automticos. Todo sistema debe poder caracterizarse por los servicios que va a brindar a quienes se sirven de l. En este caso, podemos pensar que un cliente podr acceder a servicios como retirar efectivo, transferir fondos, consultar saldo, realizar pagos, entre otros. Estos servicios pueden verse como los objetivos de un sistema de cajero automtico. Cada uno de los servicios que se le ofrecen a un cliente podrn ser vistos como casos de uso: el caso de uso de Retirar efectivo, el caso de uso de Transferir fondos, el caso de uso de Consultar saldo.

25

Con respecto a los actores, inmediatamente podemos pensar en el cliente (muchos de nosotros hoy en da hemos usado un cajero automtico), como un actor del sistema de cajeros automticos. El cliente interacta con este sistema y, en gran medida, para l es quien se ha creado el sistema. No obstante podemos pensar que existen otros actores importantes del sistema. Usted ha visto que en ciertos momentos llegan funcionarios del banco o entidad financiera duea de los cajeros automticos a realizar procesos en ellos, tales como alimentarlos de efectivo, descargar la informacin almacenada, realizar mantenimiento, entre otras acciones. Vea que, con respecto a un funcionario, al cual podramos denominar operario, encontramos otras funcionalidades en este sistema y como tal, tambin estamos identificando otro actor del sistema. Las funcionalidades como Descargar informacin almacenada, Realizar mantenimiento, Alimentar efectivo se pueden ver como casos de uso. Finalmente, podemos pensar que el cajero automtico es un sistema que se relaciona con un sistema bancario central: todas las acciones que se dan en el cajero deben estar apoyadas por el sistema bancario central donde, entre muchas cosas, se encuentra la informacin de la o las cuentas asociadas con la tarjeta que se emplea para el uso del cajero. El sistema bancario debe, adems, apoyar las acciones de registro de transacciones, de actualizacin de saldos, de comunicar a otras entidades relacionadas con los servicios ofrecidos en el cajero automtico entre muchos. Identificar los casos de uso nos da una forma de poder ir listando los objetivos y los requerimientos del sistema por parte de una serie de interesados, en este caso, los actores que podamos encontrar en el sistema. Un caso de uso es una forma relativamente sencilla de especificar los objetivos de un sistema. Por eso constituye una de las bases principales del UP. Describir lo que hace un caso de uso es bsicamente describir una historia, como lo afirma Larman (Larman, 2003). Las historias, esencialmente nos refieren a pensar en narraciones, es decir, que la descripcin de los casos de uso pasa por escribirlo en alguna lengua natural, no en trminos de lenguajes informticos. Ms adelante veremos un ejemplo de ello. Para visualizar grficamente un caso de uso, se recurre a un diagrama de casos de uso, donde se ven las interacciones de los actores con los casos de uso identificados. Para el caso del cajero automtico, puede hacerse un diagrama de casos de uso como el que sigue.

26

Validar cliente

Alimentar efectivo

Operario Cliente Descargar informacin Consultar saldo

<<use>>

Actualizar saldo Retirar efectivo <<use>>

<<use>>

Sistema Bancario Transferir fondos

Figura 4. Diagrama de casos de uso parcial del sistema de cajero automtico.

Note que en el diagrama estn varios de los casos de uso que anteriormente se identificaron para cada uno de los actores (o sea, los usuarios del sistema). No obstante, el diagrama puede ayudarnos a comprender y visualizar cmo interactan los actores del sistema. Debemos siempre hacernos a la idea de que los casos de uso tambin representan los objetivos del sistema expresados como las funcionalidades que esperamos obtener. Por lo tanto, en los diagramas de casos de uso podemos ubicar tales objetivos del sistema de una forma relativamente sencilla. Por otra parte, describir un caso de uso es, como se mencion anteriormente, describir una historia. Y para describir una historia, podra recurrirse a muchas formas de hacerlo. Por ejemplo, podra ser un texto simple y llano. Entonces la descripcin de un caso, pongamos el de Retirar efectivo, podra describirse como:

27

Caso de uso

Retirar efectivo

Descripcin El cliente, plenamente identificado ante el sistema, procede a digitar un monto mltiplo de 1000, el cual representa el monto que desea retirar. El sistema comprueba que el cliente tenga el saldo suficiente para retirar dicho monto. Si es as, el sistema comprueba que el cajero tenga la cantidad suficiente de fondos, o bien la combinacin de billetes para dispensar esa cantidad. Si es as, el efectivo se dispensa, se actualiza el saldo de la cuenta del cliente, se actualiza la informacin del efectivo disponible y las denominaciones disponibles dentro del cajero y el caso de uso termina. Observando de nuevo la Figura 4, vemos cmo se agrega un caso de uso llamado Escoger servicio. Este est relacionado con todos los casos de uso con los cuales interacta el cliente. La relacin se describe a travs de un estereotipo llamado uses (usa), el cual establece que un caso de uso usa a otro. En el siguiente captulo se profundizar ms con el tema de los casos de uso. Un caso de uso descrito en la forma que se hizo anteriormente se llama descripcin breve de casos de uso, la cual consiste en expresar en un prrafo, el escenario que se da en ste. La otra forma de descripcin que se tratar en esta unidad didctica es la llamada descripcin detallada, donde se describe un escenario en el cual, mediante una serie de pasos numerados, se especifica lo que debe cumplir el caso de uso para lograr su objetivo. Adems, se definen las condiciones previas que deben cumplirse para que el caso de uso pueda darse, los actores involucrados en ste, las posibles fallas o excepciones dentro del escenario y los cursos alternativos que podra tener el caso de uso al considerar tales fallas. Una descripcin cercanamente a una descripcin detallada, podra ser la siguiente.

28

Nombre Actor principal Meta en el contexto Condiciones previas Escenario Cliente

Retirar efectivo

Un cliente con una cuenta bancaria y tarjeta de dbito o crdito podr retirar efectivo de un cajero automtico, con lo cual se actualiza el saldo de su cuenta. El cajero automtico deber estar habilitado. El cliente previamente se ha identificado en el sistema. El caso de uso inicia cuando el cliente ha escogido la opcin de Retirar efectivo en la opcin del sistema. 1. El cliente digita el monto por retirar. 2. El sistema comprueba que el monto por retirar es menor al lmite del cliente. 3. El sistema actualiza el saldo del cliente 4. El sistema dispensa el efectivo 5. El cliente retira el efectivo de la ranura. 6. El sistema completa la operacin. En el paso 1, si el monto del retiro no es mltiplo de un nmero n, entonces el sistema indica Por favor digite un nmero mltiplo de n. (considerar n = 1000) En el paso 2, si el sistema comprueba que el monto por retirar es superior al lmite del cliente, entonces el sistema indica Por favor indique un monto menor. En el paso 2, si el monto supera el saldo del disponible en el cajero, entonces el sistema indica Por favor indique un monto menor. En el paso 3, si no puede actualizarse el saldo, entonces el sistema indica No puede realizarse la operacin en este momento y el caso de uso termina. En el paso, si el cliente no retira el efectivo despus de 10 segundos, el dinero es devuelto al cajero, la tarjeta retenida y el caso de uso termina.

Excepciones

29

Observe que la descripcin anterior es ms formal del caso de uso, que la que se denomin como breve. Los casos de uso descritos de esa forma pueden especificar condiciones que deben darse en el sistema, los cuales deben ser considerados por los ingenieros de sistemas y de software. Note, por su parte, en las excepciones; estas se refieren a un paso particular en el escenario del caso de uso. Por ejemplo, la primera excepcin que se identifica indica en el paso 2, refirindose que se trata del paso del escenario nmero 2. Ah se est describiendo un curso alternativo que debe tomar el caso de uso a la secuencia normal de pasos que se describen en el escenario (en este caso, el sistema indica el mensaje Ingrese un monto menor y queda a la espera). En algunos casos ese curso alternativo puede significar la finalizacin de ejecutar el caso de uso. Como ejercicio, trate de desarrollar la descripcin de alguno de los otros casos de uso identificados. Para ello note que las acciones descritas en el escenario son siempre las que tienen relacin con alguna accin en el software o en el sistema. Por ejemplo, acciones que haga la persona, como por decir, el cliente abre la puerta y camina hacia el cajero, no vienen al caso. En resumen, el hecho de que el UP se base en casos de uso, da la ventaja que esta forma de trabajo ayuda a identificar todas las funcionalidades de un software en perspectiva de los objetivos de los usuarios. E igualmente, tal como se ver, constituir la base para validar el trabajo tcnico que se realizar posteriormente por los ingenieros de software, en las fases de anlisis y diseo.

El UP se centra en la arquitectura: dar sustento a los casos de uso

Cuando se piensa en el trmino arquitectura, nos puede referir a un concepto de solidez, de que existe un esfuerzo de ordenar y dar una solucin de espacio, de funcionalidad a un problema o requerimiento de un cliente. En la arquitectura clsica, para resolver aspectos de una casa o de un edificio, eso es vlido. Para el caso de la arquitectura en la ingeniera de software, tenemos que acercarnos a pensar de una forma semejante. Quizs nos pueda ayudar a pensar que la arquitectura podra ser, adems de una disposicin de elementos, tambin un sistema. En una casa, los recintos como dormitorios, comedor, cochera, servicios sanitarios, entre otros, tienen una funcin y objetivos especficos por s mismos. Pero, adems, deben acomodarse, interactuar y relacionarse de la mejor forma, para que la casa funcione bien (para

30

evitar, por ejemplo, que por problemas de espacio u otros motivos, la alacena se coloque en la ducha). Con esta misma lgica, debemos comenzar a pensar en los elementos y las relaciones que deben darse en el software, para cumplir con los objetivos del sistema. Quin nos indican tales objetivos? Eso logra averiguarse a travs del trabajo que hayamos realizado, identificando casos de uso. De acuerdo con Booch, Jacobson y Rumbaugh (1999), una arquitectura se necesita para comprender el sistema, organizar el desarrollo, fomentar la reutilizacin y hacer evolucionar el sistema. Para comprender un sistema se requiere entrenar a las personas involucradas en l, desde los clientes, pasando por los ingenieros, los programadores, hasta los tcnicos en soporte, etc., de tal forma que puedan comunicarse por medio de modelos donde se expresa la solucin que va logrando obtenerse. El UML, a travs de sus diagramas, ayuda a que esta comprensin se d. Piense que en un proyecto grande pueden intervenir muchas personas las cuales, incluso, pueden estar dispersas geogrficamente. Por lo tanto, tal comunicacin estandarizada, que provoque una mayor comprensin del trabajo que se est llevando a cabo, es sumamente importante. Cuando se habla de organizar el desarrollo, puede decirse que se busca partir el problema en un conjunto de elementos previendo, eso s, que tales elementos puedan luego empalmarse. Tal divisin puede hacerse, en grandes proyectos, a travs de subsistemas. En una organizacin puede hablarse de un subsistema financiero, un subsistema de relaciones con el cliente, un subsistema de aprovisionamiento, entre muchos otros. Claro est que si bien cada uno de estos subsistemas tiene funciones y objetivos especficos, deben comunicarse y, de hecho, estn ntimamente relacionados. Es as como, por ejemplo, en una empresa fabricante, los insumos, el proceso de fabricacin de sus productos, los gastos de publicidad y mercadeo, las ventas, etc., afectan el subsistema financiero y debe preverse que estos se comunican para garantizar el buen funcionamiento de la empresa. En el caso de nuestro sistema del cajero automtico, qu subsistemas podemos encontrar? Si bien podra aparentar ser un sistema pequeo, hay elementos muy especializados los cuales, por esa naturaleza, podran separarse para su desarrollo: el manejo de los dispositivos como el lector de tarjetas, el contador de efectivo, la comunicacin con el servidor del banco, entre otros. De todas formas, al igual que se separan tareas, debern preverse las uniones o interfaces, mediante las cuales el producto requerido ser armado.

31

A lo interno de los subsistemas, igualmente, encontraremos elementos que usaremos o desarrollaremos para conseguir lo que requerimos para el producto que necesitamos crear. Hay algunos elementos esenciales que se combinan en su diseo y funcionamiento: los objetos agrupados en clases. Por fomentar la reutilizacin, debemos entender que un objetivo que se persigue en la ingeniera de software, es que las soluciones (o parte de ellas) que se han generado para un problema particular, puedan ser reutilizadas en la solucin de otro problema. Precisamente, una arquitectura busca crear componentes de software que bien pueden acomodarse en soluciones pertenecientes a otros dominios del problema. No es de esperar que una organizacin tenga que hacer un subsistema financiero, cada vez que inicia el desarrollo de un sistema nuevo. Ya sea para un sistema de ventas, de aprovisionamiento, de matrcula, o lo que fuere que emprenda la organizacin, esta sabr que existe un software orientado a las operaciones financieras que podr darles servicio en cada problema de software que tengan que resolver. Por ltimo, todo sistema est sujeto a cambios. La utilizacin misma del sistema, la formulacin de nuevos objetivos, la experiencia de la organizacin, la respuesta a nuevos retos, harn que exista la necesidad de que ste evolucione. Por lo tanto, es crucial tener una arquitectura bien planteada, fuerte, flexible, donde el impacto del cambio pueda manejarse convenientemente, y donde la ampliacin de las funciones pueda darse minimizando los efectos sobre lo que ya est hecho. Sabemos que los retos a los que se somete una arquitectura son muy altos. Es necesario, por lo tanto, que aprendamos a visualizar que todos los elementos que vayamos construyendo, tengan un proceso de construccin que permita obtener una arquitectura con caractersticas como la que hemos sealado. Los casos de uso son importantes en ese objetivo, porque nos permitirn identificar aspectos claves de la arquitectura. Algunos de stos casos de uso son esenciales en sta arquitectura, porque constituyen elementos clave en la funcionalidad esperada del sistema y, por lo tanto, harn que podamos visualizar qu aspectos en cuanto a subsistemas, componentes, clases, entre muchos otros, son vitales. En este libro nos enfocaremos principalmente en el desarrollo de modelos de clase, como parte de la formacin fundamental que debemos aprender para disear una arquitectura fuerte en el mbito del problema que tratamos. Ms adelante estudiaremos con detalle cmo hacer tales modelos.

32

No obstante cabe sealar, que es fundamental comenzar siempre por identificar los conceptos que vayamos reconociendo dentro de los requerimientos que se especifican en el problema que necesitamos resolver. Al tener identificado un concepto, debemos preguntarnos cmo se relaciona con otros conceptos y, de alguna forma, qu caractersticas de atributos y comportamiento podra tener el concepto identificado. Esto quizs llevar algn tiempo, pero en un proceso de muchas iteraciones, podramos tener un panorama completo del o de los conceptos involucrados, los cuales se expresaran mediante modelos de componentes, de clases y de interaccin. Tales modelos se explicarn a lo largo del libro y, veremos, como en ellos son fundamentales los casos de uso. Con estos modelos tendremos dos visiones de la arquitectura. Por una parte una arquitectura esttica, la cual muestra la disposicin y organizacin de los elementos del sistema y, por otra parte, la arquitectura dinmica la cual permite ver cmo interactan esos elementos para poder resolver un objetivo particular del sistema. Ese objetivo particular ha sido definido previamente como un caso de uso!

El UP es iterativo e incremental: la convergencia a una solucin

Abordar una solucin de software implica muchos riesgos. Uno de los ms importantes es, sin duda, no comprender bien los requerimientos del usuario y, por ende, desarrollar una aplicacin errnea. Al afirmar que es errnea, se asume que esta puede estar diseada, codificada y probada de la forma ms depurada tcnicamente hablando pero que lastimosamente no responde a las necesidades del cliente. Para minimizar este riesgo, el UP plantea que el desarrollo del software sea iterativo, es decir, que los proyectos de software se dividan en ciclos. Estos deben ser de una duracin relativamente corta, en general de 4 a 6 semanas. De acuerdo con Larman (2003), algunas de las ventajas de adoptar este enfoque son: Involucra continuamente a los usuarios para evaluacin, retroalimentacin y requisitos. Aborda aspectos de alto riesgo en las primeras iteraciones. Construye, en las primeras iteraciones, una arquitectura que constituye un ncleo primario consistente.

33

Verifica la calidad continuamente, ya que se desarrollan pruebas, oportuna y frecuentemente.

El riesgo de hacer un mal trabajo se reduce, pues este se circunscribe a una sola iteracin, en vez de arrastrar mucho tiempo un error, evitando as, que se descubra nicamente al final de todo el proceso. Esas caractersticas son muy valiosas para desarrollar un software que responda a las necesidades planteadas. Veamos. Involucrar continuamente al usuario en el proceso, busca tener garanta de que el trabajo que se desarrolla estar de acuerdo con las expectativas de ste ltimo. Trabajar en iteraciones o ciclos cortos implica ir generando avances de forma continua. As, el usuario logra darse cuenta de lo que va resultando del proceso conjunto de elaboracin del producto. De esa forma, tiene la posibilidad hacer sus observaciones, de manera que se enriquezca el proceso, a la vez que los ingenieros propician la forma en que los requerimientos pueden ir refinndose, o bien, mejorndose durante el proceso. Lo anterior trata de manejar una realidad ineludible: los clientes no pueden expresar todas sus necesidades al inicio. Durante el inicio del proyecto, al elaborar los casos de uso, pueden determinarse aquellos ciclos que implican mayor riesgo. Por ejemplo, dentro de la visin del negocio, un caso de uso que contenga un manejo estratgico de la relacin con los clientes, o bien, que sea fundamental en el proceso productivo de la organizacin, se identificaran como casos de uso claves dentro de las expectativas del sistema por construir. Tanto el equipo de ingeniera, como el de usuarios, pondrn especial cuidado en su construccin. El tratar estos casos de uso pueden tomarse en cuenta aspectos como:

Facilidad de uso. Quin debe usar esas funcionalidades? Qu habilidades se

espera que tenga el usuario? Deben realizarse versiones en otros idiomas? Cmo hacer fcil el uso del producto hacia el mercado meta, o el recurso humano interno que se espera use este software? incorrecto o malintencionado del software?

Robustez. Cunto tienen que protegerse esas funcionalidades ante un uso Disponibilidad.: Qu costo implica no tener disponibles las funcionalidades?
Deber tenerse un servidor espejo en caso de que falle el principal?

Datos clave para la generacin de informacin. Cunto depende la organizacin

de los datos capturados por estas funcionalidades?

34

Es posible listarse muchas ms cosas que puedan identificarse como riesgos y, dentro de stas, formular las preguntas de cules medidas pueden tomarse para minimizarlos. La posibilidad de ir convergiendo, iterativamente a la solucin, con la participacin del usuario, hace posible disminuir el riesgo de que el producto sea solamente fruto de la imaginacin de un ingeniero de software. Gente clave del negocio, como diseadores grficos, mercadlogos, personal de venta, de recursos humanos, entre otros, debe participar del proceso. Por su parte, expertos en infraestructura tecnolgica deben intervenir para disear qu arquitecturas de equipos, de telecomunicaciones y de bases de datos son las adecuadas para manejar los aspectos de mayor riesgo en el proyecto. El hecho de que estas acciones se lleven a cabo al inicio del proyecto, significa una gran ventaja sobre las metodologas tradicionales, que suelen identificarlas al final en la fase de pruebas. El anlisis de los casos de uso tambin puede generar una arquitectura base para el manejo de las aplicaciones de software por desarrollar. A medida que vayan construyndose ms casos de uso, esta podr irse enriqueciendo. Ahora bien, hemos hablado de iteraciones y de desarrollo del proyecto con esta visin, pero, cmo se visualiza ello? De acuerdo con Jacobson, Booch y Rumbaugh (1999) que son los padres del UP, las actividades e iteraciones en un proyecto de este tipo se dividen en cuatro fases, las cuales se describen a continuacin: Inicio. En esta etapa se lleva a cabo una descripcin inicial del producto final, a partir de las ideas presentadas, y se establece el anlisis del negocio para el producto. Los autores indican que en esta fase se responde a preguntas tales como: cules son las principales funciones del sistema?, cmo podra ser la arquitectura del sistema?, cul es el plan de proyectos y cunto costar desarrollar el producto? Un modelo de casos de uso empleando la descripcin breve y visualizando cules de estos casos de uso son los ms crticos para el proyecto, puede responder a la primera pregunta. En tanto, la segunda pregunta se respondera esbozando cuales seran los principales subsistemas que habra que desarrollar. Piense, por ejemplo, que si se tratara de una universidad, algunos de esos subsistemas seran: de matrcula, de registro, de planificacin docente, de administracin, entre muchos otros que puedan identificarse. En esta fase tambin se identifican y priorizan los riesgos ms importantes que deban tratarse y se estima el tiempo, los recursos y los costos del proyecto, de forma aproximada.

35

Elaboracin: en esta fase se desarrollan, de forma detallada, los casos de uso, en especial los ms crticos. Se elabora la arquitectura del sistema y se hacen las estimaciones ms precisas, por parte del director de proyecto, en cuanto a tiempo y recursos (materiales y humanos), para terminar ste. En este punto debe preguntarse si, tanto los casos de uso como la arquitectura, estn lo suficientemente estables y desarrollados, as como si los riesgos estn bien controlados y el plan bien elaborado para comprometerse con el desarrollo total del proyecto. Construccin. En esta fase se crea el producto, sustentado en las especificaciones de los casos de uso y la arquitectura elaboradas. Esta fase, si bien es en la que ms recursos se usan y est previamente especificada, no est exenta de que en el transcurso, los ingenieros descubran mejores formas de hacer las cosas, aunque se esperara que fueran cambios de menor importancia en el diseo de la arquitectura. Al final se obtiene una versin preliminar del sistema, que debe probarse. Transicin. Esta fase cubre el periodo en que se libera una versin beta del producto para que sea utilizado por un grupo reducido de usuarios. Estos, como parte de la validacin que llevan a cabo, hacen observaciones y detectan errores, que luego se corrigen. Se procede, seguidamente, con la produccin de la versin final, la cual se acompaa de la capacitacin, de los procesos de ayuda para la comunidad de usuarios, as como en la atencin de posibles fallos que se encuentren durante su aplicacin. Estos mismos usuarios pueden generar una versin incrementada del producto actual (llamada tambin, versin delta), o bien, de no ser tan urgentes, se pueden guardar para la siguiente versin del producto. Las actividades propias de la ingeniera de software, como la recopilacin de requisitos, el anlisis de stos, el diseo, la implementacin (entendida como codificacin o programacin) y las pruebas, pueden verse en qu intensidad se dan en cada una de las fases del UP. La siguiente figura puede darnos idea de ello.

36

Actividades fundamentales Requisitos

Fases Inicio

Elaboracin

Construccin

Transicin

Anlisis

Diseo

Implementacin

Pruebas

Iter #1 Iteraciones

Iter #2

...

Iter #n - 1

Iter #n

Figura 5. La conceptualizacin del UP.

Fuente: adaptacin de Booch et al. (1999)

Si nos fijamos en la figura anterior, se observa que, en primer lugar, hay que considerar que las actividades fundamentales de la ingeniera de software se encuentran presentes a lo largo de todo el proyecto. No obstante, su intensidad ser ms alta en ciertas fases. Por ejemplo, la implementacin se hace ms notoria en la fase de construccin, o bien, el diseo se hace presente en las ltimas iteraciones de la fase de elaboracin. Sin embargo, la misma naturaleza iterativa del proyecto nos revela que en cada nueva iteracin podemos hacer los cuatro tipos de actividades. Sin embargo, de acuerdo con la evolucin del proyecto, varios aspectos de la resolucin de la formulacin de requisitos, de su anlisis, o la definicin del diseo, van consolidndose y, cada vez menos, van a sufrir modificaciones. Cada iteracin debe definir un resultado en lo que al proceso del software se refiere. Un ejemplo, referido a nuestro cajero automtico, podra visualizarse de la siguiente forma

37

Fase Inicio

Actividad Requerimientos Requerimientos Requerimientos / Anlisis Requerimientos / Anlisis Anlisis / Prueba Anlisis / Diseo

Elaboracin

Anlisis / Diseo / Prueba Requerimientos / Anlisis / Diseo / Prueba Diseo Diseo / Implementacin Anlisis / Diseo Diseo / Implementacin Implementacin / Prueba Implementacin / Prueba Implementacin

Construccin

Transicin

Implementacin / Prueba Implementacin / Prueba Prueba Implementacin / Prueba

Objetivo Redactar un documento de referencia de los objetivos del proyecto. Definir un cronograma base, e identificar las funcionalidades crticas del servicio sanitario. Definir el diagrama de casos de uso, con una descripcin bsica de estos. Elaborar un documento que resuma: la definicin del proyecto, los casos de uso, los casos de uso crtico y la arquitectura bsica para el cajero automtico. Detallar los casos de uso de Retirar efectivo y Transferir fondos. Definir el modelo de clases para sustentar los casos de uso detallados en la iteracin anterior. Definir el detalle de los casos de uso de Actualizar saldo y Validar usuario. Ajustar el modelo de clases como consecuencia del anlisis de los casos de uso. Elaborar un documento con el modelo de clases de negocio y los casos de uso detallados. Diagramas de interaccin de anlisis. Definir el dispositivo de lectura de la tarjeta y la clase de diseo encargada de hacer interfaz con el sistema. Definir los dispositivos de comunicacin con el servidor central y los protocolos de seguridad y cmo definir la interfaz para el sistema de stos. Definir el detalle del caso de uso de Actualizar el saldo y verificar que puede sustentarse en la arquitectura definida o hacer el ajuste de sta. Detallar el modelo de clases con las clases de diseo. Modificar los diagramas de interaccin. Realizar un modelo de la interfaz para el uso del cajero automtico. Integrar el dispositivo lectura de tarjeta con el sistema. Elaborar un documento con la descripcin del cdigo fuente generado para el software del sistema del cajero automtico. Plan de pruebas para la transicin. Revisar los controles de la validacin del cliente. Realizar la prueba del caso de uso de Retirar efectivo. Revisin y ajuste de controles para la actualizacin del saldo y dispensar el efectivo. Realizar pruebas integrales. Simular fallas en la comunicacin con el servidor del Banco. Ajustar la versin beta del software. Elaborar la versin final del producto.

Tabla N 1. Posible marco de trabajo del sistema de cajero automtico en el marco del proceso unificado.

Note en este ejemplo, cmo en las fases iniciales se hace un gran esfuerzo por identificar un concepto general del sistema, sus aspectos claves y los riesgos ms importantes, entre otros aspectos. El trabajo posterior ir arrojando resultados concretos que son verificables por parte del usuario, a la vez que va incrementndose y refinndose la solucin que se elabora. En otras palabras, el

38

esfuerzo converge a una solucin de ingeniera que resulta adecuada a las necesidades del cliente. Tambin vase que muchas de las iteraciones combinan actividades de requerimientos, anlisis, diseo, implementacin y pruebas. Cada fase del UP debe generar lo que se denomina un hito. Esos hitos son los productos finales de cada fase. Los hitos para cada una de ellas son: Inicio. Objetivos del producto. Elaboracin. Arquitectura del producto. Construccin. Funcionalidad operativa inicial. Transicin. Versin final. En nuestro ejemplo, la ltima iteracin de cada fase muestra los productos que representan el hito esperado en el sistema del cajero automtico.

Comentarios finales sobre el UP

Un proyecto en la visin del UP, si bien la gente que integra el equipo de trabajo tiene roles especficos, no debera verse con una frontera clsica de clientes por un lado e ingenieros de software por otro. De hecho, mi experiencia personal me ha demostrado que una integracin en equipo donde, tanto los clientes, como el personal de pruebas y los ingenieros se sientan responsables y propietarios del producto final en su buen resultado, es mucho ms productivo. Laudon (Laudon, 2005) nos refiere que los sistemas de informacin son una combinacin de aspectos tcnicos y sociales. Esto nos debera indicar que ciertamente el proceso de construccin debe tener este carcter tambin. Y el UP aboga, precisamente, por un enfoque donde los usuarios son protagonistas del proyecto. La visin del UP debe hacernos entender, como ingenieros de software, que debemos estar abiertos al cambio, y dispuestos a responder con agilidad a ste en la sucesin de iteraciones. La visin tradicional nos ha hecho pensar que los proyectos tienen una forma en que, al inicio, todo debe estar definido y que, a partir de ello nos vemos algunos meses ms tarde con el cliente y que sobre esa base, cualquier cambio es motivo de angustia, enojo, reajuste de contratos u otros problemas. Ciertamente, el desarrollo de herramientas que permiten ir modelando grficamente la solucin de software, agiliza el trabajo de los ingenieros y, en ese sentido, pueden responder de forma ms eficiente al proceso que requieren los clientes. Tales herramientas aprovechan la estandarizacin metodolgica lograda por el A/DOO y apoyada por la notacin UML, la cual puede materializarse en lenguajes de programacin orientados a objetos utilizando, incluso, generadores de cdigo, los cuales, a partir del modelo creado, genera el cdigo base para

39

lenguajes como JAVA, C# u otros. Gracias a ello, las fronteras entre las actividades fundamentales de la ingeniera de software (identificadas en el UP como identificacin de requerimientos, anlisis, diseo, implementacin y pruebas) se tornan cada vez ms tenues. Paralelamente, a medida que vamos modelando el anlisis, se estn creando y haciendo parte de los modelos del diseo y estos modelos son directamente traducibles a un lenguaje de programacin.

UML y el UP
El Lenguaje Unificado de Modelacin (o UML, por sus siglas en ingls), como lo hemos mencionado al comienzo de esta obra, es una familia de diagramas orientados a apoyar el proceso de A/DOO. Vamos a ver, igualmente, que se utiliza para representar casos de uso, clases, la interaccin entre objetos de una clase, la configuracin de un sistema, entre otras muchas aplicaciones. UML es el resultado de un acuerdo entre varios precursores del A/DOO en dotar esta metodologa de una notacin estndar. El UP, al basarse en las ventajas del paradigma de orientacin a objetos, se apoya -a su vez- en la notacin que proporciona el UML. Conforme vayamos avanzando en el texto, iremos introduciendo los diagramas que nos apoyan en cada parte de la teora que vaya desarrollndose. CASOS DE USO: LA GUA DEL PROCESO Como punto de partida del proceso de construccin de software, identificar y definir los casos de uso nos ayudar a desarrollar eficientemente un proyecto, considerando siempre las necesidades de los usuarios del sistema. Los casos de uso se observan como objetivos y funcionalidades esperadas de los distintos actores que estarn interactuando con el software que se crea. Al considerar el UP (que es un proceso guiado por casos de uso), se espera, por lo tanto, que los esfuerzos que se realizan estn comprendidos en un marco de trabajo que se haya definido de acuerdo a lo que se ha identificado por parte de los clientes, en cuanto a los objetivos que deben cumplirse.

40

Cmo identificar los casos de uso de un sistema Al inicio del proyecto, tal como se ha visto anteriormente, deber hacerse un esfuerzo importante para poder identificar los casos de uso del sistema. Para ilustrar los conceptos que se desarrollarn seguidamente, se estar utilizando el ejemplo de una biblioteca de una universidad que da servicio a estudiantes, docentes y dems funcionarios de sta. Seguidamente vamos a recordar cmo se lleva a cabo el proceso de prstamo de un libro en esta biblioteca universitaria que se usar de ejemplo, como punto de partida para ilustrar los conceptos que vamos a desarrollar en este apartado del texto. El usuario puede consultar la lista de materiales bibliogrficos que hay disponibles. Esos materiales pueden ser: libros, revistas, peridicos, videos, etc. Producto de la consulta, el usuario puede averiguar si el material est disponible para prstamo, el tipo de restriccin que hay para prestarlo, as como si se le permite llevrselo fuera de la biblioteca o bien si es un material para ser consultado nicamente dentro del recinto de la Biblioteca. En el caso de los libros, si no es material restringido, la persona interesada puede ir a los estantes y ubicar el libro, o solicitar la ayuda de un bibliotecario. En el caso de los libros para sala, revistas y videos, el usuario deber ser atendido por un bibliotecario, para que ubique el material. Para realizar el prstamo, el bibliotecario lee los datos del material solicitado con un lector de cdigos de barra. Posteriormente asigna el tiempo de prstamo, dependiendo de las restricciones del material: Si el material puede prestarse fuera de la biblioteca, el bibliotecario asignar 3, 5, 7 14 das, de acuerdo con la demanda de uso. A mayor demanda, menos das se prestara. Si el material es de uso exclusivo dentro de la biblioteca, se asignarn 4 horas de prstamo en sala. Adems, para poder prestar un material, debe comprobarse que el usuario no tenga cargos por morosidad. De ser as, se le impide el prstamo fuera de sala y solo podr consultar el material dentro de la biblioteca. Un cargo por morosidad se genera en el proceso de devolucin del material prestado. Cuando el usuario lo devuelve, se corrobora si que lo est entregando lo hace dentro del plazo establecido. De lo contrario, la biblioteca genera el cargo. El usuario puede cancelar sus deudas en la biblioteca. Esta ltima genera,

41

regularmente, estados financieros para reflejar los trmites de morosidad generados y para identificar cules no han sido an cancelados. Al buscar los casos de uso de un sistema, debemos plantearnos cules son sus objetivos, bajo qu condiciones pueden lograrse y quines intervienen en su ejecucin. Los objetivos son importantes, porque nos ayudan a identificar claramente qu es lo que persigue el sistema. En nuestro caso: buscar el sistema manejar la base bibliogrfica de la biblioteca, con el registro del material, sus autores, editores, la copia de cada uno de stos? Tendr que representarse la complejidad de la informacin que representa un libro o cualquier material bibliogrfico para cumplir con los objetivos del sistema? Pareciera que este no es el caso. Nuestro asunto se limita a poder manejar lo referente a los prstamos de un material (que corresponde al objetivo del sistema que hemos tomado como ejemplo), por lo cual, las acciones por desarrollar deben limitarse a ello. Claro est, este subsistema deber comunicarse con el sistema bibliogrfico de la biblioteca, para poder referenciar el material que se tramite. Debe reconocerse en la descripcin del sistema, algunas acciones importantes que pueden resaltarse, tales como: Consultar disponibilidad de material bibliogrfico por parte del usuario. Leer datos del material bibliogrfico, por parte del bibliotecario. Consultar morosidad del usuario, por parte del bibliotecario. Registrar la accin de prstamo, por parte del bibliotecario. Registrar la accin de devolucin, por parte del bibliotecario. Generar un registro de morosidad, al procesarse la devolucin, por parte del bibliotecario. Procesar registros de morosidad, por parte del Sistema Financiero.

Todas estas acciones estn enmarcadas dentro del objetivo del sistema de brindar y administrar el servicio de prstamo de material bibliogrfico en esa universidad. Note igualmente que, adems de enumerarse esas acciones, a la par se est especificando quin hace la accin. En el fondo, lo que se est tratando de identificar, son los actores del sistema, a los que nos referiremos a continuacin.

42

Los actores del sistema

De acuerdo con Booch et al (2001), los actores son el entorno del sistema. Con ello se hace referencia a que es todo ente que interactuar con el sistema. Estos actores pueden ser personas, otros sistemas, hardware etc. Un actor asume un rol en el entorno del sistema. Es importante indicar que dicho rol puede ser asumido por distintos elementos fsicos. Ms claramente, en el caso de las personas, si por ejemplo Pedro Prez Pereira es bibliotecario en el sistema que especificamos, igualmente podra ser usuario en el momento en el que ste solicite el prstamo de un material para ser consultado por l mismo en su casa. Como hemos podido observar, los actores persiguen distintos objetivos dentro del sistema. Por ejemplo, para un bibliotecario, su objetivo sera prestar material, registrar las devoluciones, comprobar que los morosos no podrn tener servicio hasta tanto no cumplan con los requisitos exigidos para tal efecto, etc. Un usuario, por su parte, podr consultar el catlogo de material y, mediante la intermediacin de un bibliotecario, podr recibir prstamos del servicio de bibliotecas. El Sistema Financiero podr conseguir los registros contables relativos a las cuentas por cobrar y los registros de los pagos realizados por los usuarios morosos. Todos esos objetivos se logran a travs de los casos de uso que se desarrollarn en el sistema. De ello estaremos hablando a continuacin.

Casos de uso: cmo se visualizan

Hemos hablado previamente de los casos de uso. Hemos dicho que se trata de algo as como historias de lo que ocurre en el sistema. El sentido de afirmar que son historias, se debe a que stos tienen la especificacin de lo que el usuario desea del sistema. Por lo tanto, es importante que quedemos con este concepto: un caso de uso es la descripcin de lo que el usuario desea del sistema. El proceso de identificar casos de uso, puede apoyarse visualizndolos espacialmente. En UML, lo anterior se logra mediante el desarrollo de un diagrama de casos de uso. Ello puede ser un ejercicio en el cual, conforme se comienzan a identificar los actores, los objetivos y las funcionalidades del sistema, se procede a plasmarlos grficamente. Un diagrama consiste en colocar en l los actores y los casos con los que stos interactan. En la siguiente figura se muestra un ejemplo de un diagrama de ste

43

tipo. Este ejemplo no pertenece a ningn mbito de ningn problema. En ste simplemente ilustramos la notacin utilizada. Observe que los casos de uso se representan a travs de un valo y los actores mediante la figura de una persona (que por suerte no es nada compleja: es lo que aprendemos a dibujar en la escuela primaria). La interaccin entre el actor y un caso de uso en particular se expresa por medio de una lnea. Como puede notar, esto es muy sencillo. Sin embargo, esa sencillez es una forma muy poderosa de poder corroborar entre el cliente y un ingeniero lo que se requiere, en cuanto a funcionalidades de un sistema, dado que la comunicacin, usando un diagrama as, puede realizarse de una forma muy simple.

Caso de uso 1

Actor 1

Caso de uso 2

Caso de uso 3 Actor 2

Figura 6. Un diagrama de casos de uso.

En el caso de nuestro ejemplo de prstamos de una biblioteca, vamos a procurar tener claros los objetivos, las funcionalidades y los actores que estn involucrados en su desarrollo, precisamente mediante la actividad de especificar los casos de uso. Algo importante que debe considerarse antes de entrar en mayores detalles, es que la esencia de los casos de uso se basa en escribirlos, es decir, en especificarlos. El diagrama es una ayuda visual muy importante para entender, o poder plasmar el entorno del sistema y las funcionalidades esperadas. No

44

obstante, al escribir, podemos medir si realmente estamos entendiendo los objetivos del sistema. Usted y yo, en general, podemos escribir acerca de algo con propiedad, si logramos comprender sobre lo que estamos escribiendo. As que no tema. Muchas veces podemos toparnos ante actitudes que puedan esbozar una voz parecida a para qu escribe tanto?, tal vez creyendo que lo importante es diagramar clases o escribir cdigo de programacin. Considerando los objetivos y funcionalidades detalladas para nuestro ejemplo del sistema de administracin de prstamos de la biblioteca, nos sera fcil esbozar el siguiente diagrama.

Consultar Morosidad Usuario

Sistema Bibliotecario

<<uses>>

Registrar Prstamo

Usuario

Bibliotecario

<<uses>>

Leer Datos Material Consultar Material Bibliogrfico <<uses>> Registrar Devolucin Registrar Morosidad

<<extends>> <<uses>> Sistema Financiero Registrar Devolucin con Morosidad Procesar registros de morosidad

Figura 7. Diagrama de casos de uso para la administracin de prstamos de la biblioteca universitaria.

45

Hay varias cosas que debemos analizar de la figura 7 anterior. En primera instancia, note cmo todas las funcionalidades que listamos previamente aparecen como casos de uso del sistema. Tambin observe cmo aparecen cuatro actores, los cuales fueron identificados, tambin previamente, relacionados con la funcionalidad: el Bibliotecario, el Usuario, el Sistema Bibliotecario y el Sistema Financiero. Estos ltimos se refieren a actores que no son personas. Ahora los actores interactan con el sistema a travs de los casos de uso. En este caso, el Bibliotecario interacta con los casos de uso de Registrar Prstamo y Registrar Devolucin. El Usuario lo har a travs de Consultar Material Bibliogrfico. El Sistema Financiero lo har mediante el caso de Procesar Registros de Morosidad, y el Sistema Bibliotecario apoyar los procesos de Consulta de Material Bibliogrfico y Leer Datos Material.

Relaciones entre casos de uso

En la Figura 7 usted podr notar que algunos casos de uso se relacionan entre s. Un primer tipo de relacin se establece en el sentido de que, para poder realizar el objetivo planteado para un caso de uso, necesita usarse otro objetivo. Este tipo de relacin se denomina uses. Vase en el diagrama varios ejemplos de ello. Uno de ellos puede ser el caso de que, para poder registrar un prstamo, necesita leerse de cul material bibliogrfico se trata. Adicionalmente, puede existir otro tipo de relacin en el cual, un caso de uso es la especializacin de otro. Por ejemplo, Registrar Devolucin con Morosidad es, en esencia, lo mismo que Registrar Devolucin, pero incluye la capacidad de poder registrar un cargo de morosidad por una devolucin tarda. Esta relacin se denomina extends. Realizar un diagrama de casos de uso nos ayuda a visualizar, tal y como se mencion anteriormente, de qu forma los usuarios (actores) interactuarn con el sistema.

Especificacin bsica de casos de uso

En el proceso de definicin de los casos de uso, debe establecerse una especificacin de lo que hace cada uno de stos. Siguiendo con el ejemplo de la administracin de prstamos de la biblioteca, se desarrollar una especificacin bsica de los casos de uso involucrados en este sistema. Recordemos que una

46

especificacin bsica consiste en indicar, en pocas palabras, aspectos relevantes de los casos de uso. Vemoslo en el siguiente ejemplo. Caso de uso Actor (es) Consultar material bibliogrfico Usuario, Sistema bibliotecario

Descripcin. Un usuario consulta la existencia de un material bibliogrfico de su inters. El Sistema Bibliotecario apoya la bsqueda de este material a travs de parmetros como ttulo, autor, palabras calve, entre otros. Adems, puede visualizar qu restricciones de prstamo tiene este material y la disponibilidad de copias. En el caso de que la restriccin del material indique que no puede sacarse de la biblioteca, el sistema proporcionar el cdigo del material para que sea utilizado posteriormente por el bibliotecario en ventanilla. Caso de uso Registrar prstamo

Actor (es) Bibliotecario Descripcin. El bibliotecario pide al usuario su identificacin y consulta el estado de morosidad de la persona. Si est libre de cargos, lee los datos de un material bibliogrfico que ser prestado. Los datos se leen a travs de una etiqueta de cdigo de barras que viene en el material. El sistema, de acuerdo con las restricciones y la frecuencia de uso del material, indica el tiempo de prstamo conveniente para ste. El bibliotecario registra finalmente los datos del material prestado. Caso de uso Actor (es) Consultar morosidad usuario Bibliotecario

Descripcin. Al realizar el trmite de un prstamo, el bibliotecario debe consultar el estado de la morosidad de un usuario. Esta consulta deber devolver una indicacin al bibliotecario y al resto del proceso, si puede continuarse o no puede seguirse con el trmite del prstamo. Caso de uso Actor (es) Leer datos del material Bibliotecario, Sistema Bibliotecario

Descripcin. Al realizar el trmite del material bibliogrfico, bien sea para prstamo o para devolucin, el bibliotecario usa un cdigo de barras para poder leer los datos de dicho material.

47

Caso de uso Actor (es)

Registrar devolucin Bibliotecario

Descripcin. El bibliotecario, una vez que lee los datos del material devuelto, si no hay morosidad, procede a dar por devuelto dicho material.

Caso de uso Actor (es)

Registrar devolucin con morosidad Bibliotecario

Descripcin. Al procesar una devolucin, luego de leerse los datos del material prestado, si se detecta que el material est sujeto a morosidad, se habilita un proceso para tramitar la multa que el usuario debe pagar. El sistema calcula dicha multa y el bibliotecario termina de registrar los datos de la devolucin y de la multa para el usuario.

Caso de uso Actor (es)

Registrar morosidad Bibliotecario

Descripcin. Se proporcionan los datos del material bibliogrfico, el usuario que incurre en morosidad y la multa asociada, para registrar la multa por cobrar y el estado de moroso para el usuario

Caso de uso Actor (es)

Procesar registros de morosidad Sistema financiero

Descripcin. Procesa los registros que debe poner al cobro y los que ya ha pagado el usuario. Con stos ltimos, el sistema chequea si debe quitar el estado de moroso a dicho usuario.

48

Logrado este avance en la especificacin, consigue tenerse una mejor comprensin de lo que debe realizar el sistema. Adems, pueden visualizarse cules son crticos para el desarrollo, por su rol dentro del sistema o por las complejidades que acarrea, y, por lo tanto, cules son de mayor riesgo. Estos ltimos son los que debern ser tratados con especial cuidado. Siguiendo este razonamiento, de aqu en adelante vamos a enfocarnos en dos aspectos crticos relacionados con el ejemplo que estamos desarrollando: el prstamo y la devolucin de libros. Estos casos de uso, adems, relacionan muchos otros que tambin son importantes de detallar. Para los que no se especifiquen, usted ya tendr suficiente gua de cmo podra profundizar ms en ellos. En este caso tambin consideramos que al detallar las funcionalidades de prstamo y la devolucin, prcticamente se estara definiendo toda la arquitectura necesaria para sostener el sistema, esto es, tambin, todos los casos de uso. Si no fuera as ES PARTE DE LA NATURALEZA DEL UP! Quizs al incorporar la definicin de otros casos de uso, algunos ajustes, seguramente menores, habr que realizar en la arquitectura del sistema.

Especificacin detallada de casos de uso

La especificacin bsica debera cerrar un punto del proyecto en la cual ya podemos tener resultados en cuanto a identificar actores del sistema, los objetivos, las funcionalidades y comprender cada una de ellas. No obstante, en mucho, la comprensin de un trabajo de software debe ir convergiendo de lo general a lo especfico. En ese sentido tambin podemos ir descubriendo detalles cada vez ms importantes y reveladores del problema por solucionar. Es as como, en un segundo momento de especificacin de casos de uso, debemos detallar -an ms- su especificacin buscando, por una parte, descubrir mayor informacin en cuanto a las necesidades y consecuencias en el sistema de la ejecucin de stos y, por otra parte, intentando que proporcionen una gua para poder definir varios aspectos de la arquitectura y del proceso general de diseo e implementacin del software. Esta especificacin es crucial en el contexto que estamos trabajando. Recuerde que el UP es guiado por los casos de uso.

49

Elementos de una especificacin detallada

Booch et al. (2001) sugieren estructurar la especificacin de los casos de uso con los siguientes elementos y detalles: Las condiciones previas que deben cumplirse para que el caso de uso pueda ejecutarse. Una secuencia, normalmente ordenada y numerada de los pasos que se dan dentro del caso de uso. El primer paso debera indicar cmo y cundo empieza el caso de uso. En cada paso deber indicarse, cuando sea conveniente, qu acciones no son permitidas y qu aspectos son responsabilidad del actor y cules son del sistema. Veamos cmo terminan los casos de uso. Las acciones alternativas que puedan ocurrir en la ejecucin de los casos de uso, producto de situaciones anmalas (excepciones) u otras consideraciones. El estado en que queda el sistema y las acciones generadas en ste, como consecuencia de la ejecucin del caso de uso (visto como condiciones posteriores). Otros autores pueden sugerir incluir alguna otra informacin que enriquezca (o complique) la especificacin de un caso de uso detallado. Vamos a valernos de estos elementos que proporcionan una idea clara y completa de lo que es esta descripcin. Esto ltimo no contradice el hecho de que en el contexto especfico de una organizacin puedan definirse variaciones para que se desarrolle el proyecto a la conveniencia de un grupo o equipo de proyecto. Vamos a desarrollar la especificacin de uno de los casos de uso del sistema de administracin de prstamos de libros, como un primer ejemplo que ilustre lo que venimos comentando en los apartados previos. Para tal caso estaremos analizando el caso de uso de Registrar Prstamo. Vamos a recordar por un momento la especificacin bsica de ste. Caso de uso Actor (es) Registrar prstamo Bibliotecario

Descripcin. El bibliotecario pide al usuario su identificacin y consulta el estado de morosidad de la persona. Si no se identifica como moroso, lee los datos del material bibliogrfico que ser prestado. Los datos se leen a travs de una etiqueta de cdigo de barras que viene en el material. El sistema, de acuerdo a las restricciones y la frecuencia de uso del material, indica el tiempo de prstamo conveniente para ste. El bibliotecario registra finalmente los datos del material prestado.

50

Con esta base, empezar a desarrollar la especificacin detallada del caso de uso en cuestin. En primer lugar, podemos esbozar algunas condiciones previas producto de la especificacin bsica del objetivo? Nos es fcil definir qu requerir el bibliotecario para poder desarrollar el caso de uso? En este caso contamos con algunos aspectos necesarios para poder ejecutar el caso de uso. En primer lugar, el bibliotecario deber tener en sus manos el material por prestar, ya sea que el usuario se lo haya proporcionado, o bien que l mismo haya tenido que buscarlo, dado que es de prstamo restringido. Adems, el usuario debe contar con la identificacin que lo habilite para poder usar el servicio de biblioteca. Quizs podamos esbozar algunas otras condiciones, pero stas son las que son crticas para poder ejecutar el prstamo. De igual forma, podemos pensar cules son las condiciones posteriores que deben producirse al darse el caso de uso. En definitiva, deber haberse creado un registro de prstamo asociado al usuario que solicit el material, indicando, adems, la fecha y el material prestado. A su vez, el material debe quedar con el estado de prestado. La secuencia de pasos podra irse construyendo de la siguiente forma. - El caso de uso comienza cuando el Bibliotecario ingresa al sistema la identificacin del Usuario. El Sistema le indica si el Usuario es vlido. - El Sistema revela, adems, si el Usuario tiene algn registro de morosidad. - Una vez comprobados los pasos anteriores, el Bibliotecario lee del Sistema Bibliotecario, la informacin del material que va a prestarse, a travs de un lector de cdigo de barras. En ningn caso puede prestarse otra copia del mismo material al mismo usuario, lo cual se comprueba por parte del Sistema cuando se hace esta lectura. - El Sistema indica si el material puede ser prestado solo para uso interno de la biblioteca y el tiempo que puede ser prestado en cualquier caso. - El Bibliotecario registra el prstamo del material y el caso de uso termina. Note que, en primer lugar, se est cumpliendo con el objetivo de registrar el prstamo. Adems, se estn especificando algunos controles importantes, como comprobar que el usuario est afiliado a la biblioteca, que no tenga morosidad,

51

que no se le preste otra copia del mismo material y si ese mismo material es restringido o no, determinando dnde y cunto puede ser prestado ste. Los pasos anteriores los vamos a denominar como el curso normal de eventos, es decir, que esos pasos son los que se dan en la ejecucin normal del caso de uso. Esto tambin autores como Larman (2003) y Pressman (2006) lo llaman escenario. Usaremos indistintamente ambas denominaciones. Al pensar que existe un curso normal de eventos, da cabida a especular que podran existir otras alternativas de ejecutar el caso de uso. Esto los llamaremos cursos alternativos y se especifican refirindose a un paso que se ha numerado en el escenario del caso de uso. As tendramos que ver, paso por paso, qu podra ser un curso alternativo en cada uno de stos pasos. En el paso 1 se espera que el sistema compruebe que el Usuario no est registrado en la Biblioteca, por lo cual el caso de uso termina. Esto significa que no pueden darse los siguientes pasos despus del 1. En el paso 2, si el Usuario est moroso, el caso de uso termina. En el paso 3, un hecho que podra presentarse es que el cdigo de barras del libro est ilegible, por lo cual el Bibliotecario deba ingresar este directamente en un campo de edicin de la pantalla. En el paso 3, tambin, puede comprobarse que el Usuario ya tenga una copia del mismo material asignado en otro prstamo, por lo cual el caso de uso termina. En el paso 4, luego de indicarle al Usuario las restricciones del prstamo, ste puede decidir no aceptar las condiciones, por lo cual el Bibliotecario cancela la ejecucin del caso de uso. Una plantilla de esta descripcin detallada del caso de uso, puede sugerirse que sea de la siguiente forma.

52

Casos de Uso Objetivo Actores Condiciones previas Escenario

Registrar prstamo Registrar la informacin del prstamo de un material bibliogrfico que se hace a un usuario de la biblioteca de la Universidad Bibliotecario El Bibliotecario deber tener en sus manos el material a prestar, ya sea que el usuario se lo haya proporcionado, o bien que el Bibliotecario haya tenido que buscarlo, dado que es de prstamo restringido. Adems, debe contar con la identificacin del usuario que lo habilite para poder usar el servicio de la biblioteca. El caso de uso comienza cuando el Bibliotecario ingresa al Sistema la identificacin del Usuario. El Sistema le indica si el Usuario es vlido. El Sistema, le indica, adems, si el Usuario tiene algn registro de morosidad. Una vez comprobados los pasos anteriores, el Bibliotecario lee del Sistema Bibliotecario la informacin del material que va a prestarse, a travs de un lector de cdigo de barras. En ningn caso puede prestarse otra copia del mismo material al mismo Usuario, lo cual se comprueba por parte del Sistema cuando se hace esta lectura. El Sistema indica si el material puede ser prestado solo para uso interno de la Biblioteca y el tiempo que puede ser prestado en cualquier caso. El Bibliotecario registra el prstamo del material y el caso de uso termina. En el paso 1, de comprobarse que el Usuario no est registrado en la biblioteca, el caso de uso termina. En el paso 2, si el Usuario est moroso, el caso de uso termina. En el paso 3, si el cdigo de barras del libro est ilegible, el Bibliotecario deber ingresar este directamente en un campo de edicin de la pantalla. En el paso 3, de comprobarse que el Usuario ya tiene una copia del mismo material asignado en otro prstamo, el caso de uso termina. En el paso 4, luego de indicarle al Usuario las restricciones del prstamo, ste puede decidir no aceptar las condiciones, por lo cual el Bibliotecario termina la ejecucin del caso de uso. De cumplirse el paso 5, el Sistema guarda el registro del prstamo efectuado al Usuario. El material debe quedar en estado de prestado.

Excepciones o cursos alternativos

Condiciones posteriores

Observe que la informacin de esta especificacin va, ciertamente, logrando ms rico el detalle de la descripcin, haciendo resaltar controles, responsabilidades del sistema y de los actores, as como condiciones que deben darse previa y posteriormente al prstamo. Pero otro elemento poderoso es que est escrito en lenguaje natural, por lo que puede ser validado junto con el cliente del sistema. EXCELENTE! De igual forma podemos proceder a detallar el caso de uso, cuando se trata de la devolucin de un libro. En el anlisis inicial reconocimos dos casos de uso para esta funcin: Registrar Devolucin y Registrar Devolucin con Morosidad.

53

Revisemos la especificacin bsica de estos casos de uso. Caso de uso Actor (es) Registrar devolucin Bibliotecario

Descripcin. El Bibliotecario, una vez que lee los datos del material devuelto, si no hay morosidad, procede a dar por devuelto dicho material.

Caso de uso Registrar devolucin con morosidad Actor (es) Bibliotecario

Descripcin. Al procesar una devolucin, luego de leerse los datos del material prestado, si se detecta que el material est sujeto a morosidad, se habilita un proceso para tramitar la multa que el Usuario debe pagar. El sistema calcula dicha multa y el Bibliotecario termina de registrar los datos de la devolucin y de la multa para el Usuario.

Al examinar stas especificaciones podramos pensar que simplemente un condicional diferenciara una de otra (chequear la condicin de morosidad) y que podra manejarse como una excepcin en la descripcin detallada del escenario de alguno de los dos casos de uso. No obstante, los mecanismos que se desatan en la devolucin con morosidad, como podr observarse de la descripcin del caso de uso, pueden ser mucho ms complejos, como calcular la multa, registrar un registro de morosidad, entre otros. Por lo tanto, podra ser ms ntido especificar uno y otro separadamente. De igual forma, adelantndonos un poco en el tiempo del proyecto, recuerde que, gracias al paradigma de orientacin a objetos, tenemos un recurso llamado polimorfismo que nos puede ayudar a definir, en el momento de disear la solucin, dos mtodos con nombres iguales. Ms adelante, cuando definamos la arquitectura, retomaremos este aspecto de la solucin. A continuacin veremos la definicin de estos casos de uso, de forma detallada. Una devolucin, como precondicin, debera haber comprobado la morosidad del material, de tal forma que el sistema sepa cul caso de uso debera usarse. En

54

tal caso no le estamos cargando a ninguno de los casos de uso la responsabilidad de saber cul debe ejecutarse. No obstante, tal accin no la observaremos directamente reflejada en el diagrama de casos de uso. Alguien nos ayudar en su momento. Ese alguien ser una clase de gestin, la cual estudiaremos con mayor detalle ms adelante. Otra condicin previa que puede parecer obvia, pero que necesitamos controlar (a veces tendemos a obviar lo obvio), es que el material por procesar debe estar en condicin de prestado. En cualquiera de los dos casos, al final debe registrarse el material como devuelto. Este es el compromiso o contrato de estos casos de uso. El escenario de los casos de uso ser el que maneje las acciones del registro de la devolucin. Deben tomarse en cuenta las responsabilidades compartidas entre lo que hace el actor y lo que responde el sistema en cada caso, cuando sea pertinente. Vamos a escribir el detalle de los dos casos de uso y usted podr observarlos y seguramente familiarizarse ms con esta forma de especificacin. Caso de uso Objetivo Actores Condiciones previas Registrar devolucin Registrar la devolucin de un material bibliogrfico previamente prestado. Bibliotecario En la comprobacin de la morosidad del prstamo, este debi haber estado sin morosidad. El material debe tener el estado de prestado. El caso de uso empieza cuando el Bibliotecario introduce el cdigo del material que fue prestado mediante el cdigo de barras. El sistema registra la devolucin e indica: La devolucin del (Libro / Revista / Video) xxxx fue registrada con xito. En el paso 1, si el cdigo de barras del libro est ilegible, el Bibliotecario deber ingresar este directamente en un campo de edicin de la pantalla. De cumplirse el paso 2, el sistema actualiza el registro del prstamo, grabando la fecha de devolucin y cambiando el estado del material a devuelto y ubicando el estado del prstamo en Cerrado normal.

Escenario

Excepciones o cursos alternativos Condiciones posteriores

55

Mientras tanto, para el caso de uso de Registrar devolucin con morosidad tendramos lo siguiente. Caso de uso Objetivo Actores Condiciones previas Escenario Registrar devolucin con morosidad Registrar la devolucin de un material bibliogrfico previamente prestado, el cual tiene morosidad asociada Bibliotecario En la comprobacin de la morosidad del prstamo, este debi haber estado con morosidad. El material debe tener el estado de prestado. El caso de uso empieza cuando el Bibliotecario introduce el cdigo del material que fue prestado mediante el cdigo de barras. El sistema calcula el monto correspondiente por morosidad, de acuerdo con el tipo de material, las restricciones de uso y el retraso en tiempo. El Usuario procede a dar Aceptar al registro de la devolucin, visualizando el monto del cobro que se le realizar al Usuario. El sistema registra la devolucin creando a su vez un registro de morosidad. En el paso 1, si el cdigo de barras del libro est ilegible, el Bibliotecario deber ingresar este directamente en un campo de edicin de la pantalla. De cumplirse el paso 4, el sistema actualiza el registro del prstamo, grabando la fecha de devolucin y cambiando el estado del material a devuelto y colocando el estado del prstamo en Cerrado con morosidad.

Excepciones o cursos alternativos Condiciones posteriores

Finalmente, observe cmo los casos de uso sirven para poder especificar de una forma relativamente simple, pero poderosa, los objetivos que tiene un sistema, expresando las funcionalidades que se esperan de l. Las funcionalidades vienen a ser verificadas por los clientes del sistema y las pueden realizar cmodamente, puesto que estn escritas en un lenguaje natural. Adems, podemos asegurarnos que lo que vayamos a desarrollar est aprobado y comprobado por los interesados. Veremos, en los siguientes captulos, que la buena definicin de los casos de uso ser fundamental para guiar el proceso de desarrollo de la ingeniera de software en lo que se refiere al anlisis y diseo de la arquitectura.

56

EJERCICIOS DE AUTOEVALUACIN 1. 2. 3. 4. Mencione y ejemplifique los dos fundamentos de la abstraccin del paradigma de orientacin a objetos. Qu son los conceptos de identidad y estado de un objeto? Qu es una clase? encapsulamiento? Cmo se relaciona el concepto de clase con el

Construya una jerarqua de clases a partir de la clasificacin de artculos en una tienda de departamentos. Explique mediante esta clasificacin el concepto de herencia y, adems, ejemplifique el concepto de polimorfismo. Explique qu es el Proceso Unificado. Para esta explicacin bsese en las tres caractersticas propias del Proceso Unificado. Explique los conceptos de caso de uso y de actor. De ejemplos distintos a los vistos en el libro sobre casos de uso en donde se pueda tener representandos actores que son y no son personas. Para el problema que se le presenta a continuacin, elabore lo siguiente: El diagrama de casos de uso. La descripcin breve de los casos de uso. La identificacin los casos de uso ms riesgosos. Justificar por qu usted los considera as. La estrategia de cmo ir desarrollando los casos de uso usando Proceso Unificado (por ejemplo, con cules casos de uso ir empezando, en cules fases los ir especificando, qu ira obteniendo del desarrollo de stos). La elaboracin en detalle de uno de los casos de uso identificados como riesgosos.

5. 6.

7.

La empresa de seguros mdicos Aseguro, le ha contratado para desarrollar un software que permita apoyar la administracin de las actividades de ste. Para ello, esta empresa quiere facilitar a clnicas y hospitales, un sitio en Internet que permita acceder a los datos de los asegurados, as como procesar lo referente a los pagos que deben cobrarse por deducible a stos y los que deben realizarse a hospitales y clnicas como parte de los servicios brindados.

57

Cuando se da una atencin, el asegurado debe indicar al recepcionista en el hospital que es beneficiario de Aseguro. ste le muestra su credencial y posteriormente pasa a recibir los servicios mdicos del caso. Cuando la atencin termina, el hospital le da al asegurado una copia de la factura. El personal administrativo del hospital, en el mismo sitio Web, ingresa los datos y los costos de la atencin suministrada a los pacientes. Algunos hospitales han interconectado sus sistemas con los de Aseguro para el intercambio electrnico de datos de la atencin a pacientes. Con los datos suministrados por el hospital, Aseguro emite los pagos para stos, adems de poner al cobro los montos por deducible para los asegurados.

58

CAPTULO

EL MODELO CONCEPTUAL DE CLASES: LA EXPRESIN DE LOS CONCEPTOS DEL PROBLEMA

SUMARIO CONSIDERACIONES PRELIMINARES

DEFINICIN DEL MODELO CONCEPTUAL

Modelando los conceptos Categoras de clases conceptuales

CASOS DE USO E IDENTIFICACIN DE CLASES CONCEPTUALES DIFERENCIAR CONCEPTOS QUE SON CLASES Y CONCEPTOS QUE SON ATRIBUTOS
RELACIONES CONCEPTUALES ENTRE CLASES Cardinalidad de las relaciones Nombre de las relaciones Relaciones mltiples entre clases Relaciones hacia la misma clase Especificacin de conceptos en el modelo de clases

AADIENDO ATRIBUTOS AL MODELO CONCEPTUAL DEFINIENDO OPERACIONES EN EL MODELO

59

OBJETIVOS Una vez que usted estudie este captulo, podr llevar a cabo cada una de las siguientes actividades de aprendizaje, que le servirn para comprobar cunto ha aprendido de este tema - Justificar la importancia de los casos de uso como forma de guiar el desarrollo en el Proceso Unificado. - Identificar, a partir de los casos de uso, conceptos claves para la identificacin y desarrollo de clases conceptuales. - Diferenciar lo que puede ser una clase conceptual de lo que es un atributo dentro de una clase. - Indicar cmo se relacionan las clases entre ellas, identificando, adems, un nombre para la relacin y su cardinalidad. - Describir que son las relaciones mltiples entre el mismo par de clases. - Identificar relaciones entre la misma clase. - Explicar qu se entiende por especificacin de clases y solucionar situaciones de modelaje de clases usando dicho concepto. - Experimentar el proceso iterativo de la definicin del modelo conceptual de clases a partir del anlisis de un caso de uso y de la incorporacin de otros casos de uso en dicho modelo. - A partir del anlisis del escenario de los casos de uso, identificar las operaciones o mtodos necesarios que deben tener las clases.

60

CONSIDERACIONES PRELIMINARES En este captulo nos propondremos conocer los trabajos que deben realizarse para poder crear un modelo conceptual de clases. Esto resulta especialmente importante debido a que, por una parte, obtendremos la base para crear los elementos de software que podrn apoyar la implementacin de los casos de uso y, por otra parte, sern la gua del trabajo que transforman las abstracciones conceptuales identificadas en clases conceptuales, hacia las clases de diseo las cuales sern las que orientarn el trabajo de codificacin que debe realizarse. Por lo tanto, generar un modelo conceptual adecuado, resulta clave en todo el proceso de ingeniera que seguimos en el ADOO. Ya nos hemos referido en el primer captulo acerca de las clases en el paradigma de orientacin a objetos. Si recordamos, all estudiamos que las clases son creadas con el fin de agrupar todos los objetos que de la abstraccin a la cual tratbamos de acercarnos. Por ejemplo, una clase Silla debe identificar todos los objetos de tipo silla que hay en el mundo. Esta primera aproximacin que hemos dado a las clases debe ayudarnos ahora. Hay que tener presente que al buscar definir clases, buscamos especificar las caractersticas que deben ser comunes a todos los objetos de dicha clase, tanto en sus caractersticas vistas como atributos, y en su comportamiento que se expresa como operaciones o mtodos. En el mbito del ADOO tales abstracciones son vistas como los conceptos que se hallan en el espacio del problema que tratamos de solucionar. Para poder ir comprendiendo el proceso de definicin de estas clases, vamos a seguir desarrollando el ejemplo referente a nuestro sistema de prstamo bibliotecario. DEFINICIN DEL MODELO CONCEPTUAL Recordemos que, en general, nos estamos enfrentando a un proceso evolutivo de definicin de software. Los modelos que desarrollemos a travs de diagramas UML irn entrando en mayor detalle conforme pasan las iteraciones en las fases del UP. En el captulo anterior vimos cmo los casos de uso pasan por ese proceso de irse definiendo con mayor detalle, de igual forma suceder con las clases.

61

En este punto tenemos que considerar lo siguiente. Hay varios tipos de clases dentro de las cuales podemos encontrar las siguientes, de acuerdo con Pressmann (2005):

Clases de anlisis o conceptuales. Son las clases producidas a partir de ir

modelando las abstracciones y conceptos involucrados en el espacio de una solucin. Por ejemplo, en un sistema de ventas, estaremos buscando modelar abstracciones y conceptos como: producto, inventario, factura, entre muchos otros. En este tipo de clases no se busca entrar en mucho detalle, sino ms bien, busca identificar, a gran nivel, qu conceptos estn involucrados en la solucin y cmo se relacionan stas, modelando los diagramas necesarios para ello.

Clases de negocio. Este tipo de clases da un mayor nivel de refinamiento a las

clases de anlisis, buscando proveer mayor precisin para la definicin del software. Se busca detallar los atributos y las operaciones que deben tener las clases.

Clases de proceso o gestin. Este tipo de clases coordinan acciones que se dan
entre clases de negocios para un propsito del software. Por ejemplo, un proceso que coordine una venta, posiblemente tenga que usar objetos involucrados con factura, inventario y producto. Las acciones de esos objetos son administradas por una clase de gestin.

Clases persistentes. Son clases que representan almacenamiento de datos. De

igual forma, podemos encontrar en estas clases los servicios para poder grabar, en una base de datos, la informacin que se maneja en las clases de negocios. Clases de sistema. Son las clases que estn especializadas en la interaccin con el sistema operativo y los dispositivos de hardware involucrados en la solucin.

En este texto vamos a prestar especial atencin a las tres primeras clases, pues a travs de ellas se conforma, en gran medida, la solucin que, como ingenieros de software, debemos crear. Especialmente quiere resaltarse, nuevamente, que la definicin de tales clases es un proceso. Recurdese que, tanto el anlisis, como el diseo, presentan una caracterstica importante de refinamiento, el cual se espera que, conforme pasen iteraciones en el proceso de construccin del software, se definan en mayor medida las caractersticas de las clases. Y dentro de la clasificacin que acabamos de ver, pasar de las clases conceptuales, a las clases de diseo y poder identificar las clases de gestin adecuadas, es parte de ese proceso. Sin embargo este refinamiento es mucho ms directo cuando se utiliza el ADOO, usando diagramas como los que provee UML. Veremos, tal como destaca Larman,

62

que las transiciones entre un modelo conceptual, a un modelo de clases de negocio, es un proceso natural de dicho refinamiento.

Modelando los conceptos

Cuando comenzamos a tratar de elaborar un modelo de clases, debemos saber que no es una tarea fcil. Quizs si se posee mucha experiencia, poder intuir y definir clases se vuelve un proceso muy natural en un ingeniero de software, pero no es simple. Por eso debemos comenzar a realizar esbozos de los conceptos alrededor del dominio del problema que queremos modelar. Por otra parte, tambin tenemos que considerar que esos conceptos dependen mucho del contexto organizacional o cultural donde se ubiquen. Por ello usted debe estar familiarizado con dicho contexto. Por ejemplo, en la tabla que presentamos a continuacin, se muestran algunos conceptos propios de algunos trabajos en los que he participado:

Entorno Comercializacin elctrica Asistencia social Universidad

Conceptos Abonado, Facturacin, Medidor, Ciclo de lectura, Ubicacin, Ruta de lectura Familia, Beneficios, Subsidios, Medicin de pobreza, Resolucin, Presupuesto Plan de Estudios, Materias, Cursos, Proyecto de Investigacin, Matrcula

Estamos seguros que usted sabe qu significan algunos de esos conceptos y otros seguramente que no. Por lo tanto, debemos asegurarnos, incluso si tuviramos nocin de su significado, de qu es lo que las personas entienden por ellos y qu significan en el contexto en el que se encuentran. Elaborar un diccionario o glosario de esos trminos, siempre es una buena prctica. Pero, Cmo podremos comenzar a ubicar esos conceptos? Recordemos que cuando definimos clases, vimos tres partes que las componen: su nombre, sus atributos y sus operaciones o mtodos. Cuando comencemos a modelar los conceptos no vamos a detenernos a detallar -a gran nivel- TODOS sus atributos y TODAS sus operaciones, sino que nos concentraremos en identificar, en un nivel muy alto, qu conceptos estn involucrados.

63

Posiblemente, podemos definir uno que otro atributo u operacin significativa, pero, tal como lo mencionamos, sin abundar en detalles. Un primer ejemplo que quizs le resulte muy familiar. Imagine todo lo que puede pasar en un sistema cuando usted est pagando la compra de vveres, en la caja de un supermercado. Qu conceptos que podran ser potenciales clases estn reunindose all? Usted est viendo que un cajero pasa productos por un lector de cdigos de barras, que al mismo tiempo est conformndose el detalle de una factura, que podra estar actualizndose algo como un inventario, quizs el cliente podra estar presentando su tarjeta de cliente frecuente. En este momento podemos hacer una lista de conceptos que pueden ser necesarios para poder modelar la solucin: productos, lector de cdigos de barras, factura, inventario, cliente, tarjeta. Vea que tales conceptos pueden ser personas (cajero, cliente), o dispositivos (lector de cdigos de barra); pueden ser tambin elementos de informacin (tarjeta, factura), cosas muy concretas (productos) o tambin procesos que se llevan a cabo (inventario). Por el momento, no vamos a ir ms all de esbozar algo que podemos intuir del contexto que estamos observando al ver funcionar una caja en un supermercado. Al utilizar una herramienta para diagramar, podemos utilizar el modelo de clases para comenzar a dibujar estos conceptos. Eso se muestra en la siguiente figura:
Cajero Producto

Factura

ExistenciaProducto

Cliente

Venta

Tarjeta

Figura 8. Conceptos en un punto de venta de un supermercado.

Note que en la Figura 8 solamente hay una serie de cajas las cuales, por el momento, expresan un concepto potencial: Cajero, Producto, Cliente, etc. En el ADOO este es un paso fundamental, pues estamos obteniendo los insumos para ir desarrollando nuestro modelo de clases.

64

Tenemos que tomar en cuenta que estamos tratando con un sistema. Tal como lo mencionbamos en el captulo anterior, en lo referente al UP, los elementos deben organizarse y combinarse de alguna forma para que puedan expresar la solucin que queremos. Como sistema, esas cajas inconexas que vemos en la Figura 8, deberan tener alguna relacin. Esas relaciones buscan, en primer lugar, tratar de establecer cmo podran servirse unas de otras, es decir, cmo se asocian, cmo colaboran, cmo se organizan para un propsito comn: brindar el o los servicios que esperan ofrecerse a travs del sistema. Este ejemplo lo hemos venido desarrollando, usando nuestra imaginacin: como si de pronto pudiramos ir adivinando qu hay detrs de algo que nos resulta familiar, por ejemplo, ir al supermercado y ver cmo es un proceso de compras. Sin embargo, ya hemos visto que los objetivos y funcionalidades del sistema pueden expresarse a travs de los casos de uso. Entonces, si al final del prrafo transanterior se dice que los elementos se organizan para que el sistema pueda brindar el o los servicios que se esperan ofrecerse, esto ya debe estar manifiesto cuando elaboramos los casos de uso. Es primordial anotar, por lo tanto, que uno de los insumos importantes que podemos tener para identificar clases potenciales, son los casos de uso. A esto volveremos ms adelante, cuando retomemos el ejemplo de nuestra biblioteca. Volviendo al caso del punto de venta del supermercado, podemos ver en la siguiente figura, algunas relaciones que podemos visualizar en nuestro modelo conceptual.

65

Cajero

Producto

DESCRIBE ESTADO

CREA Y REGISTRA Factura DetalleVenta INCLUYE ACTUALIZA ExistenciaProducto

SE LE HACE A Cliente IDENTIFICA

Tarjeta

Figura 9. Relaciones en el modelo conceptual.

En la Figura 9 podemos observar cmo los elementos pueden ser descritos, tambin, en la forma en que se asocian con los otros. Adems, podemos darle nombre a esas relaciones. Por ejemplo, Cajero con respecto a la Factura, indica que el primero la crea y la registra en el sistema. Por otra parte, de Factura hacia el Cliente se dice que la primera se le hace para el segundo. La ExistenciaProducto dice que describe el estado del Producto en el sistema del supermercado (por ejemplo cunto hay del producto, dnde est localizado, etc.). Poder establecer estas relaciones y, adems, estar en capacidad de darles nombres, se lograr si comprendemos bien el contexto del problema. La forma que tenemos a mano para poder lograrlo, consiste en ir conociendo los objetivos del sistema, estar al corriente sobre qu es lo que hace para lograr cada uno de stos objetivos, identificando conceptos y colaboraciones importantes. Es decir, los casos de uso. Que el UP est guiado por casos de uso y orientado a la arquitectura, no es casualidad. Ac comenzamos a ver cmo convergen. Sigamos desarrollando nuestro ejemplo del sistema de prstamos de la biblioteca para ir descubriendo ms aspectos relativos a este proceso.

66

Categoras de clases conceptuales

Larman (2005) establece dos estrategias principales para poder identificar clases conceptuales: Utilizacin de una lista de categoras de clases conceptuales Identificacin de frases nominales

Para el primer caso, en la tabla que se incluye a continuacin, se presentan las categoras principales propuestas por dicho autor.

Categora de clase conceptual Ejemplos Objetos tangibles o fsicos Libro, Revista Especificaciones, diseos o descripciones de las Especificacin del producto (copias de un libro) cosas Lugares Transacciones Lneas de la transaccin Roles de la gente Contenedores de otras cosas Cosas en un contenedor Otros sistemas informticos o dispositivos externos al sistema Organizaciones Hechos Catlogos Registros de finanzas, trabajos, contratos, cuestiones legales Instrumentos y servicios financieros Manuales, documentos, libros Biblioteca Central, Biblioteca de Sede, Biblioteca de Salud Prstamo, Devolucin de un material Cada copia de material prestado en una transaccin de Prstamo Usuario, Bibliotecario Estante Libro Sistema financiero Biblioteca Prstamo, Devolucin, Mora por devolucin Catlogo de materiales bibliogrficos Comprobante de prstamo Restricciones al prstamos de libros, Adquisicin al por mayor de un libro Procedimiento de mantenimiento del material bibliogrfico

Tabla N 2. Lista de categoras de clases conceptuales. Adaptado de Larman (2003)

Como ejercicio, del ejemplo de las clases conceptuales del supermercado que vimos en las Figuras 8 y 9 podemos clasificarlas en alguna de las categoras propuestas en la Tabla N 2 anterior.

67

Cajero, Cliente: Roles de la gente. Factura, Producto, Tarjeta: Objetos tangibles o fsicos, Registro de finanzas. Detalle Venta: Lneas de la transaccin, Hechos. ExistenciaProducto: especificaciones, diseos o descripciones de las cosas.

La gua que nos da la Tabla N 2 nos permite proceder con la identificacin de los conceptos que pueden aparecer en el espacio del problema que estamos tratando. De igual forma, Larman nos seala que podemos basarnos en frases nominales, es decir, la que nos provean sustantivos significativos para poder identificar algn concepto. Sin embargo, una frase podra aparecer como ambigua, lo cual, metodolgicamente puede ser una debilidad. A mi juicio ambas estrategias no son excluyentes. Tome en cuenta que los casos de uso, en su descripcin breve o detallada, proveen informacin importante mediante frases nominales. A partir de stas, podramos fijarnos en la Tabla N 2, de categoras propuestas por Larman, para proceder a identificar conceptos. CASOS DE USO E IDENTIFICACIN DE CLASES CONCEPTUALES Hemos desarrollado hasta este momento, la especificacin de casos de uso del sistema de prstamo de libros de una biblioteca. Vamos a recordar la definicin breve de uno de los casos de uso que fueron identificados como de mayor riesgo, es decir, que es esencial para el sistema, como el de Registrar prstamo. En dicha definicin vamos a subrayar algunas palabras que pueden referirnos, de acuerdo con la categorizacin propuesta, a clases conceptuales.

Caso de uso Registrar prstamo Actor (es) Bibliotecario Descripcin: el bibliotecario pide al usuario la identificacin de ste y consulta el estado de morosidad de la persona. Si est a derecho, lee los datos de un material bibliogrfico que ser prestado. Los datos se leen a travs de una etiqueta de cdigo de barra que viene en el material. El sistema, con respecto a las restricciones y la frecuencia de uso del material, sugiere el tiempo de prstamo conveniente de acuerdo con la demanda. El bibliotecario registra finalmente los datos del material prestado.

68

Observe cmo, en primer lugar, aparecen roles de personas en el sistema: bibliotecario y usuario. De igual forma podemos notar cosas como material bibliogrfico que es lo que se registra en una transaccin (que como tales, las transacciones constituyen conceptos) como es el prstamo. Otras transacciones como la morosidad (las cuales son consultadas), que pudieron ser registradas en otro momento, intervienen en los conceptos que estamos identificando para el proceso.

Tipos de clases conceptuales Clases identificadas Roles Usuario, Bibliotecario Cosas Material bibliogrfico Transacciones Prstamo, Morosidad

Recordemos que el UP plantea identificar los casos de uso clave del sistema (tambin vistos como los de mayor riesgo) para desarrollarlos con especial atencin. Y, por otra parte, tales casos de uso deben servir como gua para desarrollar una arquitectura que pueda sustentar de forma slida al sistema. En este punto podemos comenzar a crear un modelo conceptual de nuestro sistema de prstamo de la biblioteca. En primer lugar, podemos enumerar varios conceptos encontrados: Usuario Prstamo Bibliotecario Material bibliogrfico Morosidad

Fjese que esta lista es parecida a la que encontramos analizando la descripcin breve de casos de uso. Un ingeniero de software con experiencia, podr deducir desde el momento que escribe los casos de uso, conclusiones y elementos importantes referidos al modelo de clases. Es posible que utilizando la descripcin detallada de casos de uso podamos encontrar nuevos conceptos no considerados en la descripcin breve. Eso vamos a revisarlo ms adelante. Con los conceptos hallados, podemos trazar un primer modelo conceptual. En este solamente incluiremos los conceptos como tales, sin detallar atributos u

69

operaciones, lo que podramos decir que es el cascarn de las clases que queremos desarrollar.
Condiciones Prstamo Bibliotecario

Material

Prstamo

Usuario

Registro Morosos

Figura 10. Conceptos del Sistema de Prstamo Bibliotecario.

Analicemos por un momento el modelo que hemos construido. Qu conceptos hemos encontrado? Y a partir de stos, qu nuevas preguntas se nos presentan? Observemos que hay algunos conceptos que podemos representar muy naturalmente a partir de la descripcin que hemos desarrollado en el caso de uso. Por ejemplo, las personas involucradas como el Bibliotecario y el Usuario, la transaccin de Prstamo y el Material que presta la biblioteca. Hay otros conceptos que se desprenden de la descripcin del caso de uso, por ejemplo, un Registro de Morosos que se consulta cuando se est en el proceso del prstamo. Por otra parte, puede intuirse que debe haber algo en el sistema que pueda definir la Condicin de prstamo para el material bibliogrfico, donde se indique que un material sujeto de prstamo, tiene condiciones para ello: por ejemplo, que dicho material se presta solamente para uso en las instalaciones de la biblioteca, o bien para llevarlo fuera de sta, as como el tiempo que puede prestarse, entre otros. Encontrar un concepto como ste quizs no sea tan inmediato, pero de alguna forma surge de la descripcin misma del caso de uso. Cuando se indica que el sistema, de acuerdo a las restricciones y la frecuencia de uso del material, estamos frente a la necesidad de incorporar algn elemento que maneje las restricciones de prstamo que ah se han descrito.

70

Finalmente, note cun importante es la descripcin de un caso de uso para poder ir definiendo los conceptos que requerimos para poder elaborar nuestros modelos de clases. Por ello ac reforzamos la importancia que les otorga el Proceso Unificado (UP): una buena comprensin y definicin de los casos de uso conlleva a que todo pueda depender de ellos para los elementos que deben crearse para la solucin requerida. El hecho que se diga que el UP est guiado por casos de uso, no es casual. DIFERENCIAR CONCEPTOS QUE SON CLASES Y CONCEPTOS QUE SON ATRIBUTOS En este punto lograramos apelar a la intuicin para definir conceptos que podran ser clases. Sin embargo, un consejo que nos da Larman (2003) es una regla emprica (como tantas que usamos en la informtica), previnindonos de errores tpicos en la definicin de las clases conceptuales. Tal error se manifiesta muchas veces en incluir en una clase un atributo, cuando realmente es una clase. La regla de oro que nos da este autor es la siguiente: si no consideramos

alguna clase conceptual X que sea un nmero o texto en el mundo real, X es probablemente una clase conceptual, no un atributo.

Qu nos quiere decir Larman con ello? Que generalmente, cuando estemos planteando un modelo conceptual, si nos topamos con algn concepto que puede expresarse con tipos de datos primitivos, es decir, nmeros, cadenas de texto, caracteres, bolanos, o cualquier otro que pueda proveer un lenguaje de programacin, entonces estos sern potencialmente atributos. Si nos tropezamos con un concepto que se expresa como algo ms complejo que nmeros, texto o cualquier tipo primitivo, entonces ese concepto deber ser una clase. Un ejemplo que el autor nos ofrece es el siguiente.

Vuelo - destino :

Vuelo

Aeropuerto - nombre : String - ciudad : String

Figura 11. Diferencia entre clases conceptuales y atributos.

71

A la izquierda de la Figura 11 vemos una clase conceptual llamada Vuelo que tiene un atributo llamado destino. Qu es destino en este caso? Es un aeropuerto donde debe llegar ese vuelo. En ese caso, destino se vuelve mucho ms complejo que ser solamente un atributo definido, por ejemplo, por un tipo de datos primitivo, digamos que una cadena de texto (String). Una mejor definicin conceptual se da a la derecha de la Figura 11 donde tenemos la clase Vuelo por una parte y una clase Aeropuerto por otra parte. Note que aeropuerto posee dos atributos, nombre y ciudad, los cuales son parte de la caracterizacin que damos a esa clase. Podramos analizar cada una de las clases conceptuales halladas para el caso de la Biblioteca bajo esta ptica, es decir, que podamos indagar si ellas son mucho ms complejas que un tipo de datos primitivo? Y es que si vemos la descripcin del caso de uso que analizamos, nos topamos con un posible concepto cuando se menciona la identificacin del usuario que introduce el bibliotecario. En ese caso podemos intuir que tal identificacin podra ser tan simple como una cadena de caracteres, por lo cual pasara ser un atributo de una clase, ms que una clase en s. En la siguiente tabla indagamos, tomando en cuenta la regla de Larman, las clases que hemos identificado en la Figura 11.

Nombre de la clase Bibliotecario Usuario Material Prstamo Registro Morosos Condiciones Prstamo

Atributos potenciales Identificacin, Nombre Identificacin, Nombre, Estado (activo, moroso, inactivo) Cdigo, Tipo material Cdigo, Fecha Prstamo, Tiempo prstamo, Fecha Devolucin, Estado (abierto, devuelto, moroso) Fecha registro, Importe por morosidad, Estado (abierto, cancelado) Tipo de prstamo (Interno en la Biblioteca, A domicilio), Tiempo de prstamo.

Tabla N 3. Representacin de clases de la Figura 11, usando la regla de oro sugerida por Larman.

Observe, entonces, que al evaluar algunos atributos potenciales que hay en los conceptos que identificamos, nos damos cuenta que el concepto debe expresarse a travs de un conjunto de atributos, por lo cual podemos intuir que estamos, potencialmente ante clases conceptuales.

72

Al revisar la lista de atributos usted podr preguntarse en este momento (y con sobrada justificacin): pero para registrar un prstamo debo saber qu estoy prestando (material) y a quin se lo estoy prestando (usuario)? Para responder a lo anterior, fjese que en un primer momento vamos a encontrar conceptos como los que hemos hallado en este sistema: prstamo, material, usuario, etc. Sabemos que estos conceptos, expresados luego como clases conceptuales debern relacionarse entre s. Producto de esas relaciones es que cada una de estas clases, dentro de sus atributos, podr incorporar objetos de las clases que necesitan, como es el caso de Prstamo con respecto a Material y a Usuario. Cuando elaboramos el modelo conceptual, en un primer momento tenemos que esforzarnos por descubrir los atributos propios de la clase que estamos tratando de definir. Mientras tanto, los atributos, que son objetos de otras clases, tal como mencionamos, se expresarn producto de la definicin de las relaciones entre esas clases. Finalmente, note que, mientras realizbamos la comprobacin de que si nuestros conceptos son clases o atributos, descubrimos, valga la redundancia, algunos atributos importantes que deben tener nuestras clases.

RELACIONES1 CONCEPTUALES ENTRE CLASES

Estudiemos con ms detalle el tema de las relaciones entre clases. En un modelo conceptual debemos encontrar relaciones importantes que deben darse entre las clases, de forma tal que pueda visualizarse qu tipo de colaboracin debe darse entre ellas. Al mencionar la palabra colaboracin, debemos recordar que cada uno de los elementos que estamos identificando, esto es, las clases conceptuales, son parte de un todo que es el sistema. Por lo tanto, no hay elementos aislados, sino que ellos conforman parte de una arquitectura. Tal como lo mencionamos anteriormente en este libro, la arquitectura debe verse como un sistema y, tal como en una casa, cada una de las habitaciones, ventanas, tomas de corriente, tuberas, etctera, colabora para varios objetivos que tienen sus residentes: Dormir, Iluminar habitacin, Ventilar casa, etc. As entonces, para cumplir
En este caso se va a usar el trmino relacin cuando se trate del modelo conceptual. Otros autores tambin utilizan el nombre de asociacin, como el caso de Larman. Sin embargo cuando se estudie el modelo de diseo, se va a analizar un tipo especfico de relacin cual es la asociacin, por lo cual, para no confundir trminos, como mencion anteriormente, se utilizar el trmino de relacin en esta etapa.
1

73

los objetivos del Sistema de Prstamo Bibliotecario, debemos encontrar cmo se relacionan las clases unas con otras, en trminos de poder definir la colaboracin que vamos a necesitar. En el apartado anterior ya habamos mencionado brevemente algunas colaboraciones que se necesitan para poder registrar un prstamo. Esta transaccin requiere establecer aspectos como: fecha en que se presta, cunto tiempo se presta, estado del prstamo, entre otros. Adems, debe saber a cul usuario de la biblioteca se le presta y cul material se le est prestando. Al encontrarnos con esta necesidad de colaboracin de registrar un prstamo, podemos ir modificando nuestro modelo conceptual tal como se establece en la Figura 12:

Condiciones Prstamo

Bibliotecario

Material

Prstamo

Usuario

Registro Morosos

Figura 12. Definicin de primeras relaciones entre clases conceptuales para el Sistema de Prstamo Bibliotecario.

En la figura anterior podemos notar ya el hecho de que, para poder registrar un prstamo, debemos contar con la colaboracin de las clases de Material y de Usuario.

Cardinalidad de las relaciones

Al establecer relaciones entre clases, debemos poder definir tambin lo que se denomina la cardinalidad de la relacin. Entendemos por cardinalidad el nmero de ocurrencias que pueden existir en la relacin entre las clases. Por ejemplo,

74

para la relacin entre material y prstamo pueden definirse las siguientes polticas. En todo prstamo no hay lmite, en cuanto a nmero de los materiales que el usuario desea pedir. Sin embargo, todo prstamo debe contar, al menos, con un material. En el diagrama esto se ve as:
Material 1..* Prstamo

En el extremo izquierdo de la relacin se nota un 1..*, lo cual define que, partiendo de la clase Prstamo hacia la clase Material, debe haber, al menos, un material como lmite inferior, aunque no hay lmite superior en este caso, representado por el asterisco. Otra poltica de la Biblioteca podra ser limitar el nmero de materiales que pueden prestarse a la vez, digamos, cinco materiales por prstamo. De igual forma se establece que, para que se de un prstamo, al menos debe existir un material. El diagrama anterior se modificara de la siguiente forma:
Material 1..5 Prstamo

En este diagrama notamos, tanto el lmite inferior, como el lmite superior, para el nmero de ocurrencias de materiales que pueden facilitrsele a un usuario en un prstamo. Por otro lado, podra quererse, por parte de la administracin de la Biblioteca, que todo prstamo sea exactamente de un solo material. As entonces, aunque el usuario acuda con n cantidad de materiales para que le sean prestados, el sistema registrar para cada uno de ellos, un prstamo distinto. En tal caso, la cardinalidad de la relacin entre Prstamo y Material se vera as:
Material 1..1 Prstamo

Note que cada prstamo puede contener uno, y solamente un material. La cardinalidad de Prstamo hacia Material que analizamos previamente, est sujeta a definiciones de la poltica de prstamo que tenga la Biblioteca. En ese sentido

75

puede ser ms libre de definir, dado que puede ser cualquiera de las que hemos visto anteriormente como ejemplo. Quizs la nica restriccin que no puede obviarse es que, para que haya un prstamo, debe prestarse algo. Por lo tanto, el lmite inferior de al menos un material por prstamo, es el que debe respetarse siempre, aunque puede haber variaciones en el lmite superior. Lo importante, en todo caso, es que usted, como buen ingeniero o ingeniera de software, lleve a cabo las averiguaciones necesarias para una correcta definicin. Como veremos ms adelante, cualquier definicin que se adopte, tendr un impacto en el modelo que se construya. Ahora bien, la cardinalidad en la relacin inversa a la analizada, de Material hacia Prstamo, debe pensarse tambin en los escenarios que son vlidos de ocurrir. Pongamos el caso que vamos a pensar en el lmite inferior de la relacin: para que exista un material en el sistema, debe necesariamente ocurrir un prstamo? La respuesta pareciera ser no. Por ejemplo, algn libro de Ingeniera de Software escrito por Roberto Corts podra estar por aos en una biblioteca y jams ser solicitado para prstamo. Por otra parte, para pensar en el lmite superior de la relacin, un material cuntas veces puede ser prestado?, una vez?, un nmero limitado de veces?, todas las veces que se requiera? Analicemos estas situaciones: si slo pudiera prestarse una vez, podra pensarse que la Biblioteca estara adquiriendo materiales muy extraos que parecieran que no pueden prestarse ms de una vez, por algn motivo desconocido. Tal no es el caso. Ahora bien, si fuera un nmero limitado de veces (pongamos, 5, 10 o cualquier otro nmero), sera una extensin de lo mismo que analizamos en el prrafo precedente para el caso de prestarse una sola vez, solo que definido a partir de un nmero mayor que uno. Entonces, pareciera que el material puede ser prestado una y otra vez mientras sirva. En este caso, el lmite superior sera ilimitado, por lo cual se representa por un asterisco. Finalmente, la relacin entre Prstamo y Material se vera de alguna de las siguientes formas:
Material 1..1 0..* Prstamo

O bien:
Material 1..5 0..* Prstamo

76

O bien:
Material 1..* 0..* Prstamo

Cada una de ellas, expresada de acuerdo con las polticas de ejemplo vistas para la definicin de la cardinalidad hecha de Prstamo hacia Material. En la relacin que une las clases de Prstamo y Usuario, tambin podemos hacer el mismo ejercicio. Piense usted: cuntos prstamos puede hacer un usuario en el sistema? Y, por otra parte, hacia cuntos usuarios est asociado un prstamo? Respndase estas preguntas. Yo le propongo la siguiente respuesta y usted verificar el porqu de esta.
Prstamo 0..* 1..1 Usuario

Nombre de las relaciones

Otra buena prctica que se recomienda, es poder dar nombre a las relaciones. Nombrar una relacin adecuadamente sirve para documentar de mejor forma el modelo que estamos creando. As, al visualizar el modelo, se estara facilitando una mejor lectura de ste. Pero, cmo nombrar relaciones? No hay una receta definida, ms que indicar algo significativo que describa la relacin. Procuraremos, eso s, expresar en una sola palabra tal relacin y, tambin, nos esforzaremos para que la denominacin de la relacin sea hecha con base en la clase que necesita de la otra. Qu se quiere decir con ello? Por ejemplo, en la relacin Prstamo/Material necesitamos preguntarnos qu clase necesita de la otra para que tenga sentido. Ya vimos que Material tiene sentido sin que necesariamente haya un prstamo. No obstante, Prstamo requiere necesariamente de que haya, al menos, un material que se preste. Por lo tanto, uno podr denominar la relacin en trminos de la necesidad de Prstamo hacia Material2. Un nombre candidato de esta relacin
2

Note tambin que la cardinalidad de la relacin puede ayudar definir ese rol de quin necesita a quin. En este caso se ha visto que Material, en su lmite inferior de la relacin con Prstamo, indica 0 (cero), esto es, que no necesariamente debe existir un Prstamo para que un objeto de la clase Material exista. Mientras tanto, el lmite inferior de la relacin de Prstamo hacia Material, el cual es uno, indica que debe existir dentro de Prstamo, al menos un objeto de la clase Material para que un objeto de la clase Prstamo pueda existir.

77

podra ser Incluye, SePrestan u otras denominaciones que expresen tal relacin. En el diagrama veramos algo parecido a lo siguiente.

Material

1..* Incluye

0..*

Prstamo

Note que el nombre de la relacin se muestra al lado izquierdo de esta, leyndose as: La clase Prstamo incluye los materiales que se prestan en la transaccin de registro de prstamo de materiales en el sistema. Siguiendo con el mismo ejercicio, podemos establecer el nombre de la relacin entre Prstamo y Usuario. Nuevamente, nos preguntamos quin necesita a quin, en esta relacin. En este caso diremos que Prstamo requiere saber necesariamente a cul usuario se le est prestando el material. Por el contrario, un objeto de la clase Usuario puede existir sin estar asociado nunca en su vida a un prstamo. As entonces, podemos denominar la relacin entre las clases Prstamo y Usuario en el contexto significativo de esta relacin dentro del sistema, por ejemplo, con el vocablo adjudica. As, para poder describir en nuestro modelo que el prstamo es adjudicado a un usuario, al trazar el diagrama lo veramos de la siguiente forma:

Prstamo

Usuario 0..* 1..1 Adjudica

Ahora nos interesa ir completando el modelo conceptual del Sistema de Prstamo Bibliotecario. Al visualizar el modelo de clases conceptuales para el Sistema de Prstamo Bibliotecario que hemos definido hasta el momento, nos encontramos con el siguiente diagrama.

78

Condiciones Prstamo

Bibliotecario

Material

1..* Incluye

0..*

Prstamo

Usuario 0..* 1..1 Adjudica

Registro Morosos

Figura13. Modelo de clases conceptuales para el Sistema de Prstamo Bibliotecario.

Este modelo deber irse completando. Para ello deben establecerse otras relaciones, que se propondrn a continuacin, con el objeto de que usted las analice, de acuerdo con lo que hemos visto hasta ahora, y que sintetizamos en los siguientes pasos. a) Busque conceptos claves en los casos de uso. b) Analice si esos conceptos son atributos o clases conceptuales. c) Establezca, mediante relaciones, la colaboracin que se requiere entre clases, para cumplir los objetivos del sistema. d) Defina la cardinalidad de la relacin, de acuerdo con el anlisis de polticas o reglas que se descubran en el contexto del sistema que se est diseando. e) Nombre las relaciones con alguna palabra significativa, expresando la accin que se da entre las clases conceptuales. Un primer modelo conceptual completo lo podemos apreciar en el diagrama que observamos en el siguiente diagrama.

79

Condiciones Prstamo

Bibliotecario

1..1 1..1 RestringePrestamo Material 0..*

1..1 HechoPor 0..* Prstamo Usuario 0..* 1..1 Adjudica

1..* Incluye

1..1 GeneradoPor 0..* Registro Morosos

Figura 14. Modelo conceptual completo para el Sistema de Prstamo Bibliotecario.

Analicemos rpidamente el proceso para llegar a esta versin del modelo. En primera instancia, el caso de uso Registrar Prstamo, como uno de los casos de uso fundamentales del sistema, nos proporcion varios de los conceptos y colaboraciones que ah se muestran. De esta forma, apreciamos una clase conceptual central que es Prstamo, la cual requiere colaborar con la clase Material y la clase Usuario, para poder registrar la transaccin que representa el prstamo de un material bibliogrfico, para un usuario de la biblioteca. Tal transaccin es realizada en el sistema por un Bibliotecario, tal como se muestra en la relacin Prstamo/Bibliotecario. El bibliotecario puede registrar muchos prstamos e, incluso, podra no registrar ninguno. Un prstamo puede ser registrado por uno, y solamente un bibliotecario. Por otra parte, cada material define sus restricciones de prstamo mediante la clase Condiciones Prstamo. En este caso podemos suponer dos escenarios. Existen polticas generales de prstamo, por ejemplo, el material que permite prestarse para utilizar fuera de la biblioteca, puede ser otorgado en prstamo por 15 das. Por otra parte, el material que solamente puede utilizarse dentro de la biblioteca, es prestado por 5 horas.

80

Cada material tiene una poltica de restriccin variable derivada de varios factores como: poblacin usuaria potencial, cantidad de copias existentes en la biblioteca, tipo de material, demanda efectiva registrada del material, entre muchos otros. En tal caso, el sistema define una restriccin especfica para cada material en prstamo. De acuerdo con el diagrama, el escenario escogido es el segundo. Intente explicar por qu es este y no el primero. Por ltimo, la relacin Prstamo/RegistroMorosos puede derivarse del anlisis de otro caso de uso. El caso de uso en cuestin es el llamado Registrar devolucin con morosidad Caso de uso Registrar devolucin con morosidad

Actor (es) Bibliotecario Descripcin: al procesar una devolucin, luego de leerse los datos del material prestado, si se detecta que el material est sujeto a morosidad, se habilita un proceso para tramitar la multa que el usuario debe pagar. El sistema calcula dicha multa y el bibliotecario termina de registrar los datos de la devolucin y de la multa para el usuario.

un registro de morosidad se genera a partir del registro de una devolucin de un material prestado. En este caso, note que la clase de RegistroMorosos requiere de Prstamo, por eso el nombre de la relacin se coloca en el extremo de la clase
Prstamo.

Observe que tenemos, en primera instancia, las acciones que registran la devolucin, la cual podemos suponer es el cambio de estado del prstamo (por ejemplo, de un estado abierto a un estado cerrado). Al mismo tiempo tenemos que, durante ese proceso de devolucin, se ha detectado una situacin donde se genera la multa que debe pagar el usuario, por incurrir en atraso. De ah que la colaboracin existente entre estas dos clases puede expresarse como:

Finalmente, la cardinalidad de esta relacin se fundamenta en la siguiente argumentacin: si la poltica de prstamo de la Biblioteca permite registrar por cada transaccin un nmero ilimitado de material bibliogrfico para un usuario, entonces, de igual forma podran generarse, por cada prstamo, la misma cantidad de registros de morosidad. Por ejemplo, si se prestaron 8 distintos materiales para un usuario en un mismo prstamo, potencialmente podran registrarse hasta 8 ocurrencias de morosidad. Podran ser menos, por ejemplo, que el usuario devuelva a tiempo 3 materiales y 5 no los regrese an. E igual podra no haber ningn registro de morosidad, por lo cual sabemos, entonces, que los objetos de la clase Prstamo pueden existir sin que haya registro de

81

morosidad. Entonces, la cardinalidad de Prstamo hacia RegistroMorosos es de 0 a muchos (visto en el diagrama de la Figura 14 como 0..*). Note que, por lo analizado, pueden generarse distintos registros de morosidad, en distintos momentos, para un mismo prstamo. Por ejemplo, un usuario podra devolver, en un momento dado, un material con atraso y luego, en otro momento, otro material que se otorg a partir del mismo prstamo. Esta situacin nos genera otro problema en el modelo: cmo manejar estas devoluciones parciales? Dada esta situacin, debemos manejar, de una forma particularizada, cada material prestado, es decir, no podemos suponer que todo se va a tratar al estilo de un paquete. Si bien todos los materiales solicitados por un usuario se prestan en un solo momento, la devolucin no necesariamente ser as. Vamos a retomar esta situacin ms adelante. Por otra parte, dado que un objeto de la clase RegistroMorosos se genera a partir de un objeto especfico de la clase Prstamo este debe estar asociado a uno, y solamente uno, de los objetos de esta clase. En este punto tenemos un modelo conceptual de clases bastante adelantado en cuanto a las clases que podemos incluir potencialmente para nuestro sistema. Antes de avanzar a otras fases, como por ejemplo a la definicin de atributos y operaciones en cada una de las clases (acercndonos a obtener clases de diseo), tenemos que tratar previamente aspectos que tienen que ver con la definicin del modelo conceptual: las mltiples relaciones entre clases, clases relacionadas con ellas mismas y clases que sirven para especificar o describir una clase.

Relaciones mltiples entre clases

Es posible que encontremos dentro del contexto de un problema, que una clase defina ms de una relacin con otra. Un ejemplo de ello podra ser la relacin entre una clase Vuelo con una clase Aeropuerto (que vimos en otro ejemplo anteriormente). Sabemos que un vuelo tiene, al menos, una procedencia y posee, al menos, un destino. Tanto las procedencias, como los destinos son, en s, aeropuertos. Seguidamente podemos ver cmo se refleja esa situacin.
0..* Vuelo 0..* 1..* VuelaDesde 1..* VuelaHacia Aeropuerto - nombre : String - ciudad : String

82

Note que la relacin en la parte superior define las procedencias de un vuelo, mientras que la de abajo define los destinos. En algn momento observaremos cmo estas relaciones se transforman en atributos en las clases, por lo cual resulta importante definirlas.

Relaciones hacia la misma clase

Tambin es posible que podamos encontrar que una clase deba relacionarse consigo misma. Un ejemplo claro de esta situacin, es lo concerniente a las materias que se imparten en una universidad y que forman parte de un plan de estudios. En este caso, vamos a encontrar que hay materias que son requisitos de otras. Dada esta situacin, debemos relacionar la clase Materia con ella misma, tal como se muestra en el siguiente diagrama:

0..* Materia

0..* Requiere

As observamos que al definir esa relacin, una materia puede requerir (o no requerir) de otras materias en el seguimiento de un plan de estudios.

Especificacin de conceptos en el modelo de clases

Otra situacin que podemos encontrarnos en el planteamiento de una solucin, es la necesidad de especificar un concepto de una forma ms adecuada al funcionamiento que requerimos. Por ejemplo, en el caso de nuestro sistema de prstamo bibliotecario, tenemos la clase Material. Piense por un instante qu queremos hacer nosotros con un objeto de esta clase en el contexto de nuestro sistema? S, muy bien! Queremos prestarlo (y recuperarlo, obviamente). Ahora bien, en realidad qu prestamos? El material en s mismo o una copia del material? Y dado el caso que manejramos copias (en el concepto legal de copias, no de fotocopias), qu debemos controlar, adems? Debemos controlar

83

la cantidad de copias del material existentes en la Biblioteca y, dentro de estas, verificar cuntas estn prestadas. Revisemos una parte del modelo conceptual que tenemos planteado hasta el momento y analicmoslo a la luz de estas preguntas. Veamos la situacin que se expresa en esta relacin:

Material

1..* Incluye

0..*

Prstamo

Tal como la estudiamos anteriormente, el prstamo puede incluir muchos materiales para poder ser prestados en una sola transaccin de Registrar Prstamo. Pero tal como nos cuestionbamos anteriormente, se est prestando el material en s mismo, visto como concepto, o bien, una copia de este? Tratemos de clarificar un poco ms. Cuando estamos tratando el concepto de material, nos estamos refiriendo a la informacin general de un material bibliogrfico. Tal informacin es un conjunto de atributos que definen, por ejemplo, si el material fuera un libro, especificar al autor, el nombre de la obra, quin la pblica, el ao, la edicin, el ISBN, entre otros. Por lo tanto, la biblioteca cuenta con la informacin de cada una de los materiales que tiene a disposicin de los usuarios. Sin embargo, si se relacionara directamente la clase Material con la clase Prstamo y, por ejemplo, la biblioteca adquiere 8 copias del mismo material, entonces habra que ingresar ocho objetos de la clase material, repitiendo la misma informacin de autor, nombre de la obra, ISBN, etc., cada vez. Esto no resulta prctico. Adems, si por algn motivo la biblioteca perdiera todas las copias del material, esto implicara que toda la informacin relativa a un material tambin desaparecera. Esto resulta en una situacin sumamente imprctica, que debe resolverse mediante la utilizacin de otra clase que se denomina, segn Larman (2003) como la especificacin o descripcin de una clase. En nuestro caso, pareciera conveniente contar con una clase relacionada con material, llamada Copia, que pueda ayudar al manejo de los prstamos del material en la biblioteca. Veamos cmo podra modificarse esta situacin en nuestro diagrama.

84

Material - signatura : - copias : 1..1 Concretiza 0..*

Copia - id_copia : - estado_copia :

En este caso, vemos cmo una copia del material concretiza la existencia del material en la biblioteca. Una copia est asociada a uno y solo un material, mientras que el material puede tener ya sea ninguna, o muchas copias de este. Vemos algunos atributos significativos (los cuales, ya pronto, iremos completando en el siguiente apartado). Por ejemplo, dentro de una Biblioteca es sumamente importante la identificacin de un material, en trminos de sus necesidades. Tal identificacin se hace mediante una signatura. Adems, la clase Material puede mantener, a travs del atributo copias, la cantidad de copias que hay actualmente en la biblioteca. Esta podra disminuir o aumentar, de acuerdo a prdidas o adquisiciones que se hagan para dicho material. Muy relacionado con ella tenemos la clase Copia. Vea que tal es el ligamen que se indica que Copia concretiza la clase Material en el contexto de la biblioteca. Vea que tan es as, que usted mismo puede ir a consultar un material en cualquier biblioteca (a travs de un sistema computarizado de bsqueda, o bien, no hace mucho tiempo, en los gabinetes con tarjetas) y lo que tiene usted all es una referencia del material y dnde puede ubicarla. Con esa informacin usted va a los estantes y toma una copia del material, es decir, algo que concretiza lo que usted hall en el sistema o en el tarjetero. La clase Copia tiene algunos atributos importantes: la identificacin de la copia, dado que, si bien todas ellas se refieren al mismo material, una copia es distinta de la otra. Adems, tenemos un estado de la copia, que podemos suponer, por ahora, que se trata de algo que puede indicarnos algo con respecto de ella: si est disponible, si est prestada, si est perdida, si est en reparacin o si est anulada de las existencias. Con respecto a Prstamo, lo que va a prestarse, por lo tanto, no es un objeto de la clase Material, sino una copia ligada a ella. El diagrama resultante se vera as:

Material - signatura : : - copias 1..1 Concretiza 0..*

Copia : - id_copia - estado_copia : 1..* Incluye 0..*

Prstamo

85

Note que a partir de este cambio, lo que expresa el diagrama es que lo que se incluye en el prstamo son una o varias copias de distintos materiales (al menos una), y por otra parte, la copia de un material puede estar en ninguno o en varios prstamos distintos. Prrafos atrs identificamos un problema con respecto a la dinmica del prstamo. En ese momento analizbamos que, dada la poltica de poder prestar varios materiales (o, dada la modificacin, copias de materiales) en una sola transaccin de prstamo, la devolucin poda tener un comportamiento variable: un usuario poda devolver las copias en distintos momentos. Dado lo anterior, parece imposible manejar en la clase Prstamo un solo estado para que maneje la situacin individual de la devolucin de cada una de las copias prestadas. Por eso, el atributo estado_copia en la clase Copia, va a poder determinar el estado individual de una copia de un material, en algn momento del tiempo. A su vez, las copias relacionadas en un prstamo van a permitir definir un estado general de dicho prstamo. Esto por cuanto un atributo de estado en Prstamo, podra indicar el estado general de este: por ejemplo, puede indicar si un prstamo particular est abierto (tiene devoluciones pendientes) o cerrado (ya no tiene devoluciones pendientes). Por ltimo, en RegistroMorosos es importante ubicar cul copia de material, en particular, es la que est generando que se de la morosidad. Por lo tanto, es importante poder relacionar este registro con la clase Copia. Todo este anlisis nos lleva, por lo tanto, a poder modificar el diagrama de esta forma:

Copia : - id_copia - estado_copia : 1..* Incluye 0..*

Prstamo

1..1 SeFundamentaEn

1..1 GeneradoPor

0..* 0..* Registro Morosos

86

Vemos que se agrega una relacin entre RegistroMorosos y Copia, donde se indica que una morosidad se genera por la accin de devolucin en Prstamo, pero que debe fundamentarse en identificar cul copia de un material est generando tal registro. Ahora bien, la lectura de los casos de uso tambin nos pudo haber ayudado a identificar la clase Copia, como algo asociado a la clase Material y dentro del funcionamiento deseado. Cuando estudiamos la descripcin detallada del caso de uso Registrar Prstamo, notamos en uno de sus pasos la aparicin del concepto que ac hemos analizado. En letra cursiva y negrita de la siguiente tabla, encontrar lo relacionado en el caso de uso con el concepto de Copia . Caso de uso Registrar prstamo Objetivo Registrar la informacin de prstamos de un material bibliogrfico que se le hace a un usuario de la biblioteca de la Universidad. Actores Bibliotecario Condiciones El Bibliotecario deber tener en sus manos el material por prestar, ya sea que el previas usuario se lo haya proporcionado, o bien que l mismo haya tenido que buscarlo, dado que es de prstamo restringido. Adems de contar con la identificacin del usuario que lo habilite para poder usar el servicio de biblioteca. Escenario El caso de uso comienza cuando el Bibliotecario ingresa al sistema la identificacin del usuario. El Sistema le indica si el Usuario es vlido. El Sistema, adems le indica si el Usuario tiene algn registro de morosidad. Una vez comprobados los pasos anteriores, el Bibliotecario lee del Sistema Bibliotecario la informacin del material que se va a prestar, a travs de un lector de cdigo de barras. En ningn caso puede prestarse otra copia del mismo material al mismo usuario, lo cual se comprueba, por parte del Sistema, cuando se hace esta lectura. El Sistema indica si el material puede ser prestado solo para uso interno de la biblioteca y el tiempo que puede ser prestado en cualquier caso. El Bibliotecario registra el prstamo del material y el caso de uso termina. Excepciones En el paso 1, de comprobarse que el usuario no est registrado en la biblioteca, o cursos el caso de uso termina. alternativos En el paso 2, si el usuario est moroso, el caso de uso termina. En el paso 3, si el cdigo de barras del libro est ilegible, el Bibliotecario deber ingresar este directamente en un campo de edicin de la pantalla. En el paso 3, de comprobarse que el usuario ya tiene una copia del mismo material asignado en otro prstamo, el caso de uso termina. En el paso 4, luego de indicarle al usuario las restricciones del prstamo, ste puede decidir no aceptar las condiciones, por lo cual el Bibliotecario termina la ejecucin del caso de uso. Condiciones De cumplirse el paso 5, el sistema guarda el registro del prstamo efectuado al posteriores usuario. El material debe quedar en estado de prestado.

87

Una vez ms (y se insiste con ello para hacerle ver su trascendencia) vea la importancia de los casos de uso. Si usted estudia la descripcin detallada de este caso de uso, deber darse cuenta cmo se justifica an ms el modelo conceptual: recuerde, la arquitectura del sistema es quien tiene que sostener cada uno de los casos de uso, y con mucho ms razn, los que son crticos para el sistema. Finalmente vea las implicaciones que conlleva analizar bien el contexto de la especificacin de una clase. Note que un concepto, como Material no basta por s mismo para poder manejar totalmente la funcionalidad que estamos buscando obtener en la colaboracin que deben expresar las clases. Por lo tanto, debemos aadir una clase de especificacin, en este caso la clase Copia. En otros contextos, igualmente, podemos encontrar ejemplos en los que debemos manejar una especificacin para un concepto. Imagine dentro de una fbrica el concepto Producto. En este concepto podramos tener los detalles del nombre, de la descripcin del producto, entre otros. Cuando se hace la manufactura de un producto, podramos tener la informacin especfica asociada: nmero de serie, cantidad fabricada, etctera. Esta clase especfica podra llamarse Produccin. En este caso encontramos que la clase Produccin describe, precisamente, lo que es la produccin de un producto.
Producto : - nombre - descripcin : 1..1 Describe 0..* Produccin - nmero_serie : : - cantidad

En el contexto de una universidad, con el caso de las materias que componen un plan de estudios, una especificacin de la clase puede darse en el momento en que se hace la matrcula. En este caso, un estudiante no matrcula una materia: una materia, en s, es una descripcin general de contenidos, objetivos, nmero de crditos y otros aspectos relativos a los propsitos acadmicos que se persiguen. Lo que matricula un estudiante es un Curso, el cual est asociado a un periodo lectivo, a un profesor, a un aula, a un grupo. Curso es una clase de especificacin de una clase Materia. Volviendo a nuestra biblioteca, nuestro diagrama conceptual tiene una fisonoma bastante avanzada desde que empezamos a elaborarlo. Note ello en los siguientes diagramas:

88

Diagrama inicial
Condiciones Prstamo Bibliotecario

Material

Prstamo

Usuario

Registro Morosos

Diagrama actual

Condiciones Prstamo

Bibliotecario

1..1 1..1 RestringePrstamo Material - signatura : : - copias 1..1 Concretiza 0..* Copia - id_copia : - estado_copia : 1..* Incluye 1..1

1..1 HechoPor 0..* Prstamo Usuario 0..* 1..1 Adjudica

1..1 SeFundamentaEn

1..1 GeneradoPor

0..* 0..* Registro Morosos

Figura 15. Diferencias entre el diagrama del modelo conceptual inicial y el actual del Sistema de Prstamo Bibliotecario.

89

Preste atencin a la sofisticacin que se ha seguido desde que iniciamos con un simple listado de conceptos encontrados en los casos de uso. Posteriormente hemos aadido relaciones, la cardinalidad, el nombre de las relaciones y la especificacin de clases conceptuales. Para poder llegar a este punto, y sobre todo para poder analizar el tema de la especificacin, hemos tenido que iniciar, tambin, con la definicin de atributos en las clases. En el siguiente apartado continuaremos con esta tarea. AADIENDO ATRIBUTOS AL MODELO CONCEPTUAL Tal como lo vimos al inicio del libro, cuando tratamos clases en el paradigma de orientacin a objetos, dos temas son importantes de definir: los atributos que caracterizan a cada uno de los objetos y los mtodos que describen el comportamiento que podemos obtener de dichos objetos. Por ahora vamos a detenernos en aadir atributos para cada una de las clases del modelo. En un momento nos toparemos con otras decisiones importantes que debern impactar dicho modelo. Pero vamos a comenzar por lo ms sencillo. Los atributos, tal como lo mencionamos, van a definir caractersticas en cuanto a datos que deben contener las clases conceptuales que hayamos identificado. En primera instancia, debemos tener en cuenta lo siguiente: se van a definir atributos en cada clase que sean simples, es decir, que puedan verse como tipos primitivos. Es muy posible que una clase vaya a tener atributos que no sean tipos primitivos, sino que sean complejos, posiblemente que deban contener atributos que son objetos de otras clases. Eso sucedera, por ejemplo, en la clase Prstamo, donde se requerira saber qu objeto de la clase Usuario y cul de la clase Copia estn asociados con un prstamo particular. En esa perspectiva, podra proponerse una definicin de atributos para la clase Prstamo as:
Prstamo nmero_prstamo fecha_prstamo estado_prstamo material_prestado usuario_adjudicado : : : : :

Veamos uno a uno los atributos.

90

nmero_prstamo: es el nmero de prstamo que se genera en la transaccin y

que lo identifica de forma nica en el sistema. fecha_prstamo: es la fecha en que se realiza el prstamo. material_prestado: es el conjunto de materiales prestados en el prstamo. usuario_adjudicado: es el usuario al cual se le asigna o adjudica el material prestado. Note que dentro de esos atributos hay algunos que podran ser datos que son de tipo primitivo y otros que son complejos y son de otras clases. Como regla, para la definicin de atributos de una clase, debemos encontrar e incluir aquellos que son sencillos, en general, que puedan representarse con tipos primitivos, como nmeros enteros, caracteres, nmeros reales, fechas, horas, cadena de caracteres, entre otros. Los atributos que son complejos y que obedecen a objetos de otras clases que se encuentren en el mismo modelo conceptual, los expresaremos mediante relaciones. Entonces, la clase Prstamo quedara mejor expresada, en cuanto a atributos, de la siguiente forma:
Prstamo Copia - id_copia - estado_copia : : 1..* Incluye 1..1 - nmero_prstamo - fecha_prstamo - estado_prstamo : : : 0..* 1..1 Adjudica Usuario

Para ir completando el modelo, podemos retomar la Tabla N 3 que comenzamos a elaborar cuando analizbamos si un concepto responda a ser un atributo, o bien a una clase conceptual. Dicha tabla presenta atributos potenciales en cada clase conceptual. Ahora podemos modificarla un poco, de acuerdo con la evolucin del conocimiento que hemos tenido del sistema. Veamos cul era la situacin de la tabla en aquel momento. Atributos potenciales Identificacin, Nombre Identificacin, Nombre, Estado (activo, moroso, inactivo) Cdigo, Tipo material Cdigo, Fecha Prstamo, Tiempo prstamo, Fecha Devolucin, Estado (abierto, devuelto, moroso) Registro Morosos Fecha registro, Importe por morosidad, Estado (abierto, cancelado) Condiciones Prstamo Tipo de prstamo (Interno en la Biblioteca, A domicilio), Tiempo de prstamo. Tabla N 4. Atributos potenciales de las clases conceptuales del Sistema de Prstamo Bibliotecario. Nombre de la clase Bibliotecario Usuario Material Prstamo

91

Observe que algunas clases pueden mantenerse tal como las definimos en aquel momento, tal es el caso de Bibliotecario y Usuario. De igual forma, RegistroMorosos y CondicionesPrstamo parecieran tener los atributos necesarios para caracterizar los datos que pueden manejar. Quizs, para efectos de transaccin, hara falta que RegistroMorosos incluyera la fecha en que se cancela el importe. Podra incluirse otro atributo que lograra indicar cul fue el nmero de documento del pago realizado. El anlisis de ello conseguira abrir paso a la existencia de otra clase, llamada algo as como PagoMorosidad. Este caso lo retomaremos ms adelante. En cuanto a Prstamo y Material, la aparicin de la clase Copia debi modificar algunos aspectos de los atributos que se consideraron en primera instancia. En s la clase Copia deber tener sus propios atributos los cuales, ya hemos visto, son identificacin de la copia y estado de la copia. La clase Prstamo incluir los atributos que se han visto en la Tabla N 4 anterior, con algunas diferencias. El atributo cdigo lo hemos visto como nmero o identificacin del prstamo; la fecha de prstamo, que es cuando se registra el prstamo, el estado del prstamo que obedecer a un estado general de todos los materiales que se prestaron (no a la situacin particular de cada uno de stos) y que se expresa en valores como: abierto y cerrado. Ahora bien, fecha de devolucin podra no tener ms significado en la clase, puesto que no puede individualizarse para cada una de las copias de los materiales que se prestaron. Cada copia de material debera tener su fecha de devolucin. Ahora bien, ante esto tendramos que ver dos opciones: o bien crear una clase Devolucin que se ubica entre las clases Copia y Prstamo, la cual manejara para cada copia de material prestado la fecha en que este se devuelve, o bien, podemos pensar que la fecha de devolucin solo tiene sentido si se hace de forma tarda. Tal fecha se incluye, efectivamente, en la clase RegistroMorosos. Tal decisin debe obedecer a cuntos controles debe tener en sus transacciones el sistema. La buena prctica dira que debemos incluir esa nueva clase. No obstante, para efectos de no complicar ms el modelo, vamos a escoger la segunda opcin la cual, adems, maneja el proceso ms crtico de las devoluciones: la que genera registros de morosidad. Dado este primer anlisis, tenemos algunas modificaciones importantes que hacer en la Tabla N 4 de atributos. La nueva versin sera la siguiente.

92

Nombre de la clase Bibliotecario Usuario Material Copia Prstamo Registro Morosos Condiciones Prstamo

Atributos potenciales Identificacin, Nombre Identificacin, Nombre, Estado (activo, moroso, inactivo) Signatura, Tipo material, Copias existentes, Copias disponibles, Copias prestadas Identificacin copia, Estado copia (disponible, prestada, en reparacin, anulada) Cdigo, Fecha Prstamo, Hora prstamo, Tiempo prstamo, Unidad de tiempo, Estado (abierto, cerrado) Fecha registro, Importe por morosidad, Estado (abierto, cancelado), Fecha de pago Tipo de prstamo (Interno en la Biblioteca, A domicilio), Tiempo de prstamo, Unidad de tiempo

Tabla N 5. Actualizacin de los atributos de las clases conceptuales del Sistema de Prstamo Bibliotecario.

Note que se han incluido algunos otros atributos importantes: en Prstamo se tiene la hora de prstamo, la cual es importante de tener, dado que se puede estar ante prstamos que son por hora. Por lo tanto, es necesario tambin identificar la unidad de tiempo que se presta, es decir, si se presta por horas o por das. Este atributo de unidad de tiempo tambin se incluye en la clase CondicionesPrstamo. Se ha modificado en Material el nombre de cdigo por el de signatura, lo cual es ms correcto en el contexto de las bibliotecas. Esta clase tambin tendr la responsabilidad de manejar las existencias de las copias del material que hay en la biblioteca. Por ello se aaden el nmero total de copias existentes, el nmero de copias disponibles (esto es, la cantidad de copias que pueden prestarse. No siempre todas las copias podran ser sujetas de prstamo, por ejemplo si alguna est en reparacin, o bien se adquieren para prestarse a estudiantes becados, u otra situacin especial). Tambin est el nmero de copias prestadas, cuya actualizacin reduce o incrementa el nmero de copias disponibles. Intencionalmente no vamos a profundizar en otros atributos obvios de un material como: autor, nombre, entre otros, para tocar, ms adelante, un tema importante de nuestro modelo. Hasta este punto advierta que deducir atributos es, como todo lo que se elabora en el Proceso Unificado, algo iterativo. Conforme usted va escribiendo y analizando el sistema, van surgiendo cuestionamientos importantes. No obstante, reflexione en qu momento lo estamos haciendo: no se ha codificado nada,

93

solamente se ha modelado, y sin embargo todo ello tiene consecuencias importantes en la programacin del sistema. Recuerde que el Proceso Unificado se fundamenta en iteraciones, y al cabo de stas, los productos (que pueden ser estos modelos conceptuales) se validan conforme se hacen revisiones. Tales revisiones pueden direccionar a que se agreguen requerimientos que no se haban considerado y tengan implicaciones que, por ejemplo, lleven a que se modifiquen, se quiten o se aadan atributos, tal como lo estamos haciendo ahora. As, pueden obtenerse versiones preliminares hasta consolidar una versin donde pueda observarse que muchos aspectos del modelo, en cada clase, se consolidan, de acuerdo a la funcionalidad y el control que se requieren. A partir del anlisis representando en la Tabla N 5 anterior, podemos modificar nuestro modelo nuevamente para tener una versin con los atributos que se han identificado.

94

Condiciones Prstamo - id_usuario - nombre : :

Bibliotecario

- tipo_prstamo - tiempo_prstamo - unidad_tiempo 1..1 HechoPor

: : :

1..1

0..* Prstamo Copia - id_copia - estado_copia : : 0..* 1..1 SeFundamentaEn 1..1 GeneradoPor 1..* Incluye 1..1 - nmero_prstamo - fecha_prstamo - estado_prstamo 0..* 1..1 Adjudica : : : Usuario - id_usuario - nombre - estado : : :

1..1 RestringePrstamo

1..1 Concretiza 0..* 0..* Registro Morosos fecha_registro importe_moroso estado fecha_pago : : : :

Material

signatura copias_existentes copias_disponibles copias_prestadas

: : : :

Figura 16. Visualizacin de las clases conceptuales y sus atributos.

95

Del diagrama anterior se obtiene una visin bastante completa del modelo que incluye las clases conceptuales y sus atributos con una definicin ms avanzada. Quedan dos temas pendientes: uno es con respecto al pago de los cargos por mora por parte del usuario y el otro con respecto a la definicin de la clase Materiales. Empecemos por la primera situacin. Si bien no habamos incluido un caso de uso de Pagar Prstamos Morosos por parte del usuario, a la luz de que estamos usando el Proceso Unificado y que pueden surgir requerimientos al respecto, vamos a reflexionar un momento acerca de ello. En primera instancia, podramos suponer que se aade un caso de uso para el manejo de esta funcionalidad. Este podra definirse de la siguiente forma:
Caso de uso Pagar Prstamo Morosos Actor (es) Cajero Descripcin: el cajero recibe, por parte de un usuario de la biblioteca, el pago por concepto de cancelacin de morosidad en el prstamo de material bibliogrfico. De la lista de prstamos con morosidad, el cajero cancela los que cubran la cantidad de dinero dada por el usuario. Si el usuario no queda con pagos pendientes, entonces cambia el estado del usuario de moroso a activo. Se emite un documento de recibo de pago.

Este caso de uso incluye un nuevo concepto, el cual es, adems, una nueva clase: Pago. El pago se asocia con un conjunto de registros de morosidad, los cuales, como ya se vio, fueron generados por devoluciones atrasadas de copias de material bibliogrfico. Otro concepto aadido al sistema, es el de Cajero. El diagrama, visto parcialmente en las clases que ataen, podra modificarse de la siguiente forma:
Prstamo - nmero_prstamo : : - fecha_prstamo - estado_prstamo : 0..* 1..1 Adjudica Usuario - id_usuario : : - nombre : - estado

1..1 GeneradoPor

1..1 PagadoPor

0..* 0..* Registro Morosos fecha_registro importe_moroso estado fecha_pago : : : : 1..* Cancela 1..1 Pago id_pago nmero_recibo monto_pago fecha_pago : : : : 0..* 1..1 Registra Cajero - id_cajero : - nombre :

Figura 17. Incorporacin del caso de uso de Pagar Prstamos Morosos al modelo conceptual de clases del Sistema de Prstamos Bibliotecarios.

96

Un objeto de la clase Pago se genera para cancelar, al menos, un registro de morosidad. El pago es pagado por un usuario (el cual puede tener asociado muchos pagos para un mismo prstamo o para distintos prstamos) y es registrado por un cajero. Otro aspecto del modelo que hay que considerar, es lo relativo a la clase Material. El material que puede ser prestado en la Biblioteca puede ser de distinta ndole: un libro, una revista o un vdeo. Esto nos lleva a pensar que podemos aprovechar uno de los mecanismos provistos por el paradigma de orientacin a objetos, el cual es la herencia. Por el momento nos detendremos a pensar cules atributos pueden ser generales para los tres materiales, y cules son particulares para cada uno de stos. Ya hemos visto que la clase Material contiene los atributos relativos a la signatura y el control cuantitativo de las copias del material. Estos atributos sern comunes para todo tipo de material de la Biblioteca. Ahora bien, para especializar una jerarqua de herencia en cuanto a los materiales que se prestan en esta Biblioteca, debemos pensar qu atributos son especficos para cada uno de ellos. Hagamos el ejercicio para cada caso en la siguiente tabla.

Tipo de material Libro Revista Vdeo

Atributos Autor, Ttulo, Temas, ISBN, Edicin, Editor, Ao, Nmero de pginas, Idioma, Pas Nombre, Ao, Volumen, Editor, ISSN, Idioma, Pas, Especialidad, Temas Nombre, Compaa productora, Director, Ao, Duracin, Idioma, Temas

Tabla N 6. Anlisis de atributos por cada uno de los tipos de materiales bibliogrficos.

Podemos con este listado de atributos darnos una pequea idea de lo que podran describir las caractersticas de cada uno de los materiales que se prestan en la Biblioteca. Note que podemos encontrar algunos atributos comunes para todos: idioma, ao y temas (referidos a los temas o palabras claves de cada material, tal como sera el caso de Ingeniera de Software, Anlisis y Diseo Orientado a Objetos, Proceso Unificado, para el caso de este libro). Algunos otros atributos, luego de analizarlos, podra decirse que tienen propsitos comunes, si bien pueden llamarse diferentemente. Tal es el caso de ttulo y nombre, o de compaa productora y editor. Uno podra atreverse a ponerlos como atributos comunes para las clases, buscando un nombre adecuado o escogiendo alguno (por ejemplo nombre) y que tenga un significado en el contexto particular de una clase (por ejemplo documentar que el atributo nombre se refiere a ttulo en el caso de la clase Libro). Sin embargo, tales

97

decisiones se dan cuando se definen las clases de diseo, ms que en las clases conceptuales. Dado que estamos, precisamente, en la definicin de clases conceptuales, dejaremos estas decisiones para despus. La parte del diagrama que se modificar se detalla a continuacin.
Material # # # # # # # signatura copias_existentes copias_disponibles copias_prestadas ao pas idioma : : : : : : :

Tema - nombre_tema : 1..* DescritoPor 0..*

Libro autor ttulo ISBN editor pginas : : : : : -

Revista nombre volumen editor ISSN especialidad : : : : : + + + +

Video nombre productora director duracin : int : int : int : int

Figura 18. Modelo conceptual de la clase Material Bibliogrfico, definida por mecanismos de herencia.

De los atributos vistos en la Tabla N 6, se ha decidido hacer una clase conceptual aparte llamada Tema. Vimos cmo un material particular puede ser descrito por palabras claves o temas. Estos temas pueden ser muchos, lo cual trasciende el hecho de que sea un atributo simple. De hecho, la biblioteca podra tener una lista predeterminada obtenida de un catlogo de temas (lo que en la disciplina de Ciencias de la Informacin se llama un tesauro). Ac no se desarrollar la estructuracin del sistema bibliotecario en cuanto a su catlogo, sino que nos centraremos esencialmente en el prstamo y en la devolucin de materiales. Sin embargo, es importante visualizar aspectos importantes de este, como la jerarqua por herencia que hemos descrito, por cuanto nos hace ver las grandes posibilidades que se tiene al disear bajo la ptica del ADOO. La relacin Copia/Material se mantiene tal cual. Copia tendr un objeto de tipo material (lo veremos ms adelante). En ese caso, dicho material puede ser cualquiera: un libro, o un video, o una revista. Para efectos del diseo conceptual, no tiene importancia! Cualquiera de ellos es un material y, por lo tanto, Copia podr manejar cualquiera de ellos. Esta es una caracterstica muy poderosa que nos permite modelar la propiedad de herencia de la orientacin a objetos.

98

DEFINIENDO OPERACIONES EN EL MODELO Finalmente, vamos a completar otra caracterstica importante del modelo. Debemos identificar cules son las operaciones ms relevantes que cada clase debe cumplir, de acuerdo con las funcionalidades que se esperan del sistema. Recordemos, de acuerdo con lo que usted ha estudiado de la Programacin Orientada a Objetos, que las buenas prcticas nos dicen que los atributos de las clases deben ser privados, es decir, ningn elemento de software externo a la clase puede tener acceso a dichos atributos. Solo se puede acceder a los atributos y modificarlos mediante operaciones. A su vez, a travs de las operaciones, las clases exhiben un comportamiento, y dicho de una forma ms til para nuestros propsitos, aparte de exhibir un comportamiento, tambin ofrecen servicios. Servicios en qu medida? En que una parte de las funcionalidades requeridas del sistema la cumplirn objetos de una clase particular y, por ende, tal cumplimiento se har a travs de las operaciones de las clases que actuarn convenientemente en colaboracin con otras clases. Nuevamente, los casos de uso pueden ayudarnos a identificar qu servicios podra dar cada clase en el marco de lo que quiere implementarse como solucin en el sistema. Para efectos de ilustrar esto, tomemos lo referente al escenario en la descripcin detallada del caso de uso de Registrar Prstamo. El caso de uso comienza cuando el Bibliotecario ingresa al sistema la identificacin del usuario. El Sistema le indica si el Usuario es vlido. El Sistema, adems le indica si el Usuario tiene algn registro de morosidad. Una vez comprobados los pasos anteriores, el Bibliotecario lee del Sistema Bibliotecario la informacin del material que va a prestarse, a travs de un lector de cdigo de barras. En ningn caso puede prestarse otra copia del mismo material al mismo usuario, lo cual se comprueba por parte del Sistema cuando se hace esta lectura. El Sistema indica si el material puede ser prestado solo para uso interno de la biblioteca y el tiempo que puede ser prestado en cualquier caso. El Bibliotecario registra el prstamo del material y el caso de uso termina. En el paso 1, vea que alguna clase debe indicar si un usuario es vlido; esto significa que debemos averiguar el estado de un usuario en el Sistema. Cul clase tiene esa informacin? La clase Usuario. Por lo tanto, vamos a necesitar un mtodo en dicha clase que nos indique el estado de un usuario. Dicho mtodo u operacin podra llamarse ObtieneEstado. De forma anloga, leyendo el paso 2, alguna clase en el sistema deber indicar si un usuario es, o no es, moroso. Tal clase es RegistroMorosidad. Dicha clase tiene todos los registros que no han sido cancelados y, dichos registros, estn 99

asociados a un usuario. La operacin, suministrando la identificacin del usuario, puede indicar si este ltimo es moroso o no es, moroso. Esta operacin, de tipo boolean, puede llamarse UsuarioMoroso. En el paso 3, una clase debe suministrar la informacin del material que va a prestarse. En este caso, tal informacin debera ser provista por la clase Material. Recordemos que si bien estamos tratando con una copia del material, a travs de las relaciones, las clases incluyen objetos como atributos del tipo de otras clases. En este caso, la clase Copia incluye como atributo, un objeto de la clase Material. Tal operacin en la clase Material puede llamarse ObtieneMaterial. Adems, en la clase Prstamo debe existir una operacin la cual, suministrando parmetros adecuados, como es la signatura y la identificacin del usuario, averige si el usuario ya tiene prestada alguna otra copia del mismo material. Tal operacin podra llamarse TieneCopiaPrestada. En el paso 4, se indican las condiciones del prstamo para un material. Esto, sin duda, lo suministra la clase CondicionesPrestamo. Pueden obtenerse tres mtodos: ObtieneTipo (si es para uso interno o para prstamo externo), ObtieneTiempo, donde se indica la cantidad de tiempo que puede prestarse (un nmero entero positivo mayor que cero) y por ltimo, ObtieneUnidad, que nos indicar si se presta por horas o por das. El paso 5 nos indica, efectivamente, que debe registrarse un prstamo. Esto debe hacerlo la clase responsable, la cual es Prstamo. El registro debe asociar al usuario, la copia que se presta y el bibliotecario que hace el trmite. Para ello tambin necesitamos, en su momento, las operaciones o mtodos que nos den cada uno de los objetos de esas clases que se requieren para el registro. Tales operaciones son ObtieneCopia en la clase Copia; ObtieneBibliotecario en la clase Bibliotecario y ObtieneUsuario en la clase Usuario. Adems, el objeto de la clase Copia debe actualizar su estado, mediante una operacin llamada ActualizaEstado de disponible a prestada. Ya tenemos, por lo tanto, algunos mtodos que nos pueden ayudar en una definicin ms amplia de las clases. Esto se resume en la siguiente tabla. Nombre de la clase Bibliotecario Usuario Material Copia Prstamo Registro Morosos Condiciones Prstamo Operaciones o mtodos ObtieneBibliotecario ObtieneUsuario, ObtieneEstado ObtieneMaterial ObtieneCopia, ActualizaEstado RegistraPrstamo, TieneCopiaPrestada UsuarioMoroso ObtieneTipo, ObtieneTiempo, ObtieneUnidad

Tabla N 7. Mtodos identificados en cada una de las clases involucradas en el caso de uso de Registrar Prstamo.

100

Para seguir aadiendo operaciones, podemos revisar los escenarios de los otros casos de uso crticos del sistema: Registrar devolucin y Registrar devolucin con morosidad. En primera instancia, revisamos Registrar devolucin. El caso de uso empieza cuando el Bibliotecario introduce el cdigo del material que fue prestado mediante el cdigo de barras. El Sistema registra la devolucin e indica: La devolucin del (Libro / Revista / Video) xxxx fue registrada con xito. El paso 1 y el paso 2 parecen ocurrir de forma concurrente. El Sistema se prepara para registrar una devolucin y lo que sucede es que recibe el cdigo del material prestado e, inmediatamente, se registra la devolucin, tal como se indica en el segundo paso. Por lo tanto, se requiere de una clase que se encargue de hacer el registro de la devolucin. Eso correspondera a la clase Prstamo, que es la que tiene la informacin. Por sus atributos, para poder realizar la accin, dicha clase tiene la fecha de prstamo y las copias de los materiales prestados, entre los ms importantes. Tal operacin debe llamarse RegistraDevolucion. Esta operacin debe recibir, como parmetro, la identificacin del material devuelto y, con esa misma identificacin, debe actualizarse el estado de la copia en la clase Copia con la operacin ActualizaEstado que ya habamos definido para esta clase. Revisemos ahora el escenario correspondiente al caso de uso Registra devolucin con morosidad. El caso de uso empieza cuando el Bibliotecario introduce el cdigo del material que fue prestado mediante el cdigo de barras. El Sistema calcula el monto correspondiente por morosidad, de acuerdo con el tipo de material, las restricciones de uso y el retraso en tiempo. El Bibliotecario procede a dar Aceptar al registro de la devolucin, visualizando el monto del cobro que se le realizar al usuario. El Sistema registra la devolucin creando a su vez un registro de morosidad. El paso 1 no aade nada nuevo a las operaciones que hemos considerado anteriormente. El paso 2 indica que debe calcularse el monto de la morosidad. Ac enfrentamos una situacin. O bien, le damos tal responsabilidad a alguna clase del modelo que ya tenemos, digamos, Prstamo, por cuanto tiene la fecha u hora de prstamo y la fecha u hora de devolucin (de acuerdo al tipo de prstamo de que se trate); o bien, se puede pensar que se tiene una clase especializada en cuanto a calcular los costos de la morosidad.

101

Dicha clase tendra como atributos, los montos por morosidad por hora o da, y poseera operaciones para calcular el monto de morosidad, tal como indica el paso 2. Puede sugerirse, para conseguir mayor modularidad (esto lo veremos en el siguiente captulo), optar por la opcin de crear una nueva clase. A ella la llamaremos CostoMorosidad. El paso 3 indica que esa nueva clase debera tener una operacin que permita obtener el monto calculado. Tal operacin podra llamarse, ObtieneMonto. El paso 4 puede utilizar otra versin del mtodo RegistraDevolucin en la clase Prstamo. Esto es posible debido a que el paradigma de orientacin a objetos, mediante la sobrecarga de operaciones, permite tener distintas versiones para un mtodo con el mismo nombre. Adems, debe registrarse la morosidad generada en la devolucin, lo cual debe hacerse en la clase RegistroMorosos. Esta clase, por lo tanto, debe tener una operacin llamada RegistraMorosidad. A su vez, deber cambiarse el estado del usuario, situndolo a ste como usuario moroso. La clase Usuario, por lo tanto, debe tener una operacin llamada ActualizaEstado. De esta forma, al analizar esos dos casos de uso adicionales, podemos obtener una lista de mtodos u operaciones por clase, actualizada. En otro tipo de letra podemos visualizar las operaciones que se han agregado.

Nombre de la clase Bibliotecario Usuario Material Copia Prstamo Registro Morosos Condiciones Prstamo CostoMorosidad

Operaciones o mtodos ObtieneBibliotecario ObtieneUsuario, ObtieneEstado, ActualizaEstado ObtieneMaterial ObtieneCopia, ActualizaEstado RegistraPrstamo, RegistraDevolucin, TieneCopiaPrestada UsuarioMoroso, RegistraMorosidad ObtieneTipo, ObtieneTiempo, ObtieneUnidad CalculaMontoMorosidad, ObtieneMonto

Tabla N 8. Actualizacin de los mtodos por cada clase en el Sistema de Prstamo Bibliotecario.

De esta forma podemos obtener un diagrama actualizado del modelo conceptual.

102

Figura 19. Diagrama del modelo de clases conceptual incorporando los mtodos u operaciones por cada clase

103

En este ltimo diagrama de la Figura 19, advierta que se han agregado las operaciones en las clases correspondientes. Adems, se ha adicionado otra relacin entre Bibliotecario y Prstamo, puesto que en distintos momentos uno o varios bibliotecarios actan para registrar un prstamo (lo cual ya estaba) o para registrar en un prstamo, una o varias devoluciones. Detendremos ac el desarrollo del modelo conceptual. Nos hemos centrado, fundamentalmente, en obtener un modelo que pueda apoyar los objetivos del sistema para el prstamo y devolucin de materiales bibliogrficos, adicionando algunos controles, como es el registro de morosidad. Indudablemente, desarrollar otros casos de uso, es decir, otros objetivos del sistema y plasmarlos en el modelo de clases, aumentar, ya sea el nmero de clases, o bien los atributos y operaciones de las ya existentes. Recuerde que para algunos casos hemos hecho reflexiones (como el caso del registro de pagos), los cuales derivan en que se adicionen clases conceptuales al modelo. El proceso es laborioso y complejo, pero como lo habr notado, es muy rico en descubrimientos a la luz de las reflexiones que se hacen sobre el problema que deba resolverse. Tal como hemos insistido a lo largo de este desarrollo, los casos de uso guan totalmente la elaboracin de este modelo. Un hito importante del Proceso Unificado en la fase de Elaboracin, es obtener una arquitectura slida del sistema. La arquitectura debe ayudar a implementar los casos de uso. Al revisar el trabajo hecho en este captulo, podr darse cuenta cmo obtener este modelo puede aportar, e incluso, ser por s mismo el hito que se busca en la fase de Elaboracin. Con el insumo del modelo conceptual, podr pasarse a la elaboracin del modelo de clases de diseo. Esto lo trataremos en el siguiente captulo.

104

EJERCICIOS DE AUTOEVALUACIN 1. 2. Comente, de forma justificada, por qu son relevantes los casos de uso en el desarrollo del modelo conceptual de clases. Sea un entorno de conceptos alrededor de la produccin de obras musicales. Analice cules de los siguientes conceptos podran corresponder a clases y cules a atributos. Cantante Cancin Ao de produccin lbum Gnero musical Nmero de canciones Productor Sello discogrfico 3. Dentro de las clases conceptuales definidas en el ejercicio 2, establezca relaciones siguiendo la siguiente secuencia. a) Qu clases estn potencialmente relacionadas. b) Dentro de cada par de clases, cul clase requiere de la otra (puede ser que las dos requieran servicios de la otra). c) De un nombre a cada una de las relaciones (recuerde que debe hacerse en el extremo de la relacin de la clase que sirve a la otra). d) Defina la cardinalidad de la relacin. 4. En el contexto de la produccin musical, investigue de forma tal que usted pueda definir qu conceptos puedan establecer. a) Mltiples relaciones (2 o ms) entre dos clases. b) Relaciones entre la misma clase. c) Considerando un proceso de venta de los productos musicales, defina una especificacin de una clase. Lea atentamente el siguiente planteamiento. El Ministerio de Cultura ha decidido, en conjunto con el Ministerio de Turismo, crear un kiosco electrnico donde un ciudadano o turista puedan consultar los espectculos que se estn ofreciendo en el rea Metropolitana. El kiosco ofrece la posibilidad de que la persona pueda navegar, buscando informacin de su inters, adems de que pueda reservar el espectculo que le atraiga. Tales espectculos pueden ser de tres tipos: cine, teatro o deportes. Todos tienen caractersticas comunes, como horarios, localizacin, descripcin del espectculo, entre otros. Los de tipo teatro vienen con un video del director de la 105

obra, explicando sus aspectos. Los de cine tienen guardados textos con comentarios de asistentes y su nota, adems de tres reconocidos crticos que tambin otorgan una nota. Los deportivos no presentan ninguna informacin adicional. Sin embargo, estos ltimos ofrecen un regalo a las personas que reservan en lnea. De acuerdo con lo planteado anteriormente, elabore lo siguiente: El Diagrama de Casos de Uso. Desarrolle con detalle el caso de uso referido a la reserva de un espectculo. Extienda la definicin anterior con respecto a la reserva de los tipos de espectculos especficos (deportivos, de cine o teatro). Elabore el diagrama de clases conceptual que pueda implementar el caso de uso de reservar cualquier tipo de espectculo. (Sugerencia: elabore su modelo siguiendo los pasos vistos en el captulo. Adems, debe aprovechar el mecanismo de herencia del Paradigma Orientado a Objetos).

106

CAPTULO

DE CARA A LA IMPLEMENTACIN: EL MODELO DE CLASES DE DISEO

Sumario
CONSIDERACIONES PRELIMINARES

LA TRANSICIN DEL ANLISIS AL DISEO: LA VENTAJA DEL A/DOO

TARJETAS CRC: DOCUMENTAR Y EVALUAR LAS CLASES CONCEPTUALES

LAS CLASES DE DISEO DEL NEGOCIO

Refinamiento en la definicin de atributos y operaciones Constructores Tipo de datos de los atributos Tipos de retorno y parmetros de las operaciones Relaciones de asociacin y de composicin: las relaciones conceptuales vistas en la ptica del diseo Diferencia entre relaciones de asociacin y de composicin Apuntes sobre la jerarqua de herencia

LOS GESTORES: QUIN DIRIGE LA ORQUESTA?

Arquitectura en n-capas Definir clases de gestin

107

OBJETIVOS Una vez que usted estudie este captulo, podr llevar a cabo cada una de las siguientes actividades de aprendizaje, que le servirn para comprobar cunto ha aprendido de este tema Describir el proceso de la transicin de un modelo conceptual a un modelo de diseo. Explicar los conceptos de alta cohesin y bajo acoplamiento referidos a los modelos obtenidos mediante el Anlisis Orientado a Objetos. Indicar cmo se usan las tarjetas CRC para el proceso de definicin de clases. Explicar en qu consisten las clases de diseo del negocio. Transformar una clase conceptual en una clase de diseo del negocio mediante la definicin ms precisas de las operaciones y los atributos, as como la definicin de los constructores de las clases. Diferenciar las relaciones de asociacin y composicin y su efecto en los atributos de las clases involucradas. Analizar aspectos relacionados con la herencia, especficamente con las clases abstractas. Explicar en qu consiste la arquitectura de n-capas en el marco del Anlisis y Diseo Orientado a Objetos. Justificar por qu son valiosos los casos de uso para la definicin de las clases de diseo de gestin.

108

CONSIDERACIONES PRELIMINARES A travs del estudio de este captulo vamos a revisar varias actividades propias, relacionadas con generar un modelo de diseo para una solucin de Ingeniera de Software utilizando el Diseo Orientado a Objetos. De forma general, si recordamos, el diseo tiene que ver con la definicin de una estrategia para el proceso de implementacin del software3. Al ubicar las fases genricas de la Ingeniera de Software, un proyecto de esta disciplina debe pasar, entre varias actividades, por el anlisis y diseo. Lo desarrollado hasta el captulo anterior, estara correspondiendo a las actividades de anlisis: la identificacin, definicin y refinamiento de los casos de uso y del modelo conceptual han buscado proveer, precisamente, una definicin de los requerimientos que busca implementar el sistema que necesita construirse. Uno de los retos ms importantes que tiene la Ingeniera de Software es cmo adoptar los modelos generados en la fase de anlisis, en la fase de diseo. Haremos, en primera instancia, una reflexin sobre el significado de esa transicin en el A/DOO visualizndolo en el proceso, de una forma muy prctica. Posteriormente veremos cmo surgen necesidades de crear otras clases de cara al funcionamiento del sistema. LA TRANSICIN DEL ANLISIS AL DISEO: LA VENTAJA DEL A/DOO Cuando se han hecho tareas de Anlisis con el objeto de identificar clases (desde el punto de vista conceptual), se busc elaborar un modelo con elementos que trataran, en primera instancia, a responder a las necesidades de los objetivos del sistema. En este caso, se usaron intensivamente los casos de uso para ubicar conceptos, para crear las clases conceptuales pertinentes, para relacionar tales clases y caracterizar cada una de ellas a travs de la definicin de sus atributos y operaciones ms importantes de cara a los requerimientos de cada caso de uso. El ejercicio de creacin de esas clases, si lo not, busc que cada concepto, separadamente, estuviera bien definido en cuanto a sus caractersticas: los atributos y operaciones que deben tener, con el propsito de lo que cada clase debe cumplir en el Sistema. Incluso, en su momento en el ejemplo de la Biblioteca, llegaron a crearse clases, como la que se denomin CostoMorosidad, por cuanto se vio necesario que una clase pudiera cumplir con aspectos especficos de calcular lo relativo a los montos de morosidad dentro de la funcionalidad del sistema. Esa tarea no poda ubicarse en ninguna otra clase, o bien, si se haca as, hubiera parecido algo artificial (por ejemplo, que fuera competencia de la clase Prstamo).
3

Puede consultar ms teora relativa a la Ingeniera del Diseo en Pressmann (2006), Ingeniera del Software. Un enfoque prctico.

109

Al definir clases bajo esa perspectiva, podemos relacionarlo con el conocido refrn popular de zapatero a tus zapatos. Con ello quiere decirse que cada clase que hemos definido cumple un rol muy especfico dentro del sistema y que debe especializarse y saber solamente lo concerniente a ese rol. Por ejemplo, la clase Prstamo solo se dedica a registrar prstamo y la devolucin de ese prstamo. Producto de ese conocimiento sobre los prstamos, se da cuenta que alguno de stos est retrasado y se lo dice a Registro Morosos para que proceda esta clase a llevar a cabo lo que ella deba realizar. Significa que la clase Prstamo debe saber cmo lo hace RegistrarPrstamo? No, no lo sabe. Solamente le dice esta copia de material la devolvieron con retraso. Definir clases de esta forma, encapsulando los atributos y operaciones que solamente conciernen a ella, estableciendo comunicacin con otras clases mediante relaciones, persigue, en el fondo, que aparte de lograr cumplir con los objetivos requeridos del sistema, tambin pueda realizarse una transicin hacia la fase de diseo de forma ms suave. Por qu? Porque cuando definimos clases de la forma que lo hicimos, podemos lograr encontrar que ellas puedan, eventualmente, cumplir con los principios en el diseo con respecto a la alta cohesin y el bajo acoplamiento. Recordemos brevemente estos conceptos: nos dice Pressmann (2006) que una clase de diseo cohesiva tiene un conjunto de responsabilidades pequeo y enfocado, y aplica atributos y mtodos de manera sencilla par implementar dichas responsabilidades. Hemos trabajado de esta forma con las clases conceptuales? Cada una de ellas tiene un conjunto pequeo y enfocado de responsabilidades? Se expresan esas responsabilidades de forma sencilla a travs de atributos y mtodos? Le queda a usted contestar si ello lo hemos logrado a travs del ejercicio que hemos desarrollado. Mi criterio es que s se ha hecho en gran medida as. Por otra parte, el mismo autor nos dice que acoplamiento bajo se refiere a que dentro del modelo de diseo es necesario que las clases de diseo colaboren con alguna otra. Sin embargo, la colaboracin debe mantenerse en un mnimo aceptable. Si un modelo de diseo tiene un acoplamiento alto (todas las clases de diseo colaboran con todas las otras clases de diseo), el sistema es difcil de implementar, probar y mantener a travs del tiempo. En general, las clases de diseo deben tener slo un conocimiento limitado de las otras clases. De igual forma, observe que, si se visualiza el diagrama de clases conceptuales, las colaboraciones (expresadas como relaciones) que se dan entre clases, es el mnimo necesario para cumplir las metas del sistema. Vea que podemos, mediante el ADOO, ir cumpliendo con esos objetivos de alta cohesin y bajo acoplamiento de una forma muy natural, continuando con el proceso que seguimos en el captulo anterior. En ese momento no hablamos de estos principios generales de la Ingeniera del Diseo. Lo que pasa es que elaborar clases bajo el anlisis orientado a objetos, incorpora, desde ese 110

momento, principios relativos a la fase de Diseo, aun cuando solo estamos revisando conceptos, definiendo clases, atributos y relaciones a la luz de los casos de uso, es decir, actividades de muy alto nivel de abstraccin. Larman (2003) nos indica que existe una reduccin del salto en la representacin. Siguiendo lo expuesto por este autor, cuando modelamos una clase conceptual esto obedece a que estamos acercndonos a modelar algo del mundo real. En el caso de nuestro Sistema de Prstamo Bibliotecario, si por ejemplo se sabe que un prstamo tiene una fecha o una hora en que un material se presta y que, adems, el prstamo debe registrarse, entonces al elaborar la clase conceptual correspondiente, debe modelarse esta funcionalidad. Luego, al trasladarse esa clase conceptual, proveniente del anlisis, hacia un modelo de diseo y este, a su vez, la realizamos en un lenguaje de programacin particular, entonces obtendremos un producto de software que se concibi, en primera instancia, como conceptos y procesos del mundo real: un material bibliogrfico, un prstamo, un registro de prstamo. En los siguientes diagramas y cdigo de programacin podemos ver esta evolucin.

Copia - id_copia : 1..* Incluye 0..*

Prstamo - Fecha : - Hora :

Representacin conceptual

Copia - id_copia : String + ObtieneCopia () : Copia

Prstamo 1..* Incluye 0..* - Fecha : Date - Hora : Time + RegistrarPrestamo () : int

Representacin de diseo

Figura 20. Representaciones de la clase Prstamo y Copia en el modelo conceptual y en el modelo de diseo.

111

public class Prstamo { private Date Fecha; private Time Hora; public Copia[] Incluye; public int RegistrarPrstamo() { // debe implementarse el cdigo ac return 0; } }
Figura 21. Representacin de la clase Prstamo en JAVA.

Note como todos los elementos se mantienen desde su origen como concepto y, lo que sucede en distintas etapas de la Ingeniera de Software, es un proceso de incorporacin de aspectos propios de cada una de las fases. Es as como podemos comprender que un buen modelo conceptual es un paso muy importante que resulta en que la transicin entre fases pueda ser, tal como lo mencionamos, suave. En la siguiente seccin veremos uno de los aspectos derivados de esta transicin. Vamos a definir de una forma ms precisa los atributos y las operaciones del modelo conceptual, vistos ahora como clases de diseo. TARJETAS CRC: DOCUMENTAR Y EVALUAR LAS CLASES CONCEPTUALES En este punto, es una buena prctica constatar aspectos cohesin y acoplamiento de las clases conceptuales, mediante una revisin de las responsabilidades y servicios que da cada clase. Uno puede contar con mecanismos como las llamadas Tarjetas CRC (Clase-Responsabilidad-Colaborador) donde se establecen las responsabilidades y las colaboraciones por clase. Una tarjeta CRC es sencilla (como siempre, el quid del asunto es como usarla de forma apropiada). Para cada clase se define una estructura como la que sigue:

112

Nombre de la clase Descripcin Responsabilidad

Colaborador

Como puede observarse, cada clase se describe brevemente en la seccin descripcin. Luego se establece una columna, donde se define qu responsabilidades asume cada clase y qu colaboradores (otras clases) debe tener para poder cumplir una responsabilidad especfica. Por ejemplo, para la clase Prstamo podramos establecer una tarjeta CRC de la siguiente forma.

Nombre de la clase: Prstamo Descripcin: Clase que maneja los aspectos relativos al registro de prstamos de material bibliogrfico y sus devoluciones. Responsabilidad Colaborador Registrar prstamos de materiales bibliogrficos Copia, Bibliotecario, Usuario, CondicionesPrstamo Copia, Bibliotecario

Registrar devolucin de materiales prestados Detectar si una devolucin est en mora

Iniciar proceso de registrar una devolucin morosa RegistroMorosos, Usuario, CostoMorosidad Indicar si ya un usuario tiene una copia del mismo material prestado Usuario, Copia, Material

Este tipo de documentacin es posible generarla cuando se ha tenido un proceso bastante alto de conocimiento del problema, mediante las actividades de anlisis. Es deseable poder contar con este insumo cuando se inicia la fase de diseo, pues permite, por una parte, evaluar aspectos relativos a la cohesin y a la necesidad

113

de acoplamiento entre clases y, por otra parte, obtener un insumo de cara a la estrategia de implementacin. No pierda de vista que las responsabilidades que asume la clase Prstamo son del dominio de su conocimiento. Si se incluyera la responsabilidad, por ejemplo de calcular el monto por mora, esta clase debera tener atributos que le seran conceptualmente ajenos, como el costo por retraso por unidad de tiempo (das u horas). Tal servicio lo asume, como ya se describi anteriormente, la clase CostoMorosidad. De asumir tal responsabilidad la clase Prstamo, se estara incurriendo contra el principio de cohesin y el de acomplamiento. Con lo que se ha comentado en estos prrafos y con los conocimientos que usted debe manejar de los cursos de Anlisis y Diseo, explique el porqu de la afirmacin que se hizo. LAS CLASES DE DISEO DEL NEGOCIO Cuando se ha obtenido un modelo conceptual donde sus clases, atributos y operaciones clave estn bien definidos, y ellas son altamente cohesivas y estn dbilmente acopladas, tal logro constituye un gran avance con miras al diseo. En tales clases deben tomarse algunas decisiones de cara a la implementacin. Las clases conceptuales y su transformacin en clases de diseo constituyen lo que se llama las clases de diseo del negocio. Esta denominacin, muy ampliamente aceptada, se refiere a que se centran en los procesos de negocio que una organizacin quiere implementar, es decir, donde la semntica de las clases y de los procesos involucrados tienen una referencia a lo que Larman se refiere de que los modelos generados tienen una correspondencia en el mundo real. Por ejemplo una copia de un material existe en una biblioteca, as tambin un proceso de registrar un prstamo. Lo que hemos venido analizando, por lo tanto, corresponde a lo que es el negocio de una biblioteca. En una arquitectura estratificada o por capas, se estara hablando con esta serie de clases de negocio, de la capa del negocio. Retomaremos lo referente a la arquitectura por capas ms adelante.

Refinamiento en la definicin de atributos y operaciones

Volviendo a nuestro modelo, alguna de las decisiones ms bsicas con respecto a transformar las clases conceptuales en clases de diseo, tienen que ver con el tipo de datos de cada uno de los atributos, los parmetros de las operaciones, el valor de retorno de las operaciones, la necesidad de definir atributos de clase (que son globales a todos los objetos de una clase), entre varios aspectos puntuales que deben realizarse. Tomemos como ejemplo la clase Prstamo que es una de las clases medulares de nuestro Sistema en el ejemplo que hemos venido desarrollando relacionado con la

114

Biblioteca. Desde el punto de vista de nuestro modelo conceptual, hemos obtenido la siguiente definicin para esta clase.
Prstamo nmero_prstamo fecha_prstamo hora_prstamo tiempo_prstamo unidad_tiempo estado_prstamo : : : : : :

+ RegistraPrstamo () + RegistraDevolucin () + TieneCopiaPrestada ()

Debemos recalcar nuevamente que una tarea bien desarrollada en el modelo conceptual, facilita enormemente el trabajo de las clases de negocio en el modelo de diseo. Vea que el trabajo de clases conceptuales lo hemos realizado de cara a los objetivos del sistema y, por lo tanto, al ser retomadas en la fase de diseo, quedan pocas preguntas que hacerse con respecto a cunto cumplen (o no) esas clases de cara a implementar el sistema. De esta forma, los diseadores podrn ir concentrndose en aspectos de la definicin tcnica de la clase, de los detalles algortmicos de las operaciones, de cmo lograr eficiencia, robustez y rendimiento del sistema, de cmo debe ser la interaccin hombre/mquina, etc. Todo ello, en fin, buscando el reto ms importante de la fase de diseo: la calidad del software. Volviendo a la clase Prstamo en este momento un diseador puede ver la clase y hacer observaciones y preguntas tales como: Los constructores de clase, cmo debo hacer tales constructores? Debo inicializar todo los parmetros en null, o bien, necesito asignar algn parmetro con un valor determinado? De qu tipo son los atributos? El nmero de prstamo cmo lo genero? Es un consecutivo normal, o bien es un correlativo con respecto a algo y todos los objetos de la clase deben mantenerlo (es decir, es un atributo de clase, no de objeto)? Qu parmetros requieren las operaciones y qu tipo de datos devuelven? Deben tenerse operaciones del tipo actualizar/obtener para todos los atributos? De esta forma puede comenzar a transformarse una clase conceptual en una clase de diseo. Si contestamos, a manera de ejemplo, cada una de las preguntas planteadas arriba, podramos tomar algunas decisiones con respecto a la clase Prstamo.

115

Constructores
Bien se sabe que toda clase debe tener, al menos, un constructor, que es una operacin que permite crear los objetos pertenecientes a esta. Un constructor, por defecto, siempre crea un objeto con todos los atributos con valor nulo o null. En el caso de prstamo, qu necesidad se tiene de tener constructores que no sea el constructor por defecto? Analicemos. Los atributos de la clase Prstamo estn orientados a crear una transaccin que debe registrarse en el momento preciso que esta ocurra, por ejemplo, la hora, el da, los materiales que se prestan, el tiempo de prstamo para cada material, el usuario asociado, el bibliotecario que ejecuta la accin. Por lo tanto, al imaginar la transaccin, tal como sucede en el mundo real, uno podra tener una secuencia de pasos como la siguiente. 1. El bibliotecario elige la opcin de Registrar Prstamo en el men. 2. Se pide la identificacin al usuario, se introduce y se verifica que tiene derecho a realizar solicitudes de prstamo. 3. Se incluye cada material solicitado en el prstamo. 4. Se hacen verificaciones por cada material prestado (por ejemplo que no tenga otra copia del mismo material prestada en este momento). 5. Se determina el tiempo de prstamo en cada material. 6. Se registra el prstamo. Al imaginar lo que sucede en el sistema (que quedar ms claro cuando estudiemos los diagramas de secuencia), imaginamos lo que puede suceder en cada momento con operaciones que pueden estar en Prstamo. Revisamos a continuacin cada paso. El bibliotecario elige la opcin de Registrar Prstamo en el men. Se utiliza el constructor por defecto de la clase y se tiene un nuevo objeto de la clase Prstamo. Se pide la identificacin al Usuario, se introduce y se verifica que tiene derecho a realizar solicitudes de prstamo. Puede utilizarse el mtodo de la clase Usuario para ActualizarUsuario en el atributo de usuario que debe tener, por asociacin, la clase Prstamo4. Se incluye cada material solicitado en el prstamo. Con el lector de cdigo de barras se obtiene la informacin de la copia de cada material. Cuando se cre el
4

Si bien ahora nos concentraremos en los atributos propios de la clase Prstamo, en un apartado ms adelante veremos que las relaciones creadas en el modelo conceptual implican que Prstamo debe tener atributos de las clases con las que colabora, a saber, Usuario, Bibliotecario, Copia.

116

objeto de Prstamo, se debi crear una lista vaca de las copias del material por prestar. En este momento, se incluye, en la lista, cada uno de los materiales que se prestan. Por lo tanto, Prstamo debera tener una operacin llamada IncluirCopiaEnPrstamo que actualice la lista de copias de materiales prestados. Se hacen verificaciones por cada material prestado (por ejemplo que no tenga otra copia del mismo material prestado en este momento). Se utiliza el mtodo de la clase Prstamo de TieneCopiaPrestada con los parmetros de la signatura del material y la identificacin del usuario. Se determina el tiempo de prstamo en cada material. Se obtiene el tiempo de prstamo del material mediante los mtodos de la clase CondicionesPrstamo. Se registra el prstamo. Se utiliza el mtodo RegistrarPrstamo. Sus parmetros deben ser el Bibliotecario que hace la transaccin, el Usuario, la lista de materiales prestados, CADA UNO con el tipo de prstamo y el tiempo que se prest. La fecha y hora de prstamo se obtienen de funciones del sistema como los pueden ser Today() y Now() que dan la fecha actual y la hora actual, respectivamente. Note que el ejercicio nos sirvi para muchas cosas, no solamente para aspectos relacionados con el anlisis del constructor. Veremos, en un momento, que nos ha ayudado tambin a definir varios otros aspectos, entre ellos, una modificacin al modelo de clases. El repaso tambin nos ha permitido comprobar que casi todos los atributos de un objeto de la clase Prstamo se obtienen en el transcurso del proceso de ingreso de la informacin del prstamo. De esa forma, casi no se ve necesidad de crear un constructor que no sea el constructor por defecto. Sin embargo, s debe ponerse atencin en el hecho de que la lista de copias de materiales por prestar debera estar creada (es decir, que no debe estar en null) para cuando reciba materiales. Por lo tanto, el constructor -por defecto- puede modificarse de forma tal que se inicialice para que la lista de materiales est inicializada y, por ende, preparada para recibir tems dentro de ella. Antes de seguir analizando las otras preguntas surgidas por parte de un diseador, tenemos que ver una situacin que arroj el anlisis anterior y que hace una modificacin importante en nuestro modelo. Nos referimos a lo que se detect con la frase Sus parmetros deben ser () la lista de materiales prestados, CADA UNO el tipo de prstamo y el tiempo que se prest. Recordemos el anlisis hecho con respecto a la devolucin de materiales cuando analizbamos el modelo conceptual. Argumentbamos que no poda tenerse un estado global del prstamo, porque podra suceder que no todos pudieran devolverse al mismo tiempo. Ahora bien, uno podra suponer ac que para efectos del prstamo, todos los materiales van a tener la misma hora y fecha, los cuales son globales para todos los materiales dentro de la transaccin. Tome en cuenta que, como todos son materiales distintos, cada uno de ellos tiene condiciones de prstamo diferentes. De esta forma, no puede suponerse que todos tienen el 117

mismo tipo y tiempo de prstamo, tal como lo indica el diseo actual. Por lo tanto, ste no responde a las necesidades de control que requerimos. Esto nos impulsa a que tengamos que hacer una modificacin en nuestro modelo de clases, de tal forma que encontremos una nueva clase que pueda manejar, de forma individualizada, el tiempo de prstamo de cada uno de las copias de los materiales. Ac podra argumentarse que podramos tener tales datos en CondicionesPrstamo. Pero puede suceder que en cualquier momento tales condiciones pueden variar, por lo tanto es necesario que otro elemento pueda ayudarnos a indicar las condiciones originales en las cuales se realiz un prstamo. Podemos tener, por lo tanto, una clase nueva en nuestro modelo, llamada DetallePrstamo, asociada a Prstamo y a Copia, donde se describen los detalles del prstamo de cada copia de material. El diagrama, en este punto, se modificara as:

Bibliotecario 1..1 RegistraDevolucin - id_usuario : - nombre : + ObtieneBibliotecario () 1..1 HechoPor

0..* 0..* DetallePrstamo Copia - id_copia : - estado_copia : + ObtieneCopia () + ActualizaEstado () 1..1 Incluye 0..* fecha_prestamo hora_prstamo unidad_tiempo fecha_devolucin hora_devolucin : : : : : Prstamo 1..1 Detalla numero_prstamo fecha_prstamo hora_prstamo estado_prstamo : : : :

1..*

1..1 SeFundamentaEn

+ RegistraPrstamo () + RegistraDevolucin () + TieneCopiaPrestada () 1..1 GeneradoPor

1..1

0..* Registro Morosos fecha_registro importe_moroso estado fecha_pago : : : :

+ RegistraMorosidad () + UsuarioMoroso ()

Figura 22. Diagrama modificado al incorporar la clase Detalle Prstamo.

Observe que al asumir la clase DetallePrstamo un papel protagnico en el proceso, varias relaciones se modifican. En primer lugar, en relacin con la clase Prstamo, esta nueva clase asume una relacin de detallar, con respecto a las copias de los materiales que se incluyen. Este comportamiento, en mucho, es tpico en los sistemas que vemos cotidianamente, por ejemplo, en una factura y 118

en cada una de las lneas de la factura, donde se detallan los productos adquiridos. O bien, un informe de matrcula, donde se detallan todos los cursos matriculados por un estudiante. Por otra parte, esta nueva clase va a tener los atributos correspondientes al detalle del prstamo de cada una de las copias de los materiales: as entonces tendr la fecha y hora del prstamo, la unidad de tiempo (horas o das) y, adems, manejar la fecha y hora de devolucin. Esto la har capaz de tener toda la informacin relativa a poder generar un registro de morosidad. Por lo tanto, vemos que la relacin de RegistroMorosidad se hace directamente hacia esta nueva clase. La relacin Prstamo/RegistroMorosidad tampoco ser necesaria. Cada vez que se hace una devolucin, el Bibliotecario registrar su accin directamente en el detalle. La tarjeta CRC que habamos elaborado anteriormente para la clase Prstamo, cambiar las responsabilidades y colaboraciones de esta clase y, por otra parte, la clase DetallePrstamo asumir nuevas responsabilidades, entre ellas, algunas que le correspondan a la clase Prstamo. Como ejercicio, usted puede elaborar las tarjetas CRC para estas dos clases.

Tipo de datos de los atributos

Producto del cambio realizado, podemos dar un nuevo vistazo a la clase prstamo:
Prstamo - numero_prstamo : : - fecha_prstamo : - hora_prstamo : + RegistraPrstamo () + RegistraDevolucin () + TieneCopiaPrestada ()

Con una fisonoma ms depurada, ahora podemos seguir con el ejercicio de incluir el constructor de la clase y, adems, definir los tipos de datos de cada uno de los atributos. El atributo nmero_prstamo podra corresponder a un nmero consecutivo, o bien ser un nmero correlativo. Si fuera un consecutivo podramos plantear que fuera un tipo de dato numrico normal, como un long. Sin embargo, si fuera correlativo, podra pensarse que fuera la composicin de algo como: ao + consecutivo. Podramos ver el nmero de prstamo parecido a 2007000000001. En este caso, sera ms aconsejable utilizar cadenas de caracteres, o el tipo String. Vamos a asumir la alternativa del correlativo. Para poder construir el correlativo, la clase Prstamo debera manejar dos atributos de clase, es decir, atributos que son vistos de forma global por todos los

119

objetos pertenecientes a la clase y, si alguno de estos objetos modifica ese atributo, el cambio es visible para todos los dems objetos. En este caso necesitamos los atributos de clase de Ao y de Consecutivo en Prstamo (recuerde que debern declararse con el modificador static, tratndose del lenguaje JAVA). El atributo Ao lo llamaremos Anno, para efectos del manejo adecuado de un lenguaje de programacin que no maneja bien la letra castellana ee. Este atributo ser de tipo entero. El consecutivo se llamar Consecutivo (se distinguirn atributos de objeto de los de clase en el modelo, dado que estos ltimos iniciarn su nombre con mayscula). En el momento en que se registra el prstamo, esta operacin har las conversiones necesarias de esos valores para que pueda componer el correlativo y asignrselo al atributo nmero_prstamo. Si el registro del prstamo tiene xito, se aumentar en uno el atributo de Consecutivo y la prxima transaccin de este tipo que realice cualquier otro objeto, utilizar ese nmero ya actualizado. El atributo fecha_prestamo se adjudicar un tipo de dato Date (fecha) y el de hora_prstamo asumir, por su parte, un tipo de dato Time (hora). El atributo estado_prestamo podra ser de tipo char (caracter), manejando un dominio de valores significativos para sus estados: la letra A para indicar abierto y C para indicar que el prstamo ya est cerrado. Observe cmo la definicin de los atributos se hace de acuerdo con alguna decisin relativa a la implementacin. No es casual. Claro est que las facilidades que nos pueden ofrecer los lenguajes de programacin ayudan a tomar estas decisiones. Por ejemplo, el hecho que JAVA provea un tipo de datos Date (fecha) es una ventaja para manejar atributos de esta naturaleza. Una visin actualizada de la clase Prstamo la veremos a continuacin.

Prstamo + + + + Anno Consecutivo numero_prstamo fecha_prstamo hora_prstamo estado_prestamo : int : long : java.lang.String : java.util.Date : java.util.Time : char

Prstamo () RegistraPrstamo () RegistraDevolucin () TieneCopiaPrestada ()

Note cada uno de los atributos ya definidos en sus tipos. Por otra parte, dentro de los mtodos ya se ha incluido el constructor (en JAVA, recuerde, los constructores son mtodos u operaciones que se llaman igual que la clase). Advierta, adems que los tipos en las clases de diseo se establecen de acuerdo con el lenguaje de programacin especfico que va a utilizarse. De ah que, por ejemplo, fecha_prstamo especifique en su tipo, la ruta del paquete java.lang.Date.

120

Hasta este punto hemos agregado constructores, hemos definido los atributos e, incluso, hemos definido atributos de clase de acuerdo con las preguntas hechas por el diseador. Pasamos ahora a definir aspectos relativos a las operaciones.

Tipos de retorno y parmetros de las operaciones

La definicin durante la fase de diseo incluye una especificacin ms precisa de las operaciones. Incluso, el diseo procedimental nos pide formular un detalle algortmico de cada operacin. Esto lo ilustraremos ms adelante, cuando estudiemos los diagramas de actividad. Ahora vamos a enfocarnos en definir, dentro de la clase Prstamo, lo referente a los parmetros de cada operacin y los tipos de retorno de cada una de ellas. Como ya vimos, la operacin Prstamo es el constructor de la clase. Su papel es crear objetos de tipo Prstamo. No va a recibir ningn parmetro y, salvo la modificacin anotada de inicializar, dentro de las acciones del constructor, una lista vaca para las copias del material que se deben incluir, se mantendr el constructor estndar para la clase. La operacin RegistraPrstamo deber tener los siguientes parmetros: el Usuario que solicita el prstamo, el Bibliotecario que lo hace y la lista de materiales que van a prestarse. Puede tenerse un valor de retorno del tipo int (entero), para que el programa, analizando ese valor devuelto, pueda detectar alguna accin de error. Si no ocurre nada anmalo, la operacin devuelve un valor de 0 (cero). La operacin RegistraDevolucin ya no sera responsabilidad de la clase Prstamo (analcelo a raz de las tarjetas CRC que usted cre), sino que pasar a ser parte de las responsabilidades de la clase DetallePrstamo. Por otra parte, dentro del anlisis de la secuencia de pasos que hicimos anteriormente, tuvimos la necesidad de crear una operacin dentro de esta clase que aada tems a la lista de copias de materiales que van a prestarse. La operacin la llamaremos IncluirCopiaEnPrstamo. Esta operacin recibe un parmetro, un objeto de tipo Copia, el cual se aade a lista de copias que contiene la clase Prstamo. Esta operacin no devuelve ningn tipo de valor en particular. La operacin TieneCopiaPrestada tendr como parmetro la identificacin del usuario y la signatura del material al que pertenece una copia. Devolver un valor booleano, cuyo valor es verdadero si existe un prstamo activo de ese material relacionado con el usuario, o bien falso sino existe tal prstamo. Finalmente, en cuanto a las operaciones, debe establecerse si cada uno de los atributos tendr una operacin de Obtener y otra correspondiente de Actualizar. En general, es una prctica en la orientacin a objetos, establecer operaciones para actualizar o dar valor a cada uno de los atributos, as como 121

tambin para obtener el valor de cada uno de dichos atributos. Esto por cuanto el acceso a los atributos solamente puede hacerse a travs de operaciones. Sin embargo, no siempre esa regla debe cumplirse. Si se analizan cada uno de los atributos de los objetos (no los atributos de clase), podr pensarse si ellos necesitan estas operaciones del tipo actualizar/obtener. En las de actualizar significa que puede cambiarse el valor del atributo en el momento que se requiera. Por ejemplo, nmero_prstamo es un valor transaccional generado por el sistema. De igual forma, la hora y fecha del prstamo se asignan automticamente por la transaccin. Por lo tanto, por control, estos atributos NO deberan tener operaciones de actualizar. Por su parte, en cuanto al estado del prstamo, s podra actualizarse, pero de una forma muy especfica: esto sera con la transicin del estado Abierto al estado de Cerrado. Una vez que el prstamo presenta ese estado, no podr actualizarse. La operacin pertinente (ActualizaEstado) debe controlar esa situacin. Las operaciones tipo actualizar reciben como parmetro un valor igual al del atributo. En este caso, si estado_prstamo es de tipo char, la operacin recibir un parmetro de este tipo5. En el caso de operaciones tipo obtener, no se encontrara ningn problema en poder saber cada uno de los atributos de los objetos. El tipo de valor de retorno de estas operaciones, correspondera al tipo de atributo sobre el que acta. Por ejemplo, si nmero_prstamo es String, entonces la operacin devuelve un String. Una clase de diseo para Prstamo, vista dentro del diagrama, con el trabajo realizado, lucira de esta forma:

Prstamo + + + + + + + + + Anno Consecutivo nmero_prstamo fecha_prstamo hora_prstamo estado_prestamo : int : long : java.lang.String : java.util.Date : java.util.Time : char

Prstamo () RegistraPrstamo (Usuario pUsu, Bibliotecario pBib, Copia[] pCop) TieneCopiaPrestada (String pIdUsu, String pIdMat) IncluirCopiaEnPrstamo (Copia pCopia) ObtieneNmeroPrstamo () : String ObtieneFechaPrstamo () : Date ObtieneHoraPrstamo () : Time ActualizaEstadoPrstamo (char pEstado) : char ObtieneEstadoPrstamo ()

Figura 23. Diagrama que muestra la clase Prstamo desde el punto de vista del diseo.

En la familia de lenguajes de programacin orientados a objetos de .NET, las operaciones Obtiene/Actualiza se implementan mediante un mecanismo llamado property (propiedad). En el caso de que un atributo no pueda ser actualizado, tal como se discuti, la propiedad se dice que es Read Only (de solo lectura).

122

Si vemos el cdigo en JAVA de la clase Prstamo, dicho cdigo lucira as:

import java.util.*; public class Prstamo { private static int Anno; private static long Consecutivo; private java.lang.String numero_prstamo; private java.util.Date fecha_prstamo; private java.util.Time hora_prstamo; private char estado_prstamo; public Prstamo() { } public RegistraPrstamo(Usuario pUsu, Bibliotecario pBib, Copia[] pCop) { } public TieneCopiaPrestada(String pIdUsu, String pIdMat) { } public IncluirCopiaEnPrstamo(Copia pCopia) { } public String ObtieneNmeroPrstamo() { } public Date ObtieneFechaPrstamo() { } public Time ObtieneHoraPrstamo() { } public ActualizaEstadoPrstamo(char pEstado) { } public char ObtieneEstadoPrstamo() { return this.estado_prstamo; } } Figura 24. La clase de diseo Prstamo, vista en cdigo JAVA

123

Comparar lo que muestra una clase conceptual y lo que muestra una clase de diseo es importante. Cada trabajo tiene su momento. Cuando se crea la clase conceptual no deberamos pensar en detalles como los que ac hemos abordado: tipos, parmetros, operaciones actualiza/obtiene, constructores, entre otros. En los modelos conceptuales no debemos molestarnos en cosas como esas, sino en descubrir aspectos relevantes del problema. Vea que lo que puede toparse un ingeniero de software en sus tareas de diseo, podra ser tratar con aspectos conceptuales que no se consideraron en su momento, o que no se detallaron ms finamente, como lo que sucedi en nuestro trabajo con la clase CopiaPrstamo. Esto NO ES PECADO. Recordemos que durante todas las fases del Proceso Unificado persisten las tareas de requisitos, anlisis, diseo. El modelo conceptual puede corresponder tpicamente a la fase de elaboracin del UP, mientras que el diseo corresponde ya a la fase de construccin. Sin embargo, realizar elaboracin de requisitos y anlisis no desaparece en ninguna fase. Sera lamentable que se arrastraran errores a etapas finales donde son ms caros los cambios. Vea que nosotros simplemente modificamos el diagrama. Y s, de verdad que fue simplemente as.

Relaciones de asociacin y de composicin: las relaciones conceptuales vistas en la ptica del diseo
Cuando se cre el modelo conceptual de nuestro sistema de prstamo bibliotecario, se vio la necesidad de que algunas clases colaboraran con otras. Con ese propsito dibujamos algunas relaciones. Esas relaciones tienen un significado que, igualmente, tienen repercusiones desde el punto de vista del diseo. Revisemos nuestro diagrama, centrados en las clases que intervienen en los procesos de prstamo y de devolucin:

124

Bibliotecario - id_usuario - nombre + ObtieneBibliotecario () 1..1 HechoPor 1..1 RegistraDevolucion : :

0..* Prestamo

0..*

DetallePrstamo

Usuario

1..* Incluye 1..1

: int : long : java.lang.String : java.util.Date : java.util.Time : char 0..*

fecha_prstamo hora_prstamo unidad_tiempo fecha_devolucin hora_devolucin

: : : : :

Anno Consecutivo nmero_prstamo fecha_prstamo hora_prstamo estado_prstamo

1..1 Adjudica

- id_usuario - nombre - estado

: : : + ObtieneUsuario () + ObtieneEstado () + ActualizaEstado ()

0..*

1..1 SeFundamentaEn

+ + + + + + + + + Prstamo () RegistraPrstamo (Usuario pUsu, Bibliotecario pBib, Copia[] pCop) TieneCopiaPrestada (String pIdUsu, String pIdMat) IncluirCopiaEnPrstamo (Copia pCopia) ObtieneNmeroPrstamo () ObtieneFechaPrstamo () ObtieneHoraPrstamo () ActualizaEstadoPrstamo (char pEstado) ObtieneEstadoPrstamo () : String : Date : Time : char

1..1 Detalla 1..1

Copia -

Registro Morosos fecha_registro importe_moroso estado fecha_pago : : : : + RegistraMorosidad () + UsuarioMoroso ()

- id_copia - estado_copia

: :

+ ObtieneCopia () + ActualizaEstado ()

Figura 25. Diagrama de clases de diseo involucradas en el proceso del prstamo de libros

125

Note que an conservamos las relaciones que establecimos desde el punto de vista conceptual. Si usted recuerda, cuando las fuimos creando, se les sugera que estas fueran nombradas especificando el papel de la relacin, es decir el nombre, en el extremo de la clase que era necesaria para la otra clase. En otras palabras, sabemos que la clase Prstamo requiere de la clase Bibliotecario y de la clase Usuario. Entonces, los nombres de las relaciones, como notar, estn en el extremo de la clase que le es necesaria a Prstamo. Esto lo podemos ver en las otras relaciones: RegistroMorosos requiere saber cul copia prestada en DetallePrstamo est generando la morosidad. DetallePrstamo requiere saber cul es su prstamo y la copia del material asociada. Por eso los nombres de las relaciones se consignan en el extremo de las clases requerida por esta. Seguir esa sencilla regla permite a los diseadores saber la navegabilidad de la relacin. Los diseadores van a ver el modelo y van a crear una relacin especfica, desde el punto de vista del diseo, llamada asociacin. La asociacin establece, en general, una clase que es cliente de otra. Esta ltima se dice que es una clase servidor. Si un diseador ve esta situacin en un diagrama:

Prstamo + + + + + + + + + Anno Consecutivo nmero_prstamo fecha_prstamo hora_prstamo estado_prstamo : int : long : java.lang.String : java.util.Date : java.util.Time : char 0..*

Usuario - id_usuario : - nombre : - estado : + ObtieneUsuario () + ObtieneEstado () + ActualizaEstado ()

Prstamo () RegistraPrstamo (Usuario pUsu, Bibliotecario pBib, Copia[] pCop) TieneCopiaPrestada (String pIdUsu, String pIdMat) IncluirCopiaEnPrstamo (Copia pCopia) : String ObtieneNmeroPrstamo () : Date ObtieneFechaPrstamo () : Time ObtieneHoraPrstamo () ActualizaEstadoPrstamo (char pEstado) ObtieneEstadoPrstamo () : char

1..1 Adjudica

De inmediato va a saber que la clase Usuario es una clase cliente para Prstamo, pues se establece el nombre de la relacin (adjudica) en el extremo de la clase Usuario. Las relaciones de asociacin del tipo cliente/servidor se representan mediante una flecha, donde el extremo al que apunta la flecha es la clase servidor. Al seguir con el ejemplo, veremos entonces que el diagrama anterior se transformara as:

126

Prstamo + + + + + + + + + Anno Consecutivo nmero_prstamo fecha_prstamo hora_prstamo estado_prstamo : int : long : java.lang.String : java.util.Date : java.util.Time : char 0..*

Usuario - id_usuario : - nombre : - estado : + ObtieneUsuario () + ObtieneEstado () + ActualizaEstado ()

Prstamo () RegistraPrstamo (Usuario pUsu, Bibliotecario pBib, Copia[] pCop) TieneCopiaPrestada (String pIdUsu, String pIdMat) IncluirCopiaEnPrstamo (Copia pCopia) : String ObtieneNmeroPrstamo () : Date ObtieneFechaPrstamo () : Time ObtieneHoraPrstamo () ActualizaEstadoPrstamo (char pEstado) ObtieneEstadoPrstamo () : char

1..1 Adjudica

Vemos que en el extremo de Prstamo apunta la flecha de la asociacin, por lo que se dice que DetallePrstamo navega en Prstamo. Qu implica esto? Simplemente que en Prstamo debe existir un atributo de tipo Usuario que es el que implementa esta asociacin. El cdigo en JAVA que se genera a partir de esta modificacin para la clase Prstamo, es el siguiente: public class Prstamo { private static int Anno; private static long Consecutivo; private java.lang.String numero_prstamo; private java.util.Date fecha_prstamo; private java.util.Time hora_prstamo; private char estado_prstamo; public Usuario Adjudica; Destacamos en letra negrita la inclusin del atributo de tipo Usuario, llamado Adjudica, tal como se consign en el nombre de la relacin. Posiblemente, para efectos del diseo, el ingeniero quiera cambiar ese nombre, no tanto para que sea significativo desde el punto de vista conceptual, sino para que tenga mejor legibilidad en la codificacin. Personalmente estara tentado a llamarlo simplemente usuario, lo cual debera modificarse, tambin, en el diagrama. Lo anterior por cuanto el proceso de diseo se hace mediante herramientas como Power Designer, que tienen la capacidad de generar el cdigo de acuerdo con lo que se especifica en el diagrama. Una vista de esta caracterstica de Power Designer, igual que otras que generan cdigo a partir de la especificacin del diseo, puede verse en la siguiente figura:

127

Figura 26. Vista de una ventana de Power Designer para la clase Prstamo.

La ventana anterior es la que maneja las propiedades de la clase Prstamo. Entre tantas cosas que pueden administrarse, estn los atributos, las operaciones, las asociaciones, tal como usted puede ver en las pestaas. La pestaa que estamos viendo en este momento, es la que corresponde a Preview, la cual da una vista previa del cdigo. Hacemos el parntesis correspondiente en este momento de nuestro aprendizaje y reflexionaremos acerca del diseo de clases. Si bien este no es un libro que sea un instructivo de un paquete de software particular, s es de destacar que los avances en la tecnologa de los lenguajes orientados a objetos y del UML, han permitido crear herramientas que apoyan, de forma muy sustantiva, el proceso de anlisis y diseo orientados a objetos. Dado este avance, traducir lo que dibujo en un lenguaje de programacin es casi directo, gracias a la estandarizacin a la que se ha llegado en estas metodologas. Por lo tanto, en gran medida el proceso de trabajo hormiga se facilita mucho, dejando mayores espacios a la creatividad y el talento del ingeniero. Podemos modificar, por lo tanto, el diagrama anterior, estableciendo las relaciones de asociacin que se dan entre las clases, considerando, de acuerdo con la gua que dimos, cules son las clases cliente y cules las clases servidor. Igualmente, se cambiarn los nombres de las relaciones con vista a cmo quieren que se llamen los atributos en las clases cliente.

128

Bibliotecario - id_usuario - nombre + ObtieneBibliotecario () 1..* bibliotecario 1..1 bibliotecario : :

0..* Prstamo

0..*

DetallePrstamo

Usuario - id_usuario - nombre - estado 0..* 1..1 usuario : : : + ObtieneUsuario () + ObtieneEstado () + ActualizaEstado ()

1..* copiasPrestadas 1..1

+ + + + + + + + + : String : Date : Time : char Prstamo () RegistraPrstamo (Usuario pUsu, Bibliotecario pBib, Copia[] pCop) TieneCopiaPrestada (String pIdUsu, String pIdMat) IncluirCopiaEnPrstamo (Copia pCopia) ObtieneNmeroPrstamo () ObtieneFechaPrstamo () ObtieneHoraPrstamo () ActualizaEstadoPrstamo (char pEstado) ObtieneEstadoPrstamo ()

fecha_prstamo hora_prstamo unidad_tiempo fecha_devolucin hora_devolucin

: : : : :

Anno Consecutivo nmero_prstamo fecha_prstamo hora_prstamo estado_prstamo

: int : long : java.lang.String : java.util.Date : java.util.Time : char

0..*

1..1 prstamoMoroso

1..1 copiaMaterial 1..1

Copia -

Registro Morosos fecha_registro importe_moroso estado fecha_pago : : : : + RegistraMorosidad () + UsuarioMoroso ()

- id_copia - estado_copia

: :

+ ObtieneCopia () + ActualizaEstado ()

Figura 27. Diagrama de clases de diseo incorporando las asociaciones.

129

En el diagrama anterior, otra vez nos hemos centrado en el subsistema que maneja los prstamos y las devoluciones del material bibliogrfico. Note cmo hemos transformado las relaciones conceptuales en asociaciones. Estas asociaciones, con su navegabilidad, vienen a concretizar la colaboracin que debe existir entre las clases, exportndose de cada clase tipo servidor, un objeto de su tipo a la clase cliente. De esta forma, la clase cliente puede acceder a los servicios de la clase servidor, usando las operaciones provistas por esta. Veamos, por ejemplo, el cdigo en JAVA resultante para la clase Prstamo, correspondiente a la parte de los atributos: public class Prstamo { private static int Anno; private static long Consecutivo; private java.lang.String nmero_prstamo; private java.util.Date fecha_prstamo; private java.util.Time hora_prstamo; private char estado_prstamo; private Usuario usuario; private Bibliotecario bibliotecario; private DetallePrstamo[ ] copiasPrestadas En letra negrita, de nuevo, destacamos los atributos resultantes de las relaciones definidas. Las decisiones en cuanto a diseo, incluso las que hemos puesto desde el modelo conceptual, influyen en mucha medida en lo que implica en las etapas de implementacin. En este momento es normal que, realizando el diseo, tengamos un ojo en lo que pueden significar las cosas en la codificacin, revisando constantemente el cdigo que se genera en JAVA. Como parte de las decisiones de diseo, vamos a destacar, en este momento, la que se refiere a la cardinalidad de la relacin. Vea que la relacin de Prstamo hacia DetallePrstamo indica que Prstamo puede incluir n cantidad de copias de material. Por lo tanto, a diferencia de los atributos de Bibliotecario y de Usuario, que estn relacionados con exactamente uno de cada uno de esos objetos, con copiasPrestadas, se establece un arreglo de objetos del tipo DetallePrstamo. Incluir un arreglo es la interpretacin y la materializacin de que un objeto de Prstamo manejar muchas copias de un material, los cuales se incluyen en objetos de tipo DetallePrstamo. En este caso, lo que se gener en el cdigo JAVA es el resultado de una decisin de diseo hecha en el diagrama.

130

Diferencia entre relaciones de asociacin y de composicin

Hasta ahora hemos visto que las relaciones que se han traducido del modelo conceptual, al modelo de diseo, se han visto como asociaciones. Ahora vamos a introducir conceptualmente las relaciones que son de composicin y, una vez vistas, vamos a revisar las relaciones que tenemos en nuestro diagrama. Cuando establecemos una relacin de asociacin entre dos clases, este tipo de relacin indica una colaboracin que debe darse entre dos clases de una misma jerarqua, es decir, ninguna es ms importante que la otra y, si bien se establecen necesidades, no hay ninguna dependencia que pueda notarse. Por ejemplo, una vez creado un objeto de tipo Prstamo, este permanecer vivo e independiente con respecto de las clases con las que colabor, por ejemplo Usuario o Bibliotecario. Lo anterior significa que, si por ejemplo, un Usuario despus de cierto tiempo ya no est ms afiliado a la Biblioteca, el objeto Prstamo que se cre en su momento existir en el Sistema. Ahora bien, existen clases que dependen totalmente de otras en su existencia. Se establecen as jerarquas (que no son de herencia), en las cuales, la clase principal se dice que se compone de las clases dependientes. Las clases dependientes no podran existir sin su clase principal. Estas relaciones se llaman de composicin. Una composicin que podramos pensar muy naturalmente, es la que sera el CuerpoHumano. El cuerpo humano se compone de cabeza, brazos, piernas, y muchas otras partes, y cada una de ellas depende totalmente en su existencia, de la existencia del cuerpo. La composicin se expresa por un rombo oscuro partiendo de la clase superior hacia las subordinadas. En nuestro ejemplo del cuerpo humano, veramos algo as:

CuerpoHumano

1..1

1..1

1..1

1..1 posee Cabeza

1..1 posee Tronco

2..2 posee Brazos

La desaparicin del cuerpo humano implica la desaparicin de sus partes. Cmo se vera la composicin a nivel de cdigo en JAVA en la clase CuerpoHumano? El cdigo que se genera es el siguiente:

131

import java.util.*; public class CuerpoHumano { private Cabeza posee; private Tronco posee; private Brazos posee[2..2]; } Ahora vemos que, al igual que las relaciones de asociacin, la composicin genera atributos en la clase principal. Esto se asemeja a lo que sucede como consecuencia de una relacin de asociacin. En este punto usted se preguntar si lo que tenemos es algo meramente filosfico y, al final, todo puede resolverse de la misma forma, sea que uno defina relaciones de asociacin o relaciones de composicin. Sin embargo, aunque en apariencia sean parecidas las consecuencias en lo que la definicin de las clases se refiere, el comportamiento va a diferir. Cmo? En este caso, cuando se tiene una asociacin, la clase cliente va a tener objetos de la clase servidor. En ningn caso, la clase cliente va a ser responsable por la creacin de los objetos de las clases externas. Estos objetos deben ser creados y suministrados por algn proceso previamente. Por ejemplo, en el caso de Prstamo, cuando se est en el proceso de crear un registro de un prstamo, los objetos de Usuario y de Bibliotecario ya deben estar creados previamente en el sistema, antes de asociarlos al objeto que es de tipo Prstamo. Sin embargo, cuando se trata de una composicin, el objeto de la clase principal es el encargado de crear los objetos que lo componen. Por lo tanto, sea en el constructor de la clase principal o en alguna otra operacin de su clase, en algn momento se utilizar el constructor de las clases subordinadas para crear los objetos de estas clases que integrarn la clase principal. Lo anterior nos lleva a examinar la relacin entre la clase Prstamo y la clase DetallePrstamo. Note que hasta el momento la hemos definido como una

relacin de asociacin. Sin embargo, podemos establecer, en primer lugar desde el punto de vista conceptual, que objetos del tipo DetallePrstamo estn subordinados a la existencia de un objeto de la clase Prstamo. De tal forma que lo que se establece entre Prstamo y DetallePrstamo es una relacin de composicin, donde jerrquicamente, Prstamo es la clase principal y DetallePrstamo es la clase subordinada. Por otra parte, recordemos un par de detalles del proceso que revisamos cuando nos dispusimos a registrar un prstamo. En su momento habamos indicado que el constructor de la clase Prstamo iba a crear una lista vaca de los objetos de la clase DetallePrstamo. Eso nos da una primera luz sobre la responsabilidad de Prstamo en lo que se refiere al manejo del detalle de las copias del material que va a prestarse. Por otra parte, en algn punto del proceso, debe crear un tem de esa lista: eso significa que debe utilizar el constructor de la clase DetallePrstamo, proveyendo el cdigo del material por 132

prestar y el tiempo de prstamo para ste. De tal forma que en este ejemplo se comprueba y se ilustra lo que mencionamos anteriormente sobre la responsabilidad de las clases principales, acerca de crear los objetos de las clases subordinadas. Podemos resumir, brevemente, las principales diferencias entre las relaciones de asociacin y de composicin: Tipo de relacin Asociacin Composicin No existe una jerarqua en la relacin de Se establece una relacin jerrquica entre una clase principal y clases subordinadas. clases. La existencia de los objetos de las clases Los objetos de las clases involucradas no subordinadas depende de la existencia de dependen de la existencia de unas u otras. un objeto de la clase principal. El objeto de la clase servidor asociado en la clase cliente debe estar previamente La clase principal es responsable por la creacin de los objetos asociados en ella creado. de las clases subordinadas. En cuanto a nuestro diagrama, debemos modificar la relacin entre Prstamo y DetallePrstamo, vista en el diagrama 27, de la siguiente forma:

Prstamo + + + + + + + + + Anno Consecutivo nmero_prestamo fecha_prstamo hora_prstamo estado_prstamo : int : long : java.lang.String : java.util.Date : java.util.Time : char

DetallePrstamo fecha_prstamo hora_prstamo unidad_tiempo fecha_devolucin hora_devolucin : : : : : 1..* copiasPrestadas 1..1

Prstamo () RegistraPrstamo (Usuario pUsu, Bibliotecario pBib, Copia[] pCop) TieneCopiaPrestada (String pIdUsu, String pIdMat) IncluirCopiaEnPrstamo (Copia pCopia) ObtieneNmeroPrstamo () ObtieneFechaPrstamo () ObtieneHoraPrstamo () ActualizaEstadoPrstamo (char pEstado) ObtieneEstadoPrstamo ()

: String : Date : Time : char

Figura 28. Diagrama que muestra la modificacin de la relacin entre la clase Prstamo y DetallePrstamo.

En este caso vemos que se tiene la relacin de composicin entre esas dos clases. Posiblemente, el mtodo IncluirCopiaEnPrstamo deber ser el encargado de crear los objetos de tipo DetallePrstamo que se incluir como tem en la lista. En las relaciones jerrquicas de este tipo, existe una variante de la composicin: la agregacin. En este caso no hay un requerimiento tan fuerte como el hecho que la desaparicin de la clase principal implique la desaparicin de la clase subordinada. La forma de representar la agregacin es mediante un rombo sin rellenar, partiendo de la clase principal hacia la subordinada. Un

133

ejemplo sera el concepto de un automvil: un automvil se compone de chasis, motor, llantas, entre muchos otros. En un diagrama conceptual lo veramos as:
Automovil

1..1 1..1 posee Motor

1..1 1..1 posee Chasis

1..1 1..* posee Llantas

Vea que, a diferencia de un cuerpo humano, que nace y muere como un todo, en un automvil puede agregarse un motor ya existente, o bien, una llanta que ya tiene una existencia propia por aparte. Desde la perspectiva del automvil, sin embargo, siempre es necesario crear los objetos de las clases subordinadas.

Apuntes sobre la jerarqua de herencia

En la elaboracin del modelo conceptual vimos algunos aspectos relativos a la herencia. Para la jerarqua de materiales bibliogrficos, se defini una estructura como la siguiente:
Material # # # # # # # signatura copias_existentes copias_disponibles copias_prestadas ao pas idioma : : : : : : :

+ ObtieneMaterial ()

Libro autor titulo ISBN editor pginas : : : : -

Revista nombre volumen editor ISSN especialidad : : : : : + + + +

Video nombre productora director duracin : : : :

Figura 29. Diagrama que muestra la jerarqua de herencia del concepto de Material

Bibliogrfico.

134

Cuando definimos los atributos, vimos algunos que eran comunes a todas las clases derivadas y otros especficos para ellas. Los atributos comunes son los que estn en la superclase. Ahora bien, con las operaciones debe hacerse un ejercicio semejante. Tenemos que prever que tendremos operaciones que son comunes a todas las clases y otras que podran ser especficas, o que si bien se definen de forma general, deben ser redefinidas en las clases derivadas, o bien otras que se definen de forma general pero que, en los niveles superiores de la jerarqua, no pueden drsele ninguna implementacin y, por lo tanto, se ven como abstractas. Operaciones que pueden ser comunes y que nos presentan ningn problema potencial, pueden ser las del tipo Actualizar/Obtener en cada uno de los atributos de la superclase. Por ejemplo, una operacin llamada ActualizarCopiasExistentes u ObtenerCopiasExistentes puede ser comn a todas las clases derivadas y, ciertamente, todas van a usarlas. Ahora bien, en la superclase (es decir, la clase Material) puede definirse un mtodo, el cual, dada una signatura de un material especfico, indique la longitud de la obra. Tal operacin puede llamarse LongitudObra. En este caso es una operacin comn para todas las clases derivadas: de acuerdo con los atributos, las clases derivadas que aplican para dar esa informacin son Libro (nmero de pginas) o bien, Vdeo (nmero de minutos). Quien no puede dar esa informacin es la revista, pues no tiene sentido en cunto a pginas, dado que stas se componen de artculos y otras cosas. Para ello, en la superclase puede definirse el mtodo, retornando un valor de 0. Esa implementacin de la superclase aplica muy bien para el caso de Revista. Sin embargo, las clases derivadas Libro y Vdeo tienen que redefinir esa operacin, retornando los datos respectivos de pginas y duracin. En este caso, se dice que estas clases sobrescriben la operacin de la superclase (en ingls se dice override, que es la palabra clave en JAVA para implementar este mecanismo). Por ltimo, si vemos el mtodo que est en el diagrama de la Figura 29, ObtieneMaterial, la superclase no tiene conocimiento en ese momento de qu tipo de objeto retornar. Sin embargo, esta es una operacin clave para todo el sistema. Al no tener tal conocimiento y, al saber que debe estar en todas las clases, tal operacin se define como abstracta. Tal como usted sabe de sus conocimientos en programacin orientada a objetos, cuando se define una operacin abstracta en una clase, la clase por s misma se vuelve abstracta. Y tambin se sabe que las clases derivadas estn obligadas a darle una implementacin a las operaciones abstractas (a menos que tambin mantengan tal operacin abstracta con las implicaciones del caso, esto es, que ellas mismas sern clases abstractas). Por otra parte, tambin se sabe que no pueden crearse objetos pertenecientes a clases abstractas. De qu me sirve entonces, a nivel de diseo, tener clases abstractas? Las clases abstractas permiten definir comportamientos esperados para objetos de una determinada clase. No se sabe a priori cmo estos podrn implementarse, pero son necesarios para cualquier clase que cumpla ser de la 135

superclase. Por ejemplo, para el Sistema Bibliotecario de Prstamos es necesario saber qu tipo de material va a prestarse. No se sabe a priori cul va a ser, pero debe existir una operacin en cualquier clase que cumpla ser material bibliogrfico, que indique a las otras clases que lo requieran, qu tipo de material es. Tal operacin podra llamarse ObtieneMaterial. De igual forma, se dice que una clase es abstracta cuando, necesariamente, la superclase no tiene conceptualmente sentido por s misma y debe tomar forma en alguna de sus clases derivadas. Vemos que esto aplica muy bien en el caso del material bibliogrfico: este solo tiene sentido si en algn momento lo identificamos como libro, o revista, o vdeo. Aun cuando sean clases abstractas, s pueden establecerse relaciones de asociacin con otras clases. Cuando se asocia un objeto de la clase Material, por ejemplo dentro de la clase Copia, deber estar previamente definido como un objeto de la clase derivada a la que pertenece (Libro, Revista o Vdeo). Alguien debi usar el constructor especfico de alguna de estas clases. Sin embargo, al tener la asociacin definida en la superclase, esto permite obtener una posibilidad muy alta de extender las capacidades del sistema sin tener que afectar a todo el resto. Por ejemplo, si se agrega un material bibliogrfico llamado Tesis derivado de Material, al resto del sistema le resultar transparente: siempre lidiarn con objetos que son materiales bibliogrficos. Un resumen del diagrama de lo que hemos expuesto anteriormente, se ve a continuacin.
Material {abstract} # # # # # # # signatura copias_existentes copias_disponibles copias_prestadas ao pas idioma : : : : : : : 1..1 Concretiza Copia : - id_copia - estado_copia : 0..* + ObtieneCopia () + ActualizaEstado ()

+ ObtieneMaterial () : Material : int + LongitudObra ()

Libro autor ttulo ISBN editor pginas : : : : : -

Revista nombre volumen editor ISSN especialidad : : : : : + + + +

Video nombre productora director duracin : : : : -

Tesis estudiante gradoAcadmico garrera profesorGua pginas : : : : :

+ LongitudObra () : int

+ LongitudObra () : int

Figura 30. Diagrama que muestra la clase abstracta Material y las clases derivadas especficas de cada material bibliogrfico.

136

Veamos el cdigo en JAVA de la clase Material import java.util.*; public abstract class Material { protected signatura; protected copias_existentes; protected copias_disponibles; protected copias_prestadas; protected ao; protected pas; protected idioma; public abstract Material ObtieneMaterial(); public int LongitudObra() { return 0; }
Figura 31. Representacin en JAVA de la clase abstracta Material.

Vemos en el cdigo de la clase (y en el diagrama de la Figura 30 tambin se identifica) que dicha clase es abstracta; lo que provoca que sea abstracta, especficamente, es el hecho de que el mtodo ObtieneMaterial sea tambin abstracto. Veamos cmo se refleja en JAVA alguna de las clases derivadas, por ejemplo, la clase Libro: import java.util.*; public class Libro extends Material { private autor; private ttulo; private ISBN; private editor; private pginas; override public int LongitudObra() { return pginas; }

mtodo LongitudObra.

La palabra clave extends define la clase de la cual deriva Libro, en este caso Material. Adems, mediante la palabra override se est sobrescribiendo el

137

LOS GESTORES: QUIN DIRIGE LA ORQUESTA? Hemos recorrido un largo camino para poder determinar un modelo de clases que, en primera instancia, nace como un proceso de dar forma a los conceptos inmersos en el dominio del problema. Iniciando con los casos de uso, se prosigue con las clases conceptuales. Se definen las colaboraciones entre ellas, los atributos y operaciones ms relevantes para cumplir con los objetivos de los casos de uso, lo que nos lleva a obtener un modelo conceptual. Este modelo conceptual se transforma en un modelo de diseo, donde las clases conceptuales pasan a ser clases de diseo, obteniendo el modelo de clases del negocio. Cada clase se especifica mucho ms finamente en cuanto sus atributos, operaciones y, por otra parte, se establecen a partir de las relaciones conceptuales creadas, las asociaciones y composiciones (o si es del caso, agregaciones). Llegados a este punto podra decirse que tenemos como una bodega llena de herramientas que podemos usar en un sistema. Pero, cmo usarlas? Cmo saber cmo llegar, por ejemplo, a crear un objeto de la clase Prstamo y posteriormente utilizarlo para registrar uno? Cmo s cundo disparar una accin relativa a una devolucin? Qu debo tener en mi sistema para poder utilizar todo lo que hemos creado en las clases del negocio? Para poder realizar todo ese trabajo, debemos apelar a otras clases de diseo que nos van a ayudar. Estas clases las llamaremos gestores. Tales clases no estn ligadas a un concepto propiamente dicho, como es el caso de Prstamo o Copia, sino que estn creadas para administrar lo relativo a las acciones del sistema. Pressman (2006) las denomina como clases de proceso y las concibe como clases que se requieren para manejar por completo las clases del dominio del negocio. Larman (2005) las denomina controladores y los ubica para manejar los eventos del sistema. Ambas visiones coinciden, como vamos a ver, en el propsito que perseguimos descubrir en esta seccin. Para ello nos sirve ubicarnos en el contexto de la arquitectura en capas. Vamos a realizar una breve conceptualizacin de esta arquitectura y cmo, a la postre, pueden ubicarse en ella nuestras clases del negocio y las que tenemos que crear a propsito de la gestin de stas.

Arquitectura en n-capas
Una arquitectura de este tipo busca dividir la accin de los elementos creados para un sistema en una serie de capas, los cuales parten de una visin de alto nivel, en este caso, la interfaz del usuario, descendiendo hacia otras capas de ms bajo nivel, entre las cuales hallamos una referente al modelo del negocio y que culmina, finalmente, con la capa de base de datos. Tal modelo se inici con la arquitectura denominada Arquitectura de 3 capas: en primera instancia tenemos las clases de la capa que manejan la interfaz hombre/mquina; luego,

138

las clases de la capa del negocio y las clases que ayudan a manejar la interaccin con la base de datos:

Capa de interfaz Capa del negocio Capa de interaccin con BD

Base de datos

Figura 32. Arquitectura en 3 capas.

En la Figura 32 observamos cmo se crean 3 capas especializadas. La primera maneja las peticiones que surgen de la interaccin de la interfaz Hombre/Mquina. A partir de esta interaccin, por ejemplo, la peticin de Registrar un Prstamo, estas clases llaman convenientemente a mtodos de las clases del negocio que se requieren (digamos, los pertenecientes a la clase Prstamo). Finalmente, el registro de un prstamo tendr que interactuar con la base de datos donde se almacenan los datos y donde se registran las transacciones del sistema. Esto se hace en una capa donde hay objetos de clases especializadas en la interaccin con la base de datos y que son llamados desde las clases de negocio. Esta arquitectura fue muy popular en la medida que busc administrar mejor la distribucin de la computacin cliente/servidor: se buscaba tener un cliente ms delgado en la interfaz, utilizar un servidor de aplicaciones donde resida la lgica del manejo de la capa del negocio y el manejo de sus objetos y, finalmente, una capa que maneje todo los aspectos relativos a la base de datos. Sin embargo en esta arquitectura an persiste una responsabilidad muy alta en la codificacin de la capa de interfaz para el manejo de los eventos del sistema. 139

Esto hace que la dependencia del sistema con un objeto interfaz (por ejemplo, una ventana o una pgina HTML) sea muy alta, lo cual es indeseable de cara a la reutilizacin. Para evitar esto, entre la capa de interfaz y la capa de negocio se cre una capa de gestin de los eventos del sistema, donde hay objetos que, ante una peticin especfica de un usuario del sistema, los objetos en dicha capa saben cmo administrar esa peticin independientemente del objeto de interfaz desde el cual se haga la solicitud. Estos ltimos pueden ser objetos ventana, o bien pginas HTML, o un telfono celular. Al independizar totalmente la interfaz de cualquier gestin de objetos de ms bajo nivel en la arquitectura, se fomenta enormemente la reutilizacin. En esta visin, tendramos algo una estructuracin como lo que sigue.

Capa de interfaz

Capa de gestin de eventos

Capa del negocio

Capa de objetos de sistema Clases de interaccin con BD

Base de datos

Figura 33. Arquitectura en n-capas.

140

En la figura anterior apreciamos cmo se crea una capa de la gestin de eventos entre la capa de interfaz y la capa del negocio. Al incluir esa capa, fomentamos una reutilizacin muy grande de los elementos de software del sistema. Propiamente, en la capa de interfaz se haran simplemente peticiones al sistema (vistas tambin como eventos) y dichas peticiones seran resueltas y coordinadas convenientemente por un gestor. De igual forma vemos cmo se incluye una capa de objetos del sistema. Esta capa manejara acciones con elementos muy especializados, por ejemplo, hardware, comunicacin remota con otros servidores, etc. Un ejemplo, en nuestro caso de la Biblioteca, podra ser la interaccin con el lector de cdigo de barras. Para ello, los fabricantes de tales equipos o sistemas deben proporcionar las especificaciones de cmo acceder al manejo de estos mediante lo que se denominan las Interfaces de Programacin de Aplicaciones (ms conocidas como API por sus siglas en ingls). La Figura 33 nos presenta una arquitectura de n-capas bsica. De igual forma que se ha buscado independizar la capa de interfaz Hombre/Mquina aadiendo una capa de gestin, cada capa por s misma puede crear otras capas por debajo de ellas, para lograr algn tipo de independencia requerida, transformndose plenamente en una arquitectura de mltiples niveles. Tales decisiones pueden tener que ver con independizar el funcionamiento del sistema hacia cualquier tipo de hardware, o bien, de cualquier tipo de ubicacin fsica de uno o mltiples servidores. La complejidad puede aumentar bastante de acuerdo con los objetivos donde siempre se desprende aquella mxima: tanto es ms fcil para el cliente, tanto es ms complejo para el proveedor. De lo que hemos estudiado en cursos anteriores referente a la Ingeniera del Diseo, podemos visualizar en la Figura 33, finalmente, lo que Pressman (2006) describe como clases de diseo que este autor clasifica: Clases de interfaz con el usuario Clases del dominio de negocios Clases de proceso (gestin) Clases de persistencia (bases de datos) Clases de sistema

Definir clases de gestin

Existen algunos criterios de cmo definir estas clases de gestin. Los que estn sugeridos por Larman (2003) pueden estar orientados en dos enfoques, a saber: Los gestores de fachada. En este caso, se crea una clase que contenga todos los eventos del sistema. Por ejemplo, tendramos una clase que contenga los

141

mtodos relativos a cualquier posible evento que podramos imaginar que pueda tener nuestro sistema de prstamo bibliotecario: aadir materiales para prstamo, registrarlo, registrar una devolucin, crear una morosidad, crear un material bibliogrfico y una nueva copia para ste, entre muchos otros. Tales gestores son convenientes cuando hay un nmero limitado y pequeo de eventos en el sistema. Los gestores de casos de uso. Se toma el escenario de un caso de uso y se crea una clase con el sufijo Manejador. Se incluyen los mtodos requeridos en el escenario provenientes de las clases involucradas en el escenario del caso de uso. Por ejemplo, podramos tener una clase para el caso de uso RegistrarDevolucin, la cual se llamara RegistrarDevolucinManejador. Esta clase la podramos ver como:
RegistrarPrstamoManejador + + + + + + Prstamo () ActualizarBibliotecario () ActualizarUsuario () TieneCopiaPrestada () IncluirCopiaEnPrstamo () RegistraPrstamo ()

En ese caso vemos la serie de mtodos necesarios como eventos del sistema que se requieren para poder manejar el caso de uso de Registrar un Prstamo de acuerdo al escenario del caso de uso. Crear gestores bajo la perspectiva de casos de uso son los mayormente recomendados. La discusin sobre los gestores la detendremos en este punto. Para completar una visin ms amplia de su utilizacin, en el siguiente captulo veremos cmo estos gestores resultan importantes en los diagramas de secuencia, los cuales vienen a redondear la visin de los modelos que hemos construido.

142

EJERCICIOS DE AUTOEVALUACIN 1. Explique el porqu, resultado de un buen anlisis, la transicin de las fases de anlisis al diseo puede resultar suave producto del paradigma de Orientacin a Objetos. 2. Retome el modelo conceptual creado para el problema de Reservacin de espectculos en lnea y elabore lo siguiente. Documente las clases creadas con tarjetas CRC. A partir de ello determine y justifique si las clases definidas y documentadas son altamente cohesivas y bajamente acopladas. Plantee para las clases del modelo: Indique los constructores que requieren cada una de ellas. Los atributos de clase y los atributos de objeto, segn corresponda, en cada una de las clases. Justifique las decisiones al crear un atributo de clase. Indique los constructores de cada una de las clases. Indique los mtodos de actualizar/obtener para los atributos de las clases. Justifique en cada caso la decisin de diseo tomada. Revise el modelo conceptual creado para el Sistema de Reserva de Espectculos en lnea de tal forma que: Haga evidentes las relaciones identificadas se transformen en relaciones de asociacin o de composicin. Justifique el porqu en cada caso. Asegrese de que pueda elaborar una jerarqua de herencia. Para tal caso, determine la existencia de una clase abstracta a partir de la cual las otras puedan derivarse.

3. De acuerdo con el planteamiento del problema del Sistema de Reservacin de Espectculos en Lnea, existen varios dispositivos que pueden usarse en la solucin, como es el caso de un kiosco. Suponiendo que este equipo es un hardware especializado, se le solicite que plantee de forma justificada, una arquitectura en n-capas para la solucin requerida. Adems, considere que el proceso de reservacin requiere que la persona suministre la informacin de una tarjeta de crdito o dbito para lo cual, tambin, se requiere que el sistema tenga alguna interfaz con el sistema bancario. 4. A partir del ejercicio anterior, explique qu se entiende como la capa de clases del negocio. 5. Explique para qu son las clases de diseo de gestin. Cmo incrementan, este tipo de clases, la reutilizacin de las soluciones creadas?

143

6. Retome la descripcin detallada del principal caso de uso identificado para el Sistema de Reserva de Espectculos en Lnea, para determinar un gestor para tal caso de uso. Identifique dentro de la clase que usted elabore, los mtodos u operaciones necesarias para manejar los eventos del sistema que se definan. 7. Explique, de acuerdo a lo estudiado, por qu los casos de uso son importantes en la definicin de clases de diseo?

144

CAPTULO

EL MODELO DE INTERACCIN

SUMARIO CONSIDERACIONES PRELIMINARES DIAGRAMAS DE SECUENCIA: UN PRIMER ACERCAMIENTO Y SU UTILIDAD PARA DESCUBRIR LAS CLASES DE LA CAPA DE INTERFAZ Diagramas de secuencia de sistema Diagramas de secuencia: identificando la capa de interfaz Interaccin entre capas: aadiendo la capa de gestin Cajas de activacin y su efecto en las operaciones Visin del trabajo de los gestores en un diagrama de secuencia DIAGRAMAS DE ACTIVIDAD: APOYANDO LA ESPECIFICACIN DEL DISEO Elementos de un diagrama de actividad Especificacin de casos de uso y diagramas de actividad Especificacin de operaciones DIAGRAMAS DE ESTADOS Elementos de un diagrama de estados Elaboracin de un diagrama de estados

145

OBJETIVOS Una vez que usted estudie este captulo, podr llevar a cabo cada una de las siguientes actividades de aprendizaje, que le servirn para comprobar cunto ha aprendido de este tema Reconocer la utilidad de los diagramas de secuencia en las fases de anlisis y diseo. Construir diagramas de secuencia que representen la interaccin entre los actores del sistema y el sistema. Establecer la relacin entre diagramas de secuencia y casos de uso para la definicin de clases de diseo de las capas de interfaz y de gestin. Refinar la estructura de las operaciones de las clases mediante la informacin suministrada por los diagramas de secuencia. Definir, mediante los diagramas de secuencia, la interaccin entre objetos requeridos para la solucin de un objetivo del sistema. Documentar grficamente los casos de uso utilizando diagramas de secuencia y diagramas de actividad. Expresar los algoritmos de una operacin mediante los diagramas de actividad. Definir los estados del sistema y las transiciones vlidas en dichos estados mediante los diagramas de estado.

146

CONSIDERACIONES PRELIMINARES Conforme hemos ido avanzando en el desarrollo de nuestro modelo, se han ido incorporando elementos importantes bajo el paradigma de la orientacin a objetos. Derivado de los conceptos identificados en los casos de uso, hemos encontrado los insumos para desarrollar el modelo conceptual reconociendo, precisamente, conceptos claves en el entorno del problema al que buscamos dar una solucin. Tales conceptos iniciales evolucionan en su modelado bajo un anlisis ms detallado: se comienzan a identificar posibles clases conceptuales, las colaboraciones entre ellas vistas como relaciones, la cardinalidad de cada relacin, las especificacin de clases, la identificacin de jerarquas de herencia, la definicin de atributos y operaciones. Se incorporan nuevos casos de uso en el anlisis de algunas situaciones del modelo y lo enriquecemos. Marcamos un hito en nuestro avance: logramos obtener un modelo de clases conceptuales consistente, que pueda apoyar los casos de uso. De esta forma podemos evolucionar y comenzar a construir un modelo de clases con definiciones, bajo la ptica del diseo. Se comienzan a incorporar algunas decisiones con vistas a la implementacin: tipos de datos de los atributos, parmetros y tipos de retorno de las operaciones, definicin de constructores de clases, entre muchas otras decisiones, las cuales, completan una visin hacia la implementacin de las clases requeridas para la solucin. De igual forma, a la luz de lo que plantea una arquitectura en capas, podemos incorporar otros tipos de clases que ayudarn a darle mayor robustez a nuestra solucin. Tal es el caso de los gestores, los cuales buscan independizar la solucin de la capa del negocio de aspectos especficos de la capa de interfaz. La capa del negocio se obtiene a partir de nuestro modelo de clases conceptual, el cual deriva en clases de diseo del negocio, o del dominio del negocio. La capa de gestin de eventos del sistema da respuesta a los usuarios del sistema sobre las solicitudes que dichos usuarios hagan desde la capa de interfaz, administrando la creacin de objetos, la interaccin entre stos y la ejecucin conveniente de operaciones de las clases. Igualmente, se aprecia una poderosa caracterstica del A/DOO: los conceptos hallados en el mundo real se mantienen. Algo que se modela como Prstamo seguir siendo el concepto de prstamo a lo largo del desarrollo. De igual forma, un caso de uso Registrar Prstamo, semnticamente definido en el contexto organizacional de la biblioteca que estamos usando de ejemplo, mantendr ese significado en otros elementos de software que identificamos, como por el ejemplo, la clase de diseo gestor RegistroPrstamo_Manejador. De esta forma encontramos que evolucionar del anlisis al diseo se hace de una forma muy suave. No debemos enfrentar tormentosos procesos, como se

147

daban en el anlisis y diseo estructurado, para poder deducir del anlisis al diseo, los modelos requeridos para la implementacin del sistema6. Lo que hemos recorrido hasta este punto nos da una idea clara de los elementos requeridos para construir la solucin. Es como ver, de alguna forma, el plano constructivo de una casa o edificio: vemos la distribucin espacial de las cosas de una forma esttica. As tambin observamos nuestros modelos de clases: de una forma en que los elementos, por decirlo de alguna forma, estn quietos. Sin embargo, puede interesarnos tambin encontrar alguna forma en que tales elementos puedan mostrar cmo interactan entre ellos en un momento dado, a raz de los eventos que puede desatar un usuario del sistema. Analizar tal perspectiva nos ofrecer mucha informacin acerca de otras decisiones que debemos considerar para la especificacin de nuestro modelo y del software que necesitamos construir. A continuacin estaremos estudiando el tema de los modelos de interaccin en el denominado diagrama de secuencia en UML. DIAGRAMAS DE SECUENCIA: UN PRIMER ACERCAMIENTO Y SU UTILIDAD PARA DESCUBRIR LAS CLASES DE LA CAPA DE INTERFAZ Los diagramas de secuencia son un tipo de diagrama en UML, los cuales permiten modelar la interaccin surgida a partir de un evento en el sistema que desencadena un actor. Esas interacciones pueden verse en distintos niveles de refinamiento.

Diagramas de secuencia de sistema

En primer lugar, puede servir para ilustrar la interaccin entre el actor y el sistema, este ltimo visto como una caja negra: no se conoce mayor detalle de lo que ocurre a lo interno del sistema. Simplemente, se visualizan las entradas y salidas que se dan en el contexto de lo que requiere hacerse por parte del actor. Qu podra darnos un insumo para construir un diagrama de secuencia? Nuevamente recurrimos a los casos de uso. El escenario de un caso de uso muestra los pasos que deben darse en esa interaccin entre el actor y el sistema. El diagrama de secuencia lo componen varios elementos: en la siguiente figura, observaremos un ejemplo bsico de un diagrama de este tipo.

Usted podr darse una idea de esto ltimo consultando el Captulo 10 de la versin en castellano del libro de Roger Presuman, Ingeniera del Software: un enfoque prctico, sexta edicin. Las pginas a las cuales debe referirse van de la 297 a la 310.

148

Sistema Bibliotecario IngresaIdentificacinUsuario

IndicaUsuarioVlido

IngresaMaterialPrstamo RegistraPrstamo

Figura 34. Representacin de la interaccin entre el actor Bibliotecario y el Sistema de Prstamo Bibliotecario, mediante un diagrama de secuencia.

Note los elementos del diagrama que aparecen en la Figura 34. En primera lugar, a la izquierda, encontramos un actor, tal como lo hemos visto en el diagrama de casos de uso. Especficamente vemos, en este caso, a un Bibliotecario que es actor de nuestro sistema de prstamo bibliotecario. Seguidamente vemos una caja, con el nombre Sistema. Al estar subrayado en este tipo de diagrama, significa que se est tratando con una instancia, o bien, con un objeto Sistema. Deber existir un concepto o una clase llamada Sistema en el contexto de la solucin que est desarrollndose. Debajo del actor Bibliotecario y del objeto Sistema caen unas lneas. Tales lneas podrn sustentar las interacciones que se tendr entre el actor y el sistema. Cmo es que estos interactan? Ellos lo hacen mediante mensajes, que se representan por medio de una flecha que parte del actor y tiene su llegada en el sistema. Ese mensaje tendr un nombre y los que se dirigen de izquierda a derecha (las entradas), se grafican con un trazo continuo. Los que van en el sentido inverso (las respuestas del sistema), tendrn un trazo discontinuo. Los mensajes se hacen en secuencia, de ah el nombre de este tipo de diagrama: los mensajes se ejecutan en orden, de arriba hacia abajo.

149

Note algo muy importante. La secuencia de pasos que se diagraman se asemeja, en mucho, al escenario de un caso de uso. Si nos fijamos en el escenario del caso de uso de RegistraPrstamo, podemos encontrar tal semejanza. El caso de uso comienza cuando el Bibliotecario ingresa al sistema la identificacin del Usuario. El Sistema le indica si el Usuario es vlido. El Sistema le indica, adems, si el Usuario tiene algn registro de morosidad. Una vez comprobados los pasos anteriores, el Bibliotecario lee del Sistema Bibliotecario la informacin del material que va a prestarse, a travs de un lector de cdigo de barras. En ningn caso puede prestarse otra copia del mismo material al mismo usuario, lo cual se comprueba por parte del Sistema cuando se hace esta lectura. El Sistema indica si el material puede ser prestado solo para uso interno de la biblioteca y el tiempo que puede ser prestado en cualquier caso. El Bibliotecario registra el prstamo del material y el caso de uso termina. Podemos, a partir de ello, comenzar a tener una visin interesante de, por una parte, documentar los casos de uso desde el punto de vista de la interaccin del sistema y, por otra parte, comenzar a identificar una serie de mensajes que pueden ir tomndose en cuenta para crear algunas clases de diseo que ms adelante veremos. A partir del escenario del caso de uso visto, podemos replantear el diagrama tomando como base la definicin del escenario de dicho caso y, adems, ver otros aspectos del diagrama.

150

Sistema Bibliotecario IngresaIdentificacinUsuario

IndicaUsuarioVlido

IngresaMaterialPrstamo

VerificaMaterialNoPrestado IndicaMaterialYaPrestado Los pasos dentro del rectngulo se repiten

IndicaCondicionesPrstamo

RegistraPrstamo

Figura 35. Representacin del caso de uso Registrar Prstamo, mediante un diagrama de secuencia.

En primer lugar debe considerarse que se trata de poner, dentro del diagrama, los pasos y acciones estipuladas dentro del escenario del caso de uso. Aprecie que en el diagrama de la Figura 35 aparecen dos situaciones nuevas con respecto al anterior. En primer lugar, podemos ver que Sistema enva un mensaje a s mismo. All se est indicando que, por s mismo, el sistema debe verificar que un material solicitado por un usuario de la biblioteca no est previamente prestado. Por otra parte, observe algo importante: cuando en un diagrama de secuencia usted halle un rectngulo encerrando varios mensajes, como sucede entre IngresaMaterialPrstamo e IndicaCondicionesPrstamo, entonces nos encontraremos en una serie de pasos que se repiten, es decir, una iteracin o ciclo. Estos diagramas son relativamente sencillos. Podemos estructurarlos a partir de los casos de uso y nos pueden servir para identificar eventos del sistema que pueden darse en las clases de la capa de interfaz que analizamos en la arquitectura de n-capas. Por ejemplo, si tuviramos una interfaz Web como la que presentamos a continuacin, podramos tener una situacin como la que sigue.

151

Al ingresar el Bibliotecario el nmero de identificacin del Usuario de la Biblioteca, a partir del evento generado en el botn Enviar, estara evocndose a una operacin que podra llamarse de igual forma, como se propuso en el diagrama de secuencia anterior: IngresaIdentificacinUsuario.

Diagramas de secuencia: identificando la capa de interfaz

Qu eventos del sistema encontramos asociados con la interfaz de usuario a partir del diagrama de secuencia anterior? Obsrvelo. Podemos hallar los siguientes. IngresaIdentificacinUsuario: recibira el parmetro con la identificacin de usuario. IngresaMaterialPrstamo: recibira como parmetros el nmero de identificacin de la copia del material y el tipo de material que se est prestando. RegistraPrstamo: recibira los parmetros correspondientes a la identificacin del usuario y la lista de copias por prestar. As lograramos tener una clase de diseo, correspondiente a la capa de interfaz, que podra llamarse RegistrarPrstamoInterfaz vista de la siguiente forma:
RegistrarPrstamoInterfaz + IngresaIdentificacinUsuario (java.lang.String pIdUsu) : String : String + IngresaMaterialPrstamo (java.lang.String pIdCopia, int pTipo) + RegistraPrstamo (java.lang.String pIdUsu, java.lang.String pIdBiblio, java.lang.String[] pCopias) : int

Al establecer un diagrama de secuencia utilizando esta clase, podemos formular nuevamente este de la siguiente forma.

152

:RegistrarPrstamoInterfaz

Bibliotecario IngresaIdentificacinUsuario()

IngresaMaterialPrstamo()

RegistraPrstamo()

Figura 36.

Representacin, en un diagrama de secuencia, del proceso de Registrar Prstamo, usando las operaciones de la clase de diseo de la capa de interfaz.

En este momento estamos ante otra situacin respecto de la que vimos en el diagrama anterior. Precisamente, el anterior diagrama de secuencia de la Figura 36 est tratando con una visin de alto nivel de los eventos que se dan en un objeto de interfaz (una pgina, una ventana) y lo que el actor puede apreciar directamente en l. Sin embargo, en este ltimo diagrama, estamos viendo la accin que se da, propiamente, en una clase de software correspondiente a la capa de interfaz que recibe el evento del sistema solicitado por el actor. Los tipos de retorno que incluimos en las operaciones, eventualmente sern los que usar el objeto interfaz, sea una pgina Web o una ventana, para poder responder al usuario. Por ejemplo, el String devuelto por la operacin IngresaIdentificacinUsuario, podra ser una cadena vaca ( ) que indicara que no hay problema con el usuario, o bien, una cadena con un mensaje como Usuario con problema de morosidad. Por lo visto anteriormente, vemos una utilidad importante de los diagramas de secuencia en el proceso que hemos llevado hasta ahora con ellos. De una forma sencilla pudimos comprobar, en el contexto de un caso de uso, qu interaccin podra existir entre un actor y el sistema. Posteriormente hemos visto cmo, a partir de esa interaccin, puede deducirse una clase dentro de la capa de interfaz, la cual puede manejar, o mejor dicho, canalizar los eventos que desencadena el actor. Decimos canalizar porque, a partir de este punto, las operaciones de las clases de interfaz hacen intervenir a las clases de la capa de gestin de eventos, como veremos a continuacin, mostrando que la sencillez de estos diagramas ilustran y hacen descubrir cosas muy valiosas en nuestro trabajo de diseo del software. 153

Interaccin entre capas: aadiendo la capa de gestin

Cuando analizamos la arquitectura de n-capas para introducir ciertas clases de diseo, estuvimos averiguando que este estilo arquitectnico fue concebido para independizar varios aspectos involucrados en una solucin de software: la interfaz hombre/mquina, la accin sobre las bases de datos, las clases de diseo del negocio y los dispositivos de hardware que deben usarse eventualmente. Una de estas capas, la capa de gestin de eventos del sistema, se usa para poder lograr una independencia de la capa de interfaz con respecto a la capa de dominio de negocio. Al entrar en juego la capa de gestin, pueden obtenerse aspectos muy interesantes en perspectiva del comportamiento del sistema, ya que esta capa comienza a manejar la interaccin que puede darse entre los objetos de la clase de negocio en perspectiva de dar la respuesta que desea el actor. Pero antes de entrar en esos detalles, observemos primero, cmo, mediante un diagrama de secuencia, puede apreciarse la interaccin de una capa con otra, particularmente la capa de interfaz y la capa de gestin. Hemos visto que los diagramas que hemos desarrollado tienen algunos objetos involucrados: Sistema, en el primero, RegistrarPrstamoInterfaz, en el segundo. Cuando introdujimos el tema de los gestores, en el captulo anterior, se propuso que estos podan llamarse igual que el caso de uso que manejaran y que al nombre del caso de uso se le aadira el sufijo de Manejador. En el caso de nuestro ejemplo, un gestor que maneje el caso de uso de RegistrarPrstamo, pasara a llamarse RegistrarPrstamoManejador. Al plantear la interaccin entre capas, podemos toparnos con un diagrama como el que se muestra a continuacin.

154

:RegistrarPrstamoInterfaz

:RegistrarPrstamoManejador

Bibliotecario IngresaIdentificacinUsuario() ValidarUsuario()

IngresaMaterialPrstamo() TieneCopiaPrestada()

IncluyeMaterialPrstamo()

RegistraPrstamo() RegistraPrstamo()

Figura 37. Diagrama de la interaccin entre la capa de interfaz y la capa de gestin.

En primer lugar, note que la accin entre capas se da mediante el envo de mensajes entre objetos que pertenecen a las clases de diseo involucradas. En este ejemplo, el Bibliotecario, como actor del Sistema, quiere registrar un prstamo. En primera instancia, el Bibliotecario, a travs de algn componente de la interfaz (un botn de una ventana o pgina Web), genera un evento en el Sistema, el cual busca comprobar la validez de un Usuario ante el sistema de prstamos de la Biblioteca. El evento llamado se hace mediante la operacin IngresaIdentificacinUsuario. Esta, a su vez, llama a una operacin en la capa de gestin de eventos, llamada ValidarUsuario. Lo mismo advertimos en los siguientes eventos que se dan para el registro de un prstamo: IngresaMaterialPrstamo, que llama a las operaciones TieneMaterialPrestado e IncluyeMaterialPrstamo. Por ltimo, RegistraPrstamo llama una operacin homnima en la clase de gestin.

Cajas de activacin y su efecto en las operaciones

Note que los mensajes, en este diagrama de la Figura 37, muestran una caracterstica interesante: en la lnea que desciende de la caja que representa 155

el objeto, notamos un rectngulo. Tal rectngulo se llama caja de activacin. La caja de activacin la utilizamos para poder visualizar cundo empieza y cundo termina la ejecucin de un mtodo y, durante su tiempo de vida, qu operaciones estar llamando para ejecutar. Esto ltimo nos puede dar una idea de una parte de la codificacin de las operaciones dentro de la clase. Por ejemplo, en el caso de IngresaMaterialPrstamo en la clase RegistraPrstamoInterfaz, en su cdigo de programacin necesariamente tendrn que haber llamados a los mtodos de TieneMaterialPrestado e IncluyeMaterialPrestado de la clase RegistraPrstamoManejador. Esto significa que su cdigo, debe tener un aspecto como el que sigue: public String IngresaMaterialPrstamo(String pIdCopia, int pTipo) { gestor.TieneMaterialPrestado(pIdCopia,pTipo); gestor.IncluyeMaterialPrstamo(idCopia,pTipo); return mensaje; } No se est diciendo nada en el cdigo de programacin anterior con respecto a la implementacin final de esta operacin. No obstante, lo que se trata de ilustrar, es el hecho de que este mtodo debe realizar un llamado a esas operaciones del gestor. Con el diagrama de secuencia elaborado, podemos deducir, igualmente, el comportamiento que requerimos en la clase RegistraPrstamoManejador. De esta forma, un diagrama de la clase en cuestin lo podemos ver a continuacin:

RegistrarPrstamoManejador + + + + ValidarUsuario (java.lang.String pIdUsu) TieneCopiaPrestada (java.lang.String pSignatura) IncluyeMaterialPrestamo (java.lang.String pIdCopia) RegistraPrestamo (java.lang.String pIdUsu, java.lang.String pIdBib, Copia[] pCopias) : char : int : int : int

El diagrama de secuencia nos ha servido para precisar nuestro gestor, el cual es una de las clases de diseo ms importante en un modelo de arquitectura en ncapas. Por otra parte, note del cdigo de programacin que vimos anteriormente, que la clase RegistrarPrstamoInterfaz necesita tener un objeto de tipo gestor, con el fin de enviarle los mensajes que se requieren. Por lo tanto, estas clases estn asociadas de la forma que se muestra a continuacin (trate de contestar por qu se trata de una composicin).

156

RegistrarPrstamoInterfaz + + + + RegistrarPrstamoInterfaz (RegistrarPrstamoManejador pGestor) IngresaIdentificacinUsuario (java.lang.String pIdUsu) : String IngresaMaterialPrstamo (java.lang.String pIdCopia, int pTipo) : String RegistraPrstamo (java.lang.String pIdUsu, java.lang.String pIdBiblio, java.lang.String[] pCopias) : int 1..1 1..1 gestor RegistrarPrstamoManejador + + + + ValidarUsuario (java.lang.String pIdUsu) TieneCopiaPrestada (java.lang.String pSignatura) IncluyeMaterialPrstamo (java.lang.String pIdCopia) RegistraPrstamo (java.lang.String pIdUsu, java.lang.String pIdBib, Copia[] pCopias) : char : int : int : int

Figura 38. Representacin de la composicin entre las clases de diseo de la capa de interfaz y de la capa de gestin.

De tal forma, el cdigo en JAVA de la clase RegistrarPrstamoInterfaz se vera as: import java.util.*; public class RegistrarPrstamoInterfaz { private RegistrarPrstamoManejador gestor; public RegistrarPrstamoInterfaz(RegistrarPrstamoManejador pGestor) { } public String IngresaIdentificacinUsuario(java.lang.String pIdUsu) { return null; } public String IngresaMaterialPrstamo(java.lang.String pIdCopia, int pTipo) { this.gestor.TieneMaterialPrestado(idCopia); this.gestor.IncluyeMaterialPrstamo(idCopia); return mensaje; } public int RegistraPrstamo(java.lang.String pIdBiblio, java.lang.String[] pCopias) { return 0; } } pIdUsu, java.lang.String

157

Observe del cdigo de programacin anterior, lo que se resalta en negrita. En primera instancia, que existe un atributo de tipo RegistraPrstamoManejador en la clase, debido a la direccin de la flecha en la composicin. Por otra parte, el constructor de la clase RegistroPrstamoInterfaz deber incluir un parmetro del tipo del gestor y mediante esta operacin, a su vez, se encargar de crear, llamando al constructor de la clase RegistraPrstamoManejador, el objeto de este tipo que necesita en su clase.

Visin del trabajo de los gestores en un diagrama de secuencia

Hasta este punto, con la ayuda de los diagramas de secuencia, hemos definido otras clases de diseo importantes, adicionales a las que trabajamos en el modelo de clases del negocio. Vemos, as la utilidad de este tipo de diagramas para poder descubrir las clases de gestin que necesitamos para manejar aspectos de la solucin de software que requerimos. Veremos, ahora, qu interaccin ocurre entre los objetos involucrados en la accin de RegistrarPrstamo. Para ello debemos adentrarnos, entonces, a un nivel ms de nuestras capas: lo que ocurre en la capa de clases del negocio. En tal caso, podemos acudir y tener presente el ejercicio que utilizamos, cuando analizamos aspectos de la definicin de constructores y operaciones de las clases de diseo del negocio, para poder ver la interaccin que surge. De nuevo, ello tiene que ver con un escenario del caso de uso de RegistrarPrstamo. El bibliotecario elige la opcin de Registrar Prstamo en el men. Se utiliza el Constructor por defecto de la clase y se tiene un nuevo objeto de la clase Prstamo. Se pide la identificacin al usuario, se introduce y se verifica que tiene derecho a realizar solicitudes de prstamo. Puede utilizarse el mtodo de la clase Usuario para ObtenerUsuario en el atributo de usuario que debe tener, por asociacin la clase Prstamo. Se incluye cada material solicitado en el prstamo. Con el lector de cdigo de barras se obtiene la informacin de la copia de cada material. Cuando se cre el objeto de Prstamo, debi crearse una lista vaca de las copias del material por prestar. En este momento, se incluye, en la lista, cada uno de los materiales que se prestan. Por lo tanto, Prstamo debera tener una operacin llamada IncluirCopiaEnPrstamo que actualice la lista de copias de materiales prestados. Se hacen verificaciones por cada material prestado (por ejemplo que no tenga otra copia del mismo material prestada en este momento). Se utiliza el 158

mtodo de la clase Prstamo de TieneCopiaPrestada con los parmetros de la signatura del material y la identificacin del usuario. Se determina el tiempo de prstamo en cada material. Se obtiene el tiempo de prstamo del material mediante los mtodos de la clase CondicionesPrstamo. Se registra el prstamo. Se utiliza el mtodo RegistrarPrstamo. Sus parmetros deben ser el bibliotecario que hace la transaccin, el usuario, la lista de materiales prestados, CADA UNO con el tipo de prstamo y el tiempo que se prest. La fecha y hora de prstamo se obtienen de funciones del sistema, como los pueden ser Today() y Now(), que dan la fecha actual y la hora actual respectivamente. Vamos a analizar esta secuencia detenidamente. El paso 1 indica que el bibliotecario debe elegir la opcin Registrar Prstamo de un men que se ofrece. Este servicio debera brindrselo una clase de la capa de interfaz, que le brindara al bibliotecario la posibilidad de poder ingresar un prstamo en el sistema. Ah se indica que, mediante el constructor de la clase Prstamo, se crea un objeto para ello. Pero, dado nuestro conocimiento en este punto, qu es lo que realmente necesitamos? Un objeto de la clase Prstamo? Para responder estas preguntas recordemos, antes, algunas situaciones. En primer lugar, ya vimos en su momento que no es conveniente que, desde la capa de interfaz, se manejen directamente aspectos relacionados con la capa del negocio. Para ello requerimos la accin de los gestores. Por otra parte, tambin debemos considerar que deben existir algunas validaciones previas a crear objetos de tipo Prstamo. Por ejemplo, cuando el caso de uso expresa en sus excepciones que: de comprobarse que el usuario no est registrado en la biblioteca, el caso de uso termina, estamos incurriendo en creacin de objetos sin estar seguros de que van a ser utilizados. Si bien hoy en da contamos con equipos de hardware poderosos, no podemos menospreciar los costos computacionales incurridos en la creacin de objetos, mxime que muchas veces las soluciones que brindamos (por ejemplo en un sitio de Internet) pueden atender a millones de usuarios, por lo cual la eficiencia es un objetivo que, como profesionales en computacin, siempre debemos perseguir. As que, como buenos diseadores de software, todo lo que signifique ahorro ser bienvenido (no olvide que diseo de software debe ser sinnimo de calidad). Todo ello nos lleva a pensar que lo que debe de crearse no es propiamente un objeto de tipo Prstamo, sino un gestor para RegistraPrstamo. En primera instancia se introducira un objeto de tipo RegistraPrstamoInterfaz y, dentro de ello, se creara el objeto de RegistraPrstamoManejador. Por lo tanto, la accin de que un bibliotecario elija la opcin de registrar prstamo en un men, podra verse de la siguiente forma (recuerde que los constructores de objetos de las clases llevan el mismo nombre de las clases).

159

MenuAplicacin

:RegistrarPrstamoInterfaz

:RegistrarPrstamoManejador

Bibliotecario RegistraPrstamo

RegistrarPrstamoInterfaz() RegistrarPrstamoManejador()

Figura 39. Representacin de la creacin de objetos, a partir de la interaccin entre capas.

Los siguientes pasos pueden analizarse a partir de la interaccin de las clases pertenecientes al dominio del negocio. El paso 2 indica las comprobaciones con respecto a la accin del Usuario de la Biblioteca. Hasta este momento no se ha creado ningn objeto de tipo Usuario, por lo cual es necesario crearlo con su constructor. Puede crearse suministrando el nmero de identificacin del usuario. Dicho parmetro es dado por el bibliotecario a travs de los mtodos de los gestores IngresaIdentificacinUsuario, en la interfaz y ValidarUsuario en el gestor del caso de uso. Una vez creado, se procede a averiguar el estado del usuario con respecto al sistema. Si se comprobara que tiene el estado de moroso, no podra continuarse con el proceso. El paso 3 realiza acciones referentes al prstamo. Sin embargo, hasta este punto, por lo que hemos analizado, no se ha creado el objeto de la clase Prstamo. En este punto puede concebirse con toda propiedad, dado que se ha pasado la validacin de que el usuario de la biblioteca est activo en el sistema y, por lo tanto, es el momento oportuno de contar con el objeto que maneja el prstamo. El paso 4 es complejo en su manejo, puesto que involucra varias acciones con objetos de la clase de negocio y de otras capas. En primer lugar, debe verificarse que el material que va a prestarse no tenga alguna copia, en este momento, prestada para el usuario. Para ello, el gestor debe crear un objeto de tipo Copia con el nmero de identificador suministrado por los mtodos de los gestores (por ejemplo, IncluyeMaterialCopia en el gestor de la interfaz). Ac el gestor del caso de uso puede coordinar esta accin con un objeto de tipo LectorCdigoBarra, la cual es una clase de diseo, dentro de la clasificacin vista, correspondera a una clase de diseo del sistema, es decir,

160

pertenecera a ese tipo de clases que manejan dispositivos especializados (como el cdigo de barras) o bien, aspectos relacionados con el sistema computacional. El objeto de tipo Copia debe, por su parte, suministrar la signatura del material bibliogrfico asociado a ste. Con la signatura y la identificacin del usuario, la clase Prstamo invoca su propia operacin de TieneCopiaPrestada. Ahora bien, esta ltima operacin es realmente de la clase Prstamo como lo hemos visto hasta ahora, o bien, debera pertenecer a otra clase? Para ello debemos preguntarnos quin tiene la informacin de las copias prestadas? Y s, naturalmente, usted al igual que yo, podremos darnos cuenta que la clase DetallePrstamo es quien posee tal conocimiento. Por eso mismo debemos crear en este punto un objeto de esta clase. Note tambin que, al querer plantear la secuencia del sistema a travs del diagrama, nos damos cuenta de aspectos conceptuales y de diseo que deben resolverse de mejor forma. Ac, de nuevo, apelamos al espritu iterativo del Proceso Unificado. Siguiendo con el paso 4, si el usuario no tiene una copia activa asignada en el prstamo, se procede con el paso 5, el cual consiste en averiguar el tiempo y tipo de prstamo que tiene este material. De igual forma podra usarse, para ello, operaciones en la clase Copia, la cual tiene el material asociado. Con estos datos, se procede a incluirlo dentro de la lista de materiales solicitados, lo cual se hace a travs del mtodo IncluirCopiaEnPrestamo. Finalmente, se registra el Prstamo con el mtodo RegistrarPrstamo el cual es llamado por el gestor. Previamente deben asignarse la fecha y hora del sistema en cada uno de los registros de las copias prestadas. El diagrama de secuencia resultante, teniendo los gestores creados tal como vimos en el diagrama anterior producto del anlisis del paso 1, podra ser el siguiente:

161

:RegistrarPrstamoInterfaz :Prstamo

:RegistrarPrstamoManejador

:Usuario

:Copia

:DetallePrstamo

:LectorCodigoBarras

Bibliotecario

IngresaIdentificacinUsuario() ValidarUsuario() Usuario()

ObtieneEstado()

IngresaMaterialPrstamo() Prstamo() ObtieneValor() Copia()

IncluyeMaterialPrstamo()

ObtieneSignatura()

DetallePrstamo()

TieneCopiaPrestada()

IncluirCopiaEnPrstamo()

RegistraPrstamo() RegistraPrstamo()

RegistraPrstamo() ActualizaHoraPrstamo() ActualizaFechaPrstamo()

ObtieneTipoPrstamo()

ActualizaTipoPrstamo()

ObtieneUnidadTiempo()

ActualizaUnidadTiempo()

RegistrarTransaccin()

Figura 40. Representacin completa del proceso de Registrar Prstamo, en mltiples capas 162

Le sugerimos que analice este diagrama, siguiendo el razonamiento de cada uno de los pasos que hicimos previo a este. Vea que se estn identificando algunas nuevas operaciones en ciertas clases de la capa del negocio. Esto ltimo, tambin es una riqueza que nos proporcionan los diagramas de secuencia. Podemos ver en el diagrama, de arriba hacia abajo, tres secciones bien delimitadas. La primera, lo relativo a la comprobacin del usuario. La segunda, la cual al estar bajo un rectngulo, es repetitiva; se encarga de la inclusin de materiales y, por ltimo, la seccin relativa al registro del prstamo. Cada una de ellas parte de un evento que hace el Bibliotecario en su interaccin con el Sistema. Por ejemplo, en cuanto a la comprobacin del usuario, el bibliotecario, mediante la interfaz, llama a la operacin IngresaIdentificacinUsuario. Posteriormente, el gestor de caso de uso (RegistrarPrstamoManejador) invoca dos operaciones en la clase Usuario: Usuario, para crearlo y ObtieneEstado. Vea que esta parte del diagrama es consistente con el anlisis que hicimos anterior a construir el diagrama.

Figura 41. Visin parcial de la figura 40 enfocada en la validacin del Usuario.

Si bien en un diagrama de secuencia no se aprecian estructuras de control, como un if u otro tipo de condiciones, s puede indicarse que de no tener xito la comprobacin del usuario, el resto de la secuencia no se ejecuta. Una segunda seccin del diagrama de la Figura 40 representa las acciones que aaden copias de materiales en prstamo y la tercera el registro final del prstamo. De igual forma, debemos apreciar, observando de izquierda a derecha, que en este diagrama interactan cuatro capas: la de interfaz, la de gestin de eventos, la de negocio y la de sistema. Implcitamente encontraremos una quinta capa: la de interaccin con la base de datos.

163

La

RegistraPrstamoInterfaz. La de gestin de eventos por el objeto de la clase RegistraPrstamoManejador. La de las clases de negocio est representada por las clases Usuario, Prstamo, Copia, DetallePrstamo. La de clases de sistema estara representada por el objeto de la clase LectorCdigoBarras.

de

interfaz

estara

representada

por

el

objeto

de

la

clase

Implcitamente, tambin, al obtener la fecha y hora del sistema para actualizar la hora y fecha del prstamo, existe alguna clase que provea esos servicios (posiblemente facilitada por el API de JAVA), la cual entrara a ser parte de las clases del sistema.

Por ltimo, advierta que Prstamo invoca una operacin llamada RegistrarTransaccin. Esta operacin servir para grabar, en una base de datos, los datos de la transaccin de prstamo de materiales bibliogrficos a un Usuario. Por lo tanto, esa operacin deber interactuar con alguna clase creada para dar los servicios de grabar acciones en la base de datos. As, al ver la interaccin completa, encontramos accin en 5 capas. Otro aspecto importante del cual nos valemos en los diagramas de secuencia, como mencionamos anteriormente, se refiere al descubrimiento de operaciones. Vea que previa a la elaboracin de este, an no conocamos aspectos relativos a operaciones que deban ofrecer algunas clases. Eso es evidente en ciertas operaciones como los constructores (los cuales, por requerimiento del paradigma de orientacin a objetos, todas las clases deben tenerlos). De igual forma, se han usado operaciones tipos Actualizar/Obtener en varios objetos. Dependiendo de la herramienta que se utilice, agregar nuevas operaciones en un diagrama de secuencia har que estas, tambin, sean agregadas automticamente en las clases involucradas. Por lo tanto, si se ha construido algn diagrama de clases como el que hicimos en el captulo anterior, tambin se agregarn tales operaciones en este. Vea, por ejemplo, para las clases de DetallePrstamo cmo han sido actualizadas sus operaciones a partir de las que incluimos en el diagrama de secuencia de la Figura 40.
DetallePrstamo + + + + + + fecha_prstamo hora_prstamo unidad_tiempo fecha_devolucin hora_devolucin estado_prstamo : java.util.Date : java.util.Time : char : java.util.Date : java.util.Rime : char : java.lang.Boolean : int : int : int : int

DetallePrstamo () TieneCopiaPrestada (java.lang.String pIdUsu, java.lang.String pSig) ActualizaHoraPrstamo () ActualizaFechaPrstamo () ActualizaTipoPrstamo () ActualizaUnidadTiempo ()

Figura 42. Representacin de la clase de diseo Detalle Prstamo, a partir de los descubrimientos derivados del diagrama de secuencia de la Figura 40.

164

Mediante Power Designer, todas sus operaciones fueron agregadas durante el trabajo que se hizo para construir el diagrama de secuencia de la Figura 40 anterior. Esto nos hace ver que los diagramas de secuencia tienen muchos usos en el anlisis y en el diseo orientado a objetos. Gracias a ellos hemos podido ver y obtener lo siguiente. La interaccin de un actor con el sistema. Esta es una interaccin bsica, que permite ilustrar lo que un actor podra esperar del sistema ante ciertas peticiones. No obstante ser un diagrama elemental, los diagramas de interaccin del actor con el sistema, pueden deducirse a partir de los casos de uso y, con un trabajo especial, podemos conseguir, para cada uno de stos, las clases de diseo relativas a la capa de interfaz. De igual forma, las clases de diseo de la capa de gestin de eventos del sistema (gestores), pueden definirse mejor a partir de descubrir, mediante la estos diagramas de interaccin, las necesidades de la clases de la capa de interfaz con respecto a la de gestin. Los diagramas de secuencia permiten visualizar cmo interactan los objetos de la capa de negocios, manejados a partir de un gestor. La interaccin entre objetos permite tambin tener mejor idea de la definicin de las operaciones a travs de las cajas de activacin. Todos los llamados que se ejecutan en una misma caja de activacin permite a los diseadores deducir qu operaciones deben ser llamadas a partir de una operacin particular. Por ejemplo, la operacin ValidarUsuario en RegistroPrstamoManejador, debe llamar a las operaciones Usuario y ObtieneEstado de la clase Usuario. Finalmente, no importando si se encuentra en labores de diseo o anlisis, los diagramas de secuencia pueden utilizarse para descubrir nuevas operaciones en clases conceptuales o de diseo, por lo cual, en cualquier fase del proyecto, puede echarse mano de esta forma bastante poderosa de descubrir elementos de software en la solucin que estamos elaborando. Algunas veces en el desarrollo de este libro hemos dicho frases como: esto quedar ms claro cuando veamos diagramas de secuencia. Pues bien, eso significa que en esos momentos del trabajo, fuera que estuviramos descubriendo clases conceptuales o clases de diseo, hubiera sido til utilizar este tipo de diagramas. Ahora que usted los conoce, puede usarlos cuando convenga a su proyecto. Hemos llevado a cabo una serie de trabajos que nos permite obtener una visin y un modelo de clases de diseo ms completo. Hemos obtenido clases referidas a las clases de la capa de interfaz, de la capa de gestin y de la capa del negocio. Hemos incluido tambin, una clase de la capa de sistema y hemos comentado algn aspecto de la capa de bases de datos. Por lo tanto, el avance que puede lograrse con los diagramas de secuencia, es notorio. 165

De igual forma vea que todo ello se ha conseguido centrndonos en un solo caso de uso, como es Registrar Prstamo. Por ello debemos tener en cuenta que agregar otros casos de uso permitir, eventualmente, agregar muchas otras cosas a nuestro diseo. Y, por otra parte, vea cuan valioso es que usted sepa identificar cules casos de uso son crticos en el sistema. Ellos permitirn descubrir la arquitectura ms importante en l. DIAGRAMAS DE ACTIVIDAD: APOYANDO LA ESPECIFICACIN DEL DISEO Recuerde usted que una de los propsitos principales de la Ingeniera del Diseo es poder proporcionar el llamado diseo procedimental. En trminos sencillos, se trata de especificar los detalles algortmicos de los procedimientos, funciones u operaciones que se ejecutan en un software. Dicha especificacin se provee a los programadores, de tal forma que les sirva como base para la codificacin que deba realizarse. Esta especificacin puede darse de varias formas: pueden ser narraciones en pseudo-cdigo, o apoyarse tambin en modelos grficos, como los que proporciona UML. Teniendo esto en mente, podemos darnos cuenta de que los diagramas de secuencia nos sirven, de forma muy poderosa, para establecer varios requerimientos conceptuales (en las tareas de anlisis) y de implementacin (en las tareas de diseo). Sin embargo, para proporcionar un detalle procedimental como el que se necesita, si bien brinda algunas pistas importantes (como las operaciones que deben ser llamadas desde otra operacin y el orden y momento en que deben llamarse dentro de ella o, tambin, las repeticiones de una parte del proceso), ciertamente no son suficientes para poder indicar todo el detalle algortmico requerido para la especificacin de las operaciones en las clases. La familia de diagramas de UML nos proporciona otro tipo de diagramas ms adecuado para ello, conocidos como diagramas de actividad. Tales diagramas pueden representar, de forma ms adecuada, detalles como verificacin de condiciones, ciclos, cundo puede terminar anticipadamente una ejecucin; complementando muy bien lo que se descubre en los diagramas de secuencia y manejando aspectos que se especifican en los casos de uso (s, nuevamente los casos de uso!). Por ejemplo, recordemos que los casos de uso establecen un apartado para excepciones, tambin llamados cursos alternativos. Pues bien, la visin de ello se materializa muy bien con los diagramas de actividad.

166

Elementos de un diagrama de actividad

Si usted ya ha realizado alguna vez diagramas de flujo felizmente, los diagramas de actividad le resultarn familiares. Si no los ha realizado, felizmente no son complicados. Un diagrama de actividad se compone de los siguientes smbolos:
Smbolo Inicio Nombre Propsito Seala el inicio de una proceso que se ejecuta en el sistema Seala el fin de un proceso que se ejecuta en el sistema. Establece la transicin que se da entre dos actividades Representa una actividad que se da en el sistema. Una barra horizontal recibiendo dos o ms flujos o transiciones indica que las actividades de donde parten esos flujos deben ejecutarse paralelamente Un rombo define una decisin que debe tomarse a lo interno de un proceso en el sistema.

Fin

Transiciones o flujos

Actividad

Actividad

Sincronizacin

Decisin

Figura 43. Smbolos usados en un diagrama de actividad.

Note que los elementos de un diagrama de actividad son sencillos y para usted, a esta altura de sus estudios, no le resultarn nada extraos. Como se mencion anteriormente, se asemejan en mucho a los diagramas de flujo. Los diagramas de actividad son ideales para representar y especificar procesos que se ejecutan en el sistema. Pueden especificarse, desde aspectos de muy alto nivel, como lo casos de uso o lo que sucede en la interaccin de un actor con el sistema, hasta cosas muy especficas como el detalle de una operacin de una clase, o un algoritmo especial. Para ver su mecnica, partamos de un ejemplo sencillo: imagine que usted debe especificar un pequeo algoritmo que calcule la suma de los primeros n

167

nmeros naturales. Una primera forma es realizar un ciclo que ejecute tal suma y eso lo veremos en el siguiente diagrama.

Obtiene nmero N

Declare variable contador i = 0

Declare variable acumulacin suma = 0

Incremente en uno el contador

Actualice suma = suma ms i

Retorne suma [i <= N] [i > N]

Figura 44. Diagrama de actividad para un algoritmo, para calcular una suma de nmeros naturales.

El proceso se inicia con una actividad Obtiene nmero N, la cual consigue el nmero N, que es el nmero mximo de la suma de los primeros N nmeros naturales. Se ejecuta un proceso paralelo de declarar dos variables de trabajo: un contador llamado i (cuyo valor es 0 al inicio) y una variable suma donde se acumular la suma (vea en el diagrama las actividades que hacen ello). Posteriormente, hay una actividad que incrementa en uno la variable i. Luego hay una verificacin, donde se establece que si i es menor o igual a N, entonces se actualizar la variable suma con el valor en ese momento de la variable suma adicionando el valor de la variable i. Una vez hecha esa 168

actualizacin, se llama nuevamente a la actividad de acumular en uno el contador i. Observe que el proceso descrito en el prrafo anterior se repite hasta que, finalmente, la variable i es superior a la variable N. Una vez que i supera este valor, el proceso retorna el valor acumulado en la variable suma y el proceso termina. El ejemplo anterior nos sirve para ilustrar la capacidad que tiene un diagrama de actividad para especificar condiciones (o decisiones) y para visualizar, tambin, ciclos de repeticin. Estos pueden ser fcilmente representados en estructuras de control de lenguajes de programacin, como instrucciones if, o bien for, while o do-while en JAVA. Para quienes tienen curiosidad matemtica, la suma de los primeros N nmeros naturales tambin pueden calcularse de una forma muy directa. Dicha suma corresponde a la multiplicacin de (N * (N + 1)) / 2. Formule, como ejercicio, en un diagrama de actividad sencillo, este clculo.

Especificacin de casos de uso y diagramas de actividad

Cuando se especifican casos de uso empleando los diagramas de secuencia, podemos observar lo que podra pensarse que es el curso normal de eventos, es decir, que ocurren cada uno de los pasos previstos en el escenario como se espera que pasen, sin que suceda ninguna excepcin o curso alternativo. Sin embargo, como ya se mencion, puede ocurrir que en algn momento de la ejecucin del caso de uso surja algn tipo de situacin que no permita que se ejecute el siguiente paso, pudiendo resultar, adems, que el caso de uso termine, dada una situacin particular, y no se logre el objetivo que se persegua obtener. La carencia sealada anteriormente, de los diagramas de secuencia, por no representar estas situaciones, puede solventarse con lo que puede expresar un diagrama de actividad. Como veremos a continuacin, estos pueden completar la especificacin de lo que sucede en un caso de uso. Tomemos, de nuevo, el ejemplo que corresponde al caso de uso de Registrar Prstamo. Recordemos, a continuacin, su descripcin detallada.

169

Caso de uso Objetivo

Registrar prstamo Registrar la informacin del prstamos de un material bibliogrfico que se le hace a un Usuario de la biblioteca de la Universidad Actores Bibliotecario Condiciones previas El Bibliotecario deber tener en sus manos el material por prestar, ya sea que el Usuario se lo haya proporcionado, o bien que l mismo haya tenido que buscarlo, dado que es de prstamo restringido. Adems de contar con la identificacin del Usuario que lo habilite para poder usar el servicio de Biblioteca. Escenario El caso de uso comienza cuando el Bibliotecario ingresa al sistema la identificacin del Usuario. El Sistema le indica si el Usuario es vlido. El Sistema, adems le indica si el Usuario tiene algn registro de morosidad. Una vez comprobados los pasos anteriores, el Bibliotecario lee, del Sistema Bibliotecario, la informacin del material que va a prestarse, a travs de un lector de cdigo de barras. En ningn caso puede prestarse otra copia del mismo material al mismo Usuario, lo cual se comprueba por parte del Sistema cuando se hace esta lectura. El Sistema indica si el material puede ser prestado solo para uso interno de la Biblioteca y el tiempo que puede ser prestado en cualquier caso. El Bibliotecario registra el prstamo del material y el caso de uso termina. Excepciones o cursos En el paso 1, de comprobarse que el Usuario no est registrado alternativos en la Biblioteca, el caso de uso termina. En el paso 2, si el Usuario est moroso, el caso de uso termina. En el paso 3, si el cdigo de barras del libro est ilegible, el Bibliotecario deber ingresar este directamente en un campo de edicin de la pantalla. En el paso 3, de comprobarse que el Usuario ya tiene una copia del mismo material asignado en otro prstamo, el caso de uso termina. En el paso 4, luego de indicarle al Usuario las restricciones del prstamo, ste puede decidir no aceptar las condiciones, por lo cual el Bibliotecario termina la ejecucin del caso de uso. Condiciones posteriores De cumplirse el paso 5, el Sistema guarda el registro del prstamo efectuado al Usuario. El material debe quedar en estado de prestado.

Note que en la descripcin se establece una secuencia de 5 pasos en los cuales pueden inferirse actividades. Por ejemplo, en el paso 1 se indica que: El caso varios elementos que nos pueden servir para nuestro diagrama de actividad. Por una parte se establece claramente un inicio y cul actividad se ejecuta

de uso comienza cuando el Bibliotecario ingresa al Sistema la identificacin del Usuario. El Sistema le indica si el Usuario es vlido. Ah podemos encontrar

170

primero (el caso de uso comienza cuando el Bibliotecario ingresa la identificacin del Usuario). Por lo tanto, en un primer momento, podemos tener una construccin como la que sigue:

Bibliotecario ingresa identificacin del usuario

Advierta tambin que se est estableciendo, en las excepciones del caso de uso, una especfica para el paso 1, la cual establece que: En el paso 1, de el hecho que est o no registrado en el Sistema, sino tambin que pueda estar moroso o no estarlo. Todo ello debe averiguarse en la siguiente actividad del proceso e, igualmente, debe hacerse una comprobacin que podra dar por terminado la ejecucin del caso de uso. En otro caso se seguira con la siguiente actividad descrita en el paso 3: obtener el cdigo del material en prstamo usando el lector cdigo de barras. Vamos a visualizar cmo ira resultando, hasta este punto, nuestro diagrama.

comprobarse que el Usuario no est registrado en la Biblioteca, el caso de uso termina. Dado el conocimiento que tenemos ya del Sistema, no solamente es

Bibliotecario ingresa identificacin del usuario

Comprobar la validez del usuario

[S] Leer cdigo de barras del material Usuario Valido

[No]

Figura 45. Primera elaboracin del diagrama de actividad para el caso de uso de

Registrar Prstamo.

Posteriormente, con respecto al paso 3 y relacionado con la lectura del cdigo de barras del material bibliogrfico, puede surgir una excepcin: que este no pueda leerse mediante este dispositivo. Por lo tanto, tambin debe darse una verificacin si pudo leerse o no fue posible leer el cdigo de barras del 171

material. Si la respuesta es afirmativa, se prosigue, de lo contrario, el bibliotecario tendr que ingresar dicho cdigo mediante el teclado. El diagrama se vera de esta forma.

Bibliotecario ingresa identificacin del usuario

Comprobar la validez del usuario

[S] Leer cdigo de barras del material Usuario Vlido

[No]

Cdigo ledo

[No]

Ingresar cdigo material con teclado

[S]

Comprobar material para prstamo

Figura 46. Continuacin de la elaboracin del diagrama de actividad para el caso de uso de Registrar Prstamo.

En el diagrama de la Figura 46 anterior vemos cmo, una vez que se comprueba que ha podido leerse (o que no ha podido leerse) el cdigo del material con el lector de cdigo de barras, se pasa a la actividad de comprobar el material para prstamo. Fijmonos bien en la excepcin que se enunci originalmente: En el paso 3, de comprobarse que el Usuario ya tiene una copia del mismo material asignado en otro prstamo, el caso de uso termina. De nuevo, debemos pensar en la evolucin que ha tenido nuestro conocimiento del sistema y lo que se ha resuelto (en teora) junto con el cliente.

172

Sabemos que por cada prstamo puede haber muchos materiales que pueden prestarse. Por lo tanto, lo que se expresa en esa excepcin ya no es vlido y debera modificarse. Pareciera que en el momento en que se escribi ese caso de uso, se pensaba que solo poda haber un material prestado por prstamo. Por consiguiente, tanto el paso, como la excepcin, deberan modificarse como sigue. Una vez comprobados los pasos anteriores, el Bibliotecario lee del Sistema Bibliotecario la informacin del material que va a prestarse, a travs de un lector de cdigo de barras En ningn caso puede prestarse otra copia del mismo material al mismo usuario, lo cual se comprueba, por parte del Sistema, cuando se hace esta lectura El proceso se repite por cada uno de los materiales que el Usuario solicita Se destaca en cursiva y en negrita que el proceso es repetitivo, por lo puede asociarse a un prstamo varias copias de materiales. Por otra parte, en cuanto a la excepcin se tendra lo siguiente. En el paso 3, de comprobarse que el usuario ya tiene una copia del mismo material asignado en otro prstamo, no se incluye en el prstamo que est siendo procesado. Ac se vara la excepcin: el caso de uso no termina, sino que puede seguirse con la solicitud de otros materiales para el prstamo. Podemos ver el diagrama resultante, como sigue.

173

Bibliotecario ingresa identificacin del usuario

Comprobar la validez del usuario

[S] Leer cdigo de barras del material Usuario Vlido

[No]

Cdigo ledo

[No]

Ingresar cdigo material con teclado

[S]

Comprobar material para prstamo

Usuario tiene otra copia prestada [No] [S] Usuario Acepta Condiciones

[No]

[S]

[S]

Continuar agregando

Agrega material a la solicitud

Figura 47. Continuacin de la elaboracin del diagrama de actividad para el caso de uso de Registrar Prstamo.

Con el fin de completar la visin que se da a partir de las modificaciones que realizamos en el paso 3 y su correspondiente excepcin, hemos agregado tambin lo que se indica en el punto 4. Observe que, despus de que se comprueba en la decisin llamada Usuario tiene copia prestada, en el caso de que sea positiva dicha comprobacin, se pregunta si quiere continuar agregando materiales a la solicitud. Si se dice que s, entonces se procede a leer el cdigo de otra copia de un material.

174

En caso que la comprobacin de que si una copia del material ya ha sido prestada al usuario resulta negativa, se sigue con los pasos que se dan en el paso 4: El Sistema indica si el material puede ser prestado solo para uso interno de la biblioteca y el tiempo que puede ser prestado en cualquier caso. Adems, su correspondiente excepcin indica que: En el paso 4, luego de

indicarle al usuario las restricciones del prstamo, ste puede decidir no aceptar las condiciones, por lo cual el Bibliotecario termina la ejecucin del caso de uso.

Ac tambin nos encontraremos con que deben realizarse modificaciones (las cuales ya en el diagrama de la Figura 47 estn materializadas). Un usuario podra no aceptar las condiciones del prstamo para un material en particular, pero s para otros que le interesan. Por lo tanto, en el caso de la excepcin, debera reescribirse as: En el paso 4, luego de indicarle al usuario las

restricciones del prstamo, ste puede decidir no aceptar las condiciones, por lo cual el Bibliotecario prosigue con los otros materiales solicitados.

Advierta, entonces, que en el diagrama anterior, se ejecuta una condicin en la cual el Bibliotecario indica si el Usuario est de acuerdo (o no lo est) con las condiciones del prstamo. Si este indica que s, se agrega la copia del material solicitado al trmite y, si la respuesta es negativa, se prosigue con la decisin de continuar agregando materiales en la solicitud de prstamo. Finalmente debe completarse el proceso, ejecutando el paso 5. Dicho paso debiera estar a continuacin de la decisin de agregar (o no agregar) ms materiales a la solicitud de prstamo. Por lo tanto, si se indica que no se agregarn ms, entonces se da la actividad de registrar el prstamo. El diagrama completo de este caso de uso se vera as.

175

Bibliotecario ingresa identificacin del usuario

Comprobar la validez del usuario

[S] Leer cdigo de barras del material Usuario Vlido

[No]

Cdigo ledo

[No]

Ingresar cdigo material con teclado

[S]

Comprobar material para prstamo

Usuario tiene otra copia prestada [No] [S] Usuario Acepta Condiciones

[No]

[S]

[S]

Continuar agregando

Agrega material a la solicitud

[No]

Registrar Prstamo

Figura 48. Diagrama de actividad completo para el caso de uso de Registrar Prstamo.

Note que, una vez que se hace la actividad de Registrar Prstamo, se procede con la finalizacin del proceso. Finalmente, vea que un diagrama de actividad puede ayudarnos a documentar, de una forma conveniente y 176

relativamente sencilla, los casos de uso, considerando, adems, lo pertinente a las condiciones (vistas como decisiones) y a los ciclos que pueden darse en el proceso.

Especificacin de operaciones
La capacidad de expresin de los diagramas de actividad tambin nos permite poder especificar lo que puede ocurrir en una operacin particular de una clase. Por ejemplo, podemos servirnos de algunos de los diagramas de secuencia creados y, de esta forma, poder apoyar la especificacin de algunas operaciones usando diagramas de actividad Analicemos la situacin que puede derivarse del siguiente diagrama de secuencia.
:RegistrarPrstamoInterfaz :RegistrarPrstamoManejador

Bibliotecario IngresaIdentificacinUsuario() ValidarUsuario()

IngresaMaterialPrstamo() TieneCopiaPrestada()

IncluyeMaterialPrstamo()

RegistraPrstamo() RegistraPrstamo()

Figura 49. Diagrama de secuencia de las clases de interfaz y gestin para el caso de uso de Registrar Prstamo.

Veamos que uno de los mensajes, vistos como operaciones, que van entre el actor Bibliotecario y el objeto de la clase RegistraPrstamoInterfaz es el que se llama IngresaMaterialPrestado (el segundo de arriba abajo). Tal como lo habamos analizado, al visualizar la caja de activacin, vemos cmo parten del objeto RegistraPrstamoInterfaz dos operaciones hacia RegistraPrstamoManejador:

177

TieneCopiaPrestada e IncluyeMaterialPrstamo. Esto significa que dentro de la operacin IngresarMaterialPrestado, deben existir los llamados a esas dos operaciones. Cundo y cmo llamarlas? Eso puede especificarse mediante el diagrama de actividad. El diagrama de actividad podra ilustrar, visualmente, la siguiente lgica del algoritmo requerido en IngresarMaterialPrestado: La operacin tiene como

diagramas de actividad, podemos trazar el siguiente.

parmetro el cdigo del material que quiere prestarse y la identificacin del usuario que solicita. Debe comprobarse, mediante las operaciones del gestor, si tiene una copia prestada del mismo material y, de no ser as, puede incluirse en la solicitud del material para prstamo. Por lo que ya sabemos de los

Declara variable comprobacin = falso

comprobacin = TieneCopiaPrestada

[falso]

IncluyeMaterialPrstamo

[verdadero]

mensaje = Ya tiene ese material asignado en otro prstamo

mensaje = Material incluido con xito

Retorna mensaje

Figura 50. Diagrama de actividad para especificar la operacin TieneCopiaPrestada.

178

Vea que al inicio se declara una variable booleana local llamada comprobacin. Posteriormente comprobacin asume el valor del resultado de la operacin TieneCopiaPrestada. Si comprobacin tiene valor verdadero (es decir, que el usuario s tiene una copia del mismo material en prstamo actualmente), entonces una variable de tipo cadena de texto (o string) llamada mensaje, asume el valor de: Ya tiene este material asignado en otro prstamo. Si el valor es falso, se ejecuta la actividad con la operacin IncluyeMaterialPrstamo. Posteriormente la variable mensaje asume el valor de: Material incluido con xito Finalmente se ejecuta la actividad de retornar el valor de la variable y la operacin termina. Tenga en cuenta que la especificacin de operaciones debe valerse de muchas fuentes de informacin. Ya vimos que el diagrama de secuencia da una idea de qu operaciones deben ser llamadas por otra. Sin embargo, no se tiene una idea del flujo de control que debe darse en ellas, lo cual se complementa con un diagrama de actividad. Finalmente, un diagrama de clases nos debe asegurar algunas otras especificaciones, como por ejemplo, qu parmetros de entrada posee una operacin y qu tipo de valor retorna. Juntando todos ellos, un programador puede tener la visin completa de lo que se requiere para la codificacin de las operaciones lo cual, en el paradigma de orientacin a objetos, es en s misma, la codificacin del sistema. DIAGRAMAS DE ESTADOS Otro diagrama importante para la especificacin del software del sistema con que cuenta UML, es el llamado diagrama de estados. Un diagrama de estados puede documentar algunos estados importantes que poseen objetos del sistema y que resultan claves de visualizar y controlar (e igualmente, codificar y controlar en las operaciones). Por ejemplo, controlar el estado de un usuario ante el sistema podr resguardar el hecho de que podamos prestarle material a un usuario solamente cuando est libre de obligaciones con la Biblioteca. Otro ejemplo importante es el hecho de poder controlar el estado de una copia de material particular, de tal forma que no se representen inconsistencias en el sistema, como que se indique que una misma copia pueda estar prestada dos veces al mismo tiempo, o que no se indique que est devuelta cuando s lo est.

Elementos de un diagrama de estados

Los diagramas de estado son sencillos. Se componen de pocos smbolos a saber:

179

Smbolo

Nombre Estado inicial

Propsito Representa el estado inicial de un objeto

Estado

Estado

Representa un estado en particular en el que podra estar un objeto Representa la transicin, por causa de eventos en el sistemas, entre dos estados de un objeto

Transicin

Figura 51. Smbolos utilizados en los diagramas de estados.

Un ejemplo clsico para ilustrar un diagrama de estados, que tomamos de Larman (2003), puede verse alrededor de un telfono. Cuando un telfono est colgado, se encuentra en estado inactivo, mientras que al descolgarlo pasa a estado activo. Se identifican dos estados: activo e inactivo, a la vez que se dan dos eventos: colgar y descolgar el telfono. Por lo tanto, un diagrama de estados para un objeto telfono se vera as.

Inactivo [descolgar]

Activo

[colgar]

Note que en las transiciones entre estados, vistos como flechas, se visualizan cules eventos son los que desatan tales transiciones. En este caso, el evento descolgar hace que se de la transicin del estado del telfono de inactivo a activo y, en sentido contrario, el evento de colgar. Por lo tanto, lo anterior nos hace ver que para plantear un diagrama de estados debemos identificar: El objeto el cual va a ser descrito en sus posibles estados. Los estados posibles en los que puede estar un objeto. Los eventos del sistema que hacen que un objeto pueda cambiar de estado. Las transiciones vlidas entre estados.

Esto ltimo es muy importante porque, de acuerdo con alguna condicin del sistema, podran existir transiciones entre estados que no sean vlidas. Por ejemplo, en un objeto tipo Factura, si la factura ya ha sido confeccionada y pagada por parte de un cliente, esta asume un estado que se llama

180

Cancelada. Si se encuentra en ese estado, no podra entrar en un estado que no pudo haber estado antes, digamos En confeccin y, por lo mismo, que tenga efectos en el monto que ya ha sido cancelado: sera el paraso de alguien que le guste hacer fraude! Todo sistema podra tener restricciones de este tipo, donde haya transiciones que no puedan darse, o bien, que pudieran existir estados finales de los cuales no puedan salirse ms7. Elaboracin de diagramas de estados Podemos hacer, por lo tanto, un ejercicio con un objeto del tipo Copia, es decir, una copia de un material bibliogrfico. Recordemos que esta clase tiene un atributo que se llama estado_copia, el cual, precisamente, busca reflejar el estado de un objeto de la Copia dentro del sistema. Usted recordar que, en el momento en que elaborbamos las clases conceptuales, buscbamos all los posibles atributos de tales clases y, en particular para la clase Copia, indicbamos que el atributo estado_copia describa el estado de una copia de material en el sistema y que los posibles estados eran: Disponible, Prestada, En reparacin o Anulada. Para el diagrama de estado de un objeto de tipo Copia, ya poseemos los dos primeros puntos: obviamente el objeto que va a ser descrito y los posibles estados. El diagrama preliminar lo veramos de la siguiente forma:

Disponible

Prestado

En Reparacin

Anulado

Vemos en este solamente los estados sin ninguna transicin, las cuales procedemos a identificar a continuacin. Para pensar qu transicin puede darse a partir del estado inicial (la bolita rellena), debemos pensar solamente en uno de los estados que hay en el diagrama (desde el estado inicial puede irse solamente a uno de los estados). Podemos pensar que toda copia de material nuevo que se ingresa en el sistema, pasa inmediatamente a un estado
Para ello el estudiante se puede apoyar en la teora que se desarrolla en las Matemticas Discretas con relacin a las mquinas de estado finito y la teora de autmatas.
7

181

de Disponible y que, por lo tanto, es la transicin que se da del estado inicial. No se visualiza que se ingresa una nueva copia y que directamente vaya a ser prestada, o entre en reparacin o se anule. Para que alguna de estas ltimas situaciones pueda darse, en primera instancia debe estar disponible. Por lo tanto, tenemos la primera transicin que se da en nuestro diagrama.

Disponible

Nos detenemos en el estado Disponible y reflexionamos sobre cules transiciones son posibles. Para realizar este anlisis, obviamente usted tendr que conversar con los clientes y conocer mucho del contexto del problema que est tratando. Con el objeto del tipo Copia en estado Disponible, una copia bien puede pasar al estado de Prestada. Esta es una de las transiciones ms obvias de nuestro sistema, pues es uno de los objetivos principales de la biblioteca y del software que la apoya. Ahora bien, pensemos que una copia estando Disponible, una vez devuelta por algn usuario, el bibliotecario puede verla y sentir que est descuadernada o con algn otro tipo de deterioro. Por lo tanto, del estado Disponible puede pasar al estado En Reparacin. Encontrndose en estado Disponible podra pasar directamente al estado Anulada? Entendemos por copia anulada el estado en que una copia no puede volver a estar disponible en el sistema, por algn deterioro irreversible o bien por prdida o hurto. En este caso podemos pensar que, estando disponible e identificando un Bibliotecario algn deterioro, debe pasar previamente a un estado de En Reparacin donde se valore y, si el dao es irreversible, la copia podra pasar a un estado de Anulada. En tal caso no puede irse directamente del estado de Disponible a Anulada. Ahora bien, podra en algn momento, realizarse un inventario en la biblioteca y detectarse que una copia fue robada de la coleccin, sin haber sido previamente prestada. Por lo tanto, se tiene que podra pasarse al estado de Anulada directamente desde estado de Disponible, por un evento as. En resumen, viendo el comportamiento de estados desde el estado de Disponible podemos ver las siguientes transiciones. Se presentan como una matriz, donde el contenido de las celdas corresponde al evento que dispara la transicin y su correspondiente descripcin. Las celdas que quedan en blanco

182

indican que no hay transiciones vlidas entre los dos estados que hacen la interseccin, por ejemplo entre el estado Inicio y En Reparacin.

Estado Inicio

Disponible

Prestada En Reparacin Anulada Ingresar: Se ingresa una nueva copia al Sistema y queda en estado disponible Prestar: Reparar: Reportar prdida: Una copia se da en prstamo a Se enva la copia a Se anula del sistema una un Usuario de la Biblioteca reparar producto de la copia debido a que se ha deteccin de un deterioro detectado que esta se ha perdido

El diagrama resultante del anlisis hecho hasta ahora correspondera con el siguiente.

[Reportar prdida]

Disponible

[Prestar]

Prestado

[Reparar]

En Reparacin

Anulado

Figura 52. Diagrama parcial de la transicin de estados de la copia de un material bibliogrfico.

Podemos continuar nuestro anlisis desde los otros estados, de una forma semejante. Para ello completamos la matriz que comenzamos a realizar. En las intersecciones que quedan en blanco, se asume que no hay transiciones vlidas. Esta matriz que presentamos a continuacin, usted podr analizarla y ver, de acuerdo con su criterio, su validez.

183

Estado Inicio

Disponible Ingresar: Se ingresa una nueva copia al sistema y queda en estado disponible

Prestada

En Reparacin

Anulada

Disponible

Prestar: Una copia se da en prstamo a un Usuario de la Biblioteca Devolver: Se registra la devolucin de la copia

Reparar: Se enva la copia a reparar producto de la deteccin de un deterioro

Reportar prdida: Se anula del Sistema una copia debido a que se ha detectado que esta se ha perdido

Prestada

En Disponer: Reparacin La reparacin ha sido concluida por lo cual la copia vuelve a estar disponible

Reportar prdida: El Usuario indica que se ha perdido la copia que le haba sido prestada Anular por no localizacin: No se localiza un usuario al que se le haba prestado la copia, por lo cual despus de cierto tiempo se anula del sistema Anular por dao: Mantener: El dao detectado es irreparable por Se mantiene en reparacin al finalizarse lo cual se anula. un trabajo indicando que debe hacerse otro tipo de trabajo, o bien rehacer el que se ha hecho.

Anulada

De la matriz note lo siguiente: en primer lugar, el estado de Anulada es un estado final. De l no puede salirse. No hay transiciones vlidas desde dicho estado8. En segundo lugar fjese que las transiciones entre mismos estados son vlidas, como sucede con En reparacin. All, como se indica, puede una copia permanecer en ese estado, luego de finalizar un proceso parcial o mal hecho de reparacin. El diagrama final para el objeto copia se vera a continuacin:

De alguna forma, todo sistema deber permitir salir de cualquier estado por algn error que se cometa, pero tal accin debe estar muy controlada requiriendo de autorizaciones muy precisas.

184

[Devolver] [Reportar prdida] Disponible [Reparar] [Mantener] [Prestar] Prestado

[Anular por no localizar]

En Reparacin [Disponer] [Anular por dao]

Anulado

Figura 53. Diagrama de estado completo para la copia de un material bibliogrfico.

Finalmente vea que, mediante los diagramas de estados, pueden documentarse y visualizarse aspectos claves de control del sistema. Los eventos que se dan en las transiciones podran corresponder a operaciones, o bien ser base para que dentro de ellas pueda haber estructuras de control que garanticen que se estn dando las transiciones permitidas. Tales estructuras de control pueden ser vistas dentro de un diagrama de actividad. Es ideal entonces que, tanto para el desarrollo, como las pruebas que deben realizarse en el software desarrollado, que pueda contarse con diagramas de este tipo para poder garantizar la buena construccin del software, validando aspectos sumamente importantes como los estados en los que puede estar un objeto.

185

EJERCICIOS DE AUTOEVALUACIN 1. Elabore los diagramas de secuencia para el Sistema de Reserva de Espectculos en lnea que ilustre lo siguiente. La interaccin del actor del sistema que quiera realizar la reservacin con el sistema. Deduzca del punto anterior la clase de diseo de la capa de interfaz para el caso de uso involucrado. La interaccin entre los objetos entre la capa de interfaz y la capa de gestin del caso de uso involucrado.

Note que debe elaborar las clases de diseo y de gestin correspondientes. 2. Realice el diagrama de secuencia que permita visualizar la reserva de un espectculo involucrando las capas de interfaz, de gestin, de negocio, de sistema y de base de datos. Siga la elaboracin hecha para deducir la Figura 40. 3. Explique por qu son importantes los casos de uso para la elaboracin de los diagramas de secuencia y cmo repercuten en la elaboracin de las clases de diseo. 4. Explique cmo se diferencian y cmo se complementan los diagramas de secuencia y de actividad en la documentacin de los casos de uso. 5. Represente, mediante un diagrama de actividad, el algoritmo de la sumatoria infinita, desde n = 0, de la fraccin 1/rn, mientras que el trmino de la fraccin sea superior a 0,00001. 6. Escoja dos operaciones de la clase de gestin elaborada en el ejercicio 1 y especifquelas mediante diagramas de actividad. 7. Tome el concepto de Reservacin en el Sistema de Reservaciones de Espectculos en Lnea, de tal forma que pueda: Identificar los estados de una Reservacin. Identificar las transiciones vlidas entre estados para una Reservacin representndolas mediante un diagrama de estados.

186

CAPTULO

DE CARA A LA IMPLEMENTACIN

SUMARIO

CONSIDERACIONES PRELIMINARES LAS PRUEBAS EN LA INGENIERA DE SOFTWARE

De lo integral a lo particular a lo integral Pruebas de unidad Pruebas de integracin y componentes DESPLEGABDO LA SOLUCIN Elementos de un diagrama de despliegue Construyendo un diagrama de despliegue COMPLETANDO EL PROCESO DE TRANSICIN CONCLUSIONES

187

OBJETIVOS Una vez que usted estudie este captulo, podr llevar a cabo cada una de las siguientes actividades de aprendizaje, que le servirn para comprobar cunto ha aprendido de este tema. Justificar la utilidad de los modelos creados para apoyar los distintos niveles de prueba de software. Justificar la utilidad de los casos de uso en la prueba de los elementos de software de forma particular e integral. Manejar los principios bsicos del uso de componentes como forma de integracin modular y arquitectnico del desarrollo de software. Crear diagramas de despliegue con el fin de definir los elementos de hardware que sustentan la solucin de software. Establecer claramente la relacin de un desarrollo usando el Proceso Unificado y el UML con los distintos elementos que conforman un Sistema Basado en Computadoras.

188

CONSIDERACIONES PRELIMINARES Los temas que hemos abordado en el libro, hasta ahora, buscan dotarlo de tcnicas para que usted desarrolle las tareas de Ingeniera de Software usando los principios del Proceso Unificado, los cuales explotan las capacidades del Anlisis y Diseo Orientado a Objetos y los diagramas de UML. Como tal, usted ha podido constatar, en la experiencia del ejercicio de la construccin del software para el Sistema de Prstamos Bibliotecarios, que buscamos avanzar en las tareas de Anlisis y de Diseo, usando convenientemente ciertos diagramas. Estos diagramas no son exclusivos de una fase u otra. Por ejemplo, pueden usarse diagramas de clases en el Anlisis o en el Diseo. O, por otra parte, los diagramas de secuencia pueden usarse para documentar casos de uso (fase de Anlisis) o definir clases de diseo de gestores (fase de Diseo). Basados en el mismo principio iterativo del Proceso Unificado, podemos enfrentarnos tambin con el hecho de que se estn realizando tareas de Diseo y debamos enfrentarnos, en algn momento de ese proceso, a decisiones de Anlisis. Esta caracterstica en la construccin del producto no es un descubrimiento por s mismo del Proceso Unificado; es algo que comnmente pasa y que esta forma de desarrollar software facilita integrarlo dentro de la metodologa de desarrollo, sin tener que echar al cesto de la basura lo realizado hasta ese momento. Muchas veces se trata, simplemente de modificar un diagrama. Qu cmodo, comparado a mis aos de hacer diagramas de flujo de datos con monedas! Por otra parte ha notado cmo los casos de uso son algo omnipresente en todo el desarrollo. Todos los diagramas y modelos que hemos producido han estado guiados por los casos de uso. No gratuitamente; se dice que el Proceso Unificado est guiado por los casos de uso. Este ltimo captulo lo relacionaremos con los procesos de pruebas e implementacin del producto, lo cual se denomina la fase de Transicin en el Proceso Unificado. Nos valdremos, nuevamente, de los casos de uso y otros diagramas, como los llamados diagramas de despliegue, para definir aspectos relacionados con la estrategia de implementacin del sistema. Dicha estrategia est muy relacionada con la arquitectura del sistema y los temas que hemos visto, previamente, como la arquitectura en n-capas. De paso, estaremos tocando aspectos introductorios relativos a los componentes en el software y cmo estos se resuelven y son importantes en el marco del Proceso Unificado con UML.

189

LAS PRUEBAS EN LA INGENIERA DE SOFTWARE No es el objetivo ahondar en este tema que usted debe manejar, producto de sus estudios previos en otros cursos de Ingeniera de Software. Basta que repasemos algunos aspectos bsicos relacionados con las pruebas de un producto de software. Las pruebas son un proceso cuyo objetivo es detectar errores en el software construido. Cada una de las fases del Proceso Unificado, el Inicio, la Elaboracin, la Construccin y la Transicin, estn sujetas de realizrseles pruebas. En particular, durante la Transicin se hacen las pruebas necesarias para poder entregar un producto de software que responda a todos los objetivos para que el que fuera creado, esto es, que cubra todos los casos de uso. Se establece una versin beta, la cual puede ser examinada por un grupo de usuarios y evolucionar hacia la versin final del software requerido. En este momento, es conveniente recordar la Figura 5 vista en este material: Fases Inicio

Actividades fundamentales Requisitos

Elaboracin

Construccin

Transicin

Anlisis

Diseo

Implementacin

Pruebas

Iter #1

Iter #2

...

Iter Iter #n - 1 # n

Figura 54. Las pruebas estn en todas las fases del Proceso Unificado, pero aumentan en la fase de Transicin.

190

La produccin de esta versin beta implica que ya se ha superado, dentro de la fase de Construccin del Proceso Unificado, la etapa de Codificacin o Programacin. La discusin sobre tcnicas programacin sobrepasa los alcances de este libro, dado que usted, en este punto del avance de sus estudios, debi ya superar los cursos bsicos, intermedios y avanzados de programacin. De igual forma, la teora de programacin debi ya incluir lo referente a las tcnicas de pruebas. No obstante lo anterior, podemos resaltar algunas facilidades que da el Proceso Unificado, utilizando UML, para poder apoyar el plan de pruebas. Las pruebas, en general, pueden dividirse en estas fases:
Pruebas de unidad Pruebas de integracin Pruebas de sistema Se prueba cada una de las piezas de software (clases, componentes) que se han de forma individual. Las piezas de software se prueban en su interaccin con otras Se prueba el software en relacin con otros elementos del sistema (hardware, redes, bases de datos, gente) y de acuerdo con los objetivos planteados.

Tabla N 9. Clasificacin general de los tipos de pruebas en la Ingeniera de Software

Viendo esta clasificacin, debemos tener en cuenta un aspecto importante que busca garantizar un el Anlisis y Diseo Orientado a Objetos que se obtiene mediante el Proceso Unificado: cualquier concepto que se ha trabajado debe provenir de un objetivo real, identificado desde el momento en que se desarrollaron los casos de uso. Esto, ni ms ni menos, debi seguir una validacin constante del cliente o usuario del sistema. Hemos ya mencionado que las tareas de prueba estn presentes en todas las fases del Proceso (ver Figura 54). Por ello cada iteracin que se realiza en el proyecto debe estar sujeta de un examen, en el cual el cliente debe jugar un papel relevante. Idealmente, por lo tanto, la mnima pieza de software debera estar generada en funcin del problema real. Al tratar de reducir el riesgo de malinterpretaciones, el Proceso Unificado trata de garantizar que no haya prdida en el desarrollo del proyecto, detectando lo antes posible las fallas. Ahora bien, independientemente de cundo suceda en el tiempo del proyecto, las pruebas, tal como las clasificamos en la Tabla N 9, deben darse con la estrategia descrita all. Cmo pueden los modelos generados a lo largo del proyecto apoyar la estrategia de pruebas?

191

De lo integral a lo particular a lo integral Es bueno, a esta altura de nuestro estudio, tratar de recordar de lo que se trata un caso de uso: a grandes rasgos, un caso de uso es un objetivo que tiene que cumplir el sistema. La forma en que planteamos los casos de uso no nos indica nada en particular referente a las piezas de software que intervienen en este. Hemos visto cmo un caso de uso debe ser, por ejemplo, comprendido fcilmente por personal que no es especialista en software. Adems, tambin hemos estudiado cmo, para poder cumplir el objetivo del caso de uso, colaboran mltiples objetos derivados de las diferentes clases que participan en la solucin. Qu puede significar ello para las pruebas de software? Pinselo por un instante, de acuerdo con lo descrito en la Tabla N 9 y lo retomaremos ms adelante. Cuando buscamos sustentar los casos de uso en el sistema, creamos modelos de clases, los cuales, a su vez, proveern los objetos que intervendrn para poder cumplir el objetivo del sistema sealado en el caso de uso. Por ejemplo, en el caso del Sistema de Prstamo Bibliotecario que hemos seguido, el caso de uso de Registrar Prstamo tiene varias condiciones que deben cumplirse. Esto lo podemos ver en el escenario de este caso de uso, el cual puede resumirse en: a) b) c) d) e) El Usuario debe estar inscrito en la Biblioteca. El Usuario no debe tener deudas con la Biblioteca. No debe tener prestada otra Copia del Material. Debe asignarse un tipo y tiempo de prstamo. La Copia del libro debe quedar en estado de prestada y asignada al Usuario.

En todos pasos intervienen muchos objetos de distintas clases. Por lo tanto, en un plan de pruebas, el cumplimiento de un caso de uso nos indicar que estamos ante pruebas de integracin. Pero debe notar que el caso de uso es un insumo esencial que, si est bien planteado, desarrollado y especificado, es un insumo que facilita nuestro plan de pruebas. Por lo tanto: no descuide el celo con que debe desarrollar los casos de uso! Si usted se fija en los diagramas de actividad creados, por ejemplo, el de la Figura 48, encontrar un plano para poder realizar la prueba del caso de uso. En s, muchos de los elementos que integran el diagrama de actividad pueden relacionarse con un mtodo u operacin de una clase. En la siguiente figura asociaremos, en letras rojas, la operacin que puede ayudar a implementar el caso de uso. El formato que usaremos ser: Nombre de la operacin:Clase a la que pertenece. Por ejemplo, es el caso de ObtieneEstado:Usuario.

192

Bibliotecario ingresa identificacin del usuario

Comprobar la validez del usuario

ObtieneEstado:Usuario
[Si] Leer cdigo de barras del material Usuario Vlido [No]

Cdigo ledo

[No]

Ingresar cdigo material con teclado

[S]

Comprobar material para prstamo

TieneCopiaPrestada:DetallePrstamo
Usuario tiene otra copia prestada [No] [S] Usuario Acepta Condiciones

[No]

[S]

[S]

Continuar agregando

Agrega material a la solicitud

IncluirCopiaEnPrstamo: Prstamo
[No]

Registrar Prstamo

RegistrarPrstamo: Prstamo

Figura 55. Operaciones involucradas en el caso de uso de Registrar Prstamo.

193

De forma complementaria, los diagramas de secuencia tambin deben darnos la capacidad de poder visualizar todas las operaciones que intervienen (y que debemos probar) para poder realizar un caso de uso. En ello, podemos completar la de un diagrama de actividad, dado que el diagrama de secuencia define todas las operaciones que intervienen en todas las capas (ver el ejemplo de la Figura 40 para Registrar Prstamo). En tal caso, al probar el caso de uso, debe probarse tambin la correctitud con que funcionan dichas operaciones. Como tales, estas ltimas pertenecen a una clase. Por lo tanto, usted est enfrentando aspectos relacionados con la particularidad de las unidades de software ms elementales que tenemos en nuestra solucin: las clases. Los casos de uso llevan intrnseco las pruebas de unidad. De hecho, el anlisis de lo que cada clase debe proveer a travs de sus operaciones, nace del anlisis de los casos de uso y, para poder cumplir los objetivos de stos, el modelo de diseo aade otros ms (constructores, operaciones de obtener/establecer, entre otros). Todo este proceso complejo de construccin, lo hemos seguido en el caso del Sistema de Prstamo Bibliotecario. Al realizar la prueba de todos los casos de uso de un sistema, deberamos probar todas las operaciones de todas las clases que intervienen. En s, tambin nos enfrentamos a lo particular. Los casos de uso, en s, nos ayudan en lo integral y en lo particular de las pruebas. Claro est, que las pruebas de unidad deben hacerse tambin tomando cada clase separadamente y, en cada una de las operaciones, realizar las pruebas conforme a los objetivos de ellas. Hacemos una pequea reflexin en el siguiente apartado. Pruebas de unidad Recordemos que uno de los objetivos ms importantes de la Ingeniera del Diseo (entre muchos otros), es el llamado Diseo Procedimental. Este lo podemos entender como la definicin algortmica de los procedimientos, funciones, operaciones o mtodos (dependiendo del paradigma de desarrollo que estemos usando), que se hayan identificado. A partir de ello, podemos considerar varios aspectos con respecto a los modelos que generamos usando UML. En primer lugar, a lo largo del proceso que se ha ejemplificado en este libro, el Sistema de Prstamos Bibliotecarios, se han generado modelos como el Modelo Conceptual del Clases y el Modelo de Clases de Diseo. Un hito importante es poder identificar, en las clases de diseo, todas las operaciones que una clase debe tener para cumplir su propsito dentro del sistema.

194

Algunas de ellas las definimos en el Modelo Conceptual y otras fueron aadidas y especificadas en el Modelo de Diseo. Una operacin existe en una clase con el propsito de que de los objetos derivados de dicha clases puedan cumplir con las tareas que se esperan de estos dentro del sistema. Por ejemplo, la clase Prstamo tendr las operaciones necesarias para que los objetos creados cumplan su rol. As tambin lo podemos afirmar para clases de diseo (por ejemplo, de las capas de interfaz, de gestin, de sistema). Vimos que, referente a la especificacin de operaciones, podamos recurrir a modelos como los Diagramas de Actividad para realizar dicha especificacin (vea el ejemplo de la Figura 48 para la operacin TienaCopiaPrestada). Con estos diagramas, de forma relativamente sencilla, puede detallarse el algoritmo requerido de una operacin. Adems, de sus cursos de programacin podr recordar que al crear una operacin, debe completarse una especificacin, la cual puede incluir: Nombre de la operacin. Clase a la que pertenece. Tipo de retorno de la operacin (por ejemplo si devuelve un valor entero, un booleano, una cadena de caracteres, entre muchos tipos, o bien ningn tipo en cuyo caso en JAVA se dice que es de tipo void). Rango de valores vlidos de retorno. Parmetros que recibe y los valores permitidos en cada caso. Resultado esperado de la operacin: por ejemplo, si cambia el estado de algn elemento del sistema (digamos que un material bibliogrfico pasa de estar en estado Prestado a un estado Disponible). Especificacin algortmica: diagrama de actividad para la operacin.

Para el caso de TieneCopiaPrestada, podemos darnos el ejemplo siguiente:

195

Nombre Clase Tipo de retorno Rango de valores de retorno Parmetros Resultado

TieneCopiaPrestada RegistraPrstamoManejador String pUsuario: instancia de un usuario de la biblioteca pCopia: instancia de la copia de un material bibliogrfico en la biblioteca Devuelve el mensaje Ya tiene ese material asignado en otro prstamosi el usuario indicado en pUsuario ya tiene asociado un prstamo de otra copia del mismo material asociado a pCopia. De lo contrario, devuelve el mensaje Material incluido con xito.

Especificacin algortmica

Declara variable comprobacin = falso

comprobacin = TieneCopiaPrestada

[falso]

IncluyeMaterialPrstamo

[verdadero]

mensaje = Ya tiene ese material asignado en otro prstamo

mensaje = Material incluido con xito

Retorna mensaje

Figura 56. Especificacin de la operacin TieneCopiaPrestada.

Esto ltimo, en conjunto con los modelos creados en UML, nos sirve de insumo para las pruebas de unidad. 196

Como ya mencionamos, no pretendemos ahondar en teora que usted ya maneja de sus cursos previos de programacin. No obstante, puede apreciar cunto facilita un Anlisis y Diseo Orientado a Objetos usando UML, el plan de pruebas que debe ejecutarse. En ello es esencial que usted desarrolle bien los casos de uso. La visin integral que stos proveen, amarran muy bien los elementos particulares de software que se han creado. No olvide, adems, que las pruebas en el Proceso Unificado no son algo exclusivo del final del proyecto relacionado, solamente, con el cdigo creado: todos los modelos son sujetos de examen. Esto ha sido cierto en el proceso que hemos desarrollado a lo largo de este texto. Por ejemplo, se comprob en muchos momentos y en fases distintas (de anlisis, de diseo), lo correcto (o incorrecto) de los modelos creados. En muchos casos corregimos lo que venamos trabajando, aadiendo o modificando clases o parte sustantivas de stas. Al final, tales exmenes son ganancia para el proceso de programacin y para el proceso de pruebas, dado que entre ms depurado est el modelo de clases resultante (en cada una de las capas de la arquitectura de n-capas), ser ms preciso el cdigo de programacin que se genera. Recurdese que uno de los progresos que ha conllevado el UML, es que muchas herramientas de software han podido suministrarnos una correspondencia muy alta entre el modelo y un lenguaje de programacin orientado a objetos. Pruebas de integracin y componentes Hemos mencionado que una forma conveniente que nos proporcionan los casos de uso, es que se especifica cmo deben coordinarse los objetos de distintas clases para poder cumplir los propsitos de dicho caso de uso. Cuando probamos la ejecucin de un caso de uso, estamos realizando pruebas de integracin. En la Ingeniera del Diseo (independientemente de la metodologa que usemos), encontramos tambin aspectos relacionados con la teora de la modularidad, la cual sustenta la creacin de componentes. De acuerdo con la OMG (Object Management Group), un componente es una parte modular,

desplegable y reemplazable de un sistema que encapsula implementacin y expone una serie de interfaces.

La definicin anterior puede recordarnos la definicin de objetos y clases en el Paradigma de Orientacin a Objetos. Precisamente, uno de los aspectos ms importantes de este paradigma, es que sus piezas de software ms elementales (los objetos derivados de las clases), cumplen muchos principios de la modularidad requerida por los principios de diseo de software.

197

Ahora bien, un componente es ms complejo que una clase y, de hecho, puede agrupar muchas clases. Los componentes se asocian con el concepto de mdulo, es decir, unidades de software que tienen alta cohesin y bajo acoplamiento. Por alta cohesin diremos que el mdulo cumple con un conjunto de responsabilidades enfocado. Por ejemplo, si tenemos un mdulo para la tramitacin de prstamos y devoluciones de libros en una biblioteca, tal mdulo cumplir esas dos responsabilidades y sabemos que tenemos que acudir a dicho mdulo para ello. En cuanto al bajo acoplamiento, al existir la necesidad de colaborar entre mdulos, este debe ser mnimo. Cada componente de software debe presentar una o varias interfaces. A travs de estas interfaces se accede a los servicios que provee el mdulo. En el Paradigma de Orientacin a Objetos, usted recordar que una interfaz es algo parecido a una clase, con la peculiaridad de que solamente define la signatura (o definicin) de operaciones. Para cada interfaz, deber existir una o varias clases que implementen TODAS las operaciones all definidas. Por ejemplo, se puede definir una interfaz el proceso de registrar un prstamo en el Sistema Bibliotecario de Prstamo, concebida mediante estas operaciones:
IRegistrarPrstamo + IngresarIdentificacinUsuario () : String : String + IngresarMaterialPrstamo () : int + RegistrarPrstamo ()

Figura 57. Interfaz para Registrar Prstamo.

Note que al lado superior izquierdo hay un smbolo de un crculo asociado con una lnea, lo cual comnmente, valga la redundancia, simboliza a las interfaces. Tambin es comn encontrar la convencin de que toda interfaz inicie su nombre con la letra I mayscula. El cdigo en JAVA de una interfaz es sencillo. Este se visualiza as: public interface IRegistrarPrstamo { public abstract String IngresarIdentificacinUsuario(); public abstract String IngresarMaterialPrstamo(); public abstract int RegistrarPrstamo(); }
Figura 58. Cdigo en JAVA para la interfaz IRegistrarPrstamo.

198

Posteriormente podemos indicar cul clase es la encargada de implementar esta interfaz. En este caso podremos considerar que el la clase de diseo de gestin RegistrarPrstamoInterfaz, sea la encargada de implementar la interfaz IRegistrarPrstamo9. public class RegistrarPrstamoInterfaz implements IRegistrarPrstamo { public RegistrarPrstamoManejador gestor; public RegistrarPrstamoInterfaz(RegistrarPrstamoManejador gestor) { // TODO: implement } public String IngresaIdentificacionUsuario(java.lang.String pIdUsu) { // TODO: implement return null; } public String IngresaMaterialPrstamo(java.lang.String pIdCopia, int pTipo) { this.gestor.TieneMaterialPrestado(idCopia); this.gestor.IncluyeMaterialPrstamo(idCopia); return mensaje; } public int RegistraPrstamo(java.lang.String pIdBiblio, java.lang.String[] pCopias) { // TODO: implement return 0; } }
Figura 59. Cdigo en JAVA de clase RegistrarPrstamoInterfaz que implementa la

pIdUsu,

java.lang.String

interfaz IRegistrarPrstamo.

Se resalta en letra negrita la palabra clave implements seguida del nombre de la interfaz IRegistrarPrstamo. De esta forma, en JAVA la interfaz en cuestin tiene una implementacin en esta clase.
9

En el ejemplo que estamos desarrollando se est eligiendo el gestor de la capa de interfaz como la clase que implementa una interface de JAVA. No debe confundirse la capa de interfaz con una interface. Las interfaces pueden implementarse con clases de cualquier capa.

199

Imagine, por otra parte, que se modifica todo el modelo de clases en n-capas que hemos realizado hasta ahora, de tal forma que tambin se tenga la capacidad de administrar las devoluciones de los materiales prestados. De igual forma puede tenerse otra interfaz llamada IRegistrarDevolucin, asociada con un gestor de la capa de interfaz para el manejo de este caso de uso. En s, entonces, estaramos en capacidad de crear un componente de software que tuviera esas dos interfaces, que podra llamarse AdministrarPrstamo. El componente, en UML, se visualiza, tal como se ejemplifica en la Figura 60, como una pieza rectangular, con dos conectores a mano izquierda:
AdministrarPrstamo

Figura 60. Componente AdministrarPrstamo en el Sistema Prstamos Bibliotecarios.

En PowerDesigner podemos asociar las interfaces de este componente en la definicin misma de ste, tal como se muestra en la siguiente figura.

Figura 61. Asociacin de interfaces para un componente en Power Designer.

200

Dentro de un componente no solamente definimos la interfaz, sino tambin toda la implementacin necesaria. Por lo tanto, deben incluirse las clases que proporcionan la implementacin de estas responsabilidades asignadas al componente. En el caso de Power Designer tambin podemos realizarlo, tal como se muestra en la Figura 62.

Figura 62. Asociacin de interfaces para un componente en Power Designer.

Estudiar a profundidad el tema de construccin de componentes escapa a los alcances de este libro, dado que los temas avanzados en ellos son complejos cuando se abarcan tecnologas como los componentes Enterprise Java Beams (EJB) o los COM. No obstante de esta reflexin que estamos haciendo, podemos hacernos algunos cuestionamientos. Observe que en la lista de clases escogidas, estamos incluyendo clases como Usuario o Bibliotecario. Lo anterior debera hacernos pensar en el grado de cohesin y acoplamiento que tiene el mdulo. Al esbozar que las responsabilidades de nuestro componente son las de registrar prstamos y devoluciones de materiales bibliogrficos, ciertamente que para ello necesitamos informacin del Usuario y del Bibliotecario.

201

Sin embargo, al contener en el componente las clases involucradas, tambin estaramos asumiendo que la responsabilidad del componente tendra que ir en la administracin de la informacin de los usuarios y de los bibliotecarios, por lo cual deberan tomarse algunos de los siguientes cursos de accin. Agregar otras interfaces para manejo de esa informacin. Quitar las clases de Usuario y Bibliotecario de la definicin del componente y crear componentes especializados para la administracin de stos. Qu curso de accin sera mejor tomar? Examinndolo bajo la teora de la modularidad, con respecto a los principios de cohesin y acoplamiento, ntese que se est bajando la cohesin (puesto que se est aumentando la responsabilidad del mdulo). Lo anterior porque, ya no solo se encargara de administrar prstamos y devoluciones del Material Bibliogrfico, sino que estara administrando la informacin del Usuario y del Bibliotecario. Como consecuencia de lo anterior, se aumenta el acoplamiento y, por tanto, para cumplir las responsabilidades del mdulo, debe conocerse lo correspondiente a la definicin de los conceptos de Usuario y Bibliotecario, lo cual, al fin y al cabo lo puede suministrar una operacin proveniente de componentes especializados en ellos. Dentro de los principios de arquitectura del Proceso Unificado, por otra parte, se busca crear una arquitectura de piezas de software (componentes) que sea altamente reutilizable. En este caso, debemos asegurarnos que si se hacen modificaciones en el software, estas no afecten lo que no debe afectarse. Por ejemplo, si modificamos algo relativo a la administracin de usuarios de la biblioteca, tenemos que afectar el componente relacionado con la administracin de devoluciones y prstamos, lo cual es indeseable. O si por otra parte, queremos reutilizar la administracin de usuario creada para este sistema en otro sistema, deberamos llevar tambin todo lo relacionado con devoluciones y prstamos de libros, lo cual no tendra nada que ver en la otra solucin. Por lo tanto, se elegira el curso de accin b). La definicin de clases para el mdulo quedara as.

202

Figura 63. Clases resultantes del componente de AdministrarPrstamo.

Un diagrama de componentes podra ilustrar el acoplamiento entre estos, de la siguiente forma:

AdministrarPrstamo

Usuarios

Figura 64. El componente AdministrarPrstamo se acopla con el componente Usuarios.

Dicho acoplamiento podra hacerse mediante una operacin que retorne un objeto de tipo Usuario, que es el que necesita AdministrarPrstamo para cumplir sus responsabilidades. Por qu tocamos el tema de los componentes en este punto? Por muchos motivos. En primera instancia note que pueden existir muchos niveles de integracin en el software que deben probarse.

203

Cuando creamos un componente, la implementacin de este puede llevar la coordinacin de muchos objetos provenientes de muchas clases. Fjese, por ejemplo, en la complejidad que se expone en la Figura 40 de este libro, para el caso de registrar un prstamo en la Biblioteca. Esta integracin debe verificarse a lo interno del componente, pero, a su vez, debe probarse cmo interacta este componente con los otros para tambin cumplir la solucin deseada. Por lo tanto, las pruebas de integracin pueden verse a nivel de colaboracin de objetos dentro de un componente y tambin a nivel de acoplamiento entre componentes. Idealmente, de acuerdo con el desarrollo orientado a componentes, deberan construirse estas piezas de software de tal forma que puedan reutilizarse posteriormente. Estas ya han sido probadas y para integrarlas a otras soluciones, se tiene certeza de que cumple con lo que sus interfaces definen. De esta forma, ya no seran las clases, sino los componentes las unidades ms elementales en este tipo de desarrollo de software10. Por otra parte, y complementando el prrafo anterior, el Proceso Unificado, a la vez que es guiado por casos de uso, tambin se orienta a la arquitectura. El desarrollo de componentes tiene, en cuanto al software, ese objetivo de crear piezas que sean reutilizables, intercambiables y fcilmente mantenibles. Por ejemplo, si se cambia la administracin de usuarios en la Biblioteca y se sigue respetando la interfaz requerida por la administracin de prstamos en el Sistema, entonces el impacto de ello fue mnimo en el funcionamiento global del sistema. Siguiendo con el ejemplo, si se detecta que debe realizarse una modificacin en el componente de usuarios pero que no afecta la administracin de prstamos, entonces el Sistema de Prstamos Bibliotecarios sigue funcionando. Por ltimo, desde un punto de vista muy prctico, el componente va a corresponder, en lenguaje mquina, a un archivo DLL o EXE. Los efectos prcticos de conseguir modularidad redundan en que el archivo generado por el proceso de compilacin, nos dar todos los servicios que requerimos en la conformacin de la solucin. De esta forma, si bien puede profundizarse mucho ms en este tema, usted ya tendr una idea completa de los propsitos del Proceso Unificado. Finalmente, un diagrama de componentes que puede proponeser para nuestro sistema, sera el que sigue.

10

Ver captulo 30 de Pressman (2005)

204

Bibliotecario

AdministrarPrstamo

MaterialBibliogrfico

Usuarios

Financiero

Figura 65. Diagrama de componentes que implementan el Sistema de Prstamo

Bibliotecario.

En la Figura 65 note que podramos estar ante componentes complejos en su implementacin, con muchas interfaces, como podra ser el componente de un Sistema Financiero. No obstante, se rescata el hecho de que para el Sistema de Prstamo Bibliotecario, no tenemos que inventar la rueda a cada rato. Si la organizacin ya tiene un Sistema Financiero y, de este necesitamos su servicio de generar una cuenta por cobrar, entonces simplemente utilizamos lo ya creado. De igual forma, podemos discutir si el componente de Bibliotecario corresponder ms bien a usar un componente del sistema de Recursos Humanos, donde existir un funcionario descrito en el manual de puestos con esta categora. En cuanto al componente de Material Bibliogrfico, sabemos tambin su complejidad, dado que tiene intrnseco estructura de herencia que maneja cualquier tipo de material que puede prestarse (libros, revistas, vdeos, tesis), adems de las copias de cada uno de estos tipos de material. Qu requerira el componente de AdministrarPrstamo del componente de MaterialBibliogrfico? Le dejamos que, como ejercicio, usted responda a esta pregunta. Esta visin de componentes, cuanto mayor se apropie usted como ingeniero de ella, facilita una de las primeras tareas que deben definirse en la fase de inicio del Proceso Unificado: la especificacin de los principales subsistemas. Ante las necesidades que pueden esbozarse all, si la organizacin fomenta la creacin de componentes, usted podr decir muy tranquila y felizmente, por ejemplo: del problema de crear cuentas por cobrar por morosidad no me preocupo, porque ya eso lo proporciona el componente del sistema financiero. Me concentrar en crear este subsistema con estos componentes.

205

DESPLEGANDO LA SOLUCIN La Ingeniera de Sistemas no abarca solamente el software. Nos hemos enfocado, durante el desarrollo de este material, en el tema de la Ingeniera de Software en el proceso de ir solucionando uno de los aspectos ms crticos e inciertos en los sistemas basados en computadoras. Sin embargo, el software que se desarrolla y pasa sus pruebas, debe integrarse con los otros elementos que integran la solucin. De acuerdo con Pressman (2005), los elementos de un sistema basado en computadora se constituyen en: hardware, software, base de datos, documentacin, gente y procedimientos. El ingeniero de sistemas debe construir una solucin dando una definicin y solucin para cada uno de estos elementos. Note que el desarrollo que se hace usando el Proceso Unificado mediante UML, ayuda dar soluciones en la Ingeniera de Sistemas. Elemento del sistema basado en computadora Hardware Software Bases de datos Gente Documentacin Desarrollo usando UP y UML Utilizacin de los diagramas de despliegue para definir los equipos de hardware que se usarn en la solucin. Definicin de los modelos de anlisis y diseo para la codificacin de la solucin Definicin de las necesidades de persistencia de los objetos en una base de datos. Diagramas de despliegue. Definicin de los actores humanos en la interaccin con el software. Documentacin tcnica y del mbito del negocio (incluyendo los modelos creados en UML y los casos de uso, respectivamente). Muchas herramientas proveen la facilidad de generar automticamente, documentacin tcnica relacionada con los modelos creados. Los casos de uso pueden documentar aspectos de los procedimientos existentes en el negocio (o los nuevos que modifican los actuales a partir de la creacin del sistema desarrollado)

Procedimientos

Tabla N 10. Ejemplos de cmo aporta el UP usando UML en la Ingeniera de Sistemas.

Tal como se menciona en la tabla anterior para el caso de la Documentacin, hay herramientas que manejan el UML que facilitan el proceso de generacin de documentacin tcnica.

206

Por ejemplo, en el caso de la herramienta Power Designer, puede crearse un documento a partir de los modelos creados. Vemos en la siguiente figura el ambiente de desarrollo de la documentacin en esta herramienta.

Figura 66. Ambiente para creacin automtica de la documentacin tcnica del sistema en Power Designer.

En la Figura 66 podemos notar las facilidades que proporcionan las herramientas hoy en da para el proceso de desarrollo y documentacin. Un documento se genera a partir de la estructura que el Ingeniero determine. Un trmino nuevo que se aprecia en la Tabla N 9, es con respecto a los llamados Diagramas de despliegue. Este tipo de diagramas, perteneciente tambin a la amplia familia de diagramas de UML, viene a apoyar la labor de la Ingeniera de Sistemas.

207

Elementos de un diagrama de despliegue Los diagramas de despliegue presentan los siguientes elementos: Smbolo Nombre Procesador Propsito Representa equipos de hardware con capacidad de procesamiento computacional (por ejemplo una computadora personal o un servidor). Simboliza equipos de hardware sin capacidad de procesamiento (por ejemplo, un MODEM, dispositivos de red, entre otros).

Dispositivo

Representa el hardware que Conector (la lnea conecta dos equipos cualquiera slida que (procesadores o dispositivos). conecta) Estos pueden ser conectores directos (por ejemplo cables de red) o indirectos (conexiones satelitales, celulares, etc.).
Figura 67. Elementos de un diagrama de despliegue.

Construyendo un diagrama de despliegue La elaboracin de un diagrama de despliegue debe apoyar la documentacin de la disposicin de los elementos del sistema por ejemplo elementos de software - en equipos de hardware particulares. De igual forma, debe ayudarnos a visualizar qu conexiones deben realizarse para que la solucin pueda funcionar. En otras palabras, estamos desplegando, visualmente, la arquitectura de equipos requeridos en la solucin. Al respecto podemos hacernos preguntas como: la solucin deber funcionar solo en la Intranet o tambin en Internet? Responder en uno u otro sentido nos puede llevar a configurar necesidades distintas de equipos. Por ejemplo, si la solucin solamente se usar en la Intranet, no nos preocuparemos por aspectos como tener un firewall o un servidor Web con certificado de seguridad. Podemos imaginar esta situacin para nuestro Sistema de Prstamo Bibliotecario: la solucin puede funcionar, tanto en Intranet, como en Internet. Para este ltimo escenario, podemos imaginar que la Universidad a la cual

208

pertenece la Biblioteca, tiene sedes regionales a las cuales, es difcil poder suministrarles un enlace privado11. La arquitectura n-capas nos puede ayudar en el proceso de construccin del diagrama de despliegue. En primera instancia podramos preguntarnos qu equipo de hardware necesitaremos para la interfaz, lo que comnmente llamamos, el equipo cliente (basado en la gran divisin de la arquitectura cliente/servidor). Podemos suponer que, tanto para la Intranet, como para Internet, se usar un equipo cliente representado por un Computador Personal (PC) que tenga un navegador Web. Este lo podramos representar as:
Cliente con Navegador

Figura 68. Equipo cliente del Sistema de Prstamo Bibliotecario.

Posteriormente tenemos que ver si este cliente est conectado directamente en la Intranet, o bien, debe pasar por un equipo especial de validacin, como un firewall. Ambos esquemas de conexin deben llevarnos a un servidor Web donde reside el Sistema de Prstamo Bibliotecario. Tal esquema lo podramos ver de la siguiente forma.

11

En este caso usted podr notar que la solucin que hemos modelado no tiene el concepto de Sede. Por lo tanto, nuestra Biblioteca tiene el modelo de una sola Biblioteca central. Para efectos de este ejemplo estamos imaginando que el Sistema Bibliotecario, como tal, puede tener varias bibliotecas y pueden gestionarse mediante el mismo sistema. Usted puede, como ejercicio, modificar los modelos que hemos realizado, de tal forma que incluya el concepto de Sede.

209

Cliente con Navegador Internet Red local Institucional Red Local Institucional Servidor Web Biblioteca

Firewall Universidad

Figura 69. Conexin hacia el Servidor Web de la Biblioteca desde Internet o Intranet.

Vemos cmo el equipo, si est en Intranet, se conecta al Servidor Web Biblioteca, donde reside el sistema, a travs de la red local institucional. No obstante, si est en Internet, se usa esta red para que, en primera instancia vaya a un firewall, el cual resuelve la peticin y traduce el direccionamiento externo a un direccionamiento interno hacia el Servidor Web de la Biblioteca12. Como parte de la solucin, debemos considerar que nuestro sistema debe resolver aspectos relacionados con la base de datos (toda arquitectura de un sistema debe proporcionarnos una capa que interacte con el servidor de base de datos que le da persistencia a la solucin). Por lo tanto, a la Figura 69 le aadimos un equipo adicional, el cual representa el servidor de base de datos del Sistema de Prstamo Bibliotecario13:

12

El esquema que se presenta aqu puede ser mucho ms complejo. En s la temtica de las conexiones desde Internet hacia los sistemas es muy amplio debido a la vulnerabilidad existente. Algunos equipos que pueden presentarse, como los firewall, los servidores seguros y otros, no necesariamente son equipos de hardware como tales, sino que son equipos de software o middleware especializados en seguridad y que podran estar en un mismo equipo de hardware (puede darse, aunque no es recomendable, que est en el mismo servidor Web donde estn las aplicaciones). Sin embargo, es ms fcil visualizarlos como dispositivos, tal como se muestra en la figura. El diagrama de despliegue podra ser mucho ms preciso e identificar los equipos que albergarn software o middleware como los certificados de servidor seguro o un firewall. 13 Es necesario tambin reflexionar sobre lo siguiente: no necesariamente tendremos dentro de la infraestructura de una organizacin, un equipo especializado para cada una de las bases de datos que se vayan creando. Muchas veces tendremos conviviendo, en un mismo hardware distintas bases de datos de distintos sistemas. Sin embargo, para los efectos, en el diagrama de despliegue debemos identificar como tal el equipo en el que reside una base de datos particular. En el nombre de la caja que se representa, pueden adicionarse mayor informacin, como el nombre de la base de datos y del equipo.

210

Cliente con Navegador Firewall Universidad Internet Red local Institucional Red Local Institucional Servidor Web Biblioteca

Red Local Biblioteca

Servidor de Base de datos

Figura 70. Diagrama de despliegue del Sistema de Prstamo Bibliotecario.

En el esquema tenemos representados los elementos ms importantes de la solucin desplegados en equipos de hardware particulares. Note que en mucho puede aplicarse a una arquitectura en 3 capas vista en la Figura 32 del Captulo 3. Sin embargo, el Servidor Web de la Biblioteca, puede contener los objetos para las capas de interfaz y de gestin. La divisin en n-capas pasa, en algunos casos, por una divisin lgica ms que fsica en cuanto a equipos de hardware. Adicionalmente podemos pensar que el Sistema de Prstamo Bibliotecario debe interactuar con el Sistema Financiero de la Universidad. Por ejemplo, un caso de morosidad debe generar una cuenta por cobrar al Usuario involucrado y, si este cancela la mora, el Sistema Financiero debe comunicar al Sistema Biblliotecario que dicho Usuario ha dejado de estar moroso. Tal comunicacin puede darse mediante Web Services dentro de la Intranet de la Universidad, por lo cual se usara la red local institucional.

211

Cliente con Navegador Internet

Firewall Universidad

Red local Institucional Red Local Institucional Servidor Web Biblioteca Red Local Institucional Servidor Web Financiero

Red Local Biblioteca

Servidor de Base de datos

Figura 71. Diagrama de despliegue del Sistema de Prstamo Bibliotecario integrando el

Sistema Financiero.

Note brevemente un dato que puede ser importante en la Figura 71. La conexin entre el Servidor Web de la Biblioteca y el Servidor de Base de Datos se hace mediante la Red Local de la Biblioteca. Esto significa, eventualmente, que los equipos principales de este sistema residen en la Biblioteca, por lo cual debe suponerse que la administracin de los equipos recaer en esta dependencia. No puede hacerse un juicio, a priori, si esto es conveniente o no. Todo depender de las polticas que cada organizacin puede tener al respecto, lo cual es tema de los cursos relacionados con la Administracin de la Funcin de la Tecnologa de Informacin. Por ltimo, va a incluirse un dispositivo que es importante en nuestra solucin y que da mucha agilidad al sistema: el lector de cdigo de barras, el cual se comunica directamente con el equipo cliente. Con ello podemos tener una visin global de la estructuracin de la solucin en los distintos equipos de hardware involucrados.

212

Cliente con Navegador Firewall Universidad Internet

Conector

Lector Cdigo Barras

Red local Institucional Red Local Institucional Servidor Web Red Local Institucional Servidor Web Biblioteca Financiero

Red Local Biblioteca

Servidor de Base de datos

Figura 72. Diagrama de despliegue del Sistema de Prstamo Bibliotecario completo.

El conector del equipo cliente al lector de cdigo de barras debe ser un cable directo a un puerto especfico de dicho equipo. COMPLETANDO EL PROCESO DE TRANSICIN Con la visin arquitectnica de los diagramas de despliegue completamos, tambin, la apreciacin acerca de elementos importantes necesarios en el sistema, como es el caso del hardware, software del sistema (servidores de bases de datos, servidores web, firewlall). Puede verse, de lo tratado anteriormente, que las pruebas de unidad y de integracin, casi en su totalidad, se centran en comprobar lo correcto del comportamiento del software. No obstante los otros elementos del sistema involucrados, el hardware, los procedimientos, la documentacin e incluso la gente, deben ser probados en su actuar conjunto para poder sacar a la luz el producto. Aspectos relacionados con la capacitacin y adopcin del producto, dentro de los responsables del proceso de uso del software y los procedimientos involucrados, son consideraciones que debemos tener con respecto a la gente. En ello, la documentacin (descripcin de procedimientos, manuales de usuario y tcnico), ser fundamental. 213

Por otra parte, debe probarse la interaccin del software codificado, producto del proceso de Anlisis y Diseo, con el hardware involucrado, con el software de sistema (servidor web y otros). Con ello debe completarse lo que en la Tabla N 8 vimos como pruebas de sistema. De forma resumida podemos ver cunto aporta el desarrollo a travs del Proceso Unificado, usando UML, en cada uno de los tipos de pruebas que deben realizarse. Tipo de prueba Prueba de unidad Modelos en UML usados Diagrama de actividad: especificacin algortmica de una operacin. Modelo de clases: especificacin de todas las operaciones en cada una de las clases. Diagramas de estado: garantizar que las operaciones respeten las transacciones vlidas definidas. Modelo de clases: asociacin entre clases. Diagramas de secuencia: interaccin entre objetos de distintas clases para cumplir un caso de uso. Diagramas de actividad: cuando se usan para documentar el detalle de un caso de uso. Casos de uso: definicin de los objetivos del sistema en los cuales las distintas piezas de software deben integrarse para cumplir tales objetivos. Diagramas de despliegue: definicin de los elementos de hardware requeridos para poner en funcionamiento el sistema. Diagramas de casos de uso: definicin de roles de la gente, definicin de procedimientos del negocio. Modelos de UML creados: documentacin tcnica.

Pruebas de integracin

Pruebas del sistema

Tabla N 11. Relacin entre los distintos tipos de pruebas y los modelos creados en el desarrollo del sistema.

Todos los modelos nos dan planos, tanto para la construccin del software y del sistema en general, pero al igual, con los mismos planos corroboramos que lo construdo corresponda a la exigencia de lo solicitado. No debe olvidar que no solo debemos limitarnos a los requerimientos funcionales, es decir los que son producto de los que especificamos al lado de los clientes, sino que, adems, debemos considerar los llamados requerimientos no funcionales. Por ejemplo, garantizar que las transacciones sean registradas completas y de forma eficiente no es algo que nos dir el cliente, sino que es obligacin nuestra, como ingenieros, que esto se cumpla. Al terminar todas las comprobaciones, en los distintos niveles de pruebas, podemos cumplir con los requerimientos de la fase de transicin, con lo cual el sistema puede pasar a produccin.

214

CONCLUSIONES Hemos hecho un largo recorrido, muy largo, tocando distintos trabajos que se realizan en la Ingeniera de Software, basados en los principios del Proceso Unificado usando UML y el Anlisis y Diseo Orientado a Objetos. Este libro es introductorio a todas estas tcnicas. Se ha tratado de abordar de forma inductiva, los procesos mediante los cuales se va creando la solucin, usando los diagramas provistos por UML y aprovechando, de igual forma, las ventajas del Paradigma de Orientacin a Objetos. Como tal es un proceso complejo, pero la complejidad, como se ha tratado de evidenciar, debe quedar en su capacidad de diseador como ingeniero. Las herramientas de software y el UML, facilitan este proceso. Los modelos creados, a su vez, tienen una correspondencia directa en las clases que deben definirse en la programacin del sistema. Por ello su esfuerzo, como ingeniero, se ver facilitado con el dominio de estas tcnicas. Cada vez menos, los profesionales en desarrollo de software debemos a recurrir a metodologas poco claras y al uso de monedas para hacer burbujitas, como en el anlisis estructurado, y que fue la experiencia que en mis primeros aos viv personalmente. Temas ms avanzados en estas mismas tecnologas, debern facilitarse mediante el estudio de este libro. Para ello, ya se tiene el marco necesario para abordar temticas como el desarrollo de componentes, desarrollo en tecnologas Web y arquitecturas orientadas a servicio.

215

EJERCICIOS DE AUTOEVALUACIN 1. Justifique la importancia de los casos de uso para poder tener pruebas de unidad y de integracin. 2. Indique qu importancia tiene el modelo de clases para las pruebas de unidad? 3. Indique y justifique en qu procesos de prueba pueden servir: a) los diagramas secuencia, b) los diagramas de actividad c) los diagramas de estado. 4. Describa en qu medida pueden los componentes facilitar: a. La integracin de piezas de software. b. Las pruebas de software en distintos niveles. c. La elaboracin de la arquitectura del sistema. 5. Describa cmo el Proceso Unificado usando UML aporta en la definicin de los elementos de un Sistema Basado en Computadora. 6. Para el Sistema de Reservacin de Espectculos en Lnea realice lo siguiente. a. Indique qu diagramas pueden apoyar las pruebas de unidad. Ilustre con dos ejemplos de distintos tipos de diagrama. b. Lo mismo que en a.), pero para pruebas de integracin. Esta vez ilustre con cuatro ejemplos. c. Defina dos componentes con sus interfaces y clases que lo integran. Justifique su eleccin. Indique cmo se acoplan esos dos componentes. d. Construya el diagrama de despliegue del sistema. e. Identifique los distintos elementos del Sistema Basado en Computadora para este sistema particular, a partir del trabajo elaborado en el proceso usando Proceso Unificado y UML. 7. Ejercicio prctico El ejercicio que presentamos a continuacin pretende que aplique, de manera prctica e integral, los conocimientos adquiridos durante este curso. En l fuimos introduciendo, poco a poco, muchos de los modelos de UML en ciertos procesos de Anlisis o de Diseo de software. Mencionamos, igualmente, que tales diagramas y tcnicas no son exclusivos de las fases en que se estudiaron

216

y que, en problemas que se enfrentan en la Ingeniera de Software, pueden usarse de forma conveniente. Considere el siguiente caso. Una empresa dedicada al la prensa escrita, dada su cantidad de productos y la complejidad de procesos, ha decidido incorporar una serie de soluciones de software para apoyar la ejecucin de sus tareas. Algunos de estos procesos se describen a continuacin. - Produccin de noticias. Los periodistas ingresan las noticias que elaboran mediante un software que captura el texto y las imgenes (que un fotgrafo haya hecho con relacin a los acontecimientos). Las noticias deben pasar, primero por un proceso de correccin de estilo, el cual realiza un grupo de fillogos a los cuales el sistema les asigna una tarea especfica. Luego, un editor, las agrupa en sucesos, deportes, reportajes, finanzas, etc., segn corresponda y las clasifica segn la importancia que tienen (primera plana, prxima edicin, baja prioridad, etc.) y un diseador grfico realiza la diagramacin, para finalmente enviarlas al proceso de reproduccin. Este proceso incorpora, de forma digital, el diseo del peridico que hacen los diseadores. La rotativa, que imprime los peridicos, realiza la reproduccin de acuerdo con dicho diseo. - Produccin de suplementos. Se sigue un proceso semejante al de las noticias. El suplemento, que se imprime semanalmente, puede estar producindose todos los das, sin que ello signifique que la planta de produccin lo considere para el tiraje. Solamente el da que corresponda, se har el tiraje de un suplemento. Pueden existir suplementos o insertos publicitarios que solo se distribuyen en un rea determinada. - Distribucin de peridicos. Conforme la planta de produccin hace el tiraje, se crean los paquetes que deben distribuirse. Estos se agrupan en el tiraje, de acuerdo con parmetros tales como:

rea de distribucin. Corresponde al rea encargada de clasificarlos

segn las regiones a las que van (por ejemplo que tengan un suplemento o insertos dirigidos para ciertas reas geogrficas). Cantidad de suscriptores. Corresponde al responsable que le da al software que administra la planta de produccin de tiraje, un parmetro de cantidad que se une con otros parmetros como el de rea de distribucin.

217

Estimacin de ventas por regin. Cada agencia enva al sistema, un

resumen semanal de las ventas por da, as como la cantidad de las suscripciones activos. Con dicho parmetro, el sistema calcula una estimacin de ventas para lograr un tiraje ajustado a la cantidad de ventas que se espera tener, adems de las suscripciones.

obtenidos por suscripciones y ventas depositadas en los bancos y las dems agencias que manejan la recaudacin. Este ingreso se registra en el sistema financiero. Debe considerarse que la planta de produccin tiene incorporado un software que permite realizar tirajes de un diseo de los productos que se hayan incorporado. Este tiraje lo hace de acuerdo con una fecha especfica. El diseo se elabora de acuerdo con las notas que cada periodista realiza. Las notas son elaboradas desde sus estaciones de trabajo. El peridico tiene varias agencias en el pas con el fin de que: a) Los periodistas o corresponsales que estn en las regiones puedan ingresar sus noticias. Para ello la solucin de software que debe capturar las noticias debe tener una interfaz en tecnologa Web, para dotar al peridico de una Intranet (la cual aprovecha la red de Internet) que permita realizar tales trabajos. Se tramiten suscripciones y aspectos relacionados con la distribucin local de peridicos. Se tramiten aspectos de publicidad en el peridico.

Recaudacin de suscripciones y ventas. El sistema refleja los ingresos

b) c)

Con esta informacin, su trabajo consiste en realizar lo siguiente, teniendo en cuenta las fases del Proceso Unificado.

Fase de inicio
a) Definir los casos de uso crticos. Determine los casos de uso que considere son los ms importantes de resolver para la Empresa. Estos casos de uso son los que, mayormente, definiran los elementos de software ms relevantes de la capa de negocios. Definir una arquitectura de subsistemas de la solucin. Para ello establezca un diagrama de componentes y una distribucin en capas de la solucin requerida. Considere para ello, todo el hardware y software especializado que pueda identificar. Elaborar una distribucin inicial de tareas, de acuerdo con las fases y procesos que se desarrollan en el Proceso Unificado.

b)

c)

218

Fase de Elaboracin
Defina el diagrama de casos de uso del sistema. a) b) c) d) e) Desarrolle la especificacin de los casos de uso ms importantes, tanto bsica como detallada. Elija un caso de uso de los identificados como ms importante y elabore un diagrama de clases conceptual. Compruebe la definicin de las operaciones de las clases usando diagramas de secuencia y de actividad para documentar los casos de uso. Elija otro caso de uso importante y actualice el modelo de clases conceptual. Verifique las relaciones entre clases y las operaciones mediante tarjetas CRC para cada una de las clases definidas.

Fase de construccin
a) b) c) d) Retome el modelo conceptual de clases que hizo en la fase anterior y transfrmelo en un diagrama de clases de diseo para la capa de negocios. Elabore las capas de clases de diseo para la interfaz y la gestin. Documente los procesos de los gestores usando diagramas de secuencia para cada uno de los procesos que manejen los gestores. Defina los componentes correspondientes de acuerdo con criterios de cohesin y acoplamiento para los mdulos identificados. Guese por la definicin de subsistemas identificados en la fase de inicio.

Fase de transicin
a) b) Elabore el diagrama de despliegue de la solucin. Elabore un plan de pruebas para dos de los componentes identificados.

219

BIBLIOGRAFA (Booch et al, 2001) Booch, G; Jacobson, I; Rumbaugh, J. El Proceso Unificado de desarrollo de software. Addison Wesley / Pearson Educacin, Espaa. (Fowler, 1999) Fowler, M; Kendall, S. UML gota a gota. Pearson Educacin, Mxico. (Hall, 2001) Hall, M. Servlets y Java Server Pages. Gua Prctica. Pearson Educacin, Mxico. (Larman, 2003) Larman, C. UML y patrones. Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. Segunda edicin. Pearson Educacin. Mxico. (Laudon, 2004) Laudon, K; Laudon, J. Sistemas de informacin gerencial. Octava edicin. Pearson Educacin, Mxico. (McConnell, 1997) McConnell, S. Desarrollo y gestin de proyectos informticos. McGraw-Hill Interamericana de Espaa, Espaa. (Pressman, 2005) Pressman, R. Ingeniera del software. Un enfoque prctico. McGraw-Hill Interamericana, Mxico. (Quatrani, 1998) Quatrani, T. Visual modelling with Rational Rose and UML. Addison Wesley, Estados Unidos

220