Análisis y Diseño de Sistemas con UML by Omar Torres

Universidad Católica "Redemptoris Mater" Facultad de Ingeniería y Arquitectura Escuela de Ingeniería en Sistemas de Información

Proyecto Monográfico Análisis y Diseño de Sistemas con el Lenguaje de Modelaje Unificado (UML)

Integrantes Randall Agenor Herrera Briones Roderick Javier Caldera Obregón Manuel de Jesús Martínez Dávila

Abril de 1999

A Nuestros Padres

Tabla de Contenidos Introducción .......................................................................................................... xvii Presentación........................................................................................................................... xix Antecedentes........................................................................................................................... xx Justificación .......................................................................................................................... xxii Objetivos ............................................................................................................................... xxiii Alcances y Restricciones.................................................................................................... xxiv

Capítulo 1: ¿Qué es el UML?.................................................................................... 1 El Lenguaje de Modelaje Unificado ......................................................................................... 4 La Guerra de los Métodos.............................................................................................. 5 Surgimiento del UML...................................................................................................... 6 Aceptación del Lenguaje y Estandarización OMG......................................................... 8 Metas del UML ............................................................................................................... 9 Métodos y Lenguajes de Modelaje ........................................................................................ 10 Desarrollo de Software Orientado a Objetos ....................................................................... 11 Uso del UML............................................................................................................................. 11 Diferentes tipos de sistemas ........................................................................................ 11 Ingeniería del Negocio ................................................................................................. 12

Capítulo 2: Un Vistazo al UML................................................................................ 13 Vistas........................................................................................................................................ 15 Diagramas ................................................................................................................................ 16 Diagrama de Casos de Uso ......................................................................................... 16 Diagrama de Clases..................................................................................................... 17 Diagrama de Objetos ................................................................................................... 17 Diagrama de Estados................................................................................................... 17 Diagrama de Secuencia............................................................................................... 18 Diagrama de Colaboración .......................................................................................... 18 Diagrama de Actividades ............................................................................................. 18 Diagrama de Componentes ......................................................................................... 19 Diagrama de Despliegue.............................................................................................. 19 Elementos del Modelo ............................................................................................................ 19 Mecanismos Generales .......................................................................................................... 21 Adornos ........................................................................................................................ 21 Notas ............................................................................................................................ 21 Especificaciones........................................................................................................... 22 Extensión del UML .................................................................................................................. 22 Estereotipos ................................................................................................................. 22 Valores Agregados....................................................................................................... 23 Restricciones................................................................................................................ 24 Modelaje con el UML............................................................................................................... 24 Herramientas ........................................................................................................................... 26 Soporte Para Dibujos ................................................................................................... 27 Repositorio de Modelos ............................................................................................... 28 Navegación .................................................................................................................. 28 Soporte Multiusuario .................................................................................................... 29 Generación de Código ................................................................................................. 29 Ingeniería Reversa ....................................................................................................... 29 Integración.................................................................................................................... 30 Intercambio de Modelos............................................................................................... 31

Capítulo 3: Proceso Unificado ............................................................................... 33 ¿Qué es el Proceso Unificado? ............................................................................................. 35 Un Vistazo del Proceso .......................................................................................................... 36

Página viii

Análisis y Diseño de Sistemas con el UML

Fases e Iteraciones ................................................................................................................. 37 Fase de Inicio ............................................................................................................... 37 Fase de Elaboración..................................................................................................... 38 Fase de Construcción .................................................................................................. 44 Fase de Transición ....................................................................................................... 47 Iteraciones .................................................................................................................... 47 Componentes del Proceso ..................................................................................................... 47 Componentes del Proceso y Modelos.......................................................................... 48 Captura de Requerimientos ......................................................................................... 48 Análisis y Diseño .......................................................................................................... 49 Implementación ............................................................................................................ 50 Prueba .......................................................................................................................... 51 Características del Proceso Unificado.................................................................................. 52 Tecnología de Objetos ................................................................................................. 52 Desarrollo conducido por Casos de Uso...................................................................... 52 Desarrollo Iterativo Controlado..................................................................................... 53 Administración de Requerimientos............................................................................... 54 Un fuerte énfasis en la arquitectura ............................................................................. 54 Desarrollo basado en componentes............................................................................. 55 Configurabilidad del proceso........................................................................................ 55

Capítulo 4: Creando Casos de Uso........................................................................ 57 Sistema..................................................................................................................................... 60 Actores ..................................................................................................................................... 61 Identificación de los actores ......................................................................................... 62 Relaciones entre los actores ........................................................................................ 63 Documentación de los actores ..................................................................................... 64 Casos de Uso........................................................................................................................... 64 Identificación de los casos de uso................................................................................ 64 Documentación de los casos de uso............................................................................ 65 Relaciones entre los casos de uso............................................................................... 70 Probando los casos de uso .......................................................................................... 71 Metas del usuario e interacciones del sistema ............................................................ 72

Capítulo 5: Encontrando Clases ............................................................................ 73 ¿Qué es un Objeto? ................................................................................................................ 75 Objetos por referencia.................................................................................................. 75 Objetos por valor .......................................................................................................... 76 ¿Qué es una Clase? ................................................................................................................ 76 Clases y Estereotipos................................................................................................... 77 Identificación de las Clases.......................................................................................... 78 Documentación de las clases....................................................................................... 80 Paquetes................................................................................................................................... 80 Clases Parametrizadas ........................................................................................................... 81 Perspectivas ............................................................................................................................ 82

Capítulo 6: Descubriendo Interacción entre los Objetos ..................................... 83 Realización de los casos de uso ........................................................................................... 85 Documentando los escenarios .............................................................................................. 87 Interacciones entre los objetos ............................................................................................. 87 Comparando los tres diagramas diferentes ......................................................................... 88 Diagramas de secuencia ........................................................................................................ 88 Condiciones e Iteración................................................................................................ 90 Etiquetas que definen restricciones y comentarios...................................................... 90 Creado y destruyendo objetos ..................................................................................... 91 Recursión ..................................................................................................................... 92 Forma genérica e instanciada ...................................................................................... 92 Diagramas de secuencia y clases de frontera ............................................................. 93

Tabla de Contenidos

Página ix

Complejidad y diagramas de secuencia ...................................................................... 93 Diagramas de colaboración ................................................................................................... 93 Flujo de mensajes ........................................................................................................ 94 Enlaces......................................................................................................................... 96 Tiempo de vida de un objeto........................................................................................ 96

Capítulo 7: Especificando Relaciones................................................................... 97 Asociaciones ........................................................................................................................... 99 Nombrando relaciones ........................................................................................................... 99 Nombres de roles .................................................................................................................. 100 Indicadores de multiplicidad................................................................................................ 100 Relaciones recursivas .......................................................................................................... 101 Asociación calificada............................................................................................................ 101 Asociación “O”...................................................................................................................... 102 Asociación ordenada ............................................................................................................ 102 Asociación ternaria ............................................................................................................... 103 Agregaciones......................................................................................................................... 103 ¿Asociación o agregación? ................................................................................................. 104 Encontrando relaciones ....................................................................................................... 104 Relaciones entre paquetes................................................................................................... 105

Capítulo 8: Añadiendo Comportamiento y Estructura....................................... 107 Creando operaciones............................................................................................................ 109 Documentando las operaciones.......................................................................................... 110 Relaciones y signaturas de las operaciones ..................................................................... 110 Creando atributos ................................................................................................................. 110 Documentado los atributos.................................................................................................. 110 Clases en asociación ............................................................................................................ 110

Capítulo 9: Descubriendo Herencia..................................................................... 113 Generalización y Especialización........................................................................................ 115 Arboles de herencia .............................................................................................................. 116 Herencia simple contra herencia múltiple.......................................................................... 116 Instanciación y Generalización............................................................................................ 116

Capítulo 10: Analizando el Comportamiento de los Objetos ............................ 119 Diagramas de Estados.......................................................................................................... 121 Estados y transiciones ............................................................................................... 121 Detalles de los estados .............................................................................................. 123 Detalles de la transición de estados .......................................................................... 124 Eventos ...................................................................................................................... 126 Enviando mensajes entre diagramas de estado........................................................ 127 Subestados ................................................................................................................ 128 Indicador de historia................................................................................................... 129 Diagramas de Actividades ................................................................................................... 130 Acciones y transiciones.............................................................................................. 131 Swimlanes .................................................................................................................. 134 Objetos ....................................................................................................................... 135 Señales ...................................................................................................................... 135 Modelaje de negocios con diagramas de actividad ................................................... 136

Capítulo 11: Revisando el Modelo ....................................................................... 139 Combinando clases .............................................................................................................. 141 Dividiendo clases .................................................................................................................. 141 Eliminando clases ................................................................................................................. 141 Revisión de la consistencia ................................................................................................. 142 Recorrido de los escenarios ................................................................................................ 142 Trazado de eventos............................................................................................................... 142 Revisión de la documentación ............................................................................................ 142

Capítulo 12: Diseño del Sistema .......................................................................... 143

Página x

Análisis y Diseño de Sistemas con el UML

Añadiendo clases de diseño ................................................................................................ 145 Diseñando la interfaz del usuario ........................................................................................ 145 Diseñando las relaciones ..................................................................................................... 146 Navegación................................................................................................................. 146 Contenimiento por valor (Composición) ..................................................................... 146 Dependencia y Refinamiento ..................................................................................... 147 Implementación de la multiplicidad ............................................................................ 148 Diseñando atributos y operaciones .................................................................................... 148 Atributos ..................................................................................................................... 148 Operaciones ............................................................................................................... 150 Usando tipos primitivos .............................................................................................. 151 Sutilezas en los lenguajes de programación.............................................................. 152 Diseñando la herencia .......................................................................................................... 153 Interfaces................................................................................................................................ 153 Clases abstractas .................................................................................................................. 155 Restricciones y Derivaciones .............................................................................................. 155 Atributos y asociaciones restringidos y derivados ..................................................... 155 Restricciones en la generalización............................................................................. 157 La emergencia de patrones.................................................................................................. 159

Capítulo 13: Arquitectura del Sistema................................................................. 161 La necesidad de arquitectura............................................................................................... 163 El equipo de arquitectura ..................................................................................................... 164 La vista de arquitectura “4 + 1” ........................................................................................... 165 La vista de casos de uso............................................................................................ 165 La vista lógica............................................................................................................. 166 La vista de componentes ........................................................................................... 166 La vista de procesos .................................................................................................. 168 La vista de despliegue................................................................................................ 168 Arquitectura lógica................................................................................................................ 169 Arquitectura física ................................................................................................................. 170 Hardware .................................................................................................................... 170 Software ..................................................................................................................... 171 Diagramas de componentes ................................................................................................ 172 Componentes fuentes ................................................................................................ 173 Componentes de tiempo de enlace............................................................................ 174 Componentes de tiempo de ejecución ....................................................................... 174 Diagramas de despliegue ..................................................................................................... 175 Nodos ......................................................................................................................... 175 Conexiones................................................................................................................. 176 Componentes ............................................................................................................. 176 Objetos ....................................................................................................................... 177 Modelaje complejo de nodos...................................................................................... 178 Asignando componentes a los nodos ........................................................................ 179 Construyendo las iteraciones .............................................................................................. 180 El proceso de planeación de las iteraciones.............................................................. 180 Codificando, probando, y documentado la iteración .................................................. 180

Capítulo 14: Caso de Estudio ............................................................................... 183 Requerimientos del Sistema ................................................................................................ 185 Análisis de Requerimientos ................................................................................................. 187 Análisis................................................................................................................................... 196 Diseño..................................................................................................................................... 201 Implementación ..................................................................................................................... 205 Pruebas y Despliegue ........................................................................................................... 205

Conclusiones ......................................................................................................... 207 Bibliografía............................................................................................................. 211

Tabla de Contenidos

Página xi

Anexo A: Calidad en los Modelos........................................................................ 215 Anexo B: Refactorización..................................................................................... 219 Anexo C: Diseño por Contrato............................................................................. 223 Anexo D: Comparando el UML con otros lenguajes de modelaje .................... 227 UML y otros Lenguajes de Modelaje ................................................................................... 229 Actualizándose de OMT........................................................................................................ 231 Proceso ...................................................................................................................... 231 Notación ..................................................................................................................... 232

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real ................ 239 Orientación a Objetos y los Sistemas de Tiempo Real ..................................................... 242 Conceptos de Tiempo Real .................................................................................................. 244 Clases Activas y Objetos ........................................................................................... 244 Comunicación............................................................................................................. 246 Sincronización ............................................................................................................ 250 Modelaje de Tiempo Real en el UML ................................................................................... 253 Diagrama de Estados................................................................................................. 256 Diagrama de Secuencia............................................................................................. 258 Diagrama de Colaboración ........................................................................................ 259 Diagrama de Actividades ........................................................................................... 261 Diagrama de Componentes y de Despliegue ............................................................ 262 Adaptándose a los Sistemas de Tiempo Real.................................................................... 263 Asuntos Especiales del Modelaje de Tiempo Real.................................................... 264 Problemas de los Procesos ................................................................................................. 266

Anexo F: Herramientas Utilizadas ....................................................................... 269 Rational Rose 98 ................................................................................................................... 271 Información sobre Rational Rose 98.......................................................................... 271 Que puede ofrecer Rose............................................................................................ 271 Familia de Productos ................................................................................................. 273 Valores y Características del Modelaje Visual con Rational Rose 98 ....................... 274 Oracle8 Server ....................................................................................................................... 274 La Base de Datos para Network Computing.............................................................. 275 Base de Datos Objeto-Relacional .............................................................................. 276 Oracle8 Server y Año 2000........................................................................................ 279 Oracle Developer/2000.......................................................................................................... 281 Productividad.............................................................................................................. 281 Escalabilidad Cliente-Servidor ................................................................................... 282 Portabilidad ................................................................................................................ 282 Edición y Depuración Cliente-Servidor Unificada ...................................................... 282 Soporte Completo a Interfaces Gráficas (GUI) .......................................................... 282 Desarrollo en Equipo.................................................................................................. 283 Acceso a Datos Heterogéneos .................................................................................. 283 Oracle Developer/2000 y Año 2000 ........................................................................... 283

Indice de Figuras Figura 1: Arbol genealógico del UML.......................................................................................................8 Figura 2: Algunos elementos comunes de modelaje .............................................................................20 Figura 3: Ejemplos de relaciones...........................................................................................................20 Figura 4: Una nota contiene cualquier información adicional, tales como comentarios simples...........21 Figura 5: Una ventana de especificaciones en una herramienta CASE que muestra las propiedades de la clase .................................................................................................................................22 Figura 6: Un cliente es una clase con el estereotipo <<Actor>>. El estereotipo añade semántica adicional a la clase; en este caso, que la clase representa un usuario externo del sistema ...23 Figura 7: Propiedades de una clase instrumento. Abstract es una propiedad predefinida; autor y estado son valores agregados definidos por el usuario............................................................24 Figura 8: Una restricción sobre que objetos personas pueden participar en la asociación ..................24 Figura 9: Un proceso de trabajo práctico de modelaje ..........................................................................25 Figura 10: Desarrollo Iterativo e Incremental .........................................................................................35 Figura 11: Vista de alto nivel del proceso ..............................................................................................36 Figura 12: Dimensiones del Proceso Unificado .....................................................................................37 Figura 13: Relación de los componentes de proceso y modelos ..........................................................48 Figura 14: El flujo de trabajo en la captura de requerimientos, mostrado en términos de trabajadores y sus actividades. Las flechas indican un orden lógico entre las actividades .............................49 Figura 15: El flujo de trabajo en el análisis y diseño, descrito en términos de trabajadores y sus actividades. Las flechas indican un flujo lógico entre las actividades ......................................50 Figura 16: El flujo de trabajo en la implementación, mostrado en términos de trabajadores y sus actividades. Las flechas indican un orden lógico entre las actividades....................................51 Figura 17: El flujo de trabajo en la Prueba, mostrado en términos de trabajadores y sus actividades. Las flechas indican un orden lógico entre las actividades ........................................................52 Figura 18: Un sistema en un modelo de casos de uso..........................................................................60 Figura 19: Notación en el UML para un actor ........................................................................................61 Figura 20: Generalización entre actores ................................................................................................63 Figura 21: Notación del UML para un caso de uso................................................................................64 Figura 22: Un diagrama de actividades usado para describir interacción entre el actor y el caso de uso (comprar bebida) .......................................................................................................................69 Figura 23: Relaciones en los Casos de Uso ..........................................................................................71 Figura 24: Notación del UML para un Objeto.........................................................................................75 Figura 25: Una clase en el UML.............................................................................................................77 Figura 26: Clase con un Estereotipo......................................................................................................78 Figura 27: Notación del UML para un Paquete......................................................................................81 Figura 28: Clase parametrizada y dos formas de mostrar clases instanciadas a partir de ella ............82 Figura 29: Realización de los casos de uso en colaboraciones ............................................................87 Figura 30: Notación de los tipos de mensajes .......................................................................................88 Figura 31: Nombrando objetos en un diagrama de secuencia ..............................................................89 Figura 32: Notación del UML para objetos y mensajes en un diagrama de secuencia.........................89 Figura 33: Condiciones e iteración en los mensajes .............................................................................90 Figura 34: Etiquetas que definen restricciones e iteraciones ................................................................91 Figura 35: Creación de un objeto...........................................................................................................91 Figura 36: Destrucción de un objeto ......................................................................................................92 Figura 37: Mensaje recursivo.................................................................................................................92 Figura 38: Diagrama de colaboración ....................................................................................................94 Figura 39: Iteración y valores de retorno mostrados en un diagrama de colaboración.........................95 Figura 40: Objetos creados y destruidos durante una colaboración .....................................................96 Figura 41: Notación del UML para una relación de asociación .............................................................99 Figura 42: Asociación nombrada ...........................................................................................................99 Figura 43: Nombres de rol....................................................................................................................100 Figura 44: Indicadores de multiplicidad................................................................................................100

Página xiv

Análisis y Diseño de Sistemas con el UML

Figura 45: Relación recursiva.............................................................................................................. 101 Figura 46: Asociación calificada.......................................................................................................... 101 Figura 47: Asociación “o”..................................................................................................................... 102 Figura 48: Asociación ordenada.......................................................................................................... 103 Figura 49: Asociación Ternaria ........................................................................................................... 103 Figura 50: Notación del UML para una relación de agregación.......................................................... 104 Figura 51: Agregación compartida ...................................................................................................... 104 Figura 52: Un diagrama de clase que describe un negocio de seguros............................................. 105 Figura 53: Relaciones entre paquetes ................................................................................................ 106 Figura 54: El paquete X contiene las clases P y S. El paquete A tiene una interfaz I. La clase S dentro del paquete X es dependiente de la interfaz I del paquete A ................................................ 106 Figura 55: Clase en asociación ........................................................................................................... 111 Figura 56: Promoviendo una Posible Clase en Asociación a una Clase Completa............................ 111 Figura 57: Notación del UML para la generalización (herencia) ......................................................... 116 Figura 58: Notación del UML para los estado de inicio y final ............................................................ 122 Figura 59: Notación del UML para un estado...................................................................................... 122 Figura 60: Estados y sus transiciones................................................................................................. 122 Figura 61: Compartimentos de los estados......................................................................................... 123 Figura 62: Detalles de los estados ...................................................................................................... 123 Figura 63: Detalles de la transición de estados .................................................................................. 126 Figura 64: Una jerarquía de clases señal con una superclase abstracta. .......................................... 127 Figura 65: Mensajes entre diagramas de estado................................................................................ 128 Figura 66: Subestados-o ..................................................................................................................... 128 Figura 67: Subestados-y ..................................................................................................................... 129 Figura 68: Indicador de historia........................................................................................................... 130 Figura 69: Diagrama de actividades con cláusula send, condiciones guardia y decisiones .............. 132 Figura 70: Transiciones ramificadas, iteración y condiciones en barras de sincronización ............... 133 Figura 71: Diagrama de actividades descompuesto para Autorizar Pago.......................................... 133 Figura 72: Swimlanes .......................................................................................................................... 134 Figura 73: Objeto como entrada y salida para acciones..................................................................... 135 Figura 74: : Envío y recepción de señales .......................................................................................... 136 Figura 75: Un patrón de negocios para manufactura descrito con un diagrama de actividad............ 138 Figura 76: Agregación unidireccional .................................................................................................. 146 Figura 77: Agregación y Composición ................................................................................................ 146 Figura 78: Relación de dependencia................................................................................................... 147 Figura 79: Relación de refinamiento ................................................................................................... 147 Figura 80: Clase con atributos con tipo............................................................................................... 148 Figura 81: Clase con atributos públicos y privados............................................................................. 148 Figura 82: Clase con atributo con valor por defecto ........................................................................... 149 Figura 83: Clase con atributo al nivel de clase.................................................................................... 149 Figura 84: Clase con un texto de propiedad (tipo de enumeración) ................................................... 149 Figura 85: Clase con atributos y operaciones ..................................................................................... 150 Figura 86: Clase con operación al nivel de clase................................................................................ 150 Figura 87: Clase con operaciones con valores por defecto en los parámetros .................................. 151 Figura 88: Combinación de herencia, agregación y clases abstractas............................................... 153 Figura 89: La clase A implementa las interfaces Runnable y Storable. La clase C implementa la interfaz Runnable. La clase B usa la interfaz Runnable y Storable de A, y Runnable de C.. 154 Figura 90: Asociación derivada ........................................................................................................... 156 Figura 91: Asociación restringida ........................................................................................................ 156 Figura 92: Atributos restringidos y derivados ...................................................................................... 156 Figura 93: Diferentes formas de mostrar restricciones en la herencia ............................................... 157 Figura 94: Generalización overlapping................................................................................................ 158 Figura 95: Generalización complete.................................................................................................... 158 Figura 96: La vista de arquitectura “4 + 1” .......................................................................................... 164 Figura 97: Capas de un sistema ......................................................................................................... 167

Indice de Figuras

Página xv

Figura 98: Arquitectura de tres capas en el UML mostrada como paquetes y dependencias entre ellos .................................................................................................................................................169 Figura 99: Notación del UML para un componente .............................................................................172 Figura 100: Diagrama de componente que muestra un número de componentes – fuente, binario y ejecutable – y sus dependencias ............................................................................................172 Figura 101: Interfaces y dependencias ................................................................................................173 Figura 102: Dependencias entre componentes de código fuente .......................................................174 Figura 103: Componentes de tiempo de ejecución .............................................................................174 Figura 104: Tipo nodo e instancia del mismo ......................................................................................175 Figura 105: Nodos de dispositivos y posibles estereotipos .................................................................175 Figura 106: Asociaciones de comunicación entre nodos.....................................................................176 Figura 107: Un tipo nodo soporta un tipo componente de tiempo de ejecución, y un componente de tiempo de ejecución se ejecuta en una instancia de nodo .....................................................176 Figura 108: Un objeto pasivo (de la clase Controlador de Termómetro dentro de un proceso activo (de la clase activa Supervisor) que vive dentro de una instancia de componente (de tipo guard.exe, que está asignada al sistema de horno de microondas (de tipo controlador de horno de microondas) .............................................................................................................177 Figura 109: Los objetos son asignados a nodos. El objeto transobj que originalmente existe en el Servidor Principal puede ser distribuido al nodo Dell PC .......................................................178 Figura 110: Relaciones entre nodos ....................................................................................................178 Figura 111: Diagrama de Casos de Uso – Principal del Sistema de Control de Rutas.......................190 Figura 112: Diagrama de Casos de Uso – Controlar Gastos en las Rutas .........................................190 Figura 113: Diagrama de Casos de Uso – Mantenimiento del Sistema ..............................................191 Figura 114: Diagrama de Casos de Uso – Acciones Generales .........................................................191 Figura 115: Diagrama de Casos de Uso – Reportes del Sistema .......................................................192 Figura 116: Paquetes del sistema en la Fase de Análisis ...................................................................199 Figura 117: Diagrama de secuencia para el escenario Añadir Ruta del caso de uso Datos de Rutas en la Fase de Análisis ..................................................................................................................199 Figura 118: Diagrama de Estados para la clase CalendarioMantenimiento........................................200 Figura 119: Paquetes del sistema en la etapa de diseño y sus dependencias ...................................201 Figura 120: Diagrama de Clases de Entidad en la Fase de Diseño....................................................202 Figura 121: Diagrama de secuencia para el escenario Añadir Ruta del caso de uso Datos de Rutas en la Fase de Diseño ...................................................................................................................203 Figura 122: Interfaz de usuario del Sistema de Control de Rutas .......................................................204 Figura 123: Diagrama de Componentes del Sistema ..........................................................................205 Figura 124: Diagrama de Despliegue del Sistema ..............................................................................206 Figura 125: Clase .................................................................................................................................233 Figura 126: Operación abstracta..........................................................................................................233 Figura 127: Miembro estático (atributo al nivel de clase en el UML) ...................................................233 Figura 128: Objeto................................................................................................................................233 Figura 129: Enlace ...............................................................................................................................234 Figura 130: Asociaciones, multiplicidad, nombre, calificador y rol ......................................................234 Figura 131: Asociación y atributo derivados ........................................................................................234 Figura 132: Subconjunto de una asociación ........................................................................................235 Figura 133: Agregación ........................................................................................................................235 Figura 134: Asociación ternaria ...........................................................................................................235 Figura 135: Objeto enlazado (clase en asociación en el UML) ...........................................................235 Figura 136: Discriminador y generalización .........................................................................................236 Figura 137: Restricciones en objetos...................................................................................................236 Figura 138: Estado ...............................................................................................................................236 Figura 139: Transición de estado.........................................................................................................236 Figura 140: Puntos de inicio y final en los diagramas de estados .......................................................236 Figura 141: Subestados concurrentes (subestados “y” en el UML) ....................................................237 Figura 142: División de control.............................................................................................................237 Figura 143: Mensaje entre diagramas de estados...............................................................................237 Figura 144: Sistema de tiempo real .....................................................................................................241

Página xvi

Análisis y Diseño de Sistemas con el UML

Figura 145: Los diferentes mecanismos para modelar sistemas de tiempo real................................ 244 Figura 146: Una clase activa y un objeto de esa clase activa ............................................................ 245 Figura 147: Un objeto activo con su estructura interna en términos de otros objetos activos y pasivos ................................................................................................................................................ 246 Figura 148: Estados de un objeto activo con los eventos que causan transiciones........................... 246 Figura 149: Jerarquía de clases señal ................................................................................................ 249 Figura 150: Tipos de mensajes en el UML.......................................................................................... 250 Figura 151: El sistema de alarma tiene sensores ............................................................................... 254 Figura 152: Alarmas ............................................................................................................................ 254 Figura 153: Objetos activos y pasivos en un sistema de alarma de hogar......................................... 255 Figura 154: Jerarquía de señales para el sistema de alarma de hogar.............................................. 255 Figura 155: Subestados concurrentes en un diagrama de estados. El diagrama de estados describe la activación del sistema completo............................................................................................. 257 Figura 156: Una transición compleja donde los flujos de control son divididos en hilos concurrentes que corren en paralelo y se sincronizan posteriormente ....................................................... 258 Figura 157: La secuencia de activación de alarmas indicada en un diagrama de secuencia. La mayoría de los mensajes enviados son asincrónicos, excepto por la lectura de la información de configuración de celdas , la cual es hecha sincrónicamente con un llamado de operacion normal..................................................................................................................................... 259 Figura 158: Un sensor ha detectado un movimiento e inicia una alarma en el sistema que es documentada en un diagrama de colaboración ..................................................................... 260 Figura 159: La operación run definida para la clase activa Manejador de Celdas. Se pueden mostrar actividades paralelas en el diagrama de actividades junto con la sincronización de esas actividades (la disparación de alarmas). El manejo de los mensajes de activación, desactivación, y time-out han sido colapsados en una superactividad, pero pueden ser expandidos en diagramas de actividades separados para mostrar los detalles ................... 262 Figura 160: El diagrama de despliegue para el sistema de alarma de hogar..................................... 263

Introducci贸n

Introducción

Página xix

Presentación 1. Título de la Investigación Análisis y Diseño de Sistemas con el Lenguaje de Modelaje Unificado (UML). 2. Desarrollada Por Randall Agenor Herrera Briones Roderick Javier Caldera Obregón Manuel de Jesús Martínez Dávila 3. Descripción de la Investigación En nuestro proyecto presentamos de una manera completa, detallada y comprensible cómo realizar análisis y diseño de sistemas utilizando el UML y lo respaldamos con un caso de estudio que consiste en el desarrollo de un Sistema de Control de Rutas. El análisis y diseño de este sistema serán realizados en Rational Rose 98, una herramienta de ingeniería de software asistida por computadora, por ser una herramienta que soporta la mayor parte de la notación del UML. La implementación del sistema será realizada en Oracle Developer/2000, una herramienta de desarrollo rápido de aplicaciones y será desplegada en el Oracle8 Server, un servidor de bases de datos objeto-relacional. 4. Profesor Tutor Ing. Ramón Esmirde Díaz Guillén 5. Duración de la Investigación 8 meses

Página xx

Análisis y Diseño de Sistemas con el UML

Antecedentes Durante nuestros estudios universitarios profundizamos bastante en lo que conocemos como Análisis y Diseño de Sistemas. Tuvimos la oportunidad de conocer y aplicar a profundidad lo que se conoce como Análisis y Diseño Estructurado, con todas sus técnicas como los Diagramas de Flujos de Datos, Diagramas Entidad Relación, Diagrama de Jerarquía de Funciones, etc. Sin embargo, nuestro conocimiento de otras metodologías es muy limitado. En cierta ocasión se intentó enseñarnos la metodología OMT, pero su aprendizaje fue superficial y por lo tanto no dejó un beneficio tangible en nosotros. Dadas las enormes ventajas que trae consigo la utilización de las metodologías orientadas a objetos, consideramos importante profundizar en una que busca la integración de las diferentes notaciones del campo de la orientación a objetos: el UML, porque creemos necesario conocer su notación y la forma de trabajar con ella pues se convertirá en el estándar de la industria, como es manifestado en su soporte por compañías como Oracle (Oracle Object Database Designer) y Microsoft (Microsoft Visual Modeler), así como por su utilización por grandes compañías que han encontrado en el UML las respuestas para sus necesidades. De esta forma estaremos preparados para esta nueva generación de herramientas y al mismo tiempo dejaremos un sólido fundamento teórico y práctico que servirá como base para el aprendizaje de los nuevos estudiantes de Sistemas de Información, lo que contribuirá a mejorar la calidad y conocimiento de los nuevos profesionales de nuestro país. El Lenguaje de Modelaje Unificado (UML, Unified Modeling Language), es el lenguaje de modelaje orientado a objetos estándar de la industria para especificar, visualizar, construir y documentar los elementos de los sistemas de software, así como para modelaje del negocio y de otros sistemas que no son de software. Simplifica el proceso complejo de análisis y diseño de software, facilitando un plano para la construcción. En el caso de nuestro trabajo trataremos de plasmar de manera clara la utilización del UML y su aplicación en el análisis y diseño de sistemas, de manera particular desarrollaremos un sistema que servirá como caso de estudio. El UML fue desarrollado en Rational Software Corporation por Grady Booch, James Rumbaugh e Ivar Jacobson con contribuciones de otros metodólogos líderes, vendedores de software y muchos usuarios; el UML está basado en el uso extensivo del método Booch, OMT y Jacobson; es decir, que el UML es la evolución de éstas y otras aproximaciones para modelaje de procesos de negocios, objetos, y el modelaje de componentes. El UML representa una colección de las mejores prácticas de ingeniería que han probado ser exitosas en el modelaje de sistemas grandes y complejos. En la actualidad existen una serie de empresas que se dedican al desarrollo de herramientas que utilizan como base la notación y sintaxis integrada en el UML. En el caso de Nicaragua, con la entrada de nuevas tecnologías en el campo de los sistemas de información es importante dar un vistazo a las nuevas tendencias existentes en el desarrollo mismo de los sistemas. Aquí es donde pretendemos dar a conocer al Lenguaje de Modelaje Unificado (UML) como una poderosa herramienta que puede ser utilizada para el desarrollo de los sistemas de información. Nosotros, estudiantes de la Universidad Católica queremos dar un primer paso, aunque con los fines académicos que implica un trabajo de culminación de estudios, en la incursión de las tendencias más recientes en el campo del análisis, diseño e implementación de sistemas. Por todo esto

Introducción

Página xxi

es importante que tengamos una idea clara de lo que implica el UML, y de los grandes beneficios que puede proporcionar al desarrollador, a las organizaciones y el país. El UML define una colección de notaciones para los diferentes diagramas y elementos de modelaje que lo componen; por lo tanto el UML por si mismo no es suficiente para desarrollar un producto de software; es necesario tener un proceso, una guía de como las actividades deben ser realizadas y secuenciadas con el fin de obtener un resultado. Para este fin utilizaremos el Proceso Unificado de Rational (Rational Unified Process); un proceso de análisis y diseño de sistemas iterativo e incremental, con soporte para el UML y que fue desarrollado también por Booch, Rumbaugh y Jacobson en Rational Corporation. Sin embargo, es preciso aclarar desde un inicio que los procesos pueden variar de desarrollador en desarrollador, de proyecto en proyecto y de empresa en empresa, lo que nosotros estamos buscando es utilizar un proceso que sirva de guía para dar una idea de cómo el UML debe ser utilizado en ese contexto. Consideramos que este proyecto constituirá un aporte significativo para nuestra escuela, puesto que representa un estudio detallado de una notación y metodología que es el resultado de años de estudios sobre el Análisis y el Diseño de Sistemas Orientado a Objetos para dar respuesta a las necesidades de información de las organizaciones.

Página xxii

Análisis y Diseño de Sistemas con el UML

Justificación Nuestro proyecto de culminación de estudios se justifica por las siguientes razones:

Novedad del Lenguaje de Modelaje Unificado. El UML es una nueva herramienta que no ha sido utilizada en el ámbito nacional. Es por ello que es una gran oportunidad para introducirnos en la investigación y desarrollo de este tema.

Nuestro proyecto servirá de base para la introducción de esta metodología y todos los beneficios que puede traer para el Análisis y Diseño de Sistemas, sirviendo de aporte para el mejoramiento de la calidad, eficacia y avance tecnológico de los sistemas de información en nuestro país. Recordemos que primero debe ser dado a conocer (el UML) para después lograr una aceptación del mismo.

Popularidad del paradigma de orientación a objetos. Esta es una tendencia muy marcada, puesto que se ve en la orientación a objetos una herramienta poderosa que puede ser utilizada para el desarrollo de los sistemas de información.

Necesidad de contar con trabajos de carácter investigativo que dejen una utilidad a la escuela. Como sabemos, nuestra escuela es relativamente nueva, y al igual que lo hacen las organizaciones, debe crecer, dar un vistazo a las tendencias del mercado, fijarse metas y objetivos, y ¿por qué no decirlo?, producir trabajos de calidad que permitan mostrar un nivel altamente competitivo comparado con el resto de escuelas de sistemas de información del país.

Necesidad de actualizar nuestro conocimiento de metodologías de Análisis y Diseño de Sistemas del Análisis Estructurado y OMT al Lenguaje de Modelaje Unificado. Esta es una buena oportunidad de introducirnos en las últimas tendencias en este campo. Es por ello que en el trabajo a realizar se dará una descripción muy completa de la metodología y se proporcionará un caso de estudio que ayude a esclarecer cualquier tipo de dudas que puedan presentarse. Recordemos que nosotros los informáticos debemos asumir el enorme reto que significa el tratar de mantenernos actualizados ante los enormes cambios existentes en las tendencias del análisis y diseño de sistemas, así como los cambios continuos en la tecnología. También debemos recordar que jugamos un papel muy importante dentro de las organizaciones: ser ese factor decisivo para el éxito de la organización en la cual estemos laborando; esto último por la gran importancia que tiene la información como uno de los recursos más importantes que determinan el éxito o el fracaso de la organización en un entorno tan competitivo en el que nos encontramos, producto del desarrollo acelerado en los medios de telecomunicaciones, transporte, y de la informática misma.

Necesidad de aprender a utilizar Herramientas de Ingeniería de Software Asistida por Computadora y Herramientas de Desarrollo Rápido de Aplicaciones. Recordemos que estas herramientas mejoran la eficiencia y eficacia de los desarrolladores, y por ende la obtención de sistemas que satisfacen mejor las necesidades de los usuarios finales.

Introducción

Página xxiii

Objetivos Objetivo General Investigar, analizar y estudiar el Lenguaje de Modelaje Unificado (UML) y aplicarlo en el Análisis y Diseño de un Sistema de Información. Objetivos Específicos

Verificar la aplicabilidad y bondades del Lenguaje de Modelaje Unificado para el Análisis y Diseño de Sistemas.

Proporcionar un material de apoyo didáctico para nuestra escuela, sobre el cual se puedan basar para la enseñanza del análisis y diseño orientado a objetos.

Actualizar nuestros conocimientos de análisis y diseño de sistemas de las metodologías estructurada y la técnica de modelaje de objetos (OMT) al UML.

Soportar el estudio de la metodología con un caso de estudio realizado utilizando nuestros conocimientos sobre UML.

Utilizar la herramienta Rational Rose 98, como ejemplo de una Herramienta de Ingeniería de Software Asistida por Computadora que soporta el Lenguaje de Modelaje Unificado.

Desarrollar e Implementar el Sistema de Control de Costos de Rutas utilizando la Base de Datos Oracle8 y la Herramienta de Desarrollo Rápido Oracle Developer/2000.

Página xxiv

Análisis y Diseño de Sistemas con el UML

Alcances y Restricciones Como todo proyecto de investigación, el nuestro tiene alcances y restricciones que definen qué deseamos alcanzar y qué no pretendemos cubrir en él. En nuestro proyecto presentamos de una manera completa, detallada y comprensible como realizar análisis y diseño de sistemas utilizando el UML, presentando los diferentes elementos, modelos y diagramas que lo componen, y luego lo respaldamos con un caso de estudio que consiste en el desarrollo de un Sistema de Control de Rutas. Nosotros no pretendemos presentar todos los elementos del caso de estudio en este documento, pues sería demasiado extenso y brindaría solamente un beneficio marginal. Por ello, presentaremos aquellos elementos que consideramos relevantes y que ayudan al lector a aclarar sus dudas y ver cómo el UML puede ser utilizado. Tampoco pretendemos desarrollar todos los requerimientos del Sistema de Control de Rutas, solamente aquellos que consideramos de mayor trascendencia para el usuario y que caen dentro de la primera iteración (la primera versión) del sistema. Además, no pretendemos presentar toda la notación del UML, sino lo que consideramos que será útil para alcanzar nuestros objetivos que definimos anteriormente. Si desea estudiar de manera más profunda el UML puede consultar la Guía de la Notación del UML (UML Notation Guide) y la Guía de la Semántica del UML (UML Semantics), disponibles en idioma inglés dentro del UML Documentation Set 1.1 (ver Bibliografía). Finalmente, este trabajo no es una introducción a los conceptos del Análisis y Diseño de Sistemas, Orientación a Objetos, Herramientas de Desarrollo Rápido de Aplicaciones, Herramientas de Ingeniería de Software Asistida por Comutadora, Bases de Datos, Rational Rose 98, Oracle Developer/2000 u Oracle8 Server. Recomendamos fuertemente al lector adquirir un conocimiento introductorio de los conceptos de la orientación a objetos antes de proceder en su lectura.

Capítulo 1: ¿Qué es el UML? El Lenguaje de Modelaje Unificado

Métodos y Lenguajes de Modelaje

Desarrollo de Software Orientado a Objetos

Uso del UML

Capítulo 1: ¿Qué es el UML?

Página 3

a importancia de los modelos ha sido evidente en todas las disciplinas de la ingeniería por mucho tiempo. Siempre que algo se construye, se realizan dibujos que describen su comportamiento y apariencia. Lo que se desarrolla puede ser una casa, una máquina, o un nuevo departamento dentro de una compañía. Los dibujos trabajan como una especificación de cómo queremos que se vea el producto terminado. Los dibujos son entregados a los subcontratistas, o son divididos en dibujos más detallados necesarios para el trabajo de construcción actual. Los planes de estimación de costos y tiempo, distribución del trabajo, y la localización de los recursos son realizados basándose en la información contenida en los dibujos. De nuevo, los dibujos son modelos de alguna cosa. Un modelo es una descripción de alguna cosa. Esta cosa puede existir, estar en la etapa de desarrollo, o todavía estar en la etapa de planificación. Durante el trabajo de hacer un modelo (modelaje), los diseñadores de modelos deben investigar los requerimientos para el producto terminado. Los requerimientos incluyen áreas tales como funcionalidad, apariencia, desempeño, y confiabilidad. Los diseñadores deben entonces crear un modelo que describa todos los diferentes aspectos del producto. El modelo es a menudo descompuesto en una serie de vistas, cada una de las cuales describe un aspecto específico del producto o sistema bajo construcción. El modelo puede ir a través de una serie de fases donde cada fase agrega detalles al modelo. La creación de modelos es un trabajo altamente creativo. No hay una solución final, no hay una respuesta correcta que sea chequeada al final del trabajo. Los diseñadores de modelos, a través del trabajo iterativo, aseguran que sus modelos logren los objetivos y los requerimientos del proyecto bajo construcción. Pero un modelo no es final; típicamente es cambiado y actualizado a través de un proyecto para reflejar nuevas percepciones y experiencias de los diseñadores. Durante el modelaje, las mejores soluciones son a menudo logradas permitiendo un alto grado de lluvia de ideas durante la cual diferentes soluciones y vistas son modelados y probados. Iterando las diferentes posibilidades, los diseñadores alcanzan un entendimiento más profundo del sistema, y finalmente pueden crear modelos del sistema que logren los objetivos y los requerimientos del sistema y sus usuarios. Los modelos son descritos usualmente en un lenguaje visual, lo cual significa que la mayor parte de la información en los modelos es expresada por símbolos gráficos y conexiones. El viejo dicho de que “un dibujo habla por mil palabras” es también relevante en el modelaje. La utilización de una descripción visual es necesaria para comunicar relaciones complejas; esto también hace que el modelaje práctico trabaje más fácilmente. No todo es apropiado para una descripción visual, sin embargo, alguna información en los modelos es mejor expresada en texto ordinario. Los modelos utilizables son:

Seguros: Describen correctamente el sistema a ser construido. Consistentes: Las diferentes vistas no expresan cosas que estén en conflictos con otras. Fáciles de comunicar a otros. Fáciles de cambiar. Comprensibles: Tan simple como sea posible, pero no los más simples.

Por mucho tiempo se ha hablado en la industria del software acerca de la llamada crisis del software. Las discusiones de la crisis se han basado en el hecho de que no solamente muchos proyectos de software fallan en producir sistemas que cumplan con los requerimientos y las necesidades de los usuarios, sino que también se termina excediendo los presupuestos y los horarios de tiempo. Nuevas técnicas tales como la programación orientada a objetos, la programación visual y los ambientes de desarrollo avanzados han ayudado a incrementar la productividad. Sin embargo son dirigidos en muchos de los casos a un bajo nivel de desarrollo: la programación. Uno de los problemas principales con el desarrollo de software de hoy es que en muchos proyectos comienzan a programar muy pronto

Página 4

Análisis y Diseño de Sistemas con el UML

y concentran muchos esfuerzos en la escritura de código. Esto es parcialmente por la falta de conocimiento de los administradores sobre el proceso de desarrollo del software ya que se ponen ansiosos cuando su equipo de programación no está produciendo código. Esto también ocurre porque los mismos programadores se sienten más seguros cuando están programando – una tarea con la cual ellos son muy familiares – más que cuando están construyendo modelos abstractos del sistema que van a crear. Ciertos métodos han existido por algún tiempo como un intento de prevenir el impulso de ver el desarrollo de un sistema como “un pequeño asunto de programación.” Esta multitud de métodos diferentes, todos con su propia notación única y herramientas, ha dejado confundidos a muchos desarrolladores. La falta de una notación bien establecida sobre la cual puedan ponerse de acuerdo muchos métodos y herramientas hace más difícil aprender como utilizar un buen método. Más aún, la calidad de muchos de los primeros métodos orientados a objetos debe ser puesta en cuestión, ya que muchos de ellos solamente son adecuados para pequeños sistemas con funcionalidad limitada, y por ello no tienen la capacidad de escalar a los sistemas más grandes que son prevalecientes hoy. Algunos vendedores eran alejados del área del mercado orientado a objetos debido a la necesidad de soportar muchos lenguajes de modelaje similares, pero ligeramente diferentes. En particular, la oferta de productos añadidos había disminuido debido a que los pequeños vendedores no podían costear el soporte para muchos formatos diferentes de muchas herramientas de modelaje. El costo perpetuo de usar y soportar muchos lenguajes de modelaje motivó a muchas compañías que producen o usan tecnología orientada a objetos a endorsar y soportar el desarrollo del Lenguaje de Modelaje Unificado. Aunque el Lenguaje de Modelaje Unificado no garantiza el éxito del proceso, mejora muchas cosas. Por ejemplo, reduce significativamente el costo perpetuo del entrenamiento y herramientas cuando se cambie de proyectos u organizaciones. Proporciona la oportunidad para una nueva integración entre herramientas, procesos y dominios. Pero más importante, permite a los desarrolladores enfocarse en entregar valor al negocio y les proporciona un paradigma para realizarlo. Todas las tendencias en la industria del software apuntan hacia la necesidad de crear modelos de los sistemas que intentamos construir. La programación visual es una técnica por la cual los programas son construidos visualmente manipulando y conectando símbolos; el modelaje y la programación están altamente integrados. Los sistemas se han vuelto más grandes y distribuidos a través de muchas computadoras a través de arquitecturas Cliente/Servidor (con Internet como la última arquitectura Cliente/Servidor). La necesidad de integrar sistemas complejos en un ambiente distribuido requiere que los sistemas tengan algunos modelos comunes. La ingeniería del negocio, donde los procesos de negocio de una compañía son modelados e implementados, requiere de sistemas de computadora que soporten estos procesos para implementar los modelos del negocio. Construir modelos de los sistemas antes de implementarlos se volverá tan normal y aceptado en la comunidad de ingeniería del software como lo son en las otras disciplinas de la ingeniería.

El Lenguaje de Modelaje Unificado El Lenguaje de Modelaje Unificado (el UML) es un intento para resolver algunos de los problemas que se acaban de describir. El UML es el estándar formal y puede ser también el estándar de facto para construir los modelos.

Capítulo 1: ¿Qué es el UML?

Página 5

La Guerra de los Métodos

El Análisis y Diseño Estructurado fue tal vez la primera familia de métodos de desarrollo de software que fue usada ampliamente. Formalizado durante el inicio de los 70s por Ed Yourdon, Tom DeMarco, Larry Constantine, Cris Gane, y otros, este método fue muy útil para una amplia variedad de problemas. Sin embargo, bajo los estándares actuales, los problemas para los cuales el Análisis y Diseño Estructurado era aplicado son muy simples y de poco alcance. La experiencia con sistemas más grandes y complejos descubrió limitaciones en este método, particularmente cuando se desarrollan sistemas con requerimientos inestables. La aparición de lenguajes basados en objetos y orientados a objetos como Smalltalk, C++ y Ada también descubrió problemas: el Análisis y Diseño Estructurado era más aplicable a los lenguajes estructurados como FORTRAN y COBOL. Hacia finales de la década de los 80s, los lenguajes y procesos se estaban moviendo al paradigma orientado a objetos. En general las técnicas orientadas a objetos resolvían los problemas de administración de la complejidad, y eran mucho más apropiados para un proceso de desarrollo iterativo. Una característica clave de todos los métodos orientados a objetos que emergieron en esa época fue su enfoque en modelar el vocabulario del problema y el espacio de la solución en una forma que proporciona un plano más exacto para la construcción del software y que más exactamente capturara las necesidades reales de los usuarios. El número de métodos orientados a objetos se incrementó de menos de 10 a más de 50 durante el período entre 1989 y 1994. Muchos usuarios de estos métodos tenían problemas encontrando uno que llenara sus necesidades completamente, creando así la llamada “guerra de los métodos.” Uno de los conceptos iniciales detrás del UML era ponerle fin a esta “guerra de los métodos” dentro de la comunidad orientada a objetos. Aprendiendo de esta experiencia, comenzaron a aparecer nuevas generaciones de los métodos con unos cuantos métodos emergentes, más notablemente los siguientes:

Booch: El método de Grady Booch para el desarrollo orientado a objetos está disponible en una serie de versiones. Booch definió la noción de que un sistema es analizado en una serie de vistas, donde cada vista es descrita por una serie de diagramas de modelo. La notación del método de Booch era muy extensiva, y algunos usuarios encontraron algunos de los símbolos (las infames nubes) muy difíciles de dibujar manualmente. El método también contenía un proceso por el cual el sistema era analizado por una vista de desarrollo macro y una vista de desarrollo micro, y estaba basado en un proceso altamente incremental e iterativo.

OMT: La Técnica de Modelaje de Objetos (OMT: Object Modeling Technique) es un método desarrollado en General Electric donde James Rumbaugh trabajaba previamente. Es por ello un proceso directamente para pruebas, basado en la especificación de requerimientos. El sistema es descrito por una serie de modelos: el modelo de objetos, del modelo dinámico y el modelo funcional, los cuales se complementan unos con los otros para dar una descripción del sistema. El método OMT también contenía muchas descripciones prácticas de como hacer el diseño de un sistema, tomando en cuenta la concurrencia y el mapeo a las bases de datos relacionales.

OOSE/Objectory: Los métodos OOSE y el Objectory fueron construidos desde el mismo punto de vista básico formado por Ivar Jacobson. El método OOSE es la visión de Ivar Jacobson de un método orientado a objetos; el método Objectory es utilizado para construir una serie de sistemas, tan diversos como sistemas de telecomunicaciones para Ericsson y sistemas financieros para

Página 6

Análisis y Diseño de Sistemas con el UML

compañías de Wall Street. Ambos métodos están basados en los casos de uso, los cuales definen los requerimientos iniciales de un sistema como es visto por un actor externo. Los casos de uso luego son implementados en todas las fases del desarrollo, con todas las pruebas del sistema, donde ellos son utilizados para verificar el sistema. El Objectory ha sido también adaptado para la ingeniería del negocio, donde las ideas son utilizadas para modelar y mejorar los procesos del negocio.

Fusion: El método Fusion viene de Hewlett-Packard. Es llamado un método de segunda generación, porque está basado en las experiencias de muchos de los métodos iniciales. El método Fusion ha extendido una serie de ideas previas importantes, incluyendo técnicas para la especificación de operaciones e interacciones entre los objetos. El método tiene un número grande de diagramas de modelos.

Coad/Yourdon: El método de Coad/Yourdon, también conocido como OOA/OOD, fue uno de los primeros métodos utilizados para el análisis y el diseño orientado a objetos. El método es algo simple y fácil de aprender, y como tal, trabaja bien para introducir a los principiantes a las ideas y la terminología de la tecnología orientada a objetos. Sin embargo, la notación del método no puede escalar para controlar cualquier cosa más que sistemas muy limitados. Consecuentemente, el método es raras veces utilizado hoy día.

Cada uno de estos métodos tenía su propia notación (los símbolos utilizados para dibujar los modelos orientados a objetos), proceso (qué actividades realizar en las diferentes partes del desarrollo), y herramientas (las herramientas CASE que soporten la notación y los procesos). Esto hacía la elección del método una decisión muy importante, y a menudo conllevaba a fuertes discusiones y debates acerca de cuál método era “el mejor,” “el más avanzado,” y “el correcto” para utilizar en un proyecto específico. En tales discusiones raras veces había una buena respuesta, porque todos los métodos tenían sus propias fortalezas y debilidades. Los desarrolladores experimentados a menudo tomaban un método como una base, y luego prestaban buenas ideas y soluciones de otros. En la práctica, las diferencias entre los métodos no eran realmente tan significativas, y a medida que pasaba el tiempo y los métodos fueron desarrollados llegaron a parecerse unos a otros. Esto fue reconocido por varios de los expertos, los cuales comenzaron a buscar formas de cooperar. Surgimiento del UML

El trabajo en el UML comenzó oficialmente en Octubre de 1994 cuando Rumbaugh se unió a Booch en Rational. Su objetivo era el de crear un nuevo método, el “Método Unificado,” que uniría el método de Booch y el método OMT-2. La versión 0.8 del Método Unificado fue liberada en Octubre de 1995. Alrededor de la misma fecha Ivar Jacobson – el hombre detrás de los métodos OOSE y Objectory – se unió a ellos y el alcance del UML fue expandido para incorporar OOSE. Rational Software también compró Objective Systems, la empresa sueca que desarrolló y distribuyó el Objectory. En este momento, los futuros desarrolladores del UML también se dieron cuenta que su trabajo estaba dirigido más directamente hacia la creación de un lenguaje de modelaje estándar, y renombraron su trabajo como “Lenguaje de Modelaje Unificado.” Tener éxito en el establecimiento de un lenguaje de modelaje estándar era una tarea más simple que hacer la misma cosa para un proceso, debido a que el proceso difiere sustancialmente entre las diferentes compañías y culturas. Es dudoso, si del todo posible, crear un proceso estándar que pueda ser utilizado por todos. Como autores primarios de los métodos Booch, OMT y OOSE, Grady Booch, Jim Rumbaugh e Ivar Jacobson estaban motivados a crear un lenguaje unificado por tres razones:

Capítulo 1: ¿Qué es el UML?

Página 7

1. Estos métodos estaban evolucionando claramente hacia cada uno independientemente. Era lógico seguir la evolución juntos en vez de separados, eliminando el potencial de diferencias innecesarias que confundirían a los usuarios. 2. Al unificar la semántica y notación, podrían traer cierta estabilidad al mercado orientado a objetos, permitiendo que los proyectos se asentaran en un lenguaje de modelaje maduro y permitiendo a los constructores de herramientas enforcarse en producir características más útiles. 3. Esperaban que su colaboración traería mejoras sobre sus métodos anteriores, ayudándoles a capturar lecciones aprendidas y solucionar problemas que ninguno de sus métodos previamente manejaba bien. Los esfuerzos de Booch, Rumbaugh y Jacobson resultaron en la liberación del UML 0.9 en Junio de 1996 y 0.91 en Octubre de 1996. Durante 1996, una serie de organizaciones se unieron a Rational para formar el consorcio de los socios del UML. Estas organizaciones consideraban al UML como estratégico para sus negocios y contribuyeron con la definición del UML. Naturalmente, estaban interesadas en tener sus propias áreas de experiencia dentro de la definición. Estas compañías fueron: Digital Equipment Corporation, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Texas Instruments, Unisys, y por supuesto Rational. La retroalimentación de la comunidad de ingeniería de software y de los socios del UML les dio muchas ideas y sugerencias a incorporar para mejorar el lenguaje. La versión 1.0 del UML salió en Enero de 1997. Rational hizo también un arreglo con Microsoft estableciendo que las compañías desarrollarán en conjunto el mercado de las herramientas de desarrollo empresarial. Esto quiere decir que intercambiarían licencias de tecnologías, de manera que sus productos se integrarán fácilmente los unos con los otros. Por ejemplo, Rational Rose será una herramienta CASE integrada de la parte más alta a la parte más baja de los ambientes tales como Microsoft Visual C++ o Visual Basic. Las compañías codesarrollarán y comercializarán sus soluciones integradas. Rational ha adquirido Microsoft Visual Test para ampliar sus productos base para soportar otros ambientes para el proceso de ingeniería del software. A pesar de que las partes principales del UML están basadas en los métodos de Booch, OMT y OOSE, estos diseñadores también incluyeron conceptos de otros métodos. Por ejemplo, el trabajo de David Harel en los diagramas de estado ha sido adoptado en los diagramas de estado del UML; partes de la notación del método de Fusión para la numeración de las operaciones ha sido incluida en los diagramas de colaboración; y el trabajo de Gamma-Helm-Johson-Vlissides sobre los patrones y cómo documentarlos ha inspirado detalles en los diagramas de clases. Los objetivos del UML, como fueron establecidos por los diseñadores, son:

Modelar sistemas (y no solo software) utilizando conceptos orientados a objetos. Establecer un acoplamiento explícito tanto a los artefactos conceptuales como los ejecutables. Resolver los problemas de escala inherente en sistemas complejos de misión crítica. Crear un lenguaje de modelaje utilizable por los humanos y las máquinas.

El UML está destinado a ser dominante, el lenguaje de modelaje común utilizado en la industria. Tiene un amplio rango de uso, está construido sobre técnicas bien establecidas y probadas para el modelaje de sistemas. Tiene el soporte para la industria necesario para establecer un estándar en el mundo real. El UML está bien documentado con metamodelos (un modelo de los elementos del modelo) del lenguaje, y con una especificación formal de la semántica del lenguaje.

Página 8

Análisis y Diseño de Sistemas con el UML

Aceptación del Lenguaje y Estandarización OMG

Para establecer el UML, los desarrolladores y Rational se dieron cuenta que el lenguaje tenía que estar disponible para cualquiera. Por consiguiente, el lenguaje no tiene un propietario y está abierto para todos. Las compañías son libres de utilizarlo con sus propios métodos; los vendedores de herramientas son libres para crear herramientas CASE para él; y los autores son motivados a escribir libros sobre él. Cuando comenzó el trabajo con el UML, éste estaba orientado a establecerse por sí mismo como el estándar de facto, lo cual significa que a través del uso práctico de muchos desarrolladores se volvería reconocido como el primer lenguaje de modelaje. Sin embargo cuando el OMG hizo una petición de un lenguaje de modelaje estándar, los desarrolladores del UML se dieron cuenta que ellos podrían hacer del UML el estándar aceptado. Esto impuso una mayor demanda de una definición formal y precisa del UML y mejoró la calidad del lenguaje. Una estandarización formal es importante para muchas industrias antes de que sean capaces de utilizar una nueva tecnología, tal como los desarrolladores de los sistemas militares. En respuesta a la petición de propuestas del OMG, se ofreció el UML 1.0 para su estandarización en Enero de 1997. Entre Enero y Julio de 1997 el grupo original de socios fue expandido para incluir virtualmente todos los otros colaboradores y contribuidores de la respuesta original del OMG, incluyendo Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, PTech, Reicht Technologies, Softeam, Sterling Software, y Taskon. Una fuerza de semántica fue formada, dirigida por Cris Kobryn de MCI Systemhouse y administrada por Ed Edykholt de Rational, para formalizar la especificación del UML y para integrar el UML con otros esfuerzos de estandarización. La versión revisada UML 1.1 fue ofrecida al OMG para estandarización en Julio de 1997. En Septiembre de 1997 esta versión fue aceptada por la Fuerza de Trabajo de Análisis y Diseño del OMG y la Junta de Arquitectura del OMG, y después de votos por todos los miembros del OMG fue aceptada el 14 de Noviembre de 1997.

Figura 1: Arbol genealógico del UML

Capítulo 1: ¿Qué es el UML?

Página 9

Metas del UML

Las metas primarias en el diseño del UML fueron: 1. Proporcionar a los usuarios un lenguaje de modelaje visual listo para usarse y expresivo de tal forma que permita desarrollar e intercambiar modelos con significado. Es importante que el estándar de análisis y diseño orientado a objetos soporte un lenguaje de modelaje que pueda ser usado inmediatamente para realizar tareas de modelaje normales y de propósito general. El UML consolida una conjunto de conceptos principales de modelaje que son aceptados por muchos métodos actuales y herramientas de modelaje. Estos conceptos son necesarios en muchas aplicaciones grandes, aunque no todos los conceptos son necesarios en todas las partes de la aplicación. 2. Proporcionar mecanismos de extensibilidad y especialización para extender los conceptos centrales. Se espera que el UML sea ajustado a medida que nuevas necesidades sean descubiertas para nuevos dominios. Al mismo tiempo, no se quiere forzar la redefinición o reimplementación de los conceptos centrales para cada necesidad. Por lo tanto, se cree que el mecanismo de extensión debería soportar desviaciones del caso común, en vez de que se requiera que se implementen los conceptos centrales del análisis y diseño orientado a objetos. Los conceptos centrales no deben ser cambiados más de lo necesario. Los usuarios necesitan ser capaces de: 1) construir modelos usando los conceptos centrales sin mecanismos de extensión para la mayoría de las aplicaciones normales; 2) añadir nuevos conceptos y notaciones para problemas no resueltos por la parte central; 3) escoger entre interpretaciones variadas de los conceptos existentes, cuando no hay un consenso claro; y 4) especializar los conceptos, notaciones, y restricciones para dominios particulares de aplicación. 3. Ser independiente de lenguajes de programación particulares y procesos de desarrollo. El UML debe y puede soportar todos los lenguajes de programación razonables. También debe y puede soportar todos los métodos y procesos de construir modelos. El UML puede soportar múltiples lenguajes de programación y métodos de desarrollo sin dificultad excesiva. 4. Proporcionar una base formal para entender el lenguaje de modelaje. Debido a que los usuarios usarán la formalidad para ayudarse a entender el lenguaje, éste debe ser preciso y aproximable; una falta de cualquiera de estas dos dimensiones dañaría su utilidad. 5. Incentivar el crecimiento del mercado de herramientas orientadas a objetos. Al permitir a los vendedores soportar un lenguaje de modelaje estándar usado por la mayoría de usuarios y herramientas la industria se beneficia. Aunque los vendedores pueden añadir más valor a sus implementaciones de herramientas, permitir la interoperabilidad es esencial. La interoperabilidad requiere que los modelos sean intercambiables entre usuarios y herramientas sin pérdida de información. Esto puede ocurrir solamente si las herramientas acuerdan el formato y significado de todos los conceptos relevantes.

Página 10

Análisis y Diseño de Sistemas con el UML

6. Soportar conceptos de desarrollo de más alto nivel tales como colaboraciones, estructuras, patrones y componentes. Una semántica claramente definida de estos conceptos es esencial para cosechar el completo beneficio de la orientación a objetos y la reutilización. Su definición dentro del contexto de un lenguaje de modelaje es una contribución única del UML. 7. Integrar las mejores prácticas en la industria. Una motivación clave detrás del desarrollo del UML ha sido integrar las mejores prácticas en la industria, cubriendo vistas amplias basadas en niveles de abstracción, dominios, arquitecturas, etapas de ciclo de vida, tecnologías de implementación, etc. El UML es de hecho una integración de las mejores prácticas.

Métodos y Lenguajes de Modelaje Hay diferencias importantes entre un método y un lenguaje de modelaje. Un Método es una manera explícita de estructurar nuestro pensamiento y acciones. Un método le dice a un usuario ¿qué hacer?, ¿cómo hacerlo?, ¿cuándo hacerlo?, y ¿por qué fue hecho? (el propósito de una actividad específica). Los métodos contienen modelos, y estos modelos son utilizados para describir algo y comunicar los resultados del uso de un método. La principal diferencia entre un método y un lenguaje de modelaje es que el lenguaje de modelaje carece de un proceso o de las instrucciones para ¿qué hacer?, ¿cómo hacerlo?, ¿cuándo hacerlo?, y ¿por qué fue hecho?. Cuando construimos modelos, también estructuramos nuestros pensamientos. Un modelo siempre se refiera a algo y tiene un propósito. Si un modelo no tiene un propósito específico, causará problemas, porque nadie sabrá ¿cómo?, ni ¿por qué usarlo?. Un modelo es expresado en un Lenguaje de Modelaje. Un lenguaje de modelaje consiste de una notación – los símbolos utilizados en el modelo – y un conjunto de reglas que dirigen como utilizarlo: las reglas sintácticas, semánticas, y pragmáticas. La sintaxis nos dice cómo se deben ver los símbolos y cómo son combinados en el lenguaje de modelaje. La sintaxis es comparada a las palabras en el lenguaje natural; es importante saber cómo deletrearlas correctamente y cómo poner juntas diferentes palabras para formar una oración. Las reglas de semántica nos dice qué significa cada símbolo y cómo debería ser interpretado por sí mismo y en el contexto de otros símbolos; son comparados con las palabras en el lenguaje natural. Estas reglas pragmáticas definen las intenciones de los símbolos a través de las cuales el propósito de un modelo es logrado y se vuelve compresible para otros. Esto corresponde en el lenguaje natural a las reglas para la construcción de oraciones que son claras y entendibles. Por ejemplo, los libros sobre estilos de escritura son referidos como pragmáticos en ese sentido. Para utilizar un lenguaje de modelaje bien es necesario para aprender todas estas reglas. La buena noticia es que el UML es más fácil de comprender que el lenguaje natural. La mayoría de los lenguajes cubren sólo la sintaxis y la semántica. El pragmatismo es muy difícil de describir debido a que no puede ser formalizado; puede actuar solamente como una guía. Naturalmente, aún cuando un lenguaje sea enseñado, no hay garantía que el modelo producido será bueno. Así como escribir una historia en un lenguaje natural, el lenguaje es solamente una herramienta que el autor debe dominar. Depende todavía del autor el escribir una buena historia.

Capítulo 1: ¿Qué es el UML?

Página 11

Desarrollo de Software Orientado a Objetos Como un lenguaje de modelaje orientado a objetos, todos los elementos y diagramas en el UML están basados en el paradigma de la orientación a objetos. Las definiciones de los conceptos orientados a objetos son realizadas. Cualquier lector totalmente no familiar con la orientación a objetos y su terminología debería leer algún texto introductorio. Las vistas primarias de los autores en la orientación a objetos son:

La orientación a objetos es una tecnología para producir modelos que reflejen un dominio, tal como un dominio de negocio o un dominio de una máquina, de manera natural utilizando la terminología del dominio.

Los modelos orientados a objetos, cuando son construidos correctamente son fáciles de comunicar, cambiar, expandir, validar, y verificar.

Cuando son hechos correctamente, los sistemas construidos utilizando tecnología orientada a objetos son flexibles de cambiar, tienen arquitecturas bien definidas, y proporcionan la oportunidad de crear e implementar componentes reutilizables. Los requerimientos del sistema son fáciles de convertir en código en el sistema.

Los modelos orientados a objetos son implementados convenientemente en software utilizando lenguajes de programación orientados a objetos. La utilización de lenguajes de programación que no son orientados a objetos para implementar sistemas orientados a objetos no es recomendada. Sin embargo es importante darse cuenta que la ingeniería del software orientada a objetos es mucho más que un par de mecanismos en un lenguaje de programación.

La orientación a objetos no es solamente una teoría, sino una tecnología bien probada utilizada en una serie de proyectos y para la construcción de muchos tipos diferentes de sistemas. El campo todavía carece de estandarización para mostrar el camino para una industrialización de la tecnología de objetos.

La orientación a objetos requiere un método que integre un proceso de desarrollo y un lenguaje de programación con técnicas de programación apropiadas y herramientas.

Uso del UML El UML es utilizado para modelar sistemas, cuyo rango es muy amplio: muchos tipos diferentes de sistemas pueden ser descritos. El UML puede ser utilizado también en las diferentes fases del desarrollo de un sistema, desde la especificación de los requerimientos hasta la prueba del sistema terminado. Diferentes tipos de sistemas

El objetivo del UML es describir cualquier tipo de sistema, en términos de diagramas orientados a objetos. Naturalmente, el uso más común es crear modelos de sistemas de software, pero el UML también es utilizado para describir sistemas mecánicos sin ningún software o la organización de un negocio. Aquí hay algunos tipos diferentes de sistemas y sus características más comunes.

Página 12

Análisis y Diseño de Sistemas con el UML

Sistemas de Información: Almacenan, recuperan, transforman y presentan información a los usuarios. Manejan grandes cantidades de datos con relaciones complejas, los cuales son almacenados en bases de datos relacionales o de objetos.

Sistemas Técnicos: Mantienen y controlan equipo técnico tal como procesos de telecomunicaciones, procesos de sistemas militares o procesos industriales. Deben mantener las interfaces especiales del equipo y tienen menos software que los sistemas de información. Los sistemas técnicos son a menudo sistemas de tiempo real.

Sistemas de Tiempo Real Empotrados: Se ejecutan en un hardware simple empotrado en cualquier otro equipo tal como un teléfono móvil, un carro, un utensilio del hogar, etc. Esto es llevado a cabo a través de programación de bajo nivel que requiere soporte de tiempo real. Estos sistemas a menudo carecen de dispositivos tales como pantalla, disco duro, etc.

Sistemas Distribuidos: Distribuidos en una serie de máquinas donde los datos son transferidos fácilmente de una máquina a otra. Requieren de mecanismos de comunicación sincronizada para asegurar la integridad de los datos y son construidos a menudo sobre mecanismos de objetos tales como CORBA, COM/DCOM, o Java Beans/RMI.

Software de Sistemas: Definen la infraestructura técnica que utiliza otro software. Los sistemas operativos, bases de datos, e interfaces de usuario realizan operaciones de bajo nivel en el hardware, mientras presentan interfaces genéricas para ser utilizadas por otro software.

Sistemas de Negocios: Describen los objetivos, los recursos (humanos, computadoras, etc.), las reglas (leyes, estrategias del negocio, políticas, etc.), y el trabajo actual en el negocio (procesos del negocio).

Es importante enfatizar que la mayoría de los sistemas no encajan limpiamente en una de estas categorías, pero pertenecen a más de uno de los tipos de sistemas o como una combinación. Por ejemplo, muchos de los sistemas de información de hoy tienen requerimientos distribuidos y de tiempo real. El UML tiene la capacidad de modelar todos estos tipos de sistemas. Ingeniería del Negocio

La ingeniería del negocio es una área nueva para el modelaje orientado a objetos y ha generado mucho interés. Los modelos orientados a objetos han probado ser un método excelente para modelar los procesos de negocio de una compañía. Un proceso de negocio proporciona algún valor al cliente del negocio (o quizás al cliente del cliente). Con la utilización de técnicas tal como la Reingeniería de Procesos del Negocio (BPR: Business Process Reengineering) o la administración de la calidad total (TQM: Total Quality Management) los procesos son analizados, mejorados, e implementados en la compañía. Utilizar un lenguaje orientado a objetos para modelar y documentar los procesos también hace más fácil de usar estos modelos cuando se están construyendo sistemas de información en la compañía.

Cap铆tulo 2: Un Vistazo al UML Vistas

Diagramas

Elementos del Modelo

Mecanismos Generales

Extensi贸n del UML

Modelaje con el UML

Herramientas

Capítulo 2: Un Vistazo al UML

Página 15

l Lenguaje de Modelaje Unificado tiene un amplio espectro de usos. Puede ser utilizado para el modelaje del negocio, el modelaje de software en todas las fases de desarrollo y para todos lo tipos de sistemas, y modelaje en general de cualquier construcción que tenga una estructura estática y un comportamiento dinámico. Con el objetivo de alcanzar estas amplias capacidades, el lenguaje es definido a ser extensivo y suficientemente genérico para permitir el modelaje de tales sistemas diversos, evitando tanta especialidad y complejidad. Es necesario que el usuario tenga visión del alcance y la estructura del UML. Ahora daremos un vistazo a las diferentes partes del UML:

Vistas: Las vistas muestran diferentes aspectos de los sistemas que son modelados. Una vista no es un gráfico, pero es una abstracción que consiste en una serie de diagramas. Solamente definiendo una serie de vistas, cada una mostrando un aspecto particular del sistema, puede ser construida una imagen completa del sistema. Las vistas también enlazan el lenguaje de modelaje al proceso/método escogido para el desarrollo.

Diagramas: Son los gráficos que describen los contenidos en una vista. El UML tiene nueve tipos diferentes de diagramas que son utilizados en combinación para proporcionar todas las vistas del sistema.

Elementos del modelo: Los conceptos utilizados en los diagramas son los elementos del modelo los cuales representan conceptos orientados a objetos comunes, tales como clases, objetos, mensajes, y las relaciones entre estos conceptos incluyendo asociación, dependencia y generalización. Un elemento del modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y símbolo.

Mecanismo Generales: Los mecanismos generales proporcionan comentarios extras, información, o semántica acerca de un elemento del modelo; ellos proporcionan también mecanismos de extensión para adaptar o extender el UML a un método, proceso, organización o usuario específico.

Vistas El modelaje de un sistema complejo es una tarea extensiva. Idealmente, el sistema completo sería descrito con un sólo gráfico que describa al sistema entero sin ambigüedades, y que sea fácil de comunicar y entender. Sin embargo, esto es usualmente imposible. Un sólo gráfico no puede capturar toda la información necesaria para describir un sistema. Un sistema es descrito con una serie de aspectos funcionales (su estructura estática e interacciones dinámica) y no funcionales (requerimientos de tiempo, confiabilidad, despliegue, etc.). Es por ello que un sistema es descrito en una serie de vistas, donde cada vista representa una proyección de la descripción completa del sistema, mostrando un aspecto particular del sistema. Cada vista es descrita en una serie de diagramas que contienen información que enfatiza un aspecto particular del sistema. Hay un pequeño traslape, de manera que un diagrama puede actualmente ser parte de una o más vistas. Viendo al sistema de diferentes vistas, es posible concentrarse en un aspecto del sistema a la vez. Un diagrama en una vista particular debería ser suficientemente simple para ser fácilmente comunicado, y ser coherente con los otros diagramas y vistas, de manera que una imagen completa del sistema es descrita por las vistas en conjunto (a través de sus respectivos diagramas). Un diagrama contiene símbolos gráficos que representan los elementos de modelo del sistema. Las vistas son:

Página 16

Análisis y Diseño de Sistemas con el UML

Vista de Casos de Uso: Es una vista que muestra la funcionalidad de un sistema como es percibida por los actores externos.

Vista Lógica: Es una vista que muestra como es diseñada la funcionalidad dentro del sistema, en términos de las estructuras estáticas del sistema y su comportamiento dinámico.

Vista de Componentes: Es una vista que muestra la organización de los componentes de código.

Vista de Procesos: Es una vista que muestra la concurrencia en el sistema, resolviendo problemas de comunicación y sincronización que estén presentes en un sistema concurrente.

Vista de Despliegue: Es una vista que muestra el despliegue de un sistema dentro de una arquitectura física con computadoras y dispositivos llamados nodos.

Estas vistas serán descritas en mayor detalle posteriormente. Cuando se selecciona una herramienta para dibujar los diagramas, debe asegurarse que ésta hace fácil la navegación de una vista a otra. Además, con el objetivo de ver cómo está diseñada para trabajar una función dentro de un diagrama, la herramienta debería hacer fácil el cambio ya sea a una vista de casos de uso para ver cómo es descrita la función por un usuario externo o a una vista de despliegue para ver cómo se distribuye la función en la estructura física. En otras palabras, saber qué computadoras están disponibles en ella. Note que otras vistas pueden ser utilizadas incluyendo las vistas estáticas-dinámicas, lógica-física, de flujos de trabajo y otras. El UML no requiere que las vistas anteriores sean utilizadas, pero ellas son las que los diseñadores del UML tenían en mente, de manera que es probable que la mayoría de las herramientas estarán basadas en estas vistas.

Diagramas Los diagramas son los gráficos actuales que muestran los símbolos de los elementos del modelo arreglados para ilustrar una parte particular o aspecto del sistema. Un modelo del sistema típicamente tiene varios diagramas de cada tipo. Un diagrama es una parte de una vista específica; y cuando es dibujado, es usualmente adecuado para una vista. Algunos tipos de diagramas pueden ser parte de varias vistas, dependiendo de los contenidos del diagrama. A continuación se dará una descripción de los conceptos básicos detrás de cada diagrama. Todos los detalles de los diagramas, su sintaxis, su significado exacto, y cómo interactúan será descrito más adelante en este documento. Diagrama de Casos de Uso

Un diagrama de casos de uso es una vista gráfica de algunos o todos los actores, casos de uso y sus interacciones, identificados para un sistema. Cada sistema típicamente tiene un diagrama de Caso de Uso Principal, el cual es la imagen de las fronteras del sistema (actores) y la funcionalidad principal proporcionada por el sistema (casos de uso). Otros diagramas de caso de uso pueden ser creados cuando sea necesario. Algunos ejemplos son:

Capítulo 2: Un Vistazo al UML

Página 17

Un diagrama que muestre todos los casos de uso para un actor determinado. Un diagrama que muestre todos los casos de uso implementados en una iteración. Un diagrama que muestre un caso de uso y sus relaciones.

Diagrama de Clases

Un diagrama de clases es un tipo de modelo estático. Un diagrama de clases describe la vista estática del sistema. Aunque tiene similitudes con un modelo de datos (entidad-relación), recuerde que las clases no solo muestran la estructura de la información, sino que describen también el comportamiento. Un propósito de los diagramas de clases es definir una base para otros diagramas donde otros aspectos del sistema son mostrados (tales como los estados de los objetos o la colaboración entre ellos mostrados en los diagramas dinámicos). Una clase en un diagrama de clase puede ser directamente implementada en un lenguaje de programación orientado a objetos. A medida que más y más clases son añadidas al modelo, una representación textual de las clases no es suficiente. Los diagramas de clases son creados para proporcionar una imagen o vista de algunas o todas las clases en el modelo. El diagrama de clases principal en la vista lógica del modelo es típicamente una imagen de los paquetes del sistema (a veces a este diagrama se le llama diagrama de paquetes). Cada paquete también tiene su diagrama de clases principal, que típicamente despliega las clases públicas del paquete. Otros diagramas se crean según sea necesario. Algunos usos típicos de otros diagramas son:

Vista de todas las clases de implementación en un paquete. Vista de la estructura y comportamiento de una o más clases. Vista de una jerarquía de herencia.

Los diagramas de clases también pueden ser creados en la vista de casos de uso del modelo. Estos diagramas típicamente son asignados a los casos de uso y contienen una vista de las clases que participan en los casos de uso. Diagrama de Objetos

Un diagrama de objetos es una variante del diagrama de clases y utiliza casi la misma notación. La diferencia entre los dos es que el diagrama de objetos muestra una serie de objetos (instancias de las clases), en vez de las clases actuales. Un diagrama de objetos es entonces un ejemplo de un diagrama de clases que muestra una posible imagen de la ejecución del sistema (cómo se vería el sistema en algún punto dado de tiempo). Es utilizada la misma notación que para los diagramas de clases, con dos excepciones: los nombres de los objetos son subrayados y son mostradas todas las instancias en una relación. Los diagramas de objetos no son tan importantes como los diagramas de clases, pero pueden ser utilizados para ejemplificar un diagrama de clases complejo mostrando cómo se verían las instancias actuales y las relaciones. Los diagramas de objetos son también utilizados como parte de los diagramas de colaboración, en los cuales es mostrada la colaboración dinámica entre los objetos. Diagrama de Estados

Un diagrama de estados es típicamente un complemento de la descripción de una clase. Muestra todos los estados posibles que los objetos de la clase puedan tener, y qué eventos causan un cambio de

Página 18

Análisis y Diseño de Sistemas con el UML

estado. Un evento puede ser otro objeto que envía un mensaje – por ejemplo, que el tiempo especificado se ha terminado – o que alguna otra condición ha sido cumplida. Un cambio de estado es llamado transición. Una transición puede tener también una acción conectada a él para especificar qué sería hecho en conexión con el estado de transición. Los diagramas de estados no son dibujados para todas las clases, solamente para aquellas que tienen una serie de estados bien definidos y en donde el comportamiento de la clase es afectado y cambiado por los estados diferentes. Los diagramas de estados pueden también ser dibujados para el sistema en su totalidad. Diagrama de Secuencia

Un diagrama de secuencia muestra una colaboración dinámica entre una serie de objetos. El aspecto importante de este diagrama es mostrar una secuencia de mensajes enviados entre los objetos. También son mostradas las interacciones entre los objetos, algo que sucederá en un punto específico de la ejecución de un sistema. Los diagramas consisten en una serie de objetos mostrados con líneas verticales. El tiempo pasa descendentemente en el diagrama, y el diagrama muestra el intercambio de mensajes entre los objetos a medida que pasa el tiempo en la secuencia o función. Los mensajes son mostrados como líneas con flechas de mensajes entre las líneas verticales de los objetos. Las especificaciones de tiempo y otros comentarios son añadidos en una escritura en el margen del diagrama. Diagrama de Colaboración

Un diagrama de colaboración muestra una colaboración dinámica, como el diagrama de secuencia. Es a menudo una elección mostrar una colaboración ya sea con un diagrama de secuencia o un diagrama de colaboración. Además de mostrar el intercambio de mensajes (llamado interacción), el diagrama de colaboración muestra los objetos y sus relaciones (a veces referidos como el contexto). A menudo uno puede decidir si utilizar un diagrama de secuencia o un diagrama de colaboración: si el tiempo o la secuencia es el aspecto más importante a enfatizar, escoja un diagrama de secuencia; si es importante enfatizar el contexto, escoja un diagrama de colaboración. La interacción entre los objetos es mostrada en ambos diagramas. El diagrama de colaboración es dibujado como un diagrama de objetos, donde una serie de objetos son mostrados junto con sus relaciones (utilizando la notación en el diagrama de clases o de objetos). Las flechas de mensajes son dibujadas entre los objetos para mostrar el flujo de mensajes entre los objetos. Se ponen etiquetas en los mensajes, lo cual entre otras cosas, muestra el orden en el cual son enviados los mensajes. También pueden mostrarse las condiciones, iteraciones, valores de retorno, y así sucesivamente. Cuando está familiarizado con la sintaxis de etiquetas para los mensajes, el desarrollador puede leer la colaboración y seguir el flujo de ejecución y el intercambio de mensajes. Un diagrama de colaboración puede también contener objetos activos que se ejecutan concurrentemente con otros objetos activos. Diagrama de Actividades

Un diagrama de actividades muestra el flujo secuencial de las actividades. El diagrama de actividades es utilizado típicamente para describir las actividades realizadas en una operación, aunque puede ser también utilizado para describir otros diagramas, tal como un caso de uso o de interacción. El diagrama de actividades consiste de estados de acción, los cuales contienen una especificación de la actividad que va a ser realizada (una acción). Un estado de acción termina cuando ha sido realizada la

Capítulo 2: Un Vistazo al UML

Página 19

acción (un estado en un diagrama de estados necesita un evento explícito aún antes que deje el estado). Por lo tanto, el control fluye entre los estados, que están conectados entre sí. Las decisiones y las condiciones, así como la ejecución en paralelo de los estados de acción, pueden ser también ser mostrados en el diagrama. El diagrama puede también tener especificaciones de los mensajes que han sido enviados o recibidos como parte de las acciones realizadas. Diagrama de Componentes

Un diagrama de componentes muestra la estructura física del código en términos de los componentes de código. Un componente puede ser un componente de código fuente, un componente binario, o un componente ejecutable. Un componente contiene información sobre la clase lógica o las clases que implementa, creando un mapeo de la vista lógica a la vista de componentes. Las dependencias entre los componentes son mostradas, haciendo fácil de analizar cómo los otros componentes son afectados por un cambio en uno de los componentes. Los componentes pueden ser mostrados también con cualquiera de las interfaces que exponen, tal como las interfaces OLE/COM y pueden ser agrupados en paquetes. El diagrama de componentes es utilizado en trabajos prácticos de programación. Diagrama de Despliegue

El diagrama de despliegue muestra la arquitectura física del hardware y el software en el sistema. Se pueden mostrar las computadoras y los dispositivos (nodos), junto con las conexiones que tienen unos con otros; también se puede mostrar el tipo de conexión. Dentro de los nodos, los componentes ejecutables y objetos son localizados para mostrar qué unidades de software son ejecutadas y en qué nodos. Además se muestran las dependencias entre los componentes. Como se dijo previamente, el diagrama de despliegue muestra la vista de despliegue la cual describe la arquitectura física actual del sistema. Esto está lejos de la descripción funcional en la vista de casos de uso. Sin embargo, con un modelo bien definido, es posible navegar todo el camino desde un nodo en la arquitectura física a sus componentes, a las clases que implementa, a las interacciones de los objetos de la clase en la cual participan y finalmente al caso de uso. Las diferentes vistas del sistema son utilizadas para dar una descripción coherente del sistema como un todo.

Elementos del Modelo Los conceptos utilizados en los diagramas son llamados elementos del modelo. Un elemento del modelo es definido con una semántica, una definición formal del elemento o el significado exacto de lo que representa en un enunciado no ambiguo. Un elemento del modelo también tiene un elemento de vista correspondiente, el cual es una representación gráfica del elemento o el símbolo gráfico utilizado para representar al elemento en los diagramas. Un elemento puede existir en varios tipos diferentes de diagramas, pero hay reglas para las cuales los elementos pueden ser mostrados en cada tipo de diagrama. En la siguiente figura se muestran algunos ejemplos de elementos del modelo tales como clase, objeto, estado, caso de uso, nodo, interfaz, paquete, nota, componente, actor, señal, y estados inicial, final e historia:

Página 20

Análisis y Diseño de Sistemas con el UML

Figura 2: Algunos elementos comunes de modelaje

Las relaciones son también elementos del modelo, y son utilizadas para interconectar otros elementos del modelo unos a otros. Algunas relaciones diferentes son:

Asociación: Conecta elementos y enlaza instancias.

Generalización: También llamada herencia, esto significa que un elemento puede ser la especialización de otro elemento.

Dependencia: Muestra que un elemento depende de alguna manera de otro elemento.

Agregación: Es una forma de asociación en la cual un elemento contiene otros elementos.

Refinamiento: Es una forma de generalización entre un elemento a mayor nivel de detalle que otro pero que representan lo mismo.

La siguiente figura muestra ejemplos de las relaciones antes descritas:

Figura 3: Ejemplos de relaciones

Capítulo 2: Un Vistazo al UML

Página 21

Otros elementos del modelo, además de los descritos incluyen mensajes, acciones y estereotipos. Todos los elementos, su significado, y sus usos permitidos serán explicados más adelante en este documento.

Mecanismos Generales El UML utiliza algunos mecanismos generales en todos los diagramas, para añadir información adicional en los mismos, lo cual típicamente no puede ser representado utilizando las habilidades básicas de los elementos del modelo. Adornos

Los adornos gráficos pueden ser incorporados a los elementos del modelo en los diagramas. Los adornos agregan semántica al elemento. Un ejemplo de adorno es la técnica utilizada para separar un tipo de una instancia. Cuando un elemento representa un tipo, su nombre es mostrado en negrillas. Cuando el mismo elemento representa una instancia del tipo, su nombre es subrayado y puede especificar el nombre de la instancia, así como el nombre del tipo. Un rectángulo de clase, con el nombre en negrillas representa una clase, y el mismo nombre subrayado representa un objeto. Lo mismo se aplica a los nodos, donde el símbolo del nodo puede ser un tipo, en negrillas, tal como Impresora, o bien, una instancia del tipo, tal como Impresora HP 5MP. Otros adornos son la especificación de la multiplicidad de las relaciones, donde la multiplicidad es un número o un rango que indica cuántas instancias de tipos conectados pueden contenerse en la relación. Los adornos son escritos cerca del elemento a los cuales agregan información. Todos los adornos son descritos en conjunción con la descripción del elemento que ellos afectan. Notas

No todo puede ser definido en un lenguaje de modelaje, no importa cuán extenso sea el lenguaje. Para permitir agregar información al modelo que de otra manera no puede ser representada, el UML proporciona las notas. Una nota puede ser puesta en cualquier lugar del diagrama, y puede contener cualquier tipo de información. Su tipo de información es una cadena que no puede ser interpretada por el UML. La nota es agregada típicamente a algún elemento en el diagrama con alguna línea punteada que especifica cuál elemento está siendo explicado o detallado, junto con la información en la nota.

Figura 4: Una nota contiene cualquier información adicional, tales como comentarios simples

Una nota contiene a menudo comentarios y preguntas del modelador como un recordatorio para resolver un dilema más tarde. Las notas pueden tener también estereotipos que describen el tipo de nota.

Página 22

Análisis y Diseño de Sistemas con el UML

Especificaciones

Los elementos del modelo tienen propiedades que guardan datos sobre el elemento. Una propiedad es definida con un nombre y un valor llamado valor agregado, el cual es de un tipo especificado, por ejemplo integer o string. Hay una serie de funciones predefinidas tales como Documentación, Responsabilidad, Persistencia, y Concurrencia. Las propiedades son utilizadas para agregar especificaciones sobre instancias de elementos que son normalmente mostrados en el diagrama. Una clase típicamente es descrita de manera informal listando las responsabilidades y capacidades de la clase. Este tipo de especificación no es normalmente mostrada en el diagrama por sí mismo, pero está disponible e una herramienta usualmente accesada haciendo doble click sobre el elemento que despliega una ventana con todas las propiedades.

Figura 5: Una ventana de especificaciones en Rational Rose 98 que muestra las propiedades de la clase

Extensión del UML El UML puede ser extendido o adaptado a un método específico, organización, o usuario. Tocaremos tres extensiones mecanismos aquí: estereotipos, valores agregados, y restricciones. Estereotipos

Los estereotipos son mecanismos de extensión que define un nuevo tipo de elemento del modelo basados en un componente de modelo existente. Es por ello, que un estereotipo “es justo como” un

Capítulo 2: Un Vistazo al UML

Página 23

elemento existente, más una semántica extra que no está presente en el elemento existente. Un estereotipo de un elemento puede ser utilizado en las mismas situaciones en las cuales es utilizado el elemento original. Los estereotipos están basados en todos los tipos de elementos – clases, nodos, componentes, y notas, así como relaciones tales como asociaciones, generalizaciones, y dependencias. Una serie de estereotipos son predefinidos en el UML, y son utilizados para ajustar un elemento del modelo existente en vez de definir uno nuevo. Esto hace que el UML sea simple. Un estereotipo es descrito poniendo su nombre como una cadena rodeada de guillemets (<< >>) – por ejemplo <<Nombre del estereotipo>> – alrededor del nombre del elemento como se muestra en la siguiente figura:

Figura 6: Un cliente es una clase con el estereotipo <<Actor>>. El estereotipo añade semántica adicional a la clase; en este caso, que la clase representa un usuario externo del sistema

Un estereotipo puede también tener su propia representación gráfica, tal como un icono, conectado a él. Un elemento de un estereotipo específico puede ser mostrado en su representación normal con el nombre del estereotipo encima del nombre, como un icono gráfico representando al estereotipo, o una combinación de ambos. Si un elemento tiene un nombre de estereotipo o un icono conectado a él, se lee como un tipo de elemento del tipo especificado. Por ejemplo, una clase con el estereotipo <<Ventana>> es leída como “una clase del estereotipo ventana,” lo cual significa que es un tipo de clase ventana. Las características particulares de una clase Ventana deben ser definidas cuando el estereotipo es definido. Como se explicó anteriormente, un estereotipo es un excelente mecanismo de extensión, y uno de los que previene que el UML se torne excesivamente complejo, y todavía facilita las extensiones y adaptaciones necesarias a ser realizadas. La mayoría pedía que los nuevos elementos del modelo tuvieran un prototipo en el UML. Un estereotipo puede ser utilizado para agregar la semántica necesaria con el objetivo de definir elementos perdidos del modelo. Valores Agregados

Como fue descrito antes, los elementos pueden tener propiedades que contienen pares de nombre-valor de la información sobre ellos. Estas propiedades son también conocidas como valores agregados. Una serie de propiedades son predefinidas en el UML pero las propiedades pueden también ser definidas por el usuario para guardar información adicional sobre los elementos. Cualquier tipo de información puede ser incorporada a los elementos: información de un método específico, información administrativa sobre el progreso del modelaje, información utilizada por otras herramientas, tal como herramientas de generación de código, o cualquier tipo de información que el usuario desee agregar a los elementos.

Página 24

Análisis y Diseño de Sistemas con el UML

Figura 7: Propiedades de una clase instrumento. Abstract es una propiedad predefinida; autor y estado son valores agregados definidos por el usuario

Restricciones

Una restricción limita el uso de un elemento o la semántica (significado) del elemento. Una restricción es declarada en una herramienta y utilizada repetidamente en varios diagramas, o es definida y aplicada en la medida que es necesitada en un diagrama. La siguiente figura muestra una asociación entre la clase Grupo Ciudadanos Mayores y la clase Persona, indicando que el grupo puede tener personas asociadas a él. Sin embargo, para indicar que sólo las personas mayores de 60 años de edad pueden incorporarse a él, se define una restricción que limita la participación a solamente a las personas mayores de 60 años.

Figura 8: Una restricción sobre que objetos personas pueden participar en la asociación

Esta definición restringe que Personas son usadas en la asociación. Sin ella podría haber un mal entendimiento a la hora de interpretar el diagrama. En el peor caso, podría conducir a una implementación incorrecta del sistema. En este caso, la restricción es definida y aplicada directamente al diagrama en el cual es utilizado, pero también podría definirse una restricción con un nombre y especificación tal como “Ciudadano Mayor” y “Persona.Edad > 60” y ser utilizado en varios diagramas. Hay una serie de restricciones predefinidas que pueden ser utilizadas.

Modelaje con el UML Cuando estamos construyendo sistemas con el UML, no se construye solamente un modelo. Hay distintos modelos en las diferentes fases del desarrollo, y los propósitos de los modelos son separados. En la fase de análisis, el propósito del modelo es capturar los requerimientos del sistema y modelar las clases básicas del “mundo real” y las colaboraciones. En la fase de diseño, el propósito del modelo es expandir el modelo del análisis en una solución técnica de trabajo con consideración del ambiente de implementación. En la fase de implementación, el modelo es la fuente actual de código que es

Capítulo 2: Un Vistazo al UML

Página 25

programado y compilado en los programas. Y finalmente en el modelo de despliegue, una descripción explica la forma en que el sistema es desplegado en la arquitectura física. El control entre las fases y los modelos es mantenido a través de las propiedades y las relaciones de refinamiento. A pesar de que los modelos son diferentes, son normalmente construidos expandiendo el contenido de los anteriores. Debido a esto, todos los modelos deberían ser guardados de modo de que sea fácil ir hacia atrás y deshacer o expandir el modelo inicial del análisis, y luego introducir gradualmente los cambios en los modelos de diseño e implementación. El UML es independiente de la fase, lo cual significa que el mismo lenguaje genérico y los mismos diagramas son utilizados para modelar cosas diferentes en diferentes fases. Depende del modelador decidir el propósito y el alcance que debería cubrir un modelo. El lenguaje de modelaje solamente proporciona la habilidad de crear modelos de una manera expresiva y consistente.

Figura 9: Un proceso de trabajo práctico de modelaje

Cuando modelamos con el UML, el trabajo debería ser gobernado por un método o un proceso que subraye los diferentes pasos a tomar y cómo son implementados esos pasos. Tal proceso típicamente

Página 26

Análisis y Diseño de Sistemas con el UML

divide el trabajo en iteraciones sucesivas de las fases de análisis de requerimientos, análisis, diseño, implementación y despliegue. Sin embargo hay también un proceso más pequeño al cual le concierne el trabajo actual de modelaje. Normalmente cuando se produce un modelo o un sólo diagrama, el trabajo es comenzado reclutando un grupo conveniente de gente quien presentan el problema y los objetivos; ellos caen en una lluvia de ideas informal y sesiones cerradas durante las cuales son intercambiadas las ideas sobre el posible modelo. Las herramientas utilizadas son muy informales – a veces anotaciones pequeñas o notas en una pizarra. Esta sesión continúa hasta que los participantes sienten que tienen una aproximación práctica para la base del modelo (una hipótesis temprana). El resultado es entonces puesto dentro de una herramienta; el modelo de hipótesis es organizado, y el diagrama actual es construido de acuerdo a las reglas del lenguaje de modelaje. Después, el modelo es detallado a través de un trabajo iterativo, a través del cual son descubiertos y documentados más detalles sobre la solución. A medida que es adquirida una mayor información sobre el problema y su solución, la hipótesis se convierte gradualmente en un diagnóstico para el modelo utilizable. Cuando el modelo está casi finalizado, es tomado un paso de integración y verificación, lo cual conlleva el modelo o diagrama a ser integrado con otros diagramas o modelos en el mismo proyecto para asegurar que no existen inconsistencias. El modelo es también validado para verificar si resuelve el problema correcto. Finalmente el modelo es implementado en algún tipo de prototipo que es evaluado por cualquier deficiencia en la solución actual. Las deficiencias incluyen cosas como funcionalidad perdida, mal rendimiento, o un gran costo de desarrollo. Las deficiencias deberían conducir a los desarrolladores atrás hacia el paso respectivo con el objetivo de removerlas. Si los problemas son mayores, los desarrolladores pueden tener que ir todo el camino hacia atrás a la fase de lluvia y limitación de ideas. Si los problemas son menores, probablemente los desarrolladores sólo tendrán que cambiar partes de la organización y especificación del modelo. Note que el paso de prototipo no debe ser realizado inmediatamente después de que el diagrama es construido; debería de ser realizado cuando una serie de diagramas pueden ser prototipados juntos. El prototipo puede ser construido sólo como evaluación, o bien, si el prototipo es exitoso se vuelve en una iteración en el proceso de desarrollo real. Probablemente, nosotros no estamos conscientes de las posibilidades del UML. Tradicionalmente, los diseñadores de lenguajes de programación o lenguajes macros se sorprenden por los usos que se les da. Por ejemplo, James Gosling dice que su lenguaje macro es utilizado en el editor Emacs para escribir sistemas de navegación por satélite o compiladores básicos, dada la versatilidad del UML, podemos asegurar que tendrá un destino similar.

Herramientas Utilizar un lenguaje de modelaje tan complejo y extenso como el UML requiere el soporte de herramientas. Aún si los primeros bosquejos de un modelo son realizados utilizando una pizarra (dibujar los modelos manualmente), el trabajo de mantener, sincronizar, y proveer consistencia en una serie de diagramas es casi imposible sin una herramienta. Las herramientas de modelaje o herramientas CASE se mantienen sorprendentemente inmaduras debido a que son la primera visión de programas que sirven para hacer programas. Muchas de las herramientas son poco más que herramientas de dibujo, con escasa verificación de consistencia o conocimiento del método o lenguaje de modelaje presente. Sin embargo, aquí han habido mejoras y las herramientas de hoy se están acercando cada vez más a la visión inicial. Muchas de las herramientas contienen errores o particularidades que las aplicaciones ordinarias no tienen, tal como problemas de cortar y pegar. Estas herramientas son también limitadas por el hecho

Capítulo 2: Un Vistazo al UML

Página 27

de que tienen su propio lenguaje de modelaje, o al menos su propia definición del lenguaje. Con la aparición del UML, los vendedores de herramientas pueden ahora pasar más tiempo mejorando las herramientas y menos tiempo definiendo nuevos métodos y lenguajes. Una herramienta CASE moderna debe facilitar las siguientes funciones:

Dibujo de Diagramas: La herramienta debe soportar la fácil elaboración de diagramas en el lenguaje de modelaje. La herramienta debería ser lo suficientemente inteligente para entender el propósito de los diagramas y saber la semántica simple y las reglas de modo que puede advertir o prohibir el uso inapropiado o incorrecto de los elementos del modelo.

Actuar como Repositorio: La herramienta debe soportar un repositorio común de modo que la información recolectada sobre el modelo sea almacenada en un solo lugar. Si el nombre de una clase es cambiado en un diagrama, el cambio debe ser reflejado en los otros diagramas en los cuales sea utilizada la clase.

Soportar la Navegación: La herramienta debería de facilitar la navegación del modelo, para seguir un elemento de un diagrama a otro, o extender la descripción de un elemento.

Proporcionar Soporte Multiusuario: La herramienta debería soportar múltiples usuarios, y permitirles trabajar en un modelo sin interferirse o molestarse unos a otros.

Generar Código: Una herramienta avanzada debería ser capaz de generar código, donde toda la información del modelo es traducida en esqueletos de código que son utilizados como la base de la fase de implementación.

Ingeniería Reversa: Una herramienta avanzada debería ser capaz de leer el código existente y producir modelos de él. Es por ello que un modelo podría ser construido a partir del código existente; o bien un desarrollador podría iterar entre trabajar en la herramienta de modelaje y la de programación.

Integración con otras herramientas: Una herramienta debería ser capaz de integrarse con otras herramientas ya sea con ambientes de desarrollo tales como un editor, un compilador, un depurador, o con otras herramientas de la empresa tal como administración de configuración y sistemas de control de versiones.

Cubrir el Modelo en Todos los Niveles de Abstracción: La herramienta debería ser fácil de navegar desde el nivel máximo de descripción del sistema (como una serie de paquetes) hasta el nivel del código. Entonces para accesar el código para una operación específica en una clase, solamente haríamos click sobre el nombre de la operación en el diagrama.

Intercambio de Modelos: Un modelo o los diagramas individuales de un modelo deberían ser capaces de exportarse de una herramienta y luego importarse en otra herramienta. El mismo intercambio debería aplicarse a los modelos en un lenguaje bien definido.

Soporte Para Dibujos

Una herramienta debe hacer el dibujo de los diagramas fácil y divertido. Ha pasado mucho tiempo cuando una herramienta avanzada de dibujo podía llamarse una herramienta CASE, no solamente debe proporcionar excelentes mecanismos para seleccionar, ubicar, conectar y definir los elementos del

Página 28

Análisis y Diseño de Sistemas con el UML

diagrama, sino que debe de ayudar al modelador en interpretación del diagrama correcto. La herramienta debería “tener un entendimiento” de la semántica de los elementos de manera que pueda proporcionar una advertencia si el elemento es utilizado incorrectamente o si una operación específica es consistente con cualquier otra operación. Por ejemplo, si un cambio propuesto en un diagrama crea conflictos con otro diagrama en el mismo modelo. La herramienta debería de brindar también soporte para la distribución del diseño de los diagramas. Esto debería incluir la facilidad de que el modelador redistribuya los elementos y la herramienta redistribuya de forma automática las líneas de mensajes de modo que no puedan cruzarse unas con otras. Muchos sistemas CAD tienen algoritmos muy elegantes para hacer esto, y muchos vendedores de herramientas de modelaje podrían aprender mucho mirando estos sistemas. Repositorio de Modelos

Las herramientas CASE deben mantener un repositorio de modelos que proporcione una base de datos con toda la información sobre los elementos utilizados en el modelo, sin importar de cuál diagrama viene la información. El repositorio debería contener la información base sobre el modelo completo, lo cual es visto después a través de una serie de diagramas. Algunas tareas que puede realizar una herramienta con la ayuda de un repositorio son:

Chequeo de Inconsistencia: Si un elemento es utilizado inconsistentemente en diferentes diagramas, la herramienta debe prevenir o prohibir esto. Si el modelador trata de borrar un elemento en un diagrama y es utilizado por otros diagramas, el desarrollador debe ser prevenido sobre esto. Si el desarrollador insiste en borrar el elemento, debe ser borrado de todos los diagramas donde es referenciado, y el desarrollador debe ir hacia atrás y actualizar estos diagramas para hacerlos válidos.

Críticas: Utilizando la información en un repositorio, una herramienta puede criticar el modelo, señalando las partes que no han sido especificadas o aplicando modelos heurísticos que muestran los posibles errores o soluciones inapropiadas.

Reportes: La herramienta puede generar automáticamente una documentación completa y extensa sobre todos los elementos, tal como las clases o los diagramas en un modelo, similar al término de catálogo de todos los datos.

Reutilización de Elementos o Diagramas: Un repositorio puede soportar reutilización de modo que la solución de modelaje o partes de una solución en un proyecto pueda ser fácilmente reutilizada en otro proyecto. Los componentes en un modelo del UML son directamente conectados al código fuente de modo que el modelo y el código actual sean reutilizados en proyectos diferentes.

Navegación

Cuando son utilizadas varias vistas y diagramas en conjunto para describir un sistema, es muy importante que sea fácil navegar entre ellos. Por consiguiente la herramienta debe soportar una navegación fácil, en términos de escala y de revisión rápida. Debe ser fácil navegar los diferentes diagramas, y realizar búsquedas de los elementos del modelo.

Capítulo 2: Un Vistazo al UML

Página 29

Un elemento debería tener hipervínculos, vínculos que no son visibles cuando vemos los diagramas impresos, pero que son accesibles solamente a través de una herramienta. Debería ser posible hacer click sobre un elemento con el botón derecho del ratón y obtener un menú de selección que despliegue las operaciones comunes y proporciones posibilidades de navegación, tales como ver otros diagramas donde está presente el elemento o accesar a la información detallada sobre el elemento. Partes de un diagrama deberían ser expansibles o plegables. Debería ser fácil expandir y ver los contenidos de un paquete, y desplegar la vista alrededor del paquete. Soporte Multiusuario

Una herramienta debería permitir que varios usuarios trabajen cooperativamente en el mismo modelo; esto es, sin molestar o interferir unos a otros. Típicamente, un usuario que trabaja en un diagrama debería enllavarlo de modo que nadie más pueda cambiarlo al mismo tiempo. Más aún, cualquier cambio realizado sobre elementos compartidos en el repositorio debería ser identificado por la herramienta. Pero las decisiones sobre qué cambio es válido deben ser resuelta por los usuarios. Generación de Código

Las herramientas modernas tienen soporte para generación de código, de manera que esas partes del trabajo que han sido provechosamente guardadas de la fase de modelaje no tienen que ser creadas de nuevo cuando empieza la fase de implementación. Estas herramientas típicamente generan esqueletos de código en un lenguaje orientado a objetos y transfieren la información de los modelos en el código en ese lenguaje. El tipo de código generado usualmente es información estática, tal como declaraciones de clases, incluyendo declaración de atributos y métodos. Los cuerpos de los métodos que contienen el código actual son normalmente dejados en blanco, para ser llenados por el programador – aunque teóricamente es posible que las partes de los modelos dinámicos puedan ser trasladadas a cuerpos de código. La generación de código puede ser parametrizada por los usuarios, en la que ellos dan instrucciones sobre cómo debería de verse el código generado. Son utilizados diferentes tipos de lenguajes destino. Naturalmente, los lenguajes de programación orientados a objetos tales como C++ y Java son utilizados, pero lenguajes como SQL (para la definición del esquema de una base de datos relacional) o IDL (para interfaces en un sistema CORBA) pueden también ser generados. Por consiguiente una herramienta debería de tener la capacidad de conectarse a diferentes generaciones de código para diferentes lenguajes. ¿Qué sucede si usted genera código de un modelo, comienza a codificar los cuerpos de los métodos, y luego hace un cambio en el modelo?, ¿Se pierde el trabajo de código cuando usted genera un esqueleto de código de su modelo actualizado?. Afortunadamente, este no es el caso. El código generado tiene marcas que muestran qué secciones del código son generadas de un modelo y qué secciones son codificadas manualmente. Cuando el código es generado de nuevo, las secciones que contienen el código manual no serán tocadas por el generador de código. Ingeniería Reversa

La funcionalidad de ingeniería reversa es casi el opuesto de la funcionalidad de la generación de código. El código es leído y analizado por la herramienta, y son creados los diagramas que muestran la estructura del código. Típicamente solamente los diagramas de estructura estática, tales como los diagramas de clases son construidos a partir del código: Ninguna información dinámica es extraída del código. La función de ingeniería reversa es utilizada ya sea para el código desconocido que es traído o codificado manualmente y para el código generado con la función de generación de código. Cuando es

Página 30

Análisis y Diseño de Sistemas con el UML

aplicada al código desconocido, el resultado es el levantamiento o depresión dependiendo de la estructura del código. Cuando se compran las librerías de clases, la ingeniería reversa es a menudo utilizada para obtener el diagrama que representa la estructura de la librería, de modo que las clases en la librería pueden ser utilizadas en los diagramas. Cuando es combinada la ingeniería reversa y la generación de código, es comúnmente referida como ingeniería de ida y vuelta. Cuando utilizamos una ingeniería de ida y vuelta, el desarrollador puede iterar entre el modelaje y la implementación, de modo que es definido un modelo; el código es generado, explorado, y cambiado en el ambiente de desarrollo, y luego de aplicársele ingeniería reversa vuelve al modelo. El proceso de desarrollo se vuelve realmente iterativo. Integración

Las herramientas tradicionales de modelaje (finalmente) se están volviendo más integradas con otras herramientas utilizadas en el desarrollo de sistemas. Debido a que la herramienta de modelaje actualmente almacena un modelo del sistema entero, es realmente natural hacer un centro común para todas las otras herramientas, tales como:

Ambiente de Desarrollo: Con estas herramientas, es posible ir directamente de un elemento del modelo de un diagrama a un ambiente de desarrollo, donde el código es editado, compilado y depurado. El opuesto es también verdadero. La herramienta debería ir directamente de un módulo de edición de código para determinar su localización en los modelos lógicos y físicos del sistema.

Control de Versión y Configuración: Estas son herramientas para manejar diferentes configuraciones del sistema y diferentes versiones del sistema y de los elementos individuales. El control de versión debería ser de ambos, de los modelos y del código.

Herramientas de Documentación: Estas herramientas pueden generar automáticamente una documentación del repositorio del modelo. La herramienta debería ser también capaz de generar estadísticas basándose en la información encontrada ahí.

Herramientas de Prueba: Las herramientas de prueba son principalmente para la administración del proceso de pruebas – recolecta y almacena los reportes de pruebas. La prueba realmente es la validación (¿Construimos el sistema correcto?) y verificación (¿Construimos el sistema de la manera correcta?) del proceso de desarrollo. Como tales, los modelos contienen mucha información para que el proceso de pruebas que debería de ser transferida a las herramientas de prueba.

Constructores de GUI (interfaces gráficas de usuario): Es una buena idea hacer que las asociaciones de clases en el modelo tengan su representación GUI en un constructor de GUI, donde la organización de la interfaz del usuario sea almacenada. También debería ser posible generar automáticamente formas GUI para clases en el modelo. Por ejemplo si son leídos los atributos en una clase, los campos de los tipos apropiados en una forma son generados a partir de esos atributos.

Herramientas de Especificación de Requerimientos: El UML tiene casos de uso para capturar los requerimientos funcionales del sistema. Sin embargo, hay también aspectos no funcionales del sistema, y estos deberían ser descritos utilizando herramientas de especificación de requerimientos.

Capítulo 2: Un Vistazo al UML

Página 31

Herramientas de Administración de Proyectos y de Soporte de Procesos: Una herramienta de administración de proyectos está destinada para ayudar al administrador de un proyecto para definir los horarios de tiempo y los planes de localización de recursos y realizar un seguimiento del progreso. Debido a que la producción de modelos es una parte grande de un proyecto, es beneficioso cuando el administrador del proyecto puede verificar fácilmente el trabajo de modelaje. La integración con las herramientas de soporte para procesos no es probablemente la prioridad máxima. Las herramientas de soporte para procesos soportan el uso de un método específico o proceso; y, naturalmente, la producción de modelos es una parte sustancial de cualquier método o proceso.

Note que no todas estas herramientas necesitan ser utilizadas en cada proyecto; tampoco hay una herramienta de modelaje en el mercado de hoy que sea integrada de esta manera. Las posibilidades de integración descritas son solamente una visión del posible futuro. Intercambio de Modelos

Solía ser imposible crear un modelo en una herramienta y luego exportarla a otra herramienta. Un prerequisito es un formato estandarizado para almacenar el modelo. El trabajo para definir tal formato para el UML está en progreso, aunque los formatos no son parte del estándar OMG. Cuando los modelos sean intercambiables entre las herramientas, será más fácil proporcionar herramientas simples de modelaje construidas en ambientes de desarrollo, donde los modelos puedan luego ser transferidos e integrados en una herramienta más avanzada. Naturalmente, otra ventaja es que los usuarios no tendrán que confiar solamente en un vendedor de CASE, y serán capaces de mover sus modelos a otros productos si sienten que les agrada más. Con un formato común, otras herramientas independientes tales como herramientas de documentación, de reportes, y de generación de bases de datos pueden ser desarrolladas más fácilmente.

Capítulo 3: Proceso Unificado ¿Qué es el Proceso Unificado?

Un Vistazo del Proceso

Fases e Iteraciones

Componentes del Proceso

Características del Proceso Unificado

Capítulo 3: Proceso Unificado

Página 35

¿Qué es el Proceso Unificado? Un proyecto de software exitoso satisface o excede las expectativas del cliente, es desarrollado en una forma económica y puntual, y es resistente al cambio y la adaptación. El ciclo de desarrollo debe promover la creatividad e innovación. Al mismo tiempo, el proceso de desarrollo debe ser controlado y medido para asegurar que el proyecto sea bien completado. Un ciclo de vida iterativo e incremental (ver la figura siguiente) bien manejado proporciona el control necesario sin afectar la creatividad. El UML es un lenguaje de modelaje, no un método. El UML no tiene noción de proceso, el cual es una parte importante de un método. El Proceso Unificado de Rational (Rational Unified Process) es un proceso de Ingeniería de Software. Proporciona una aproximación disciplinada para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de alta calidad que llene los estándares de los usuarios finales, dentro de un horario y presupuesto predecible. El Proceso Unificado captura muchas de las mejores prácticas en el desarrollo de software moderno en una forma que es adaptable para un amplio rango de proyectos y organizaciones. A pesar, de nuestro uso del Proceso Unificado, es importante recordar que el UML es independiente del proceso; es decir, con cualquier proceso que se use, puede usar el UML para grabar las decisiones resultantes del análisis y el diseño.

Figura 10: Desarrollo Iterativo e Incremental

Página 36

Análisis y Diseño de Sistemas con el UML

Un Vistazo del Proceso

Figura 11: Vista de alto nivel del proceso

Este proceso es un proceso de desarrollo iterativo e incremental, en el sentido de que el software no es liberado de una sola vez al final proyecto, sino que es desarrollado por partes. La fase de construcción consiste de muchas iteraciones, en cada una de las cuales se construye software de calidad de producción, probado e integrado que satisface un subconjunto de los requerimientos del proyecto. La entrega puede ser externa, a los usuarios, o puramente interna. Cada iteración contiene todas las fases del ciclo de vida de análisis, diseño, implementación y prueba. En principio, puede iniciar desde el comienzo: escoja alguna funcionalidad y constrúyala; escoja otra funcionalidad y constrúyala; y así sucesivamente. Sin embargo, es útil planear durante un cierto período de tiempo. Las primeras fases son inicio y elaboración. Durante el inicio, se establece la razón del negocio para el proyecto y se decide el alcance del proyecto. Aquí es donde se obtiene el compromiso del patrocinador del proyecto para seguir adelante. En la elaboración, se obtienen requerimientos más detallados, se hace análisis y diseño de alto nivel para establecer una arquitectura base, y se crea el plan para la construcción. Aún con este tipo de proceso iterativo, hay cierto trabajo que tiene que dejarse para el final, en la fase de transición. Esto puede incluir pruebas beta, optimización del rendimiento, y capacitación al usuario. Los proyectos varían con relación a cuanta ceremonia tienen. Los proyectos de alta ceremonia tienen una gran cantidad de entregas de documentos, entrevistas y documentos formales. Los proyectos de poca ceremonia pueden tener una fase de inicio que consiste de una plática de una hora con el patrocinador del proyecto y un plan en una hoja de cálculo. Naturalmente, mientras más grande sea el proyecto, se necesitará más ceremonia. Los fundamentos de cada fase todavía ocurren, pero en formas diferentes. En nuestro estudio mostramos iteraciones solamente en la fase de construcción. En realidad, puede tener iteraciones en todas las fases, y es a menudo una buena idea hacerlo en una fase larga. Sin embargo, la construcción es la fase clave sobre la cual iterar. El Proceso Unificado puede ser descrito en dos dimensiones:

A lo largo del tiempo, los aspectos del ciclo de vida del proceso y cómo se desarrolla. A lo largo de los componentes del proceso, que agrupa las actividades lógicamente por naturaleza.

Capítulo 3: Proceso Unificado

Página 37

Figura 12: Dimensiones del Proceso Unificado

La primera dimensión representa el aspecto dinámico del proceso, como es promulgado, y como es expresado en término de ciclos, fases, iteraciones e hitos. La segunda dimensión representa el aspecto estático del proceso: como es descrito en términos de los componentes del proceso, actividades, flujo de trabajo, artificios y trabajadores.

Fases e Iteraciones Estas conforman la organización dinámica del proceso a lo largo del tiempo. El ciclo de vida del software está dividido en ciclos, cada ciclo trabaja en una nueva generación del producto. El Proceso Unificado divide un ciclo de desarrollo en cuatro fases consecutivas:

Fase de Inicio (Inception Phase). Fase de Elaboración (Elaboration Phase). Fase de Construcción (Construction Phase). Fase de Transición (Transition Phase).

Cada fase es construida con hitos – un punto en el tiempo en el cual ciertas decisiones críticas deben ser tomadas – bien definidos, y por lo tanto metas claves han sido alcanzadas. Cada fase tiene un propósito específico. Fase de Inicio

La fase de inicio puede tomar varias formas. Para algunos proyectos, es una plática en la máquina de café: “Por favor pongan los catálogos de servicios en el Web.” Para proyectos mayores, puede ser un estudio de factibilidad completo que tome meses. Durante la fase de inicio se trabaja en el caso del negocio para el proyecto – cuánto costará y cuánto traerá de beneficio – y también se establecen los casos de uso del negocio y se delimita el alcance del proyecto. Para lograr esto debe identificar todas las entidades externas con las que el sistema interactua (actores) y definir la naturaleza de esta interacción a un nivel alto. Esto involucra identificar

Página 38

Análisis y Diseño de Sistemas con el UML

todos los casos de uso y describir unos cuantos significantes. El caso del negocio incluye criterios de éxito, valoración de riesgo, estimaciones de los recursos necesarios, y un plan de fase que enseña las fechas de los hitos mayores. También se obtiene una estimación inicial del alcance del proyecto. Al final de la fase de inicio, se examinan los objetivos del ciclo de vida del proyecto y se decide si se procede o no con el desarrollo. Fase de Elaboración

Las metas de la fase de elaboración son analizar el dominio del problema, establecer una fundación arquitectónica sólida, desarrollar el plan del proyecto y eliminar los elementos de más alto riesgo del proyecto. Las decisiones arquitectónicas deben ser tomadas con un entendimiento del sistema completo. Esto implica que debe describir la mayoría de los casos de uso y tomar en cuenta algunas de las restricciones: requerimientos no funcionales. Para verificar la arquitectura, debe implementar un sistema que demuestre las opciones arquitectónicas y ejecute casos de uso significativos. Al final de la etapa de elaboración, debe examinar los objetivos detallados del sistema y su alcance, la elección de arquitectura, y la resolución de riesgos mayores. Hasta este punto se tiene la autorización para iniciar el proyecto. En esta etapa típicamente tiene solamente una idea vaga de los requerimientos. Por ejemplo, podría ser capaz de decir: Vamos a construir el sistema de próxima generación de soporte para los clientes para la compañía X. Pretendemos usar tecnología orientada a objetos para construir un sistema más flexible que esté más orientado al cliente – específicamente, uno que soportará cobros consolidados a los clientes. Por supuesto, el documento de requerimientos será más extenso que eso, pero en realidad puede no decir mucho más. En este punto desea obtener un mejor entendimiento del problema.

¿Qué es lo que realmente se va a construir? ¿Cómo se va a construir? ¿Qué tecnología se va a usar?

En las decisiones de qué situaciones deben ser vistas durante esta etapa, se debe guiar primero y sobre todo por los riesgos del proyecto. ¿Cuáles son las cosas que podrían salir mal? Mientras mayor el riesgo, debe ser mayor la atención que se le debe prestar. Los riesgos pueden ser clasificados en cuatro categorías: 1. Riesgos de requerimientos. ¿Cuáles son los requerimientos del sistema? El peligro es que se construya el sistema incorrecto, uno que no hace lo que el cliente desea. Durante la etapa de elaboración, se necesita obtener claramente los requerimientos y sus prioridades relativas. 2. Riesgos tecnológicos. ¿Cuáles son los riesgos tecnológicos que tiene que resolver? Pregúntese estas preguntas: a. Se van a utilizar orientación a objetos. ¿Cuánta experiencia tiene haciendo análisis y diseño orientado a objetos?

Capítulo 3: Proceso Unificado

Página 39

b. Le han dicho que use Java y el Web (por ejemplo) ¿Qué tan bien trabaja esta tecnología? ¿Puede realmente entregar a los usuarios la funcionalidad que requieren mediante un navegador Web conectado a una base de datos? 3. Riesgos de habilidades. ¿Puede conseguir el personal y las habilidades que necesita? 4. Riesgos políticos. ¿Hay algunas fuerzas políticas que pueden ponerse en el camino y que afecten seriamente el proyecto? En cada caso puede haber más de uno, pero los riesgos que caen en una de estas cuatro categorías están casi siempre presentes. Tratando con los Riesgos de requerimientos

Los requerimientos son importantes y es donde las técnicas del UML pueden ser más obviamente utilizadas. El punto inicial son los casos de uso. Los casos de uso conducen el proceso de desarrollo completo. Un caso de uso es una interacción típica entre un usuario y un sistema para alcanzar alguna meta. Los casos de uso varían considerablemente en tamaño. La clave es que cada uno indica una función que el usuario puede entender y que tiene valor para el usuario. Los casos de uso proporcionan las bases de la comunicación entre los patrocinadores y los desarrolladores en la planeación del proyecto. Una de las cosas más importantes en la etapa de elaboración es identificar todos los casos de uso potenciales para el sistema que se está construyendo. En la práctica no es posible obtenerlos todos; sin embargo, se desea obtener la mayoría particularmente los más importantes. Es por esta razón que durante la fase de elaboración, debería planificar entrevistas con los usuarios para obtener los casos de uso. Los casos de uso no tienen que ser detallados. Usualmente un párrafo a tres de texto descriptivo es suficiente. Otra tarea importante es obtener un esqueleto del modelo conceptual del dominio. Dentro de las cabezas de uno o más usuarios está guardado cómo el negocio opera. Por ejemplo: Nuestros clientes pueden tener varios sitios, y proporcionamos servicios variados a esos sitios. Actualmente, un cliente obtiene un cobro por todos los servicios en un sitio dado. Deseamos que un cliente reciba un recibo para todos los servicios en todos los sitios. A esto se le llama cobro consolidado. Este pasaje contiene las palabras “cliente,” “sitio,” y “servicio.” ¿Qué significan estos términos? ¿Cómo se utilizan juntos? Un modelo conceptual del dominio inicia respondiendo estas preguntas y, al mismo tiempo, pone las bases para el modelo de objetos que será usado para representar los objetos en el sistema posteriormente en el proceso. Se usa el término modelo del dominio para describir cualquier modelo cuyo propósito principal es el mundo que soporta el sistema de cómputo, en cualquier etapa del proceso de desarrollo. En el Proceso Unificado, se usan diferentes modelos para capturar aspectos diferentes del desarrollo. Los modelos de dominio y casos de uso capturan los requerimientos funcionales; los modelos de análisis exploran las implicaciones de estos requerimientos para una aplicación en particular; los modelos de diseño añaden la infraestructura interna para que trabaje la aplicación. El modelo del dominio del Proceso Unificado es construido antes de que se encuentren los casos de uso; su propósito es explorar el vocabulario del dominio en términos que sean entendibles para los expertos del dominio.

Página 40

Análisis y Diseño de Sistemas con el UML

Después de que tiene un modelo de dominio y un modelo de casos de uso, se desarrolla un modelo de diseño que realiza tanto la información en los modelos de dominio como el comportamiento en los modelos de casos de uso. El modelo de diseño añade clases para realizar el trabajo y también para proporcionar una arquitectura reutilizable para extensiones futuras. En proyectos de mayor tamaño, se puede desarrollar un modelo de análisis intermedio para explorar las consecuencias de los requerimientos externos antes de tomar decisiones de diseño. El Proceso Unificado no requiere que se construya el sistema completo en cascada. Es importante obtener las clases y casos de uso clave del dominio del problema correctamente y después construir una arquitectura reutilizable que soporte extensiones futuras. Después, los casos de uso adicionales pueden ser añadidos incrementalmente, y pueden ser implementados en el modelo de diseño como parte de un proceso de desarrollo iterativo. El sistema completo no debe ser construido de un solo. Tres técnicas del UML son particularmente útiles para construir modelos de dominio:

Los diagramas de clase cuando se dibujan desde una perspectiva conceptual son excelentes para capturar el lenguaje del negocio. Puede usar estos diagramas para mostrar los conceptos que los expertos del dominio usan cuando piensan sobre el negocio y para mostrar las formas en que esos expertos enlazan juntos los conceptos. Los diagramas de actividades complementan los diagramas de clase describiendo el flujo de trabajo del negocio – es decir, los pasos que la gente realiza en su trabajo. El aspecto clave de los diagramas de actividades es que motivan la búsqueda de procesos paralelos, lo cual es importante en la eliminación de secuencias innecesarias en los procesos del negocio. Los diagramas de secuencia y colaboración exploran como varios roles interactúan en el negocio.

El modelaje del dominio puede ser una gran ayuda a los casos de uso. Cuando se juntan los casos de uso, es bueno traer un experto del dominio y explorar cómo esa persona piensa del negocio con la ayuda de las herramientas anteriores. En esta situación se usa una notación mínima, sin intentar capturar todos los detalles. Al contrario, se debe concentrar en los detalles importantes y áreas que implican riesgos. Después de cubrir las áreas más relevantes, se deben consolidar los diagramas diferentes en un modelo de dominio consistente. Para esto, se deben usar uno o dos expertos del dominio para desarrollar un solo modelo del dominio que sea consistente con los modelos discretos anteriores. Este modelo puede actuar como un punto inicial para construir clases y un diseño mayor de clases en la fase de construcción. Si este modelo es grande se pueden usar paquetes para dividirlo en partes. Se consolidan las clases y otros diagramas y tal vez se dibujan diagramas de estado para las clases con un ciclo de vida interesantes. Debe pensar en el modelo del dominio inicial como un esqueleto, no como un modelo de alto nivel. El término “modelo de alto nivel” implica que muchos detalles hacen falta. Tampoco se puede seguir el camino opuesto y construir un modelo muy detallado; si lo hace, tomará mucho tiempo. El truco es encontrar y concentrarse en los detalles importantes. La mayoría de los detalles serán descubiertos durante el desarrollo iterativo. El modelaje del dominio también es conducido por los casos de uso a medida que se conocen. A medida que aparecen, el grupo de modelaje debe mirarlos para ver si contienen algo que pudiera tener un impacto profundo en el modelo del dominio, si no, se deben apartar por el momento. El grupo de modelaje debe incluir desarrolladores y expertos del dominio y debe trabajar intensamente durante la elaboración para alcanzar un acuerdo del modelo. Durante este período, el líder debe

Capítulo 3: Proceso Unificado

Página 41

asegurar que el grupo no sea agobiado en detalles ni opere a un nivel tan alto que sus pies no toquen el suelo. Como parte de entender los requerimientos, se debe construir un prototipo de los casos de uso problemáticos. El prototipado es una técnica útil para entender mejor como trabajan las situaciones dinámicas. Tratando con los Riesgos técnológicos

Lo más importante en relación con los riesgos tecnológicos es construir prototipos que prueben las piezas de tecnología que se planean usar. Por ejemplo, digamos que trabaja con C++ y bases de datos relacionales. Estos son los pasos que debería seguir: 1. Obtener el compilador C++ y otras herramientas 2. Construir una parte simple de una versión temprana del modelo de dominio. Vea como las herramientas trabajan para Ud. 3. Construya la base de datos y conéctela al código C++ 4. Pruebe varias tareas, vea cuáles son más fáciles y cuáles más difíciles. Aprenda a usar las herramientas que escogió. No olvide que los riesgos tecnológicos mayores se encuentran en cómo los componentes del diseño trabajan juntos, en vez de en ellos por separado. Puede conocer C++ bien, y puede conocer las bases de datos relacionales bien, pero ponerlos a los dos juntos no es tan fácil. Por esto es muy importante obtener todos los componentes que desea usar y ponerlos juntos en esta temprana etapa del proceso. Debe también tomar decisiones de arquitectura durante esta etapa. Estas usualmente toman la forma de ideas de cómo los componentes mayores son y cómo serán construidos. Esto es particularmente importante si se contempla un sistema distribuido. Como parte de este ejercicio, enfóquese en cualquier idea que parezca difícil de cambiar posteriormente. Trate de hacer su diseño de una forma que le permita cambiar los elementos del diseño de una forma relativamente fácil. Pregúntese a sí mismo:

¿Qué sucede si una pieza de tecnología no trabaja? ¿Qué sucede si no podemos conectar dos piezas del rompecabezas? ¿Cuál es la posibilidad de hacer algo malo? ¿Cómo podemos resolverlo si sucede?

Al igual que con el modelo del dominio, debe mirar los casos de uso para verificar si contienen algo que podría afectar el diseño. Si sospecha que si, debe investigar a mayor profundidad. Durante este proceso, típicamente se usan varias técnicas del UML para plasmar las ideas y documentar las cosas que intenta. No trate de ser completo en este punto; todo lo que necesita son breves dibujos y por lo tanto, lo que debería usar.

Los diagramas de clase y los diagramas de interacción son útiles para mostrar como los componentes se comunican. Los diagramas de paquetes pueden mostrar una imagen de alto nivel de los componentes en esta etapa. Los diagramas de despliegue pueden proporcionar una vista de como las piezas están distribuidas.

Página 42

Análisis y Diseño de Sistemas con el UML

Tratando con los Riesgos de habilidades

A menudo, muchas conferencias se tratan de casos de estudio dados por personas que acaban de terminar un proyecto orientado a objetos. Usualmente responden a la pregunta “¿Cuál fue su peor error?” con respuestas que incluyen “Deberíamos habernos capacitado más.” Nunca para de asombrar cómo las compañías inician proyectos importantes orientados a objetos con poca experiencia y poco conocimiento para ganar más. La gente se preocupa del costo de la capacitación, pero pagan cada centavo cuando los proyectos toman más tiempo. La capacitación es una forma de evitar errores porque los instructores ya los han cometido. Cometer errores toma tiempo, y el tiempo cuesta dinero; por lo que, paga de las dos formas, pero no tener el entrenamiento retrasa el proyecto. La mejor forma de aprender orientación a objetos es a través de un mentor, el cual es un desarrollador experimentado que trabaja con el proyecto durante un tiempo. El mentor le dice cómo hacer las cosas, mira lo que hace, le da sugerencias, y le brinda pequeñas sesiones de entrenamiento. Un mentor trabaja con lo específico del proyecto y sabe qué partes de su experiencia aplicar en un momento dado. En las etapas tempranas, un mentor es parte del equipo. A medida que pasa el tiempo, Ud. se vuelve más capaz y el mentor hace más revisión que trabajo. La meta es que un mentor debe ser llegar a ser innecesario. El mentor puede ser el factor más importante en el éxito del proyecto por lo que vale la pena pagar calidad. Si no puede conseguir un mentor, considere una revisión del proyecto cada determinado período de tiempo. Bajo esta forma, un mentor con experiencia llega por unos cuantos días para revisar varios aspectos del diseño. Durante este tiempo, el mentor puede resaltar áreas de interés, ideas adicionales, y mostrar técnicas útiles que el grupo puede no conocer. Aunque esto no da los beneficios completos de un mentor, puede ser invaluable en la detección de aspectos claves que pueden ser mejorados. También se pueden complementar las habilidades con la lectura. Trate de leer un libro técnico por lo menos mensualmente. Mejor aún, léalo con un grupo y discútanlo. Haciendo esto pueden obtener un mejor entendimiento del libro que si lo leen solos. A medida que trabaja en la elaboración observe las áreas en las que no tiene experiencia o habilidades. Planee adquirirlas en el punto en que las necesite. Recuerde que si no aplica lo que aprende inmediatamente se le olvidará. Tratando con los Riesgos políticos

Trate de buscar ayuda de un profesional corporativo con experiencia para que le dé un consejo sabio sobre este aspecto. Particularmente de importancia son las áreas de cultura organizacional, resistencia al cambio, motivación al cliente e involucramiento de la organización en el proyecto.

Capítulo 3: Proceso Unificado

Página 43

Arquitectura base

Un resultado importante de la elaboración es que tiene una arquitectura base para el sistema. Esta arquitectura consiste de:

La lista de casos de uso, que dice cuáles son los requerimientos. El modelo del dominio, que captura el entendimiento del negocio y sirve como el punto inicial para las clases claves del dominio. La plataforma tecnológica, que describe las piezas de tecnología de implementación y cómo trabajan juntas.

Esta arquitectura es la base para el desarrollo; actúa como plano para etapas posteriores. Inevitablemente, los detalles de la arquitectura cambiarán, pero no debe cambiar significativamente. ¿Cuándo termina la elaboración?

Una regla que se podría aplicar es que la elaboración toma aproximadamente una quinta parte del tiempo total del proyecto. Dos eventos claves de que la elaboración está completa son:

Los desarrolladores se sienten confortables proporcionando estimados del esfuerzo en personasemana, o de cuánto tiempo tomará construir cada caso de uso. Todos los riesgos significativos han sido identificados, y los mayores son entendidos al punto que sabe cómo lidiar con ellos.

Planeación

La esencia de un plan es configurar una serie de iteraciones para la construcción y asignar los casos de uso a las iteraciones. El plan es finalizado cuando cada caso de uso es puesto en una iteración y la fecha de inicio de cada iteración ha sido identificada. El plan no es más detallado que eso. La primera etapa es categorizar los casos de uso.

Los usuarios usualmente indican los niveles de prioridad de los casos de uso. Usualmente hay tres niveles “Absolutamente necesito esta función en un sistema real” “Puedo vivir sin esta función por un corto período” “Es una función importante, pero puedo sobrevivir sin ella por un tiempo” Los desarrolladores deben considerar el riesgo de arquitectura asociado con cada caso de uso, el cual es el riesgo si el caso de uso es apartado hasta el final del proyecto. De nuevo hay tres categorías: alto riesgo, posible pero no probable, y poca oportunidad. Los desarrolladores deben valorar que tan confidentes se sienten en estimar el esfuerzo requerido para cada caso de uso. Esto se conoce como el calendario de riesgo. Hay tres niveles aquí también. “Estoy muy seguro de cuanto tiempo tomará” “Puedo estimarlo solamente al persona-mes más cercano” “No tengo idea”

Una vez que esto es hecho, debe estimar el tiempo que requerirá cada caso de uso, hasta el personames más cercano. Al realizar esta estimación, asuma que necesita hacer análisis, diseño, codificación,

Página 44

Análisis y Diseño de Sistemas con el UML

pruebas de unidades, integración y documentación. Asuma que tiene también un desarrollador completamente comprometido sin distracciones. Note que los desarrolladores son los que deben estimar, no los administradores. El desarrollador con mayor conocimiento de un caso de uso debe hacer la estimación. Una vez que se tienen las estimaciones, puede validar si está listo para hacer el plan. Mire los casos de uso con alto riesgo. Si una buena parte del tiempo del proyecto está atada en estos casos de uso o si estos casos de uso contienen bastante riesgo de arquitectura, puede necesitar hacer más elaboración. El próximo paso es determinar la longitud de la iteración. Necesita una longitud fija para las iteraciones del proyecto de forma que tenga un ritmo regular en la entrega de iteraciones. Una iteración debe ser lo suficientemente larga para realizar un puñado de casos de uso. Ahora puede considerar cuanto esfuerzo necesita para cada iteración. Un buen lugar para comenzar es asumir que los desarrolladores trabajan al 50% de su eficiencia. Multiplique la longitud de la iteración por el número de desarrolladores por un medio. El resultado es el esfuerzo de desarrollo que tiene para cada iteración. Por ejemplo, dados ocho desarrolladores y una longitud de iteración de tres semanas, tendría 12 semanas-desarrollador (8 * 3 * ½) de esfuerzo por iteración. Añada el tiempo para todos los casos de uso, divida por el esfuerzo por iteración, y añada uno para suerte. El resultado es el primer estimado de cuantas iteraciones se necesitan para el proyecto. El siguiente paso es asignar los casos de uso a las iteraciones. Los casos de uso que tienen alta prioridad, riesgo de arquitectura, o riesgo de calendario deben ser tratados al inicio. No deje el riesgo hasta el final!. Puede tener que dividir los casos de uso grandes, y probablemente tendrá que revisar los estimados de los casos de uso a la luz del orden en que se harán las cosas. Puede tener menos trabajo para hacer que el esfuerzo en la iteración, pero no debe calendarizar más que lo permitido por el esfuerzo. Para la transición, asigne de 10% a 35% del tiempo de construcción para afinar y empacar la entrega. Después añada un factor de contingencia: 10% al 20% del tiempo de construcción, dependiendo de que tan peligrosas se miran las cosas. Añada este factor al final de la fase de transición. Debe planear entregar sin usar tiempo de contingencia – es decir al final del tiempo de entrega interno – pero no permitir que la entrega se pase después del tiempo de contingencia. Después de seguir todas estas guías debe tener un plan que muestre los casos de uso que serán hechos durante cada iteración. Este plan simboliza el compromiso entre desarrolladores y usuarios; un buen nombre para este plan es el calendario de compromiso. Este calendario no es fijo – de hecho, todo el mundo debe esperar que cambie a medida que pasa el proyecto. Sin embargo, debido a que es un compromiso entre desarrolladores y usuarios los cambios deben ser hechos en conjunto. Fase de Construcción

Durante la fase de construcción, iterativamente e incrementalmente se desarrolla un producto completo que está listo para pasar a su comunidad de usuarios. Cada iteración es un mini-proyecto. Hace análisis, diseño, codificación, pruebas, e integración para los casos de uso asignados a cada iteración. Finaliza la iteración con una demostración al usuario y se realizan pruebas del sistema para confirmar que los casos de uso han sido construidos correctamente.

Capítulo 3: Proceso Unificado

Página 45

El propósito de este proceso es reducir el riesgo. El riesgo a menudo aparece porque los aspectos difíciles son dejados al final del proyecto. Hay proyectos en los cuales las pruebas y la integración son dejados al final. Las pruebas y la integración son tareas grandes, y siempre toman más tiempo de lo que la gente piensa. Atrás en el tiempo, en los días de OS/360, se estimaba que la mitad de un proyecto era pruebas (y corrección de errores). Las pruebas y la integración son más difíciles cuando se dejan al final – y más desmoralizadoras. Todo este esfuerzo lleva a un gran riesgo. Con el desarrollo iterativo realiza el proyecto entero en cada iteración, lo que conduce al hábito de lidiar con todos los problemas cada vez. Un desarrollador debe escribir tanto código de pruebas como de producción. Las pruebas deben ser un proceso continuo. Ningún código debe ser escrito hasta que se sepa como probarlo. Una vez que lo halla escrito, debe escribir pruebas para el mismo. Hasta que las pruebas trabajen no puede decir que se ha finalizado de escribir el código. El código de prueba, una vez escrito debe ser mantenido por siempre. Configure su código de prueba de tal forma que corra cada prueba con un solo comando o botón. El código debe responder con un OK o con una lista de fallos. Además, todas las pruebas deben verificar sus propios resultados. Separe las pruebas en pruebas de unidades y pruebas del sistema. Las pruebas de unidades deben ser escritas por los desarrolladores. Deben ser organizadas por paquetes y codificadas para probar las interfaces de todas las clases. Las pruebas del sistema deben ser desarrolladas por un grupo pequeño cuyo trabajo es solamente probar. Este grupo debe tener una vista de caja negra del sistema y tener un deleite particular en encontrar errores. Las iteraciones en la construcción son incrementales e iterativas.

Las iteraciones son incrementales en función. Se construyen sobre las bases de los casos de uso desarrollados en iteraciones previas. Son iterativas en términos de la base del código. Cada iteración deberá involucrar la reescritura de cierto código existente para hacerlo más flexible. La refactorización (ver Anexo B) es útil cuando se itera el código.

La integración debe ser un proceso continuo. Para iniciar, la integración completa es parte del final de cada iteración. Sin embargo, la integración puede y debe ser más frecuente que eso. Un desarrollador debe integrar después de cada pieza de trabajo. El conjunto completo de pruebas de unidad debe ser corrida en cada integración para asegurar pruebas completas de regresión. Desarrollo iterativo y planificación

Dentro de cada iteración, puede hacer una planeación más detallada. Una parte clave de cualquier plan es lidiar con cosas que no van de acuerdo con el plan. Afrontémoslo, siempre ocurre. La característica clave del desarrollo iterativo es que es enmarcado en el tiempo – no se permite pasarse de ninguna fecha. Por el contrario, los casos de uso pueden ser movidos a una iteración posterior mediante negociación y acuerdo con el promotor. El punto de esto es mantener un hábito regular de cumplir con las fechas y evitar el mal hábito de pasarse. Sin embargo, note que si está pasando muchos casos de uso, es hora de rehacer el plan, incluyendo la reestimación de los niveles de esfuerzo de los casos de uso. En esta etapa, los desarrolladores deben tener una mejor idea de cuánto tiempo tomarán las cosas.

Página 46

Análisis y Diseño de Sistemas con el UML

Usando el UML en la construcción

Todas las técnicas del UML son útiles durante esta etapa. A medida que añade un caso de uso dado, primero usa el caso de uso para determinar cuál es el alcance. Un diagrama de clase conceptual puede ser útil para suavizar algunos conceptos de los casos de uso y ver como estos conceptos trabajan con el software que ya ha sido construido. Si el caso de uso contiene elementos significativos de flujo de trabajo, puede verlos con un diagrama de actividad. La ventaja de estas técnicas en esta etapa es que pueden ser usadas en conjunto con el experto del dominio. Como es dicho por los expertos: el Análisis ocurre cuando el experto del dominio está en la habitación (de otra forma es seudoanálisis). Para moverse al diseño, un diagrama de clases de especificación puede ser útil para mapear las clases en mayor detalle. Los diagramas de interacción son útiles para mostrar como las clases interactúan para implementar los casos de uso. Los diagramas del UML son útiles para entender completamente el sistema. Sin embargo, no se deben producir diagramas muy complejos: Los memos cuidadosamente seleccionados y bien escritos pueden fácilmente sustituir a la documentación tradicional comprensiva. La última raramente es útil excepto en puntos aislados. Eleve estos puntos … y olvídese del resto.1 Confine la documentación a las áreas en las cuales ayude. Si encuentra que la documentación no le ayuda mucho, es una señal de que algo está mal. Los diagramas de paquete son usados como un mapa lógico del sistema. Estos diagramas ayudan a entender las piezas lógicas del sistema y a ver las dependencias (y mantenerlas bajo control). Un diagrama de despliegue, que muestra la imagen física de alto nivel, puede ser útil en este momento. Dentro de cada paquete, se debe tener un diagrama de clase de especificación donde no se muestre cada operación y atributo en las clases. Solamente se muestran las asociaciones, atributos y operaciones claves que ayudan a entender lo que está plasmado. Si una clase tiene un ciclo de vida complejo, se puede dibujar un diagrama de estados para describirla. En el Proceso Unificado, se deben dibujar diagramas de interacción para cada caso de uso que se identifique. Los diagramas de interacción deben cubrir cada escenario. No necesita un diagrama diferente para cada escenario, pero debe asegurarse que la lógica de cada escenario es capturada por el diagrama de interacción que se asocia al caso de uso. Si hay conceptos que se repiten continuamente se pueden usar patrones. Los patrones son útiles dentro del alcance del proyecto y cuando se comunican ideas fuera del proyecto.

Ward Cunningham: "EPISODES: A Pattern Language of Competitive Development." In Vlissides et al. 1996, pp. 371-388.

Capítulo 3: Proceso Unificado

Página 47

Fase de Transición

Durante la fase de transición se hace la transición del software a la comunidad de usuarios. Una vez que el producto ha sido puesto en las manos de los usuarios, a menudo surgen problemas que requieren desarrollo adicional para ajustar el sistema, corregir errores no detectados, o finalizar algunas de las características que hallan sido pospuestas. Esta fase típicamente inicia con una versión “beta” de los sistemas. Hay otras cosas que no se pueden hacer durante el proceso de desarrollo normal. Un ejemplo de ello es la optimización. La optimización reduce la claridad y extensibilidad del sistema para mejorar el rendimiento. Esto es un compromiso – después de todo, el sistema tiene que ser lo suficientemente rápido para cumplir con los requerimientos del usuario. Sin embargo, la optimización muy temprana hace el desarrollo más difícil, por lo tanto se necesita dejar al final. Al final de la fase de transición se decide si los objetivos del ciclo de vida han sido cumplidos, y posiblemente si se debe iniciar otro ciclo de desarrollo. Este es también un punto donde se empacan algunas de las lecciones aprendidas en este proyecto para mejorar el proceso. Iteraciones

Cada fase en el Proceso Unificado puede ser dividida aun más en iteraciones. Una iteración es un ciclo completo de desarrollo que resulta en una versión (interna o externa) de un producto ejecutable, un subconjunto del producto final bajo desarrollo, el cual crece incrementalmente de iteración en iteración para convertirse en el sistema final. Cada iteración pasa por todos los aspectos del desarrollo de software, ej.: todos los componentes de proceso, aunque con un énfasis diferente en cada componente del proceso dependiendo de la fase. Esto es mostrado en el diagrama en la sección Un Vistazo al Proceso. La consecuencia principal de esta aproximación iterativa es que los artificios que describimos anteriormente crezcan y maduren a medida que el tiempo fluye.

Componentes del Proceso El Proceso Unificado está compuesto de siete componentes de proceso, que están descritos en términos de actividades, flujos de trabajo, trabajadores y artificios. Hay cuatro componentes del proceso de ingeniería: Captura de requerimientos, Análisis y Diseño, Implementación, y Prueba y tres procesos de soporte: Administración, Despliegue, y Entorno

Página 48

Análisis y Diseño de Sistemas con el UML

Componentes del Proceso y Modelos

Cada componente del proceso de ingeniería describe cómo crear y mantener un modelo. El Proceso Unificado tiene los siguientes modelos: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba. La siguiente figura muestra la relación de los componentes de proceso y los modelos:

Figura 13: Relación de los componentes de proceso y modelos

Captura de Requerimientos

La meta de la captura de requerimientos es describir qué es lo que el sistema debería hacer y permite a los desarrolladores y al cliente ponerse de acuerdo en esa descripción. Para alcanzar esto, se debe delimitar el sistema, definir sus alrededores y el comportamiento que debe presentar. Los clientes y usuarios potenciales son fuentes importantes de información así como cualquier otro requerimiento del sistema que pueda existir. La captura de requerimientos resulta en un modelo de casos de uso y algunos requerimientos suplementarios. El modelo de caso de uso es esencial para el cliente, quien necesita el modelo para validar que el sistema se transformará en lo que esperaba, y para los desarrolladores, quienes necesitan el modelo para obtener un mejor entendimiento de los requerimientos del sistema. El modelo de casos de uso es relevante para toda la gente envuelta en el proyecto. El modelo de casos de uso consiste de actores y casos de uso. Los actores representan a los usuarios, y cualquier otro sistema que puede interactuar con el sistema en desarrollo. Los actores ayudan a delimitar el sistema y a obtener una imagen más clara de lo que se debería hacer. Los casos de uso representan el comportamiento del sistema. Debido a que los casos de uso son desarrollados de acuerdo a las necesidades de los actores, es más posible que el sistema sea relevante para los usuarios.

Capítulo 3: Proceso Unificado

Página 49

Cada caso de uso es descrito en detalle. La descripción de caso de uso muestra como el sistema interactua paso por paso con los actores y lo que el sistema hace. Los casos de uso funcionan como un hilo unificador a lo largo del ciclo de desarrollo del sistema. El mismo modelo de caso de uso es usado durante la captura de los requerimientos, análisis y diseño y prueba.

Figura 14: El flujo de trabajo en la captura de requerimientos, mostrado en términos de trabajadores y sus actividades. Las flechas indican un orden lógico entre las actividades

Análisis y Diseño

La meta del Análisis y Diseño es enseñar cómo el sistema será realizado en la fase de implementación. Se desea construir un sistema que:

Realice – en un ambiente de implementación específico – las tareas y funciones especificadas en las descripciones de casos de uso. Llene todos los requerimientos. Sea estructurado para ser robusto (fácil de cambiar sí y cuando sus requerimientos funcionales cambien).

La fase de análisis trata con las abstracciones primarias (clases y objetos) y los mecanismos presentes en el dominio del problema. Las clases que modelan estos son identificadas, con las relaciones de las unas con las otras, y son descritas en el diagrama de clases del UML. La colaboración entre las clases para realizar los casos de uso también es descrita mediante cualquiera de los modelos dinámicos en el UML. En el análisis, solamente las clases que están en el dominio del problema (conceptos del mundo real) son modeladas – no las clases técnicas que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuarios, bases de datos, comunicación, concurrencia, y así sucesivamente. En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Nuevas clases son agregadas para proporcionar una infraestructura técnica: Las interfaces de usuarios, el manejo de bases de datos para almacenar objetos en una base de datos, comunicación con otros sistemas, interfaces para dispositivos en el sistema, y otras. Las clases del dominio del problema del análisis son

Página 50

Análisis y Diseño de Sistemas con el UML

“incorporadas” en esta infraestructura técnica, haciendo posible cambiar el dominio del problema y la infraestructura. El diseño resulta en especificaciones detalladas para la fase de construcción. El diseño resulta en un modelo de diseño que sirve como una abstracción del código fuente; esto es, el modelo de diseño actúa como un plano de cómo el código fuente está estructurado y escrito. El diseño también resulta en unas descripciones internas de los casos de uso, o realizaciones de los casos de uso, que describen como los casos de uso son realizados en términos de las clases/objetos participantes. El modelo de diseño consiste de clases de diseño estructuradas en paquetes de diseño; también contiene descripciones de como los objetos de estas clases de diseño colaboran para ejecutar los casos de uso. Las actividades del diseño son centradas alrededor de la noción de arquitectura. La producción y validación de esta arquitectura es el foco principal de las iteraciones tempranas de diseño. La arquitectura es representada por una serie de vistas de arquitectura. Estas vistas capturan las decisiones de diseño estructural de mayor importancia. En esencia las vistas de arquitectura son abstracciones o simplificaciones del diseño entero, en el cual las características importantes son hechas más visibles dejando los detalles al lado. La arquitectura es un vehículo importante no solo para desarrollar un buen modelo de diseño, sino también para incrementar la calidad de cualquier modelo construido durante el desarrollo del sistema.

Figura 15: El flujo de trabajo en el análisis y diseño, descrito en términos de trabajadores y sus actividades. Las flechas indican un flujo lógico entre las actividades

Implementación

En la implementación las clases de la fase de diseño son convertidas a código actual en un lenguaje de programación orientado a objetos (la utilización de un lenguaje procedural no es recomendada). Dependiendo de la capacidad del lenguaje utilizado, esta puede ser una tarea difícil o fácil. Cuando se hacen los modelos del análisis y diseño, es mejor tratar de evitar traducir mentalmente los modelos a código. En las primeras fases, los modelos son medios para entender y estructurar un sistema; por ello,

Capítulo 3: Proceso Unificado

Página 51

llegar a conclusiones tempranas acerca del código puede ser contraproducente para crear modelos simples y correctos. La programación es una fase separada durante la cual los modelos son convertidos a código. El sistema es realizado a través de la implementación produciendo los fuentes (archivos de código fuente, archivos de encabezados, makefiles, y así sucesivamente). Los fuentes son descritos en un modelo de implementación que consiste de módulos estructurados en paquetes de implementación. El diseño del modelo es la base para la implementación. La implementación incluye probar las clases separadas y/o paquetes, pero no probar que los paquetes/clases trabajan juntos. Eso es descrito en el próximo componente del proceso, la Prueba.

Figura 16: El flujo de trabajo en la implementación, mostrado en términos de trabajadores y sus actividades. Las flechas indican un orden lógico entre las actividades

Prueba

Un sistema es normalmente probado en pruebas de unidades, pruebas de integración, pruebas de sistemas, y pruebas de aceptación. Las pruebas de unidades son a menudo de clases individuales o un grupo de clases, y son realizadas típicamente por el programador. Las pruebas de integración integran los componentes y las clases con el objetivo de verificar que ellas cooperan como se especificó. Las pruebas de sistema miran al sistema como una “caja negra” y valida que el sistema tenga la funcionalidad final esperada por el usuario final. Las pruebas de aceptación conducidas por el cliente para verificar que el sistema cumple con los requerimientos son similares a las pruebas del sistema. Los diferentes equipos de prueba utilizan diferentes diagramas del UML como la base para su trabajo: las pruebas de unidades utilizan los diagramas de clase y especificaciones de clases, las pruebas de integración típicamente utilizan diagramas de componentes y diagramas de colaboración, y las pruebas del sistema implementan los diagramas de casos de uso para validar que el sistema se comporta como fue inicialmente definido en estos diagramas. La prueba verifica el sistema entero. Primero se debe probar cada caso de uso separadamente para verificar que sus clases participantes trabajan juntas correctamente. Después se debe probar (ciertos

Página 52

Análisis y Diseño de Sistemas con el UML

aspectos de) el sistema como un todo con descripciones de casos de uso como entradas a esta prueba. Al final de la prueba, el sistema puede ser entregado.

Figura 17: El flujo de trabajo en la Prueba, mostrado en términos de trabajadores y sus actividades. Las flechas indican un orden lógico entre las actividades

Características del Proceso Unificado Tecnología de Objetos

Muchos proyectos hoy utilizan lenguajes de programación orientados a objetos para obtener sistemas estables, reutilizables y tolerantes al cambio. Para obtener estos beneficios, es aún más importante usar tecnología orientada a objetos en el diseño. El Proceso Unificado produce un modelo de diseño orientado a objetos que es la base para la implementación. Un modelo orientado a objetos tiende a reflejar el mundo real. Por lo tanto, los objetos mismos a menudo corresponden a un fenómeno en el mundo real que el sistema va a manejar. Por ejemplo, un objeto puede ser una factura en un sistema de negocios o un empleado en un sistema de nómina. Un modelo correctamente diseñado usando tecnología de objetos es:

Fácil de entender. Claramente corresponde a la realidad. Fácil de modificar. Los cambios en un fenómeno particular solamente afectan el objeto que representa el fenómeno.

Desarrollo conducido por Casos de Uso

Es a menudo difícil distinguir a partir de un sistema tradicional orientado a objetos cómo un sistema hace lo que se supone que debe hacer. En el Proceso Unificado, los casos de uso definen el

Capítulo 3: Proceso Unificado

Página 53

comportamiento de un sistema. Los casos de uso no son parte de la orientación a objetos tradicional, pero su importancia se ha vuelto más y más aparente. En el Proceso Unificado, los casos de uso definidos para un sistema son las bases para el proceso de desarrollo entero. Los casos de uso juegan un rol en cada uno de los cuatro componentes de ingeniería: análisis de requerimientos, diseño, implementación y prueba. El modelo de casos de uso es el resultado del análisis de requerimientos. En esta etapa temprana del proceso se necesitan los casos de uso para modelar lo que el sistema debería hacer desde la perspectiva del usuario. Por lo tanto, los casos de uso constituyen un concepto fundamental que debe ser aceptable tanto para el cliente como para los desarrolladores del sistema. En el diseño, las descripciones de los casos de uso son usadas para desarrollar un modelo de diseño. Este modelo describe, en términos de objetos de diseño, las diferentes partes del sistema implementado y cómo las partes deben interactuar para realizar los casos de uso. Durante la implementación el modelo de diseño es la especificación de implementación. Debido a que los casos de uso son la base para el modelo de diseño, son implementados en términos de clases de diseño. Durante las pruebas los casos de uso constituyen casos de prueba. Esto significa que el sistema es verificado realizando cada caso de uso. Desarrollo Iterativo Controlado

La aproximación iterativa del Proceso Unificado es generalmente superior a las aproximaciones lineales o en cascada por varias razones: Permite tomar en cuenta cambios de requerimientos. La triste verdad es que los requerimientos normalmente cambiarán. Los cambios de requerimientos han sido siempre una fuente primaria de problemas para los proyectos. La Integración no ocurre al final – los elementos son integrados progresivamente. Actualmente, la aproximación iterativa del Proceso Unificado es casi continua. Lo que acostumbraba ser un tiempo largo que tomaba hasta el 40% del esfuerzo total al final del proyecto ahora esta dividido en seis a nueve integraciones menores que comienzan con menos elementos por integrar. Ayuda a mitigar riesgos más temprano porque la integración es generalmente el momento donde se descubren y resuelven los riesgos. A medida que pasan las iteraciones tempranas a través de todos los componentes del proceso se utilizan varios aspectos del proyecto: herramientas, software, habilidades, etc. Proporciona administración con una forma de hacer cambios tácticos al producto; por ejemplo, para competir con productos existentes. Puede decidir liberar un producto más temprano con funcionalidad reducida para reducir una movida de la competencia. Facilita la reutilización, debido a que es más fácil identificar partes comunes a medida que son parcialmente diseñadas e implementadas, en vez de identificarlas de una sola vez. Identificar y desarrollar partes reutilizables es difícil. Las revisiones del diseño en las primeras iteraciones permiten

Página 54

Análisis y Diseño de Sistemas con el UML

a los arquitectos identificar reutilización potencial no sospechada y desarrollar un código común maduro en iteraciones sucesivas. Resulta en una arquitectura más robusta porque está corrigiendo errores en varias iteraciones. Las fallas son detectadas aún en las primeras iteraciones cuando el producto pasa el inicio. Los problemas de desempeño son descubiertos cuando todavía pueden ser resueltos, no en el momento de la entrega. Los desarrolladores pueden aprender a medida que avanzan, y las varias compentencias y especialidades son más completamente utilizadas durante el ciclo de vida completo. Los probadores comienzan a realizar pruebas temprano, los escritores técnicos escriben temprano y así sucesivamente. En el desarrollo no iterativo la misma gente tendría que esperar para comenzar su trabajo. Las necesidades de entrenamiento o de ayuda adicional son detectadas temprano. El proceso mismo puede ser mejorado y refinado en el camino. Al final de una iteración no solamente se mira el estado del proyecto desde un punto de vista producto/cronograma sino también se analiza lo que debería ser cambiado en la organización y en el proceso mismo para trabajar mejor en la próxima iteración. Administración de Requerimientos

Los dos elementos clave detrás de un proceso iterativo controlado son la administración de requerimientos y el control del cambio. La administración de requerimientos es una aproximación de sistema para obtener, organizar, comunicar y administrar los requerimientos cambiantes de un sistema intensivo de software. Los beneficios de una administración de requerimientos efectiva incluyen: Mejor control de proyectos complejos. Calidad mejorada del software y satisfacción del cliente. Costos y retrasos reducidos. Comunicación de equipo mejorada. Un fuerte énfasis en la arquitectura

Los casos de uso controlan el Proceso Unificado desde el inicio hasta el final del ciclo de vida, pero las actividades de diseño son centradas en la noción de arquitectura – arquitectura de sistema o de software. El foco principal de las primeras iteraciones del proceso es producir y validar una arquitectura de software, la cual en el ciclo de desarrollo inicial toma la forma de un prototipo ejecutable que gradualmente se transforma en el sistema final en iteraciones posteriores. El Proceso Unificado proporciona una forma metódica y de sistema para diseñar, desarrollar y validar una arquitectura. Ofrece plantillas para descripciones de arquitectura alrededor de conceptos de múltiples vistas de arquitectura, y la captura de estilo de arquitectura, reglas de diseño y restricciones. El componente del proceso de diseño contiene actividades específicas dirigidas a identificar restricciones de arquitectura y elementos significativos, así como guías sobre como tomar decisiones de arquitectura. El proceso de administración muestra como la planeación de iteraciones tempranas toma en cuenta el diseño de una arquitectura y la resolución de los riesgos técnicos mayores. La arquitectura es importante por varias razones: Permite ganar y retener control intelectual sobre el proyecto, para manejar su complejidad y para mantener la integridad del sistema.

Capítulo 3: Proceso Unificado

Página 55

Es una base efectiva para una reutilización a larga escala. Proporciona las bases para la administración de proyectos.

Desarrollo basado en componentes

Un componente de software puede ser definido como una pieza de software no trivial, un módulo, paquete o subsistema, que llena una función clara, tiene una frontera clara y puede ser integrado en una arquitectura bien definida. Es la realización física de una abstracción en su diseño. Los componentes vienen de varias fuentes: Al definir una arquitectura bien modular, se identifican, separan, diseñan, desarrollan y prueban componentes bien formados. Estos componentes pueden ser individualmente probados y gradualmente integrados al sistema completo. Algunos de estos componentes pueden ser desarrollados para ser reutilizables, especialmente los que proporcionan soluciones comunes a una amplia variedad de problemas. Recientemente, el advenimiento de infraestructuras de componentes como CORBA, Internet, ActiveX y JavaBeans han disparado una industria de componentes para varios dominios, permitiendo comprar e integrar componentes en vez que desarrollarlos. El Proceso Unificado soporta desarrollo basado en componentes de varias formas: La aproximación iterativa permite identificar componentes progresivamente, decidir cuál desarrollar, cuál reutilizar y cuál comprar. El foco en arquitectura de software permite articular la estructura: los componentes y las formas en que se integran: los mecanismos fundamentales y patrones por los que interactúan. Los conceptos como paquetes, subsistemas y capas son usados durante el análisis y diseño para organizar componentes y especificar interfaces. Las pruebas son organizadas por componentes primero, después gradualmente mayores conjuntos de componentes integrados. Configurabilidad del proceso

El Proceso Unificado es general y completo y puede ser usado como es por algunas organizaciones de desarrollo de software. Sin embargo, en muchas circunstancias, este proceso de ingeniería de software tendrá que ser modificado y ajustado para acomodar características específicas, restricciones e historia de la organización adoptante. En particular, un proceso no debe ser seguido ciegamente, generando trabajo inútil; debe ser hecho tan limpio como sea posible para cumplir su misión de producir software de alta calidad rápidamente y predeciblemente. Los elementos del proceso que son candidatos para modificación, customización, adición o eliminación son artificios, actividades, flujos de trabajo, trabajadores y componentes del proceso.

CapĂtulo 4: Creando Casos de Uso Sistema

Actores

Casos de Uso

Capítulo 4: Creando Casos de Uso

Página 59

l comportamiento del sistema bajo desarrollo, es decir, la funcionalidad que es proporcionada por el sistema, es documentada en un modelo de casos de uso que ilustra las funciones pretendidas del sistema (casos de uso), su entorno (actores), y las relaciones entre los casos de uso y los actores (diagramas de casos de uso). El rol más importante de un modelo de caso de uso es el de comunicación. Proporciona un vehículo usado por los clientes o usuarios finales y los desarrolladores para discutir la funcionalidad del sistema y su comportamiento. En el modelaje de casos de uso, el sistema se mira como una “caja negra” que proporciona casos de uso. La forma en que el sistema trabaja, cómo son implementados los casos de uso y cómo trabajan internamente no es importante. De hecho, cuando el modelaje de casos de uso es hecho temprano en el proyecto, los desarrolladores no tienen idea de cómo los casos de uso serán implementados. Los principales propósitos para los casos de uso son:

Decidir y describir los requerimientos funcionales del sistema, resultando en un acuerdo entre el cliente y los desarrolladores de software que construyen el sistema. Dar una descripción concisa y consistente de lo que el sistema debería hacer, de tal forma que el modelo sea usado a lo largo del proceso de desarrollo para comunicar a todos los desarrolladores esos requerimientos, y para proporcionar las bases para modelaje de diseño adicional que entregue la funcionalidad requerida. Proporcionar las bases para las pruebas del sistema. Por ejemplo, preguntando, ¿el sistema final realmente realiza la funcionalidad inicialmente pedida? Proporcionar la habilidad de trazar los requerimientos funcionales en clases y operaciones del sistema para simplificar cambios y extensiones al sistema alterando los modelos de casos de uso y después trazando los casos de uso afectados en el diseño e implementación del sistema.

El modelo de casos de uso inicia en la fase de Inicio con la identificación de actores y casos de uso principales del sistema. El modelo es luego madurado en la fase de Elaboración – se añade información más detallada a los casos de uso identificados, y casos de uso adicionales son añadidos a medida que se necesiten. El trabajo real requerido para crear un modelo de casos de uso involucra, encontrar los actores y los casos de uso, describir los casos de uso, definir las relaciones entre los casos de uso, y finalmente validar el modelo. Es un proceso altamente iterativo que debería incluir discusiones con el cliente y las personas que representan los actores. Un sinnúmero de personas diferentes tiene un interés en los modelos de casos de uso. El cliente está interesado porque los modelos de caso de uso especifican la funcionalidad del sistema y describen cómo el sistema será y podrá ser usado. Es útil cuando el cliente juega un rol activo en el modelaje de casos de uso porque entonces los modelos pueden ser adaptados en detalle a los deseos del cliente. Los casos de uso son descritos en la terminología del cliente. Los desarrolladores necesitan los casos de uso para entender lo que el sistema debería hacer, y para proporcionar las bases para trabajo futuro (otros modelos, diseño de la arquitectura, e implementación). Los grupos de integración y pruebas del sistema necesitan los casos de uso para verificar que el sistema realiza la funcionalidad especificada en los casos de uso. Y finalmente, cualquiera envuelto en actividades conectadas a la funcionalidad del sistema puede tener un interés en los modelos de casos de uso; esto puede incluir los grupos de mercadeo, ventas, soporte, y documentación. El modelo de casos de uso representa la vista de casos de uso del sistema. Esta vista es muy importante, porque afecta las otras vistas del sistema. Tanto la arquitectura física como lógica del sistema son afectadas por los casos de uso, porque las funciones especificadas en los modelos de caso

Página 60

Análisis y Diseño de Sistemas con el UML

de uso son implementadas en esas arquitecturas. Una solución es diseñada que satisface los requerimientos. El modelaje de casos de uso no es usado solamente para capturar los requerimientos de nuevos sistemas; también es usado cuando se desarrollan nuevas generaciones de los sistemas. Cuando una nueva generación de un sistema es desarrollada, la nueva funcionalidad es añadida al modelo de casos de uso insertando nuevos actores y casos de uso, o modificando las especificaciones de los casos de uso existentes. Cuando se añada a casos de uso existentes se debe tener cuidado de no remover cualquier funcionalidad que todavía sea necesaria.

Sistema Como parte del modelaje de casos de uso, las fronteras del sistema son definidas. Note que un sistema no tiene que ser necesariamente de software; puede ser de negocios o una máquina. Definir las fronteras y responsabilidades del sistema no es siempre fácil, porque no es siempre obvio qué tareas son mejor automatizadas por el sistema y cuáles deben ser manejadas manualmente o por otros sistemas. Otra consideración es que tan grande debe ser el sistema en su primera generación. Es tentador ser ambicioso para la primera generación, pero las metas muy altas pueden hacer el sistema muy grande y el tiempo de entrega mayor. Una mejor idea es identificar la funcionalidad básica y concentrarse en definir una arquitectura estable y bien definida a la cual se le pueda añadir más funcionalidad posteriormente en futuras generaciones del sistema. Es esencial compilar un catálogo de conceptos centrales (entidades) con términos y definiciones en una etapa temprana. Esto no es un modelo de objetos del dominio, sino un intento de describir la terminología del sistema o negocio que está siendo modelado. La terminología posteriormente describe los casos de uso. El catálogo también puede ser usado para comenzar el análisis de dominio que sigue después. La longitud de este catálogo puede variar; puede ser un modelo conceptual que muestra relaciones simples o solamente un catálogo de texto que contenga términos y una corta descripción de lo que hay en el mundo real. Un sistema en un diagrama de casos de uso puede ser descrito como una caja; el nombre del sistema aparece dentro o arriba de la caja. La caja también contiene símbolos para los casos de uso en el sistema como se muestra a continuación. Sin embargo, la descripción del sistema en los diagramas es opcional.

Figura 18: Un sistema en un modelo de casos de uso

Capítulo 4: Creando Casos de Uso

Página 61

Actores Los actores no son parte del sistema – representan algo o alguien que debe interactuar con el sistema y que lo usa de alguna forma. Un actor puede

Solamente introducir información al sistema. Solamente recibir información del sistema. Introducir y recibir información hacia y del sistema.

El actor se comunica con el sistema enviando y recibiendo mensajes, los que son similares a los mensajes encontrados en la programación orientada a objetos, aunque no son especificados tan formalmente en un caso de uso. Un caso de uso es siempre iniciado por un actor que le envía un mensaje. Esto es a menudo llamado un estímulo. Cuando el caso de uso es realizado puede enviar mensajes a uno o más actores. Estos mensajes también pueden ir a otros actores además del que inició el caso de uso. Un actor es una clase, no una instancia. El actor representa un rol, no un usuario individual del sistema. Si John Doe quiere obtener seguro de una compañía de seguros, es su rol como asegurado el que se desea modelar, no John Doe. De hecho, una persona puede jugar múltiples roles en el sistema y los roles que una persona juega pueden ser restringidos. Por ejemplo, la misma persona puede estar prohibida de entrar y de aprobar una factura. Un actor tiene un nombre, y el nombre debe reflejar el rol del actor. El nombre no debe reflejar una instancia específica de un actor, ni la funcionalidad del mismo. Los actores tienen importancia particular cuando se configura el sistema para usuarios diferentes. Si el sistema tiene casos de uso que corresponden a funciones del usuario de alto nivel, puede usar los enlaces de caso de uso/actor para perfilar usuarios individuales. Cada usuario tendría una lista asociada de nombres de actores, la cual usaría para determinar que casos de usos el usuario puede realizar. También tienen importancia para saber quién quiere un caso de uso. Esto puede ser importante cuando se analizan necesidades que compiten. Entender los actores puede ayudarle a negociar las demandas que compiten. También pueden ser útiles para especificar la política de seguridad el sistema. Los actores pueden tener rangos. Un actor primario es uno que usa las funciones principales del sistema. Un actor secundario es uno que usa las funciones secundarias del sistema, tales como mantenimiento del sistema, respaldos, comunicación y administración de bases de datos. Ambos tipos de actores son modelados para asegurarse que la funcionalidad completa del sistema es descrita, aunque son las funciones primarias las de mayor importancia para el cliente. Los actores pueden ser activos o pasivos. Un actor activo es el que inicia casos de uso, mientras un actor pasivo nunca inicia un caso de uso pero participa en uno o más.

Figura 19: Notación en el UML para un actor

Página 62

Análisis y Diseño de Sistemas con el UML

Identificación de los actores

Típicamente, los actores son encontrados en la descripción del problema y en conversaciones con los clientes y los expertos del dominio. Las siguientes preguntas pueden ser usadas para ayudar a identificar los actores para un sistema:

¿Quién usará la funcionalidad principal del sistema? ¿Quién está interesado en cierto requerimiento? ¿Dónde en la organización será usado el sistema? ¿Quién se beneficiará del uso del sistema? ¿Quién suplirá al sistema con esta información, usará esta información, y removerá esta información? ¿Quién administrará, soportará y mantendrá el sistema? ¿El sistema usa un recurso externo (recursos de hardware)? ¿Alguna persona juega varios roles diferentes? ¿Varias personas juegan el mismo role? ¿El sistema interactua con otro sistema?

Cuando se busquen los actores del sistema, no considere solamente los individuos sentados frente a la computadora. Recuerde que el usuario puede ser algo o alguien que directamente o indirectamente interactua con el sistema y usa los servicios del sistema para alcanzar algo. Recuerde que el modelaje de casos de uso es hecho para modelar un negocio; por lo tanto, los actores son usualmente los clientes de ese negocio y no usuarios en el sentido informático. Como un medio para identificar actores, conduzca un estudio de usuarios del sistema actual (sistema manual o existente), preguntando que roles diferentes juegan cuando realicen su trabajo diario en el sistema. El mismo usuario puede jugar varios roles en momentos diferentes, dependiendo de qué funciones del sistema estén en uso. Repitiendo, un actor es un rol (una clase) no una instancia. Sin embargo, proporcionando un par de instancias de un actor se puede validar que el actor realmente existe. Un actor debe tener alguna asociación con uno o más casos de uso. Note que los actores no necesitan ser humanos, aunque sean representados con figuritas humanas. Un actor puede ser también un sistema externo o dispositivo que interactua con el sistema. El asunto de interacción con otros sistemas causa mucha confusión y variaciones de estilo entre los usuarios de los diagramas de casos de uso. 1. Algunas personas sienten que todas las interacciones con sistemas remotos deben ser mostradas en el diagrama. 2. Algunos sienten que solo debe mostrar los casos de uso de interacción externa cuando es el otro sistema el que inicia el contacto. 3. Algunos sienten que debe mostrar los actores del sistema solamente cuando ellos son los que necesitan el caso de uso. 4. Algunos sienten que pensar de un sistema como un actor es un enfoque incorrecto. Ellos piensan que un actor es alguien que desea algo del sistema. Considerando todas las alternativas, nos inclinamos hacia la 3; esto se debe a que los casos de uso consisten en la funcionalidad del sistema requerida por un actor externo.

Capítulo 4: Creando Casos de Uso

Página 63

¿Qué constituye un buen actor?

Se debe tener cuidado cuando se identifiquen los actores para un sistema. Esta identificación es hecha en una forma iterativa – la primera identificación de la lista de actores es raramente la lista final. Por ejemplo, ¿es un estudiante nuevo diferente de un estudiante de reingreso?. Suponga que inicialmente dice que si a esta pregunta. El próximo paso es identificar como el actor interactua con el sistema. Si el nuevo estudiante usa el sistema diferentemente que el estudiante de reingreso, son diferentes actores. Si usan el sistema en la misma forma, son el mismo actor. Otro ejemplo es la creación de un actor para cada rol que una persona pueda jugar. Esto también puede ser demasiado. Un buen ejemplo es un asistente de profesor que toma clases e imparte clases. Las capacidades necesarias para seleccionar cursos para tomar y seleccionar cursos para impartir ya estarían capturadas por la identificación de la funcionalidad necesitada por los actores Estudiante y Profesor. Por lo tanto, no hay necesidad para actor Asistente de Profesor. Mirando a los actores identificados y documentando cómo usan el sistema, llegará iterativamente a un buen conjunto de actores para el sistema. Relaciones entre los actores

Debido a que los actores en el UML son clases con el estereotipo <<Actor>>, pueden tener relaciones como el resto de clases. En los diagramas de casos de uso se muestran por lo general las relaciones de generalización para describir comportamiento común a un número de actores. Una generalización se utiliza cuando varios actores juegan – aparte de su rol – un rol más generalizado. Esto ocurre cuando el comportamiento del rol generalizado es descrito en una superclase actor. Los actores especializados heredan el comportamiento de la superclase y lo extienden de alguna forma. La generalización entre actores es mostrada como una línea con un triángulo en el extremo de la clase generalizada, como se muestra en la siguiente figura. La generalización será descrita con mayor detalle en capítulos posteriores.

Figura 20: Generalización entre actores

Página 64

Análisis y Diseño de Sistemas con el UML

Documentación de los actores

Una breve descripción de cada actor debe ser añadida al modelo. La descripción debería identificar el rol que el actor juega en su interacción con el sistema. Por ejemplo, si se identificó un actor que se llama cliente. Una descripción de tal actor sería: Un cliente es aquella persona que adquiere un producto de la compañía.

Casos de Uso Los casos de uso modelan un diálogo entre un actor y el sistema. Representan la funcionalidad proporcionada por el sistema; es decir, qué capacidades serán proporcionadas a un actor por el sistema. La colección de casos de uso para un sistema constituye todas las formas definidas en que el sistema será usado. Un caso de uso representa una funcionalidad completa tal y como es percibida por un actor. La definición formal de un caso de uso en el UML es: un caso de uso es una secuencia de acciones realizadas por el sistema que proporciona un resultado observable de valor para un actor en particular. Las acciones pueden incluir comunicación con un número de actores así como realizar cálculos y trabajo dentro del sistema. Las características de un caso de uso son:

Un caso de uso es siempre iniciado por un actor. Un caso de uso es siempre realizado en beneficio de un actor. El actor debe directa o indirectamente ordenar al sistema que realice el caso de uso. Ocasionalmente el actor puede no estar consciente de iniciar un caso de uso. Un caso de uso proporciona valor a un actor. Un caso de uso debe proporcionar algún tipo de valor tangible a un usuario. El valor no tiene que ser saliente, pero debe ser discernible. Un caso de uso es completo. Un caso de uso debe ser una descripción completa. Un error común es dividir un caso de uso en casos de uso menores tanto como llamadas de función en un lenguaje de programación. Un caso de uso no está completo hasta que un valor final es producido, aún si varias comunicaciones (como cajas de diálogo) ocurren en el camino.

Un caso de uso es una clase, no una instancia. Describe la funcionalidad como un todo, incluyendo alternativas posibles, errores, y excepciones que puedan ocurrir a lo largo de la ejecución del caso de uso. Una instanciación de un caso de uso es llamada un escenario, y representa un uso específico del sistema. Por ejemplo, una instancia (escenario) de Firmando Póliza de Seguro podría ser “John Doe contacta el sistema por teléfono y firma una póliza para el Toyota Corolla que acaba de comprar.” En el UML, un caso de uso es representado por una elipse, como se muestra a continuación.

Figura 21: Notación del UML para un caso de uso

Identificación de los casos de uso

El proceso para identificar los casos de uso inicia con los actores previamente definidos. Para cada actor identificado se pueden hacer las siguientes preguntas:

Capítulo 4: Creando Casos de Uso

Página 65

¿Cuáles son las tareas para el actor, qué necesita hacer? ¿Qué funciones requiere el actor del sistema? ¿El actor creará, almacenará, cambiará, removerá o leerá algún tipo de información del sistema? ¿Necesitará el actor informar al sistema de cambios externos súbitos? ¿Necesita el actor ser informado acerca de ciertas ocurrencias en el sistema? ¿Podría el trabajo diario del actor ser simplificado mediante nuevas funciones del sistema (típicamente funciones no automatizadas en el sistema)?

Otras preguntas que no involucran uno de los actores actuales son:

¿Qué casos de uso soportarán y mantendrán el sistema? ¿Pueden todos los requerimientos funcionales ser realizados por los casos de uso? ¿Qué casos de uso crearán, almacenarán, cambiarán, removerán o leerán esta información? ¿Qué entrada/salida necesita el sistema y de dónde viene o a dónde va? ¿Cuáles son los problemas mayores con la implementación actual de este sistema?

Estas preguntas no indican que los casos de uso no tienen un actor asociado, solamente que los actores son reconocidos identificando primero los casos de uso. Un caso de uso debe estar siempre conectado a un actor. ¿Qué constituye un buen caso de uso?

A través de los años ha habido una gran discusión sobre la “bondad” de los casos de uso. Un problema encontrado es el nivel de detalle en los casos de uso. Es decir, ¿qué tan grandes (o pequeños) deberían ser?. No hay respuesta correcta a esa pregunta. Una regla que se podría aplicar es: “Un caso de uso típicamente representa una pieza mayor de funcionalidad que está completa de inicio a fin. Un caso de uso debe brindar algo de valor para un actor.” Por ejemplo, en un sistema de facturación e inventario, el cliente factura los productos y paga y luego esta transacción debe ser registrada en el inventario. ¿Son estos dos casos de uso o solamente uno? Creemos que en realidad es un solo caso de uso, pues representa lo que sucede desde el inicio hasta el final. La funcionalidad estaría totalmente incompleta si el sistema no actualizara el inventario después de facturar los productos. Documentación de los casos de uso

Breve descripción de los casos de uso

Una breve descripción del caso de uso indica el propósito u objetivos del caso de uso en unas cuantas oraciones; es decir, qué trata de alcanzar; proporcionando una definición de alto nivel de la funcionalidad proporcionada por el caso de uso. Los casos de uso son orientados a metas, y la meta de cada caso de uso debe ser aparente. La descripción es típicamente creada durante la fase de Inicio cuando el caso de uso es identificado. Esta descripción es hecha textualmente y especifica simple y consistentemente como los actores y los casos de uso interactúan. Se concentra en el comportamiento externo del sistema e ignora como las cosas son realizadas dentro del sistema. El lenguaje y terminología usada es la misma del cliente o usuario del sistema.

Página 66

Análisis y Diseño de Sistemas con el UML

Por ejemplo, en un sistema de registro académico, un caso de uso llamado Seleccionar Cursos para impartir sería descrito como: Este caso de uso es iniciado por el profesor. Proporciona la capacidad de añadir, eliminar, revisar e imprimir los cursos que el profesor desea impartir en la escuela. Flujo de eventos para los casos de uso

Cada caso de uso es también documentado con un flujo de eventos. El flujo de eventos para un caso de uso es la descripción de los eventos necesarios para cumplir el comportamiento requerido del caso de uso. El flujo de eventos es escrito en términos de lo que el sistema debería hacer, no cómo el sistema lo hará. Es decir, es escrito en el lenguaje del dominio, no en términos de la implementación. El flujo de eventos debe incluir:

Cuándo y cómo inicia el caso de uso: ¿Qué actor inicia la ejecución del caso de uso y bajo que circunstancias? Qué interacciones tiene el caso de uso con los actores: ¿Qué mensajes o eventos intercambian el caso de uso y los actores para notificarse, actualizarse o recuperar información, y ayudarse con decisiones? Qué datos son necesarios para el caso de uso: ¿Qué entidades en el sistema son usadas o modificadas? La secuencia normal de eventos para el caso de uso: ¿Qué debería describir el flujo de mensajes principal entre el sistema y los actores? La descripción de cualquier flujo alterno o excepcional: Un caso de uso puede tener ejecuciones alternas que dependen de excepciones o condiciones. Estas deben ser mencionadas pero con cuidado de no esconder el flujo principal de acciones del caso de uso general. El manejo de errores específicos es descrito como escenarios. Cuando y como el caso de uso finaliza: ¿Bajo que circunstancias finaliza el caso de uso?

La documentación del flujo de eventos típicamente es creada en la etapa de Elaboración en una forma iterativa. Al inicio, solamente una breve descripción de los pasos necesarios para llevar a cabo el flujo normal del caso de uso (la funcionalidad proporcionada por el caso de uso) es escrita. A medida que el análisis progresa, los pasos son refinados para añadir mayor detalle. Finalmente, los flujos excepcionales son añadidos al caso de uso (las “¿qué sucede si …” partes del flujo de eventos). Cada proyecto deberá usar una plantilla estándar para la creación de los documentos de flujo de eventos. La siguiente plantilla puede ser útil. X. X.1 X.2 X.3 X.4

Flujo de eventos para el caso de uso: <nombre> Precondiciones Flujo Principal Subflujos (si son aplicables) Flujos Alternos

Donde X es un número desde 1 hasta el número de casos de uso. Un flujo de eventos para el caso de uso Seleccionar Cursos para impartir mencionado anteriormente se muestra a continuación.

Capítulo 4: Creando Casos de Uso

1.0

Flujo de eventos para el caso de uso: Seleccionar Cursos para impartir

1.1

Precondiciones

Página 67

El subflujo Crear Grupos para los Cursos del caso de uso Mantener Cursos debe ejecutarse antes que este caso de uso inicie. 1.2

Flujo Principal El caso de uso inicia cuando el profesor ingresa al sistema y entra su login y password. El sistema verifica que este password es válido (E-1) y le pide al profesor que seleccione el semestre actual o un semestre futuro (E-2). El profesor introduce el semestre deseado. El sistema le pide al profesor que seleccione la actividad deseada: AÑADIR, ELIMINAR, REVISAR, IMPRIMIR o SALIR. Si la actividad seleccionada es AÑADIR, el S-1: Añadir un Grupo de Curso es realizado. Si la actividad seleccionada es ELIMINAR, el S-2: Borrar un Grupo de Curso es realizado. Si la actividad seleccionada es REVISAR, el S-3: Revisar Calendario es realizado. Si la actividad seleccionada es IMPRIMIR, el S-4: Imprimir el Calendario es realizado. Si la actividad seleccionada es SALIR, el caso de uso finaliza.

1.3

Subflujos S-1: Añadir un Grupo de Curso El sistema despliega la pantalla de cursos conteniendo un campo para nombre y número de curso. El profesor introduce el nombre y número de un curso (E-3). El sistema despliega los grupos disponibles para el curso (E-4). El profesor selecciona un grupo. El sistema enlaza el profesor al grupo seleccionado (E-5). El caso de uso inicia de nuevo. S-2: Borrar un Grupo de Curso El sistema despliega la pantalla de cursos conteniendo un campo para nombre y número de curso. El profesor introduce el nombre y número de un grupo (E-6). El sistema elimina el enlace entre el grupo y el profesor (E-7). El caso de uso inicia de nuevo. S-3: Revisar Calendario El sistema recupera (E-8) y despliega la información siguiente para todos los grupos para los cuales el profesor está asignado: nombre del curso, número del curso, número del grupo, días de la semana, tiempo y lugar. Cuando el profesor indica que ya terminó de revisar, el caso de uso inicia de nuevo. S-4: Imprimir Calendario El sistema imprime el calendario del profesor (E-9). El caso de uso inicia de nuevo.

1.3

Flujos Alternos E-1: Un password inválido fue introducido. El usuario puede introducir de nuevo el password o salir del caso de uso. E-2: Un semestre inválido fue introducido. El usuario puede introducir de nuevo el semestre o salir del caso de uso.

Página 68

Análisis y Diseño de Sistemas con el UML

E-3: Un combinación nombre/número de curso inválida fue introducida. El usuario puede introducir de nuevo una combinación válida o salir del caso de uso. E-4: Los grupos del curso no pueden ser desplegados. El usuario es informado de que esta opción no está disponible en el momento. El caso de uso inicia de nuevo. E-5: Un enlace entre el profesor y el grupo no puede ser creado. La información es guardada y el sistema creará el enlace posteriormente. El caso de uso continua. E-6: Una combinación nombre/número de curso inválida fue introducida. El usuario puede introducir de nuevo una combinación válida o salir del caso de uso. E-7: Un enlace entre el profesor y el grupo no puede ser eliminado. La información es guardada y el sistema eliminará el enlace posteriormente. El caso de uso continua. E-8: El sistema no puede recuperar la información del calendario. El caso de uso inicia de nuevo. E-9: El calendario no puede ser impreso. El usuario es informado de que esta opción no está disponible en el momento. El caso de uso inicia de nuevo. Recuerde que la descripción identifica lo que el sistema hace en relación con el actor externo, no cómo las cosas son hechas dentro del sistema. El texto debe ser claro y consistente para que un cliente pueda entenderlo y validarlo (estar de acuerdo que representa lo que él o ella quiere del sistema). Evite las oraciones complicadas que son difíciles de entender y fáciles de mal interpretar. El caso de uso puede ser descrito también en un diagrama de actividades, como se muestra en la siguiente figura. El diagrama de actividades muestra una secuencia de actividades, su ordenamiento, y decisiones opcionales que son tomadas para indicar que actividad va después. Tenga presente que el modelo de casos de uso debe ser fácil de comunicar al usuario y no debe ser descrito muy formalmente. El diagrama de actividades será descrito posteriormente.

Capítulo 4: Creando Casos de Uso

Página 69

Figura 22: Un diagrama de actividades usado para describir interacción entre el actor y el caso de uso (comprar bebida)

Como un complemento a una descripción de un caso de uso que contiene la descripción completa y general, una serie de escenarios actuales son usados para ilustrar lo que sucede cuando el caso de uso es instanciado. La descripción de escenario ilustra un caso específico, con los actores y casos de uso envueltos como instancias actuales. Los clientes pueden entender mejor un caso de uso complejo cuando un escenario más práctico describe el comportamiento del sistema. Note que una descripción de un escenario es un complemento y no un sustituto para la descripción del caso de uso.

Página 70

Análisis y Diseño de Sistemas con el UML

Relaciones entre los casos de uso

Los casos de uso están conectados a los actores a través de asociaciones, las cuales son llamadas a veces asociaciones de comunicación. Las asociaciones muestran los actores que se comunican con el caso de uso, incluyendo el actor que inicia su ejecución. La asociación es normalmente una asociación uno a uno sin dirección, lo que significa que la instancia del actor se comunica con una instancia del caso de uso, y que se comunican en ambas direcciones. Un caso de uso es nombrado por la instancia que realiza el caso de uso, tal como Firmando Póliza de Seguro, Actualizando Registro, y así sucesivamente, y es a menudo una frase y no una palabra. Las asociaciones pueden ser navegables en una sola dirección. La dirección de navegación de una asociación representa quien inicia la comunicación. Una asociación es representada como una línea que conecta los elementos relacionados. La navegación en una sola dirección es dibujada añadiendo una cabeza de flecha a la línea de asociación que denota la dirección. Entre casos de uso pueden haber dos tipos de relaciones: uses y extends. Relación uses

Múltiples casos de uso pueden compartir piezas de la misma funcionalidad. Esta funcionalidad es puesta en un caso de uso separado en lugar de documentarla en cada caso de uso que la necesita. Las relaciones uses son creadas entre el nuevo caso de uso y cualquier otro caso de uso que usa su funcionalidad. Cuando un caso de uso usa otro, el caso de uso entero debe ser usado (aunque las actividades en el caso de uso usado no tienen que estar en la misma secuencia, pueden estar mezcladas con las actividades del caso de uso que usa). Si un caso de uso nunca es usado por si mismo, es llamado un caso de uso abstracto. Una relación uses es dibujada como una flecha con un triángulo (flecha de generalización) en el final más cercano al caso de uso usado y con el estereotipo <<uses>> en la línea de asociación. Por ejemplo, muchos casos de uso en los sistemas de información inician con una verificación del usuario. Esta funcionalidad puede ser capturada en un caso de uso “Verificar Usuario,” el cual sería usado por otros casos de uso como fuera necesario. Relación extends

El que un caso de uso extiende otro caso de uso significa que el primer caso de uso incluye una parte del comportamiento del caso de uso que es extendido. No tiene que incluir el comportamiento completo; puede escoger que partes del comportamiento del caso de uso generalizado desea reutilizar. El caso de uso que es extendido debe ser completo. Debido a que los casos de uso son descritos en texto, puede ser difícil imaginarse que partes de un caso de uso son utilizados, cuales son refinadas, y cuales son añadidas. Una relación extends es usada para mostrar:

Comportamiento opcional o excepcional. Comportamiento que se da solamente bajo ciertas condiciones, como disparar una alarma. Varios flujos diferentes que pueden correrse basados en una selección del actor.

Por ejemplo, un caso de uso que monitorea el flujo de paquetes en una banda de aeropuerto puede ser extendido por una alarma sin los paquetes se atoran. Una relación extends es dibujada como una flecha

Capítulo 4: Creando Casos de Uso

Página 71

con un triángulo (flecha de generalización) en el final más cercano al caso de uso extendido y con estereotipo <<extends>> en la línea de asociación.

Figura 23: Relaciones en los Casos de Uso

Es hasta que todos los casos de uso han sido descritos que los desarrolladores tienen el conocimiento completo para identificar las relaciones posibles en los casos de uso (relaciones con actores y relaciones uses y extends entre ellos); puede ser peligroso intentar lo contrario. Durante esta actividad, conteste las siguientes preguntas:

¿Tienen todos los actores envueltos en el caso de uso una asociación con él? ¿Hay similitudes entre una serie de actores que representen un rol común y que puedan ser descritos como un actor generalizado? ¿Hay similitudes entre una serie de casos de uso que representen un rol común y que puedan ser descritos como una relación uses a un caso de uso? ¿Hay casos especiales de un caso de uso que pueden ser descritos como una relación extends? ¿Hay algunos actores o casos de uso sin asociaciones de comunicación? Si es así, algo está mal: ¿Por qué están los actores ahí? ¿Hay requerimientos funcionales conocidos, pero no manejados por un caso de uso? Si es así, cree un caso de uso para ese requerimiento.

Probando los casos de uso

Los casos de uso tienen un propósito en las pruebas. Dos tipos de pruebas son realizadas: verificación y validación. La verificación confirma que el sistema es desarrollado correctamente o de acuerdo con las especificaciones hechas. La validación asume que el sistema bajo desarrollo es el que el cliente o usuario final realmente necesita. La validación es hecha en el proceso de desarrollo. Tan pronto como hay un modelo de casos de uso finalizado (o quizás durante su desarrollo) el modelo es presentado y discutido con los clientes y usuarios finales. Ellos deben validar si el modelo cumple de forma correcta y completa con sus expectativas del sistema; específicamente, la forma en que el sistema proporciona la funcionalidad para ellos. Para hacer esto, el desarrollador debe asegurarse que los clientes realmente entienden el modelo y su significado, para evitar la aprobación de algo que no es aceptable. Durante este proceso generalmente surgen ideas y preguntas que necesitan ser agregadas al modelo de casos de uso antes de la validación final. La validación también puede ser hecha en las pruebas del sistema, pero el problema

Página 72

Análisis y Diseño de Sistemas con el UML

con esto es que si el sistema no cumple con los requerimientos del usuario, el proyecto completo pueda tener que ser trabajado desde el inicio. La verificación prueba que el sistema trabaja de acuerdo con sus especificaciones. Por lo tanto, no puede ser hecha hasta que hallan partes del sistema funcionando. Entonces, es posible probar que el sistema se comporta bajo las especificaciones de sus usuarios, que los casos de uso descritos en el modelo trabajan, y que se comportan como es establecido en la descripción. Una buena técnica implementada durante la definición y prueba de los casos de uso se llama recorrer los casos de uso. En esta técnica, diferentes personas en el grupo juegan los roles de los actores y el sistema en un caso de uso específico. La persona que juega el rol del actor inicia diciendo lo que el actor hace con el sistema. Eso resulta en el sistema ejecutando un caso de uso específico que es iniciado por esa acción; la persona que juega el rol del sistema entonces dice lo que hace cuando el caso de uso se ejecuta. Los desarrolladores no envueltos en el juego toman notas y tratan de encontrar deficiencias en los casos de uso descritos por los jugadores. Típicamente, se encuentra que ciertas alternativas no son descritas del todo y algunas acciones no son descritas con el detalle suficiente. Mientras más conocimiento del uso del sistema tengan los jugadores, mejor serán las pruebas de los casos de uso. De esta forma, cambiando quién juega los diferentes roles resulta en vistas e interpretaciones variadas, dando información a los modeladores sobre cómo hacer la descripción del caso de uso menos ambigua y anotando cosas que omitieron. Cuando los roles de todos los actores son jugados y todos los casos de uso son ejecutados de esta forma, la prueba del modelo de casos de uso está completa. Metas del usuario e interacciones del sistema

Un aspecto importante que se encuentra con los casos de uso es la diferencia entre las metas del usuario y las interacciones del sistema. Por ejemplo, considere la función de estilos encontrada en la mayoría de los procesadores de palabras. Con las interacciones del sistema, podría decir que los casos de uso incluirían “definir un estilo,” “cambiar un estilo,” y “mover un estilo de un documento a otro.” Sin embargo, esos casos de uso reflejan lo que el usuario está tratando de hacer con el sistema y no las metas que trata de alcanzar. Las metas reales del usuario podrían ser descritas en términos como “asegurar un formato consistente para un documento” y “dar el mismo formato de un documento a otro.” La diferencia entre las metas del usuario y las interacciones del sistema no están presentes en todos las situaciones. Por ejemplo, el proceso de indexar un documento es casi lo mismo desde ambas perspectivas. Sin embargo, donde si difieren es importante tomar en cuenta la diferencia. Ambos estilos de casos de uso tienen sus aplicaciones. Las interacciones del sistema son mejores para propósitos de planeación; pensar sobre las metas del usuario es importante para considerar formas alternas de satisfacer las metas. Si se apura mucho hacia las interacciones del sistema, obviará formas creativas de satisfacer las necesidades del usuario más eficientemente de lo que podría tomando la primera opción obvia. En cada caso es una buena idea preguntarse, “¿Por qué hicimos eso?” La pregunta usualmente lleva a un mejor entendimiento de las metas del usuario. En el trabajo real se debe enfocar primero en las metas del usuario y después en los casos de uso necesarios para satisfacerlas. Al final de la etapa de elaboración se debe tener por lo menos un conjunto de interacciones del sistema para cada meta del usuario que se halla identificado. (o por lo menos para las metas del usuario que se pretendan soportar en la primera entrega).

Capítulo 5: Encontrando Clases ¿Qué es un Objeto?

¿Qué es una Clase?

Paquetes

Clases Parametrizadas

Perspectivas

Capítulo 5: Encontrando Clases

Página 75

n el modelaje orientado a objetos, las clases, objetos y sus relaciones son los elementos principales del modelaje. Las clases y objetos modelan lo que hay en el sistema que estamos tratando de describir, y las relaciones entre ellas muestran como están estructurados en términos de cada uno. La clasificación ha sido usada por miles de años para simplificar descripciones de sistemas complejos, de tal forma que podamos entenderlos más fácilmente. Cuando se usa programación orientada a objetos para construir software, las clases y relaciones se convierten en el código real.

¿Qué es un Objeto? Un objeto es una representación de una entidad, ya sea del mundo real o conceptual. Un objeto puede representar algo concreto, como el camión de Joe o mi computadora; o un concepto, como un proceso químico, una transacción bancaria, una orden de compra, la historia de crédito de María, o una tasa de interés. Podría ser parte de cualquier tipo de sistema, por ejemplo, una máquina, una organización, o un negocio. Un objeto es un concepto, abstracción, o cosa con fronteras y significado bien definidos para una aplicación. Cada objeto en un sistema tiene tres características: estado, comportamiento e identidad. El estado de un objeto es una de las posibles condiciones en la cual puede existir. El estado de un objeto típicamente cambia en el tiempo, y es definido por los valores de un conjunto de propiedades (llamadas atributos) más las relaciones que pueda tener con otros objetos. Por ejemplo, un Grupo puede estar abierto o cerrado. Si el número de grupos registrados para el curso pasa de un límite predeterminado, el Grupo se cierra. El comportamiento determina cómo un objeto responde a peticiones de otros objetos, y tipifica todo lo que el objeto puede hacer. El comportamiento es implementado por un conjunto de operaciones para el objeto. Por ejemplo, un Grupo podría tener las operaciones Añadir un estudiante y Eliminar un estudiante. La identidad significa que cada objeto es único – aún si su estado es idéntico al de otro objeto. Por ejemplo, Matemáticas I – A1 y Matemáticas I – A2 son dos objetos Grupo del mismo Curso pero tienen una identidad única. En el UML, los objetos son representados como rectángulos, y el nombre del objeto es subrayado como se muestra a continuación.

Figura 24: Notación del UML para un Objeto

Objetos por referencia

Los objetos por referencia son cosas como Cliente. Aquí, la identidad es muy importante, porque usualmente se desea que solamente un objeto de software represente a un cliente del mundo real. Cualquier objeto que haga referencia a un objeto cliente lo hará a través de una referencia o puntero; todos los objetos que hagan referencia a este cliente harán referencia al mismo objeto. De esa forma, los cambios al cliente están disponibles a todos los usuarios del cliente.

Página 76

Análisis y Diseño de Sistemas con el UML

Si tiene dos referencias a un cliente y desea ver si son el mismo, usualmente compara sus identidades. Las copias pueden no ser permitidas y si lo son se hacen raramente, tal vez para propósitos de respaldos o replicación a través de una red. Si se hacen copias se tiene que buscar una forma de sincronizar los cambios. Objetos por valor

Los objetos por valor son cosas como Fecha. A menudo se tienen múltiples objetos que representan el mismo objeto del mundo real. Por ejemplo, es normal tener cientos de objetos que designan 1-Ene-99. Estas son todas copias intercambiables. Nuevas fechas son creadas y destruidas frecuentemente. Si tiene dos fechas y desea ver si son la misma, no se miran sus identidades – se miran los valores que representan. Esto significa usualmente que tienen que escribir un operador de igualdad, el cual para las fechas haría una prueba en el año, mes, y día. Usualmente el objeto que referencia 1-Ene-99 tiene su objeto dedicado, pero a veces se tienen fechas compartidas. Los objetos por valor deben ser inmutables. En otras palabras, no debe ser capaz de tomar un objeto fecha 1-Ene-99 y cambiarlo a 2-Ene-99. Lo que se tiene que hacer es crear un objeto nuevo 2-Ene-99 y enlazarlo al primer objeto. La razón para esto es que si la fecha fuera compartida, actualizaría la fecha de otro objeto en una forma impredecible. Como una regla general, no cambie los objetos por valor. En días ya pasados, la diferencia entre objetos por referencia y objetos por valor era clara. Los objetos por valor eran los valores interconstruidos del sistema de tipos. Ahora puede extender el sistema de tipos con sus propias clases, así que este problema requiere mayor pensamiento. Dentro del UML, los atributos son usualmente usados para objetos por valor y las asociaciones para objetos por referencia. También puede usar composición para objetos por valor.

¿Qué es una Clase? Una clase es una descripción de un grupo de objetos con propiedades (atributos), comportamiento (operaciones), relaciones a otros objetos, y semántica comunes. Por lo tanto, una clase es una plantilla para crear objetos. Cada objeto es una instancia de una clase y por lo tanto, tiene un valor para los atributos y acceso a las operaciones especificadas por la clase. Los objetos se relacionan con la clase similarmente a la relación entre una variable y un tipo de datos en un lenguaje de programación ordinario. Las clases son usadas para describir sistemas y clasificar los objetos que identificados en el mundo real. Considere a Charles Darwin, que usó clases para describir la raza humana. Combinó las clases mediante herencia para describir su teoría de la evolución. Una buena clase captura una y solo una abstracción – debería tener un tema principal. Por ejemplo, una clase que tiene la capacidad de mantener información sobre dos entidades no es una buena clase, pues no tiene un tema principal; esta clase debe ser dividida en dos clases relacionadas. Cuando modelamos y construimos sistemas de negocio, sistemas de información, máquinas u otros sistemas, las clases deben ser nombradas usando el vocabulario del dominio para hacer los modelos entendibles y fáciles de comunicar. Un sistema basado en los conceptos primarios del negocio puede ser fácilmente rediseñado para incorporar nuevas leyes, estrategias, reglas, etc., porque sólo hay que ajustar las diferencias entre el negocio viejo y el nuevo negocio. Cuando se modelan máquinas, es útil

Capítulo 5: Encontrando Clases

Página 77

imitar su apariencia y comportamiento en el mundo real tanto como sea posible. Es importante que los modelos sean fáciles de discutir, fáciles de verificar contra los requerimientos funcionales y fáciles de mantener. Cuando los modelos se construyen basados en cómo sus contrapartes del mundo real se miran y comportan la orientación a objetos encaja perfectamente. El nombre de la clase debe ser un nombre singular que caracterice de la mejor forma la abstracción. Se pueden usar acrónimos a menos que el acrónimo tenga diferente significado para diferentes personas, en cuyo caso el nombre completo debe ser usado. Si una clase es nombrada con un acrónimo, el nombre completo debe ser contenido en la documentación de la clase. Una clase podría ser una descripción de un objeto en cualquier tipo de sistema – de información, técnico, de tiempo real empotrado, distribuido, de software, y de negocio. Los artificios en un negocio, es decir, información que debería ser almacenada o analizada y los roles que juegan los actores en el negocio a menudo se transforman en clases en los sistemas de información y de negocios. Ejemplos de clases en sistemas de información y de negocios son: cliente, acuerdo, factura, débito, activo. Las clases en los sistemas técnicos a menudo involucran objetos técnicos como los dispositivos usados en los sistemas. Ejemplos de clases en los sistemas técnicos son: sensor, pantalla, tarjeta de entrada/salida, máquina, botón, clase de control. Los sistemas de software tienen clases que representan entidades de software en un sistema operativo. Ejemplos de clases en un sistema de software son: archivo, programa ejecutable, dispositivo, icono, ventana, barra de desplazamiento. Las restricciones de las herramientas pueden también afectar los estándares de nombramiento establecidos para un proyecto. En Rational Rose, un actor es una clase con el estereotipo <<Actor>>. Por lo tanto, no se puede tener un actor y una clase con el mismo nombre. Lo importante es escoger un estándar para nombrar clases que esté en conformidad con el proyecto y asegúrese que todo el mundo siga ese estándar. En el UML las clases son representadas como rectángulos con compartimentos. El compartimento superior contiene el nombre de la clase en negrillas, el compartimento medio contiene la estructura de la clase (atributos), y el compartimento inferior contiene el comportamiento de la clase (operaciones). La sintaxis usada para los compartimentos es independiente de los lenguajes de programación. Una clase se muestra a continuación.

Figura 25: Una clase en el UML

Es importante notar que en esta etapa solamente estamos descubriendo las clases del sistema, su comportamiento y estructura serán descubiertos posteriormente. Clases y Estereotipos

Las clases pueden tener estereotipos. Igual que anteriormente, un estereotipo proporciona la capacidad de crear un nuevo tipo de elemento de modelaje, es decir nuevos tipos de clases. Algunos estereotipos

Página 78

Análisis y Diseño de Sistemas con el UML

comunes para las clases son entity (entidad), boundary (frontera), control, utility (utilidad) y exception (excepción). La esencia del estereotipo es que sugiere cierta responsabilidad para una clase El estereotipo para una clase es mostrado arriba del nombre de la clase entre guillemets (<< >>). Si se desea, un icono gráfico o un color específico puede ser asociado con un estereotipo. Por ejemplo, todas las clases con el estereotipo <<Exception>> (excepción) pueden ser mostradas en rojo. Una clase con estereotipo es mostrada en la siguiente figura.

Figura 26: Clase con un Estereotipo

Identificación de las Clases

Un libro de recetas para encontrar clases no existe. Como Grady Booch dice, “¡Esto es difícil!.” El Proceso Unificado recomienda encontrar las clases para un sistema bajo desarrollo buscando las clases de entidad (entity), frontera (boundary) y control. Estos tres estereotipos conforman un punto de vista modelo-vista-controlador y permiten al analista particionar el sistema separando el dominio, la vista y el control necesitados por el sistema. Debido a que el proceso de análisis y diseño es iterativo, la lista de clases cambiará a medida que pasa el tiempo. El conjunto inicial de clases probablemente no será el conjunto de clases que eventualmente sea implementado. Por lo tanto, el término clase candidata es usualmente usado para describir el conjunto inicial de clases encontradas para un sistema. Algunas preguntas que se pueden hacer cuando se busquen clases son:

¿Hay información que debe ser almacenada o analizada? Si hay cualquier tipo de información que tiene que ser almacenada, transformada, analizada, o manejada de cualquier otra forma, entonces es un posible candidato para una clase. La información podrían ser conceptos que deben estar siempre registrados en el sistema o eventos o transacciones que ocurran en un momento específico. ¿Hay sistemas externos? Si es así, son de interés cuando modelamos. El sistema externo podría ser visto como clases que nuestro sistema contiene o con las que debería interactuar. ¿Hay patrones, librerías de clase, componentes, etc.? Si tenemos algunos de ellos de proyectos anteriores, colegas, o fabricantes, normalmente contienen clases candidatas. ¿Hay dispositivos que el sistema debe manejar? Cualquier dispositivo técnico conectado al sistema se convierte en clases, especialmente en modelos de negocio. ¿Qué roles juegan los actores en el negocio? Estos roles pueden ser vistos como clases; por ejemplo, usuario, operador del sistema, cliente, etc.

Si se tiene una especificación de requerimientos o análisis de negocio, éste debe ser usado como base para encontrar clases.

Capítulo 5: Encontrando Clases

Página 79

Clases de entidad

Una clase de entidad modela información y comportamiento asociado que es generalmente de larga duración. Este tipo de clase puede reflejar una entidad del mundo real, o puede ser necesaria para realizar tareas internas del sistema. Típicamente son independientes de sus alrededores; es decir, no son sensibles a la forma en que los alrededores se comunican con el sistema. Muchas veces, son independientes de la aplicación, lo que significa que pueden ser usadas en más de una aplicación. El primer paso es examinar las responsabilidades documentadas en el flujo de eventos para los casos de uso identificados (lo que el sistema debe hacer). Las clases de entidad típicamente son clases que son necesarias por el sistema para realizar alguna responsabilidad. Los nombres y frases usadas para describir las responsabilidades pueden ser un buen punto de inicio. La lista inicial de nombres debe ser filtrada debido a que podría contener nombres que están fuera del alcance del problema, nombres que son solamente expresiones del lenguaje, nombres que son redundantes, y nombres que son descripciones de estructuras de clases. Las clases de entidad típicamente son encontradas temprano en la etapa de elaboración. Son llamadas a menudo clases de dominio porque usualmente se refieren a abstracciones de entidades del mundo real. Clases de frontera

Las clases de frontera manejan la comunicación entre el entorno del sistema y el interior del mismo. Pueden proporcionar la interfaz a un usuario u otro sistema (la interfaz a un actor). Constituyen la parte dependiente del entorno. Las clases de frontera son usadas para modelar las interfaces del sistema. Cada par físico actor/escenario es examinado para descubrir clases de frontera. Las clases de frontera descubiertas en la fase de Elaboración son típicamente a un nivel alto. Por ejemplo, se puede modelar una ventana pero no cada uno de sus cuadros de diálogo y botones. En esta etapa se están documentando los requerimientos de la interfaz del usuario, no implementándolos. Los requerimientos de interfaz tienden a ser muy vagos – los términos “amigable al usuario” y “flexible” parecen ser usados mucho. Pero amigable al usuario significa diferentes cosas para diferentes personas. Es aquí donde el prototipado puede ser muy útil. El cliente puede ver y sentir el sistema y capturar verdaderamente lo quiere decir amigable al usuario. El qué es capturado, así como la estructura y comportamiento de la clase de frontera. Durante el diseño, estas clases son refinadas para tomar en consideración los mecanismos de interfaz seleccionados – es decir, como son implementados. Las clases de frontera son también añadidas para facilitar la comunicación con otros sistemas. Durante el diseño, estas clases son refinadas para tomar en cuenta los protocolos de comunicación escogidos. Clases de control

Las clases de control modelan comportamiento de secuencia específico a uno o más casos de uso. Las clases de control coordinan los eventos necesarios para realizar el comportamiento especificado en el caso de uso. Puede pensar de una clase de control como la que “corre” o “ejecuta” el caso de uso. Las clases de control típicamente son clases dependientes de la aplicación.

Página 80

Análisis y Diseño de Sistemas con el UML

En las etapas iniciales de la fase de Elaboración, una clase de control es añadida para cada par actor/caso de uso. La clase de control es responsable por el flujo de eventos en el caso de uso. El uso de las clases de control es muy subjetivo. Muchos autores sienten que el uso de clases de control resulta en el comportamiento separado de los datos. Esto puede ocurrir si sus clases de control no son escogidas sabiamente. Si una clase de control está haciendo más de que dar secuencia, entonces está haciendo mucho. Las clases de control bajo ninguna circunstancia deben realizar operaciones sobre otras clases otras que dirigir la secuencia. Las clases de control deben saber cuándo hacer las cosas, pero las clases de entidad y de frontera son las que deben saber cómo hacerlas. La agregación de una clase de control por par actor/caso de uso es solamente al inicio – a medida que el análisis y diseño continúan, las clases de control pueden ser eliminadas, divididas o combinadas. Documentación de las clases

A medida que se crean clases, deben ser documentadas también. La documentación debe contener el propósito de la clase y no la estructura de la clase. Una dificultad en nombrar o documentar una clase indica que puede no ser una buena abstracción. La siguiente lista tipifica las cosas que pueden ocurrir a medida que las clases son nombradas y documentadas:

Se puede identificar un nombre y una definición clara y concisa – buena clase candidata. Se puede identificar un nombre, pero la definición es la misma que otra clase – combine las clases. Se puede identificar un nombre, pero necesita un libro para documentar el propósito – divida la clase. No puede identificar un nombre o definición – se necesita más análisis para determinar las abstracciones correctas.

Paquetes Si un sistema contuviera solamente unas cuantas clases, podrían ser manejadas fácilmente. La mayoría de los sistemas están compuestos de muchas clases, y por lo tanto necesitan un mecanismo para agruparlas juntas por facilidad de uso, mantenibilidad, y reutilización. Aquí es donde el concepto de paquete es útil. Un paquete en la vista lógica de un modelo es una colección de paquetes o clases relacionados. Agrupando las clases en paquetes podemos tener una vista de mayor nivel del modelo (viendo los paquetes) o podemos ver a mayor profundidad el modelo mirando los contenidos del paquete. En general, un paquete es un mecanismo de agrupación, por el cual todos los tipos de modelos pueden ser enlazados. En el UML un paquete es definido como: “un mecanismo de propósito general para organizar elementos en grupos semánticamente relacionados.” Como mecanismo de agrupación, el paquete no tiene ninguna semántica (significado). Por lo tanto, los paquetes tienen solamente significado durante el trabajo de modelaje, pero no necesariamente en el sistema ejecutable. Un paquete es dueño de sus elementos, y los elementos de un modelo no pueden pertenecer a más de un paquete. Si el sistema es complejo, los paquetes pueden ser creados temprano en la fase de Elaboración para facilitar la comunicación. Para sistemas más simples, las clases encontradas temprano en el análisis pueden ser agrupadas en un paquete – el sistema mismo. A medida que progresa el análisis y el diseño,

Capítulo 5: Encontrando Clases

Página 81

el concepto de paquete será usado para agrupar las clases que son necesarias para realizar las decisiones de arquitectura hechas para el sistema. En el UML los paquetes son representados como carpetas como se muestra en la figura siguiente:

Figura 27: Notación del UML para un Paquete

Un paquete puede tener visibilidad igual que las clases, mostrando como otros paquetes pueden accesar sus contenidos. El UML define cuatro grados de visibilidad: private (privado), protected (protegido), public (público), e implementation (implementación). La visibilidad por defecto es pública, que quiere decir que otros elementos pueden ver y usar los contenidos en el paquete. Privado indica que solamente el paquete que es dueño del elemento o un paquete que importa el elemento puede usarlo. Protegido indica que solamente el paquete que posee o importa el elemento puede usarlo, pero es también posible accesar los elementos en el paquete generalizado por paquetes especializados. Implementación es similar a privado, pero los elementos que no tienen dependencia a un paquete no pueden usar los elementos dentro del paquete. La visibilidad para las clases será discutida cuando se analice el diseño de las clases.

Clases Parametrizadas Las clases parametrizadas (también llamadas plantillas) son soportadas en lenguajes de programación como C++, mientras otros como Java no tienen equivalente. Los parámetros de la clase parametrizada son usados para crear una clase real que puede ser usada. Por lo tanto, una clase parametrizada es una clase que no ha sido completamente especificada en donde la especificación final es hecha a través de los parámetros de la clase. Los parámetros pueden ser clases o tipos primitivos, por ejemplo, integer o Boolean. La clase parametrizada es usada para especificar grupos de clases. Una clase parametrizada puede ser un arreglo, donde las clases instanciadas de la plantilla podrían ser entonces un arreglo de carros, un arreglo de colores, etc. La clase parametrizada tiene una lista de parámetros que contiene el nombre y tipo de cada parámetro, separados por comas. Si uno de los parámetros es una clase, entonces es opcional mostrar el tipo en la lista de parámetros. La lista de parámetros es mostrada dentro de un rectángulo punteado en la esquina superior derecha del rectángulo de la clase parametrizada. Una instanciación de la plantilla es mostrada con un rectángulo de clase ordinario con una relación de dependencia hacia la plantilla con el nombre de la clase describiendo de qué plantilla es instanciado y con cuáles parámetros, por ejemplo, Arreglo<Carro,100>. Es posible también mostrar la relación entre una clase instanciada y su plantilla mediante una relación de refinamiento con el estereotipo <<bind>> (enlazar) seguido de los parámetros reales usados en la clase.

Página 82

Análisis y Diseño de Sistemas con el UML

Figura 28: Clase parametrizada y dos formas de mostrar clases instanciadas a partir de ella

Perspectivas Existe un aspecto muy sutil sobre los diagramas de clase con relación a la forma en que son usados. Esta sutileza no es documentada usualmente, pero tiene un impacto en la forma en que se debe interpretar un diagrama. Se puede decir que existen tres perspectivas que se pueden usar con los diagramas de clases.

Conceptual. Si se toma la perspectiva conceptual, se dibuja un diagrama que representa los conceptos del dominio bajo estudio. Estos conceptos se relacionarán naturalmente con las clases que los implementan, pero a menudo no hay un mapeo directo. Un modelo conceptual debe ser dibujado con poca o ninguna importancia del software que lo implementará, por lo que puede ser considerado independiente del lenguaje. Especificación. Aquí se mira el software, pero se miran las interfaces no la implementación. Por lo tanto se miran tipos en vez de clases. La orientación a objetos pone una gran diferencia entre la interfaz y la implementación, pero esto es obviado en la práctica porque la noción de clase en un lenguaje orientado a objetos combina la interfaz y la implementación. Por eso a mundo se oye que las interfaces son llamadas tipos y la implementación de esas interfaces son llamadas clases. Esto está cambiando; un tipo representa una interfaz que puede tener muchas implementaciones diferentes. Implementación. En esta vista, se ven las clases de implementación. Esta es la vista más usada a menudo, pero en muchos aspectos es mejor tomar la vista de especificación.

Entender la perspectiva es crucial para dibujar y leer los diagramas de clase. Desafortunadamente las líneas entre perspectivas no son claras, y la mayoría de modeladores no las toman en cuenta cuando están dibujando. Un diagrama debe ser dibujado desde una perspectiva clara. Cuando se lea un diagrama debe conocerse desde que perspectiva fue dibujado; ese conocimiento es esencial para interpretar el diagrama correctamente.

Cap铆tulo 6: Descubriendo Interacci贸n entre los Objetos Realizaci贸n de los casos de uso

Documentando los escenarios

Interacciones entre los objetos

Comparando los tres diagramas diferentes

Diagramas de secuencia

Diagramas de colaboraci贸n

Capítulo 6: Descubriendo Interacción entre los Objetos

Página 85

odos los sistemas tienen una estructura estática y una estructura dinámica. El UML proporciona diagramas para capturar y describir estos dos aspectos. Los diagramas de clase son usados para describir y expresar la estructura estática de un sistema – las clases, objetos y sus relaciones. Los diagramas de secuencia, colaboración, estados y actividades son usados para expresar el comportamiento (dinámica) del sistema, y para demostrar cómo los objetos interactúan dinámicamente en diferentes momentos durante la ejecución de un sistema.

Los diagramas de clase modelan cosas intelectuales y físicas y las relaciones entre esas cosas. Describir la estructura estática de un sistema puede revelar lo que el sistema contiene y cómo esas cosas están relacionadas, pero no explica cómo esas cosas cooperan para realizar sus tareas y proporcionar la funcionalidad del sistema. La comunicación entre un conjunto de objetos para generar alguna función es llamada una interacción, la cual puede ser descrita en tres tipos de diagramas: secuencia, colaboración y actividad.

Realización de los casos de uso El diagrama de casos de uso presenta una vista exterior del sistema. La funcionalidad de los casos de uso es capturada en el flujo de eventos. Los escenarios son usados para describir cómo los casos de uso son realizados como interacciones entre sociedades de objetos. Un escenario es una instancia de un caso de uso – es un camino a través del flujo de eventos para el caso de uso. Los escenarios son desarrollados para ayudar a identificar los objetos, las clases, y las interacciones de los objetos necesarias para llevar a cabo una parte de funcionalidad especificada por el caso de uso. Los escenarios documentan decisiones sobre cómo las responsabilidades especificadas en los casos de uso son distribuidas entre los objetos y las clases en el sistema. También proporcionan un medio excelente de comunicación para ser usado en la discusión de los requerimientos del sistema con los clientes. “Los escenarios hablan el lenguaje del usuario final y del experto del dominio, y por lo tanto proporcionan un medio que expresa sus expectativas sobre el comportamiento deseado del sistema a sus desarrolladores.”2 Cada caso de uso es una red de escenarios – escenarios primarios (el flujo normal para el caso de uso) y escenarios secundarios (la lógica “qué sí …” del caso de uso). Esto significa que hay varios escenarios para todos los casos de uso. Durante la etapa temprana del análisis es seguro decir que mirar a los escenarios principales para cada caso de uso identificado es suficiente. Cuando encuentre que cada nuevo escenario está repitiendo muchos pasos de los escenarios previamente identificados ha alcanzado la línea final. “Esta fase del análisis debería llegar al final una vez que el grupo ha elaborado aproximadamente 80% de los escenarios principales de un sistema junto con una representación selectiva de los secundarios. Si elabora más el análisis no obtendrá mayores resultados; si elabora menos no tendrá un suficiente entendimiento del comportamiento deseado del sistema para entender propiamente los riesgos.”3 Los principios del UML para la realización de los casos de uso son:

2 3

Un caso de uso es realizado en una colaboración. Una colaboración muestra una implementación interna dependiente de los casos de uso en términos de clases/objetos y sus relaciones (llamada el contexto de la colaboración) y sus interacciones para alcanzar la funcionalidad (llamada la interacción de la colaboración). El símbolo para una colaboración es una elipse que tiene el nombre de la colaboración. Booch, Grady. Object Solutions, Redwood City, CA: Addison-Wesley, 1995 Booch, Grady. Object Solutions, Redwood City, CA: Addison-Wesley, 1995

Página 86

Análisis y Diseño de Sistemas con el UML

Una colaboración es representada en el UML como una serie de diagramas que muestran el contexto y la interacción entre los participantes en la colaboración. Hay una serie de clases que participan en una colaboración (y en una instancia de colaboración hay objetos). Los diagramas son colaboración, secuencia y actividad. El tipo de diagrama a usar para dar una imagen completa de la colaboración depende del caso actual. En algunos casos, un tipo de diagrama puede ser suficiente, en otros casos puede necesitarse una combinación de diagramas. Un escenario es una instancia de un caso de uso o una colaboración. El escenario es un camino de ejecución específico (un flujo de eventos) y representa una instanciación de un caso de uso (un uso del sistema). Cuando un escenario es visto como un caso de uso, sólo el comportamiento hacia el exterior es descrito. Cuando un escenario es visto como una instancia de una colaboración, la implementación interna de las clases envueltas, sus operaciones y su comunicación es descrita.

La tarea de realizar un caso de uso consiste en transformar los diferentes pasos y acciones en el flujo de eventos del caso de uso en clases, operaciones en esas clases, y relaciones entre ellas. Esto se conoce como asignar la responsabilidad de cada paso en el caso de uso a las clases que participan en la colaboración que realiza el caso de uso. En esta etapa, se encuentra una solución que indica el comportamiento externo del caso de uso especificado; es descrito en términos de una colaboración dentro del sistema. Cada paso en la descripción del caso de uso es transformado en operaciones en las clases que participan en la colaboración que realiza el caso de uso. Un paso en el caso de uso es transformado en un número de operaciones en las clases; es poco probable que halla una relación uno a uno entre una acción el caso de uso y una operación en la interacción entre objetos de las clases participantes. También note que una clase puede participar en varios casos de uso. La responsabilidad total de la clase es la integración de todos los roles que juega en los casos de uso. La relación entre un caso de uso y su implementación en términos de una colaboración es mostrada como una relación de refinamiento, o como un hipervínculo invisible en una herramienta que hace posible cambiarse de un caso de uso a la colaboración que lo implementa. Asignar responsabilidades a las clases satisfactoriamente es una tarea que requiere cierta experiencia. Como siempre, es un trabajo altamente iterativo. El desarrollador trata diferentes posibilidades, gradualmente mejorando su solución hasta que tiene un modelo que realiza la funcionalidad y es lo suficientemente flexible para permitir cambios futuros. En la siguiente figura un caso de uso es realizado en una colaboración, y un número de clases participan en la colaboración. Para realizar un caso de uso, la responsabilidad de cada paso en el caso de uso debe ser transformada en colaboraciones entre las clases en términos de relaciones y operaciones.

Capítulo 6: Descubriendo Interacción entre los Objetos

Página 87

Figura 29: Realización de los casos de uso en colaboraciones

Documentando los escenarios El flujo de eventos para un caso de uso es capturado en texto, mientras los escenarios son capturados en diagramas de interacción. Hay dos tipos de diagramas de interacción – diagramas de secuencia y diagramas de colaboración; además, se pueden usar diagramas de actividad. Cada diagrama es una vista gráfica del escenario.

Interacciones entre los objetos En la programación orientada a objetos, una interacción entre dos objetos es realizada como un mensaje enviado de un objeto a otro. En este contexto, es importante que la palabra “mensaje” sea entendida como una simple llamada de una operación que un objeto hace sobre otro, no tanto como un mensaje en un protocolo de comunicaciones; aunque también puede ser un mensaje enviado a través de un mecanismo de comunicación (a través de una red o internamente dentro de la computadora); sin embargo, esto es más común en sistemas de tiempo real. Los mensajes son mostrados en todos los diagramas dinámicos (secuencia, colaboración, estado y actividad) como un medio de comunicación entre objetos. Un mensaje es dibujado como una línea con una flecha entre la fuente y el destino. El tipo de flecha indica el tipo de mensaje. Los tipos de mensajes usados en el UML son:

Simple. Representa un flujo plano de control. Muestra cómo el control del sistema es pasado de un objeto a otro sin describir ningún detalle sobre la comunicación. Este tipo de mensaje es usado cuando los detalles de la comunicación no son conocidos o no son relevantes en el diagrama. Es también usado para mostrar el retorno de un mensaje sincrónico; es decir, es dibujado del objeto que maneja el mensaje hacia el que inició el mensaje para mostrar que el control es regresado. Sincrónico. Un flujo anidado de control, típicamente implementado como una llamada a una operación. La operación que maneja el mensaje es completada (incluyendo cualquier otros mensajes que sean enviados como parte del manejo) antes que el objeto llamador siga su ejecución. Asincrónico. Un flujo de control asincrónico, donde no hay un retorno explícito al objeto llamador y donde se continua ejecutando después de enviar el mensaje sin esperar que sea manejado. Esto es típicamente usado en sistemas en tiempo real donde los objetos se ejecutan concurrentemente.

Página 88

Análisis y Diseño de Sistemas con el UML

Figura 30: Notación de los tipos de mensajes

Los mensajes simples y sincrónicos pueden ser combinados en una línea de mensajes con la flecha sincrónica en un extremo y la flecha simple en el otro para indicar que el regreso es casi inmediato después de la llamada.

Comparando los tres diagramas diferentes Debido a que los diagramas de secuencia, colaboración y actividades muestran interacción, a menudo se debe hacer una elección sobre qué diagrama utilizar cuando se documente una interacción. La decisión depende de qué aspecto considere más importante, tiempo, espacio o trabajo. Los diagramas de secuencia proporcionan una forma de mirar un escenario en una forma basada en el tiempo – qué ocurre primero, qué ocurre después. Los clientes pueden fácilmente leer y entender este tipo de diagrama. Por ello son muy útiles en las primeras etapas del análisis. Los diagramas de colaboración tienden a proporcionar una imagen amplia para un escenario pues las colaboraciones están organizadas alrededor de los enlaces entre los objetos. Estos diagramas parecen ser usados más en la etapa de diseño cuando se diseña la implementación de las relaciones. Los diagramas de actividades son otra forma de mostrar interacciones pero se enfocan en el trabajo. Cuando los objetos interactúan entre si, los objetos realizan trabajo que consiste en actividades. Estas actividades y su orden son descritos en diagramas de actividad. Los diagramas de actividad serán estudiados posteriormente.

Diagramas de secuencia Un diagrama de secuencia muestra las interacciones de los objetos arregladas en una secuencia de tiempo. Muestra los objetos y clases envueltas en el escenario y la secuencia de mensajes intercambiados entre los objetos necesarios para realizar la funcionalidad del escenario. Los diagramas de secuencia típicamente son asociados con casos de uso en el modelo del sistema bajo desarrollo. Los diagramas de secuencia tienen dos ejes: el eje vertical muestra el tiempo y el eje horizontal un conjunto de objetos. En el UML, un objeto en un diagrama de secuencia es dibujado como un rectángulo que contiene el nombre del objeto subrayado. Un objeto puede ser nombrado de tres formas: el nombre del objeto, el nombre del objeto y su clase, o solamente la clase (objeto anónimo). Las tres formas son mostradas a continuación.

Capítulo 6: Descubriendo Interacción entre los Objetos

Página 89

Figura 31: Nombrando objetos en un diagrama de secuencia

Los nombres de los objetos pueden ser específicos o generales. A menudo, un objeto anónimo puede ser usado para representar cualquier objeto en la clase. Cada objeto también tiene su tiempo de vida representado por una línea punteada abajo del objeto (llamada línea de vida). Los mensajes entre objetos son representados por flechas que apuntan desde la línea de vida del emisor hacia la línea de vida del receptor. La flecha indica si el mensaje es sincrónico, asincrónico o simple. Un mensaje es una comunicación entre objetos que transporta información con la esperanza de que una acción será tomada. La recepción de un mensaje es normalmente considerada un evento. Los mensajes pueden ser señales, llamadas de operación o algo similar (ej.: llamadas remotas de procedimientos en C++ o invocación remota de métodos en Java). Cuando un mensaje es recibido, una actividad se inicia en el objeto receptor; esto es llamado activación. La activación muestra el foco de control – qué objeto se ejecuta en un tiempo en particular. Un objeto activado está ejecutando su propio código o está esperando el retorno de otro objeto al cual le envió un mensaje. La activación es mostrada como un rectángulo fino en la línea de vida del objeto. Cada mensaje puede tener una signatura con un nombre y parámetros, por ejemplo: print (file : File). Los mensajes también pueden tener números de secuencia, aunque son raramente usados pues la secuencia es explícita en el diagrama. Los retornos son mostrados como flechas usando el símbolo del mensaje simple, aunque no siempre se muestran. La notación del UML para objetos y mensajes en un diagrama de secuencia está mostrada en la siguiente figura.

Figura 32: Notación del UML para objetos y mensajes en un diagrama de secuencia

Página 90

Análisis y Diseño de Sistemas con el UML

Condiciones e Iteración

Los mensajes también pueden tener condiciones e iteraciones. Una condición (por ejemplo [necesitaOrden]) debe ser cierta para que el mensaje sea enviado y recibido. Las condiciones son mostradas para modelar ramificaciones o para decidir si enviar o no el mensaje. Si las condiciones son usadas para describir ramificaciones, varias flechas de mensajes son dibujadas con condiciones que excluyen a las otras (solamente un mensaje es enviado a la vez). Si las ramificaciones son modeladas con condiciones que no se excluyen entre sí, los mensajes son enviados concurrentemente. Una iteración (mostrado con un asterisco) muestra que un mensaje es enviado muchas veces a múltiples objetos receptores, como ocurriría cuando está iterando en una colección. Puede mostrar las bases de la iteración dentro de corchetes (como *[for all DetallesOrden]).

Figura 33: Condiciones e iteración en los mensajes

Etiquetas que definen restricciones y comentarios

Los diagramas de secuencia pueden tener etiquetas y comentarios en el margen derecho o izquierdo. Las etiquetas pueden ser de cualquier tipo como marcas de tiempo, descripciones de acciones tomadas durante la activación, restricciones, etc. La iteración puede también ser documentada usando un comentario al margen. Es también posible expresar restricciones de tiempo con etiquetas. Por ejemplo, puede ser posible restringir el tiempo entre dos mensajes y el tiempo que toma para un mensaje regresar (el tiempo de transición).

Capítulo 6: Descubriendo Interacción entre los Objetos

Página 91

Figura 34: Etiquetas que definen restricciones e iteraciones

Creado y destruyendo objetos

Los diagramas de secuencia pueden mostrar como los objetos son creados y destruidos como parte del escenario documentado. Un objeto puede crear otro objeto con un mensaje. El objeto creado es dibujado con su símbolo de objeto localizado donde es creado (en el eje vertical de tiempo). El mensaje que crea o destruye un objeto es normalmente un mensaje sincrónico. La destrucción de objeto se puede marcar con una X grande al final de la línea de vida del objeto.

Figura 35: Creación de un objeto

Página 92

Análisis y Diseño de Sistemas con el UML

Figura 36: Destrucción de un objeto

Recursión

La recursión es una técnica usada en muchos algoritmos. La recursión ocurre cuando una operación se llama a sí misma, lo cual es dibujado como una activación añadida a sí misma. El mensaje es siempre sincrónico.

Figura 37: Mensaje recursivo

Forma genérica e instanciada

Los diagramas de secuencia pueden ser usados de dos formas: la forma genérica y la forma instanciada. La forma instanciada describe un escenario específico en detalle; documenta una interacción posible. La forma instanciada no tiene ninguna condición, ramificaciones, o ciclos; muestra la interacción sólo para el escenario escogido. La forma genérica describe todas las posibles alternativas en el escenario, por lo tanto se pueden incluir ramificaciones, condiciones y ciclos. Por ejemplo, el escenario “abrir una cuenta” en un diagrama de secuencia usando la forma genérica sería descrito con todas las alternativas posibles: donde todo es exitoso, donde al cliente no se le permite abrir la cuenta, donde el dinero es depositado inmediatamente en la cuenta, etc. El mismo escenario documentado con la forma instanciada tendría que escoger una ejecución específica y quedarse en ella;

Capítulo 6: Descubriendo Interacción entre los Objetos

Página 93

por ejemplo, un diagrama podría mostrar la apertura exitosa de una cuenta. Si todos los casos deben ser mostrados usando la forma instanciada, se tendría que dibujar varios de ellos. Diagramas de secuencia y clases de frontera

Las clases de frontera son añadidas a los diagramas de secuencia para mostrar la interacción con el usuario u otro sistema. En las fases tempranas del análisis, el propósito de mostrar las clases de frontera en los diagramas de secuencia es para capturar y documentar los requerimientos de interfaz, no para mostrar cómo la interfaz será implementada. Los mensajes actuales del actor a la clase de frontera junto con su información de secuencia son dependientes de la armazón de aplicación que se escoja durante el desarrollo; por lo tanto, probablemente cambiarán a medida que se profundice en el desarrollo del sistema. Complejidad y diagramas de secuencia

La pregunta “¿Qué tan complejo puede ser un diagrama de secuencia?” es muy familiar. La respuesta es “mantenerlo simple.” La belleza de estos diagramas es su simplicidad – es muy fácil ver los objetos, las interacciones, los mensajes entre los objetos, y la funcionalidad capturada por el escenario. Otra pregunta es “¿Qué hago con la lógica condicional?” (todos los if, then, else que existen en el mundo real). La respuesta es muy subjetiva. Si la lógica es simple, e intervienen unos cuantos mensajes, usualmente se añade la lógica a un diagrama y se usan notas para comunicar las opciones que se pueden tomar. Por otro lado, si la lógica es compleja, típicamente se usa un diagrama separado – uno para el caso if, otro para el caso then y otro para el caso else. Esto es así para mantener simples los diagramas.

Diagramas de colaboración Un diagrama de colaboración es una manera alterna de mostrar un escenario. Este tipo de diagrama muestra las interacciones de los objetos organizadas alrededor de objetos y sus enlaces hacia los otros. Un diagrama de colaboración contiene:

Objetos dibujados como rectángulos. Enlaces entre objetos mostrados como líneas que conectan los objetos enlazados. Mensajes mostrados como texto y una flecha que apunta del emisor al receptor.

En un enlace se puede añadir una etiqueta de mensaje que define entre otras cosas, un número de secuencia para el mensaje. La etiqueta requiere una sintaxis especial. Un diagrama de colaboración inicia con un mensaje que inicia la colaboración o interacción entera, por ejemplo, una llamada a una operación.

Página 94

Análisis y Diseño de Sistemas con el UML

Figura 38: Diagrama de colaboración

Flujo de mensajes

Una etiqueta de mensaje (la etiqueta colocada en un mensaje) en un diagrama de colaboración es especificada con la sintaxis: Precedecesor condición_guardia expresión_de_secuencia valor_de_retorno := signatura

Donde el predecesor es especificado con la sintaxis: Número_de_secuencia ‘,’ ... ‘/’

El predecesor es una expresión para sincronización de hilos o caminos, que significa que los mensajes conectados a los números de secuencia especificados deben ser realizados y manejados antes que el mensaje actual sea enviado. La lista de números de secuencia es separada por comas. La condición guardia es especificada con la sintaxis: ‘[‘ cláusula_de_condición ‘]’

La cláusula de condición es normalmente expresada en seudocódigo o en lenguaje de programación. El UML no prescribe una sintaxis específica. La expresión de secuencia tiene la sintaxis: [entero | nombre][recurrencia] ‘:’

Capítulo 6: Descubriendo Interacción entre los Objetos

Página 95

El entero es una secuencia de números que especifican el orden de los mensajes. El mensaje 1 siempre inicia una secuencia de mensajes; el mensaje 1.1 es el mensaje anidado primero dentro del manejo del mensaje 1. Una secuencia ejemplo sería: mensaje 1, mensaje 1.1, 1.2, 1.2.1, 1.2.2, 1.3, etc. Por lo tanto, el número puede delinear tanto la secuencia como la anidación de mensajes. El nombre representa un hilo concurrente de control. Por ejemplo, 1.2a y 1.2b son mensajes concurrentes enviados en paralelo. La expresión de secuencia debe ser terminada con dos puntos (:). La recurrencia representa una ejecución condicional o iterativa. Hay dos opciones: ‘*’ ‘[‘ cláusula_de_iteración ‘]’ ‘[‘ cláusula_de_condición ‘]’

La cláusula de iteración es ocupada para especificar iteración (ejecución repitente), donde la cláusula de iteración es una condición para la iteración, como [i := 1..n]. Por ejemplo, una etiqueta de mensaje que contenga una iteración podría ser mostrada como: 1.1 *[x = 1..10]: hacerAlgo()

La cláusula de condición es usualmente usada para describir ramificaciones, no para condiciones guardia. [x<0] y [x>=0] son dos cláusulas de condición que pueden ser usadas para ramificar, en la cual solamente una de las condiciones es verdadera; por lo tanto, solamente una de las ramificaciones será ejecutada (enviando el mensaje conectado a esa ramificación). Tanto las cláusulas de condición como las cláusulas de iteración se deben expresar en seudocódigo o en el lenguaje de programación a usar. El valor de retorno debe ser asignado a una signatura de mensaje. Una signatura está compuesta de un nombre de mensaje y una lista de argumentos. El valor de retorno muestra el valor recuperado como resultado de una llamada a una operación (un mensaje). Un ejemplo de esto sería la etiqueta 1.4.5: x := calc(n).

Figura 39: Iteración y valores de retorno mostrados en un diagrama de colaboración

Ejemplos de etiquetas de mensajes son: 1: display() [mode = display] 1.2.3.7: redraw() 2 * [n := 1..z]: prim := nextPrim (prim) 3.1 [x>0]: foo() 3.2 [x>=0]: bar90 1.1a,1.1b/1.2: continue()

Página 96

Análisis y Diseño de Sistemas con el UML

Enlaces

Un enlace es una conexión entre dos objetos. Cualquier nombre de rol de los objetos en el enlace puede ser mostrado en los extremos de los enlaces, junto con calificadores en los enlaces. Tanto los calificadores como los roles son especificados en los diagramas de clase que contienen las definiciones de las clases de los objetos. Hay también algunos estereotipos que pueden ser añadidos a los roles de los enlaces de los objetos en el enlace: global, local, parameter (parámetro), self (a sí mismo), vote (voto), y broadcast (difusión).

Global es una restricción aplicada a un rol de un enlace, que especifica que la instancia correspondiente es visible porque está en un alcance global (la instancia está disponible a través de un nombre global conocido a lo largo del sistema). Local es una restricción aplicada a un rol de un enlace, que especifica que la instancia correspondiente es visible porque es una variable local en una operación. Parameter es una restricción aplicada a un rol de un enlace que especifica que la instancia correspondiente es visible porque es un parámetro en una operación. Self es una restricción aplicada a un rol de un enlace, que especifica que un objeto puede enviarse mensajes a sí mismo. Vote es una restricción aplicada a un mensaje, que restringe una colección de mensajes de retorno. La restricción vote especifica que un valor de retorno es seleccionado mediante un voto de mayoría de todos los valores de retorno en la colección. Broadcast es una restricción aplicada a un conjunto de mensajes, que especifica que el conjunto de mensajes no son invocados en un orden dado.

Tiempo de vida de un objeto

Los objetos que son creados durante una colaboración son designados con {new}. Los objetos que son destruidos durante la colaboración son designados con la restricción {destroyed}. Los objetos que son creados y destruidos durante la misma colaboración son designados como {transient}.

Figura 40: Objetos creados y destruidos durante una colaboración

Capítulo 7: Especificando Relaciones Asociaciones Nombrando relaciones Nombres de roles Indicadores de multiplicidad Relaciones recursivas Asociación calificada Asociación “O” Asociación ordenada Asociación ternaria Agregaciones ¿Asociación o agregación? Encontrando relaciones Relaciones entre paquetes

Capítulo 7: Especificando Relaciones

Página 99

odos los sistemas están hechos de muchas clases y objetos. El comportamiento del sistema es logrado mediante la colaboración de los objetos en el sistema. Esto a menudo es referido como un objeto enviando un mensaje a otro objeto. Dos tipos de relaciones descubiertas durante el análisis son asociaciones y agregaciones.

Asociaciones Una asociación es una conexión bidireccional semántica entre clases. No es un flujo de datos como en el análisis y diseño estructurado – los datos pueden fluir en cualquier dirección de la asociación. Una asociación entre clases significa que hay un enlace entre objetos de las clases asociadas. El número de objetos conectados depende de la multiplicidad de la asociación, la cual es discutida posteriormente. En el UML, las relaciones de asociación son mostradas como líneas sólidas que conectan las clases asociadas, como se muestra a continuación.

Figura 41: Notación del UML para una relación de asociación

Nombrando relaciones Una asociación puede ser nombrada. Usualmente el nombre es un verbo activo o frase verbal que comunica el significado de la relación. Debido a que la frase verbal típicamente implica una dirección de lectura, es deseable nombrar la asociación de forma que se lea correctamente de izquierda a derecha o de arriba hacia abajo. Las palabras pueden tener que ser cambiadas para leer la asociación en la otra dirección. Es importante notar que el nombre de la asociación es opcional. Los nombres son añadidos si son necesarios para agregar claridad al modelo. Las relaciones de agregación típicamente no son nombradas debido a que son leídas usando las palabras “tiene” o “contiene.” La siguiente figura muestra una relación nombrada.

Figura 42: Asociación nombrada

Página 100

Análisis y Diseño de Sistemas con el UML

Nombres de roles El extremo de una asociación donde se conecta a una clase se llama el rol de la asociación. Los nombres de roles pueden ser usados en vez de los nombres. Un nombre de rol es un nombre que denota el propósito o capacidad por la que una clase se asocia a otra. El nombre del rol es colocado en la asociación cerca de la clase que modifica. Un nombre de rol puede ser puesto en uno o ambos extremos de la línea de asociación. No es necesario tener ambos un nombre de rol y un nombre de asociación. La siguiente figura muestra una relación con un nombre de role.

Figura 43: Nombres de rol

No existe un estándar sobre si se deberá usar nombres de asociaciones o nombres de roles. Sin embargo, la mayoría de la gente hoy tiende a usar nombres de roles en vez de nombres de asociaciones porque es más fácil explicar el significado de la relación. Esto es especialmente cierto en una relación bidireccional porque es muy difícil encontrar una frase verbal que se lea correctamente en ambas direcciones. Las asociaciones son nombradas o los nombres de rol usados cuando los nombres son necesarios por claridad. Si tiene una relación entre Compañía y Persona, entonces podrá usar un nombre de asociación llamado “emplea” o los nombres de rol “empleador” y “empleado.” Si los nombres de las clases fueran Empleador y Empleado, no se necesitará nombre pues el significado de la relación estaría claro basado en los nombres de las clases.

Indicadores de multiplicidad Aunque la multiplicidad es especificada para las clases, define el número de objetos que participan en la relación. La multiplicidad define el número de objetos que están enlazados a otro. Hay dos indicadores de multiplicidad para cada asociación o agregación – uno al extremo de cada línea. Algunos indicadores de multiplicidad comunes son: 1 0..* 1..* 0..1 5..8 4..7,9

Exactamente uno Cero o más Uno o más Cero o uno Rango específico (5,6,7 u 8) Combinación (4,5,6,7 o 9)

Si la multiplicidad no es especificada es 1 por defecto. Los indicadores de multiplicidad son mostrados en la siguiente figura.

Figura 44: Indicadores de multiplicidad

Capítulo 7: Especificando Relaciones

Página 101

Relaciones recursivas Múltiples objetos pertenecientes a la misma clase pueden tener que comunicarse entre sí. Esto es mostrado en el diagrama de clase como una asociación o agregación recursiva. Típicamente se utilizan nombres de rol en vez de nombres de asociación para las relaciones recursivas. Una relación recursiva se muestra en la siguiente figura.

Figura 45: Relación recursiva

Asociación calificada Las asociaciones calificadas son usadas con asociaciones uno a muchos o muchos a muchos. Son el equivalente de un concepto de programación conocido como arreglos asociativos, mapas y diccionarios. El calificador distingue entre un grupo de objetos en el extremo muchos de la asociación. El calificador especifica como un objeto específico en el extremo muchos de la asociación es identificado, y puede ser visto como un tipo de clave (llave) que separa todos los objetos en la asociación. El calificador es mostrado como una pequeña caja en el extremo de la asociación cerca de la clase desde la cual la navegación debe ser hecha. Las asociaciones calificadas reducen la multiplicidad efectiva en el modelo de uno a muchos a uno a uno.

Figura 46: Asociación calificada

En la figura anterior, el calificador dice que en conexión con una Orden, puede haber un Detalle de Orden para cada Producto. Conceptualmente, este ejemplo indica que no se pueden tener dos Detalles de Orden dentro de una Orden para el mismo Producto. Desde un punto de vista de especificación esto indica que todo el acceso a un Detalle de Orden requiere la identidad del Producto como un argumento. Una multiplicidad de 1 indicaría que debe haber un Detalle de Orden para cada producto; * indicaría que puede tener múltiples Detalles de Orden por Producto, pero que el acceso a los Detalles de Orden estaría indexado por Producto. Las asociaciones calificadas pueden ser usadas cuando se muestran restricciones del tipo “un solo Detalle de Orden por Producto en la Orden.”

Página 102

Análisis y Diseño de Sistemas con el UML

Asociación “O” En algunos modelos no todas las combinaciones son válidas, y esto puede causar problemas que deben ser manejados. Observe la siguiente figura:

Figura 47: Asociación “o”

En la figura anterior, una persona puede tener un contrato de seguro con la compañía de seguros, y otra compañía puede tener contratos con la compañía de seguros, pero la persona y la compañía no pueden tener el mismo contrato. Una forma de resolver este problema es usar asociaciones “o.” Una asociación “o” es realmente una restricción en dos o más asociaciones. Especifica que los objetos de una clase pueden participar en cuando mucho una de las asociaciones a la vez. Las asociaciones “o” son dibujadas como una línea punteada entre las asociaciones que son parte de la asociación “o,” y con la especificación {or} en la línea punteada como se mostró en la figura anterior.

Asociación ordenada Los enlaces entre los objetos pueden tener un orden implícito; por ejemplo, las ventanas pueden ser ordenadas en la pantalla. El valor por defecto de una asociación es sin orden. Puede ser mostrado explícitamente pero no es necesario. Si hay un orden explícito entre los enlaces, éste se muestra poniendo {ordered} en de línea de la asociación cerca de la clase de los objetos que están ordenados. La forma en que se ordena es especificada ya sea con una propiedad de la asociación o dentro de las llaves (ej.: {ordered by increasing time}).

Capítulo 7: Especificando Relaciones

Página 103

Figura 48: Asociación ordenada

Asociación ternaria La asociación ternaria asocia más de dos clases entre sí. La asociación ternaria se muestra como un diamante grande. Los roles y la multiplicidad pueden ser mostrados, pero los calificadores y agregación no están permitidos. Una clase en asociación puede estar conectada a la asociación ternaria dibujando una línea punteada a uno de las cuatro puntas del diamante.

Figura 49: Asociación Ternaria

La figura anterior muestra que un cliente que juega el rol de polizahabiente tiene muchos contratos de seguro, y cada contrato está asociado con una compañía de seguros que juega el rol del aseguradora.

Agregaciones Una agregación es una forma especializada de asociación, en la cual un todo está relacionado a sus partes. La agregación es conocida como una relación “parte de” o de contenimiento. La notación del UML para una relación de agregación es una asociación con un diamante cerca de la clase que denota el agregado (todo). Note que el diamante no puede ser dibujado en más de un extremo.

Página 104

Análisis y Diseño de Sistemas con el UML

Figura 50: Notación del UML para una relación de agregación

Las siguientes pruebas pueden ser usadas para determinar si una asociación debería ser una agregación:

Es la frase “parte de” usada para describir la relación. Hay algunas operaciones en el todo que son aplicadas a sus partes. Por ejemplo, borrar una orden y luego sus detalles. Hay una asimetría intrínseca en la relación donde una clase es subordinada de la otra.

Una agregación puede ser compartida si la multiplicidad de la relación es de más de 1 en ambos extremos. Por ejemplo, un Grupo está compuesto de Personas. Una persona podría ser miembro de varios grupos.

Figura 51: Agregación compartida

¿Asociación o agregación? Si dos clases están fuertemente ligadas por una relación todo-parte, la relación es típicamente una agregación. “La decisión de usar agregación es una de juicio y es a menudo arbitraria. A menudo, no es obvio si una asociación debería ser modelada como una agregación. Si ejercita un juicio cuidadoso y es consistente, la distinción imprecisa entre agregación y asociación ordinaria no causa problemas en la práctica.”4 Si una relación es una asociación o una agregación es a menudo dependiente del dominio. ¿Qué tipo de relación debería ser usada para modelar un carro con sus llantas? Si la aplicación es un centro de servicios y la única razón por la que le importa la llanta es porque forma parte del carro, entonces la relación es una agregación. Por otro lado, si la aplicación es una tienda de llantas, le importará la llanta independientemente del carro, y por lo tanto la relación debería ser una asociación.

Encontrando relaciones Los escenarios son examinados para determinar si una relación debería existir entre dos clases. Los mensajes entre objetos significan que los objetos deben comunicarse entre sí. Las asociaciones o agregaciones proporcionan los canales para esa comunicación. Las relaciones también pueden ser descubiertas basados en la signatura de una operación (esto se explicará más adelante).

Rumbaugh, James, et al. Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991. Page 58.

Capítulo 7: Especificando Relaciones

Página 105

Cuando se modelan sistemas muy completos, especialmente sistemas de información o sistemas de negocio, es muy importante comunicar los resultados (el modelo). Un diagrama de clase es menos ambiguo de comunicar que un texto. Cuando se crea un modelo muchas decisiones deben ser tomadas que de otra forma no se tomarían. Aún un modelo pequeño contiene una gran cantidad de información, y es siempre posible transcribir el modelo en lenguaje natural.

Figura 52: Un diagrama de clase que describe un negocio de seguros

Por ejemplo, el modelo de la figura anterior puede ser expresado en lenguaje natural:

Una compañía de seguros tiene contratos de seguro, los que se refieren a uno o más clientes. Un cliente tiene contratos de seguro (cero o más), los que se refieren a una compañía de seguros. Un contrato de seguro se da entre una compañía de seguros y uno o más clientes. El contrato de seguro se refiere a un cliente (o clientes) y una compañía de seguros. El contrato de seguros es expresado en (cero o más) pólizas de seguro (un contrato escrito de seguro). La póliza de seguro se refiere a un contrato de seguro.

El punto es que es muy importante modelar el negocio real, no lo que parece ser. Si se modela el negocio de seguros basado en la póliza, puede tener problemas. Por ejemplo, ¿qué sucedería si un cliente asegurara su carro y lo estrellara un minuto después (todavía no habría póliza, pero ya hay un contrato verbal con el agente)? Alternativamente, ¿qué sucedería sin el negocio de seguros instituyera otros tipos de pólizas de seguros (seguros en el Web)? Si se modela el alma del negocio, puede manejar fácilmente problemas que desarrollan cuando el negocio cambia debido a nuevas leyes, competencia o cambios económicos. En el caso de los seguros en el Web se podría añadir una nueva clase llamada póliza de seguro en el Web. Esta nueva clase tendría un comportamiento diferente de las pólizas de seguro normales.

Relaciones entre paquetes Las relaciones entre paquetes son también añadidas al modelo. Este tipo de relación puede ser una relación de dependencia, mostrada como una flecha punteada hacia el paquete dependiente, como se muestra en la figura siguiente.

Página 106

Análisis y Diseño de Sistemas con el UML

Figura 53: Relaciones entre paquetes

También se permiten las relaciones de refinamiento y generalización. Si el paquete A es dependiente del paquete B, esto significa que una o más clases en el paquete A inician comunicación con una o más clases públicas del paquete B. El paquete A es conocido como el paquete cliente y el paquete B como el paquete suplidor. Las relaciones entre paquetes también son descubiertas examinando los escenarios y las relaciones entre clases para el sistema en desarrollo. Como este es un proceso iterativo, las relaciones cambiarán a medida que el análisis y diseño progresen. Los paquetes pueden importar elementos de otros paquetes. Cuando un elemento de modelaje es importado, solamente se refiere al paquete que lo posee. Importar de un paquete es descrito como una dependencia con el estereotipo <<imports>> (importa), lo cual significa que si un paquete tiene la visibilidad implementación, ningún otro paquete puede importar de ese paquete. Cada paquete tiene una interfaz que es realizada por su conjunto de clases públicas – esas clases con las que hablan las clases en otros paquetes. El resto de clases en el paquete son de implementación y no se comunican con clases en otros paquetes. La interfaz es mostrada como un pequeño círculo conectado mediante una línea sólida al paquete como es el caso con las clases. Típicamente una o más clases dentro del paquete implementan la interfaz.

Figura 54: El paquete X contiene las clases P y S. El paquete A tiene una interfaz I. La clase S dentro del paquete X es dependiente de la interfaz I del paquete A

CapĂtulo 8: AĂąadiendo Comportamiento y Estructura Creando operaciones

Documentando las operaciones

Relaciones y signaturas de las operaciones

Creando atributos

Documentado los atributos

Clases en asociaciĂłn

Capítulo 8: Añadiendo Comportamiento y Estructura

Página 109

na clase contiene un conjunto de responsabilidades que definen el comportamiento de los objetos de la clase. Las responsabilidades son realizadas por las operaciones definidas en la clase. Una operación debe hacer una sola cosa y debe hacerla bien. Todas las instancias de la clase son capaces de realizar las operaciones identificadas para la clase. Las operaciones son usadas para manipular los atributos o para realizar otras acciones. Las operaciones son normalmente llamadas funciones, pero están dentro de una clase y pueden ser aplicadas solamente a los objetos de esa clase. La estructura de un objeto es descrita por los atributos de la clase. Cada atributo es una definición de datos mantenida por objetos de la clase y en conjunto describen las características de los objetos. Los objetos definidos para la clase tienen un valor para cada atributo de la clase. Los valores de los atributos no tienen que ser únicos. Los atributos correctos capturan la información que describe e identifica una instancia específica de la clase. Sin embargo, solamente los atributos que son importantes dentro del sistema modelado deben ser incluidos. Además, el propósito del sistema también influye en qué atributos deben ser usados. Como con las clases, se deben seguir guías de estilo cuando se definen atributos y operaciones para proporcionar código más legible y mantenible, por ejemplo, iniciar todos los atributos y operaciones con una letra minúscula, no usar signo de subrayado (“_”) – los nombres con múltiples palabras se juntan y la primera letra de cada palabra adicional se capitaliza. Se debe tener cuidado para asegurar que se siguen las guías apropiadamente, esto proporciona consistencia a través de las clases, lo cual lleva a modelos y código más mantenibles. Si un objeto de una clase no necesita un atributo u operación, mire la definición de la clase. Esto puede ser un signo de que la clase no es cohesiva y que debería ser dividida en varias clases.

Creando operaciones Los mensajes en los diagramas de interacción típicamente son mapeados a operaciones de la clase receptora. Sin embargo, hay algunos casos especiales donde el mensaje no se convierte en una operación. Si la clase receptora es una clase de frontera que representa una clase de interfaz de usuario (GUI), el mensaje es una indicación de los requerimientos de interfaz. Estos tipos de mensajes típicamente son implementados como algún tipo de control GUI y no son mapeados a operaciones debido a que el comportamiento es llevado a cabo por el control mismo. Por ejemplo, un actor necesita introducir una clave para realizar un escenario. Esto es representado como un mensaje a una clase de frontera. Esto nunca será una operación de la clase de interfaz de usuario – probablemente será una caja de texto en una ventana. Si el mensaje es hacia o desde un actor que representa una persona física, el mensaje es un procedimiento humano y es por lo tanto incorporado en un manual de usuario, pero no una operación, debido a que no tiene sentido crear operaciones para los humanos. Si el mensaje es de o hacia un actor que representa un sistema externo, una clase es creada para llevar control del protocolo que es usado para realizar la comunicación con el sistema externo. En este caso, el mensaje es mapeado a una operación en la clase. Las operaciones deben ser nombradas en términos de la clase que realiza la operación, no la clase que pide la funcionalidad a realizarse. Además, los nombres de las operaciones no deben reflejar la implementación de la operación debido a que puede cambiar en el tiempo. Las operaciones pueden ser creadas independientemente de los diagramas de interacción, debido a que no todos los escenarios son representados en el diagrama. Esto también es cierto para las operaciones que son creadas para ayudar a otra operación.

Página 110

Análisis y Diseño de Sistemas con el UML

Documentando las operaciones Cada operación debe ser documentada de tal forma que el lector del modelo pueda entender rápidamente su propósito. La documentación debería indicar la funcionalidad realizada por la operación. También debería indicar cualquier valor de entrada necesario para la operación junto con el valor de retorno de la operación. Las valores de entrada y retorno constituyen la signatura de la operación. Esta información puede no ser conocida inicialmente pero puede ser añadida posteriormente en el ciclo de vida cuando se sepa más sobre la clase.

Relaciones y signaturas de las operaciones La signatura de una operación puede indicar una relación. Si la clase para un argumento o el retorno de una operación es una clase fundamental como String, la relación típicamente no se muestra en el diagrama. Para otras clases (no fundamentales), la relación típicamente es desplegada en uno o más diagramas. Las relaciones basadas en signaturas inicialmente son modeladas como asociaciones que pueden ser refinadas en relaciones de dependencia a medida que el diseño madura. Las relaciones entre paquetes deben ser revisadas a medida que las relaciones basadas en signaturas de operaciones son añadidas al modelo.

Creando atributos Muchos de los atributos de una clase son encontrados en la descripción del problema, el conjunto de requerimientos del sistema, y la documentación del flujo de eventos. Pueden también ser descubiertas cuando se define la clase.

Documentado los atributos Los atributos deben ser documentados también, con una definición clara y concisa. La definición debe indicar el propósito del atributo, no la estructura del atributo (ej., una cadena de caracteres de longitud 15).

Clases en asociación Una relación también puede tener estructura y comportamiento. Esto es cierto cuando la información trata con un enlace entre dos objetos y no con el objeto mismo. En este caso se añade una clase a la asociación. La clase en asociación no está conectada a ninguno de los extremos de la asociación, sino a la asociación misma. La clase en asociación es una clase normal; puede tener atributos, operaciones y otras asociaciones. Cada enlace de la asociación está relacionado con la clase en asociación.

Capítulo 8: Añadiendo Comportamiento y Estructura

Página 111

Figura 55: Clase en asociación

En la figura anterior podemos ver que en un sistema de elevadores el control de elevadores manipula cuatro elevadores. En cada enlace entre los elevadores y el control hay una sola cola. Cada cola almacena las peticiones hechas al elevador. En el UML la clase en asociación añade una restricción más, la cual es que solamente puede existir una instancia de la clase en asociación entre dos objetos participantes. Por ejemplo, en una relación entre las clases Persona y Compañía podría haber una clase en asociación llamada Empleo que contendría los detalles del período de trabajo, salario, puesto, etc. Sin embargo, podríamos imaginar a una persona trabajando para la misma compañía en períodos diferentes (se retira y luego regresa). Esto significa que la misma persona puede tener más de un Empleo en una Compañía en diferentes períodos. Esto no es legal en el UML por lo que el Empleo debe ser representado por una clase normal.

Figura 56: Promoviendo una Posible Clase en Asociación a una Clase Completa

Capítulo 9: Descubriendo Herencia Generalización y Especialización

Arboles de herencia

Herencia simple contra herencia múltiple

Clasificación y Generalización

Capítulo 9: Descubriendo Herencia

Página 115

Generalización y Especialización La definición de generalización en el UML es: “una relación taxonómica (la taxonomía es la ciencia de la clasificación) entre un elemento más general y uno más específico.” El elemento más específico es completamente consistente con el más general y contiene información adicional. Una instancia del elemento más específico puede ser usada donde el elemento más general es permitido. Por lo tanto, la generalización (también llamada herencia) permite que los elementos sean especializados en nuevos elementos, de tal forma que casos especiales o extensiones puedan ser añadidas fácilmente como elementos separados. La generalización se usa para las clases, los casos de uso, y para otros elementos como los paquetes. La generalización es usada solamente en tipos, nunca en instancias (una clase puede heredar de otra, pero un objeto no puede heredar de otro) aún cuando las instancias son directamente afectadas por sus tipos. Una generalización es a veces llamada una relación “es un” o “tipo de.” La generalización es una relación entre una clase general y una específica. La clase específica, llamada la subclase, hereda todo de la clase general, llamada la superclase. Los atributos, operaciones, y todas las asociaciones son heredados. La generalización es muy común en los inicios del análisis debido a que las clases que existen son las que modelan el mundo real. Las clases son examinadas para ver si existe comportamiento (operaciones) o estructura (atributos) comunes. Se deben buscar sinónimos porque los nombres de atributos y operaciones son expresados en lenguaje natural y los aspectos comunes pueden estar escondidos. Adicionalmente, se buscan atributos y comportamientos que a primera vista parecieran ser específicos, pero que en realidad pueden ser generalizados. La generalización proporciona la habilidad de crear subclases especializadas que representan refinaciones de la superclase – típicamente estructura y comportamiento son añadidos a la nueva subclase. Este método de encontrar herencia a menudo entra en juego si la clase ya existe, las subclases son añadidas para especializar el comportamiento de la clase existente. Las operaciones pueden ser redefinidas por la subclase. Esto es conocido como polimorfismo. Sin embargo, una subclase no debe nunca restringir una operación definida en su superclase. Es decir, la subclase nunca debería proporcionar menos comportamiento o estructura que sus superclases. La generalización es clave para la reutilización; una clase puede ser creada para una aplicación, y después una subclase puede ser creada para añadir más información necesaria para una aplicación diferente. Se debe tener cuidado, pues la generalización es a menudo mal utilizada – el síndrome “la herencia es buena, por lo tanto, mientras más la use mejor será mi código,” no es cierto; de hecho, el mal uso de la herencia puede llevar a problemas tales como que un objeto tenga que cambiar de clase o que al añadir una nueva dimensión se tengan que añadir nuevas subclases para manejar todas las combinaciones de superclases. La generalización también puede ser aplicada a las interfaces, usando los mismos símbolos que para las clases. La generalización es mostrada en el UML como una línea sólida de la subclase a la superclase con un triángulo en el extremo de la línea cerca de la superclase.

Página 116

Análisis y Diseño de Sistemas con el UML

Figura 57: Notación del UML para la generalización (herencia)

Arboles de herencia Una clase puede ser a la vez superclase y subclase si está en un árbol de herencia. Un árbol de herencia es un gráfico donde las clases están conectadas mediante relaciones de generalización. Por lo tanto, una clase puede heredar de una clase y a la vez ser heredada por otra clase. La base para la generalización y la especialización (la razón por la cual las subclases fueron creadas) en una relación de herencia es llamada el discriminador. El discriminador típicamente tiene un conjunto finito de valores, y las subclases pueden ser creadas para cada valor. La relación de herencia puede ser mostrada como un árbol para todas las clases creadas a partir de un discriminador. Se debe tener cuidado cuando se descubren múltiples discriminadores para una clase porque puede llevar a herencia múltiple o a una agregación. A medida que progresa el análisis y diseño las respuestas a estos problemas llevarán a la estructura del modelo. Los atributos, operaciones y relaciones son movidos al nivel más alto aplicable en la jerarquía una vez que una superclase es identificada.

Herencia simple contra herencia múltiple Con herencia simple, una clase tiene un conjunto de padres – es decir, hay una cadena de superclases (ej. Un carro es un vehículo terrestre que es un vehículo de motor). La herencia múltiple envuelve más de una cadena de superclases (ej. Un vehículo anfibio es un vehículo terrestre que es un vehículo de motor y a la vez es un vehículo marino que es un vehículo de motor). Pueden haber numerosos problemas asociados con la herencia múltiple – por ejemplo choques entre nombres y copias múltiples de la misma funcionalidad. Como se resuelven estos problemas es muy dependiente del lenguaje y varía desde el uso de características especiales hasta la falta de soporte para herencia múltiple. La herencia múltiple también lleva a código menos mantenible – mientras más superclases, es más difícil determinar qué viene de dónde y qué sucede si cambio algo. Use herencia múltiple solamente cuando sea necesario y úsela con cuidado.

Instanciación y Generalización Como ya hemos mencionado anteriormente, la generalización es a menudo llamada la relación “es un.” Se debe tener mucho cuidado con esa forma de pensar. El problema es que la frase “es un” puede significar cosas diferentes.

Capítulo 9: Descubriendo Herencia

Página 117

Considere las siguientes frases: 1. 2. 3. 4. 5.

Shep es un Border Collie. Un Border Collie es un Perro. Los Perros son Animales. Un Border Collie es una Raza. Perro es una Especie.

Ahora intente combinar las frases. Si combina las frases 1 y 2 obtiene “Shep es un Perro”; 2 y 3 resulta en “Los Border Collie son Animales.” 1 y 2 y 3 resulta en “Shep es un Animal.” Hasta ahora todo bien. Ahora intente 1 y 4 “Shep es una Raza”; 2 y 5 “Un Border Collie es una Especie.” Estas no están bien. ¿Por qué se pueden combinar unas frases y no otras? La razón es que algunas son instanciación (el objeto Shep es una instancia del tipo Border Collie), mientras que otras son generalización (el tipo Border Collie es un subtipo del tipo Perro). La generalización es transitiva, mientras que la instanciación no lo es. Se puede combinar instanciación seguida de generalización pero no viceversa. El punto es que se debe tener cuidado con “es un.” Su utilización puede llevar a un uso inapropiado de la herencia y confusión de responsabilidades. Mejores frases para la generalización en este caso serían “Los Perros son tipos de Animales” y “Los Border Collie son tipos de Perros.”

CapĂtulo 10: Analizando el Comportamiento de los Objetos Diagramas de Estados

Diagramas de Actividad

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 121

Diagramas de Estados Los casos de uso y escenarios proporcionan una forma para describir el comportamiento del sistema; es decir, la interacción entre objetos en el sistema. Algunas veces es necesario mirar el comportamiento dentro de un objeto, los eventos de mensajes que causan la transición de un estado a otro, y las acciones que resultan de un cambio de estado. Los diagramas de estado capturan el ciclo de vida de objetos, subsistemas y sistemas. Describen los estados que un objeto puede tener y cómo los eventos (mensajes recibidos, tiempo que transcurre, errores, y condiciones que se vuelven ciertas) afectan esos estados a lo largo del tiempo. Un diagrama de estados no será creado para cada clase en el sistema. Son creados solamente para clases con comportamiento dinámico significativo. Los diagramas de interacción pueden ser estudiados para determinar los objetos dinámicos en el sistema – aquellos que reciben y envían muchos mensajes. Los diagramas de estados son también útiles para investigar el comportamiento de una clase agregada en un todo y clases de control. Se debe tener cuidado de permanecer en una solución de análisis – concentrándose en el problema y no en la solución. Estados y transiciones

Todos los objetos tienen un estado; el estado es el resultado de acciones previas realizadas por el objeto. Un estado es una condición durante la vida de un objeto en la cual satisface alguna condición, realiza alguna acción, o espera un evento. El estado de un objeto puede ser caracterizado por el valor de uno o más de los atributos de la clase. Además el estado puede ser caracterizado por la existencia de un enlace a otro objeto. Mirando al estado de un objeto podemos validar la multiplicidad escogida para una relación con otro objeto. Es decir, si estar en un estado depende de la existencia de un enlace a otro objeto, esto implica que la multiplicidad de la relación que modifica el rol de la clase asociada debe incluir 0 (la relación es opcional). Por lo tanto, los estados de un objeto son encontrados examinando los atributos y enlaces definidos para el objeto. Ejemplos de estados son:

La factura (objeto) está pagada (estado). El carro (objeto) está detenido (estado). La máquina (objeto) está corriendo (estado). Jim (objeto) está jugando el rol de vendedor (estado). Kate (objeto) está casada (estado).

Un diagrama de estados incluye todos los mensajes que un objeto puede enviar y recibir. Los escenarios representan un camino a través de un diagrama de estados. El intervalo entre dos mensajes enviados por un objeto típicamente representa un estado. Por lo tanto, los diagramas de secuencia pueden ser examinados para descubrir los estados para un objeto (buscando los espacios entre las líneas que representan los mensajes recibidos por el objeto). Los diagramas de estado tienen un estado inicial y uno o varios estados finales. Cada diagrama debe tener uno y solo un estado inicial debido a que el objeto debe estar en un estado consistente cuando es

Página 122

Análisis y Diseño de Sistemas con el UML

creado. La notación del UML para un estado inicial es un círculo sólido pequeño. La notación del UML para un estado de finalización es un bull’s eye (ojo de toro).

Figura 58: Notación del UML para los estado de inicio y final

La notación en el UML para un estado es un rectángulo con esquinas redondeadas, como se muestra en la siguiente figura.

Figura 59: Notación del UML para un estado

Entre los estados hay transiciones, las cuales representan un cambio de un estado original a un estado sucesor (que puede ser el mismo que el original). Las transiciones pueden estar etiquetadas con el evento que causa la transición. Cuando el evento ocurre, la transición de un estado a otro se da (a veces se dice que la transición se dispara). Una transición puede ser acompañada por una acción. Hay dos formas de salir de un estado – automática y no automática. Una transición de estado automática ocurre cuando la actividad del estado original se completa – no hay un evento nombrado asociado con la transición de estado. Una transición de estado no automática es causada por un evento nombrado (ya sea de otro objeto o de afuera del sistema). Ambos tipos de transiciones de estados toman cero tiempo y no pueden ser interrumpidas. Una transición de estados es representada por una flecha que apunta del estado original al estado sucesor. En la siguiente figura se muestran los estados y las transiciones de estados.

Figura 60: Estados y sus transiciones

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 123

Detalles de los estados

Un estado puede tener tres compartimentos. El primer compartimento muestra el nombre del estado. El segundo compartimento es opcional y muestra las variables de estado, donde los atributos pueden ser listados y asignados. Los atributos son los de la clase desplegada por el diagrama de estado; además, algunas veces son útiles variables temporales en los estados como contadores. El tercer compartimento es también opcional y es el compartimento de actividades, donde los eventos y acciones pueden ser listados.

Figura 61: Compartimentos de los estados

Tres eventos estándar pueden ser usados en el compartimento de actividades: entry (entrada), exit (salida), y do (hacer). El evento entry puede ser usado para especificar acciones a realizar en la entrada a un estado; es decir, que todas las acciones que acompañan a todas las transiciones de estados hacia dentro del estado se colocan en el evento entry porque son iguales; por ejemplo, asignar un atributo o enviar un mensaje. El evento exit puede ser usado para especificar acciones a realizar cuando se sale de un estado; es decir, que todas las acciones que acompañan a todas las transacciones de estados hacia fuera del estado se colocan en el evento exit porque son iguales. El evento do puede ser usado para especificar una acción realizada mientras se encuentra en el estado; por ejemplo, enviar un mensaje, esperar o calcular. Estos eventos estándar no pueden ser usados para otros propósitos. El comportamiento que ocurre cuando el objeto se encuentra dentro del estado es llamado una actividad. Una actividad inicia cuando se entra al estado y se completa o se interrumpe por una transición de estados hacia afuera. El comportamiento puede ser una simple acción, o puede ser un evento enviado a otro objeto. Al igual que con las acciones y condiciones guardia, este comportamiento típicamente es mapeado a operaciones en el objeto. La notación del UML para la información detallada de los estados es mostrada en la siguiente figura.

Figura 62: Detalles de los estados

Página 124

Análisis y Diseño de Sistemas con el UML

La sintaxis formal para el compartimento de actividades es: nombre_evento lista_argumentos ‘/’ expresión-acción

El nombre de evento puede ser cualquier evento, incluyendo los eventos estándar entry, exit y do. La expresión-acción indica que acción debería ser realizada cuando el evento ocurra. Una acción do dentro de un estado puede ser un proceso continuo, lo cual indica que un evento en una transición de estados puede interrumpir una acción do interna continua. Detalles de la transición de estados

Una transición de estados puede tener una expresión-acción y/o condición guardia asociada con ella, y también puede disparar un evento (cláusula send). La sintaxis formal para especificar una transición de estados es: signatura_del_evento ‘[‘ condición_guardia ‘]’ ‘/’ expresión-acción ‘^’ cláusula_send

Signatura del evento

La signatura del evento consiste de un nombre de evento y parámetros, que especifican qué evento dispara la transición, junto con datos adicionales conectados al evento. La sintaxis de la signatura del evento está definida como: nombre_del_evento ‘(‘ parámetro ‘,’, ...’)’

Los parámetros son una lista separada por comas de parámetros con la sintaxis: nombre_del_parámetro ‘:’ expresión_de_tipo, nombre_del_parámetro ‘:’ expresión_de_tipo ...

Ejemplos de transiciones de estados con signaturas de eventos son: dibujar(f : figura, c : color) redibujar() imprimir(factura)

Condición guardia

Una condición guardia es una expresión boleana colocada en una transición de estados. Si la condición guardia es combinada con la signatura del evento, el evento debe ocurrir y la condición guardia debe ser verdadera para que la transición se dispare. Si solamente una condición guardia está añadida a una transición de estado la transición se disparará cuando la condición se vuelva verdadera. Ejemplos de transiciones de estado con condiciones guardia son: [t = 15seg] [número de facturas > n] retirar (cantidad) [balance >= cantidad]

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 125

Expresión-acción

Una expresión-acción es una expresión procedural ejecutada cuando la transición se dispara. Puede ser escrita en términos de operaciones y atributos dentro del objeto dueño (el objeto que posee todos los estados) o con parámetros dentro de la signatura del evento. Es posible tener más de una expresiónacción en una transición de estados, pero deben estar delimitadas con una fleca inversa (/). Las acciones expresiones son ejecutadas una a una en el orden especificado (de izquierda a derecha). Las expresiones-acciones anidadas o recursivas no están permitidas. Sin embargo, es posible tener una transición de estados que contenga solamente una expresión-acción. Ejemplos de transiciones de estados con expresiones-acciónes son: incrementar () / n := n + 1 / m := m + 1 añadir (n) / suma := suma + n / parpadear

Tanto las expresiones-acciones como las condiciones guardia son comportamientos del objeto y típicamente se convierten en operaciones. A menudo estas operaciones son privadas – es decir, son usadas solamente por el objeto mismo. Cláusula send

La cláusula send es un caso especial de una acción. Es una sintaxis específica para enviar un mensaje durante la transición entre dos estados. La sintaxis consiste de la expresión destino y nombre del evento como se define a continuación; expresión_de_destino ‘.’nombre_de_evento_del_destino ‘(‘ argumento ‘,’, ...’)’

La expresión de destino es una expresión que evalúa a un objeto o un conjunto de objetos. El nombre del evento es el nombre del evento con significado para el objeto (o conjunto de objetos) destino. El destino de objeto puede ser también el objeto mismo. [timer = time-out] / bajar (primer piso)

puede ser escrita como cláusula send como: [timer = timer-out] ^ self.bajar (primer piso)

Otros ejemplos de transiciones de estados con una cláusula send son: sin_papel () ^ indicador.encender() botón_izquierdo_presionado (lugar) / color := seleccionarColor(lugar) ^ lapiz.establecer(color)

Los diagramas de estado deben ser fáciles de comunicar y entender, pero a veces es difícil expresar dinámicas internas complejas y al mismo tiempo crear un modelo que es fácil de comunicar. En cada situación, el modelador debe decidir si crear un modelo con todas las dinámicas internas como aparecen en detalle, o simplificarlas haciendo el modelo más fácil de entender.

Página 126

Análisis y Diseño de Sistemas con el UML

Figura 63: Detalles de la transición de estados

Eventos

Un evento es algo que ocurre y que puede causar alguna acción. Por ejemplo, cuando presiona el botón Play en su CD Player, comienza a tocar (dado que el CD Player está encendido, un CD está insertado, y el CD Player está en buen estado). El evento es que Ud. presiona el botón Play, y la acción es que comienza a tocar. Cuando hay conexiones bien definidas entre eventos y acciones se llama una causalidad. En ingeniería de software, normalmente modelamos sistemas causales en los cuales eventos y acciones están conectados entre sí. No es causal por ejemplo, si maneja rápido en la autopista y la policía lo detiene, porque la acción no es segura; por lo tanto, no hay conexión entre el evento y la acción. Hay cuatro tipos de eventos en el UML:

Una condición se vuelve verdadera: Esto es mostrado como una condición guardia en una transición de estados Recibo de una señal explícita de otro objeto: La señal misma es un objeto. Esto es mostrado como una signatura de evento en las transiciones de estados. Este tipo de evento es llamado un mensaje. Recibo de un llamado en una operación por otro objeto (o por el mismo objeto): Esto es mostrado como una signatura de evento en las transiciones de estados. Este tipo de evento es llamado un mensaje. Paso de un período de tiempo designado: El tiempo es calculado normalmente después de otro evento designado (a menudo la entrada para el estado actual) o el paso de un tiempo dado. Esto es mostrado como una expresión de tiempo en las transiciones de estado.

Note que los errores pueden ser también eventos útiles de modelar. El UML no da ningún soporte explícito para los eventos de error, pero puede ser modelado como un evento estereotipado; por ejemplo:

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 127

<<error>> out_of_memory

Es importante saber alguna semántica básica sobre los eventos. Primero, los eventos son disparadores que activan las transiciones de estados; estos eventos son procesados uno a la vez. Si un evento potencialmente puede activar más de una transición de estados, solamente una de las transiciones será disparada (cuál de ellas es indefinida). Si un evento ocurre y la condición guardia de la transición es falsa, el evento será ignorado (el evento NO será almacenado disparando la transición cuando la condición guardia sea cierta). Una clase puede recibir y enviar mensajes; es decir, llamadas de operación o señales. La signatura de evento para una transición de estado es usada para ambas. Cuando una operación es llamada, se ejecuta y produce un resultado. Cuando una objeto señal es enviado, el receptor captura el objeto y lo usa. Las señales son clases ordinarias, pero usadas solamente para enviar señales; representan la unidad enviada entre objetos en el sistema. Las clases de señal pueden ser estereotipadas con el estereotipo <<signal>>, que restringe la semántica de los objetos, lo que indica que sólo pueden ser usados como señales. Es posible construir jerarquías de señales que soporten polimorfismo, de tal forma que si una transición de estado tiene una signatura de evento que especifique una señal específica, todas las subseñales también puedan ser aceptadas por la misma especificación.

Figura 64: Una jerarquía de clases señal con una superclase abstracta.

Enviando mensajes entre diagramas de estado

Los diagramas de estado pueden enviar mensajes a otros diagramas de estado. Esto es mostrado ya sea por acciones (especificando el receptor en una cláusula send) o con flechas punteadas entre los diagramas de estado. Si se usan flechas punteadas, los diagramas de estado deben ser agrupados dentro de sus objetos (se usa el rectángulo de clase). El símbolo de clase puede ser usado también para

Página 128

Análisis y Diseño de Sistemas con el UML

modelar sistemas o subsistemas (algo así como una macro clase). La flecha punteada debe ser dibujada de una transición dentro del objeto fuente al borde del objeto destino. Entonces, una transición debería ser dibujada dentro del objeto destino, dentro del objeto destino, que corresponde a y captura el mensaje especificado.

Figura 65: Mensajes entre diagramas de estado

Subestados

Un estado puede tener subestados anidados, los cuales pueden ser mostrados en otros diagramas de estado. Los subestados pueden ser subestados-y o subestados-o. Un subestado-o indica que el estado tiene subestados, pero solo uno a la vez. Por ejemplo, un carro puede estar en el estado corriendo, que tiene dos subestados: adelante y atrás.

Figura 66: Subestados-o

Por otro lado, el estado corriendo puede tener subestados concurrentes (subestados-y): adelante y baja velocidad, adelante y alta velocidad, atrás y baja velocidad, atrás y alta velocidad. Cuando un estado tiene subestados-y, varios de ellos pueden ser ciertos en paralelo, indicando que un estado puede tener subestados que son ambos subestados-y y subestados-o. Los subestados-y pueden ser llamados también subestados concurrentes, y pueden ser usados cuando se modelan los estados de los hilos concurrentes.

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 129

Figura 67: Subestados-y

Indicador de historia

Un indicador de historia es usado para memorizar estados internos; por ejemplo, recuerdo un estado de tal forma que es posible regresar a ese estado posteriormente, en caso de que una actividad tenga que ser interrumpida o revertida. Un indicador de historia se aplica a la región de estado en la cual es colocado. Un indicador de historia es mostrado como un círculo con una H dentro. Puede tener varias transiciones de entrada, pero ninguna de salida.

Página 130

Análisis y Diseño de Sistemas con el UML

Figura 68: Indicador de historia

Diagramas de Actividades Los diagramas de actividades son una parte inesperada de UML. A diferencia de la mayoría de técnicas del UML, el diagrama de actividades no tiene un origen claro en el trabajo anterior de Rumbaugh, Booch o Jacobson. Combinan ideas de varias técnicas: los diagramas de eventos de Jim Odell, técnicas de modelaje de estados SDL, y redes Petri. Los diagramas son particularmente útiles en conexión con el flujo de trabajo y para describir comportamiento que tiene una gran cantidad de procesamiento paralelo. Los diagramas de actividades capturan acciones y sus resultados. Se enfocan en el trabajo realizado en la implementación de una operación (método), y las instancias en un caso de uso o en un objeto. El diagrama de actividades es una variante del diagrama de estado y tiene un propósito ligeramente diferente, el cual es capturar acciones (trabajo y actividades que serán realizadas) y sus resultados en términos de cambios de estados. Los estados en un diagrama de actividades cambian al estado siguiente directamente cuando la acción en el estado es realizada (sin esperar un evento como en los diagramas de estado). Otra diferencia entre los diagramas de actividades y los diagramas de estado es que las acciones pueden ser colocadas en swimlanes. Un swimlane agrupa actividades con respecto a quién es responsable por ellas o donde residen en la organización. Un diagrama de actividades es una manera alterna de describir interacciones, con la posibilidad de expresar cómo se toman las acciones, que hacen (cambio de estados de objetos), cuándo se hacen (secuencia de acciones), y dónde se hacen (swimlanes).

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 131

Los diagramas de actividades pueden ser usados con propósitos diferentes, incluyendo:

Capturar el trabajo (acciones) que serán realizadas cuando una operación sea ejecutada (la instancia de la implementación de la operación). Este es el uso más común de los diagramas de actividad. Capturar el trabajo interno de un objeto. Mostrar cómo un conjunto de acciones relacionadas pueden ser realizadas, y cómo afectarán a los objetos alrededor de ellos. Mostrar cómo una instancia de un caso de uso puede ser realizada en términos de acciones y cambios de estado de los objetos. Mostrar cómo un negocio trabaja en términos de trabajadores (actores), flujos de trabajo, organización, y objetos (factores físicos e intelectuales usados en el negocio).

La gran fortaleza de los diagramas de actividades es que soportan y motivan el comportamiento paralelo. Esto los hace una gran herramienta para modelaje de flujo de trabajo, y programación con múltiples hilos. Una gran desventaja es que los enlaces entre las acciones y los objetos no son muy claras. Por esta razón, mucha gente siente que los diagramas de actividades no son orientados a objetos y, por lo tanto, malos. Sin embargo, la técnica es muy útil y no se desechan las técnicas útiles. Los diagramas de actividades son particularmente útiles en las siguientes situaciones:

Cuando se analiza un caso de uso. En esta etapa no interesa asignar acciones a los objetos; sólo se necesita ver qué acciones se necesitan realizar y cuales son las dependencias de comportamiento. Se asignan los métodos a los objetos posteriormente con un diagrama de interacción. Para entender el flujo de trabajo entre varios casos de uso. Cuando los casos de uso interactúan entre si, los diagramas de actividades son una gran herramienta para representar y entender el comportamiento. En situaciones que son dominadas por el flujo de trabajo, son soberbios. Tratar con aplicaciones con múltiples hilos.

Acciones y transiciones

Una acción es realizada para producir un resultado. Desde un punto de vista conceptual, una acción es cierta tarea que necesita ser realizada y desde el punto de vista de especificación es un método en una clase. La implementación de una operación puede ser descrita como un conjunto de acciones relacionadas, las cuales son convertidas en código posteriormente. Un diagrama de actividades puede tener un estado de inicio y un estado final. Un estado de inicio es mostrado con un círculo sólido relleno, el estado final es mostrado con un circulo que rodea a un círculo sólido relleno de menor tamaño (un bull’s eye). Sin embargo, los diagramas de actividades no necesitan tener un estado final necesariamente; el punto final es el punto donde todas las acciones han corrido y no hay nada más que hacer. Las acciones (estados de acción) en un diagrama de actividades son dibujadas como rectángulos con esquinas redondeadas. Dentro de la acción, un texto es colocado para especificar la acción o acciones tomadas. Las transiciones entre las acciones tienen la misma sintaxis que en los diagramas de estado, excepto por los eventos. Los eventos pueden ser añadidos solamente en la transición del estado inicial a la primera acción. Las transiciones entre acciones son mostradas con una flecha a las cuales se les pueden añadir condiciones guardia, cláusulas send (envio), y una expresión-acción. A menudo nada es especificado, indicando que la acción será disparada tan pronto las actividades en el estado sean realizadas.

Página 132

Análisis y Diseño de Sistemas con el UML

Las transiciones son protegidas con condiciones guardia, las cuales deben ser ciertas para que ocurra la transición, usando la misma sintaxis para condiciones guardia que en los diagramas de estado. Las decisiones son hechas usando condiciones guardia. Por ejemplo, [si] y [no]. Un símbolo con forma de diamante es usado para mostrar un punto de decisión. El símbolo de decisión puede tener una o más transiciones entrantes y dos o más transiciones salientes etiquetadas con condiciones guardia. Normalmente una de las transiciones salientes es siempre verdadera.

Figura 69: Diagrama de actividades con cláusula send, condiciones guardia y decisiones

Una transición puede estar dividida en una o más transiciones que resultan en la ejecución paralela de las mismas. Las acciones son ejecutadas concurrentemente, aunque pueden ser ejecutadas una por una. Lo importante es que las transiciones paralelas sean realizadas antes de que se unan (si se llegan a unir). Una línea gruesa (barra de sincronización) es dibujada para mostrar que una transición está dividida en varias ramificaciones, y muestra la división actual en acciones paralelas. La barra de sincronización es también usada para mostrar la unificación de las ramificaciones. También se pueden añadir indicadores de iteración (mostrado con un asterisco) para indicar que el mensaje es enviado muchas veces. Puede mostrar las bases de la iteración dentro de corchetes (como *[for each Producto en]). Cuando se da una iteración, usualmente se mira posteriormente una barra de sincronización que junta los hilos separados. Generalmente a esta barra de sincronización se le añade una condición, de tal forma que cada vez que un hilo llega a ella la condición es probada; si es cierta, se dispara la transición de salida. Las barras de sincronización sin condición trabajan de la misma forma. La falta de una condición indica que la condición por defecto para las barras de sincronización es usada (que es que todas las transiciones de entrada hayan ocurrido). Esto muestra las dos formas de mostrar paralelismo en un diagrama de actividad: mediante transiciones múltiples que salen de una barra de sincronización y mediante la misma actividades que sale múltiples veces mediante un indicador de iteración.

Cap铆tulo 10: Analizando el Comportamiento de los Objetos

P谩gina 133

Figura 70: Transiciones ramificadas, iteraci贸n y condiciones en barras de sincronizaci贸n

Figura 71: Diagrama de actividades descompuesto para Autorizar Pago

Página 134

Análisis y Diseño de Sistemas con el UML

Los diagramas de actividades también pueden tener varios puntos de inicio, lo cual es correcto porque el diagrama de actividades representa como el negocio reacciona a eventos externos múltiples. Estos diagramas generalmente son usados para describir comportamiento que abarca varios casos de uso; los diagramas de actividades pueden mostrar la imagen completa del comportamiento interno. Las acciones también pueden ser descompuestas en otro diagrama de actividad, texto o código. Cuando se dibuja un diagrama de actividades como descomposición de una acción se debe proporcionar un solo punto inicial y tantos puntos de salida como transiciones de salida hayan en la acción descompuesta. Swimlanes

Como ya se mencionó, un swinlane agrupa actividades, normalmente con respecto a su responsabilidad. Los swimlanes son usados para varios propósitos diferentes; por ejemplo, para mostrar explícitamente dónde son realizadas las acciones (en qué objeto), o para mostrar en que parte de la organización se realiza un trabajo (acción). Los swimlanes son dibujados como rectángulos verticales. Las actividades que pertenecen a un swimlane son colocadas dentro de su rectángulo. Al swimlane se le da un nombre que es colocado en la parte superior del rectángulo. Los swimlanes son buenos porque combinan la lógica mostrada en los diagramas de actividades con la responsabilidad mostrada en los diagramas interacción. Sin embargo, pueden ser difíciles de dibujar en un diagrama complejo.

Figura 72: Swimlanes

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 135

Objetos

Se pueden mostrar objetos en los diagramas de actividad. Pueden ser entrada o salida de las acciones, o pueden mostrar simplemente que un objeto es afectado por una acción específica. Los objetos son mostrados como rectángulos de objetos. Cuando un objeto es entrada para una acción, es mostrado con una flecha punteada del objeto a la acción; cuando es salida es mostrado con una flecha punteada de la acción al objeto. Cuando el objeto es afectado por la acción, se muestra como una línea punteada entre la acción y el objeto. Opcionalmente, el estado del objeto puede ser mostrado bajo el nombre de la clase y entre corchetes, tales como [planeado], [comprado], [lleno], etc.

Figura 73: Objeto como entrada y salida para acciones

Señales

Se pueden enviar o recibir señales (las señales fueron descritas anteriormente) en los diagramas de actividad. Hay dos símbolos, uno para enviar y uno para recibir una señal. El símbolo de envío corresponde a la cláusula send (envío) añadida a una transición. Al igual que con la cláusula send, tanto el símbolo de envío como el de recepción son añadidos a una transición; sin embargo, gráficamente la transición es dividida en dos transiciones con un símbolo de envío y uno recepción en medio. Los símbolos de envío y de recepción pueden ser añadidos a los objetos que son los receptores o los emisores de los mensajes. Esto es hecho dibujando una línea punteada con una flecha del símbolo de envió o recepción al objeto. Si es un símbolo de envío la flecha apunta al objeto; si es un símbolo de recepción, la flecha apunta al símbolo de recepción. Es opcional dibujar los objetos. El símbolo de envío es un pentágono convexo, mientras el símbolo de recepción es un pentágono concavo.

Página 136

Análisis y Diseño de Sistemas con el UML

Figura 74: : Envío y recepción de señales

Modelaje de negocios con diagramas de actividad

De acuerdo con Nilson5, cuando se modelan los negocios, estos aspectos importantes deben ser estudiados y descritos en los modelos: recursos, reglas, metas, y acciones (flujo de trabajo). Hay dos tipos de recursos: físicos e información. Los trabajadores (actores dentro del negocio) son ejemplos de recursos; son objetos físicos. Otros objetos físicos podrían ser elementos que son producidos, consumidos o manejados. Los objetos de información llevan información acerca de los negocios. Las reglas del negocio restringen el uso de los recursos, tanto físicos como de información. Por ejemplo, una regla podría ser que cierta información es estratégica y debe ser mantenida confidencial. El uso de estos recursos es el trabajo actual, llamado el grupo de trabajo. Las metas del negocio motivan el flujo de trabajo, donde los recursos son usados de acuerdo con las reglas especificadas. En modelaje de negocios, es a menudo importante separar los objetos físicos de los objetos de información. Los objetos físicos son esos que existen en el mundo real (o el entendimiento del mundo real), por ejemplo, carros, clientes, y contratos. Los objetos de información llevan información sobre el negocio, ya sea sobre el trabajo o cosas físicas (objetos). Por lo tanto los objetos cliente en un sistema de información no son los clientes reales; contienen información sobre los clientes reales. Se pueden usar estereotipos para separar objetos físicos de los objetos de información dentro de los diagramas de actividad. El estereotipo <<Information>> (información) 5

B. Nilsson. “Vision 95,” CaiSE91 Conferencia sobre Ingeniería de Sistemas de Información Avanzados, 1991.

Capítulo 10: Analizando el Comportamiento de los Objetos

Página 137

podría, por ejemplo, ser usado para indicar que un objeto es un objeto de información; similarmente, el estereotipo <<Physical>> (físico) podría ser usado para indicar que un objeto representa el objeto físico real. Cuando los objetos son manejados, producidos, o consumidos, están cambiando sus estados, lo cual puede ser descrito en diagramas de actividad. Todos los negocios tienen una organización, y podrían a veces ser de interés en los modelos. En los diagramas de actividad, se usan swimlanes para representar organizaciones. Los trabajadores son considerados recursos, y podrían ser tratados como objetos físicos aunque usualmente son tratados como actores. Un actor es un sistema (un ser humano es también considerado un sistema) que actúa en el negocio. Normalmente, los trabajadores son seres humanos empleados en el negocio y que realizan el trabajo. Los actores están dividiendo el trabajo, y están soportados por sistemas de información y otros sistemas. Los actores pueden ser modelados con el icono del UML o con el estereotipo <<Actor>>. La aproximación a modelar negocios con diagramas de actividades puede ser complementada con casos de uso u otras técnicas para capturar los requerimientos del sistema (el sistema del negocio). Note que con esta aproximación, los objetos son identificados y clasificados en elementos físicos y de información. Los objetos de información identificados pueden convertirse en una fundación para analizar y construir un sistema para soportar el negocio modelado. Usar diagramas de actividades tienen similitudes a implementar técnicas de flujo de trabajo como IDEF0 (un lenguaje de modelaje visual de procesos estándar). Por lo tanto, las acciones pueden ser descritas como en esas técnicas. Las acciones pueden ser descritas de muchas formas. Una manera práctica es describirlas con los siguientes encabezados:

Definición: una descripción formal o informal de la acción. Propósito: una descripción del propósito de la acción. Característica: típicamente repetitiva o de una sola vez. Método de medición: cuando es posible y deseable medir las acciones, el método de medición debe ser descrito. Actores/Roles: ¿Qué actores y roles son requeridos para realizar la acción?. Tecnología de la información: ¿Qué tipo de soporte de sistemas de información es requerido. Reglas, prácticas, y estrategias: cualquier documento, estrategia, o políticas que restringen el rendimiento de las acciones debe ser mencionada.

Página 138

Análisis y Diseño de Sistemas con el UML

Figura 75: Un patrón de negocios para manufactura descrito con un diagrama de actividad

Cap铆tulo 11: Revisando el Modelo Combinando clases

Dividiendo clases

Eliminando clases

Revisi贸n de la consistencia

Recorrido de los escenarios

Trazado de eventos

Revisi贸n de la documentaci贸n

Capítulo 11: Revisando el Modelo

Página 141

medida que más casos de uso son desarrollados, es necesario hacer el modelo homogéneo. Esto es especialmente cierto si múltiples grupos están trabajando en diferentes partes del modelo. Debido a que los casos de uso y escenarios tratan con la palabra escrita, la gente puede usar diferentes palabras para indicar la misma cosa, o pueden interpretar las palabras diferentemente. En este momento, las clases pueden ser combinadas, divididas en múltiples clases, o una clase puede ser eliminada del modelo. Esto es la maduración natural del modelo durante el ciclo de vida del proyecto. La homogeneización no ocurre en un punto del ciclo de vida – debe ser continua. Los proyectos que esperan hasta el final para juntar información desarrollada por múltiples grupos de personas están destinados al fracaso. Los proyectos más exitosos están conformados de grupos que tienen mecanismos de comunicación constante implementados. La comunicación puede ser tan simple como una llamada telefónica o tan formal como una reunión con horario – todo depende del proyecto y la naturaleza de la necesidad para hablar (por ejemplo, es una pregunta simple o una revisión formal de una pieza del sistema). La única cosa que importa es el hecho de que los grupos no trabajan solos.

Combinando clases Si diferentes grupos están trabajando en diferentes escenarios, una clase puede ser llamada por varios nombres. Los conflictos de nombre deben ser resueltos. Esto es realizado principalmente mediante recorrido de los modelos. Cada clase junto con su definición es examinada. También se examinan los atributos y operaciones definidos para las clases. Se debe buscar el uso de sinónimos. Una vez que ha sido determinado que dos clases hacen lo mismo, escoja la clase con el nombre que es más cercano al lenguaje usado por los clientes. Preste especial atención a las clases de control creadas para el sistema. Inicialmente una clase de control es creada para cada caso de uso. Esto puede ser demasiado. Las clases de control con comportamiento similar deben ser combinadas. Examina la lógica de secuenciación de las clases de control para el sistema. Si son muy similares las clases de control pueden ser combinadas en una clase de control. Por ejemplo, si dos clases de control obtienen información de una clase de frontera y trabajan con las mismas clases de entidad es posible que puedan ser combinadas porque tienen comportamiento muy similar y accesan información similar.

Dividiendo clases Las clases deben ser examinadas para determinar si están siguiendo la regla de oro de la orientación a objetos, la cual dice que una clase debería hacer una cosa y hacerla bien. Deben ser cohesivas, es decir tratar solamente con un tema y no con dos. A menudo, lo que parece ser solamente un atributo finaliza teniendo estructura y comportamiento por si mismo y debe ser dividido en su propia clase. En ambos casos, la clase original debe ser dividida y las clases resultantes unidas por una asociación.

Eliminando clases Una clase puede ser eliminada del todo del modelo. Esto ocurre cuando:

La clase no tiene estructura o comportamiento. La clase no participa en ningún caso de uso.

Página 142

Análisis y Diseño de Sistemas con el UML

En particular examine las clases de control. Una falta de responsabilidad de secuenciación puede llevar a la eliminación de la clase de control. Esto es especialmente cierto si la clase de control solamente recibe información de la clase de frontera e inmediatamente la pasa a la clase de entidad sin necesidad de lógica de secuenciación.

Revisión de la consistencia La revisión de la consistencia es necesaria debido a que la vista estática del sistema, como es mostrada en los diagramas de clase, y la vista dinámica del sistema, como es mostrada en los diagramas de casos de uso y de interacción, están bajo desarrollo en paralelo. Debido a que ambas vistas están bajo desarrollo concurrentemente, deben ser revisadas entre sí (revisión cruzada) para asegurarse que no se estén tomando decisiones contradictorias o se asuman cosas diferentes. La revisión de la consistencia no ocurre durante una fase separada o un solo paso del proceso de análisis. Debe ser integrado a lo largo del ciclo de vida del sistema bajo desarrollo. El chequeo de la consistencia es mejor cumplido formando un pequeño grupo (cinco a seis personas cuando mucho). El grupo debería estar compuesto de una sección del personal – analistas y diseñadores, clientes o sus representantes, expertos del dominio, y personal de prueba.

Recorrido de los escenarios Un método principal para chequear la consistencia es recorrer los escenarios de alto riesgo en un diagrama de colaboración o secuencia. Debido a que cada mensaje representa comportamiento de la clase receptora, verifique que cada mensaje es capturado como una operación en diagrama de clase. Verifique que dos objetos que interactúan tienen un camino para comunicarse ya sea mediante una asociación o agregación. Especialmente busque relaciones recursivas que puedan ser necesarias debido a que estas relaciones son fáciles de omitir durante el análisis. Las relaciones recursivas son necesarias cuando múltiples objetos de la misma clase interactúan durante un escenario. Para cada clase representada en un diagrama de clase, asegúrese de que la clase participa en por lo menos un escenario. Para cada operación listada para la clase, verifique que la operación es usada en por lo menos un escenario o que es necesaria para completar la clase. Finalmente, verifique que cada objeto incluido en un diagrama de secuencia o colaboración pertenece a una clase en el diagrama de clase.

Trazado de eventos Para cada mensaje mostrado en un diagrama de secuencia o colaboración, verifique que una operación en la clase emisora sea responsable de enviar el evento y que una operación en la clase receptora espera el evento y lo maneja. Verifique que una asociación o agregación en el diagrama de clase existe entre las clases emisora y receptora. Añada la relación al diagrama de clase si no existe. Finalmente, si un diagrama de estados para la clase existe, verifique que el evento es representado en el diagrama para la clase receptora. Esto es necesario porque el diagrama muestra todos los eventos que una clase puede recibir.

Revisión de la documentación Cada actor, caso de uso y clase deben estar documentados: revise que los nombres de clase sean únicos y revise que las definiciones estén completas. Asegúrese que todos los atributos y operaciones tienen una definición completa. Finalmente, revise que todos los estándares, especificaciones de formato, y reglas de contenido establecidas para el proyecto han sido seguidas.

Capítulo 12: Diseño del Sistema Añadiendo clases de diseño

Diseñando la interfaz del usuario

Diseñando las relaciones

Diseñando atributos y operaciones

Diseñando la herencia

Interfaces

Clases abstractas

Restricciones y Derivaciones

La emergencia de patrones

Capítulo 12: Diseño del Sistema

Página 145

l diseño es una expansión y adaptación técnica de los resultados del análisis. Las clases, relaciones, y colaboraciones del análisis son complementadas con nuevos elementos, enfocándose en cómo implementar el sistema en una computadora. Todos los detalles de cómo las cosas deben trabajar técnicamente y las restricciones del ambiente de implementación deben ser considerados. Los resultados del análisis son acarreados al diseño y mantenidos como centro del sistema. Las clases de análisis deben ser empotradas en una infraestructura técnica, donde las clases de diseño les ayudan a volverse persistentes, a presentarse en la interfaz del usuario, etc. Separando las clases de análisis de la infraestructura técnica es mucho más fácil cambiar o actualizar una de ellas. En el diseño, se usan los mismos tipos de diagramas que en el análisis, aunque se deben crear y modelar nuevos diagramas para mostrar la solución técnica.

Añadiendo clases de diseño Típicamente se añaden clases al modelo para facilitar el cómo de un sistema. Por ejemplo, la mayoría de los sistemas indican que el usuario debe introducir una clave para entrar al sistema, la cual debe ser validada. Una clase que sabe cómo validar claves se añade al sistema para implementar este requerimiento. A medida que se añaden clases al sistema, son desplegadas en los diagramas.

Diseñando la interfaz del usuario Más temprano en el ciclo de vida del proyecto, se han creado las clases de frontera del sistema, las cuales interactúan con el usuario. Ahora estas clases deben ser finalizadas – número de ventanas, disposición de las ventanas, y manejo de eventos de los usuarios. Los diagramas de secuencia son buenas fuentes para los requerimientos de la interfaz del usuario. Algo en la interfaz del usuario debe proporcionar la capacidad de comunicar (recibir y enviar) todos los mensajes de un actor. Por ejemplo, para diseñar la interfaz del usuario del caso de uso Seleccionar Curso para Enseñar se analizan sus escenarios asociados encontrándose los siguientes requerimientos:

El profesor debe introducir su password para entrar al sistema. Se crea una ventana para pedir el password al profesor. Si el password es válido, la ventana Opciones de Curso de Profesor es desplegada. La ventana contiene un campo para el semestre y los siguientes botones: AÑADIR CURSO, BORRAR CURSO, REVISAR HORARIO, IMPRIMIR HORARIO. Se crean ventanas para las opciones añadir, borrar, y revisar.

La opción AÑADIR CURSO trata con asociar un profesor con un curso. Este escenario necesita una ventana para permitir al profesor entrar la información necesaria – se puede llamar ventana añadir. La ventana añadir contiene las siguientes opciones:

Campo de nombre de curso. Campo de número de curso. Lista desplegable de grupos. Botón Aceptar. Botón Cancelar. Botón Salir.

Una vez que el profesor entra el nombre y número del curso, el sistema recupera los grupos disponibles. Adicionalmente, el profesor será capaz de seleccionar un grupo. Cuando el botón OK es

Página 146

Análisis y Diseño de Sistemas con el UML

presionado un mensaje es enviado al objeto curso. La implementación actual de la interfaz depende de la librería de clases escogida y va más allá de nuestro alcance.

Diseñando las relaciones Las siguientes decisiones de diseño deben ser hechas para las relaciones: navegación, contenimiento, dependencia y refinamiento, e implementación de la multiplicidad. Navegación

Las asociaciones y agregaciones son relaciones bidireccionales. Durante el diseño, las asociaciones son analizadas para determinar si la bidireccionalidad realmente es necesaria. Si es posible, la relación es hecha unidireccional debido a que las relaciones unidireccionales son más fáciles de implementar y mantener.

Figura 76: Agregación unidireccional

Contenimiento por valor (Composición)

El contenimiento de la agregación debe ser añadido al modelo. El contenimiento puede ser por valor o por referencia. El contenimiento por valor (llamado composición) implica propiedad exclusiva de la clase contenedora y es mostrado por un diamante relleno. El contenimiento por referencia no indica propiedad exclusiva; es mostrado por un diamante abierto. La composición indica que las partes viven dentro del todo y por lo tanto serán destruidas con el todo. La multiplicidad en la parte del todo debe ser 0..1, pero la multiplicidad en las partes puede ser cualquiera. Una agregación de composición forma un árbol, mientras una agregación compartida forma una red.

Figura 77: Agregación y Composición

Capítulo 12: Diseño del Sistema

Página 147

Por ejemplo, en la figura anterior las composiciones a Punto indican que una instancia de Punto puede estar en Polígono o en Círculo, pero no en ambos. Sin embargo, una instancia de Estilo puede ser compartida por muchos Polígonos y Círculo. Además, esto implica que borrar un Polígono causaría que los Puntos asociados sean borrados, pero no el Estilo asociado. Esta restricción – que un Punto puede aparecer solamente en un Polígono o Círculo a la vez – no podría ser expresada con las multiplicidades por sí mismas. También implica que el punto es objeto por valor. Dependencia y Refinamiento

Una relación de asociación puede ser cambiada en una relación de dependencia en este momento. La dependencia implica una conexión semántica entre dos elementos, un cambio en el elemento independiente afectará al dependiente. El elemento puede ser una clase, paquete, caso de uso, etc. Una dependencia implica que el objeto dependiente no tiene conocimiento explícito de la localidad del objeto independiente – se le debe decir dónde está localizado. Típicamente, el objeto independiente es pasado como un parámetro a uno de los métodos de la clase dependiente, es declarado localmente dentro de un método de la clase dependiente, el dependiente accesa una variable global del independiente o llama una operación al nivel de clase del independiente. Una dependencia friend (amigo) indica que un elemento de modelo dependiente tiene acceso a la estructura interna del elemento independiente. Una relación de dependencia es mostrada por una flecha punteada apuntando del dependiente al independiente.

Figura 78: Relación de dependencia

Un refinamiento es una relación entre dos descripciones de la misma cosa, pero a diferentes niveles de abstracción. Una relación de refinamiento puede ser entre un tipo y una clase que lo realiza, en cuyo caso es llamada una realización. Otros refinamientos son entre clases de análisis y clases de diseño que modelan la misma cosa, o entre una descripción de alto nivel y una descripción de bajo nivel (tal como una vista rápida de una colaboración y un diagrama detallado de la misma colaboración). También pueden ser usadas para modelar diferentes implementaciones de la misma cosa (una que es simple y otra más compleja, pero más eficiente). Una relación de refinamiento es mostrada como una flecha punteada con un triángulo entre dos elementos (un símbolo de generalización con línea punteada).

Figura 79: Relación de refinamiento

La refinación es usada en la coordinación de modelos. En proyectos grandes, todos los modelos que son producidos deben ser coordinados. La coordinación de los modelos puede ser usada para:

Mostrar cómo los modelos en diferentes niveles de abstracción están relacionados. Mostrar cómo los modelos de diferentes fases están relacionados. Soportar administración de la configuración. Soportar trazabilidad en el modelo.

Página 148

Análisis y Diseño de Sistemas con el UML

Implementación de la multiplicidad

La multiplicidad de uno es implementada como un objeto empotrado, una referencia o un puntero. La multiplicidad de más de uno es típicamente implementada usando una clase contenedora (un conjunto o lista). De nuevo, la lista puede ser un objeto empotrado o un puntero al contenedor. La decisión de actualizar el modelo para mostrar todos los contenedores que están siendo usados es dependiente del proyecto. Típicamente no se muestran todos los contenedores porque tienden a hacer complejo el diagrama.

Diseñando atributos y operaciones Durante el análisis era suficiente especificar los nombres de atributos y operaciones. Durante el diseño, los tipos de datos, visibilidad y valores iniciales deben ser especificados para los atributos así como las signaturas de las operaciones. Atributos

Un atributo tiene un tipo, que nos dice que tipo de atributo es. Tipos típicos de atributos son integer, Boolean, real, point, area, y enumerator, que son llamados tipos primitivos. Pueden ser específicos para un lenguaje de programación y cualquier tipo puede ser usado, incluyendo otras clases.

Figura 80: Clase con atributos con tipo

Los atributos tienen diferente visibilidad. La visibilidad describe si el atributo es visible y puede ser referenciado desde otras clases. Si un atributo tiene la visibilidad public (público) puede ser usado y visto desde fuera de la clase. Si tiene la visibilidad private (privado) no lo puede accesar desde otras clases. Otra visibilidad es protected, la cual es usada junto con la generalización y especialización para permitir que las subclases tengan acceso a los atributos de su superclase. Otros tipos de visibilidad pueden ser definidos para un lenguaje de programación particular. Público es expresado con un signo más (+), privado con un signo (-) y protegido con un signo de número (#) antes del nombre del atributo.

Figura 81: Clase con atributos públicos y privados

Los atributos pueden tener valores por defecto, lo cual indica que el valor es asignado en el momento que los objetos son creados.

Capítulo 12: Diseño del Sistema

Página 149

Figura 82: Clase con atributo con valor por defecto

Una clase también puede tener atributos al nivel de clase. Esto significa que un atributo es compartido entre todos los objetos de una clase dada (llamado a veces variable de clase). Un atributo al nivel de clase es subrayado.

Figura 83: Clase con atributo al nivel de clase

Un texto de propiedad puede ser usado para identificar explícitamente que valores son permitidos para un atributo. Es usada para especificar tipos de enumeración como color, estado, dirección, etc. Un texto de propiedad es escrito entre llaves y es una lista separada por comas de todos los posibles valores de un atributo enumeración.

Figura 84: Clase con un texto de propiedad (tipo de enumeración)

La sintaxis formal para describir un atributo es: visibilidad nombre : expresión_de_tipo = valor_inicial {texto_propiedad}

Solamente el nombre y el tipo son mandatorios; todas las otras partes son opcionales. El texto propiedad puede ser usado también para especificar otra información sobre el atributo, tal como si el atributo debe ser persistente.

Página 150

Análisis y Diseño de Sistemas con el UML

Operaciones

Una operación es descrita con un tipo de retorno, un nombre, y cero o más parámetros. Juntos, el tipo de retorno, nombre, y parámetros son llamados la signatura de la operación. La signatura describe todo lo necesario para usar la operación. Para utilizar una operación debe ser aplicada a un objeto de esa clase (es llamada en un objeto). Las operaciones en una clase describen lo que la clase puede hacer, es decir, que servicios ofrece, por lo tanto, pueden ser vistas como la interfaz a la clase. Al igual que un atributo una operación puede tener un alcance y visibilidad.

Figura 85: Clase con atributos y operaciones

Una clase también puede tener operaciones al nivel de clase. Una operación al nivel de clase puede ser llamada sin tener un objeto de la clase, pero está restringida a atributos al nivel de clase. Las operaciones al nivel de clase son definidas para realizar operaciones genéricas como crear objetos y encontrar objetos donde un objeto específico no está envuelto.

Figura 86: Clase con operación al nivel de clase

La sintaxis formal para una operación es: visibilidad nombre (lista_de_parámetros) : expresión_de_retorno {texto_propiedad}

donde la lista de parámetros es una lista separada por comas de parámetros formales, cada uno especificado usando la sintaxis: nombre : expresión_de_tipo = valor_inicial

La visibilidad es la misma que para los atributos (+ para público, - para privado y # para protegido). No todas las operaciones deben tener un tipo de retorno o parámetros, pero deben tener una signatura única (tipo de retorno, nombre y parámetros). Es posible tener valores iniciales en los parámetros, lo que significa que si el que llama la operación no proporciona un parámetro, el parámetro usará el valor por defecto especificado.

Capítulo 12: Diseño del Sistema

Página 151

Figura 87: Clase con operaciones con valores por defecto en los parámetros

La operación es parte de la interfaz de una clase; la implementación de una operación se conoce como un método. Una operación debe ser especificada con una signatura y con una precondición, poscondición, algoritmo y la relación que tiene con un objeto. Una precondición es algo que debe ser cierto para que la operación se ejecute. Una poscondición es algo que debe ser cierto después de que la operación se ejecute. Una poscondición podría ser por ejemplo, que después que la operación dibujar se ejecute una figura debe ser actualizada. Podría también ser documentado si la operación cambia el estado del objeto de alguna forma (ej.: el cambio de tamaño afecta el estado del objeto). Todas estas especificaciones son hechas como propiedades para una operación. Estas propiedades no son usualmente dibujadas en un diagrama, pero están disponibles desde una herramienta (de tal forma que cuando se haga clic en una operación todas sus propiedades y sus valores se muestren). Una clase persistente es una clase cuyos objetos existen después que el programa que los creó ha terminado. Las clases persistentes se almacenan en una base de datos, archivos, o algún almacenamiento permanente, y típicamente tienen operaciones al nivel de clase para manejar el almacenamiento de objetos; por ejemplo, store(), load(), create(). Una clase puede ser descrita como persistente poniéndole el estereotipo <<Persistent>> (persistente). Cuando los objetos son creados, normalmente deberían inicializar los atributos y enlaces a otros objetos. Es posible tener una operación llamada create que sea al nivel de clase usada para crear e inicializar los objetos. Es también posible tener una operación con el mismo nombre que la clase, lo que correspondería a un constructor en un lenguaje de programación (como C++ o Java). Un constructor es llamado para crear e inicializar un objeto de la clase. Usando tipos primitivos

Un tipo primitivo no es una clase, como un entero o un enumerador. No hay tipos primitivos predefinidos en el UML. Normalmente, la herramienta usada para dibujar los diagramas UML puede ser configurada para un lenguaje de programación específico, en cuyo caso, los tipos primitivos para el lenguaje se vuelven disponibles. Si el lenguaje de programación no es conocido (o el sistema a implementarse no debe ser implementado en un programa), un subconjunto de tipos normales podría ser usado (como integer, string, float). Los tipos primitivos son usados para tipos de retorno, parámetros, y atributos. Tipos generales como date, integer, real, Boolean, etc., pueden ser definidos. Las clases definidas en cualquier diagrama de clase en el modelo pueden ser usadas como tipos de atributos, tipos de retorno, parámetros, etc.

Página 152

Análisis y Diseño de Sistemas con el UML

Sutilezas en los lenguajes de programación

La visibilidad es uno de los conceptos que parece simple en principio, pero que tiene sutilezas complejas. La idea simple es que una clase puede tener elementos públicos, privados y protegidos. Sin embargo, cada lenguaje tiene sus propias reglas. Sus diferencias son pequeñas, pero confusas, especialmente para los programadores que trabajan en más de un lenguaje. En C++ un miembro público es visible en cualquier lugar del programa y puede ser llamado por cualquier objeto del sistema. Un miembro privado puede ser usado solamente por la clase que lo define. Un miembro protegido puede ser usado solo por la clase que lo define y por las subclases de ella. Por ejemplo si tenemos en clase Cliente que tiene una subclase ClientePersonal del cual Pedro es un objeto. Pedro puede usar cualquier miembro público de cualquier objeto del sistema; también puede usar cualquier miembro privado de la clase ClientePersonal; no puede usar los miembros privados definidos dentro de Cliente; pero puede usar los miembros protegidos dentro de Cliente y ClientePersonal. En Smalltalk todas las variables de instancia son privadas, y todas las operaciones son públicas. Sin embargo, privado no significa lo mismo que en C++. En Smalltalk privado es similar a protegido en C++, en el sentido de que Pedro podría accesar cualquier variable de instancia dentro de su propio objeto si la variable fue definida dentro de Cliente o ClientePersonal. Regresando a C++, digamos que tenemos otra instancia de ClientePersonal llamada José. José puede accesar cualquier miembro de Pedro que fuera definido en la clase ClientePersonal ya sea público, privado o protegido. José también puede accesar cualquier miembro protegido o público de Pedro que fuera definido en la clase Cliente. Sin embargo, en Smalltalk, José no puede accesar las variables de instancia privadas de Pedro – solamente las operaciones públicas de Pedro. En C++ se pueden accesar los miembros de otros objetos en la misma clase en la misma forma en que se accesan los miembros propios. En Smalltalk no importa si un objeto es de otra clase o no; solamente se pueden accesar las partes públicas de otro objeto. Como regla general es preferible no accesar los miembros privados o protegidos de otros objetos de la misma clase. Java es similar a C++ en que ofrece acceso libre a los miembros de otros objetos dentro de la misma clase. Java también añade una nueva visibilidad llamada paquete. Un miembro con la visibilidad paquete puede ser accesado solamente por instancias de otras clases dentro del mismo paquete. Continuando, para asegurarse de que las cosas no sean tan simples, Java redefine levemente protegido. En Java, un miembro protegido puede ser accesado por subclases, pero también por otras clases en el mismo paquete que la clase dueña. Esto significa que en Java protegido es más público que paquete. C++ añade un aspecto final. Un método o clase en C++ puede ser un friend (amigo) de una clase. Un amigo tiene acceso completo a todos los miembros de una clase – por lo tanto, de ahí la frase “en C++ los amigos se tocan las partes privadas entre sí.”

Capítulo 12: Diseño del Sistema

Página 153

Diseñando la herencia Durante el análisis las jerarquías de herencia entre abstracciones clave son establecidas. Durante el diseño, las jerarquías de herencia son refinadas para:

Incrementar la reutilización. Incorporar clases de diseño. Incorporar librerías de clases escogidas. Determinar si alguna superclase es abstracta.

Los diagramas de análisis son revisados para identificar atributos, operaciones, y relaciones comunes. Se definen superclases para llevar los aspectos comunes encontrados. Esto reduce la cantidad de código que debe ser escrito y probado. También fortalece la uniformidad; es decir, el mismo elemento no puede ser manejado diferentemente en dos clases diferentes si las dos clases heredan de la misma superclase. Es también durante esta fase del desarrollo que el polimorfismo se añade al modelo. Las subclases pueden redefinir operaciones. Las operaciones redefinidas mediante polimorfismo deberán tener la misma signatura que en su superclase. Se pueden añadir nuevos atributos, operaciones y asociaciones a la subclase. Un objeto de la subclase puede ser usado en cualquier situación donde es posible usar un objeto de su superclase. Esta técnica, donde un objeto de una subclase actúa como un objeto de la superclase, y una o más operaciones de la superclase son redefinidas en la subclase se llama polimorfismo. El polimorfismo indica que la implementación actual usada depende del tipo de objeto al cual la operación es aplicada. Una técnica común es combinar herencia, polimorfismo, y asociaciones o agregaciones recursivas como se muestra en la figura siguiente.

Figura 88: Combinación de herencia, agregación y clases abstractas

Interfaces Una de las grandes cualidades del desarrollo orientado a objetos es que puede variar las interfaces de las clases independientemente de la implementación. Mucho del poder del desarrollo orientado a objetos viene de esta propiedad; sin embargo, poca gente hace uso de él.

Página 154

Análisis y Diseño de Sistemas con el UML

Los lenguajes de programación usan una sola construcción, la clase, la cual contiene tanto interfaz como implementación. Cuando se especializa, se heredan ambas. Usar la interfaz como una construcción separada es raramente usado, lo cual es una pena. Una interfaz es una clase sin implementación, y por lo tanto, tiene declaraciones de operaciones pero no cuerpos de métodos ni atributos, lo cual hace que las operaciones y la clase sean abstractas. El punto es que la especialización proporcionará la implementación, pero los clientes nunca verán la implementación, solamente la interfaz. En la mayoría de los lenguajes orientados a objetos las interfaces son declaradas mediante clases abstractas (que explicaremos a continuación), pero en algunos (como Java) existe un tipo interface específico. Un paquete, componente, o clase que tiene una interfaz conectada a sí se dice que implementa o soporta la interfaz, lo que indica que soporta el comportamiento definido en la interfaz. Las interfaces juegan un papel muy importante cuando se diseñan sistemas bien estructurados pues son vistas como contratos entre clusters de elementos de modelos que colaboran. Los equivalentes de programación son las interfaces OLE/COM o Java, donde una interfaz puede ser especificada separadamente de cualquier clase específica y un número de clases (o paquetes o componentes) pueden escoger implementar esa interfaz. Una interfaz es descrita solamente con operaciones abstractas (que serán descritas también posteriormente). La interfaz es mostrada como un pequeño círculo con un nombre. La interfaz está conectada a su elemento de modelaje mediante una línea sólida. Una clase que usa una interfaz tal y como es implementada en una clase específica está conectada mediante una relación de dependencia (una flecha punteada) al círculo de la interfaz. La clase dependiente depende solamente de las operaciones en esa interfaz, no de nada más en la clase. La clase dependiente puede llamar las operaciones publicadas en la interfaz, que no se muestran directamente en el diagrama. Para mostrar las operaciones en una interfaz, la interfaz es especificada como una clase con el estereotipo <<interface>>.

Figura 89: La clase A implementa las interfaces Runnable y Storable. La clase C implementa la interfaz Runnable. La clase B usa la interfaz Runnable y Storable de A, y Runnable de C

Capítulo 12: Diseño del Sistema

Página 155

Clases abstractas Una clase abstracta es una que no tiene objetos; o, más precisamente, no se le permite tener objetos. Una clase abstracta es solamente usada para heredar de ella, en el sentido que describe comportamiento y estructura similar para otras clases. Una clase abstracta se muestra con el valor etiquetado {abstract} debajo del nombre de la clase o con el nombre de la clase en itálicas. Una clase abstracta normalmente tiene operaciones abstractas. Una operación abstracta es aquella que no tiene método de implementación en la clase donde fue especificada; solamente se muestra la signatura. Una clase que tiene por lo menos una operación abstracta debe ser una clase abstracta. Una clase que hereda de una clase que tiene una o más operaciones abstractas debe implementar esas operaciones (proveer métodos para ellas) o convertirse ella misma en otra clase abstracta. Las operaciones abstractas se muestran con el texto propiedad {abstract} siguiendo la signatura de la operación o con su signatura en itálicas. Las operaciones abstractas son definidas en las clases abstractas para especificar comportamiento que todas las subclases deben tener. Las clases abstractas y las interfaces son similares pero con diferencias. Ambas permiten definir comportamiento en común y heredar su implementación en subclases. Sin embargo, la clase abstracta puede tener atributos e implementación para algunas de sus operaciones, mientras en la interfaz no hay atributos y las operaciones son todas abstractas.

Restricciones y Derivaciones Atributos y asociaciones restringidos y derivados

Mucho de lo que se hace cuando se crea un diagrama de clase es indicar restricciones. Por ejemplo, cuando se crea una relación entre una clase Orden y una clase Cliente, se puede inferir que una orden puede ser colocada por un solo cliente. Las estructuras básicas de asociación, atributo, y generalización especifican restricciones importantes, pero no las pueden expresar todas. Estas reglas adicionales necesitan ser capturadas y son descritas como restricciones y derivaciones. Las restricciones restringen un modelo. Ejemplos de restricciones ya discutidas son asociaciones “o,” y asociaciones ordenadas. Las derivaciones son reglas sobre cómo ciertas cosas pueden ser derivadas, tales como la edad de una persona (fecha actual menos fecha de nacimiento). Las reglas pueden ser agregadas a cualquier elemento de modelaje, pero son especialmente útiles para atributos, asociaciones, herencia, roles, y restricciones de tiempo en los modelos dinámicos. Todas las reglas son mostradas dentro de llaves ({}) cerca del elemento de modelaje o entre llaves dentro de una nota conectada al elemento de modelaje. Idealmente, las reglas deben ser implementadas como aserciones en un lenguaje de programación. Estas corresponden a la noción del Diseño por Contrato (ver Anexo C) de invariantes. Es posible crear un método checkInvariant en las clases que tienen invariantes y llamarlos durante la depuración para ayudar a chequear invariantes. Las asociaciones pueden ser restringidas o derivadas. Si una compañía tiene contratos con muchos clientes, una asociación derivada podría ser que algunos clientes son más importantes (VIP). La asociación derivada va directamente de la clase compañía a la clase cliente. Una asociación derivada tiene una etiqueta colocada cerca de la asociación que comienza con una fleca (/) seguida del nombre de la derivación. Una asociación restringida puede ser establecida cuando una asociación es un subconjunto de otra.

Página 156

Análisis y Diseño de Sistemas con el UML

Figura 90: Asociación derivada

Figura 91: Asociación restringida

Los atributos también pueden ser restringidos o derivados. Una restricción típica para un atributo es un rango de valores. Un rango de valores es lo mismo que un texto propiedad para un atributo y especifica una serie de valores posibles para el mismo. Un texto propiedad es una cadena en cualquier formato. Un ejemplo de un texto propiedad para el atributo color es {rojo, verde, azul} o {0<=color<=255}. Un atributo derivado es calculado en alguna forma a partir de otros atributos. La fórmula para el cálculo es dada dentro de llaves bajo la clase. Una atributo derivado siempre inicia con una fleca (/) y no es almacenado en los objetos de la clase (siempre es calculado).

Figura 92: Atributos restringidos y derivados

Los roles pueden tener restricciones que restringen las combinaciones de roles jugados por un objeto (ej.: una persona no aprueba sus propias compras). También hay restricciones para tiempo. Cuando se expresan reglas en restricciones y derivaciones, se refieren a los elementos de un modelo. Esto es hecho mediante un pequeña sintaxis en el UML llamada expresión de navegación, la cual es un lenguaje básico para expresar reglas, y puede tener que ser extendido a veces. set ‘.’ atributo

El resultado es el valor o conjunto de valores del atributo dependiendo de la multiplicidad de la asociación. El conjunto debe ser una expresión para un objeto o un conjunto de objetos.

Capítulo 12: Diseño del Sistema

Página 157

set ‘.’ ole

El rol está en la parte destino de la asociación. El resultado es un objeto o un conjunto de objetos dependiendo de la multiplicidad de la asociación. El conjunto debe ser una expresión para un objeto o un conjunto de objetos. set ‘.’ ‘~’ rol

El role está en la parte origen de la asociación. El resultado es un objeto o conjunto de objetos dependiendo de la multiplicidad de la asociación. Esto es el inverso de la asociación. El conjunto debe ser una expresión para un objeto o conjunto de objetos. set ‘[‘ expresión_boleana ‘]’

La expresión boleana es escrita en términos de objetos dentro del conjunto. El resultado es el subconjunto de objetos para los cuales la expresión boleana es verdadera. El conjunto debe ser una expresión para un objeto o conjunto de objetos. set ‘.’ ‘[‘ valor_calificador ‘]’

El valor calificador designa una asociación calificada que califica el conjunto. Es también un valor para el atributo calificador dentro de la asociación calificada. El resultado es el objeto relacionado seleccionado por el calificador dentro de la asociación calificada. El conjunto debe ser una expresión para un objeto o conjunto de objetos. Algunos ejemplos son: Contrato.Portador > 0 Persona.~Portador.suma_asegurado > 1000$ Carro.Conductor.licencia = Verdadero Persona[Suplidor.Prospecto] < Persona[Suplidor.Sospechoso] Restricciones en la generalización

Una restricción en la generalización especifica información adicional sobre cómo la generalización podría ser usada y extendida en el futuro. Las siguientes restricciones están predefinidas para las generalizaciones con más de una subclase: overlapping (superpuesta), disjoint (disjunta), complete (completa), incomplete (incompleta). Estas son restricciones semánticas, y pueden ser mostradas entre llaves cerca del triángulo del discriminador. Si los caminos no comparten el discriminador, una línea punteada cruza todas las líneas de herencia, y las restricciones se insertan cerca de la línea punteada.

Figura 93: Diferentes formas de mostrar restricciones en la herencia

Página 158

Análisis y Diseño de Sistemas con el UML

Generalizaciones overlapping y disjoint

La herencia overlapping significa que cualquier subclase adicional que herede de la superclase en la relación de herencia puede heredar más de una de las superclases (puede usar herencia múltiple con una superclase común en el árbol de herencia). La herencia disjoint es lo opuesto, lo que significa que no se permite a las clases especializarse en una subclase común. La generalización es disjoint por defecto si nada se especifica.

Figura 94: Generalización overlapping

Generalizaciones complete e incomplete

Una restricción que especifique que una generalización es complete significa que todas las subclases han sido especificadas y que no se pueden hacer más subclases. Una generalización incomplete (por defecto) significa que se pueden añadir subclases posteriormente.

Figura 95: Generalización complete

Capítulo 12: Diseño del Sistema

Página 159

La emergencia de patrones Mucha gente ha comentado que los proyectos tienen problemas porque la gente involucrada no conoce diseños que son bien conocidos para aquellos con mayor experiencia. Los patrones de diseño proporcionan soluciones a problemas comunes de diseño de software. Por lo tanto, los patrones de diseño pueden jugar un papel en diseñar el cómo de un sistema. En palabras de Grady Booch, “los patrones son, bien, muy suaves.”6 Los patrones proporcionan la capacidad de reutilizar diseños y arquitecturas exitosas, lo que lleva a sistemas más mantenibles y productividad mejorada. Al igual que con las clases creadas hasta este momento, las clases creadas para instanciar el patrón de diseño son añadidas al modelo y los diagramas de clase. Hay varios libros publicados con descripciones de patrones de diseño. Uno de los más populares es Design Patterns: Elements of Reusable Object-Oriented Software por Gamma, et al., publicado por Addison-Wesley en 1995. Otros lugares donde puede encontrar información es el Patterns Home Page on the Web (http://st-www.cs.uiuc.edu/users/patterns/patterns.html). Otro sitio es la Portland Patterns Repository Page (http://c2.com/ppr/index.html).

Booch, Grady. Best of Booch. SIGS Reference Library, New York, NY, 1996. Página 167.

Capítulo 13: Arquitectura del Sistema La necesidad de arquitectura

El equipo de arquitectura

La vista de arquitectura “4 + 1”

Arquitectura lógica

Arquitectura física

Diagramas de componentes

Diagramas de despliegue

Construyendo las iteraciones

Capítulo 13: Arquitectura del Sistema

Página 163

La necesidad de arquitectura A través de los años han habido varias definiciones de arquitectura del sistema que van desde “la arquitectura del software es lo que hacen los arquitectos de software” hasta “la arquitectura del software es política.” En realidad, la arquitectura de software es muy difícil de definir. Es un conjunto de artificios que es usado para especificar las decisiones estratégicas acerca de la estructura y comportamiento del sistema, las colaboraciones entre los elementos del sistema, y el despliegue físico del sistema. “Establecer una fundación de arquitectura sólida es absolutamente esencial para el éxito de un proyecto orientado a objetos. Algunos grupos tratan de ignorar esta fase, ya sea porque están tan apurados para terminar un producto rápidamente que sienten que no tienen tiempo para diseñar la arquitectura, o porque no creen que la arquitectura les proporciona algún beneficio real. De cualquier forma, el apuro hacia la codificación es siempre desastroso: falle en llevar a cabo esta etapa apropiadamente, y su proyecto sufrirá seguramente de baja calidad en el software.”7 El desarrollo de la arquitectura es un proceso complicado. La arquitectura del sistema es desarrollada iterativamente en la fase de elaboración del desarrollo. “La arquitectura de un sistema propuesto no aparece de inmediato. Toma exploración de los casos de uso, un prototipo de prueba de concepto, una base de arquitectura, y otros esfuerzos durante las fases de Inicio y elaboración.”8 Los prototipos ejecutables de la arquitectura son construidos para verificar que las decisiones de diseño tomadas son correctas. “Construir algo ejecutable es absolutamente esencial, porque fuerza al equipo de desarrollo a validar lo que asumen en la dura luz de la realidad.”9 La arquitectura del sistema es un plano para todas las partes que juntas definen el sistema: su estructura, interfaces, y los mecanismos que usan para comunicarse. Al definir una arquitectura apropiada se hace más fácil navegar el sistema, encontrar el lugar de una función específica o concepto, o identificar un lugar al cual añadir una nueva función o concepto que se ajuste a la arquitectura global. La arquitectura debe ser lo suficientemente detallada de tal forma que pueda ser mapeada en código actual. Una arquitectura que es fácil de navegar y suficientemente detallada debe también ser escalable, lo que significa que puede ser vista en diferentes niveles Una arquitectura bien definida permite la inserción de nuevas funciones y conceptos sin imponer problemas en el resto del sistema (como en los sistemas monolíticos donde un pequeño cambio en una parte del sistema podría causar problemas en algo que parece completamente no relacionado debido a las complejas relaciones entre diferentes partes del sistema). La arquitectura debe servir como un mapa para los desarrolladores, revelando cómo el sistema es construido y dónde están localizadas funciones o conceptos específicos. A lo largo del desarrollo este mapa pueda tener que ser cambiado debido a descubrimientos importantes y experiencias a lo largo del camino. La arquitectura debe “vivir” en el sistema a medida que es desarrollado, y debe reflejar constantemente la construcción del sistema en todas las fases y generaciones. Naturalmente, la arquitectura base es definida en la primera versión del sistema, y la calidad de esta arquitectura inicial es vital para permitir a los desarrolladores cambiar, extender, y actualizar la funcionalidad del sistema.

Booch, Grady. Object Solutions. Redwoood City, CA: Addison Wesley, 1995. Jacobson, Ivar. The Objectory Software Development Process, Draft Edition. 9 Jacobson, Ivar. The Objectory Software Development Process, Draft Edition. 8

Página 164

Análisis y Diseño de Sistemas con el UML

La definición de arquitectura en el UML es: Arquitectura es la estructura organizacional de un sistema. Una arquitectura puede ser descompuesta recursivamente en partes que interactúan a través de interfaces, relaciones que conectan partes, y restricciones para ensamblar partes. Buschmann et al. (1996)10 ofrece otra definición de arquitectura de software: Una arquitectura de software es una descripción de los subsistemas y componentes de un sistema de software y las relaciones entre ellos. Los subsistemas y componentes son típicamente especificados en vistas diferentes para mostrar las propiedades funcionales y no funcionales relevantes de un sistema de software. La arquitectura de software de un sistema es un artificio. Es el resultado de una actividad de diseño de software.

El equipo de arquitectura Cada proyecto debería tener un arquitecto en jefe el cual puede ser asistido por un pequeño grupo de personas. “Las principales actividades del arquitecto incluyen la definición de la arquitectura del software, el mantenimiento de la integridad de la arquitectura del software, la evaluación de los riesgos técnicos del proyecto, la definición del orden y contenido de las iteraciones sucesivas junto con la planeación de cada iteración, proporcionando servicios de consultoría a varios grupos de diseño, implementación, integración, y control de calidad y asistiendo en proporcionar direcciones de mercadeo futuras.”11

Figura 96: La vista de arquitectura “4 + 1”

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, y Michael Stal: PatternOriented Software Architecture: A System of Patters. John Wiley & Sons, 1996 11 Kruchten, Philippe. Software Arquitecture and Iterative Development. Santa Clara, CA: Rational Software Corporation. P. 53. Abril 1994

Capítulo 13: Arquitectura del Sistema

Página 165

La vista de arquitectura “4 + 1” La arquitectura de software no tiene una sola dimensión – esta formada de múltiples vistas concurrentes. La figura de la página anterior muestra las diferentes vistas de la arquitectura de software12: la vista de casos de uso, la vista lógica, la vista de componentes, la vista de procesos y la vista de despliegue. Cada vista se concentra en un aspecto específico del sistema. La imagen completa del sistema puede ser hecha solamente definiendo todas las vistas. Una separación más amplia usualmente divide la arquitectura en lógica y física. La arquitectura lógica especifica principalmente las propiedades funcionales del sistema y es dirigida por los requerimientos funcionales del sistema; la arquitectura física trata principalmente con aspectos no funcionales como confiabilidad, compatibilidad, uso de recursos, y despliegue del sistema. Los desarrolladores con experiencia a veces tienen la capacidad mágica para definir buenas arquitecturas. Pero esta habilidad viene de haber diseñado una cantidad de sistemas, lo cual les da conocimiento de cuáles soluciones trabajan y cuáles no. Típicamente reutilizan soluciones que han trabajado bien en el pasado. Con todas estas definiciones en mente, ¿qué constituye una buena arquitectura?

Debe ser una descripción correcta de las partes que definen el sistema, tanto en términos de la arquitectura lógica como la física. Debe proporcionar un mapa del sistema con el cual el desarrollador pueda localizar fácilmente dónde una funcionalidad o concepto específico puede ser implementado. La funcionalidad o concepto puede ser orientado a la aplicación (un modelo de algo en el dominio de la aplicación) o orientado al diseño (alguna solución de implementación técnica). Esto también implica que los requerimientos del sistema deberían ser trazables al código que lo maneja. Debe facilitar hacer cambios y extensiones en un lugar específico en el sistema, sin que se afecte negativamente el resto del sistema. Debe ser simple, con interfaces bien definidas y dependencias claras entre partes diferentes, de tal forma que un arquitecto pueda desarrollar una parte específica sin tener un entendimiento completo de todos los detalles del sistema. Debe soportar la reutilización incorporando partes reutilizables en el diseño y permitiendo el diseño de partes genéricas que pueden ser usadas en otros sistemas.

Una arquitectura que cumpla con todas estas cualidades no es fácil de diseñar, y algunas veces se deben hacer compromisos. Lo importante en el desarrollo de sistemas exitosos es definir una buena arquitectura base. Si esto no es hecho a conciencia, la arquitectura será definida de abajo hacia arriba por el código, resultando en un sistema que es difícil de extender, mantener, y entender. La vista de casos de uso

La vista de casos de uso describe la funcionalidad que el sistema debería proporcionar, tal y como es percibida por los actores externos. Un actor interactua con el sistema; este puede ser un usuario u otro sistema. La vista de casos de uso es para los clientes, diseñadores, desarrolladores, y probadores; es 12

Kruchten, Philippe. Software Arquitecture and Iterative Development. Santa Clara, CA: Rational Software Corporation. P. 53. Abril 1994

Página 166

Análisis y Diseño de Sistemas con el UML

descrita en el diagrama de casos de uso y ocasionalmente en los diagramas de actividad. El uso deseado de un sistema es descrito en una serie de casos de uso en la vista de casos de uso, donde un caso de uso es una descripción genérica de un uso del sistema (una función requerida). Esta vista de arquitectura demuestra y valida las vistas lógica, de procesos, de componentes, y de despliegue. Los diagramas de secuencia y colaboración son creados para mostrar como los varios elementos de diseño interactúan para producir el comportamiento deseado. La vista de casos de uso es central, debido a que sus contenidos conducen y afectan el desarrollo de otras vistas. El objetivo final de un sistema es proporcionar la funcionalidad descrita en esta vista – acompañada de algunas propiedades no funcionales. Esta vista es utilizada también para validar y finalmente verificar el sistema probando la vista de casos de respecto al cliente (preguntando: “¿es esto lo que usted quiere?”) y respecto al sistema terminado (preguntando: “¿el sistema trabaja como se especificó?”). La vista lógica

La vista lógica describe cómo es proporcionada la funcionalidad del sistema – lo que el sistema debería proporcionar en términos de servicios a sus usuarios. Es principalmente para diseñadores y desarrolladores. La arquitectura lógica es capturada en diagramas de clase que contienen las clases y relaciones que representan las abstracciones clave del sistema bajo desarrollo, así como en los diagramas dinámicos (estados, secuencia, colaboración y actividades) que ocurren cuando los objetos envían mensajes unos a otros para proporcionar una función dada. La mayoría de la notación del UML trata sobre esta vista. Esta vista de arquitectura es realizada temprano en la etapa de elaboracion con la creación de clases y paquetes que representan las abstracciones principales del dominio. A medida que pasa el tiempo, más clases y paquetes son añadidos al modelo para reflejar las decisiones tomadas en relación con los mecanismos claves del sistema. Un mecanismo clave es una decisión en relación con estándares comunes, políticas, y prácticas. La selección de mecanismos claves para un sistema es a menudo llamada diseño táctico. “Un diseño táctico pobre puede arruinar aún la arquitectura más profunda, por lo tanto, el grupo debe mitigar este riesgo identificando explícitamente las políticas claves del proyecto."13 Algunos mecanismos claves comunes incluyen la selección de un lenguaje de implementación, almacenamiento persistente de datos, el “look and feel” de la interfaz del usuario, manejo de errores, mecanismos de comunicación, distribución y migración de objetos, y redes. Hoy, existen muchos patrones que pueden ser usados para implementar las decisiones de mecanismos claves tomadas para el sistema. Es recomendado fuertemente analizar patrones ya existentes antes de intentar comenzar desde cero. Adicionalmente, los conceptos de cohesión, cierre y reutilización afectarán las opciones que puede hacer. El UML puede ser usado para comunicar las decisiones estratégicas hechas para su sistema añadiendo paquetes y clases al modelo para comunicar, implementar, y documentar estas decisiones. La vista de componentes

Esta vista de arquitectura trata con la organización actual de los módulos de software dentro del ambiente de desarrollo, por lo que es principalmente para los desarrolladores. La vista de componentes 13

Booch, Grady. Object Solutions. Redwoood City, CA: Addison Wesley, 1995.

Capítulo 13: Arquitectura del Sistema

Página 167

de la arquitectura toma en cuenta requerimientos derivados relacionados a facilidad de desarrollo, administración de software, reutilización, y restricciones impuestas por lenguajes de programación y herramientas de desarrollo, Los elementos de modelaje en la vista de componentes son paquetes y componentes junto con sus conexiones. Un paquete en esta vista de arquitectura representa una partición física del sistema. Los paquetes de la vista de componentes son a menudo llamados subsistemas. Los paquetes son organizados en una jerarquía de capas donde cada capa tiene una interfaz bien definida. El hecho de que un sistema orientado a objetos tienda a estar formado en capas no debe ser una sorpresa. Esto es debido a la definición de un objeto – ¡debe hacer una cosa y hacerla bien!. Un diagrama que muestra algunas capas típicas de un sistema se muestra a continuación.

Figura 97: Capas de un sistema

La notación del UML para un paquete en la vista de componentes es la misma que para la vista lógica – una carpeta. La información en la vista lógica del modelo está conectada a la información en la vista de componentes mapeando paquetes de la vista lógica a paquetes de la vista de componentes. En general, un paquete de la vista lógica corresponde directamente a un paquete en la vista de componentes. Sin embargo, hay circunstancias donde una relación uno a uno no es posible. Algunas razones para esto son: un paquete lógico puede ser dividido para propósitos de implementación (posiblemente desarrollado por diferentes contratados); los paquetes lógicos pueden ser fusionados para mantener cerca objetos que se comunican frecuentemente; y finalmente, los paquetes de la vista de componentes pueden ser añadidos para implementar funcionalidad de bajo nivel no presentada durante el análisis (ej. Comunicación para sistemas distribuidos). En la vista de componentes del modelo, un componente representa un archivo de software que está contenido por un paquete (subsistema). El tipo de archivo es dependiente del lenguaje (ej. En C++ los componentes de software representan archivos .h y .cpp, en Java representan archivos .java, y en PowerBuilder representan archivos .pbl). Las clases en la vista lógica son mapeadas a componentes en la vista de componentes. En C++, el mapeo es típicamente uno a uno; es decir, una clase se mapea a un componente. Sin embargo, hay ocasiones cuando más de una clase será mapeada a un componente. Esto es generalmente hecho cuando hay una relación muy estrecha entre las clases. Por ejemplo, un contenedor y su iterador son contenidos en un archivo .h y un archivo .cpp. En este caso, el contenedor y el iterador serían mapeados a un componente. También puede darse el caso de clases que representan un patrón de colaboración mapeadas a un archivo físico. Los diagramas de componentes se estudiarán en detalle más adelante.

Página 168

Análisis y Diseño de Sistemas con el UML

La vista de procesos

Esta vista de arquitectura se enfoca en la implementación en tiempo de ejecución de la estructura del sistema, es decir, la división del sistema en procesos y procesadores. La vista de procesos de la arquitectura toma en cuenta requerimientos como rendimiento, confiabilidad, escalabilidad, integridad, administración de sistema, y sincronización. Los componentes son también usados en esta vista de arquitectura. Los diagramas de componente son creados para ver los componentes en tiempo de ejecución y ejecutables creados para el sistema. Los componentes son relacionados mediante relaciones de dependencia. Los componentes de tiempo de ejecución muestran el mapeo de clases a librerías en tiempo de ejecución como applets Java, componentes ActiveX, y librerías dinámicas. Los componentes ejecutables muestran las interfaces y dependencias de llamadas entre ejecutables. La vista de procesos es para desarrolladores e integradores del sistema, y consiste en diagramas dinámicos (diagramas de estado, secuencia, colaboración y de actividad) y los diagramas de implementación (diagramas de componentes y de despliegue que serán estudiados más adelante). La vista de despliegue

La vista de despliegue muestra el despliegue físico del sistema, tal como computadoras y dispositivos (nodos) y cómo se conectan unos a otros. La vista de despliegue es para desarrolladores, integradores y probadores, y es representada por el diagrama de despliegue. Esta vista de arquitectura trata con el mapeo de software a nodos de procesamiento – muestra la configuración de los elementos de procesamiento en tiempo de ejecución y los procesos de software que corren en ellos. La vista de despliegue toma en cuenta los requerimientos como disponibilidad del sistema, confiabilidad, rendimiento y escalabilidad. El diagrama de despliegue visualiza la distribución de componentes a lo largo de la empresa. Los elementos de procesamiento en tiempo de ejecución son representados como nodos. Los nodos son conectados por asociaciones que indican vías de comunicación entre ellos. Los procesos de software son ilustrados como texto añadido a un nodo o grupo de nodos.

Capítulo 13: Arquitectura del Sistema

Página 169

Arquitectura lógica

Figura 98: Arquitectura de tres capas en el UML mostrada como paquetes y dependencias entre ellos

La figura anterior muestra una arquitectura lógica. La arquitectura lógica trata con la funcionalidad del sistema, asignando funcionalidad a diferentes partes del sistema y especificando en detalle como la solución trabaja. La arquitectura lógica contiene la lógica de aplicación, pero no la distribución física de la lógica en procesos diferentes, programas o computadoras. La arquitectura lógica da un entendimiento más claro de la construcción del sistema para facilitar la administración y coordinación del trabajo (para usar los recursos humanos más eficientemente). No todas las partes de la arquitectura lógica tienen que ser desarrolladas dentro del proyecto; se pueden comprar librerías de clase, componentes binarios, y patrones. La arquitectura lógica responde preguntas como:

¿Qué funcionalidad el sistema trata de entregar? ¿Cuáles clases existen, y cómo esas clases están relacionadas entre sí? ¿Cómo las clases y los objetos colaboran para realizar la funcionalidad?

Página 170

Análisis y Diseño de Sistemas con el UML

¿Cuáles son las restricciones de tiempo para las funciones del sistema? ¿Cuál sería un plan aceptable de seguir para que los desarrolladores desarrollen esta arquitectura.

En el UML, los diagramas usados para describir la arquitectura lógica son casos de uso, clases, estados, actividades, colaboración, y secuencia. Una arquitectura común es una estructura en tres capas, donde el sistema está dividido en una capa de interfaz, una capa de objetos del negocio, y una capa de base de datos.

Arquitectura física La arquitectura física trata con una descripción detallada de un sistema, en términos del hardware y software que el sistema contiene. Revela la estructura del hardware, incluyendo nodos diferentes y como esos nodos están conectados entre sí. También ilustra la estructura física y las dependencias de los módulos de código que implementan los conceptos definidos en la arquitectura lógica; y la distribución de software de tiempo de ejecución en término de procesos, programas, y otros componentes. La arquitectura física intenta alcanzar un uso eficiente de los recursos de hardware y software. La arquitectura física responde preguntas como:

¿En qué programas o procesos están las clases y objetos físicamente localizados? ¿En que computadoras los programas y procesos se ejecutan? ¿Cuáles computadoras y otros dispositivos de hardware están en el sistema, y cómo están conectados entre sí? ¿Cuáles son las dependencias entre los diferentes archivos de código? ¿Si un archivo específico es cambiado, que otros archivos tienen que ser recompilados?

La arquitectura física describe la descomposición del software y hardware. Un mapeo es dibujado entre la arquitectura lógica y la arquitectura física, donde las clases y mecanismos en la arquitectura lógica son mapeados en componentes, procesos, y computadoras en la arquitectura física. Este mapeo permite al desarrollador seguir una clase en la arquitectura lógica a su implementación física; o viceversa, para trazar la descripción de un programa o un componente hacia su diseño en la arquitectura lógica. Como se describió previamente, la arquitectura física trata con la implementación, y por lo tanto, es modelada en los diagramas de implementación. Los diagramas de implementación en el UML son el diagrama de componentes y el diagrama de despliegue. El diagrama de componente contiene los componentes de software: las unidades de código y la estructura de los archivos reales (de código fuente y binarios). El diagrama de despliegue muestra la arquitectura en tiempo de ejecución del sistema y cubre los dispositivos físicos y el software asignado a ellos. Estos diagramas serán descritos en detalle posteriormente. Hardware

Los conceptos de hardware en la arquitectura física pueden ser divididos en:

Procesadores: Estas son las computadoras que ejecutan los programas en el sistema. Un procesador puede ser de cualquier tamaño, desde un microprocesador en un sistema empotrado hasta una supercomputadora.

Capítulo 13: Arquitectura del Sistema

Página 171

Dispositivos: Estos son los dispositivos de soporte como impresoras, enrutadores, lectores de tarjetas, etc., en el sistema. Están típicamente conectados a un procesador que los controla. Puede haber una línea fina entre lo que es un procesador y lo que es un dispositivo (pues la mayoría tienen un CPU), pero generalmente un procesador corre parte del software creado específicamente para el sistema. Conexiones: Los procesadores tienen conexiones a otros procesadores. También tienen conexiones a dispositivos. Las conexiones representan un mecanismo de comunicación entre dos nodos, y pueden ser descritas como el medio físico (por ejemplo, fibra óptica) y el protocolo de software (por ejemplo, TCP/IP).

Software

Tradicionalmente, el software en una arquitectura de sistema era definido superficialmente como consistente de partes. Otras palabras para parte podrían ser paquetes, módulos, componentes, espacios o subsistemas. Un nombre común para la unidad modular manejada en la arquitectura es subsistema, un sistema miniatura dentro de un sistema más grande. Tiene una interfaz y está internamente descompuesto en subsistemas más detallados o en clases y objetos. Los subsistemas pueden ser asignados a procesadores en los cuales se ejecutan (y los procesos pueden ser asignados a computadoras en las que se ejecutan). En el UML, un subsistema es modelado como un paquete de clases. Un paquete organiza un número de clases en un grupo lógico, pero no define semánticas para el grupo. En el diseño, es común definir uno o más componentes como una fachada para un subsistema. El componente fachada proporciona la interfaz del subsistema (paquete) y es el único componente visible para el resto del sistema. Usando una fachada el paquete se convierte en una unidad muy modular, en la cual el diseño interno puede ser escondido y solamente el componente fachada necesita ser mostrado en los diagramas. Los paquetes son usados en el diseño lógico, donde las clases son agrupadas en una unidad, y en la arquitectura física, donde un paquete encapsula un número de componentes (típicamente implementando las clases en el diseño lógico). Una construcción de fachada tiene una representación en el UML, pero es aplicada a un paquete. Un paquete contiene un paquete fachada que hace referencia a otros elementos, pero no posee elementos el mismo. El paquete fachada representa el paquete en el cual está incluido, y es anotado como una fachada añadiendo el estereotipo <<Fachada>> a ese paquete. Los principales conceptos en la descripción del software son componentes, procesos, hilos, y objetos:

Componentes: un componente en el UML es definido como “una parte reutilizable que proporciona el empaquetamiento físico de una colección de instancias de elementos de modelaje.” Esto significa que un componente es una implementación física (por ejemplo, una archivo de código fuente) que implementa los elemenos lógicos del modelo como se definen en los diagramas de clase y diagramas de interacción. Un componente puede en diferentes etapas del desarrollo, como tiempo de compilación, tiempo de enlazado, y tiempo de ejecución. En un proyecto, la definición de un componente es a menudo mapeada al ambiente de implementación. Procesos e hilos: un proceso representa un flujo de control pesado, mientras un hilo representa un flujo de control liviano. Ambos son descritos como clases activas con estereotipos, y los objetos activos son asignados a los componentes ejecutables en los que corren. Objetos: los objetos (pasivos) son aquellos sin un hilo de ejecución propio. Corren solamente cuando alguien les manda un mensaje (llamado a una de sus operaciones). Pueden ser asignados a procesos o hilos (a un objeto activo) o directamente a un componente ejecutable.

Página 172

Análisis y Diseño de Sistemas con el UML

Diagramas de componentes El diagrama de componentes describe los componentes de software y sus dependencias entre sí, representando la estructura del código. Los componentes son la implementación en la arquitectura física de los conceptos y la funcionalidad descrita en la arquitectura lógica (clases, objetos, sus relaciones, y colaboraciones). Los componentes son típicamente los archivos de implementación en el ambiente de desarrollo. Un componente es mostrado en el UML como un rectángulo con dos rectángulos menores a la izquierda. El nombre del componente es escrito bajo el símbolo o dentro del rectángulo grande.

Figura 99: Notación del UML para un componente

Un componente de software puede ser cualquiera de lo siguiente:

Componente fuente: un componente fuente tiene significado en tiempo de compilación. Es típicamente un archivo de código fuente que implementa una o más clases. Componente binario: un componente binario es típicamente código de objeto que es el resultado de compilar un componente fuente. Podría ser un archivo de código de objeto, una archivo de librería estática, o un archivo de librería dinámica. Un componente binario tiene significado en el momento de enlazado, o en el caso de una librería dinámica, en tiempo de ejecución (una librería dinámica es cargada por el componente ejecutable en tiempo ejecución). Componente ejecutable: un componente ejecutable es un archivo de programa ejecutable que es el resultado de enlazar todos los componentes binarios (ya sea estáticos en tiempo de enlace o dinámicos en tiempo de ejecución). Un componente ejecutable representa la unidad ejecutable que es corrida por el procesador (computadora).

Figura 100: Diagrama de componente que muestra un número de componentes – fuente, binario y ejecutable – y sus dependencias

Los componentes son tipos, pero solo un componente ejecutable puede tener instancias (las cuales son los programas que representan cuando corren en el procesador). Un diagrama de componente muestra solamente los componentes como tipos. Para mostrar instancias de los componentes se debe usar un

Capítulo 13: Arquitectura del Sistema

Página 173

diagrama de despliegue, donde las instancias de los componentes son asignados a instancias de nodos en las cuales se ejecutan. Una conexión de dependencia entre componentes significa que un componente necesita otro para tener una definición completa. Una dependencia de un componente de código fuente A otro componente B significa que hay una dependencia específica del lenguaje de A a B. En un lenguaje compilado, esto indicaría que un cambio en B requiere una recompilación de A. Si los componentes son ejecutables, las conexiones de dependencia pueden ser usadas para identificar que librerías dinámicas un programa ejecutable necesita para correr. Un componente puede definir interfaces que son visibles a otros componentes. Las interfaces pueden ser interfaces a nivel código fuente (como en Java) o interfaces binarias usadas en el momento de la ejecución (como en OLE). Una interfaz es mostrada con una línea desde el componente con un círculo en el extremo. Las dependencias entre componentes pueden apuntar a la interfaz del componente usado.

Figura 101: Interfaces y dependencias

Componentes fuentes

Los componentes fuentes contienen el código producido en los proyectos. Otros componentes como los componentes de tiempo de enlace o de tiempo de ejecución pueden ser generados de los componentes fuentes. Algunos estereotipos que pueden ser usados para los componentes fuentes son:

<<file>>: una representación de un archivo que contiene código fuente. <<page>>: una representación de una página Web. <<document>>: una representación de un archivo con documentación.

Una dependencia de un componente de compilación a otro revela cuáles otros componentes son necesarios para completar su definición; por ejemplo, qué otros componentes de tiempo de compilación no incluye en su definición.

Página 174

Análisis y Diseño de Sistemas con el UML

Figura 102: Dependencias entre componentes de código fuente

Componentes de tiempo de enlace

Un componente de tiempo de enlace es usado cuando se enlaza el sistema. Es típicamente el código objeto que resulta de compilar un componente de tiempo de compilación o una librería que es el resultado de compilar uno o más componentes de tiempo de compilación. Un caso especial es la librería de enlace dinámico (DLL), la cual es enlazada en tiempo de ejecución en vez de en tiempo de enlace. El estereotipo <<library>> puede ser usado para mostrar que un componente es una librería estática o dinámica. Componentes de tiempo de ejecución

Un componente de tiempo de ejecución representa un componente usado cuando se ejecuta el sistema. Es generado de los componentes de tiempo de enlace (de código objeto y librerías) o en algunos casos directamente de los componentes de código fuente. El estereotipo <<application>> representa un programa ejecutable, y el estereotipo <<table>> representa una tabla de base de datos que también puede ser vista como un componente usado en tiempo de ejecución.

Figura 103: Componentes de tiempo de ejecución

Solamente los componentes en tiempo de ejecución tienen instancias y son localizados en nodos (las unidades en los diagramas de despliegue). Una instancia de un componente de tiempo de ejecución indica que a partir del tipo del componente se instanciaron varios procesos para correr la aplicación representada en el archivo de componente. Las dependencias de un componente de tiempo de

Capítulo 13: Arquitectura del Sistema

Página 175

ejecución son otros componentes necesarios para su ejecución: librerías de enlace dinámico, archivos de imágenes o tablas de base de datos.

Diagramas de despliegue El diagrama de despliegue presenta la arquitectura de tiempo de ejecución de los procesadores, dispositivos, y los componentes de software que se ejecutan en esa arquitectura. Es la descripción física última de la topología del sistema, y describe la estructura de las unidades de hardware y el software que se ejecuta en cada unidad. En una arquitectura así, debe ser posible mirar un nodo específico de la topología, ver qué componentes se ejecutan en el nodo, ver qué elementos lógicos están implementados en el componente, y finalmente trazar esos elementos al análisis de requerimientos inicial del sistema. Nodos

Los nodos son dispositivos físicos que tienen algún tipo de recurso computacional, entre ellos computadoras, impresoras, lectores de tarjetas, dispositivos de comunicación, etc. Los nodos son identificados mirando a o decidiendo los recursos de hardware necesarios para implementar el sistema, tanto en términos de capacidad (memoria, velocidad, almacenamiento secundario) como de localización (geográfica). Un nodo puede ser mostrado como un tipo y una instancia (un nodo es una clase), donde un tipo describe las características de un procesador o tipo de dispositivo y una instancia representa ocurrencias actuales (máquinas) de ese tipo. La definición detallada de la capacidad del sistema puede ser definida ya sea como atributos o propiedades de los nodos. Un nodo es dibujado como un cubo tridimensional con el nombre dentro de él; y si el símbolo representa una instancia el nombre debe subrayarse.

Figura 104: Tipo nodo e instancia del mismo

Los dispositivos en el sistema son representados como nodos, típicamente con un estereotipo que especifica el tipo de dispositivo, o por lo menos con un nombre que lo defina claramente como un nodo de dispositivo y no un nodo de procesador.

Figura 105: Nodos de dispositivos y posibles estereotipos

Página 176

Análisis y Diseño de Sistemas con el UML

Conexiones

Los nodos están conectados entre sí por asociaciones de comunicación. Son dibujadas como asociaciones normales con una línea recta, indicando que hay algún tipo de camino de comunicación entre ellas, y que los nodos intercambian objetos o envían mensajes mediante el camino de comunicación. El tipo de comunicación es representado por un estereotipo que identifica el protocolo de comunicación o la red usada.

Figura 106: Asociaciones de comunicación entre nodos

Componentes

Las instancias ejecutables de los componentes pueden ser contenidas dentro los símbolos de instancia de los nodos, mostrando que residen y se ejecutan en una instancia de nodo. Del tipo nodo, una flecha de dependencia con el estereotipo <<supports>> puede ser dibujada a un tipo componente de tiempo de ejecución, indicando que el nodo soporta un componente específico. Cuando un tipo nodo soporta un tipo componente, es posible ejecutar una instancia de ese componente en la instancia del tipo nodo. Por ejemplo, no es posible crear un programa Windows en un AS/400, por lo que el tipo nodo AS/400 no soporta el tipo componente. Los componentes están conectados a otros componentes mediante flechas de dependencia. Recuerde que en un diagrama de despliegue solamente los componentes de tiempo de ejecución son mostrados. Esto significa que un componente usa los servicios de otro componente.

Figura 107: Un tipo nodo soporta un tipo componente de tiempo de ejecución, y un componente de tiempo de ejecución se ejecuta en una instancia de nodo

Capítulo 13: Arquitectura del Sistema

Página 177

Objetos

Un objeto es colocado dentro de una instancia de nodo para indicar donde reside en esa instancia. El objeto puede ya sea ser activo (con los estereotipos <<Process>> (proceso) o <<Thread>> (hilo), y dibujado con una línea gruesa), que se ejecuta en el nodo, o pasivo. El objeto es contenido dentro de otro objeto o dentro del componente. Esto es mostrado anidando los símbolos; o, si se complica mucho, una propiedad de lugar puede mostrar donde un objeto está localizado. Por ejemplo, un objeto pasivo puede ser contenido dentro de un proceso (un objeto activo), y el proceso vive dentro de un componente asignado a un nodo.

Figura 108: Un objeto pasivo (de la clase Controlador de Termómetro dentro de un proceso activo (de la clase activa Supervisor) que vive dentro de una instancia de componente (de tipo guard.exe, que está asignada al sistema de horno de microondas (de tipo controlador de horno de microondas)

Un objeto puede ser dibujado directamente dentro de un nodo sin enseñar el componente en el que es implementado. La información acerca del componente al que pertenece es identificada ya sea a través de la propiedad de lugar o es indefinida. En un sistema distribuido, un objeto puede moverse entre nodos diferentes durante la vida de un sistema. Esto es técnicamente hecho mediante sistemas de objetos distribuidos como CORBA u OLE, donde los objetos pueden ser transmitidos a través de la red y pueden cambiar su localidad en el sistema. Un objeto que cambia su localidad durante la vida del sistema puede ser incluido en todos los nodos en los que puede existir posiblemente. Para mostrar como un objeto puede ser distribuido en el sistema, una dependencia con el estereotipo <<becomes>> (transformarse) es dibujada entre las diferentes ocurrencias del objeto. La dependencia puede contener propiedades que definen el tiempo o condición que dispara el cambio en la localidad del objeto.

Página 178

Análisis y Diseño de Sistemas con el UML

Figura 109: Los objetos son asignados a nodos. El objeto transobj que originalmente existe en el Servidor Principal puede ser distribuido al nodo Dell PC

Modelaje complejo de nodos

Figura 110: Relaciones entre nodos

Los nodos son definidos como clases en el UML; por lo tanto, pueden existir relaciones más complejas entre ellos. Esto es usado cuando se describe una familia de nodos, donde la generalización se usa para definir una configuración general de nodos y la especialización para capturar casos especiales. Un nodo también puede tener un role en una asociación y tener una interfaz definida.

Capítulo 13: Arquitectura del Sistema

Página 179

Asignando componentes a los nodos

Las clases y colaboraciones como se definen en el diseño lógico son asignados a los componentes en los que son implementados. La asignación es dirigida por el lenguaje de programación usado. Por ejemplo, C++ implementa una clase con dos archivos: una archivo de encabezado (.h) que contiene la especificación y un archivo de implementación (.cpp) que contiene la implementación de las operaciones. Java implementa las clases en un solo archivo. Algunos lenguajes, como Java, tienen un concepto modular a mayor escala que una clase, lo que puede ser usado para agrupar clases. Esto puede ser mapeado para implementar el mecanismo de paquetes en el UML (también se llama un paquete en Java). El lenguaje de programación define las reglas para asignar clases a componentes. Los procesos son asignados a los componentes en los que se ejecutan. La asignación es dirigida por la necesidad de objetos activos o por la necesidad de distribuir geográficamente el sistema. Finalmente, los componentes son asignados a los nodos. Una instancia de componente se ejecuta en por lo menos una instancia de nodo y posiblemente en varias. La asignación de componentes a nodos puede afectar también la topología actual, de tal forma que se tengan que hacer cambios a la configuración en término de nodos. Hay un número de aspectos a considerar cuando se asignan componentes a nodos:

Uso de recursos: una de las metas principales cuando se determina la arquitectura física y la asignación de componentes es el uso de recursos de hardware. El hardware debe ser usado de la forma más eficiente posible, a la capacidad completa de cada nodo. Localización geográfica: Se tienen que hacer decisiones con relación a dónde se requiere una funcionalidad específica (en qué nodos) y qué funcionalidad debe estar disponible localmente (debido al rendimiento), o debe estar disponible aun si otros nodos no están operando. Acceso a dispositivos: ¿Cuáles son las necesidades para un dispositivo específico en un nodo? ¿Puede la impresora estar conectada al servidor, o necesita cada cliente una impresora local? Seguridad: ¿Cuál arquitectura maneja los derechos de acceso y protección de información en una forma optimizada y eficiente?. El control de acceso puede tratar con localización geográfica (tener el servidor en un lugar seguro) así como las soluciones de comunicación (usando hardware y software seguro para comunicarse). Rendimiento: La necesidad de alto rendimiento a veces afectará la localidad de un componente. Es posible mejorar el rendimiento creando proxies en un nodo local, sustituyendo el componente real disponible en otro nodo. Extensibilidad y portabilidad: Cuando diferentes nodos tienen diferentes sistemas operativos o arquitectura de hardware, se debe considerar que componentes pueden ser dependientes de un sistema operativo específico y cuáles deben ser portables a un número de sistemas operativos. Esto afecta la localidad de esos componentes y posiblemente también el lenguaje de programación para la implementación.

Se requiere un diseño iterativo para producir un diagrama de despliegue. Varias soluciones deben ser probadas, primero discutiendo durante el modelaje y más tarde implementando prototipos. Idealmente el sistema será flexible de tal forma que un componente específico pueda ser movido entre diferentes nodos. Un sistema distribuido de objetos como CORBA o OLE permitirá la creación de estos sistemas.

Página 180

Análisis y Diseño de Sistemas con el UML

Construyendo las iteraciones El proceso de planeación de las iteraciones

El plan de liberación de las iteraciones prescribe calendarios para todos los incrementos del sistema. “Este plan debe identificar una serie controlada de liberaciones, cada una creciendo en funcionalidad y finalmente cubriendo los requerimientos del sistema de producción completo.”14 “El plan de iteración debe presentar las metas específicas de la iteración:

Capacidades a desarrollarse. Riesgos mitigados durante la iteración. Defectos a componerse en la iteración.

Criterios de salida:

Información de capacidad actualizada. Plan de mitigación de riesgos actualizado. Un documento de descripción de la liberación que capture los resultados de la iteración. Casos de prueba y resultados de las pruebas conducidas en los productos incluyendo una lista de defectos. Un plan de iteración, detallando la próxima iteración incluyendo criterios medibles de evaluación para valorar los resultados de la próxima iteración.”15

Los escenarios desarrollados durante el análisis son la entrada principal para esta fase de desarrollo. Los escenarios son examinados y priorizados de acuerdo al riesgo, importancia al cliente, y la necesidad de desarrollar ciertos escenarios básicos primero. Esta tarea es mejor realizada con un grupo hecho de expertos del dominio, analistas, el arquitecto, y personal de pruebas. “Los escenarios deben ser agrupados de tal forma que para cada liberación, colectivamente proporcionen un pedazo significativo del comportamiento del sistema y adicionalmente requieran que el grupo de desarrollo ataque los riegos más relevantes del proyecto.”16 A medida que cada iteración es completada, los riesgos son reevaluados y el plan del proyecto es actualizado como sea necesario. “Para la mayoría de los proyectos, planee cerca de cinco (más o menos dos) liberaciones intermedias.”17 Codificando, probando, y documentado la iteración

Uno de los pasos finales en construir una iteración es la implementación de los cuerpos de los métodos en el lenguaje escogido antes de que la iteración esté completa. Los diagramas de interacción son usados para ayudar en este proceso porque dicen quién hace qué a quién y cuándo lo hace. Las pruebas son muy importantes en un ciclo de vida iterativo e incremental. A medida que el análisis y diseño progresan a través del ciclo de vida, los planes de pruebas y procedimientos son creados. De nuevo, los casos de uso son una parte importante de esta actividad porque documentan lo que el sistema debería hacer. La iteración debe ser probada para asegurarse que verdaderamente hace lo que 14

Booch, Grady. Object Solutions. Redwood City, CA: Addison-Wesley, 1995. Kruchten, Philippe. A Rational Development Process. Santa Clara, CA: Rational Software Corporation. 16 Booch, Grady. Object Solutions. Redwood City, CA: Addison-Wesley, 1995. 17 Booch, Grady. Object Solutions. Redwood City, CA: Addison-Wesley, 1995. 15

Capítulo 13: Arquitectura del Sistema

Página 181

se dice en el caso de uso. Las iteraciones son también integradas con iteraciones previas – no espera hasta que el sistema esté completo para poner juntas las iteraciones. La iteración es evaluada para asegurarse que elimine los riesgos asignados. Cualquier riesgo que no sea eliminado (junto con los riesgos encontrados en el camino) es asignado a una iteración futura. Las decisiones hechas en relación con el diseño de la iteración son capturadas en modelos para la iteración. Esta información es usada para generar la documentación para la iteración. La documentación debe ser generada sobre una base iterativa.

Capítulo 14: Caso de Estudio Requerimientos del Sistema

Análisis de Requerimientos

Análisis

Diseño

Implementación

Pruebas y Despliegue

Capítulo 14: Caso de Estudio

Página 185

n esta sección presentamos un caso de estudio para demostrar como el UML puede ser usado en el análisis y diseño de un sistema de información. Como se ha mencionado anteriormente, un sistema o aplicación es analizado y descrito en un modelo de análisis con casos de uso y análisis del dominio. Después es expandido en un modelo de diseño que incluye una solución técnica; finalmente, es programado en un ambiente de desarrollo, en nuestro caso Oracle Developer/2000. Este caso de estudio es un Sistema de Control de Rutas para cualquier empresa que cuente con rutas de distribución de productos y desea llevar un control detallado de los gastos de operación de las rutas, vehículos y empleados. Los propósitos de la presentación de este caso de estudio son los siguientes:

Mostrar el uso del UML en un sistema completo, trazando los modelos desde el análisis hasta el diseño. Ilustrar el uso de herramientas de modelaje con el UML utilizando Rational Rose. Demostrar que la metodología de nuestro trabajo es efectiva y produce resultados tangibles.

Este capítulo discutimos solamente algunos de los diagramas del caso de estudio por su gran extensión, pero el modelo entero está en el CD-ROM y puede ser estudiado e impreso desde Rational Rose (incluido en el CD-ROM). Las instrucciones para instalar y correr el software son proporcionadas en el archivo Leame.htm en el directorio raíz del CD-ROM.

Requerimientos del Sistema Una especificación escrita para la primera versión del Sistema de Control de Rutas, compilada de entrevistas con varios encargados de dicha área en varias empresas podría ser la siguiente: Consideremos el caso de cualquier empresa comercializadora que esté interesada en contar con un Sistema de Control de Rutas que le permita controlar los diferentes gastos en las rutas de distribución de sus productos, así como los costos asociados a dicha actividad, los cuales serán descritos más adelante. Supongamos que cada ruta cubre un área geográfica específica y es el área que es cubierta por un vehículo repartidor específico que hace las entregas correspondientes a los vendedores finales (distribuidores o clientes). Es importante tomar en cuenta que las rutas incluyen varios elementos de costo, entre los cuales podemos mencionar los costos relacionados con: vehículos, empleados y gastos indirectos. Esto es importante si consideramos que si existe un buen control sobre la flota vehicular se podrán tomar decisiones más acertadas para lograr de ella el máximo rendimiento y una mayor generación de utilidades para la empresa que desea aumentar su competitividad. Es de vital importancia considerar los siguientes aspectos:

Vehículos Entre los datos que podrá manejar el sistema para los vehículos tenemos: descripción, fecha de compra, costo de compra, factura de compra y cheque con que se pagó, datos de circulación, vendedor, impuestos. Los vehículos son los equipos utilizados para transportar al vendedor (chofer), su ayudante y el producto a vender. La flota vehicular de una empresa va a estar en concordancia con el tamaño de la empresa, así como con otros aspectos, tales como demanda del mercado, tipo de producto a distribuir y la estrategia planteada por la organización para llevar a cabo sus operaciones de distribución.

Página 186

Análisis y Diseño de Sistemas con el UML

Mantenimientos Toda empresa que posee una flota vehicular debe tomar en cuenta que debe llevarse una administración efectiva de los mantenimientos de los vehículos, para lo cual se calendarizan mantenimientos preventivos y se realizan mantenimientos correctivos que deben ser puestos en marcha con el objetivo primordial de no sufrir retrasos en las operaciones de distribución por problemas en las unidades vehiculares. El sistema deberá almacenar la información sobre los mantenimientos así como sus elementos de costos. El calendario preventivo puede manejarse por planes. Un plan puede definirse como un conjunto de trabajos a realizarle a un vehículo en una unidad de tiempo para asegurar su buen funcionamiento. Ejemplo de un plan podría ser: Plan A: Aplicado cada tres meses Cambio de aceite Engrase Chequeo liquido de frenos Plan B: Aplicado cada seis meses Cambio de aceite Engrase Chequeo de liquido de frenos Cambio de banda El sistema deberá registrar todos los gastos asociados a los mantenimientos correctivos de los vehículos en mal estado. Esto incluye tanto el pago de servicios de taller externos o interno, según sea la disponibilidad del mismo dentro de la organización, así como el pago de los repuestos que sean requeridos para realizar dichos mantenimientos.

Sustento Vehicular Se refiere a todos los gastos asociados con la compra de llantas, lavado, revisión de gas, aire, filtros, impuestos, pintura, etc. Los gastos accesorios se refieren a aquellos que no son de mantenimiento del vehículo. Por ejemplo, pago de parqueo, derecho de entrada a mercados, pago de vigilancia, etc. Estos conceptos deben ser abiertos.

Rutas El sistema deberá almacenar todos los datos concernientes al supervisor, distancias, estado de la carretera, situación geográfica y política. También deberá almacenar todos los gastos directamente atribuibles a las rutas. Hay que tomar en cuenta que una ruta puede tener diferentes recorridos dependiendo del día de la semana.

Empleados El sistema registrará los datos de los empleados que trabajan en las rutas, así como todos los gastos asociados entre los cuales debemos mencionar también los gastos de nómina y gastos de operación en ruta. Los gastos de operación se refieren a gastos propios del trabajo en ruta. Por

Capítulo 14: Caso de Estudio

Página 187

ejemplo, viáticos, hospedaje, llamadas telefónicas, etc. Los conceptos deben ser abiertos. También deberá llevarse un control completo del historial del empleado como choques, multas, etc.

Seguros Además de todas las capacidades antes mencionadas el Sistema de Control de Rutas deberá ofrecer facilidades para el manejo de pólizas de seguros tanto para los empleados como para los vehículos.

Proveedores Debe llevarse control de los proveedores de los distintos elementos de gastos del sistema.

Análisis de Requerimientos El análisis de requerimientos consiste en definir los casos de uso para el sistema, los cuales describen lo que el Sistema de Control de Rutas proporcionará en términos de funcionalidad. El análisis de casos de uso consistió en leer y analizar las especificaciones, así como discutir el sistema con los usuarios potenciales (clientes) del sistema. Actores Los actores del sistema fueron identificados como:

Operador del sistema: es la persona que se encarga de introducir los datos generales del sistema y de darle mantenimiento. Gerente Ventas: es la persona que desempeña el cargo de Gerente de Ventas. Gerente Financiero: es la persona que desempeña el cargo de Gerente Financiero. Gerente Recursos Humanos: es la persona que desempeña el cargo de Gerente de Recursos Humanos. Sistema de Contabilidad: es el Sistema de Contabilidad de la empresa. Usuario: es un supertipo del cual todos los actores humanos heredan.

Casos de Uso Basados en los actores, las necesidades planteadas en los requerimientos del sistema y ciertos requerimientos de implementación fueron identificados los siguientes casos de uso (con su respectiva descripción):

Controlar Gastos en las Rutas: este caso de uso es iniciado por el gerente financiero o de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes gastos en las rutas. Controlar Recorridos de las Rutas: este caso de uso es iniciado por el gerente de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los datos de los recorridos de las rutas. Mantener Itinerarios de las Rutas: este caso de uso es iniciado por el gerente de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los datos de los itinerarios de las rutas.

Página 188

Análisis y Diseño de Sistemas con el UML

Controlar Asignaciones de los Vehículos: este caso de uso es iniciado por el gerente de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los datos de las asignaciones de los vehículos. Calendarizar Mantenimientos de los Vehículos: este caso de uso es iniciado por el gerente de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los datos de los calendarios de mantenimientos de las rutas. Mantener Historial del Empleado: este caso de uso es iniciado por el gerente de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar el historial del empleado. Reportes: este caso de uso es iniciado por el gerente de ventas, el gerente financiero o el gerente de recursos humanos y proporciona la capacidad de obtener reportes del sistema. Exportar Gastos al Sistema de Contabilidad: este caso de uso es iniciado por el gerente financiero. Proporciona la capacidad de exportar los gastos registrados en el sistema al sistema de contabilidad mediante archivos de texto. Gastos de Rutas: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes gastos atribuibles directamente a las rutas. Gastos de Vehículos: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes gastos misceláneos de los vehículos. Gastos de Mantenimientos: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes gastos de mantenimiento de los vehículos. Gastos de Seguros de Vehículos: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes gastos de seguros (pólizas) de los vehículos. Gastos de Empleados: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes gastos de los empleados. Gastos de Seguros de Empleados: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes gastos de seguros (pólizas) de los empleados. Importar Nómina de Empleados: este caso de uso proporciona la capacidad de importar los gastos en salarios del empleado del sistema de nómina al sistema de control de rutas mediante un archivo de texto del sistema operativo. Mantenimiento del Sistema: este caso de uso es iniciado por el operador. Proporciona la capacidad de crear, modificar, eliminar y visualizar los datos de los catálogos del sistema y las utilerías del mismo. Datos de Rutas: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de las rutas de distribución. Datos de Vehículos: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de los vehículos. Datos de Empleados: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de los empleados (choferes y ayudantes). Datos de Clientes: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de los clientes. Datos de Proveedores: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de los proveedores. Datos de Productos y/o Servicios: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de los productos y/o servicios de los gastos. Datos de Mantenimientos: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de los mantenimientos preventivos. Nombres de Historiales: Proporciona la capacidad de crear, modificar, eliminar y visualizar los diferentes datos generales de los nombres de los historiales. Exportar Base de Datos: Proporciona la capacidad de exportar la base de datos del sistema a un archivo del sistema operativo. Ayuda: este caso de uso es iniciado por un usuario. Proporciona la capacidad del proporcionar ayuda en línea al usuario.

Capítulo 14: Caso de Estudio

Página 189

Validar Usuario: este caso de uso es iniciado por un usuario. Proporciona la capacidad de verificar el usuario y darle o no acceso al sistema. Reporte de Calendarios de Mantenimiento: Proporciona la capacidad de imprimir un reporte del calendario de mantenimiento de los vehículos. Reporte de Itinerarios: Proporciona la capacidad de imprimir un reporte de los itinerarios de las rutas. Reporte de Historiales: Proporciona la capacidad de imprimir un reporte de los historiales de los empleados. Reporte de Recorridos: Proporciona la capacidad de imprimir un reporte de los recorridos de las rutas. Reporte de Asignaciones: Proporciona la capacidad de imprimir un reporte de asignaciones de vehículos. Reporte de Seguros de Vehículos: Proporciona la capacidad de imprimir un reporte de pólizas de seguros de vehículos. Reporte de Seguros de Empleados: Proporciona la capacidad de imprimir un reporte de pólizas de seguros de empleados. Reporte de Gastos de Rutas: Proporciona la capacidad de imprimir un reporte de gastos directamente atribuibles a las rutas. Reporte de Gastos de Vehículos: Proporciona la capacidad de imprimir un reporte de gastos misceláneos de los vehículos. Reporte de Gastos de Mantenimiento: Proporciona la capacidad de imprimir un reporte de gastos de mantenimiento de los vehículos. Reporte de Gastos de Empleado: Proporciona la capacidad de imprimir un reporte de gastos de los empleados. Reporte de Rutas: Proporciona la capacidad de imprimir un reporte de los datos de las rutas. Reporte de Vehículos: Proporciona la capacidad de imprimir un reporte de los datos de los vehículos. Reporte de Empleados: Proporciona la capacidad de imprimir un reporte de los datos de los empleados. Reporte de Proveedores: Proporciona la capacidad de imprimir un reporte de los datos de los proveedores. Reporte de Productos y/o Servicios: Proporciona la capacidad de imprimir un reporte de los datos de los productos y/o servicios. Reporte de Clientes: Proporciona la capacidad de imprimir un reporte de los datos de los clientes.

Todos estos casos de uso deben ser implementados a lo largo del desarrollo del sistema. Son usados durante el análisis para verificar si las clases de dominio (entidades) apropiadas han sido definidas, y son usados durante el diseño para confirmar que la solución técnica es suficiente para manejar la funcionabilidad requerida. También el análisis de requerimientos es documentado en diagramas de casos de uso y con flujos de eventos para cada caso de uso. Los diagramas de casos de uso se muestran a continuación.

Página 190

Análisis y Diseño de Sistemas con el UML

Figura 111: Diagrama de Casos de Uso – Principal del Sistema de Control de Rutas

Figura 112: Diagrama de Casos de Uso – Controlar Gastos en las Rutas

Capítulo 14: Caso de Estudio

Figura 113: Diagrama de Casos de Uso – Mantenimiento del Sistema

Figura 114: Diagrama de Casos de Uso – Acciones Generales

Página 191

Página 192

Análisis y Diseño de Sistemas con el UML

Figura 115: Diagrama de Casos de Uso – Reportes del Sistema

A continuación presentamos el flujo de eventos para algunos casos de uso. Los flujos de todos los casos de uso son incluidos en la documentación de cada caso de uso. 1

Flujo de eventos para el caso de uso: Controlar Gastos de las Rutas

1.1 Precondiciones 1.2 Flujo principal Este caso de uso inicia cuando el gerente financiero o de venta ingresa al sistema. El sistema le pide al usuario su nombre y contraseña. El usuario entra su nombre y contraseña. El sistema verifica que el nombre y contraseña sean válidas (E-1). El sistema le pide al usuario que seleccione un gasto de las pestañas del sistema:

Gastos de rutas Gastos de vehículos Gastos de mantenimientos Gastos de seguro de vehículos Gastos de empleados Gastos de seguro de empleados Importar nómina de empleados

Capítulo 14: Caso de Estudio

Página 193

El usuario selecciona la opción deseada. El sistema despliega la pantalla de gastos de la opción seleccionada y le pide al usuario la actividad deseada: AÑADIR, REMOVER, MODIFICAR, CONSULTAR o SALIR. 1.3 Subflujos Nota: Los subflujos están descritos específicamente para cada tipo de gastos del sistema. 1.4 Flujos alternos E-1: El nombre y/o contraseña introducido por el usuario es inválido. El sistema le notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del caso de uso. 2

Flujo de eventos para el caso de uso: Gastos de Rutas

2.1 Precondiciones Los subflujos AÑADIR de los casos de uso Datos de Rutas y Datos de Producto y/o Servicios deben de ejecutarse antes que este caso de uso inicie. 2.2 Flujo principal Este caso de uso inicia cuando el gerente financiero o de venta ingresa al sistema. El sistema le pide al usuario su nombre y contraseña. El usuario entra su nombre y su contraseña. El sistema verifica que el nombre y contraseña sean válida (E-1). El sistema despliega la pantalla de gastos de rutas y le pide al usuario que seleccione la ruta a cargar el gasto. El usuario selecciona la ruta deseada (E-2). El sistema le pide al usuario que seleccione la actividad deseada: AÑADIR, REMOVER, MODIFICAR, CONSULTAR o SALIR. Si la actividad es AÑADIR, es S-1: Añadir un gasto de ruta es realizado. Si la actividad es REMOVER, es S-2: Remover un gasto de ruta es realizado. Si la actividad es MODIFICAR, es S-3: Modificar un gasto de ruta es realizado. Si la actividad es CONSULTAR, es S-4: Consultar los gastos de la ruta es realizado. Si la actividad es SALIR, el caso de uso finaliza. 2.3 Subflujos S-1: Añadir un gasto de ruta El sistema solicita el código del producto y/o servicio a cargar como gasto, la fecha y hora del gasto, la cantidad, el costo de materiales y de mano de obra. El usuario introduce el código del producto y/o servicio a cargar como gasto (E-3), la fecha y hora del gasto (E-4), la cantidad (E-5), el costo de materiales (E-6) y de mano de obra (E-7). El sistema guarda el gasto. El caso de uso inicia de nuevo. S-2: Remover un gasto de ruta El sistema solicita al usuario que seleccione el gasto de ruta a remover. El usuario selecciona el gasto de ruta. El sistema remueve el gasto de ruta. El caso de uso inicia de nuevo. S-3: Modificar un gasto de ruta El sistema solicita la selección del gasto de ruta a modificar. El usuario selecciona el gasto de ruta. El sistema solicita el código del producto y/o servicio a cargar como gasto, la fecha y hora del

Página 194

Análisis y Diseño de Sistemas con el UML

gasto, la cantidad, el costo de materiales y de mano de obra. El usuario introduce el código del producto y/o servicio a cargar como gasto (E-3), la fecha y hora del gasto (E-4), la cantidad (E-5), el costo de materiales (E-6) y de mano de obra (E-7). El sistema guarda los cambios del gasto. El caso de uso inicia de nuevo. S-4: Consultar los gastos de la ruta. El sistema solicita el criterio de consulta. El usuario introduce el criterio de consulta (E-8). El sistema despliega los gastos de rutas encontrados según el criterio de consulta (E-9). El caso de uso inicia de nuevo. 2.4 Flujos alternos E-1: El nombre y/o contraseña introducido por el usuario es inválido. El sistema le notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del caso de uso. E-2: El usuario ha introducido un código inválido o nulo de ruta. El sistema notifica al usuario. El usuario puede introducir un código válido de ruta o salir del caso de uso. E-3: El usuario introduce un código inválido o nulo del producto y/o servicio. El sistema notifica al usuario. El usuario puede introducir un código válido de producto y/o servicio o salir del caso de uso. E-4: El usuario introduce una fecha y hora inválida o nula. El sistema notifica al usuario. El usuario puede introducir una fecha y hora válida o salir del caso de uso. E-5: El usuario introduce una cantidad inválida o nula. El sistema notifica al usuario. El usuario puede introducir una cantidad válida o salir del caso de uso. E-6: El usuario introduce un costo inválido o nulo de materiales. El sistema notifica al usuario. El usuario puede introducir un costo válido de materiales o salir del caso de uso. E-7: El usuario introduce un costo inválido de mano de obra. El sistema notifica al usuario. El usuario puede introducir un costo válido de mano de obra o salir del caso de uso. E-8: El usuario ha introducido un criterio inválido de consulta. El sistema notifica al usuario. El usuario puede introducir un criterio de consulta válido o salir del caso de uso. E-9: El sistema no pudo recuperar ningún gasto de ruta. El caso de uso inicia de nuevo. 3

Flujo de eventos para el caso de uso: Datos de Rutas

3.1 Precondiciones 3.2 Flujo principal Este caso de uso inicia cuando el operador del sistema ingresa al sistema. El sistema le pide al usuario su nombre y contraseña. El usuario entra su nombre y su contraseña. El sistema verifica que el nombre y contraseña sean válida (E-1). El sistema despliega la pantalla de datos de rutas. El sistema le pide al usuario que seleccione la actividad deseada: AÑADIR, REMOVER, MODIFICAR, CONSULTAR o SALIR.

Capítulo 14: Caso de Estudio

Página 195

Si la actividad es AÑADIR, es S-1: Añadir una ruta es realizado. Si la actividad es REMOVER, es S-2: Remover una ruta es realizado. Si la actividad es MODIFICAR, es S-3: Modificar una ruta es realizado. Si la actividad es CONSULTAR, es S-4: Consultar las rutas es realizado. Si la actividad es SALIR, el caso de uso finaliza. 3.3 Subflujos S-1: Añadir una ruta El sistema solicita el código de la ruta, la descripción, el nombre del supervisor, la situación geográfica y la situación política. El usuario introducirá el código de la ruta (E-2), la descripción (E-3), el nombre del supervisor (E-4), la situación geográfica (E-5) y la situación política (E-6). El sistema guarda la ruta. El caso de uso inicia de nuevo. S-2: Remover una ruta El sistema solicita al usuario el código de la ruta a remover. El usuario introduce el código de la ruta (E-2). El sistema remueve la ruta. El caso de uso inicia de nuevo. S-3: Modificar una ruta El sistema solicita al usuario el código de la ruta a modificar. El usuario introduce el código de la ruta. El sistema solicita la descripción, el nombre del supervisor, la situación geográfica y la situación política. El usuario introducirá la descripción (E-3), el nombre del supervisor (E-4), la situación geográfica (E-5) y la situación política (E-6). El sistema guarda los cambios de la ruta. El caso de uso inicia de nuevo. S-4: Consultar las rutas El sistema solicita el criterio de consulta. El usuario introduce el criterio de consulta (E-7). El sistema despliega las rutas encontradas según el criterio de consulta (E-8). El caso de uso inicia de nuevo. 3.4 Flujos alternos E-1: El nombre y/o contraseña introducido por el usuario es inválido. El sistema le notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del caso de uso. E-2: El usuario ha introducido un código inválido o nulo de ruta. El sistema notifica al usuario. El usuario puede introducir un código válido de ruta o salir del caso de uso. E-3: El usuario ha introducido una descripción inválida o nula. El sistema notifica al usuario. El usuario puede introducir una descripción válida o salir del caso de uso. E-4: El usuario introduce un nombre de supervisor inválido o nulo. El sistema notifica al usuario. El usuario puede introducir un nombre válido o salir del caso de uso. E-5: El usuario introduce una situación geográfica inválida. El sistema notifica al usuario. El usuario puede introducir una situación geográfica válida o salir del caso de uso. E-6: El usuario introduce una situación política inválida. El sistema notifica al usuario. El usuario puede introducir una situación política válida o salir del caso de uso.

Página 196

Análisis y Diseño de Sistemas con el UML

E-7: El usuario ha introducido un criterio inválido de consulta. El sistema notifica al usuario. El usuario puede introducir un criterio válido de consulta o salir del caso de uso. E-8: El sistema no pudo recuperar ninguna ruta. El caso de uso inicia de nuevo. 4

Flujo de eventos para el caso de uso: Reporte de Rutas

4.1 Precondiciones El subflujo AÑADIR del caso de uso Datos de Rutas deben de ejecutarse antes que este caso de uso inicie. 4.2 Flujo principal Este caso de uso inicia cuando el gerente de finanzas, de venta o de recursos humanos ingresa al sistema. El sistema le pide al usuario su nombre y contraseña. El usuario entra su nombre y su contraseña. El sistema verifica que el nombre y contraseña sean válida (E-1). El sistema pide al usuario seleccionar el reporte de rutas del menú del sistema. El usuario selecciona el reporte de rutas. El sistema despliega la pantalla de reporte de rutas y le pide al usuario que seleccione el destino de salida: IMPRESORA, E-MAIL o CANCELAR. Si el destino es IMPRESORA, es S-1: Reporte de rutas por impresora es realizado. Si el destino es E-MAIL es S-2: Reporte de rutas por e-mail es realizado. Si la actividad es CANCELAR, el caso de uso finaliza. 4.3 Subflujos S-1: Reporte de rutas por impresora El sistema da salida al reporte por impresora con los datos de códigos de rutas, descripciones de rutas, situaciones geográficas y políticas de las rutas (E-2). S-2: Reporte de rutas por e-mail El sistema da salida al reporte por correo electrónico con los datos de códigos de rutas, descripciones de rutas, situaciones geográficas y políticas de las rutas (E-2). 4.4 Flujos alternos E-1: El nombre y/o contraseña introducido por el usuario es inválido. El sistema le notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del caso de uso. E-2: El destino de salida del reporte no esta disponible. El sistema le notifica al usuario. El usuario puede introducir un destino disponible o salir del caso de uso.

Análisis El propósito del análisis es capturar y describir todos los requerimientos del sistema y elaborar un modelo que defina las clases claves del dominio del sistema (qué es manejado en el sistema). También se quiere proporcionar una explicación clara y permitir una comunicación fluida entre los desarrolladores (nosotros) y la gente que establece los requerimientos (usuario o cliente); por lo tanto, el análisis es típicamente conducido en cooperación con el usuario final.

Capítulo 14: Caso de Estudio

Página 197

Para realizarlo, analizamos las especificaciones y los casos de uso y buscamos qué “conceptos” deben ser manejados por el sistema. Para esto organizamos una sesión de lluvia de ideas con los clientes para identificar los conceptos claves que deben ser manejados, junto con las relaciones entre sí. Clases de Entidad Las clases de entidad en el Sistema de Control de Rutas son definidas con el estereotipo <<Entity>>, lo cual indica que los objetos de la clase son parte del dominio del problema y deben ser almacenadas persistentemente en el sistema. Enfatizamos el hecho de que las clases de entidad están siendo dibujadas a un nivel alto en esta etapa. Las clases de entidad identificadas junto con su descripción se muestran a continuación:

Ruta: Una ruta es una división geográfica que hace la empresa con el fin de distribuir sus productos. Vehículo: Un vehículo es usado por la empresa para la distribución de los productos a los clientes. Cliente: Un cliente es cualquier persona o empresa que compra productos de la empresa. Mantenimiento: Un mantenimiento es la descripción de cada uno de los planes de mantenimiento que tiene la empresa para sus vehículos. CalendarioMantenimiento: Un CalendarioMantenimiento es una ejecución específica de un mantenimiento para un vehículo en una fecha dada o calendarizada. Recorrido: Un Recorrido es un viaje que un vehículo hace en una ruta. Empleado: Un empleado es una persona que trabaja para la empresa. En el Sistema de Control de Rutas hay dos tipos: chofer y ayudante. Historial: Un Historial es la descripción de un nombre de historial (evento) que ocurre a un empleado en una fecha y hora dada. Proveedor: Un Proveedor es una persona o empresa que proporciona materia prima a la empresa. Producto: Un Producto o Servicio es un elemento de costo del sistema; es decir, algo en lo que se gasta y por lo tanto tiene un costo asociado. GastoRuta: Un GastoRuta es un gasto que es atribuible directamente a una ruta en una fecha y hora específica. GastoVehículo: Un GastoVehículo es un gasto que es atribuible a un vehículo en una fecha y hora específica. GastoMantenimiento: Un GastoMantenimiento es un gasto que es atribuible a un CalendarioMantenimiento en una fecha y hora específica. GastoEmpleado: Un GastoEmpleado es un gasto que es atribuible a un empleado en una fecha y hora específica. SeguroVehículo: Un SeguroVehículo es un gasto por concepto de seguro que es atribuible a un vehículo en una fecha y hora específica. SeguroEmpleado: Un SeguroEmpleado es un gasto por concepto de seguro que es atribuible a un empleado en una fecha y hora específica. Itinerario: Un Itinerario es una descripción de los días de operación de una ruta. NombreHistorial: Un NombreHistorial es un evento que puede ocurrir a un empleado y que debe ser almacenado en el sistema. DetalleItinerario: Un DetalleItinerario contiene información relativa a los clientes que la ruta visita de acuerdo al día de la semana y en que orden. Asignación: Una Asignación contiene información relativa a que empleado tiene asignado un vehículo (o viceversa) en un período. DetalleMantenimiento: Un DetalleMantenimiento contiene información relativa a los Productos y/o Servicios que se realizan durante un mantenimiento (plan).

Página 198

Análisis y Diseño de Sistemas con el UML

Clases de Frontera Cuando se analizan los flujos de eventos se vuelve obvio que se necesitan ventanas y cuadros de diálogos para proporcionar una interfaz a los actores. En el análisis es suficiente darse cuenta que se necesitan las ventanas y cuadros de diálogos para documentar los requisitos de interfaz del usuario. Las ventanas las modelamos con el estereotipo <<Ventana>>. El diseño detallado de la interfaz del usuario no es especificado en este momento; de nuevo, es una especificación de alto nivel. También es necesario añadir las interfaces con los sistemas de contabilidad y nómina que son también clases de frontera con el estereotipo <<ArchivoTexto>>. Esto lo hicimos porque la interfaz se hace mediante archivos de texto. Las clases de frontera identificadas para el sistema son: Contabilidad, Nómina, VentanaRutas, VentanaRecorridos, VentanaItinerarios, VentanaGastosRuta, VentanaVehículos, VentanaAsignaciones, VentanaGastosVehículos, VentanaCalendarios, VentanaSegurosVehículos, VentanaEmpleados, VentanaHistoriales, VentanaGastosEmpleados, VentanaSegurosEmpleados, VentanaClientes, VentanaProveedores, VentanaProductos, VentanaMantenimientos, VentanaNombresHistoriales, Menú, VentanaAyuda, VentanaValidarUsuario, VentanaRepGastosEmpleados, VentanaRepGastosVehículos, VentanaRepGastosRutas, VentanaRepSegurosEmpleados, VentanaRepSegurosVehículos, VentanaRepEmpleados, VentanaRepProductos, VentanaRepGastosMantenimientos, VentanaRepCalendarioMantenimientos, VentanaRepClientes, VentanaRepItinerarios, VentanaRepHistoriales, VentanaRepRecorridos, VentanaRepAsignaciones, VentanaRepRutas, VentanaRepVehículos, VentanaRepProveedores, VentanaNómina, Pestañas, VentanaRepMantenimientos, VentanaExportarGastos, Las descripciones de estas clases son todas similares y del tipo: “VentanaRutas: Proporciona una interfaz para el caso de uso Datos de Rutas”; por eso no las incluimos aquí. Clases de Control Durante esta etapa añadimos una clase de control por cada caso de uso para manejar el flujo de eventos del mismo. Estas clases las definimos con el estereotipo <<Control>>. Las clases de control añadidas son: AdmControlGastos, AdmRecorridos, AdmItinerarios, AdmMantenimientoSist, AdmAsignaciones, AdmCalendarios, AdmMantenimientos, AdmReportes, AdmSegurosEmpleados, AdmSegurosVehiculos, AdmRutas, AdmVehículos, AdmEmpleados, AdmGastosVehículos, AdmHistoriales, AdmGastosEmpleado, AdmGastosMantenimiento, AdmClientes, AdmProveedores, AdmProductos, AdmExportarBD, AdmExportarContabilidad, AdmImportarNómina, AdmAyuda, AdmNombresHistorial, AdmValidarUsuario, AdmRepGastosEmpleados, AdmRepGastosVehículos, AdmRepGastosRutas, AdmRepSegurosEmpleados, AdmRepSegurosVehículos, AdmRepEmpleados, AdmRepEmpleados, AdmRepProductos, AdmRepGastosMantenimientos, AdmRepCalendarioMantenimientos, AdmRepClientes, AdmRepItinerarios, AdmRepHistoriales, AdmRepRecorridos, AdmRepAsignaciones, AdmRepRutas, AdmRepVehículos, AdmRepProveedores, AdmRepMantenimientos.. Las descripciones de estas clases son todas similares y del tipo: “AdmControlGastos: Proporciona lógica de secuenciación para el caso de uso Controlar Gastos en las Rutas”; por eso no las incluimos aquí.

Capítulo 14: Caso de Estudio

Página 199

Paquetes Para separar las clases de entidad, las clases de frontera y las clases de control, se agrupan en paquetes llamados respectivamente Objetos del Negocio, Interfaz del Sistema y Utilidades. Estos paquetes serán detallados en el diseño.

Figura 116: Paquetes del sistema en la Fase de Análisis

Diagramas de secuencia Los casos de uso deben ser realizados durante esta etapa. Para describir el comportamiento dinámico del sistema, cualquiera de los diagramas de interacción del UML pueden ser utilizados. Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboración (en notación completa del UML) usaremos diagramas de secuencia. De nuevo, las operaciones son definidas a un nivel alto y no son descritas en detalle con signaturas. Las metas principales del análisis son lograr una comunicación eficiente con el usuario/cliente y lograr un entendimiento de alto nivel del sistema que se construye; no es una solución de diseño detallado.

Figura 117: Diagrama de secuencia para el escenario Añadir Ruta del caso de uso Datos de Rutas en la Fase de Análisis

Página 200

Análisis y Diseño de Sistemas con el UML

Relaciones entre Clases Las relaciones entre clases son encontradas analizando los requerimientos del sistema (de una forma muy parecida a las relaciones en los diagramas entidad-relación) y también mediante los mensajes en los diagramas de secuencia. En el escenario Añadir Ruta del caso de uso Datos de Rutas podemos observar que hay comunicación entre las clases VentanaRutas (del paquete interfaz) y Ruta (del paquete objetos del negocio), por lo que hay que crear una relación de asociación entre ellas. Operaciones de las Clases Las operaciones de las clases fueron encontradas mapeando los mensajes en los diagramas de secuencia a operaciones en la clase receptora. Por ejemplo, en el escenario Añadir Ruta del caso de uso Datos de Ruta podemos observar que la clase Ruta recibe dos mensajes. Estos mensajes se convirtieron en operaciones llamadas Crear y Guardar. Atributos de las Clases Los atributos de las clases fueron encontrados en los requerimientos del sistema y en los flujos de eventos. Por ejemplo, en los requerimientos del sistema dice: "El sistema deberá almacenar todos los datos concernientes al supervisor, distancias, estado carretera, situación geográfica y política" (de las rutas). Por lo tanto se crearon atributos para la clase Ruta llamados Supervisor, Sit_Geo y Sit_Pol. Se añadió un atributo Id para identificar cada clase y un atributo Ruta_Desc que contendrá la descripción de cada ruta. También se añadieron los atributos distancia, vía y estado a la clase DetalleItinerario. Diagramas de Estados Algunas de las clases tienen diagramas de estados para mostrar los diferentes estados que los objetos de dichas clases puedan tener, junto con los eventos que causarán la transición de estados.

Figura 118: Diagrama de Estados para la clase CalendarioMantenimiento

Capítulo 14: Caso de Estudio

Página 201

Diseño La fase de diseño (y los modelos UML resultantes) expande y detalla los modelos de análisis tomando en cuenta todas las implicaciones y restricciones técnicas. El propósito del diseño es especificar una solución que trabaje y pueda ser fácilmente convertida en código fuente y construir una arquitectura simple y fácilmente extensible. Las clases definidas en el análisis fueron detalladas, y se añadieron nuevas clases para manejar áreas técnicas como base de datos, interfaz del usuario, comunicación, dispositivos, etc. Una arquitectura bien diseñada es la base para un sistema fácilmente extensible y cambiable. Durante esta etapa se expandieron los paquetes del sistema, incluyendo sus dependencias y mecanismos de comunicación. Estos paquetes son detallados, de tal forma que las clases sean detalladas de forma suficiente para dar especificaciones claras al programador que las codifica. Los paquetes fueron definidos tomando en cuenta la separación entre áreas funcionales y áreas técnicas. Un problema clave por resolver en esta definición fue establecer las reglas para dependencias entre los paquetes, de tal forma que se eviten las dependencias bidireccionales entre ellos e identificar la necesidad de librerías estándar que puedan ser usadas y simplifiquen el trabajo.

Figura 119: Paquetes del sistema en la etapa de diseño y sus dependencias

La figura anterior muestra los paquetes del caso de estudio. A continuación se detallan cada uno de ellos:

Paquete de base de datos La aplicación debe almacenar sus objetos persistentemente, por lo tanto una capa de base de datos fue añadida para proporcionar este servicio. La solución desarrollada fue implementar el almacenamiento mediante la base de datos objeto-relacional Oracle8. Los detalles sobre el almacenamiento son escondidos de la aplicación, la cual sólo tiene que llamar operaciones comunes como insert(), update(), delete(), y select(), y así sucesivamente, en los objetos.

Página 202

Análisis y Diseño de Sistemas con el UML

Paquete de objetos del negocio El paquete de objetos del negocio está basado en el paquete correspondiente en el análisis. Las clases, sus relaciones, y su comportamiento son preservados; sólo que las clases son descritas con mayor detalle, incluyendo cómo sus relaciones y comportamiento son implementados. Las operaciones del análisis han sido detalladas, lo que significa que algunas de ellas han sido cambiadas. Esto es considerado normal, debido a que el análisis es un dibujo de las capacidades de cada clase mientras que el diseño es una descripción detallada del sistema. A continuación se muestra una sección del diagrama de clases de entidad en la etapa de diseño:

Figura 120: Diagrama de Clases de Entidad en la Fase de Diseño

Es importante notar que entre los modelos de análisis y de diseño se realizaron los siguientes cambios:

Se agregaron clases para representar interfaces entre dispositivos como la impresora y para representar el envío de reportes mediante correo electrónico. Esta versión del sistema (la primera iteración) no maneja la importación del sistema de nómina, por que fue dejada para una iteración posterior; por lo tanto no fue implementada. Los modelos dinámicos en el modelo de diseño han sido actualizados. De nuevo los diagramas de secuencia se utilizan para mostrar los modelos dinámicos.

Capítulo 14: Caso de Estudio

Página 203

Figura 121: Diagrama de secuencia para el escenario Añadir Ruta del caso de uso Datos de Rutas en la Fase de Diseño

Paquete de interfaz del sistema El paquete de interfaz del sistema está por encima de los otros paquetes. Presenta los servicios y la información en el sistema a los actores. Este paquete está basado en las capacidades proporcionadas por Oracle Developer/2000.

Paquete de utilidades El paquete de utilidades contiene servicios que otros paquetes usan en el sistema, tales como las clases de control definidas durante el análisis, las cuales han sido detalladas, combinadas y expandidas durante el diseño.

Página 204

Análisis y Diseño de Sistemas con el UML

Interfaz del usuario

Figura 122: Interfaz de usuario del Sistema de Control de Rutas

Una actividad especial llevada a cabo durante la fase de diseño es la creación de la interfaz del usuario. Este trabajo, iniciado separadamente durante el análisis es hecho paralelamente a otros trabajos de diseño. Sin embargo, cómo crear una interfaz de usuario exitosa está fuera del alcance de nuestro trabajo, por lo que se pueden consultar otras fuentes sobre el tema. La interfaz del usuario está basada en los casos de uso, y ha sido dividida en las siguientes secciones, cada una de las cuales tiene un módulo independiente en la ventana principal:

Rutas Vehículos Empleados Catálogos

La interfaz también posee un menú, que corresponde también a algunos casos de uso:

Reportes Herramientas Operaciones generales de los casos de uso Ayuda

Capítulo 14: Caso de Estudio

Página 205

La interfaz de usuario resultante en la aplicación está compuesta de una ventana principal con una barra de menú y una barra de herramientas, con pestañas con indicaciones adecuadas de cómo accesar los diferentes módulos del sistema, una línea de mensajes y una línea de estado.

Implementación Esta es la fase cuando las clases son programadas. Para esto fueron implementadas en Oracle Developer/2000. Es importante mencionar que como se mencionó anteriormente, no se programaron todos los casos de uso del sistema porque fueron dejados para una iteración posterior, específicamente: Importar Nómina de Empleados. También queremos recalcar el hecho de que Rational Rose no puede generar código para Developer/2000, por lo que el trabajo fue más arduo. Sin embargo, puede generar código para lenguajes como C++, Java, Visual Basic y el esquema de base de datos para Oracle8. El diagrama de componentes muestra los diferentes componentes fuentes, binarios y ejecutables que componen el sistema

Figura 123: Diagrama de Componentes del Sistema

También creamos otros diagramas de componentes (que no se muestran aquí) donde se muestran los Reportes del Sistema, los Iconos del Sistema y los Scripts SQL del Sistema.

Pruebas y Despliegue Por supuesto, el sistema tuvo que ser probado. Los casos de uso originales fueron probados en la aplicación terminada para ver si eran correctamente soportados por la aplicación y podían ser realizados como se definen en las descripciones de los casos de uso. La aplicación también fue probada de una manera más informal poniéndola en las manos de ciertos usuarios especializados en la materia. El despliegue de la aplicación es la entrega actual. Debido a que el nuestro es un caso de estudio que no fue implementado en ninguna organización no fue creada ninguna documentación formal del sistema o manuales de usuario. Sin embargo, el sistema incluye una amplia ayuda en línea de todo el sistema, incluyendo instrucciones para la instalación y ejecución del mismo en el archivo Leame.htm en el CD-ROM. Se realizó un diagrama de despliegue de la arquitectura física. Este sistema puede ser desplegado en cualquier computadora con sistemas operativos Windows 95/98 o Windows NT 4.0 (con SP3) con acceso a una base de datos Oracle local o remota.

Página 206

Análisis y Diseño de Sistemas con el UML

Figura 124: Diagrama de Despliegue del Sistema

Conclusiones

Página 209

Desde el momento en que se inventó la programación, se ha intentado buscar la forma de plasmar la estructura de los programas y después de los Sistemas de Información en modelos que representen su comportamiento y estructura. Primero aparecieron técnicas como el Análisis y Diseño Estructurado que se adecuaban bien a los antiguos lenguajes estructurados. A medida que los lenguajes orientados a objetos se fueron haciendo más populares, se vio la necesidad de crear metodologías de análisis y diseño orientadas a objetos. Hacia principios de los 90s había varias de estas metodologías, cada una con su propia notación, fortalezas y debilidades. Esto hacía que la elección de una metodología fuera muy importante para el éxito de un proyecto y a menudo se hablaba de que una era mejor que la otra. También causaba que hubiera confusión entre los usuarios de dichas metodologías puesto que sus notaciones diferentes a menudo estaban en conflicto unas con otras. Es en ese momento en que los creadores del UML se dieron cuenta que esa situación estaba causando daño a la industria del software y por eso y otras razones expuestas anteriormente decidieron crear una metodología unificada llamada Método Unificado. Sin embargo, pronto se dieron cuenta que crear una sola forma de trabajar que cubriera la gran variedad de proyectos de software y las particularidades de cada persona, grupo u organización era imposible, por lo que decidieron crear solamente una notación estándar; el proceso, la otra parte de una metodología sería independiente de la notación. A esta notación se le llamó Lenguaje de Modelaje Unificado (UML). Han pasado ya dos años desde que el UML vio la luz pública en su versión 1.0 en enero de 1997 y ya comenzamos a ver los resultados de su influencia. La organización de administración de objetos (OMG) escogió al UML como su lenguaje de modelaje, muchas compañías contribuyeron al éxito del UML y todas ellas han dado soporte al mismo de una forma o de otra. Poco o poco irán apareciendo más herramientas que soporten su notación y modelos, por lo que aquellas personas que la manejen podrán hacer uso de ella. Como ya mencionamos, el UML por ser un conjunto de notaciones estándar necesita ser acompañado de un proceso que diga cuándo y cómo hacer las cosas. En nuestro estudio se utilizó el Proceso Unificado de Rational, un proceso que fue creado también por los autores del UML. Es importante mencionar que también existen otros procesos con soporte para el UML, pero su análisis y descripción está fuera del alcance de nuestro trabajo. Creemos que el UML representa un gran aporte a la comunidad de Ingenieros de Software y Programadores porque mejora la comunicación y el entendimiento entre diferentes grupos, proyectos y también herramientas al estandarizar el lenguaje en que se expresan los modelos. También consideramos que el UML junto con los procesos como el Proceso Unificado proporciona una forma clara, concisa, y fácil de aprender de cómo realizar Análisis y Diseño de Sistemas Orientado a Objetos; de tal forma que las actividades se derivan lógicamente una de la otra y los modelos utilizados en etapas más tempranas sirven como base en modelos utilizados posteriormente. Una pequeña dificultad que notamos es que el proceso de aprendizaje es un poco largo debido a la gran cantidad de diagramas, notación y elementos que posee el UML, así como sus reglas semánticas, dificultad que es rápidamente ignorada cuando observamos sus enormes ventajas. Una gran ventaja que observamos en el UML es la capacidad de poder utilizar los modelos en todas las etapas del ciclo de desarrollo de sistemas, y de poder ser discutidos con todo el personal involucrado como clientes o usuarios, desarrolladores, analistas, diseñadores, probadores, etc. Esto da como resultado una mejor comunicación, captación de los requerimientos, menos dudas y errores, y una mayor satisfacción al cliente por que ve un producto tangible más pronto.

Página 210

Análisis y Diseño de Sistemas con el UML

Finalmente, nos gustaría mencionar que creemos que el UML puede ser la respuesta a muchos de los problemas encontrados con el desarrollo de software en el mundo informático actual. Muchos de los riesgos de los proyectos informáticos (tales como cambios de requerimientos, entregas tardías, y otros riesgos) pueden ser reducidos o eliminados cuando se utiliza adecuadamente junto con su proceso acompañante. Por esto, nos sentimos orgullosos de presentar nuestro trabajo monográfico, el cual beneficiará seguramente a muchos nuevos profesionales de la informática dándoles un sólido fundamento teórico y práctico en esta nueva y poderosa herramienta.

Bibliografía

Página 213

Hans-Erik Eriksson y Magnus Penker. UML Toolkit. Primera Edición. Wiley Computer Publishing. 1998

Martin Fowler. UML Distilled. Primera Edición, Sexta Impresión. Addison-Wesley. 1998

Terry Quatrani. Visual Modeling with Rational Rose and UML. Primera Edición, Segunda Impresión. Addison-Wesley. 1998

Rational Software Corporation. Rose Enterprise Edition Getting Results. 1998

Rational Software Corporation. Rational Objectory Process Whitepaper. 1997

Rational Software Corporation. UML Documentation Set 1.1. http://www.rational.com/uml/resources/documentation/index.jtmpl.

Rational Software Corporation.A Rational Approach to Software Development using

Rational Rose. http://www.rational.com/products/rose/prodinfo/whitepapers/dynamic.jtmpl?doc_key=293

Philippe Kruchten de Rational Software Corporation. A Rational Development Process. http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl?doc_key=334

Philippe Kruchten de Rational Software Corporation. The 4+1 View Model of Architecture. http://www.rational.com/uml/resources/whitepapers/dynamic.jtmpl?doc_key=350

Rational Software Corporation. Values and features of visual modeling with Rational Rose 98. http://www.rational.com/support/techpapers/devprcs/

Oracle Corporation. Oracle Products and Year 2000 Compliance. http://www.oracle.com/year2000/2000/2000_files/2000.pdf

Rational Software Corporation. Rose 98 Enterprise Edition Help System.

Oracle Corporation. Oracle8 Enterprise Edition Documentation Set. 1997

Oracle Corporation. Oracle Developer/2000 2.1 Documentation Set. 1997

Anexo A: Calidad en los Modelos

Página 217

¿C

ómo sabemos si un modelo es bueno o no? Un lenguaje de modelaje puede brindaros una sintaxis y semántica pero no puede decirnos si un buen modelo ha sido producido. Esto abre el tema muy subjetivo de la calidad en los modelos. Lo que es importante cuando diseñemos modelos es lo que digamos sobre la realidad. Los modelos dan una expresión a lo que sea que estamos estudiando (realidad, visión, etc.). En un modelo, es muy importante que la esencia del dominio del problema sea capturada. En sistemas financieros, estamos modelando facturas pero no la deuda. En la mayoría de los negocios, la factura no es de importancia real, pero las deudas lo son. Una factura es solamente una representación de la deuda, por lo que debería ser modelada como tal. Otro ejemplo son las cuentas bancarias. Durante los años 70 y 80 muchos bancos modelaron cuentas de bancos, donde los clientes eran parte de las cuentas (la cuenta era una entidad y el cliente un atributo). El primer problema fue que los bancos no podían manejar una cuenta con muchos dueños. El segundo problema era que los bancos no podían conducir trabajo de mercadeo que involucraba clientes sin una cuenta porque no tenían la dirección. Por lo tanto, una dimensión de la calidad del modelo debe ser la relevancia del modelo. Un modelo relevante captura los aspectos importantes de lo que se está estudiando. Otras dimensiones de la calidad de los modelos son que el modelo debe ser fácil de comunicar, tener una meta explícita, ser fácil de mantener, ser consistente, y tener integridad. Modelos diferentes de la misma cosa pero con propósitos o perspectivas diferentes deben ser integrados. Sin importar que metodología o lenguaje de modelaje se use, hay otros problemas. Cuando hacemos modelos nos convertimos en parte del negocio, lo que significa que debemos considerar los efectos de nuestra intervención en el negocio. Es muy importante manejar todos los aspectos de nuestra intervención como política, cultura, estructura social, y poder. Si fallamos al hacer eso, podría no ser posible descubrir y capturar todas las necesidades reales del cliente (note que los requerimientos informados no son siempre lo mismo que las necesidades del cliente). En particular, problemas con políticas internas, patrones sociales, estructura informal, y poder que rodeen a los clientes deben ser tomados en consideración. Todos los proyectos, pequeños y grandes dependen de la comunicación. La gente se comunica entre sí. Leen los documentos de los otros y discuten sus contenidos. Por lo tanto la idea principal detrás de los modelos es la capacidad de comunicarlos. Si creamos modelos que nadie entiende o lee, no tiene sentido hacerlos del todo. Un modelo es bueno cuando es posible comunicarlo, cuando alcanza sus propósitos y cuando hemos capturado la esencia. Un buen modelo toma tiempo para crearse; es normalmente hecho por un equipo compuesto para un propósito particular. Cuando la gente se asigna a equipos debe ser hecho con el propósito del equipo en mente. Los equipos para modelar un sistema de información o de negocios pueden estar compuestos de clientes, expertos de modelaje, y expertos del dominio del problema. Un modelo debe tener un propósito explícito que todo el que lo use reconozca. Los modelos de análisis y diseño pueden ser modelos de los mismos sistemas pero son modelos diferentes y se enfocan en detalles diferentes. El también necesario tener un propósito explícito para el modelo para verificarlo y validarlo. Sin un propósito explícito, podríamos por ejemplo, verificar un modelo de análisis como si fuera de diseño. Muchos modelos envuelven solamente documentos en el negocio. ¿Entonces, que sucede cuando el negocio cambia? En la práctica esto es un gran problema. Es necesario capturar la esencia del negocio y modelar sobre esos conceptos para ser capaz de manejar los cambios apropiadamente. Se debe modelar el negocio central y después modelar la representación del negocio principal. Si la esencia es

Página 218

Análisis y Diseño de Sistemas con el UML

modelada, pequeños cambios en el negocio pueden ser manejados mediante alteraciones en las clases que representan el mismo. Los nombres en los elementos del modelo deben ser derivados del dominio del problema; deben tener un prefijo o sufijo. Es importante que a los elementos se les asignen nombres relevantes, especialmente a las clases, asociaciones, roles, atributos, y operaciones. Cuando los elementos tienen nombres del dominio, es más fácil comunicar el modelo. Los modelos diferentes de la misma cosa deben ser capaces de ser integrados y relacionados con los otros. Un aspecto de la coordinación de modelos es la integración. La integración significa que si un conjunto de modelos tienen el mismo propósito (aunque puedan tener diferentes perspectivas, ej.: dinámico, funcional, estático) y representan la misma cosa, debería ser posible juntarlos sin introducir inconsistencias. Las relaciones entre los modelos en diferentes niveles de abstracción es un aspecto importante. Es una de las claves para el éxito en la trazabilidad en ingeniería de software. Las relaciones entre diferentes niveles de abstracción pueden ser visualizadas con relaciones de refinamiento en el UML. Esto significa que los modelos son coordinados en cada nivel de abstracción y entre los diferentes niveles de abstracción. Aún si los modelos que diseñamos pueden ser comunicados, tienen un propósito explícito, capturan la esencia del negocio, y son coordinados, todavía podemos tener problemas si los modelos son muy complejos. Los modelos extremadamente complejos pueden ser difíciles de revisar, verificar, validar, y mantener. A menudo es buena idea iniciar con una simplificación, y después añadir más detalle usando coordinación de modelos. Cuando el dominio del problema es complejo, se debe dividir el modelo en más modelos (usando paquetes) y mediante ese proceso controlar la situación.

Anexo B: Refactorizaci贸n

Anexo B: Refactorización

Página 221

¿L

e ha ocurrido el principio de entropía del software? Sugiere que los programas inician en una forma bien diseñada, pero a medida que nuevos trozos de funcionalidad son añadidos, los programas gradualmente pierden su estructura, transformándose eventualmente en una masa de espagueti. Parte de esto es debido a la escala. Se escribe un programa pequeño que hace un trabajo específico bien. La gente le pide mejorar el programa, y se vuelve más complejo. Aún si trata de controlar el diseño, eso puede ocurrir. Una de las razones por las que ocurre la entropía del software es que cuando añade una nueva función a un programa, la construye encima del programa existente, a menudo en una forma en que el programa no estaba destinado a soportar. En esta situación, puede rediseñar el programa existente para soportar mejor los cambios o puede trabajar alrededor de esos cambios en sus adiciones. Aunque en teoría es mejor rediseñar el programa, esto resulta usualmente en trabajo extra porque la reescritura de su programa viejo traerá nuevos errores y problemas. Recuerde el viejo adagio de la ingeniería: “Si no está roto, no lo repare.” Sin embargo, si no rediseña el programa, las adiciones serán más complejas de lo que deberían ser. Gradualmente, la complejidad adicional traerá problemas mayores. Por lo tanto, hay un compromiso: rediseñar causa dolor a corto plazo para aliviar dolor a largo plazo. La refactorización es un término usado para describir técnicas que reducen el dolor a corto plazo de rediseñar. Cuando se refactoriza, no cambia la funcionalidad del programa, si no su estructura interna para hacerlo más comprensible y manejable. Los cambios de refactorización son usualmente pequeños: renombrar un método, mover un atributo de una clase a otra, consolidar dos métodos similares en una superclase. Cada paso es pequeño, pero un par de horas de realizar estos pasos puede hacer mucho bien a un programa. La refactorización es hecha más fácil siguiendo los siguientes principios:

No refactorice un programa y añada funcionalidad a la vez. Imponga una separación clara entre los dos mientras trabaja. Puede cambiar de uno a otro en pasos cortos – por ejemplo, media hora refactorizando, y una hora añadiendo nueva funcionalidad. Asegúrese que tiene buenas pruebas establecidas antes de refactorizar. Corra las pruebas tan seguido como sea posible; de esa forma sabrá pronto si los cambios han dañado algo. Haga pasos cortos y deliberados. Mueva un atributo de una clase a otra. Fusione dos clases similares en una superclase. La refactorización a menudo involucra hacer muchos cambios localizados que resultan en un cambio en larga escala. Si mantiene sus pasos pequeños y prueba después de cada paso, evitará pruebas prolongadas.

Debe de refactorizar cuando:

Añade funcionalidad al programa y encuentra que el código viejo se pone en el camino. Cuando eso se vuelve un problema, pare añadiendo la nueva funcionalidad, y refactorice el código viejo. Tiene dificultades entendiendo el código. La refactorización es una buena forma de ayudarle a entender el código y preservar ese entendimiento para el futuro.

Página 222

Análisis y Diseño de Sistemas con el UML

A menudo, deseará refactorizar código que alguien más escribió. Cuando haga esto, hágalo al lado del autor del código o con alguien que lo entienda. Es difícil escribir código en una forma que otros puedan entender fácilmente. La refactorización es una técnica muy subutilizada. Ha comenzado a ser reconocida principalmente en la comunidad Smalltalk. Sin embargo, puede ser una técnica clave en mejorar el desarrollo del software. Asegúrese de que conoce cómo hacer refactorización en una forma disciplinada. Una forma de hacerlo es conseguir un mentor que le enseñe las técnicas apropiadas.18

Vea: 1. William F. Opdyke: Refactoring Object-Oriented Frameworks. Ph.D. Thesis, University of Illinois at Urbana-Champaign, 1992. ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdykethesys.ps.Z 2. Kent Beck: Smalltalk Best Practice Patterns. Prentice Hall, 1996. 3. Kent Beck: “Make It Run, Make It Right: Design Through Refactoring.” The Smalltalk Report, Vol. 6, No. 4, pp. 19-24, SIGS Publications, Enero 1997.

Anexo C: Dise単o por Contrato

Anexo C: Diseño por Contrato

Página 225

l diseño por contrato es una técnica desarrollada por Bertrand Meyer. La técnica es una característica central del lenguaje Eiffel; sin embargo, es una técnica valiosa que puede ser usada con cualquier lenguaje de programación.

En el corazón del Diseño por Contrato se encuentra la aserción. Una aserción es una sentencia Boleana que nunca debería ser falsa y, por lo tanto es falsa solamente por un error en el programa. Típicamente, las aserciones son chequeadas durante la depuración y no durante la ejecución de los programas. Un programa nunca debe asumir que las aserciones están siendo chequeadas. El diseño por contrato usa tres tipos de aserciones: precondiciones, poscondiciones, e invariantes. Las precondciones y poscondiciones se aplican a las operaciones. Una poscondición es una sentencia que cómo se debería ver el mundo después de la ejecución de una operación. Por ejemplo, si definimos la operación “cuadrado” en un número, la poscondición tomaría la forma resultado = esto * esto, donde resultado es la salida y esto es el objeto en la cual la operación fue invocada. La poscondición es una forma útil de decir lo que se hace sin decir cómo se hace – en otras palabras, de separar la interfaz de la implementación. Una precondición es una sentencia de cómo esperamos que sea el mundo antes de ejecutar la operación. Podríamos definir una precondición para la operación “cuadrado” como esto >= 0. Esta precondición dice que es un error invocar “cuadrado” en un número negativo y que las consecuencias de hacerlo son indefinidas. A primera vista, esto parece una mala idea, porque podríamos poner una verificación en alguna parte para asegurar que “cuadrado” sea invocado apropiadamente. La pregunta importante es quien es responsable de hacer esto. La precondición hace explícito que es el llamador el responsable de la verificación. Sin esta sentencia de responsabilidades explícita podríamos hacer muy poca verificación (porque ambas partes asumen que la otra es la responsable) o mucha (ambas verifican). Mucha verificación es algo malo, porque lleva a código duplicado lo cual puede incrementar la complejidad de un programa. Ser explícito sobre quien es responsable ayuda a reducir esta complejidad. El peligro de que el llamador se olvide de verificar es reducido por el hecho de que las aserciones son revisadas durante la depuración y las pruebas. De estas definiciones de precondición y poscondición se puede ver una definición fuerte del término exception (excepción), que ocurre cuando una operación es invocada con su precondición satisfecha, pero no puede regresar con su poscondición satisfecha. Un invariante es una aserción acerca de una clase. Por ejemplo, una clase Cuenta puede tener un invariante que dice que balance == suma(entradas.cantidad()). El invariante es “siempre” verdadero para todas las instancias de la clase. Aquí, “siempre” significa “cuando el objeto se encuentra disponible para tener una operación invocada en él.” En esencia, esto significa que el invariante es añadido a las precondiciones y poscondiciones asociadas con todas las operaciones públicas de la clase dada. El invariante puede llegar a ser falso durante la ejecución de un método, pero debe ser regresado a su estado verdadero cuando cualquier otro objeto quiera hacer algo con el receptor. Las aserciones juegan un papel único en la generalización. Uno de los peligros del polimorfismo es que se podría redefinir una operación en una subclase que sea inconsistente con la operación de la

Página 226

Análisis y Diseño de Sistemas con el UML

superclase. Las aserciones no permiten esto. Los invariantes y poscondiciones de una clase se deben aplicar a todas las subclases. Las subclases pueden fortalecer estas aserciones, pero no debilitarlas. Por otro lado, la precondición no puede ser fortalecida pero si debilitada. Esto parece extraño al inicio, pero es importante para permitir enlaces dinámicos. Debe ser capaz de tratar siempre un objeto de la subclase como si fuera una instancia de la superclase (polimorfismo). Si una subclase fortaleciera su precondición, entonces una operación de la superclase podría fallar en la subclase. Esencialmente, las aserciones pueden solamente incrementar las responsabilidades de la subclase. Las precondiciones son una sentencia de un paso de responsabilidad al llamador; se incrementan las responsabilidades del receptor debilitando las precondiciones. En la práctica, esto permite mucho mejor control de la generalización y ayuda a asegurar que las subclases se comportan apropiadamente. Idealmente, las aserciones deberían ser incluidas en el código como parte de la definición de la interfaz. Los compiladores deberían ser capaces de activar la verificación de las aserciones para la depuración y removerla para el código de producción. Varias etapas de verificación de aserciones pueden ser usadas. Las precondiciones a menudo dan las mejores oportunidades para atrapar errores con el menor aumento de procesamiento. El diseño por contrato es una técnica útil que debe usar cuando programe. Es de particular utilidad en construir interfaces claras. Solamente Eiffel soporta aserciones como parte del lenguaje, pero no es un lenguaje ampliamente usado. Es bastante directo añadir mecanismos para algunas aserciones en C++ y Smalltalk, pero un poco complejo para Java. El UML no habla mucho de las aserciones, pero pueden ser usadas sin problema. Los invariantes son equivalentes a reglas de restricciones en los diagramas de clase, y debe usarlas tanto como sea posible. Las precondiciones y poscondiciones de las operaciones deben ser documentadas dentro de la definición de las operaciones19 .

Vea: Sitio Web de la compañía ISE en http://www.eiffel.com. Bertrand Meyer: Object-Oriented Software Construction. Prentice Hall, 1997 Kim Walden y Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analisis and Design of Reliable Systems. Prentice Hall, 1995. Steve Cook y John Daniels: Designing Object Systems: Object-Oriented Modeling with Syntropy. Prentice Hall, 1994.

Anexo D: Comparando el UML con otros lenguajes de modelaje UML y otros Lenguajes de Modelaje

Actualizรกndose de OMT

Anexo D: Comparando el UML con otros lenguajes de modelaje

Página 229

UML y otros Lenguajes de Modelaje Debería estar claro que el Lenguaje de Modelaje Unificado no es una separación radical del método de Booch, OMT, o OOSE, sino el sucesor legítimo de los tres. Esto significa que si hoy usted es un usuario de OMT de Booch o OOSE, su entrenamiento, experiencia, y herramientas serán preservadas, porque el Lenguaje de Modelaje Unificado es un paso evolutivo natural. El UML será igualmente fácil de adoptar para los usuarios de muchos otros métodos, pero sus autores deben decidir por sí mismos si adoptar la notación y los conceptos del UML bajo sus métodos. El Lenguaje de Modelaje Unificado es más expresivo, más limpio y más uniforme que Booch, OMT, OOSE y otros métodos. Esto significa que hay valor en cambiarse hacia el UML, porque permitirá en los proyectos el modelaje de cosas que antes no se podían. Los usuarios de la mayoría de otros métodos y lenguajes de modelaje ganarán valor cambiándose al UML, porque elimina las diferencias necesarias en notación y terminología que oscurecen las similitudes de la mayoría de estas aproximaciones. Con respecto a otros lenguajes de modelaje visual, incluyendo modelaje entidad relación, diagramas de flujo BPR, lenguajes conducidos por estados, el UML proporciona expresividad e integridad mejorada. Una pregunta frecuente es ¿Por qué el UML no soporta diagramas de flujo de datos? Para ponerlo de forma simple, los diagramas de flujo de datos y otros tipos de diagramas que no fueron incluidos en el UML no se adecuan limpiamente a un paradigma consistente orientado a objetos. Los diagramas de actividades realizan mucho de lo que la gente busca en los diagramas de flujos de datos, y aún más; los diagramas de actividades son también útiles para modelar flujo de trabajo. Los autores del UML están claramente promoviendo los diagramas del UML sobre todas las otras formas para proyectos orientados a objetos, pero no condenan necesariamente a todos los otros diagramas. Los usuarios de los métodos existentes experimentarán cambios ligeros en la notación, pero esto no debe tomar mucho aprendizaje y traerá una clarificación de las semánticas subyacentes. Si las metas de la unificación han sido alcanzadas, el UML será una elección obvia cuando se inicien proyectos nuevos, especialmente a medida que la disponibilidad de libros, herramientas y capacitación aumente. Muchas herramientas de modelaje visual soportan notaciones existentes, tales como Booch, OMT, OOSE y otras; cuando estas herramientas añadan soporte para UML los usuarios gozarán los beneficios de cambiar sus modelos actuales a la notación UML sin pérdida de información. Los usuarios existentes de cualquier método orientado a objetos pueden esperar una curva de aprendizaje rápida para alcanzar la misma expresividad que previamente conocían. Uno puede aprender y usar las bases productivamente. Las técnicas más avanzadas, como el uso de estereotipos y propiedades requerirá cierto estudio, porque permiten la elaboración de modelos muy expresivos y precisos, que se necesitan solamente cuando el problema lo requiere. Los objetivos de la unión de esfuerzos fueron mantener la simplicidad, eliminar elementos de OMT, Booch, y OOSE que no trabajaban en la práctica, y agregar elementos de otros métodos que eran más efectivos, e inventar nuevos elementos solamente cuando no estaba disponible una solución existente. Debido a que los autores del UML estaban en efecto diseñando un lenguaje (aunque uno gráfico), ellos tenían que lograr un balance apropiado entre minimización (todo es texto y cajas) y sobreingeniería (tener un icono para cada elemento concebible). Para ese fin, ellos fueron muy cuidadosos al agregar cosas nuevas, porque no querían hacer al UML complejo innecesariamente. Sobre la marcha, de

Página 230

Análisis y Diseño de Sistemas con el UML

cualquier modo, se encontraron algunas cosas ventajosas de agregar porque habían probado ser útiles en la práctica en otro lenguaje de modelaje. Hay varios conceptos nuevos que están incluidos en el UML, incluyendo mecanismos de extensibilidad: Estereotipos, valores agregados, y restricciones; hilos y procesos; distribución y concurrencia (por ejemplo para modelar ActiveX/DCOM y CORBA); patrones/colaboraciones; diagramas de actividades (para el modelaje de procesos del negocio); refinamiento (manejar relaciones entre los niveles de abstracción); interfaces y componentes; y lenguaje de restricciones. Muchas de estas ideas estaban presentes en varios métodos individuales y teorías pero el UML los reúne en una totalidad coherente. Además de estos cambios mayores, hay muchas otras mejoras localizadas sobre la semántica y la notación de OMT, Booch, y OOSE. El UML es una evolución del OMT, Booch, OOSE y varios otros métodos orientados a objetos, y muchas otras fuentes. Estas fuentes variadas incorporaron muchos elementos diferentes de muchos autores, incluyendo influencias no orientadas a objetos. La notación del UML es una mezcla de la sintaxis gráfica de fuentes variadas, con una variedad de símbolos eliminados (porque eran confusos, superfluos, y poco usados) y con algunos símbolos nuevos agregados. Las ideas en el UML vienen de la comunidad de ideas desarrolladas por muchas personas diferentes en el campo de orientación a objetos. Los desarrolladores del UML no inventaron la mayoría de estas ideas; en vez de ello, su función fue la de seleccionar e integrar las mejores ideas de la orientación a objetos y las prácticas de la ciencia de la computación. La genealogía actual de la notación y de la semántica subyacente detallada es complicada, de modo que es discutida aquí solamente para brindar un contexto, no para representar una historia precisa. Los Diagramas de Casos de Uso son similares en apariencia a aquellos en OOSE. Los Diagramas de Clases son una mezcla de los diagrama de clase de OMT, Booch y de otras metodologías orientadas a objetos. Las extensiones (ej: estereotipos y sus iconos correspondientes) pueden ser definidos para varios diagramas para soportar otros estilos de modelaje. Los estereotipos, restricciones y valores agregados son conceptos añadidos en el UML que no existían previamente en los lenguajes de modelaje mayores. Los diagramas de estados están basados sustancialmente en los estados de David Harel con modificaciones menores. El diagrama de actividades, que comparte mucha de la misma semántica subyacente, es similar a los diagramas de flujo de trabajo desarrollados por muchas fuentes incluyendo fuentes previas a la orientación a objetos. Los diagramas de secuencia se encontraban en una variedad de métodos orientados a objetos bajo una variedad de nombres (interacción, trazo de mensajes y trazo de eventos) y datan de antes de la orientación a objetos. Los diagramas de colaboración fueron adaptados de Booch (diagrama de objeto), Fusion (gráfico de interacción de objetos), y un número de otras fuentes. Las colaboraciones son entidades de modelaje de primera clase, y a menudo son la base para los patrones. Los diagramas de implementación (diagramas de componentes y despliegue) son derivados de los diagramas de módulo y proceso de Booch, pero son están ahora centrados en componentes, en vez de en módulos y están mejor interconectados.

Anexo D: Comparando el UML con otros lenguajes de modelaje

Página 231

Los estereotipos son uno de los mecanismos de extensión y extienden la semántica del metamodelo. Los iconos definidos por el usuario pueden ser asociados con estereotipos dados para adecuar el UML a procesos específicos. El Lenguaje de Restricción de Objetos (OCL) es usado por el UML para especificar las semánticas y es proporcionado como un lenguaje para expresiones durante el modelaje. OCL es un lenguaje de expresión que tiene sus raíces en el método Syntropy y ha sido influenciado por lenguajes de expresión en otros métodos como Catalysis. La navegación informal de OMT tiene el mismo fin, donde OCL es formalizado y más extensivo. Cada uno de estos conceptos tiene más predecesores y muchas otras influencias. El UML es el producto de una larga historia en las Ciencias de la Computación e Ingeniería de Software.

Actualizándose de OMT Proceso

La Técnica de Modelaje de Objetos (OMT) es un proceso y una notación para desarrollo orientado a objetos. Un paso de preparación es escribir u obtener la sentencia del problema y describir los problemas a solucionarse. Cuando la sentencia del problema es escrita, el OMT proporciona tres pasos primarios para definir y construir un sistema: análisis, diseño de sistemas, y diseño de objetos. Después de la etapa de diseño de objetos, los modelos pueden ser implementados con código de programación y, en algunos casos, un esquema de base de datos. El primer paso, análisis, es el modelaje de conceptos claves dentro del dominio del problema. Los conceptos claves son encontrados, o deben ser encontrados, en la sentencia del problema. El análisis es un plano usado para dos próximos pasos: diseño de sistemas y de objetos. El análisis proporciona tres modelos/vistas diferentes del sistema: un modelo de objetos, un modelo dinámico, y un modelo funcional. Los resultados del análisis son diagramas de modelo de objetos, diagramas de estados, diagramas de flujo de eventos, y diagramas de flujo de datos. Los pasos en el análisis son: 1. 2. 3. 4. 5.

Escribir u obtener la sentencia del problema. Construir un modelo de objetos (diagrama de modelo de objetos). Desarrollar un modelo dinámico (diagrama de estados y diagramas de flujo de eventos). Construir un modelo funcional (diagrama de flujo de datos). Verificar, iterar, y refinar los tres modelos (objeto, dinámico y funcional).

En OMT, el diagrama de modelo de objetos y el diagrama de estados corresponden a los diagramas de clases y de estados en el UML. El diagrama de flujo de datos no tiene diagrama correspondiente en el UML, pero el diagrama de actividades puede ser usado para tipos similares de modelos (aunque no exactamente los mismos). Un diagrama de flujo de eventos corresponde a un diagrama de secuencia en el UML. Después que la etapa de análisis está completa, el diseño del sistema comienza y se concentra en la arquitectura global del sistema. Los pasos son: 1. Organizar el sistema en subsistemas. Dividir el modelo en paquetes. El subsistema del UML hace esto. 2. Identificar la concurrencia presente en los problemas. El UML maneja la concurrencia con los diagramas de colaboración.

Página 232

Análisis y Diseño de Sistemas con el UML

3. Asignar los subsistemas a procesadores y tareas. El diagrama de despliegue y el diagrama de componentes dentro del UML son usados para modelar procesadores y tareas. 4. Escoger las estrategias básicas para implementar los almacenamientos de datos. 5. Determinar los mecanismos para controlar el acceso a los recursos globales. 6. Implementar control de software. 7. Manejar situaciones de frontera. 8. Establecer prioridades. Los estereotipos son usados para indicar que algunas clases son usadas para manejar recursos globales, almacenamiento de datos, y así sucesivamente. El paso final es el diseño de objetos, donde todos los modelos son completamente especificados y la base para la programación es creada. Los pasos son: 1. Extraer operaciones de los modelos dinámicos y los modelos funcionales. Desde una perspectiva del UML, las operaciones son identificadas de las interacciones que son o pueden ser expresadas en diagramas de secuencia (diagramas de flujo de eventos en OMT), diagramas de colaboración, o diagramas de actividades (los cuales son similares a los diagramas de flujo de datos dentro del OMT). 2. Diseñar algoritmos para implementar las operaciones. 3. Optimizar las vías hacia los datos. 4. Implementar control de software. 5. Ajustar la estructura de las clases para incrementar la herencia. 6. Diseñar la implementación de asociaciones y agregaciones. 7. Determinar la representación en atributos de tipos, valores por defecto, etc. 8. Agrupar las clases y asociaciones en módulos. El UML hace esto con diagramas de componentes. Como se puede observar, casi todo lo expresado en la notación de OMT puede ser expresado en el UML. Sin embargo, algunos de los conceptos que en el OMT no tienen notación la tienen en el UML, como los componentes y los nodos. Los diagramas de flujo de datos no son parte del UML, pero se pueden manejar especificaciones similares con un diagrama de actividades. La diferencia principal entre la notación de OMT y el UML es en como son ilustradas las interacciones. OMT muestra las interacciones con dos puntos focales: datos y eventos; el UML muestra las interacciones con tres puntos focales: tiempo (diagrama de secuencia), espacio (diagrama de colaboración), y trabajo (diagrama de actividades). OMT tiene un principio por el cual las operaciones son identificadas y definidas mediante los modelos de interacción (flujo de datos y eventos). Este principio es mantenido en el UML pero con una perspectiva diferente en la interacción. Sin embargo, esta diferencia no es significante, pues las descripciones de los flujos de datos son tomadas con parte del flujo de trabajo descrito en un diagrama de actividades. Notación

Las siguientes figuras muestran las diferencias básicas entre la notación de OMT y el UML. Los símbolos de OMT se encuentran a la izquierda y los símbolos correspondientes del UML a la derecha.

Anexo D: Comparando el UML con otros lenguajes de modelaje

Figura 125: Clase

Figura 126: Operaciรณn abstracta

Figura 127: Miembro estรกtico (atributo al nivel de clase en el UML)

Figura 128: Objeto

Pรกgina 233

Página 234

Análisis y Diseño de Sistemas con el UML

Figura 129: Enlace

Figura 130: Asociaciones, multiplicidad, nombre, calificador y rol

Figura 131: Asociación y atributo derivados

Anexo D: Comparando el UML con otros lenguajes de modelaje

Figura 132: Subconjunto de una asociaciรณn

Figura 133: Agregaciรณn

Figura 134: Asociaciรณn ternaria

Figura 135: Objeto enlazado (clase en asociaciรณn en el UML)

Pรกgina 235

Página 236

Análisis y Diseño de Sistemas con el UML

Figura 136: Discriminador y generalización

Figura 137: Restricciones en objetos

Figura 138: Estado

Figura 139: Transición de estado

Figura 140: Puntos de inicio y final en los diagramas de estados

Anexo D: Comparando el UML con otros lenguajes de modelaje

Figura 141: Subestados concurrentes (subestados “y” en el UML)

Figura 142: División de control

Figura 143: Mensaje entre diagramas de estados

Página 237

Anexo E: Modelaje Dinรกmico Avanzado: Sistemas de Tiempo Real Orientaciรณn a Objetos y los Sistemas de Tiempo Real

Conceptos de Tiempo Real

Modelaje de Tiempo Real en el UML

Adaptรกndose a los Sistemas de Tiempo Real

Problemas de los Procesos

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 241

lgunos entre el amplio rango de sistemas que pueden ser modelados con el UML son los sistemas de tiempo real. No hay una definición establecida de lo que realmente constituye un sistema de tiempo real, pero intuitivamente es un sistema en el cual el tiempo es muy importante. El sistema debe manejar los eventos externos dentro de límites de tiempo restringidos, la ejecución es concurrente, y el rendimiento del sistema a menudo necesita ser optimizado (el sistema debe ser “rápido”). Dentro de este amplio rango de definiciones, la mayoría de los sistemas pueden ser considerados de alguna forma sistemas de tiempo real, y por eso necesitan tener especificaciones de tiempo y restricciones identificadas en su modelaje. La siguiente figura muestra un sistema de tiempo real:

Figura 144: Sistema de tiempo real

Donde es importante el lineamiento del tiempo: El sistema desempeña sus funciones dentro de límites de tiempo especificados (“tiempo de respuesta”). Todas las líneas muertas de tiempo deben ser encontradas.

Es reactivo: El sistema responde continuamente a los eventos del ambiente externo que “conducen” la ejecución del sistema.

Con hilos de ejecución de control, donde las diferentes partes corren en paralelo: La ejecución concurrente puede ser realizada en sistema en paralelo “real” con varios procesadores; cada hilo se ejecuta en su propio procesador. Alternativamente, puede ser realizado en un ambiente simulado con un solo procesador, pero el sistema operativo en tiempo real calendariza los hilos para que compartan el procesador (les pasa el control a ellos uno a la vez). La concurrencia permite una utilización eficiente del hardware y es utilizada en la creación de buenos modelos de los sistemas donde los eventos externos ocurren asincrónicamente.

Página 242

Análisis y Diseño de Sistemas con el UML

Con altos requerimientos de la mayor parte de los requerimientos no funcionales tales como confiabilidad, tolerancia a fallas, y rendimiento

No determinísticos: Es imposible probar formalmente que el sistema trabajará en todas las situaciones bajo todas las condiciones, debido a la complejidad de la concurrencia, los eventos asincrónicos externos que pueden ocurrir en cualquier orden, y el hardware implicado.

Los modelos de los sistemas de tiempo real necesitan especificaciones de requerimientos de tiempo, manejo de eventos asincrónicos, comunicación, concurrencia, y sincronización. Debido a que los sistemas de tiempo real son a menudo distribuidos, los modelos deben mostrar la distribución del sistema. Los diagramas más afectados por los aspectos de un sistema de tiempo real son los diagramas del modelo dinámico tales como los diagramas de secuencia y de colaboración, donde pueden ser agregadas las especificaciones de concurrencia y de tiempo. Es, sin embargo importante entender que aún los sistemas de tiempo real más especializados también tienen una estructura estática que tiene que ser modelada utilizando los diagramas (tales como los diagramas de clases y los diagramas de despliegue). Un diagrama de tiempo real es a menudo altamente integrado con su ambiente físico, en el cual recibe los eventos y la información a través de sensores y dispositivos de control a través de actores. Por esto a menudo un sistema de tiempo real trabaja cercanamente con hardware especializado y tiene que manejar interruptores de bajo nivel e interfaces de hardware. Un sistema que implica un hardware y software integrado y especializado es llamado un sistema empotrado. Los sistemas empotrados pueden ser encontrados en los autos, consumidores electrónicos, maquinas de manufactura, y muchos otros. Un sistema de tiempo real empotrado a menudo utiliza un pequeño sistema operativo de tiempo real que puede ser montado fácilmente en un sistema con capacidad de memoria limitada. Un sistema empotrado deber ser lo suficientemente rápido para comunicarse y controlar su hardware, manejar y reaccionar a todos los eventos que ocurran, aún en la situación del peor de los casos (donde todo ocurre a la vez). Los sistemas de tiempo real a menudo se dividen en la categoría rígidos y suaves. En un sistema de tiempo real rígido, una respuesta tardía (o incorrecta) es considerada un error inaceptable que puede resultar la pérdida de la vida. Ejemplos de sistemas de tiempo real rígidos son los sistemas de control de aeroplanos, sistemas de supervivencia de vida, sistemas automáticos de control de trenes. Los sistemas de tiempo real suaves pueden aceptar ocasionalmente una respuesta tardía; por ejemplo, en un sistema telefónico digital, puede tomarse un largo tiempo para conectar una llamada, o la conexión puede fallar; en ninguno de los escenarios es considerado un error serio o peligroso. Obviamente, entonces, las demandas son cada vez mayores cuando se diseñan los sistemas de tiempo real, especialmente los sistemas rígidos de tiempo real. Los sistemas deben ser tolerantes a fallas, lo que significa que los errores excepcionales de hardware y software deben ser manejados por el sistema y que bajo ninguna el sistema puede volverse inoperable. Las excepciones y los errores que puedan ocurrir deben ser manejados (“esperar lo inesperado”). Para ser capaz de manejar las peores situaciones de muchos eventos ocurriendo al mismo tiempo, el rendimiento debe ser optimizado y entonado de manera tal que haya una gran reserva que pueda ser utilizada cuando sea necesario.

Orientación a Objetos y los Sistemas de Tiempo Real Una interrogante común sobre el modelaje orientado a objetos es si la orientación a objetos puede ser utilizada realmente para modelar sistemas de tiempo real. Dada las grandes demandas de rendimiento de los sistemas de tiempo real y las consideraciones de que los objetos son solamente datos

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 243

almacenados en bases de datos relacionales, muchos darían una respuesta escéptica a esta interrogante. Claramente, dada la complejidad de los sistemas de tiempo real, la necesidad de diseñar modelos precisos y descriptivos es más importante que en los sistemas normales. Pero a medida que el lenguaje de modelaje soporte los conceptos tradicionales orientados a objetos y los conceptos de tiempo real, la orientación a objetos y de tiempo real se combinan muy bien. Existen problemas de implementación, tales como el que el ambiente subyacente tenga el soporte adecuado para las construcciones de tiempo real (procesos o hilos, y mecanismos de comunicación y sincronización). Hay también veces cuando la implementación de un modelo debe ser optimizada, para permitir un máximo rendimiento. Esto es el caso típico cuando hay muchas capas de abstracción, lo cual resulta en un costo de rendimiento con mucha comunicación entre una serie de objetos para manejar un evento específico. En tal situación, deben ser tomados atajos de implementación en conflicto con el modelo ideal (usualmente al costo de obtener un sistema más complejo y más difícil de mantener). Como se ha mencionado, un sistema de tiempo real orientado a objetos requiere de un sistema operativo que soporte construcciones de tiempo real. El sistema operativo puede ser un sistema operativo estándar tal como Windows, OS/2 o Unix, o un sistema operativo de tiempo real optimizado para sistemas empotrados de tiempo real. La calidad de los servicios en tiempo real (rendimiento, confiabilidad, facilidad de programación) depende del sistema operativo utilizado, y no es realmente una propiedad del lenguaje o método orientado a objetos. La orientación a objetos es utilizada para modelar los sistemas que están en construcción, y para mapear esos modelos en los servicios proporcionados por el sistema operativo. Naturalmente, la calidad del diseño orientado a objetos afecta la calidad del sistema terminado. Los principios primarios introducidos cuando modelamos sistemas con ejecución concurrente es aquel de las clases activas. Un objeto de una clase activa (un objeto activo) puede ejecutar sus propios hilos de control, y por ello tomar la iniciativa de realizar acciones sin que le haya sido enviado un mensaje. En los sistemas con varios objetos activos, varios hilos de control se estarán ejecutando concurrentemente. Esto introduce nuevos problemas por manejar, tal como la comunicación entre los objetos activos y su sincronización cuando comparten recursos. El opuesto de una clase activa es una clase pasiva, la cual es la clase “normal.” Un objeto de una clase pasiva se ejecutará solo cuando sea enviado un mensaje (ejemplo cuando es llamada una operación); y cuando la operación retorna, devolverá de nuevo el control al que la llama. Un sistema de tiempo real es una mezcla de objetos activos y pasivos. La concurrencia en los sistemas de tiempo real orientado a objetos puede ser visualizada a través del modelo de concurrencia implícita y explícita. El modelo de concurrencia explícita describe la concurrencia separadamente de los objetos, definiendo los procesos en las primeras etapas del análisis. El sistema es descompuesto en una serie de procesos, y cada proceso es internamente modelado como un sistema orientado a objetos para diseñar la estructura interna (naturalmente, las clases puede ser reutilizadas en varios procesos). Los conceptos de procesos y objetos son separados, y el sistema es dividido en procesos donde cada proceso es modelado internamente como un sistema orientado a objetos de sí mismo. El modelo de concurrencia implícita retrasa el diseño de concurrencia. El sistema es modelado como objetos, donde en un análisis temprano, se considera que todos los objetos poseen sus propios hilos de ejecución; esto es, ser objetos activos (o, una variante, solamente aquellos objetos marcados explícitamente como activos tienen sus propios hilos de ejecución). Gradualmente, a través de la arquitectura y del diseño detallado, los modelos ideales de análisis son mapeados en la implementación con soporte de servicios del sistema operativo de tiempo real subyacente. En la

Página 244

Análisis y Diseño de Sistemas con el UML

implementación final, solamente son implementados como activos aquellos objetos que se necesitan. A pesar de que el UML puede soportar modelos de concurrencia implícita y explícita, tiene un mejor soporte para el modelo de concurrencia implícita. Las clases activas, asincrónicas, la comunicación y sincronización pueden ser modeladas en las fases tempranas y gradualmente traducidas en los servicios y capacidades del ambiente de implementación. El manejo del hardware es realizado típicamente a través de clases de envoltura de hardware; las cuales son diseñadas para presentar interfaces al hardware y para modelar las capacidades del hardware. Estas envolturas de hardware mantienen el protocolo de comunicación para el dispositivo y las interrupciones que pueda generar el dispositivo. La utilización de tales clases de hardware permite que sea escondido el protocolo de bajo nivel, y que una interrupción de bajo nivel sea rápidamente traducida en un evento de un nivel más alto en el resto del sistema. Dependiendo de la naturaleza del hardware, una clase de envoltura puede ser una clase activa o pasiva.

Conceptos de Tiempo Real En esta parte hablaremos sobre los mecanismos básicos para el modelaje de sistemas de tiempo real en el UML. Los mecanismos presentados son las definiciones de las clases activas y los objetos (concurrencia), comunicación entre los objetos activos, y la sincronización de los objetos activos como se muestra en la siguiente figura:

Figura 145: Los diferentes mecanismos para modelar sistemas de tiempo real

Clases Activas y Objetos

Las clases activas son utilizadas para modelar el comportamiento concurrente del mundo real, y para crear un modelo que utilice los recursos del sistema tan eficientemente como sea posible. Una clase activa es aquella que posee su propio hilo de ejecución y puede iniciar una actividad de control. Una clase activa (o actualmente una instancia de la clase activa, un objeto activo) se ejecuta en paralelo con otros objetos activos e inician sesiones por sí mismos (en su propio código o enviando mensajes a otros). Entonces una clase activa es la “unidad” que se ejecuta concurrentemente. En contraste a las clases activas están las clases pasivas, que son todas las clases “normales” en el sistema. Un objeto pasivo (de una clase pasiva) es capaz de ejecutarse solamente cuando algún otro objeto (pasivo o activo) realiza alguna operación sobre él (le envía algún mensaje a él). Una clase activa es implementada como un proceso o un hilo. Un proceso es un hilo de control de “peso pesado”; un hilo es un hilo de control de “peso ligero.” La diferencia importante entre un proceso y un hilo es que un proceso normalmente encapsula y protege toda su estructura interna ejecutándose en su propio espacio de memoria, mientras que un hilo se ejecuta en un espacio de memoria compartido con otros hilos; este espacio de memoria puede contener información compartida (tal como otros objetos). Un proceso es iniciado por un programa ejecutable, y puede ser visto como

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 245

un sistema en sí mismo. Note que en algunos sistemas operativos, un proceso es equivalente a un hilo, de modo que estas definiciones de proceso e hilo deberían de ser tomados como una guía más que literalmente. Los conceptos pueden también ser combinados, de modo tal que dentro de un proceso, se ejecutan una serie de hilos y comparten espacio de memoria. Las clases activas son típicamente implementadas a través de librerías de clases que tienen una superclase, ActiveClass. Esta superclase es heredada por todas las subclases que deberían ser activas, y contiene un mapeo de los procesos o operaciones de hilos tales como inicio, parada, suspender, resumir, manejo de prioridad, y así sucesivamente que corresponden a llamadas del sistema operativo que implementa esas funciones en el sistema operativo subyacente. Normalmente, una operación abstracta llamada run (ejecutar) en la superclase debe ser implementada en la subclase activa concreta. La implementación de esta operación especifica el código del hilo de ejecución de la clase activa; esto es, el código que se ejecuta en paralelo con otros hilos de ejecución. Típicamente la operación run se ejecuta en un ciclo infinito, leyendo señales de entrada o interactúando con mecanismos de sincronización y realizando el trabajo de las clases activas. Los objetos activos interactúan a través de mecanismos de comunicación y sincronización. El mecanismo de comunicación puede ser una operación ordinaria de llamada entre los objetos (mensajes sincrónicos en el mundo orientado a objetos; o el mecanismo de comunicación puede ser el soportado por el sistema operativo, tal como cajas de correo o colas donde los mensajes o señales pueden ser enviados o recibidos asincrónicamente. Los mecanismos de sincronización son técnicas utilizadas para controlar la ejecución hilos concurrentes, para prevenir los conflictos o la utilización ineficiente de los recursos (ejemplo, múltiples hilos utilizando el mismo recurso concurrentemente, o un consumidor tratando de leer y trabajar sobre la misma información antes que de que el productor haya terminado de proporcionar la información). Los objetos activos son usualmente más grandes que los objetos pasivos, porque ellos contienen o hacen referencia a una serie de otros objetos. A veces un paquete (el equivalente del UML de un subsistema) es controlado a través de un objeto activo que hace que el paquete se ejecute concurrentemente con otros paquetes. Sin embargo, es importante darse cuenta que aún en un sistema de tiempo real rígido, hay muchos más objetos pasivos que objetos activos. Un costo es asociado con la creación de hilos de procesos, y el sistema se volverá excesivamente complejo y lento si son definidos muchos objetos activos. Una clase activa (u objeto) es mostrada en el UML como un rectángulo de clase u objeto dibujado con una línea gruesa. Si el nombre dentro rectángulo contiene al nombre de una clase, el símbolo representa a una clase activa; si el nombre es un objeto subrayado, el símbolo representa un objeto activo. La clase es del estereotipo “ActiveClass,” el cual debería ser visible cuando la clase es mostrada en el diagrama de clase. Veamos la siguiente figura:

Figura 146: Una clase activa y un objeto de esa clase activa

Una clase activa u objeto es desplegada a menudo con su estructura interna empotrada. Utiliza de forma típica varias otras clases para definir su estructura interna. Estas clases internas son normalmente pasivas, pero pueden ser otras clases activas. Veamos la siguiente figura:

Página 246

Análisis y Diseño de Sistemas con el UML

Figura 147: Un objeto activo con su estructura interna en términos de otros objetos activos y pasivos

Estados de una Clase Activa

Una clase activa a menudo cambia su comportamiento dependiendo de algún estado interno (o en algunos casos, del estado total del sistema). Los estados de una clase activa y su comportamiento son modelados en el diagrama de estados, el cual muestra los posibles estados de una clase activa – cuáles eventos son aceptados en cada estado y las transiciones y acciones realizadas cuando ocurre un evento específico. Las restricciones de tiempo no son mostradas en el diagrama de estado, excepto quizás como notas. En la siguiente figura se muestra un diagrama de estado con las características antes mencionadas:

Figura 148: Estados de un objeto activo con los eventos que causan transiciones

Comunicación

Cuando los objetos pasivos se comunican unos con otros, esto se hace normalmente a través de operaciones (envío de mensajes sincrónicos). Un objeto llama en una operación (envía mensajes a) otro objeto, y el objeto que llama espera que la operación se ejecute y tiene de vuelta el control cuando es realizada la operación (posiblemente acompañada con el valor de retorno de la operación). Como parte de la llamada de la operación, los datos pueden ser pasados entre los objetos como parámetros. Una serie de mecanismos pueden ser utilizados para permitir a los objetos activos comunicarse unos con otros. Los objetos activos deben ser capaces de ejecutarse concurrentemente y enviar mensajes a otros objetos activos sin tener que esperar a que finalice la operación. Algunos de los mecanismos utilizados más comunes cuando se da la comunicación de los objetos activos son:

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 247

Llamadas de Operaciones: Es una llamada ordinaria de una operación en un objeto. Esto es el equivalente de enviar un mensaje sincrónico a un objeto, donde el que llama espera que la operación termine y retorne.

Buzones de Correo/Colas de mensajes: Es una técnica que define buzones de correo o pilas de mensajes. Un mensaje es puesto en un buzón de correo por el que lo envía, y en algún punto es leído y manejado por el que lo recibe. Esta técnica se permite para los mensajes asincrónicos; el que lo envía puede poner un mensaje en el buzón de correo e inmediatamente seguir ejecutándose.

Memoria Compartida: Un bloque de memoria es reservado para la comunicación, de manera que dos o más objetos activos puedan leer y escribir información. El bloque tiene que ser guardado por algún tipo de mecanismo de sincronización de modo que los objetos que se ejecutan concurrentemente no traten de leer y/o leer la información al mismo tiempo. La técnica de la memoria compartida es utilizada normalmente cuando una gran estructura de datos debe ser trabajada por varios objetos.

Puntos de Encuentro: Es una técnica por la cual son definidos los puntos específicos de encuentro en la ejecución de dos hilos. El primer hilo alcanza su punto de encuentro de parada y espera que otro hilo alcance su correspondiente punto de encuentro. Cuando ambos hilos están en el punto de encuentro, intercambian información y luego comienzan a ejecutarse concurrentemente de nuevo.

Llamadas a Procedimientos Remotos (RPCs): Las RPCs administran la distribución de los hilos concurrentes para computadoras separadas en una red y permite que los hilos sean escritos en diferentes lenguajes. Los hilos que llaman identifican una operación en el objeto que quieren llamar, luego realizan esta petición a la librería RPC. El RPC encuentra al objeto en la red, empaqueta la petición en un formato universal y envía la petición a toda la red. En el lado en que se recibe, la petición es traducida del formato universal al formato que quiere el objeto que la recibe, y la llamada es realizada. Cuando la llamada es finalizada, el resultado es enviado de forma similar. Es por esto, que las RPC son mecanismos de comunicación y sincronización.

Los mecanismos descritos aquí son técnicas de implementación que son mapeadas a propiedades del sistema operativo. En el modelaje, la comunicación entre objetos activos es descrita utilizando eventos, señales, y mensajes. No es hasta la fase de diseño que son escogidas las técnicas de implementación actuales. La comunicación puede ser asincrónica o sincrónica. La comunicación asincrónica es impredecible; esto es, que un evento puede ocurrir en cualquier momento durante la ejecución del sistema, y no es posible saber cuándo será enviado un evento específico. La comunicación sincrónica es predecible en que esto puede ocurrir solamente en tiempos especificados en la ejecución del sistema (lo cual puede ser identificado leyendo el flujo de control en el código). Un sistema de tiempo real utiliza tanto comunicación sincrónica como asincrónica. Típicamente, los eventos externos en el ambiente ocurren asincrónicamente, mientras que partes de la comunicación interna en el sistema son sincrónicas. Cuando discutimos el envío de mensajes entre los objetos, la comunicación sincrónica y asincrónica vienen para indicarnos si el objeto emisor espera que el mensaje sea tomado (envío de mensajes sincrónico) o no (envío de mensajes asincrónico). Eventos

En un sistema de tiempo real, los eventos son los conductores de la actividad del sistema. Un evento es algo que ocurre en un sistema o en el ambiente, y algo a lo que el sistema debe reaccionar y manejar. Todos los eventos que puedan ocurrir deben ser definidos; aún más, debe ser definido el

Página 248

Análisis y Diseño de Sistemas con el UML

comportamiento del sistema cuando ocurre un evento. El comportamiento es a menudo conectado al estado de un objeto en el cual el mismo evento puede causar diferentes comportamientos dependiendo del estado del objeto cuando ocurre el evento. Un evento puede también causar una transición de un estado a otro. En el UML, existen cuatro categorías diferentes de eventos:

Una condición que se vuelve verdadera: Una condición de espera que se vuelve verdadera es considerada un evento. Esto es implementado típicamente a través de un objeto activo que monitorea esta condición y nota cuando se ha vuelto verdadera.

El recibo de una señal explícita de un objeto señal: Un objeto señal es enviado de un objeto a otro. El objeto señal, el cual es considerado un mensaje, es de una clase señal y puede contener atributos y operaciones. Los objetos señales son típicamente a través de algunos mecanismos de sistemas operativos, tales como buzones de correo o colas. Los objetos señales pueden ser enviados asincrónicamente.

El recibo de una llamada de operación: Un objeto llama a una operación en otro objeto. Esta llamada de operación, la cual es considerada un mensaje asincrónico, pasa información a través de parámetros y el valor de retorno.

Un pasaje de tiempo: Una cantidad especificada de paso de tiempo es también un evento, a veces llamado evento periódico. Tal evento es utilizado para describir un retraso intencional en el procesamiento o tiempos fueras si algún otro evento no ha ocurrido dentro de un tiempo especificado. Un evento pasaje de tiempo es implementado ya sea a través de una llamada a dormir, la cual suspende la ejecución del hilo por una cantidad específica de tiempo, o una petición al sistema operativo de un mensaje fuera de tiempo, el cual es enviado al objeto que hace la petición cuando ha terminado el tiempo especificado.

Los eventos pueden ser divididos en las categorías lógica y física. Un evento físico es de bajo nivel, al nivel del hardware; un evento lógico es una representación de un nivel más alto de esa ocurrencia. El evento físico “interrupción en el puerto 4H” podría ser traducido al evento lógico “alarma del dispositivo sensor de infrarrojo.” Debido a que los eventos lógicos son de un mayor nivel de abstracción, los modelos deberían ser preferiblemente definidos con eventos lógicos más que eventos físicos de bajo nivel. Los eventos físicos deberían ser traducidos en eventos lógicos tan cerca a su detección como sea posible (esto es realizado típicamente a través de un objeto activo con un diagrama de estado, el cual, dependiendo del estado actual, puede hacer una interpretación y traducción del evento físico en un evento lógico). Propiedades tales como la categorización de un evento, prioridad, requerimientos de manejo de tiempo, o información administrativa pueden ser definidas para los eventos. Para hacer esto, es a menudo conveniente definir el evento como una clase y definir esas propiedades como valores agregados de la clase; o, si la información es conectada a las instancias actuales, como atributos de la clase. Señales

Las señales son definidas en el UML como “un evento nombrado que puede ser creado.” Una señal es descrita como una clase con un estereotipo <<signal>> que representa a un evento que ocurre en el sistema. Debido a que la señal es descrita como una clase, puede tener atributos y operaciones que manejan la información y el comportamiento sobre el evento. Las señales son pasadas entre los objetos

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 249

en el sistema, ya sea sincrónicamente como asincrónicamente, y son mensajes (solamente los mensajes pasados entre los objetos que se comunican también contienen un objeto señal, y no es solamente una llamada a una operación). Las señales son descritas en los diagramas de clases, y todas las señales en un sistema de tiempo real son modeladas en una jerarquía, como se ilustra en la siguiente figura:

Figura 149: Jerarquía de clases señal

Esto hace posible agrupar una serie de señales teniendo una superclase común. Un receptor de una señal puede entonces especificar que acepta objetos de una superclase especificada, lo cual significa entonces que acepta objetos de señal de la superclase de cualquiera de sus subclases especializadas. Una superclase en tal jerarquía puede contener también información general sobre la señal, tal como prioridad, tiempo enviado, y así sucesivamente. Como las señales son un caso especial de eventos, pueden ser divididas en señales lógicas y físicas cargando ya sea información de hardware de bajo nivel o una interpretación de un nivel más alto de lo que significan los eventos en términos de la ejecución del sistema. Mensajes

Los objetos se comunican a través de mensajes; específicamente, los mensajes son utilizados para la comunicación de los objetos pasivos, entre objetos pasivos y activos, o entre objetos activos. Un mensaje es implementado por una simple llamada a una operación, o como un objeto señal que es puesto en un buzón de correo o una cola. La recepción de un mensaje es considerada normalmente un evento en un sistema de tiempo real. Los mensajes son mostrados en una serie de diagramas del UML – secuencia, colaboración, estado, y actividad – para ilustrar la comunicación entre los objetos. La siguiente figura muestra los tipos de mensajes en el UML.

Página 250

Análisis y Diseño de Sistemas con el UML

Figura 150: Tipos de mensajes en el UML

En esta figura podemos apreciar los tipos de mensajes que existen:

Simples: Representa un flujo de control. Un mensaje simple muestra cómo es pasado el control de un objeto a otro sin describir ningún detalle sobre la comunicación. Este tipo de mensaje es utilizado cuando los detalles sobre la comunicación no son conocidos o no son considerados relevantes en el diagrama. Es también utilizado para mostrar el retorno de un mensaje sincrónico; es dibujado desde el objeto emisor de vuelta el mensaje al que llama para mostrar que el control es devuelto (posiblemente junto con algún resultado).

Sincrónicos: Es un flujo anidado de control, típicamente implementado como una llamada a una operación. La operación que toma el mensaje es completada (incluyendo cualquier otros mensajes enviados como parte del manejo) antes de que el que llama termine la ejecución. El retorno puede ser mostrado en un diagrama de secuencia como un simple mensaje, o el retorno puede ser explícito cuando el mensaje ha sido manejado o recibido. Un mensaje sincrónico entre los objetos activos indica semánticas de espera; el emisor espera que el mensaje sea recibido antes de seguir ejecutándose (el emisor espera a que el receptor esté listo para recibirlo y espera que el receptor sepa que actualmente ha sido recibido).

Asincrónicos: Son los flujos de control asincrónicos donde no hay un retorno explícito al emisor. Un mensaje asincrónico entre los objetos indica que no hay semántica de espera; el emisor no espera que el mensaje sea recibido antes de seguir ejecutándose.

Los mensajes simples y los sincrónicos pueden ser combinados en una línea, con la flecha de mensaje sincrónica en un extremo y la flecha de retorno simple en el otro. Esto indica que el retorno de control es virtualmente inmediato. Otros tipos de mensajes son extensiones del UML básico, tal como un mensaje de obstáculo (un mensaje que es enviado solamente sí el receptor está listo para aceptarlo) y mensajes fuera de tiempo (el cual será cancelado sino es recibido en una cantidad especificada de tiempo). Estos tipos de mensajes y otras variantes similares son descritos como estereotipos de mensajes. Sincronización

La sincronización es el proceso de coordinar los hilos concurrentes de ejecución unos con otros, de modo que no puedan interferir inapropiadamente unos con otros (ejemplo, que no estén concurrentemente tratando de modificar o accesar recursos compartidos al mismo tiempo) y que ellos interactuen en un orden eficiente. La sincronización es necesaria en cualquier sistema que tenga concurrencia. No sólo nos referimos con esto a los objetos activos, sino también a todos los objetos pasivos que son compartidos entre los objetos activos.

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 251

Los problemas que pueden ocurrir si la sincronización no es manejada correctamente son:

Acceso compartido incorrecto: Los recursos o los objetos pasivos que son compartidos entre los objetos activos pueden causar problemas si son accesados concurrentemente. Si un hilo llama a una operación en un objeto pasivo, la operación puede ejecutar algunas líneas de código que ponen atributos en el objeto. En cualquier momento durante la ejecución de la operación, el hilo puede ser suspendido por el sistema operativo, el cual calendariza otros hilos para la ejecución. Este otro hilo llama a la misma o a otra operación en el mismo objeto, ahora un objeto que no está en un estado seguro (debido a que la última llamada a esa operación no ha finalizado todavía). Digamos que la operación que se ejecuta al final del primer hilo es entonces calendarizada concluyendo la ejecución en el punto donde fue suspendido. Los atributos del objeto han sido cambiados, y el resultado final de la operación es indeterminado. Lo cual se necesita es la exclusión mutua entre los hilos de modo que solamente un hilo a la vez ejecuta la operación y ningún otro hilo puede accesar la operación hasta que el primer hilo lo ha finalizado. El problema con el acceso compartido se refiere tanto a los objetos que son compartidos como los otros recursos compartidos (dispositivos tales como impresoras, puertos de comunicación, etc).

Uso ineficiente de los recursos: A menudo existen dependencias entre la ejecución de diferentes hilos. Un hilo puede depender de otro hilo para hacer alguna preparación de los datos que está utilizando. El primer hilo podría estar continuamente ejecutándose en un ciclo de espera ocupada, chequeando y chequeando de nuevo para determinar si el otro hilo ha sido finalizado. Esto es un gran desperdicio de los recursos de la máquina. Una mejor solución es tener un mecanismo de sincronización para coordinar el hilo con la preparación del hilo, para asegurarse que no está calendarizado para ejecutarse hasta se le notifique que el primer hilo ha finalizado su trabajo.

Punto Muerto: Un punto muerto ocurre cuando una serie de hilos todos ellos están esperándose unos a otros. Como un ejemplo, un sistema podría tener dos puertos de comunicación, A y B, controlados por algún mecanismo de sincronización. Los dos hilos (posiblemente dos instancias de la misma clase activa) en algún punto necesitan ambos puertos de comunicación. Un hilo se administra para reservar el puerto A, y el otro para reservar el puerto B. El primer hilo espera que el puerto B sea liberado, y el segundo hilo espera por el puerto A, mientras ninguno de ellos está liberando el puerto que han reservado. Esto es un punto muerto el cual detiene totalmente que el sistema continúe corriendo correctamente.

Inanición: Un problema de Inanición es cuando un hilo nunca se ejecuta. Esto ocurre cuando las prioridades de los hilos son definidas en tal forma que es imposible o es muy difícil para un hilo tomar el control. Consecuentemente, la tarea de un hilo nunca es realizada, lo cual conduce a otras dificultades.

Los mecanismos utilizados para sincronizar los hilos son conceptos tales como semáforos, monitores, o regiones críticas. Todos ellos comparten características comunes tales como que todos ellos guardan un bloque específico de código de modo que solamente un hilo a la vez tiene acceso a él. El bloque de código contiene entonces el código para reservar o utilizar un recurso tal como un dispositivo o un objeto compartido. Los mecanismos también tienen operaciones para esperar que un recurso (o actualmente, el bloque de código que guarda por el recurso) sea liberado sin una “espera ocupada” continua, lo cual es un desperdicio de los recursos del procesador. Los mecanismos necesitan ser soportados por el sistema operativo porque ellos tienen que ser implementados utilizando instrucciones indivisibles de bajo nivel, y son incluidos varios programas ejecutándose concurrentemente.

Página 252

Análisis y Diseño de Sistemas con el UML

Resolver los problemas de sincronización que se describieron antes también hace un llamado a la calendarización de los hilos, lo cual es logrado a través del establecimiento de prioridades. Obviamente un hilo con una prioridad más alta tiene precedencia y es calendarizado para ejecutarse antes de un hilo de una prioridad más baja. En algunos sistemas operativos, es también posible parametrizar el algoritmo o aún escoger el algoritmo de calendarización. La forma más simple de controlar la calendarización está en el código de los objetos activos, donde ellos pueden voluntariamente rendir el control llamando funciones tales como sleep (dormir, lo cual hace que el hilo no sea utilizado por una cantidad de tiempo especificado) o esperando por un mecanismo de comunicación o sincronización tal como una buzón de correo o un semáforo que sea señalado o liberado. La estructura de soporte para la sincronización en el UML es limitada, pero puede ser definida a través de extensiones utilizando estereotipos o propiedades. Una clase o una operación puede tener sus requerimientos de concurrencia definidos a través de una propiedad Concurrencia con los posibles valores Secuencial, Vigilado, y Sincrónico. Si una propiedad es establecida para una clase, esto afecta a todas las operaciones en la clase, de otra manera solamente la operación para la cual la es establecida la propiedad es afectada. Los significados de los valores son:

Secuencial: La clase/operación está dirigida para utilizarse únicamente en un sólo hilo de control (no concurrentemente por varios hilos).

Vigilado: La clase/operación trabajará en la presencia de múltiples hilos de control, pero necesita de la colaboración activa de los hilos para lograr una exclusión mutua. Los hilos tienen normalmente que enllavar la clase/operación antes de utilizarla, y desenllavarla más adelante.

Sincronizado: La clase/operación trabajará en la presencia de múltiples hilos de control; la clase maneja por sí misma esto. Esta característica está siendo construida en los lenguajes de programación más modernos, tal como Java, donde una operación puede ser declarada como sincronizada; entonces el manejo de la sincronización de esa operación es automático de modo que solamente un hilo a la vez puede accesarla.

Si la sincronización debe ser modificada más explícitamente, una clase semáforo puede ser definida e instanciada para los semáforos siempre que tenga que ser mostrada la sincronización entre los objetos activos. Otra posibilidad es definir un estereotipo semáforo que es utilizado para todas las clases cuyas instancias son compartidas y deberían de ser vigiladas por un semáforo (en ese caso, el semáforo está conectado implícitamente a la clase que es estereotipada). Los mecanismos de sincronización además de los semáforos pueden ser modelados por supuesto como clases o bien con estereotipos. Calendarización

Como se introdujo de forma breve anteriormente, otras técnicas utilizadas para sincronizar los objetos activos es calendarizarlos. La calendarización es el proceso de decidir qué hilo debería de ejecutarse después en una situación donde varios hilos son concebibles. La calendarización es realizada por el sistema operativo, el cual localiza el procesador para un hilo utilizando algún algoritmo predefinido (ejemplo un algoritmo de ida y vuelta, por medio del cual todos los hilos obtienen una ranura de tiempo especificada, o un algoritmo de prioridad dinámica, el cual se basa en dar prioridad a los hilos que están en el frente interactúando con el usuario). El programador puede controlar partes de la calendarización, normalmente estableciendo prioridades de los hilos o estableciendo parámetros de algoritmo de calendarización. En una situación compleja donde el control detallado se necesita para la calendarización, puede ser diseñado un hilo supervisor.

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 253

El hilo supervisor, dada una máxima prioridad, da el control a los hilos de aplicación de acuerdo de cómo han sido programados (el algoritmo definido es el código supervisor). En el UML, la prioridad de un objeto activo es notada más conveniente como un valor agregado de la clase activa. No hay un valor agregado predefinido para tal valor, pero puede ser fácilmente definido. El rango de valores depende de la resolución del sistema operativo; por ejemplo, puede ser sólo una prioridad baja, media, o alta, o un rango de valor entre 1 y 32. Normalmente la prioridad establecida durante el modelaje necesita ser entonada cuando se prueban los prototipos en las primeras versiones del sistema.

Modelaje de Tiempo Real en el UML En esta parte daremos una descripción de todas las construcciones de modelaje de tiempo real en el UML. No hay diagramas especiales para expresar el tiempo real; en vez de ello, la información de modelaje de tiempo real es agregada el UML normal, especialmente a los diagramas dinámicos. El UML posee definiciones para especificar los siguientes tipos de información:

Tiempo: Las especificaciones y restricciones de tiempo son mejor definidas en los diagramas de secuencia, donde el tiempo es un aspecto primario. Sin embargo, las especificaciones de tiempo pueden ser agregadas a otros diagramas como notas.

Concurrencia: La concurrencia es descrita como clases activas (utilizando el estereotipo <<ActiveClass>> y es dibujada con una línea gruesa alrededor del rectángulo de la clase u objeto). Las propiedades de la clase activa (por ejemplo, proridad) pueden ser definidas como valores agregados de la clase. Puede ser realizado un mapeo al ambiente de implementación a través de los estereotipos componentes <<Process>> (proceso) y <<Thread>> (hilo).

Eventos Asincrónicos: El UML soporta los mensajes asincrónicos enviados entre los hilos o inicializados de los eventos asincrónicos en el ambiente.

Sincronización: La sincronización puede ser descrita ya sea como propiedades de las clases u operaciones (la Propiedad de Concurrencia) o como clases/estereotipos que definen mecanismos tales como semáforos, monitor, o región crítica.

Distribución: Los hilos desplegados en un sistema distribuido son descritos en un diagrama de despliegue (en el cual en su turno utiliza componentes de un diagrama de componentes para representar procesos e hilos).

Las siguientes cuatro figuras muestran ejemplos selectos de un sistema de alarma de una casa. El sistema consiste de una unidad principal a la cual son conectados una serie de sensores y alarmas. Los sensores detectan movimientos en el área vigilada, y las alarmas generan sonidos y/o luces para alejar a un intruso. El área total que puede ser vigilada es dividida en celdas, donde una celda contiene algunos sensores y algunas alarmas que vigilan un área específica. Cuando es activada una celda, la funcionalidad de alarma es encendida; cuando es desactivada, no se está vigilando el área.

Página 254

Análisis y Diseño de Sistemas con el UML

Figura 151: El sistema de alarma tiene sensores

Figura 152: Alarmas

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 255

Figura 153: Objetos activos y pasivos en un sistema de alarma de hogar

Figura 154: Jerarquía de señales para el sistema de alarma de hogar

Los sensores son dispositivos que detectarán actividad en un área específica. Son modelados como una serie de clases especializando una clase abstracta Sensor, la cual define la interfaz de los sensores. La clase Sensor es activa; tiene su propio hilo de control el cual maneja las interrupciones de bajo nivel del dispositivo actual. Un sensor puede ser activado o desactivado, puede ser probado, y puede generar ACK, NAK, y una señal de alarma. Las alarmas son dispositivos para alejar a un intruso por medio de efectos de sonidos y de luces, o llamando o enviando información a un número telefónico de alarma. Una alarma puede ser disparada o apagada y puede ser probada; las señales que puede generar son ACK o NAK. Como los sensores, las

Página 256

Análisis y Diseño de Sistemas con el UML

alarmas son modeladas como una clase activa que maneja una comunicación de bajo nivel con el dispositivo. Un diagrama de clases del sistema ilustra cómo los sensores y las alarmas están integrados en una solución de sistemas. Los sensores y alarmas están conectados a un Manejador de Celda, una clase activa que maneja una celda específica. Un objeto Manejador de Celda lee su configuración de un objeto persistente manteniendo la configuración actual de la celda (los sensores y alarmas a los cuales están conectados y otros parámetros de configuración). El Manejador de Celda está conectado al Manejador del Sistema, el cual es una clase activa que maneja la comunicación del usuario a través de un panel de usuario que tiene un despliegue LCD y un pequeño teclado. A través de esta interfaz de usuario, el sistema puede ser configurado, activado, y desactivado. Todos estos cambios son almacenados en las clases de información de configuración de celda y del sistema. El Manejador del Sistema también contiene un hilo supervisor, el cual se comunica continuamente con todos los Manejadores de Celda. El supervisor realiza autopruebas en los dispositivos, y recibe señales del Manejador de Celda para indicar que está ejecutándose correctamente. También recibirá una señal de alarma de una celda, en cuyo caso normalmente difundirá el disparo de una señal a las otras celdas, causando que se inicien todas las alarmas en el sistema. El Manejador del Sistema tiene un registro en el cual almacena los eventos; también tiene una alarma de sonido interna que puede ser utilizada bajo todas las circunstancias, aún si las conexiones a las otras alarmas han sido cortadas (la unidad principal tendría una unidad de batería en caso de fallo de energía). Las señales en el sistema forman parte de la estructura estática del sistema de alarma para una casa. Todas ellas están conectadas en jerarquía, cuya organización está abierta a la discusión. En la solución en el ejemplo del sistema de alarma para casa, hay tres tipos de señales: general, sensor, y alarma. Las señales generales pueden ser utilizadas ya sea entre el Manejador del Sistema y el Manejador de Celda, así como para los dispositivos. Toda la comunicación asincrónica en el sistema es realizada utilizando señales. Diagrama de Estados

Un diagrama de estados identifica los estados y comportamiento de un objeto activo. El comportamiento cambia en los diferentes estados durante el ciclo de vida del objeto. (Los diagramas de estados normales (concurrente) ya fueron descritos anteriormente en este documento). El estado de un objeto activo puede ser refinado en subestados concurrentes, donde son realizadas concurrentemente una serie de acciones. El resultado de los subestados anidados determina el estado total del objeto activo. Los subestados son máquinas de estado con estados de inicio y parada, y pueden mantener sus estados por períodos de tiempo más largos (por ejemplo, para la ejecución total del sistema). Los subestados no tienen que ser ejecutados en sus propios hilos, lo cual se piensa que es a menudo el caso. Los subestados concurrentes son mostrados dividiendo la región del gráfico del estado en subregiones utilizando líneas punteadas. Cada subregión es un subestado concurrente, que puede tener un nombre opcional, y contener un diagrama de estado anidado con estados disjuntos. Veamos la siguiente figura:

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 257

Figura 155: Subestados concurrentes en un diagrama de estados. El diagrama de estados describe la activación del sistema completo

La fase de activación puede ser modelada utilizando subestados concurrentes, donde los subestados muestran las acciones y los subestados de interés actual para las alarmas, los sensores, y el Manejador de Celda, respectivamente. Solamente si y cuando todos los subestados han alcanzado su estado de parada tiene que ser activado todo el sistema completo; de otra manera, el sistema ha sido puesto en un estado de falla de activación. Los subestados concurrentes son este caso realizados concurrentemente. Las transiciones complejas pueden ser utilizadas como una alternativa a los subestados concurrentes. Una transición compleja puede tener múltiples estados fuentes y objetos, y divide el control en hilos concurrentes que se ejecutan en paralelo o une los hilos concurrentes en un sólo hilo. De esta manera, partes del diagrama de estado son realizados en paralelo, pero la diferencia de utilizar subestados concurrentes es que los estados concurrentes en una transición compleja no son máquinas de estado de su propiedad; son estados del mismo nivel realizados en paralelo. Una transición compleja es ya sea una transición de estado donde el control es dividido en dos o más estados nuevos que son realizados concurrentemente, o un estado de transición donde dos o más estados son sincronizados en un nuevo estado. Una transición compleja es mostrada como una barra vertical, la cual puede tener una o más flechas sólidas extendiéndose de los estados a la barra (llamados estados fuente). Puede también tener una o más flechas sólidas de la barra a los estados (llamados estados destino). Un texto de transición puede ser mostrado cerca de la barra. Solamente cuando el objetos está en todos los estados fuentes y el texto de vigilancia de transición es verdadero se dispara la transición, lo cual significa que comienza o termina la ejecución concurrente. Un modelo más simple de la fase de activación es mostrarla con sus transiciones complejas como se ilustra en la figura siguiente:

Página 258

Análisis y Diseño de Sistemas con el UML

Figura 156: Una transición compleja donde los flujos de control son divididos en hilos concurrentes que corren en paralelo y se sincronizan posteriormente

Por definición, las actividades en cada una de las regiones son realizadas concurrentemente, y solamente cuando son realizadas todas se completa la transición al estado activado por el sistema. Diagrama de Secuencia

Un diagrama de secuencia muestra cómo interactúan una serie de objetos en una situación específica. El aspecto primario es el tiempo, el cual es determinado leyendo el diagrama desde arriba hacia abajo. Naturalmente entonces, un diagrama de secuencia es apropiado para especificar el tiempo y las restricciones de tiempo en los sistemas de tiempo real. Estas especificaciones de tiempo son escritas usualmente en cualquiera de las áreas de comentarios del diagrama; por ejemplo, una especificación del tiempo máximo entre dos mensajes, o un comentario sobre cuánto tiempo debería esperar un objeto antes de enviar otro mensaje a otro objeto. Como una ayuda, las marcas de tiempo (indicando un punto específico en la secuencia, por ejemplo, A o B) pueden ser definidas en el manuscrito y más tarde ser referenciadas en la especificación (por ejemplo, A-B < 10 seg.). En el diagrama de secuencia, los diferentes mensajes pueden ser utilizados para mostrar diferentes tipos de comunicación entre los objetos. Un mensaje simple puede mostrar que el tipo de mensaje no es conocido todavía o es irrelevante; o puede dar un valor de retorno de un mensaje sincrónico. Un mensaje sincrónico en un sistema concurrente proporciona semánticas de espera; lo cual es, que el objeto que envía, espera que el objeto receptor tenga el mensaje. Un mensaje asincrónico revela que el objeto que envía no espera, pero continúa ejecutándose después de haber enviado el mensaje (cualquier resultado es enviado típicamente de vuelta como un mensaje asincrónico también). Los retrasos de transmisión pueden ser desplegados por medio de una flecha inclinada de mensaje indicando que el mensaje será recibido en un tiempo después que cuando fue enviado (el tiempo máximo de transmisión puede ser especificado en el margen). Los objetos activos son dibujados como rectángulos de objetos con una línea gruesa. La activación (cuando un objeto tiene control de ejecución) es mostrada como un rectángulo fino en la línea de vida desde el punto de activación hasta que el objeto no está activado. Un objeto pasivo es activado solamente mientras maneja un mensaje; pierde la activación cuando es retornado el mensaje, mientras tanto un objeto activo mantiene el control y realiza actividades mientras envía y recibe otros eventos. La ramificación, iteración, recursión, creación y destrucción de objetos tiene la misma notación que para los sistemas no concurrentes.

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 259

La siguiente figura muestra de nuevo la secuencia de activación del sistema donde el Manejador del Sistema da una orden al Manejador de Celda de activarse a sí mismo. El Manejador de Celda después envía un mensaje sincrónico (hace una llamada a una operación) al objeto Configuración de Celda pidiendo información; este retorna los datos de configuración.

Figura 157: La secuencia de activación de alarmas indicada en un diagrama de secuencia. La mayoría de los mensajes enviados son asincrónicos, excepto por la lectura de la información de configuración de celdas , la cual es hecha sincrónicamente con un llamado de operacion normal

Luego el Manejador de Celda envía señales de autopruebas a todos los dispositivos, para saber si están trabajando correctamente. Los dispositivos sensores también necesitan una señal de activar para volverse activados. Note que los nombres de los rectángulos Sensor y Alarma no están subrayados, indicando que actualmente representan a las clases. En vez de dibujar una serie de objetos sensores y alarmas en este diagrama de secuencia, ha sido utilizada la alternativa de utilizar clases para mostrar una serie de objetos. La comunicación con sensores y alarmas, la cual es realizada a través de mensajes asincrónicos, se repite para cada uno de los dispositivos instalados (descrito en el margen izquierdo). Cuando todos los dispositivos han sido probados y activados correctamente, una señal de reconocimiento es enviada al Manejador del Sistema. Este diagrama de secuencia describe el escenario exacto de una activación exitosa. Es también posible un caso más general, en el cual alternativas de errores deberían ser también documentadas. Note que las especificaciones de tiempo pueden ser agregadas al manuscrito en el margen izquierdo del diagrama. En este caso, el tiempo desde la activación al punto en el cual el sistema actualmente es activado no debería de tomar más de cinco segundos. Diagrama de Colaboración

Un diagrama de colaboración muestra un contexto (un conjunto de objetos y sus relaciones) y una interacción (cómo cooperan los objetos para realizar una tarea específica). Es muy útil para mostrar las interacciones en los sistemas de tiempo real, porque puede mostrar ambas estructuras de objetos

Página 260

Análisis y Diseño de Sistemas con el UML

activos y pasivos interactúando. En el mismo diagrama puede ser mostrado más de un hilo de ejecución, así como el envío paralelo de los mensajes. La secuencia de mensajes es identificada por una serie de mensajes con etiquetas. Los objetos activos son dibujados como un rectángulo de objeto con una línea gruesa, a menudo con su estructura interna. Como habrá notado, un diagrama de colaboración es excelente para mostrar la interacción entre un conjunto de objetos activos, junto con la estructura interna de esos objetos activos (a menudo compuestos por objetos pasivos). Los tipos de mensaje son los mismos que el diagrama de secuencia (simple, sincrónico, y asincrónico) y tienen los mismos significados y símbolos. La etiqueta que contiene la secuencia del mensaje reemplaza la secuencia de tiempo vertical en el diagrama de secuencia. Los mensajes enviados en paralelo pueden ser descritos utilizando letras en la expresión del número de secuencia. Por ejemplo, los números de secuencia 2.1a y 2.1b de dos mensajes en el diagrama de colaboración indican que esos mensajes son enviados en paralelo. La etiqueta del mensaje puede tener implícitamente información de sincronización a través de la especificación del predecesor. Un predecesor especifica otros mensajes que deben ser realizados antes de que sea permitido el flujo del mensaje (por ejemplo, que el mensaje sea enviado). Eso significa que el predecesor puede ser usado para sincronizar los objetos activos de modo que el trabajo sea realizado en el orden correcto aún si varios objetos activos se ejecuten concurrentemente. Una etiqueta de mensaje puede tener también una condición de vigilancia que debe ser llenada para que el mensaje sea enviado. La condición de vigilancia puede por ello contener condiciones de sincronización que requiere que un recurso sea disponible antes de ser utilizado. Las anotaciones de tiempo pueden ser agregadas a un diagrama de colaboración, aunque no tan claramente como en un diagrama de secuencia. Estas son agregadas normalmente como notas y restricciones de los elementos en el diagrama. El diagrama de colaboración que se mostrará a continuación muestra la interacción cuando un sensor detecta algo:

Figura 158: Un sensor ha detectado un movimiento e inicia una alarma en el sistema que es documentada en un diagrama de colaboración

Primero el sensor envía una señal de alarma asincrónica al Manejador de Celda. Luego el Manejador de Celda envía en paralelo señales de disparo asincrónicas a todas las alarmas (en este caso, una alarma de teléfono y una alarma de sonido) y una señal de alarma asincrónica al Manejador del

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 261

Sistema. Dentro del Manejador del Sistema, la señal de alarma es manejada sincrónicamente – el hilo supervisor primero llama a la alarma de sonido interna y luego escribe el evento al registro. Un diagrama de colaboración proporciona una buena imagen de la estructura de los objetos implicados y su interacción. Diagrama de Actividades

El diagrama de actividades es utilizado principalmente para un flujo secuencial de control. Un diagrama de actividades es conectado típicamente a una operación en una clase, y por esto no es tan importante como los otros diagramas dinámicos en términos de la especificación en tiempo real, aunque se cree que es todavía útil en tal sistema. El diagrama de actividades contiene los estados de acción, cuyas acciones necesitan ser realizadas antes que pueda ser hecha la transición a un nuevo estado (entonces no es necesario un evento externo). Las condiciones y decisiones pueden ser agregadas al diagrama; un diamante de decisión indica qué camino debería de tomar la ejecución (qué estado de acción debería de ser realizado después). Los estados de acción pueden ser ejecutados en paralelo, lo cual es mostrado dividiendo la línea de flujo de ejecución en varias líneas, cada una en un estado separado de acción. Las acciones en los estados son realizadas entonces en paralelo. Los objetos afectados por las actividades en los estados de acción pueden ser mostrados dibujando rectángulos de objetos y conectándolos ya sea como una entrada o una salida a un estado de acción con líneas con flechas punteadas. Los diagramas de actividades pueden demostrar también el envío y la recepción de mensajes, lo cual es interesante cuando modelamos sistemas de tiempo real. Los símbolos del estado de acción pueden ser complementados por símbolos que indican que ha sido enviado un mensaje (un pentágono convexo similar un rectángulo con un punto triangular en un lado) o recibido (un pentágono cóncavo similar a un rectángulo con una muesca triangular en un lado). Las flechas de dependencia pueden ser dibujadas desde los símbolos de mensajes a los objetos que son los emisores o receptores de los mensajes. Un posible uso de los diagramas de actividades en los sistemas de tiempo real es especificar la operación run (ejecutar) de una clase activa, debido a que esta operación muestra el comportamiento concurrente de los objetos de esa clase. La figura muestra la operación run en el Manejador de Celda, en la cual puede ser visto un ciclo de hilos infinito.

Página 262

Análisis y Diseño de Sistemas con el UML

Figura 159: La operación run definida para la clase activa Manejador de Celdas. Se pueden mostrar actividades paralelas en el diagrama de actividades junto con la sincronización de esas actividades (la disparación de alarmas). El manejo de los mensajes de activación, desactivación, y time-out han sido colapsados en una superactividad, pero pueden ser expandidos en diagramas de actividades separados para mostrar los detalles

La operación espera por las señales, y, dependiendo de la señal recibida, realiza algunas actividades para manejarlas. Luego envía una señal de pulso al Manejador del Sistema, pide una señal fuera de tiempo del sistema operativo de modo que se garantiza que reciba una señal en ese momento, y regresa a esperar una nueva señal. En esta figura, las actividades para activar, desactivar, y las señales fuera de tiempo han sido colapsadas en superactividades para prevenir que los diagramas se vuelvan muy complejos. Diagrama de Componentes y de Despliegue

Los diagramas de componentes y de despliegue describen la arquitectura física del sistema, lo cual incluye cómo son implementadas las clases en diferentes componentes de código y cómo están localizados los componentes ejecutables resultantes en los nodos (computadoras y otros dispositivos) en los cuales se ejecutan. Los aspectos de tiempo real de estos diagramas son de que las clases activas son localizadas para los componentes, en los cuales son implementadas y ejecutadas (un componente puede ser ya sea un componente de código fuente y un componente de código ejecutable). Un componente puede tener ya

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 263

sea un estereotipo <<Process>> o un estereotipo <<Thread>>, especificando si la clase activa es implementada como un proceso o un hilo. Las clases activas son desplegadas físicamente y distribuidas entre las computadoras actuales en el sistema vía los componentes en los cuales están implementadas. Por ello, existe un rastro entre las clases lógicas y donde ellas se ejecutan en las computadoras, y viceversa, de los programas de computadora de vuelta a sus descripciones en la vista lógica del sistema. En el sistema de alarma para una casa, la arquitectura física muestra la unidad principal con un panel de usuario que tiene conexiones una serie de sensores y alarmas. Todos los componentes han sido localizados en la unidad principal, la cual tiene todo el software en el sistema, incluyendo los hilos:

Figura 160: El diagrama de despliegue para el sistema de alarma de hogar

Adaptándose a los Sistemas de Tiempo Real Aunque el UML posee una serie de mecanismos para modelar los sistemas de tiempo real, a menudo es necesaria la utilización de mecanismos de extensión para adaptar al UML a un proyecto de tiempo real. Los mecanismos de extensión pueden ser utilizados para adaptar al UML a un método específico, organización, o dominio de aplicación. Los mecanismos serán descritos más adelante en este trabajo. Un estereotipo estándar, <<ActiveClass>>, define una clase (y sus objetos) como activa. El estereotipo es dibujado como una línea. También hay estereotipos estándares, <<Process>> e <<Thread>>, usado con los componentes para describir si un componente es implementado como un proceso o como un hilo. Más estereotipos pueden ser definidos para identificar el mapeo del modelo lógico a los ambientes de implementación. <<Semaphore>> (semáforo), <<Mailbox>> (buzón de correo), <<Exception>> (excepción), <<Interrupt>> (interrupción), y otros. Los estereotipos pueden ser utilizados también para clarificar los modelos, por ejemplo, con estereotipos tales como <<HardwareWrapper>> (envoltura de hardware) o <<Scheduler>> (calendarizador), para explicar el rol de una clase específica o componente. Los estereotipos pueden definir también diferentes tipos de mensajes. Las propiedades (valores agregados) son utilizadas para definir la concurrencia de una clase o una operación (con los valores Secuencial, Vigilado, o Sincronizado). Los valores agregados definidos por el usuario pueden ser asignados a las clases activas para especificar una marca de prioridad u otra información de calendarización.

Página 264

Análisis y Diseño de Sistemas con el UML

Las restricciones de tiempo son utilizadas a menudo en los sistemas de tiempo real, y más a menudo son anotadas en los manuscritos de los diagramas de secuencia, aunque pueden ser agregados libremente a cualquier diagrama como una restricción entre llaves cerca del elemento afectado. Asuntos Especiales del Modelaje de Tiempo Real

Hay algunos asuntos especiales cuando se modelan los sistemas de tiempo real. Naturalmente, la concurrencia, la comunicación, y sincronización son los factores más importantes, pero la tolerancia a fallas, optimización del rendimiento, y la distribución deben también ser tratados cuando modelamos sistemas de tiempo real. Tolerancia a Fallas

La tolerancia a fallas es la capacidad de un sistema de funcionar en la presencia de fallos de hardware y software. En muchos sistemas de tiempo real, una falla en un sistema es simplemente no aceptada bajo ninguna circunstancia. Como se mencionó anteriormente, si un software de tiempo real controla un aeroplano, un vehículo, o una unidad de control médica, una falla del sistema podría significar la diferencia entre la vida y la muerte. Tales sistemas deben ser capaces de manejar las situaciones más anormales, donde el hardware o el software fallan y no trabajan como se esperaba. Un sistema con un alto grado de confiabilidad es aquel cuyos resultados son predecibles y el sistema es robusto. El sistema debe manejar los errores y mantenerse en operación bajo todas las circunstancias. Hay una serie de técnicas para lograr este estado:

Manejo de Errores y Excepciones: Ciertos aspectos de la tolerancia a fallas pueden ser manejados a través del manejo “normal” de los errores y excepciones. Los errores deben ser anticipados en todas las situaciones, y deben ser definidas las excepciones extras de seguridad, generadas siempre que ocurra algún evento excepcional. Los manejadores de excepciones son definidos en lugares apropiados en el código para manejar las excepciones y asegurarse de que el sistema continúe funcionando.

Sistemas Múltiples: Una técnica que implica sistemas múltiples es utilizada en aplicaciones tales como la implementada en el transbordador espacial, donde el hardware y el software es duplicado y aún triplicado. En los sistemas múltiples, el hardware y el software que no está funcionando bien es reemplazado con su unidad de respaldo. El software ha sido escrito por varios equipos; y solamente cuando todos los sistemas de software dan la misma orden se implementa (excepto en una situación en donde debe ser tomada una decisión, en cuyo caso la mayoría manda). A una escala más pequeña, un sistema puede tener un proceso supervisor que monitoree la ejecución del sistema; en caso de una situación seria, el supervisor puede tomar el mando, causando una alarma o un posible reinicio del sistema.

Pruebas Formales: Los métodos matemáticos utilizados para analizar la ejecución concurrente y el intercambio de mensajes pueden detectar los problemas comunes tales como puntos muertos, inanición, uso concurrente, y así sucesivamente. Aún tales métodos matemáticos requieren mucho trabajo, y pueden ser utilizados para detectar posibles situaciones de error en un sistema de tiempo real rígido.

En el UML, pocos mecanismos pueden ser utilizados para tratar de alcanzar la tolerancia a fallas, aún cuando no hay un mecanismo específico para ese propósito. Si no está garantizada la comunicación, todos los diagramas de secuencia deben contener las especificaciones delineando qué pasa si se pierde

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 265

un mensaje. Esto típicamente requiere de tiempos fuera que ocurrirán en el caso de que un mensaje (tal como un reconocimiento) se haya perdido. Los diagramas de estados pueden ser modelados con estados de falla en el nivel más alto, de modo que cuando ocurra cualquier evento no esperado, el objeto sea transferido a un estado de fallas que contenga un manejo conveniente. Optimización del Rendimiento

El uso de abstracción, la cual es una piedra clave en el desarrollo orientado a objetos, puede desafortunadamente conducir a la degradación del rendimiento en tiempo real. Cuando la optimización del rendimiento es importante, podría surgir un conflicto entre el modelo orientado a objetos “ideal” por un lado y el rendimiento por otro, de modo que la implementación actual debe ser actualizada. Esto incluye la toma de atajos en la comunicación entre los objetos (así que un objeto gana acceso directo a un objeto al que normalmente no tiene acceso) y las clases que surjan para disminuir el número de capas entre las diferentes partes del software. Esto puede mejorar el rendimiento, aunque al costo de un descenso en la modularidad del software. Como parte de la optimización, es necesario mirar a los objetos activos. Si es posible, los objetos deberían de ser implementados como hilos es vez de procesos. Los hilos pueden ejecutarse en conjunto en el mismo espacio de memoria; el manejo de hilos es definitivamente más “barato” para los sistemas operativos en términos de rendimiento. También es necesario chequear si los objetos activos pueden ser fusionados, por esto evitando compartir objetos pasivos, con todo el manejo de sincronización que sería entonces requerida. Otras guías para lograr un mayor rendimiento son:

Uso de comunicación sincrónica (ejemplo llamadas de operación) en vez de comunicación asincrónica. Reutilización de objetos mensajes u otros objetos utilizados frecuentemente en vez de estarlos recreándolos continuamente. Evitar copiar objetos entre espacios de memoria diferentes.

Tal trabajo de optimización detallado puede ser necesario cuando se trata de lograr un rendimiento máximo de un sistema de tiempo real. Sin embargo, el primer lugar donde buscar posibilidades de optimización es al nivel de todo el diseño. A menudo un diseño completo puede significar grandes ganancias en el rendimiento, ganancia que es casi imposible al optimizar los niveles más bajos. Para guiarnos a los lugares “correctos,” debemos considerar una herramienta tal como un perfilador (un perfilador muestra dónde gasta el procesador su ejecución de un programa; esto es, las partes del programa que son utilizadas más a menudo). Distribución

Un sistema de tiempo real es a menudo distribuido, lo cual es modelado en el UML en el diagrama de despliegue donde los componentes son distribuidos a través de los nodos. El envío de mensajes y objetos entre los diferentes nodos puede ser fácil si un sistema tal como OLE o CORBA está presente; de otro modo los mecanismos de distribución deben ser diseñados e implementados manualmente. Un mecanismo de distribución incluye el empacar y desempacar objetos complejos hacia y desde corrientes de bytes (a veces llamado serialización) que pueden ser enviados en una línea de comunicación. Esto también incluye la tarea de intuir un sistema de identificación global del objeto, de modo que los objetos puedan dirigirse unos a otros sin saber la localización exacta de los objetos.

Página 266

Análisis y Diseño de Sistemas con el UML

Deben también haber procesos de servidor o hilos para permitir que los objetos se registren y entonces resolver las peticiones a ese objeto en operaciones actuales en el objeto.

Problemas de los Procesos Ha habido una falta de métodos para construir sistemas de tiempo real en general, y el modelaje de los sistemas de tiempo real orientado a objetos no ha sido la excepción. La construcción de los sistemas de tiempo real, especialmente los sistemas de tiempo real rígidos, a menudo han sido tratados como un oficio por lo cual los desarrolladores experimentados construyen los sistemas “en sus cabezas.” Considerando los sistemas de tiempo real rígidos a menudo gobiernan situaciones de vida o muerte, usted puede preguntarse si es una solución de ingeniería disciplinada. Como una base para la construcción de sistemas de tiempo real orientado a objetos, puede ser utilizado todo el conocimiento de la construcción de los sistemas orientados a objetos ordinarios. Como todos los otros sistemas, los sistemas de tiempo real tienen una estructura estática en términos de clases y objetos, los cuales son relacionados unos a otros utilizando asociaciones, generalizaciones, y dependencias. Y un sistema de tiempo real tiene un comportamiento que puede ser descrito utilizando modelos dinámicos y una vista de desarrollo y de despliegue que puede ser modelada en los diagramas de componentes y de despliegue. Las áreas especiales que necesitan ser manejadas cuando definimos un método o un proceso para los sistemas de tiempo real son:

Determinación del modelo para separar los procesos/hilos y los objetos. Identificación y definición de las clases activas. Comunicación y sincronización de las clases activas. Mapeo de los aspectos de tiempo real a los ambientes de implementación.

Debido a que los procesos y los hilos son similares a los objetos (pueden encapsular información y comportamiento, y se comunican utilizando algún tipo de mensajes), un modelo debe ser determinado para saber cómo utilizar los conceptos cuando construimos sistemas que los necesitan. Tradicionalmente, la solución más común fue definir primero un modelo de procesos de gran tamaño que se comunican utilizando primitivas del sistema operativo, y luego diseñar un modelo orientado a objetos de objetos pasivos dentro de cada proceso (la concurrencia explícita del modelo). Es por ello que cada proceso se ha visto como un sistema en sí mismo, y los conceptos de proceso y objeto fueron manejados por separado. Los métodos más modernos siguen el modelo de concurrencia explícita, donde la concurrencia está integrada en el mundo orientado a objetos utilizando clases activas. El sistema es entonces totalmente descrito en los modelos orientados a objetos, donde los objetos activos pueden ejecutarse concurrentemente. Las razones para identificar a una clase como activa típicamente son:

Eventos Asincrónicos en el Ambiente: Cuando el ambiente emprende los eventos asincrónicamente, y hay fuertes requerimientos de tiempo para reaccionar a esos eventos, los objetos activos deben ser introducidos para manejarlos. Estas clases activas son mapeadas a los eventos sincrónicos en el mundo real y pueden ser elaboradas para darle una mayor prioridad a los eventos.

Manejo Periódico: El trabajo que debe ser realizado periódicamente es normalmente modelado como clases activas que duermen por un tiempo prescrito de tiempo, despiertan, realizan su trabajo, y luego vuelven a dormir otra vez.

Anexo E: Modelaje Dinámico Avanzado: Sistemas de Tiempo Real

Página 267

Funciones de Tiempo Crítico: Las funciones dictadas por las restricciones pueden ser modeladas como clases activas a las cuales se les da mayor prioridad que otras. En un sistema preemtive, un hilo con una prioridad mayor siempre suspenderá a todos los otros hilos de menor prioridad, ganando por ello un acceso completo a los recursos de máquina.

Tarea de cómputo en el fondo: Las tareas pueden ser consideradas un trabajo de fondo, el cual puede ser realizado por sí solas y usualmente a una prioridad menor. Tales tareas están imprimiendo, colectando estadísticas, o haciendo trabajo de cómputo que no es de tiempo crítico. El tipo de trabajo que puede ser ubicado en un objeto activo con una menor prioridad, el cual se ejecuta solamente cuando hay tiempo “aparte” para la ejecución normal del sistema.

Cuando las clases activas han sido identificadas, surgen inmediatamente los problemas de comunicación y sincronización. Los sistemas de tiempo real pueden tener mensajes asincrónicos que deben ser manejados en un lenguaje de modelaje y en un método. Típicamente, la comunicación entre los objetos activos es asincrónica, mientras la comunicación interna en el objeto activo es sincrónica. Todos los objetos que comparten dos o más objetos activos deben tener construcciones de protección contra el uso concurrente, y esto debe ser identificado cuando modelamos (es cercanamente imposible “encontrar” los mecanismos correctos de sincronización sólo conduciendo pruebas). Finalmente, un método de tiempo real orientado a objetos debe tomar en consideración el ambiente de implementación. Los modelos deben ser fácilmente mapeados a primitivas en el ambiente; y a veces, los requerimientos de rendimiento dictan que más modelos ideales puedan ser fácilmente traducidos en soluciones de implementación optimizadas. Han sido realizados intentos para definir métodos orientados a objetos especialmente dirigidos a los sistemas de tiempo real. ROOM (Real Time Object-Oriented Modeling Languaje: Lenguaje de Modelaje de Tiempo Real Orientado a Objetos) es un lenguaje de modelaje complementado con heurísticas y guías de organización del trabajo para crear modelos de sistemas de tiempo real. El lenguaje está basado en el concepto de un actor (no debe ser confundido con los actores en los casos de uso) que es una clase activa. Los actores pueden ser descritos como una máquina de estado, la cual puede tener subestados anidados. La clase activa es definida con componentes de interfaces llamadas puertos. Cada puerto define un protocolo: entradas y salidas y su ordenamiento legal. Un actor puede tener varios puertos y así reflejar los diferentes roles del actor. Los objetos de datos pasivos pueden ser también modelados, y los actores pueden ser ubicados en capas. ROOM también incorpora un lenguaje de programación, el cual puede ser utilizado para expresar detalles de bajo nivel tales como paso de mensajes y manipulación de datos. Los modelos de ROOM son ejecutables de modo que pueden ser ejecutados en una herramienta para observar el comportamiento del modelo. OCTAPUS es una adaptación del OMT a los sistemas de tiempo real. Los requerimientos del sistema pueden ser modelados utilizando clases, y el diagrama de contexto describe un vistazo del sistema. La fase de arquitectura del sistema el sistema en subsistemas, los cuales son descritos en un análisis utilizando los modelos estructural, funcional, y dinámicos del método OMT. Los modelos dinámicos tienen un soporte especial de tiempo real en términos de actividades y modelos para listas de eventos, grupos de eventos, páginas de eventos, diagramas de estado, tablas de acción, y tablas de significancia. Una fase de diseño subsecuente detalla la interacción entre los objetos en los hilos de interacción de objetos (los cuales son muy similares a los diagramas de colaboración en el UML). A partir de los hilos de interacción de los objetos, se toman decisiones sobre los procesos convenientes y los mensajes de los interprocesos, y traducidos en un programa en una fase de implementación.

Anexo F: Herramientas Utilizadas Rational Rose 98

Oracle8 Server

Oracle Developer/2000

Anexo F: Herramientas Utilizadas

Página 271

Rational Rose 98

¿Cómo se mide el éxito de un producto de software? Simple. Es el producto correcto en el tiempo correcto. Hace lo que los usuarios quieren que haga, y lo hace rápidamente, eficientemente y confiablemente. Es completamente compatible con cualquier otro software que el usuario necesite y es escalable, desde pequeñas instalaciones hasta gigantes y complejas instalaciones distribuidas. Finalmente, desde el punto de vista de la compañía que lo desarrolló, es barato de producir, genera riqueza y prosperidad para sus empleados y accionistas. ¿Existe un secreto para este tipo de éxito? Puede apostar que no es una bala mágica sino una serie de herramientas que sustancialmente incrementan sus posibilidades de éxito. Una de esas herramientas es Rational Rose. Rose es la primera herramienta visual que ayuda a las organizaciones a construir sistemas que realmente satisfagan las necesidades del negocio – sistemas que evolucionen fácilmente a medida que nuevos requerimientos emerjan. Información sobre Rational Rose 98

Rational Rose domina el mercado de herramientas de análisis orientado a objetos, modelaje, diseño y herramientas de construcción. International Data Corporation (IDC), una firma líder, independiente de investigación de mercado y tecnología publicó un reporte en Mayo de 1998 que muestra que la porción del mercado de Rational es más grande que aquella de los próximos tres vendedores combinados y más de tres veces la del competidor más cercano. Expertos en industria y editores periodísticos han reconocido el liderazgo de Rose, honrándolos con más premios de productos que a cualquier otra herramienta de modelaje visual. Son reconocidos como los líderes de la tecnología por su papel en el desarrollo del Lenguaje de Modelaje Unificado (UML), la notación estándar para la arquitectura de software orientado a objetos. Que puede ofrecer Rose

Miremos rápidamente unos pocos de los beneficios que Rose puede traer en los sistemas que desarrolla:

Página 272

Análisis y Diseño de Sistemas con el UML

Comunicaciones mejoradas

Todos los miembros del grupo de desarrollo usan un lenguaje común. Se evita confusión sobre la terminología y requerimientos. Resultado: los errores se evitan. La transición entre planeo y programación es acortada debido a un mejor entendimiento entre diseñadores e implementadores.

Complejidad administrada

Los sistemas complejos con muchas variables son fácilmente entendidos. Los diseñadores pueden enfocarse en los aspectos generales en vez de en pequeños detalles. Resultado: el tiempo de desarrollo se acorta, y los sistemas son construidos en una manera lógica y rápida.

Arquitectura de software definida

Crea planos del diseño de software. Los requerimientos y variables son claramente definidos. Resultado: hay menos errores en el proceso de diseño, y los sistemas son más fuertes y elásticos al cambio.

Reusabilidad

Rational Rose crea unidades controladas del diseño de la aplicación. Los proyectos pueden ser alterados o actualizados cambiando modelos o parte de los modelos, no la aplicación completa. Resultado: se ahorra tiempo y la productividad se incrementa mediante el cambio de piezas de un sistema existente, aún traducidas a un lenguaje diferente, fácil y eficientemente.

Procesos del negocio capturados

Los requerimientos de un sistema son capturados en casos de uso, definiendo los procesos de negocio desde la perspectiva del usuario. El proceso es definido en formato textual, no en lenguaje computacional. Resultado: un proceso de desarrollo más suave en el cual el producto final realmente satisface las necesidades del usuario final debido a que todos los requerimientos fueron claramente entendidos desde el principio.

Anexo F: Herramientas Utilizadas

Página 273

Familia de Productos

Las características de las diferentes ediciones de la familia Rose están sumarizadas en la tabla siguiente: Característica

Rose 98 Enterprise

Modelaje UML X Soporte Multiusuario X Diferenciación visual y fusión X Framework Wizard X Integración con MS Repository X Integración con ClearCase X Integración con Visual SourceSafe X ERwin add-in X Data Access Add-In X Soporta Productos Rose Link Partner X Interfaz de Extensibilidad Rose X Generación Básica de Reportes X Ingeniería reversa de componenetes X COM Generación Corba/IDL X Generación de Esquema de Base de X Datos (DDL) Soporte para C++ incluyendo VC++ X Java Visual Basic

X X

Ingeniería evolutiva y reversa para X Oracle8 Ada 95 y Ada 83

Rose 98 Professional X X X

X X X

Rose 98 for UNIX X X X

X X

X SCCS

X X X

Edición C++ solamente Edición de Java solamente Edición de VB solamente

Rose 98 Modeler

C++ solamente X

Rational Rose 98 Modeler Edition

Rational Rose 98 Modeler Edition proporciona un soporte sin paralelo del Lenguaje de Modelaje Unificado versión 1.1 para equipos de Desarrolladores de Software y Analistas de Sistemas. El Modeler Edition incluye soporte para el modelaje de procesos del negocio, objetos, y aplicaciones basadas en componentes. También permite diferenciación visual y fusión entre los modelos en las diferentes etapas del diseño para facilitar el desarrollo en paralelo. Para una versatibilidad aún mayor, el Rose Extensibility Interface extiende a Rose con Add-ins de terceras partes y le permite desarrollar sus propios Add-ins customizados.

Página 274

Análisis y Diseño de Sistemas con el UML

Rational Rose 98 Professional Editions

Rational Rose 98 Professional Editions, disponibles en C++, JavaTM, o Visual Basic, incluyen todas las características de la Modeler Edition más generación de código y capacidades de ingeniería reversa. Proporciona un ambiente controlado e iterativo para que múltiples grupos de desarrolladores trabajen en múltiples proyectos. Sus capacidades de ingeniería de ida y vuelta le toman de su diseño al código fuente y de regreso a diseño de nuevo, completamente soportando el ciclo de desarrollo de software. Rational Rose 98 Enterprise Edition

Rational Rose 98 Enterprise Edition se establece por sí mismo como una plataforma de integración para el desarrollo empresarial. Esto incluye toda la funcionalidad del Modeler Edition incluyendo soporte para múltiples lenguajes: C++, Java™, Visual Basic, y Oracle8, desarrollo en equipo múltiple, ingeniería reversa de componentes COM, y la integración del Repositorio de Microsoft. Las capacidades de ingeniería de ida y vuelta le toman desde el diseño hasta el código fuente y de regreso al diseño de nuevo, soportando por completo el ciclo de vida de su software. Rose 98 Enterprise Edition es la mejor herramienta para modelar "componentware" en la industria. Valores y Características del Modelaje Visual con Rational Rose 98

El desarrollo iterativo controlado resulta en ciclos de desarrollo más cortos. El desarrollo conducido por modelos resulta en una productividad incrementada del desarrollador. Desarrollo enfocado en Casos de Uso y el negocio resulta en una calidad mejorada del software. El enfocamiento en la arquitectura de software y componentes resulta en reutilización de software significante. Un lenguaje común y estándar – el UML – resulta en comunicación mejorada del equipo. Las capacidades de ingeniería reversa permiten la integración con sistemas antiguos.

Oracle8 Server El corazón de la línea de productos Oracle es la base de datos Oracle8. Una base de datos simplifica el proceso de búsqueda y almacenamiento de información, como es un archivo electrónico. Reemplaza a los viejos archivadores de oficina y es el archivo digital de la nueva red multimedia conocida como Super Autopista de Información (Information Highway). Oracle8 es el resultado de más de 17 años de desarrollo y mejoras continuas. Es la base de datos más poderosa del mundo. Puede operar virtualmente en cualquier lenguaje de computadora y también en 26 lenguas humanas. Corre en más plataformas que cualquier otro producto, por lo que los clientes de Oracle pueden utilizarla en todos los niveles de la empresa, en cualquier equipo, desde computadoras portátiles hasta supercomputadoras. Oracle8 ha superado récords de rendimiento en todas las plataformas existentes. Oracle8 utiliza el standard SQL para consultas y transacciones que puedan acceder a datos almacenados en múltiples servidores. Provee funciones altamente sofisticadas requeridas por profesionales de informática, incluyendo replicación simétrica en dos fases (two phase commit) transparente. Es la única base de datos capaz de manejar la potencia de procesadores paralelos masivos, que utilizan decenas de procesadores trabajando en tándem para lograr un enorme poder, velocidad, y confiabilidad, a un costo mínimo.

Anexo F: Herramientas Utilizadas

Página 275

Debido al liderazgo de la tecnología de Oracle8, esta se ha convertido en la principal base de datos, con más del 55% del mercado mundial de bases de datos relacionales. Sobre la base de datos Oracle8 se desenvuelve una completa familia de herramientas integradas para desarrollo de aplicaciones y automatización de documentos. Las herramientas de Oracle automatizan todos los pasos de desarrollo de una aplicación, desde el diseño inicial hasta su operación y mantenimiento. La base de datos de Oracle está siempre evolucionando y mejorando, soportada por un presupuesto de investigación y desarrollo que en el último año fiscal rondó los $300 millones. Oracle8 ha integrando la tecnología de “objetos” en la base de datos y herramientas, y podrá proveer soporte para el video-on-demand en la televisión de alta definición (HDTV). Actualmente, la base de datos Oracle8, en conjunción con las herramientas y paquetes de aplicación ofrece un entorno para implementar casi cualquier sistema de información imaginable, constituyéndose en una oferta de amplitud sin competencia. El problema esencial con las primeras bases de datos cliente/servidor radicaba en que las aplicaciones no podían acceder a la información en más de un servidor en forma simultánea, sin recurrir a una programación especial. Dicho de otra manera, una base de datos cliente/servidor de primera generación no soporta un SQL standard o una operación actualizada de SQL Standard que acceda a la información en más de un computador (SQL es el lenguaje estructurado de consulta de bases de datos). En oposición, el servidor Oracle8 soporta SQL Standard, en operaciones actualizadas que automáticamente recuperan y modifican la información en múltiples servidores. Esta información puede ser recuperada aún si alguna porción de la misma está almacenada en una base de datos distinta de la base de datos Oracle, como ser DB2 de IBM o Rdb de DEC. Al ocultar la complejidad de la red, el servidor cooperativo Oracle8 facilita la creación de aplicaciones cliente/servidor más modernas. Oracle8 ha establecido registros certificados de funcionamiento en cada tipo de computador en la que ha sido probado, incluyendo Digital VAX, Data General, Hewlett-Packard, Sequent y Sun. Además, Oracle8 ha alcanzado el mejor rendimiento y mejor costo/performance que jamás se haya registrado en la prueba del “TCP A Transaction Procesing Council.” La Base de Datos para Network Computing

A medida que los sistemas de información evolucionan hacia arquitecturas abiertas basadas en redes y hacia sistemas distribuidos, las empresas se enfrentan a los siguientes retos:

Mantenimiento de la robustez y el rendimiento de los sistemas existentes en nuevos sistemas que se encuentran en fase de desarrollo. Gestión de la interoperatividad de los datos existentes y nuevos. Identificación de los mejores productos que se pueden implantar en ese entorno. Integración y gestión de un entorno multinivel y multiplataforma.

La Network Computing Architecture™ (NCA) de Oracle es abierta y está basada en estándares, y permite a los departamentos de tecnología de la información dedicar menos tiempo a cuestiones de interoperatividad y más tiempo a la implantación de nuevos sistemas. Oracle Server, que es un importante componente de NCA, se ha diseñado para hacer frente a las exigencias de rendimiento,

Página 276

Análisis y Diseño de Sistemas con el UML

fiabilidad y escalabilidad de networking computing para trabajar en la red y de los métodos de desarrollo de objetos. Tanto para las aplicaciones empresariales tradicionales como para el comercio electrónico en World Wide Web, Oracle8 y NCA aportan la potencia, el rendimiento, la robustez, la integración en red y la flexibilidad necesarias para soportar las aplicaciones más exigentes. Oracle8 incluye importantes mejoras de rendimiento y de utilización de recursos. Independientemente de que se necesite dar soporte a decenas de miles de usuarios y cientos de terabytes de datos, o se disponga de un sistema mucho más pequeño, pero igualmente crítico, todos se benefician del rendimiento de Oracle8. Oracle8 soporta aplicaciones de procesamiento de transacciones en línea (OLTP) y de data warehousing mayores y más exigentes. Oracle8 alcanza nuevas cotas de disponibilidad con características que hacen posible operaciones prácticamente ininterrumpidas (7 días a la semana, 24 horas al día, 52 semanas al año). Oracle8, que es el primer servidor objeto-relacional de Oracle, introduce un paradigma orientado a objetos que proporciona nuevas posibilidades para gestionar la complejidad de los datos. Oracle8 Enterprise Edition, Release 8.0 también incluye mejoras en prácticamente todas las demás áreas del servidor Oracle, aumentando la disponibilidad global, el rendimiento, la capacidad de gestión, el soporte de tipos de datos multimedia y la funcionalidad de réplica de datos. Oracle8 Enterprise Edition, Release 8.0 se ha diseñado para abordar las siguientes necesidades:

Alta disponibilidad y capacidad de gestión con tablas e índices divididos en particiones. Paralelismo mejorado. Mayor rendimiento y mejor gestión de aplicaciones de data warehouse. Procesamiento de transacciones en línea a un nivel comparable al ofrecido por un mainframe. Mejor administración de la seguridad. Mejor soporte de Sistemas Distribuidos. Tecnología de objetos y extensibilidad. Herramientas de gestión de fácil uso. Perfecta migración e interoperatividad con versiones anteriores.

Base de Datos Objeto-Relacional

Oracle8 representa un importante avance en la tecnología de gestión de datos con la introducción de un paradigma objeto-relacional. Los esquemas y las aplicaciones de bases de datos son cada vez más complejos. A menudo, varias aplicaciones independientes con datos similares, tales como información de clientes, facturación y envío, existen en distintos esquemas de base de datos, y el departamento de sistemas de información debe gestionar su interacción. La gestión de la información se convierte en una tarea sumamente difícil consistente en integrar distintos objetos relacionales y diferentes aplicaciones, posiblemente de distintos proveedores, para formar un modelo de datos de usuario final más uniforme y coherente. Al mejorar la base de datos relacional con extensiones de objetos para proporcionar una completa solución objeto-relacional, Oracle aborda la necesidad de simplificar la modelización de datos y ampliar la base de datos con nuevos tipos de datos. Entre las características objeto-relacionales de Oracle cabe mencionar las siguientes:

Tipos de objetos para ampliar el servidor de maneras específicas para cada aplicación Los tipos de objetos aportan una manera de ampliar el sistema de tipos de datos relacionales de Oracle. Las bases de datos relacionales admiten tres tipos de datos: caracteres, números y fechas.

Anexo F: Herramientas Utilizadas

Página 277

Los tipos de objetos permiten definir nuevos tipos de datos y utilizarlos de la misma manera que se usarían los tipos de datos relacionales normales. Por ejemplo, se puede crear un nuevo tipo denominado Dirección que puede contener datos, denominados atributos, tales como la calle, la población y el código postal. El tipo de objeto también puede contener métodos, tales como Distancia, para calcular la distancia entre las direcciones. Estos métodos se pueden escribir en PL/SQL, C o Java. La dirección se podrá utilizar entonces en cualquier lugar en el que pueda usarse un tipo de datos normal, tanto en definiciones de columna como en variables PL/SQL, o incluso como definición de una tabla de objetos. Los tipos de objetos de Oracle pueden utilizar potentes técnicas de modelización de objetos para crear objetos complejos. Por ejemplo, pueden representarse colecciones de objetos similares en estructuras de matriz o en tablas anidadas. También pueden almacenarse punteros de objetos para desplazarse rápidamente sin necesidad de combinar tablas. Los tipos de objetos permiten a los desarrolladores de aplicaciones codificar la lógica de la aplicación en la base de datos o en el servidor de aplicaciones de nivel intermedio, en lugar de utilizar código en el lado del cliente. Todas las aplicaciones podrán compartir entonces la lógica de los nuevos tipos de datos, por lo que los desarrolladores no tienen que volver a escribir el código. Esta característica ofrece las ventajas de crear componentes de código reutilizables y una segmentación transparente de las aplicaciones, por lo que el código puede residir y ejecutarse en el nivel que mayor rendimiento aporte: cliente, servidor de aplicaciones o servidor de base de datos. Oracle8 sigue el estándar emergente SQL3 en lo relativo a la definición de tipos de objetos y las técnicas de modelización de objetos. SQL3 define la sintaxis para crear y modificar tipos de objetos, generar y almacenar identificadores de objetos (OIDs), crear referencias o punteros de objetos y modelizar colecciones de objetos similares.

Procedimientos externos como métodos de objetos Oracle proporciona un método rápido y seguro para que la base de datos realice una llamada a un programa externo escrito en C, C++ o Java. La llamada también se puede realizar a través de protocolos abiertos como HTTP o IIOP (un estándar de CORBA). Los procedimientos externos permiten utilizar el código existente de las aplicaciones, o bien escribir código altamente optimizado para fines específicos, como por ejemplo un algoritmo computacionalmente complejo como una transformada rápida de Fourrier (FFT). Asimismo, pueden utilizarse procedimientos externos para interactuar con otras aplicaciones o con dispositivos especializados, como sistemas integrados.

Soporte de objetos en el lado del cliente para agilizar la navegación La memoria caché de objetos del lado del cliente permite a las aplicaciones del usuario recuperar una jerarquía compleja de objetos en una memoria caché de aplicación. La aplicación puede entonces desplazarse a través de los objetos sin realizar recuperaciones adicionales en la red. Esto ofrece una manera práctica y rápida de utilizar objetos en una aplicación cliente y escribir código que sea más parecido al código nativo orientado a objetos.

Evolución de un entorno relacional existente Oracle8 se ha diseñado para facilitar la evolución hacia la nueva funcionalidad orientada a objetos por parte de los usuarios, ya que todas las aplicaciones existentes serán compatibles con las versiones posteriores. Las nuevas extensiones objeto-relacional se fundamentan en la misma base

Página 278

Análisis y Diseño de Sistemas con el UML

que la funcionalidad relacional, por lo que los usuarios no tienen que desechar o volver a escribir sus aplicaciones relacionales existentes antes de realizar la migración a Oracle8. A diferencia de lo que ocurre con otras bases de datos objeto-relacionales, este diseño permite que las aplicaciones relacionales más antiguas –que siguen leyendo y escribiendo filas y columnas– coexistan con las nuevas aplicaciones orientadas a objetos, que leen y escriben objetos. Oracle8 proporciona vistas de objetos para recuperar datos relacionales y representar los datos a un cliente como si fuesen un objeto, y viceversa. Por ejemplo, un sistema relacional de introducción de pedidos ya existente podría necesitar un nuevo front-end para World Wide Web. Las aplicaciones existentes que acceden al esquema relacional pueden seguir en funcionamiento y se puede desarrollar un nuevo conjunto de vistas de objetos como una representación de objetos para el cliente Web. Las aplicaciones nuevas y antiguas se pueden basar en los mismos datos, pero cada una tiene su propia representación.

Herramientas de desarrollo para modelaje de objetos Las herramientas de desarrollo y las herramientas de modelaje gráfica son muy importantes para asegurar el éxito de cualquier proyecto de desarrollo. Oracle Designer/2000 con su herramienta Oracle Object Designer admite plenamente el modelo de objetos de Oracle8. Además, otros muchos proveedores de herramientas, como Rational Software Corporation, admiten el desarrollo de objetos con Oracle8.

Soporte de datos no estructurados (imágenes, vídeo, texto, etc.) Los objetos grandes (LOBs) gestionan datos no estructurados tales como imágenes, sonidos, vídeo y texto, y cuentan con una funcionalidad superior que sus predecesores LONG y LONG RAW. Los LOBs de caracteres (CLOB o NCLOB), los LOBs binarios y los BFILES (o LOBs almacenados externamente) se pueden duplicar y utilizarse como atributo de un objeto. También se puede disponer de más de un LOB por tabla/objeto. Los LOBs también tienen un tamaño máximo superior que los LONGs y cuentan con mecanismos diferentes para mantener la coherencia de lectura y el acceso aleatorio. Los datos de los LOBs están indexados para permitir un acceso rápido a partir de un byte especificado; por ejemplo, se puede leer/escribir en desplazamientos de bytes específicos. También es posible leer/escribir LOBs a través de la memoria caché intermedia de Oracle8, o acceder a los mismos directamente desde disco.

Soporte de estándares abiertos: JAVA Oracle ha elaborado tres iniciativas para admitir Java: un driver JDBC suministrado por Oracle que está integrado de manera más estrecha con los tipos de objetos de Oracle; J/SQL para incrustar instrucciones SQL en el código Java; y una máquina virtual (VM) Java en la base de datos para almacenar y ejecutar el código Java dentro del motor de la base de datos. JDBC ya está disponible para clientes Java con el fin de permitir el acceso a Oracle8. Oracle proporcionará sus propios drivers JDBC para ofrecer mayor rendimiento con Oracle8. J/SQL permite incluir instrucciones SQL en una aplicación Java. A continuación, el precompilador J/SQL convierte las instrucciones SQL en llamadas JDBC, permitiendo el uso de código SQL existente en nuevas aplicaciones Java. Oracle8 ofrece Java en el nivel de base de datos. Esto extiende el soporte de la VM (“máquina virtual”) Java por parte de Oracle al nivel de aplicación y al nivel de base de datos. Puesto que las VMs Java ya se admiten en el cliente, ello ofrece a los programadores una portabilidad a través de

Anexo F: Herramientas Utilizadas

Página 279

distintos niveles y una potencia para segmentar la aplicación de manera flexible a través de niveles. En la base de datos, los desarrolladores pueden utilizar Java con el fin de escribir procedimientos, triggers y métodos almacenados para los objetos de Oracle8, por lo que Java se convierte en una excelente elección para escribir cartuchos de datos. La VM Java está estrechamente integrada en el motor del SGBDR y se ejecuta en el mismo espacio de dirección, aportando un elevado rendimiento. Oracle8 Server y Año 2000

El Oracle Server está certificado para el año 2000 desde la versión 7.1. No es necesario revisar los datos almacenados por las aplicaciones que explotan el tipo de datos DATE (para fechas y para fecha/hora) y que usan el Oracle RDBMS (Oracle7 y Oracle8). El Oracle Server almacena el tipo de datos DATE con una precisión que incluye el año con cuatro dígitos y un componente de tiempo hasta segundos (típicamente ‘YYYY:MM:DD:HH24:MI:SS’). No se esperan problemas operacionales en el Oracle Server, ni en sus productos de redes y de administración de sistemas. La organización de desarrollo de Oracle ha conducido pruebas de varios escenarios operaciones del año 2000 para verificar que no hay impacto a los usuarios en el cambio de siglo. Estos escenarios incluyeron pruebas de replicación, recuperación de punto en el tiempo y transacciones distribuidas; así como pruebas en los productos de redes y de administración de sistemas. El Oracle RDBMS ha siempre almacenado las fechas usando un año con cuatro dígitos, por lo tanto, los usuarios del tipo DATE no deben tener ningún problema al nivel de aplicación. Para facilitar la conformidad con el año 2000 de las aplicaciones que usan años con dos dígitos, el Oracle7 y Oracle8 proporcionan una máscara de formato especial ‘RR’. Usando la máscara ‘RR’, cualquier año de dos dígitos será convertido como sigue: Año actual: dígitos 0-49 50-99 0-49 50-99

dos

últimos Año de dos dígitos especificado 0-49 0-49 50-99 50-99

‘RR’ regresa el siglo Siglo actual Siglo siguiente Siglo anterior Siglo actual

Por lo tanto, sin importar el siglo actual en el momento en que el dato es entrado la máscara ‘RR’ se asegurará que el año sea almacenado en la base de datos como sigue: Si el año actual está en la segunda mitad del siglo (50-99):

Y un año de dos dígitos entre 00 y 49 es entrado: será almacenado como un año del próximo siglo. Ejemplo: 02 entrado en 1996 será almacenado como 2002. Y un año de dos dígitos entre 50 y 99 es entrado: será almacenado como un año del siglo actual. Ejemplo: 97 entrado en 1996 será almacenado como 1997.

Si el año actual está en la primera mitad del siglo (00-49):

Y un año de dos dígitos entre 00 y 49 es entrado: será almacenado como un año en el siglo actual. Ejemplo: 02 entrado en 2001 será almacenado como 2002.

Página 280

Análisis y Diseño de Sistemas con el UML

Y un año de dos dígitos entre 50 y 99 es entrado: será almacenado como un año en el siglo anterior. Ejemplo: 97 entrado en 2001 será almacenado como 1997.

La máscara de fecha ‘RR’ está disponible para insertar y actualizar datos DATE en la base de datos. No es requerida para recuperar/consultar los datos almacenados en la base de datos ya que Oracle ha almacenado siempre el componente del año con cuatro dígitos. Cuando las aplicaciones usan cadenas de caracteres en tipos de datos CHAR o VARCHAR2, si la información del siglo no es mantenida, la aplicación deberá ser modificada para incluir rutinas para asegurar que esas fechas sean tratadas apropiadamente cuando cambie el siglo. Esto puede ser hecho cambiando las cadenas para mantener la información del siglo o, con ciertas restricciones, usando la máscara ‘RR’ cuando se interprete una cadena como una fecha. Para aplicaciones nuevas, o cuando se realicen modificaciones para asegurar que las fechas almacenadas como cadenas cumplan con el año 2000, se sugiere convertir dichas fechas al tipo de datos DATE, asegurando por lo tanto conformidad con el año 2000, o si esto no es posible, entonces almacenar las fechas en un forma que sea independiente de leguaje y formato que maneje los años completos. Por ejemplo ‘YYYY/MM/DD’, y si es necesario el elemento de tiempo almacenarlo como ‘hh24:mi:ss’. El formato ‘YYYY/MM/DD HH24:MI:SS’ tiene las siguientes ventajas:

Es independiente del lenguaje. Tiene el año con cuatro dígitos, por lo que los siglos no son ambiguos. El tiempo es representado completamente, los elementos más significativos ocurren primero, así los ordenamientos basados en caracteres ordenan las fechas correctamente.

Algunas aplicaciones almacenan fechas con dos dígitos para el año. Esto puede llevar a resultados impredecibles cuando se mezclan fechas 19xx con 20xx. Las aplicaciones deben ser modificadas para usar fechas con cuatro dígitos, y corregir los datos en la base de datos. En otras aplicaciones, un año de cuatro dígitos debería ser almacenado, pero errores en algunas aplicaciones almacenan incorrectamente algunas filas con fechas con años de dos dígitos junto con los otros con cuatro. Esto lleva a resultados impredecibles para consultas por fecha si los campos de fecha pueden regresar a fechas antes de 1900. Una aplicación puede revisar los registros para ver cuales contienen fechas anteriores de 1900 y marcar ese error. Muchas aplicaciones en el pasado han definido las fechas con dos dígitos para ahorrar espacio. Para simplificar el procesamiento de este formato ‘YY’, Oracle introdujo el formato ‘RR’ y las reglas de como es procesado internamente. Sin embargo, es usual que sus reglas no sean cuidadosamente observadas por el programador de aplicaciones lo que puede llevar a resultados no esperados. Recuerde que la máscara RR opera correctamente entre los años 1950 y 2049. Las aplicaciones deben ser inspeccionadas si procesan fechas anteriores a 1950 o posteriores a 2049 y almacenan las fechas como dos dígitos. Si estas condiciones se cumplen, dichas aplicaciones no deben usar la máscara RR sino expandir los años a cuatro dígitos y almacenarlos así en la base de datos. Para mostrar la interacción entre NLS_DATE_FORMAT (parámetro de inicio de Oracle Server) y la máscara RR miremos el siguiente ejemplo: SELECT TO_CHAR(TO_DATE(LAST_DAY(‘01-FEB-00’),’DD-MON-RR’), ‘MM/DD/RRRR’) FROM DUAL;

Anexo F: Herramientas Utilizadas

Página 281

La consulta anterior regresará lo siguiente: 02/28/2000. Esto parece incorrecto inicialmente, pero no lo es. La operación está usando el NLS_DATE_FORMAT por defecto, que es DD-MON-YY. Si se cambia el NLS_DATE_FORMAT a DD-MON-RR usando el comando ALTER SESSION antes de la consulta, la misma consulta regresa: 02/29/2000 La diferencia radica en que con YY el LAST_DAY es 28-Feb-00 y con RR es 29-Feb-00. Esto es correcto, pues 1900 no es un año bisiesto, mientras 2000 si lo es (en el primer caso está usando el año 1900).

Oracle Developer/2000

Oracle Developer/2000 es un ambiente de desarrollo rápido de aplicaciones para construir aplicaciones de bases de datos a un nivel empresarial. Es un ambiente muy visual, declarativo para construir aplicaciones escalables, portables, multilenguajes; e incluye componentes para construir aplicaciones complejas incluyendo pantallas, reportes y gráficas. Las aplicaciones de Oracle Developer/2000 pueden ser desplegadas en el Web, en ambientes Cliente/Servidor de dos pisos o en ambientes tradicionales de modo texto, en la mayoría de las plataformas disponibles hoy. La introducción del Web, moviéndose de una arquitectura de dos pisos a una de tres pisos, ha visto la extensión de Oracle Developer/2000 con la introducción de Oracle Developer/2000 Server. Oracle Developer/2000 Server permite a los usuarios usar los beneficios del Web para reducir los costos administrativos, reducir la memoria del cliente y requerimientos de disco y proporcionar acceso a una audiencia más grande a través de un despliegue más fácil. Además, Oracle Developer/2000 continua proporcionando las ventajas tradicionales del despliegue Cliente/Servidor, permitiendo el despliegue de aplicaciones de gran escala, distribuidas y críticas para la misión. Productividad

Utilice las poderosas capacidades declarativas de la herramienta Developer/2000 para crear aplicaciones de las definiciones de la base de datos sin tener que escribir una sola línea de código. Con oprimir unas cuantas veces el ratón, al instante se puede otorgar a las aplicaciones acceso de lectura y escritura a la base de datos libre de errores y mantenimiento y optimizado para el ambiente clienteservidor. Además, Developer/2000 establece nuevas facilidades de uso y estándares de productividad para las herramientas GUI cliente-servidor a través del uso de técnicas de diseño rápido de aplicaciones (RAD), orientación a objetos y el soporte unificado cliente y servidor. La potente interfaz Developer/2000 utiliza una poderosa combinación, fácil de usar, de navegadores de objetos, diálogos “tabbed” y paletas (“palette”) de propiedades para hacer que la creación de aplicaciones GUI sea extremadamente sencilla. La herramienta Developer/2000 incorpora un conjunto avanzado de formas, reportes, gráficos y herramientas de documentación en línea diseñados para garantizar el poder y la escalabilidad que demandan las aplicaciones complejas.

Página 282

Análisis y Diseño de Sistemas con el UML

Escalabilidad Cliente-Servidor

La escalabilidad es muy sencilla para los desarrolladores de Developer/2000. Esta, es inherente a la arquitectura del producto. Es explícita en el soporte sin igual para la funcionalidad del servidor, tal como “array fetch,” cursores de base de datos, variables “bind,” “savepoints” y secuencias. Es definitiva en el particionamiento cliente-servidor “drag and drop” de procedimientos. Y, es evidente en las características que posee que le permiten a los clientes escalar de 5 a 5,000 usuarios, de megabytes a gigabytes de datos y de soporte a decisiones a aplicaciones OLTP complejas. En toda su programación, Developer/2000 utiliza PL/SQL™ lo cual le permite utilizar al máximo el poder de su base de datos Oracle™ y la plataforma del cliente. Obtenga los beneficios de productividad y rendimiento de un lenguaje común y unificado entre cliente y servidor. Mejorar el rendimiento de sus aplicaciones por orden de magnitud es tan fácil como “drag... and drop.” Portabilidad

Los productos Oracle se caracterizan por su portabilidad e implementación global y Developer/2000 no es la excepción. Genere sus aplicaciones con el uso de Microsoft Windows, Apple Macintosh ó Motif e impleméntelas en cualquiera de estos ambientes o en terminales de modo caracter. Disfrute los beneficios que le ofrece la garantía de que sus aplicaciones van a ser compatibles con sus ambientes de cómputo actuales y futuros. También, las aplicaciones Developer/2000 son totalmente portables a través de los idiomas nacionales. Distribuya sus aplicaciones alrededor del mundo en un número de idiomas sin recodificar y utilice las capacidades de la administración de traducciones para garantizar la exactitud de la implementación local. Edición y Depuración Cliente-Servidor Unificada

Hacer a la medida sus aplicaciones Developer/2000 es ahora tan fácil como modificar sus objetos en el servidor. De igual forma, es extremadamente fácil visualizar y manipular el código de programación tanto del cliente como del servidor desde una sóla ventana unificada. Utilice el depurador e intérprete PL/SQL para aislar y corregir errores en la aplicación. Oprima dos veces el botón del ratón en un línea fuente para fijar o remover puntos de corte y aplicar puntos de corte condicionales para aislar futuras áreas problema en su código. Una vez que la ejecución de un procedimiento se ha interrumpido, usted puede ver la pila actual que se llamó, examinar y modificar el estado variable e incluso ejecutar instrucciones PL/SQL arbitrarias. Conforme avanza incrementalmente la ejecución del programa, la localización actual de la fuente PL/SQL es automáticamente identificada y mostrada. Este enfoque por incrementos integrado le permite crear un procedimiento y reiterar rápidamente a través del proceso de editar, compilar, ejecutar y depurarlo. Con pequeños pasos entrelazados, esta herramienta reemplaza el ciclo monolítico tradicional de multiherramienta de edición-compilación-enlace-depuración. Si usted decide particionar la lógica de una aplicación, simplemente arrastre (“drag”) el objeto cliente dentro de un servidor y se convierte en un procedimiento almacenado o un disparador (“trigger”) de la base de datos. Soporte Completo a Interfaces Gráficas (GUI)

Developer/2000 permite crear aplicaciones portables con la apariencia original de Windows, Macintosh, Motif y modo caracter. Construya aplicaciones atractivas e intuitivas con el uso de “toolbars,” “combo boxes,” listas dinámicas, grupos “radio,” botones y otras funciones GUI y mejore fácilmente su apariencia con imágenes y gráficos. En Windows, integre sus aplicaciones

Anexo F: Herramientas Utilizadas

Página 283

Developer/2000 con otros componentes a través de controles OLE 2.0 (Object Linking and Embedding) y Dynamic Data Exchange. Developer/2000 incorpora poderosas herramientas para diagramación y visualización de datos que utilizan una combinación de gráficos, diagramas e imágenes para presentar información en un formato intuitivo, así como también, soporta objetos multimedia tales como vídeo, imágenes y sonido en una variedad de formatos multimedia estándares. Desarrollo en Equipo

Sus aplicaciones Developer/2000 pueden compartir la lógica de las aplicaciones y los objetos de la interfaz de usuario, lo cual le permite definir e imponer estándares de desarrollo en equipo y reutilizar rápidamente objetos o código de las aplicaciones. Almacene procedimientos PL/SQL en bibliotecas centralizadas para usarse por múltiples aplicaciones y desarrolladores. El manejo de configuración, inclusive “check-in,” “check-out,” etiquetado de versiones y emisión de reportes de diferencias, es suplido a través de las interfaces a los paquetes origen y de control de versión de su preferencia. Alternativamente, almacene sus aplicaciones en una base de datos Oracle para crear acceso centralizado para todo su equipo de desarrollo. Acceso a Datos Heterogéneos

Developer/2000 está diseñado no sólo para utilizar al máximo las capacidades de una base de datos Oracle, sino también para accesar toda la información en su organización, indistintamente de su formato o localización. Utilice el adaptador Open Client Adapter, la tecnología Oracle Open Gateway ó las interfaces de programación de aplicaciones (APIs) para comunicarse con las fuentes de datos de su preferencia, incluso DB/2, SQL Server, DB2/400, Access y Rdb. Oracle Developer/2000 y Año 2000

Las herramientas de desarrollo Developer de Oracle están certificadas el año 2000 (Oracle Forms desde la versión 4.5, Oracle Reports desde la 2.5 y Oracle Graphics desde la 2.5; el resto de aplicaciones están certificadas desde su primera versión). En Oracle Forms están disponibles dos máscaras para Text Items (cuadros de texto) y Display Items (etiquetas) – ‘RR’ y ‘RRRR’. Estas máscaras implementan las reglas descritas para la base de datos. La máscara ‘RRRR’ permite que un año de dos dígitos sea entrado en un campo de cuatro dígitos y sea asignado al siglo de acuerdo con las reglas antes descritas. Oracle Reports y Oracle Graphics no son realmente afectados por el cambio de siglo pues principalmente recuperan datos de la base de datos los cuales tienen cuatro dígitos para los años. Sin embargo, todas las facilidades en estos productos que permiten manipulación de datos en la base de datos están certificados para el año 2000.