Andres Munoz - Analisis y Diseno Orientado Al Objeto

ANLISIS Y DISEO ORIENTADO AL OBJETO
A P U N T E S D E M O D E L A M I E N T O D E SI ST E M A S U S A N D O U M L Y U P
Prof. Andrs Muoz Ordenes Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana
TABLA DE CONTENIDO
INTRODUCCIN ........................................................................................... 7
RESUMEN EJECUTIVO ................................................................................................................ 8 AGREDECIMIENTOS ................................................................................................................... 8
UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETO .............. 9

FUNDAMENTOS DE LA ORIENTACIN AL OBJETO ........................................................................... 10
Objeto .................................................................................................................................... 10 Clase ...................................................................................................................................... 10 Instancias ............................................................................................................................... 11 Atributos y Operaciones ........................................................................................................ 11 Mensajes ............................................................................................................................... 12 Encapsulamiento ................................................................................................................... 12 Herencia ................................................................................................................................ 12 Abstraccin ............................................................................................................................ 13 Modularidad .......................................................................................................................... 14 Reutilizacin .......................................................................................................................... 15 Polimorfismo ......................................................................................................................... 16
METODOLOGAS DE MODELAMIENTO ......................................................................................... 16 La Tcnica de Modelado de Objetos (OMT).................................................................. 17

Fases de la Metodologa........................................................................................................ 17 Los Modelos, Diagramas y Su Notacin ................................................................................ 18
El Proceso Unificado (UP) de Desarrollo de Software .................................................. 22

UP y el Desarrollo Iterativo Incremental ............................................................................... 22 La Retroalimentacin y la Adaptacin: Filosofas de UP ....................................................... 24 La Arquitectura: El Centro de UP .......................................................................................... 24 Las Fases del UP .................................................................................................................... 25 Disciplinas del UP .................................................................................................................. 26 Otros Conceptos Orientados a la Planificacin ..................................................................... 27
EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML) .................................................................. 28 Qu es UML? ............................................................................................................... 28 Visin General de los Metamodelos UML Aplicados al A/DOO .................................... 29
Modelo de Dominio............................................................................................................... 30 Modelo de Casos de Uso ....................................................................................................... 31 Modelo de Anlisis ................................................................................................................ 32 Modelo Arquitectnico ......................................................................................................... 33 Modelo de Diseo ................................................................................................................. 34 Modelo de Implementacin .................................................................................................. 35 2
UNIDAD II. EL ANLISIS ORIENTADO AL OBJETO ........................................ 37

FUNDAMENTOS DEL ANLISIS DE SOFTWARE ............................................................................... 38 Caractersticas de los Requerimientos .......................................................................... 38 Clasificacin de los Requerimientos ............................................................................. 38 ESPECIFICACIN DE REQUISITOS ................................................................................................ 39 Tcnica de Especificacin de Requisitos ....................................................................... 40
Paso 1: Definir el Panorama General .................................................................................... 40 Paso 2: Identificar el o los Clientes del Sistema .................................................................... 40 Paso 3: Definir Los Objetivos y Metas ................................................................................... 40 Paso 4: Identificar las Funciones del Sistema........................................................................ 40 Paso 5: Identificar los Atributos del Sistema ......................................................................... 41
MODELO DE CASOS DE USO ..................................................................................................... 42 Conceptos Bsicos ......................................................................................................... 43

Actor ...................................................................................................................................... 43 Escenario ............................................................................................................................... 43 Caso de Uso ........................................................................................................................... 43 Responsabilidad .................................................................................................................... 44 Formalidad ............................................................................................................................ 44
Artefactos del Modelo .................................................................................................. 44 Proceso de Desarrollo del Modelo ................................................................................ 45

Identificacin de Casos de Uso.............................................................................................. 45 Especificacin de Casos de Uso ............................................................................................. 46 Diagrama de Casos de Uso .................................................................................................... 48
GLOSARIO ............................................................................................................................. 50 MODELO DE DOMINIO ............................................................................................................ 51 Conceptos Bsicos ......................................................................................................... 51

Dominio ................................................................................................................................. 51 Clases Conceptuales .............................................................................................................. 52 Proceso .................................................................................................................................. 52

Especificacin del Proceso de Negocio ................................................................................. 53 Identificacin de Clases Conceptuales .................................................................................. 55 Diagrama de Clases Conceptuales......................................................................................... 62
MODELO DE COMPORTAMIENTO............................................................................................... 64 Conceptos Bsicos ......................................................................................................... 64

Evento.................................................................................................................................... 64 Contrato ................................................................................................................................ 64 3
Estado .................................................................................................................................... 64

Diagramas de Secuencia de los Eventos de Casos de Uso .................................................... 65 Contratos de las Operaciones ............................................................................................... 68 Diagramas de Estado ............................................................................................................. 71
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ..................................... 73 Especificacin de Funciones .......................................................................................... 74 Modelo de Casos de Uso ............................................................................................... 76
Especificacin de Casos de Uso ............................................................................................. 76
Glosario ......................................................................................................................... 80 Modelo de Dominio ...................................................................................................... 81

Diagrama de Actividades ....................................................................................................... 81 Diagrama de Clases Conceptuales......................................................................................... 82
Modelo de Comportamiento ........................................................................................ 85

Diagramas de Secuencia........................................................................................................ 85 Contratos de las Operaciones ............................................................................................... 89 Diagramas de Estados ........................................................................................................... 90
UNIDAD III. EL DISEO ORIENTADO AL OBJETO ......................................... 91

FUNDAMENTOS DEL DISEO DE SOFTWARE ................................................................................. 92 La Arquitectura del Software ........................................................................................ 92 MODELO ARQUITECTNICO ..................................................................................................... 94 Conceptos Bsicos ......................................................................................................... 94
Refinamiento ......................................................................................................................... 94 Componente .......................................................................................................................... 95

Especificacin de los Factores de la Arquitectura ................................................................. 95 Especificacin de las Decisiones de la arquitectura .............................................................. 96 Diagrama de Componentes ................................................................................................... 97
MODELO DE DISEO ............................................................................................................... 98 Conceptos Bsicos ......................................................................................................... 99

Realizacin de Caso de Uso ................................................................................................... 99 Responsabilidad .................................................................................................................... 99 Patrones de Diseo ............................................................................................................. 100
Artefactos del Modelo ................................................................................................ 101 Proceso de Desarrollo del Modelo .............................................................................. 101
Diagramas de Colaboracin ................................................................................................ 101 Patrones de Diseo GRASP.................................................................................................. 103 Patrones de Diseo GoF ...................................................................................................... 112 Diagrama de Clases de Diseo ............................................................................................ 115
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ................................... 125 Modelo Arquitectnico ............................................................................................... 125
Diagrama de Componentes ................................................................................................. 125
Modelo de Diseo ....................................................................................................... 128

Diagramas de Colaboracin ................................................................................................ 129 Diagrama de Clases de Diseo ............................................................................................ 134
UNIDAD IV: INTRODUCCIN A LA IMPLEMENTACIN.............................. 139

FUNDAMENTOS DE LA IMPLEMENTACIN DEL SOFTWARE ............................................................. 140 Codificacin de Calidad ............................................................................................... 140 Estndares de Codificacin ......................................................................................... 140 Herramientas CASE ..................................................................................................... 141 MODELO DE IMPLEMENTACIN............................................................................................... 141 Conceptos Bsicos ....................................................................................................... 141
Cdigo.................................................................................................................................. 141
Artefactos del Modelo ................................................................................................ 142 Proceso de Desarrollo del Modelo .............................................................................. 142
Diagrama de Clases de Implementacin ............................................................................. 142 Estructura del Cdigo .......................................................................................................... 147
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ................................... 149 Modelo de Implementacin ........................................................................................ 149
Diagrama de Clases de Implementacin ............................................................................. 149 Estructura de Clases ............................................................................................................ 151
ANEXOS ................................................................................................... 155

PLANTILLA DE DOCUMENTACIN DEL A/DOO ........................................................................... 156 Especificacin de Requisitos ....................................................................................... 156
Identificacin del Sistema ................................................................................................... 156 Especificacin de Funciones ................................................................................................ 156
Modelo de Casos de Uso ............................................................................................. 156

Especificacin de Casos de Uso ........................................................................................... 156 Diagrama de Casos de Uso .................................................................................................. 157
Glosario ....................................................................................................................... 157 Modelo de Dominio .................................................................................................... 157

Diagrama de Actividades ..................................................................................................... 157 5
Diagrama de Clases Conceptuales....................................................................................... 157
Modelo de Comportamiento ...................................................................................... 157

Diagramas de Secuencia...................................................................................................... 158 Contratos de las Operaciones ............................................................................................. 158 Diagramas de Estado ........................................................................................................... 158
Modelo Arquitectnico ............................................................................................... 158

Diagrama de Componentes ................................................................................................. 158
Modelo de Diseo ....................................................................................................... 158

Diagramas de Colaboracin ................................................................................................ 158 Diagrama de Clases de Diseo ............................................................................................ 158
Modelo de Implementacin ........................................................................................ 159

Diagrama de Clases de Implementacin ............................................................................. 159 Estructura de Clases ............................................................................................................ 159
GUA DE USO DE STARUML ................................................................................................... 160 Introduccin a las Herramientas CASE ........................................................................ 160
Historia ................................................................................................................................ 160 Objetivos ............................................................................................................................. 160 Clasificacin de las Herramientas........................................................................................ 161
UML Case-Tool: StarUML ............................................................................................ 163

Ficha Tcnica ....................................................................................................................... 163 Descripcin .......................................................................................................................... 163 Funcionalidades................................................................................................................... 164 Recomendaciones y Buenas Prcticas ................................................................................ 171
BIBLIOGRAFA ...................................................................................................................... 172 TABLA DE ILUSTRACIONES ...................................................................................................... 174
INTRODUCCIN
RESUMEN EJECUTIVO
Este documento contiene una compilacin de clases y apuntes del curso de Diseo Orientado al Objeto dictado por el profesor Andrs Muoz O. durante 3 aos seguidos a alumnos de quinto semestre de la carrera de Ingeniera en Computacin en Informtica del Instituto Profesional La Araucana. Los contenidos principales se dividen en 4 unidades: En la Unidad I se abordan los conceptos bsicos del modelamiento orientado al objeto, su historia y la descripcin del proceso de desarrollo de software con el cual se basa este curso. En la Unidad II se desarrollan los modelos y artefactos en UML correspondientes a la disciplina del anlisis de requisitos y de sistema del proceso de desarrollo. En la Unidad III se desarrollan los modelos y artefactos en UML correspondientes a la disciplina de diseo de sistema del proceso de desarrollo. En la Unidad IV se introduce una tcnica para la conversin del diseo a cdigo, preparando la construccin del software.
El contenido de este documento puede ser utilizado como apuntes de curso, material de apoyo para otros profesores como tambin de alumnos de carreras a fines o similares, solo con la debida citacin del autor. Cualquier colaboracin para mejorar este apunte, por favor enviarla a andmunoz@gmail.com.
AGREDECIMIENTOS
Agradezco profundamente a mis alumnos del instituto de los aos 2007, 2008 y 2009, quienes recibieron este apunte clase a clase, y por supuesto fueron informando todo tipo de errores e inconsistencias que encontraban. Adems, agradecer el apoyo y confianza de los profesores Ral Rojas y Nelson Carvallo, quienes me dieron la oportunidad de lograr desarrollar este ramo. Tambin al profesor Daniel Muoz G., quien tambin utiliz en su curso esta informacin, validando la aplicabilidad de este contenido desarrollado. Y por ltimo, a mi esposa quin fue comprensiva cuando trabajaba dedicadamente en estos apuntes en la comodidad de mi hogar. A todos, muchas gracias. Profesor Andrs Muoz O.
UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETO

El objetivo de esta unidad es entender cmo los conceptos de la orientacin al objeto tambin son aplicables en el modelamiento de un software y adems cmo su uso puede ser beneficioso desde el punto de vista del producto de software que espera el cliente obtener.
FUNDAMENTOS DE LA ORIENTACIN AL OBJETO

Para comenzar, veamos cules son los conceptos bsicos que define la Orientacin al Objeto. OBJETO En el mundo real, estamos rodeados de objetos, basta que echemos una mirada a nuestro alrededor y nos daremos cuenta de ello: el lpiz con el que escribo, la silla en la que estoy sentado, el apunte que estoy leyendo, el celular que tengo en mi bolsillo, el computador que uso para conectarme al MSN, el libro de UML que est en la biblioteca, el sistema operativo de mi computador, el microbs del Transantiago que me trae al instituto, el semforo que me hizo llegar tarde, etc. Todos estos ejemplos representan distintas cosas que vemos, tocamos, usamos, omos y entendemos como objetos de nuestra realidad. Pues, la definicin de lo que es un objeto en OO no est alejada de esa realidad, porque un objeto no es ms que cualquier cosa con la cual se interacta. As, podemos decir que:
UN OBJETO ES CUALQUIER COSA REAL O ABSTRACTA QUE POSEA ATRIBUTOS, SE PUEDA ALMACENAR INFORMACIN Y TENGA UN CONJUNTO DE OPERACIONES CON LAS CUALES SE PUEDE INTERACTUAR.
En A/DOO lo que interesa es el comportamiento del objeto. De esta forma, al disear la estructura de la informacin incorporaremos objetos para representar cada entidad o elemento que interacta dentro del sistema. Por ejemplo, una Factura es un objeto ya que posee un cdigo de factura, informacin de a quien se le est entregando esa factura, la informacin del emisor de dicha factura, el detalle de los servicios o productos, los montos por esos productos, un total, etc. A pesar de que todas las facturas que conocemos poseen esta informacin, el objeto se refiere a una de ellas en particular como individuo nico dentro de su especie. CLASE El ser humano posee una capacidad innata de clasificar. Gracias a esta capacidad entendemos que todos los objetos son de cierto tipo, lo que normalmente lo representamos con un nombre genrico de dicho tipo. Es as como definimos que:
UNA CLASE ES UNA CLASIFICACIN ABSTRACTA, BAJO LA CUAL AGRUPAMOS UN CONJUNTO DE OBJETOS QUE POSEEN EL MISMO TIPO DE CARACTERSTICAS Y LAS MISMAS OPERACIONES.
Cuando hablamos del mismo tipo de caractersticas, queremos decir que las clases definen todos aquellos objetos que podemos definirlos con la misma plantilla.
10
Por ejemplo, la clase Perro es una clasificacin que hacemos para definir los animales que tiene 4 patas, 2 orejas, que ladran, jadean y que son utilizados como compaa del ser humano por su fidelidad al amo. De esta forma, estamos agrupando a todos los perros del mundo bajo este concepto de perro. Sin embargo, cada uno de los perros que conocemos son un objeto en particular de aquella clase porque posee caractersticas que lo hacen nico entre sus pares: color de pelo, largo de pelo, talla, peso, frecuencia de ladrido, etc. INSTANCIAS La distincin que hacemos entre una clase y un objeto generalmente no es fcil de digerir, pues en muchos casos tienden a confundirse. Sin embargo, definiremos el concepto de instancia para hacer ms notoria la diferencia. Es as como decimos que:
UNA INSTANCIA ES UNA REFERENCIA QUE SE HACE A UNO Y SOLO UNO DE LOS OBJETOS DE CIERTA CLASE.
Cuando en OO hablamos de instancia generalmente nos referimos a la relacin que existe entre una clase y un objeto. De esta forma escucharemos cosas como por ejemplo: el objeto es una instancia de una clase o la clase posee como instancias a un conjunto objetos diferentes. Por ejemplo, podemos decir que el alumno Rodrigo Vera es una instancia de la clase Alumno. ATRIBUTOS Y OPERACIONES Las clases poseen cierta estructura la cual define a todas sus instancias. Estas estructuras se construyen a travs de atributos y operaciones. De esta forma, definiremos que:
UN ATRIBUTO ES UN DATO QUE PERMITE DEFINIR UNA
CARACTERSTICA CON LA CUAL SE PUEDE DIFERENCIA A LOS OBJETOS DE UNA MISMA CLASE.
Tal cual como se define, los atributos son variables entre instancias diferentes o a travs del tiempo. De esta forma, dos objetos de la misma clase podran tener diferente informacin en ellos, o simplemente el objeto podra ir variando su atributo a medida que su ciclo de vida vaya avanzando. Por ejemplo, toda Persona posee caractersticas como Talla, Peso y Edad. Estos tres atributos van variando a travs del tiempo y tambin son distintos para diferentes instancias de Persona. As, Mara Eliana tiene 26 aos, mide 1 metro 64 centmetros y pesa 58 kilgramos, en cambio, Pedro tiene 47 aos, mide 1 metro 82 centmetros y pesa 75 kilgramos. El prximo ao ambos cambiaran su edad, d forma que Mara Eliana tendr 27 aos y Pedro 48. Por otro lado, decimos que:
11
UNA OPERACIN O MTODO ES UNA ACCIN QUE PUEDE REALIZAR UN OBJETO Y QUE LE PERMITE INTERACTUAR CON LOS ATRIBUTOS QUE POSEE.
Las operaciones son definidas en la clase, y los objetos automticamente adhieren esa accin a su ADN, lo que nos permite interactuar con ellos directamente (nosotros solo interactuamos con los objetos y no con las clases). Por ejemplo, la Cuenta Corriente posee un atributo de saldo. Cuando de una instancia de la cuenta corriente hacemos la operacin de Giro o Depsitos, el saldo de la cuenta vara. MENSAJES Es importante relacionarse con los objetos de alguna manera estandarizada, de esta forma, se definen algunas solicitudes que nos permiten interactuar con ellos. Con esta premisa, podemos definir que:
UN MENSAJE ES LA FORMA CON QUE SE PUEDE INTERACTUAR CON UN OBJETO.
An cuando esta definicin es muy bsica (y casi abstracta), la lgica de mensajes en el A/DOO tiene la misma simplicidad, es decir, los mensajes son solo el medio de interaccin que los objetos ocupan para comunicarse entre s y con el medio ambiente. ENCAPSULAMIENTO Dentro del diseo OO es muy importante tener en cuenta que nuestros sistemas no interactan directamente con los atributos de los objetos. Por lo que definimos un nuevo concepto como:
ENCAPSULAMIENTO ES LA CAPACIDAD DE OCULTAR LA
REPRESENTACIN INTERNA DE UNA CLASE (ATRIBUTOS) UTILIZANDO OPERACIONES RELACIONADAS CON LAS FUNCIONALIDADES DEL MISMO.
Con esta herramienta, no necesitamos conocer la definicin interna de un objeto, sino que es importante saber cules son las operaciones con las cuales se puede interactuar. HERENCIA Otro concepto muy utilizado es la herencia. An cuando no tenga nada que ver con dinero de algn familiar, la herencia es, por decirlo as, la capacidad de entregar atributos y operaciones entre clases de cierto parentesco. De esta forma definiremos:
12
LA HERENCIA ES EL MECANISMO A TRAVS DEL CUAL SE GENERAN CLASES QUE COMPARTEN ALGUNOS ATRIBUTOS Y OPERACIONES, PERO QUE EN SU ESENCIA SON CONSIDERADOS COMO DISTINTOS.
Con esta definicin encontraremos diferentes soluciones a problemas similares, ya que nos abre una serie de posibilidades sin restriccin. Por ejemplo, si hablamos de la clase Telfono. Esta clase posee atributos que son conocidos: Sistema marcador que permite marcar un nmero telefnico Auricular que permite hablar y escuchar a travs de l Campanilla o timbre que me permite escuchar cuando alguien llama
De la misma manera podemos identificar algunas operaciones que se pueden realizar con l: Conectar a otro telfono Recibir una llamada de otro telfono Hablar con una persona que est al otro lado del telfono Colgar el telfono para finalizar una llamada
An as, y tal como hemos visto anteriormente, estoy hablando de todos los telfonos que existen. Sin embargo, podemos subdividir esta clase en dos grupos: Telfonos Fijos y Telfono Celulares. Ambos grupos comparten los atributos y operaciones anteriormente mencionadas porque son todos del tipo Telfono, pero cada uno puede tener algunas otras caractersticas que lo hace diferente con respecto al otro. ABSTRACCIN Como parte del diseo OO, este concepto es una verdadera herramienta en el modelamiento. As, para entender ms el trmino, definimos:
LA ABSTRACCIN ES LA REPRESENTACIN DE LAS CARACTERSTICAS Y FUNCIONALIDADES ESENCIALES DE UN OBJETO, DESDE EL PUNTO DE VISTA DEL OBSERVADOR, SIN DETALLAR NI ESPECIFICAR SU IMPLEMENTACIN INTERNA.
Este concepto tiene por fin el descomplejizar el diseo, con respecto a la implementacin futura. En efecto, cuando estamos diseando nuestros sistemas es muy importante tener en cuenta que, lo que nos interesa, es el comportamiento de los objetos desde el punto de vista del sistema y no importa mucho la implementacin de cada uno hasta el momento en que los programadores deban comenzar a implementarlos, utilizando herramientas e instrucciones predecibles segn nuestra experiencia. Por ejemplo, si consideramos a la clase Complejo bajo nuestro prisma de abstraccin podemos mencionar algunas de sus funcionalidades:
13
Crear un objeto de tipo Complejo. Sumarle otro Complejo. Restarle otro Complejo. Obtener su parte real o su parte imaginaria. Amplificarlo por un nmero. Etc.
Al leer esta definicin de funcionalidades, podemos rpidamente percatarnos que no hemos hablado nunca en cmo estn implementadas, sino que esas son las funcionalidades que podemos utilizar de la clase. Ms an, ni siquiera hablamos de la representacin interna de la clase, porque para nosotros es transparente. Es muy importante destacar que la abstraccin nos permite fcilmente ver un conjunto de definiciones y operaciones de un objeto como algo funcional, sin reparar en sus detalles, porque es una caracterstica humana. Alguien se ha preocupado de que el ser humano sea un conjunto de clulas y seres microscpicos que realizan todas las labores que podemos ver? Adems de los estudiosos de la materia, para nosotros un ser humano no es ms que un objeto con el cual podemos interactuar y que posee algunas operaciones definidas (aunque a veces no sean predecibles). MODULARIDAD Profundizando un poco en el tema, encontramos conceptos un poco ms avanzados pero que tienen mucho que ver con el Diseo OO. Por ejemplo, decimos que:
LA MODULARIDAD ES LA CAPACIDAD DE PARCELAR CARACTERSTICAS Y FUNCIONALIDADES DE UN SISTEMA, EN PAQUETES DE PROGRAMAS INDEPENDIENTES CON EL RESTO.
Desde el punto de vista de programacin, este concepto es fcil de entender, ya esas caractersticas y funcionalidades son identificables dentro de la implementacin de las clases el sistema. Sin embargo, desde el punto de vista del diseo es muy importante tener en cuenta que, a pesar de no tener claramente identificados los programas y las instrucciones que definen las clases, son perfectamente agrupables en paquetes de implementacin independientes desde el punto de vista de su funcionalidad. Por ejemplo, si tomamos un sistema de remuneraciones, podemos comenzar a identificar las acciones que deseamos que realice: Administracin de Empleados Emisin de Sueldos Emisin de Reportes Etc.
14
Ya con esta sencilla divisin obtenemos mdulos que son considerados independientes con respecto a los dems. Sin embargo, esos mdulos pueden ser mucho ms especficos, por ejemplo: Ingreso de Nuevo Empleado Modificacin de Empleado Eliminacin de Empleado Mandato de Pago de Sueldos Emisin de Liquidaciones de Sueldo Emisin de Reporte de Sueldos Pagados Emisin de Reporte de Sueldos de Empleados Emisin de Certificado de Rentas Etc. Emisin de Reportes Emisin de Sueldos Administracin de Empleados
Como pueden ver, los mdulos encontrados en el primer ejemplo fueron descompuestos en este segundo ejemplo para mostrar que se pueden modularizar con distintos niveles de detalles. Esto a su vez permite que los mdulos sean ms simples y sencillos de implementar, sin embargo, aumenta la complejidad con respecto a las relaciones y mensajes que se deben utilizar para integrar estas funcionalidades. La receta de la modularidad en el diseo tiene que ver con la capacidad de reunir funcionalidades o eventos del sistema que sean atmicos, de manera tal de independizar cada mdulo para que integren un sistema como si fuera un verdadero lego. REUTILIZACIN Este concepto es uno de los ms importantes temas que resuelve un buen diseo OO, y a su vez, es una consecuencia de una buena modularidad. Entonces, diremos que:
LA REUTILIZACIN ES EL MECANISMO O PROCEDIMIENTO A TRAVS DEL CUAL ES POSIBLE UTILIZAR DEFINICIONES DE CLASES Y/O MDULOS YA EXISTENTES, EN UN PROBLEMA NUEVO, DE MANERA NTEGRA O CON ALGN NIVEL DE ADAPTACIN.
Por mucho tiempo, la ingeniera de software se ha dedicado a industrializar procesos de manera de poder reutilizarlos en distintos problemas en forma reiterativa. Sin embargo, la lgica de cada problema en particular hace que las componentes de software sean cada vez menos reutilizables. Sin embargo, cuando el sistema se encuentra modularizado, es posible identificar funcionalidades replicables entre sistemas con ciertas similitudes (imprimir, guardar en disco, etc). Dichas funcionalidades son definidas de una manera general la que permite su reutilizacin dentro de otros sistemas. Es as como aparecen cada vez ms herramientas que hacen ms genricas las soluciones. Por ejemplo, en el despliegue de las pginas web, los diseadores de los programas navegadores de Internet se preocupan solo de aprender a interpretar el lenguaje de hipertexto (HTML) de manera 15
ntegra. Sin embargo, ese mismo mdulo intrprete puede ser usado en cualquiera de los navegadores en forma transparente. POLIMORFISMO Recordando lo que conocemos desde la programacin, este concepto es ms o menos similar. As, definiremos que:
EL POLIMORFISMO ES LA CAPACIDAD DE QUE UNA MISMA OPERACIN PUEDA REALIZARSE DE FORMAS DISTINTAS EN CLASES DISTINTAS.
Como podemos ver, el concepto es el mismo, desde el punto de vista del diseo, como de la programacin, porque trata de explicar cmo la implementacin de las operaciones pueden variar segn la utilidad y momento en la cual deben ser utilizadas. Por ejemplo, si hablamos de una clase Polgono, podemos definir sus operaciones: permetro: Obtiene el valor del permetro del polgono. rea: Obtiene el valor del rea del polgono. altura: Obtiene la altura del polgono.
Utilizando la abstraccin, no hemos definido cul es la implementacin de ninguna de estas operaciones, las cuales sabemos (por nuestros conocimientos de matemticas) que dependiendo del polgono, las frmulas varan. Ahora bien definiremos 2 clases que heredan de Polgono: La clase Rectngulo y la clase Tringulo. Tanto para Rectngulo como para Tringulo, la operacin permetro se calcula como la suma de los lados de la figura (los 4 lados cuando es cuadrado y 3 lados cuando es tringulo). Sin embargo, la implementacin vara cuando hablamos de rea y de altura, porque ambas figuras tienen diferentes frmulas para calcularlas: El rea de un rectngulo es el producto del lado ms corto por el lado ms largo, en cambio, el rea de un tringulo es la mitad del producto de la base por la altura. La altura de un rectngulo es igual al tamao del lado perpendicular a la base, en cambio, la altura de un tringulo es el tamao del segmento de la recta que pasa por el vrtice superior y que es perpendicular a la base.
Sin entrar en terreno computacional vemos que la misma operacin definida desde el punto de vista abstracto en la clase Polgono se ve enfrentado a diferentes frmulas, pero el comportamiento sigue siendo el mismo (el calcular el permetro, rea y altura).
METODOLOGAS DE MODELAMIENTO
Para comenzar, debes entender que:
16
UNA METODOLOGA DE MODELAMIENTO ES UN CONJUNTO DE PASOS, FASES, ITERACIONES, DISCIPLINAS Y ETAPAS QUE SE DEBEN CUMPLIR PARA OBTENER UN MODELO A NIVEL FUNCIONAL, DE NEGOCIO Y/O DE IMPLEMENTACIN DE UN SISTEMA.
En particular, las Metodologas de Modelamiento Orientado al Objeto son un enfoque de la ingeniera de software que nos permite modelar un sistema como un grupo de objetos que interactan entre s. Este enfoque representa un dominio en trminos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional. En ste mtodo de anlisis y diseo se crea un conjunto de tcnicas utilizando una notacin acordada. A continuacin estudiaremos 2 metodologas modernas con las cuales se puede realizar A/DOO.
LA TCNICA DE MODELADO DE OBJETOS (OMT) 1

La metodologa OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James diriga un equipo de investigacin de los laboratorios General Electric. OMT es una de las metodologas de anlisis y diseo orientadas a objetos, ms maduras y eficientes que existen. La gran virtud que aporta esta metodologa es su carcter de abierta (no propietaria), que le permite ser de dominio pblico y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolucin para acoplarse a todas las necesidades actuales y futuras de la ingeniera de software. FASES DE LA METODOLOGA Al igual que cualquier metodologa, OMT se compone de cierta receta que debe cumplir. Las fases que conforman la metodologa son: Anlisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades ms importantes. El modelo de anlisis es una abstraccin resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se har. Los elementos del modelo deben ser conceptos del dominio de aplicacin y no conceptos informticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informticos. Diseo del Sistema. El diseador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basndose tanto en la estructura del anlisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.
Ver OMT en http://www.monografias.com/trabajos13/metomt/metomt.shtml
17
Diseo de Objetos. El diseador de objetos construye un modelo de diseo basndose en el modelo de anlisis, pero incorporando detalles de implementacin. El diseo de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseo puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.). Implementacin. Las clases de objetos y relaciones desarrolladas durante el anlisis de objetos se traducen finalmente a una implementacin concreta. Durante la fase de implementacin es importante tener en cuenta los principios de la ingeniera del software de forma que la correspondencia con el diseo sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilizacin de cdigo y la correspondencia entre el dominio del problema y el sistema informtico, si luego perdemos todas estas ventajas con una implementacin de mala calidad.
LOS MODELOS, DIAGRAMAS Y SU NOTACIN OMT emplea tres clases de modelos para describir el sistema. Estos modelos permiten, de manera sencilla y aplicando conceptos orientados al objeto, definir desde un punto de vista OO cada una de las componentes, funciones y responsabilidades del sistema. EL MODELO DE OBJETOS EN OMT
EL MODELO DE OBJETOS DESCRIBE LA ESTRUCTURA ESTTICA DE LOS OBJETOS DEL SISTEMA (IDENTIDAD, RELACIONES CON OTROS OBJETOS, ATRIBUTOS Y OPERACIONES).
El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo dinmico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicacin. Se representa mediante diagramas de objetos. La definicin clara de las entidades que intervienen en el sistema es un paso inicial necesario para poder definir qu transformaciones ocurren en ellas y cundo se producen estas transformaciones. Esta forma de pensar es inherente al paradigma de OO donde las clases y su jerarqua determinan el sistema. Los diagramas de objetos permiten representar grficamente los objetos, las clases y sus relaciones mediante dos tipos de diagramas: los diagramas de clases y los diagramas de casos concretos (instancias). Los diagramas de clases describen las clases que componen el sistema y que permitirn la creacin de casos concretos, los diagramas de casos concretos describen la manera en que los objetos del sistema se relacionan y los casos concretos que existen en el sistema de cada clase. En los diagramas que componen este modelo se pueden representar los siguientes elementos del sistema: objetos y clases, atributos, operaciones, y relaciones o asociaciones. Para la construccin del Modelo de Objetos, es importante seguir ciertos puntos esenciales de la metodologa: 18
Identificar las clases de objetos. Iniciar un diccionario de datos que contenga descripciones de clases, atributos y asociaciones. Agregar asociaciones entre clases. Agregar atributos a objetos. Organizar y simplificar las clases de objetos usando herencia. Probar las rutas de acceso usando escenarios e iterar los pasos anteriores segn sea necesario. Agrupar las clases en mdulos, basndose en "acoplamiento cercano" y funcin relacionada.
La Notacin del Modelo se puede describir en la siguiente cartilla:
ILUSTRACIN 1. NOTACIN DEL MODELO DE OBJETOS DE OMT
MODELO DINMICO
EL MODELO DINMICO DESCRIBE LOS ASPECTOS DE UN SISTEMA QUE TRATAN DE LA TEMPORIZACIN Y SECUENCIA DE OPERACIONES (SUCESOS QUE MARCAN LOS CAMBIOS, SECUENCIAS DE SUCESOS, ESTADOS QUE DEFINEN EL CONTEXTO PARA LOS SUCESOS) Y LA ORGANIZACIN DE SUCESOS Y ESTADOS.
19
Los conceptos ms importantes del modelado dinmico son los sucesos, que representan estmulos externos, y los estados, que representan los valores de los objetos. El diagrama de estados va a representar los sucesos y los estados que se dan en el sistema. El modelo de objetos describe las posibles tramas de objetos, atributos y enlaces que pueden existir en un sistema. Los valores de los atributos y de los enlaces mantenidos por un objeto son lo que se denomina su estado. A lo largo del tiempo, los objetos se estimulan unos a otros, dando lugar a una serie de cambios en sus estados. Un estmulo individual proveniente de un objeto y que llega a otro es un suceso. La respuesta a un suceso depende del estado del objeto que lo recibe, y puede incluir un cambio de estado o el envo de otro suceso al remitente o a un tercer objeto. La trama de sucesos, estados y transiciones de estados para una clase dada se puede abstraer y representar en forma de un diagrama de estados. El modelo dinmico consta de mltiples diagramas de estados, con un diagrama de estados para cada clase que posea un comportamiento dinmico importante, y muestra la trama de actividad para todo el sistema. En resumen, los aspectos del sistema que estn relacionados con el tiempo y con los cambios constituyen el modelo dinmico. La notacin del Modelo Dinmico se puede observar en la siguiente cartilla:
ILUSTRACIN 2. NOTACIN DEL MODELO DINMICO
Para la construccin del modelo, es necesario definir y realizar algunas actividades:
20
Preparar escenarios para las secuencias de interaccin tpicas. Identificar eventos entre objetos y preparar trazos de eventos para cada escenario. Preparar un diagrama de flujo de eventos para el sistema. Desarrollar un diagrama de eventos para cada clase que tenga un comportamiento dinmico importante. Verificar que los eventos compartidos entre diagramas de estado sean consistentes y correctos.
MODELO FUNCIONAL
EL MODELO FUNCIONAL DESCRIBE LAS TRANSFORMACIONES DE VALORES DE DATOS (FUNCIONES, CORRESPONDENCIAS, RESTRICCIONES Y DEPENDENCIAS FUNCIONALES) QUE OCURREN DENTRO DEL SISTEMA.
Este modelo muestra la forma en que se derivan los valores producidos en un clculo a partir de los valores introducidos, sin tener en cuenta el orden en el cual se calculan los valores. Consta de mltiples diagramas de flujo de datos, que muestran el flujo de valores desde las entradas externas, a travs de las operaciones y almacenes internos de datos hasta las salidas externas. Tambin incluyen restricciones entre valores dentro del modelo de objetos. Los diagramas de flujo de datos no muestran el control ni tampoco informacin acerca de la estructura de los objetos; todo esto pertenece a los modelos dinmico y de objetos. El modelo funcional consta de mltiples diagramas de flujo de datos, que especifican el significado de las operaciones y de las restricciones. Un diagrama de flujo de datos (DFD) muestra las relaciones funcionales entre los valores calculados por un sistema, incluyendo los valores introducidos, los obtenidos, y los almacenes internos de datos. Un diagrama de flujo de datos es un grafo que muestra el flujo de valores de datos desde sus fuentes en los objetos mediante procesos que los transforman, hasta sus destinos en otros objetos. Un diagrama de flujo de datos no muestra informacin de control como puede ser el momento en que se ejecutan los procesos o se toman decisiones entre vas de datos alternativas; esta informacin pertenece al modelo dinmico. Un diagrama de flujo de datos no muestra la organizacin de los valores en objetos; esta informacin pertenece al modelo de objetos. Un diagrama de flujo de datos contiene procesos que transforman datos, flujos de datos que los trasladan, objetos actores que producen y consumen datos, y de almacenes de datos que los almacenan de forma pasiva. Para la construccin del Modelo Funcional, es necesario realizar las siguientes actividades: Identificar valores de entrada y salida. Usar diagramas de flujo de datos para mostrar dependencias funcionales.
21
Describir las funciones. Identificar restricciones. Especificar criterios de optimizacin.
La notacin se puede resumir en la siguiente cartilla:
ILUSTRACIN 3. NOTACIN DEL MODELO FUNCIONAL
EL PROCESO UNIFICADO (UP) DE DESARROLLO DE SOFTWARE

Tal como ya mencionamos al principio del curso, el Proceso Unificado (UP) es una metodologa de desarrollo descrita por Ivar Jacobson, Grady Booch y James Rumbaugh (The Three Amigos) que utiliza conceptos y estrategias OO en el modelamiento del software. No existe claridad si UP dio origen a RUP (Rational Unified Process) o viceversa, sin embargo es claro que es la misma metodologa, con la diferencia que el segundo es una versin comercial de la misma metodologa y apoyada con un paquete de software especfico (Rational Rose actualmente de IBM). UP Y EL DESARROLLO ITERATIVO INCREMENTAL La primera distincin que debemos conocer, es que el UP se basa en un enfoque Iterativo Incremental. Qu quiere decir esto? Esto significa que cada proyecto de software se divide en mini-proyectos de menor complejidad y que son resueltos en un menor tiempo. A esta subdivisin en mini-proyectos se les llama Iteraciones. De esta forma, tenemos que:
22
UNA ITERACIN ES UN INTERVALO DE TIEMPO DENTRO DEL PROYECTO, EN DONDE SE RESUELVE PARTE DE LA PROBLEMTICA ENTREGANDO UN MINI-SISTEMA QUE PUEDE SER PROBADO, INTEGRADO Y EJECUTADO.
La duracin de una iteracin es variable, a pesar de que cada una siempre es un tiempo corto, este tiempo puede ser desde das como algunas semanas. Entre ms largas son las iteraciones ms complejos son los mini-proyectos, por lo que se complejiza ms el desarrollo. Los expertos dicen que una duracin adecuada va entre 2 a 6 semanas. Sin embargo, la duracin de cada iteracin depende directamente de los objetivos de la misma.
Requerimientos Diseo Implementacin Integracin & Pruebas Tiempo Requerimientos Diseo Implementacin Integracin & Pruebas
Iteracin
El Producto va creciendo a medida que se va avanzando en el proyecto
ILUSTRACIN 4. ITERACIONES DEL PROCESO UNIFICADO DE DESARROLLO
Mientras se va avanzando en el proyecto, cada vez que hacemos una nueva iteracin, el producto final va incrementando su tamao, lo que lo convierte en un proceso incremental. Los miniproyectos se van repartiendo de forma tal de comenzar con un producto muy simple y de poca envergadura, para luego ir creciendo junto al sistema para llegar a un trmino en donde el sistema cumpla con todos los requerimientos recogidos del sistema. Esta estrategia se asemeja mucho a la prototipacin de algunos procesos de desarrollo, pero difiere en que cada producto es parte del sistema final, y no un prototipo desechable. An as, es probable que en algunas iteraciones de realicen prototipos, pero stos siempre los veremos como parte del sistema final. Cada producto debe ser un mini-sistema que sea utilizable, quiere decir, con el cual se puede interactuar y comprobar los requerimientos solicitados. Sin embargo, eso lo hace algo voltil, ya que si no se cumple algn requerimiento en particular, el cliente puede solicitar un cambio en el desarrollo realizado convirtindose en un tiempo perdido. Este tiempo perdido, como suelen llamarlo algunos, no lo es tal, pues es la parte que nos ayuda tener ms claro los requerimientos reales y no los que nosotros creemos que el cliente quiere. Las ventajas prcticas de que UP sea iterativo son: Mitigacin de riesgos altos de manera temprana (tcnicos, funcionales, de usabilidad, etc)
23
Progreso visible desde las primeras fases Retroalimentacin, adaptacin y compromiso por parte de los usuarios Gestin de la complejidad a procesos largos de anlisis Reutilizacin de conocimientos aprendidos en iteraciones previas
LA RETROALIMENTACIN Y LA ADAPTACIN: FILOSOFAS DE UP Dentro del desarrollo de Software hay siempre una aprensin: el cliente no sabe lo que quiere. Esto se explica de formas muy variadas. Sin embargo, el problema central no es que el cliente no sepa, sino que es un problema de lenguaje. Muchos proyectos caen en este juego, ya que comienzan por un levantamiento de requerimientos en donde los analistas tratan (en forma infructuosa) de capturar todos los requerimientos que el cliente necesita, llevndose consigo un montn de dudas que hacen que el anlisis y diseo se torne algo turbio. Esto a su vez lleva a que el desarrollo tome cursos indeseados para llegar a productos que, a pesar de su exactitud a los requerimientos levantados, no son satisfactorios para el cliente final. Para mitigar esta situacin muchos comienzan a realizar documentos de anlisis o de diseo que deben ser firmados por el cliente, respaldando sus errores, generando un nivel de frustracin al cliente obligndolo a conformarse con el sistema final entregado. Esta problemtica es abordada por el UP, ya que compromete la participacin del cliente final en el proceso de desarrollo desde el principio del proyecto, para realizar la retroalimentacin. Con esta relacin directa, y el compromiso de parte del usuario, podemos hacer que el sistema se vaya adaptando a las reales necesidades del cliente y no solo con los requisitos funcionales declarados al inicio del proyecto. En las primeras iteraciones, muchas veces trabajaremos con especulaciones de requerimientos. Sin embargo, considerando el objetivo de esta iteracin, el cliente por su parte entender su preocupacin y podr clarificar si esta especulacin est correctamente abordada o realmente fue un invento de los analistas. Esta retroalimentacin es muy importante, ya que nos permite ahorrar mucho tiempo en corregir el error al final del proyecto. Luego de que hemos clarificado el requerimiento, podemos adaptarlo de forma tal que cumpla con las expectativas del cliente final. Pero no todo es color de rosa, ya que el lenguaje ser un gran antagonista en nuestros proyectos. Ms adelante veremos que esta problemtica se resuelve en parte utilizando UML como lenguaje comn. LA ARQUITECTURA: EL CENTRO DE UP Otro tema importante para el UP es que es un desarrollo centrado en la Arquitectura. Definiremos que:
ARQUITECTURA ES UNA DESCRIPCIN DE LOS ELEMENTOS MS IMPORTANTES Y DA UNA PERSPECTIVA DEL SISTEMA COMPLETO.
La arquitectura sirve para: 24
Comprender el sistema Organizar el desarrollo en mini-sistemas Fomentar la reutilizacin Flexibilizar la evolucin del sistema
Esta distincin nos hace nacer otras dudas: cmo se hace una arquitectura slida? Durante las primeras iteraciones del UP se define esta arquitectura. Esta arquitectura se arma con todas las vistas del sistema, a travs de metamodelos y con una comprensin general del mismo. Para armar estos modelos se usan los Casos de Uso. De esta forma, diremos que:
LOS CASOS DE USO SON UN CONJUNTO DE ARTEFACTOS QUE NOS PERMITEN MODELAR LOS REQUERIMIENTOS DESDE EL PUNTO DE VISTA DEL USUARIO FINAL Y QUE NOS DAN LAS VISTAS DEL SISTEMA COMPLETO.
De esta forma, a travs de los casos de uso podemos armar la arquitectura del sistema, de manera tal que podamos entender y dar un panorama general de lo que se debe realizar en el resto del proyecto. Generalmente estos casos de uso son generados con el cliente final y en un lenguaje ms al alcance del usuario, ya que requeriremos una alta retroalimentacin para construir la base del sistema. LAS FASES DEL UP Ahora que ya sabemos bajo qu principios se utiliza el UP, es hora de que veamos cules son las fases que lo definen y comencemos a adentrarnos en el detalle de esas fases, indicando cules son los modelos utilizados en el anlisis y diseo orientado al objeto. Veamos el ciclo de desarrollo desde un punto de vista macro para luego comenzar a desarrollar cada etapa:
Fase Iteracin
...
Inicio
Elaboracin
Construccin Ciclo de Desarrollo
Transicin
ILUSTRACIN 5. FASES DEL PROCESO UNIFICADO DE DESARROLLO
Como vemos en el diagrama, una fase puede estar constituida por una o ms iteraciones, y el ciclo de desarrollo completo se compone de 4 fases:
25
1. Fase de Inicio (Inception): Tiene por objetivo tener una visin aproximada del sistema, realizar el anlisis del negocio, definir el alcance del sistema y realizar estimaciones imprecisas que sern refinadas en las siguientes fases. 2. Fase de Elaboracin (Elaboration): Tiene por objetivo definir una visin refinada del problema, implementar iterativamente el ncleo central de la arquitectura, resolver los riesgos altos, identificar ms requisitos y alcances del sistema y realizar estimaciones ms realistas. 3. Fase de Construccin (Construction): Tiene por objetivo implementar en forma iterativa el resto de los requerimientos de menor riesgo y elementos ms sencillos, adems de preparar el despliegue del sistema en la siguiente fase. 4. Fase de Transicin (Transition): Tiene por objetivo realizar las pruebas del tipo beta y adems de implementar el despliegue del sistema. DISCIPLINAS DEL UP Es importante destacar que las fases del proceso de desarrollo de software no definen en donde se disea o en qu parte se programa, por el contrario, existe en cada iteracin un nmero de disciplinas con las cuales se cruzan estas fases y que si incluyen metodologas de anlisis, diseo, construccin y calidad. Estas disciplinas son: a) Modelado del Negocio b) Requisitos c) Diseo d) Implementacin e) Prueba f) Despliegue
g) Gestin de Configuraciones y Cambios h) Gestin del Proyecto i) Entorno
En cada fase, los matices que se les da a cada disciplina es muy importante. Por ejemplo, un diagrama muy interesante es el siguiente:
26
ILUSTRACIN 6. CARGA DE TRABAJO POR DISCIPLINA EN EL PROCESO UNIFICADO DE DESARROLLO
En este diagrama podemos ver como la carga de trabajo en cada disciplina va variando dependiendo de las fases del proyecto, pero no significa en muchos casos que en etapas posteriores (o anteriores) no exista, pero que es menos importante desde el punto de vista del objetivo de la iteracin en cuestin. En particular, nosotros nos centraremos en las 3 primeras disciplinas, ya que son parte del Anlisis y Diseo OO. El resto de las disciplinas son parte del proyecto en otras reas del mismo. OTROS CONCEPTOS ORIENTADOS A LA PLANIFICACIN Para terminar la visin general del UP, debemos tener en cuenta que existen algunos conceptos que van orientados a la planificacin, ms que al diseo, pero que son importantes clarificar desde un punto de vista del proyecto de software. Estos conceptos, se definen a continuacin: Proyecto es el conjunto de definiciones y la planificacin necesaria para resolver una problemtica puntual. Hito es un punto de terminacin de una iteracin o etapa del proyecto en donde es necesaria tomar alguna decisin o evaluacin importante. Producto o Entregable es el resultado fsico de una iteracin en donde es entregado y validado tanto los requisitos, como el diseo o la implementacin del sistema. Versin es un subconjunto estable y ejecutable del producto final. Incremento es la diferencia (delta) entre las versiones de dos iteraciones seguidas. Versin Final se define cuando el sistema se lanza para su puesta en produccin y es el ltimo hito del proyecto. 27
EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML)

UML nace originalmente como una iniciativa de Booch y Rumbaugh en el 1994 cuando combinan las notaciones visuales de sus mtodos de Booch y OMT (citados anteriomente). Luego de eso, se consolid con la incorporacin de Jacobson, y posteriormente el aporte continuo de Cris Kobryn, refinando el proceso iniciado por The Three Amigos. Hablando del lenguaje, dice textualmente:
EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML) ES UN LENGUAJE PARA ESPECIFICAR, VISUALIZAR, CONSTRUIR Y DOCUMENTAR LOS ARTEFACTOS DE LOS SISTEMAS SOFTWARE, AS COMO PARA EL MODELADO DEL NEGOCIO Y OTROS SISTEMAS NO SOFTWARE.
Esta definicin formal, entregada por el Object Management Group (OMG), quien adopt a UML como lenguaje estndar en 1997, define claramente qu es y para qu sirve. Es as como vemos claros indicios de algo que ya habamos visto: UML es un lenguaje, compuesto por una sintaxis, pero solo comprende de la notacin o nomenclatura y no se hace cargo del proceso de desarrollo (para eso est el Proceso Unificado que veremos ms adelante). UML sirve para especificar, visualizar, construir y documentar nuestros sistemas a travs de metamodelos que sirven en las diferentes etapas del proceso de desarrollo de software. UML documenta sistemas software y otros sistemas no software porque no solo aplica el modelamiento a las componentes de software de un sistema, sino tambin es factible modelar procesos y el mismo negocio a travs de los metamodelos que propone la metodologa de desarrollo. Como se puede ver, UML no es solo notacin aislada, sino que tambin tiene un potencial maysculo cuando hablamos de acompaar al proceso de desarrollo de software. Sin embargo, las disciplinas de anlisis y diseo que nos interesa estudiar no estn dadas por un manual de UML, sino que, a travs del uso de este lenguaje, podremos plasmar en documentos o diagramas los modelos que sean necesarios de realizar. A continuacin, daremos un paseo por el UML, como lenguaje, y su aplicabilidad orientada en las disciplinas de UP como parte del proceso de desarrollo de software.
QU ES UML?
UML se define a travs de dos elementos importantes: una Notacin y un Metamodelo. Diremos entonces que:
28
LA NOTACIN ES LA SINTAXIS DEL LENGUAJE DE MODELADO.
Para esta definicin tenemos un mundo completo de preguntas. Cul sintaxis? En qu lenguaje? Qu quiere decir? En realidad la respuesta es ms fcil de lo que parece, ya que la notacin, tal cual como versa su significado textual, es un conjunto de elementos utilizados en los artefactos.
UN ARTEFACTO ES UN ELEMENTO DEFINIDO A TRAVS DE LA NOTACIN DEL LENGUAJE Y QUE MUESTRA UN PUNTO DE VISTA DE LO QUE SE REQUIERE MODELAR.
De esta manera, los artefactos utilizan la notacin de manera de poder dar una visin del problema en cuestin. As, podemos definir diferentes artefactos dependiendo tambin del punto de vista que se desea plantear. Existen 2 tipos de artefactos: Diagramas: Son aquellos artefactos que utilizan una notacin principalmente grfica o visualmente esquemtica. Documentos: Son aquellos artefactos que describen a travs de un lenguaje natural o estructurado diferentes propiedades de la vista que se desea modelar. En el segundo caso (documentos), UML provee plantillas que definen qu tipo de informacin se debe describir, indicada por el artefacto respectivo, pero no define el idioma. Para esto se recomienda que el lenguaje siempre sea el adecuado a la audiencia del mismo, de esta manera, si es orientado al cliente, el lenguaje natural es ms adecuado. En cambio si es orientado al programador, puede serlo un lenguaje estructurado o incluso un pseudocdigo. Ahora, si seguimos con definiciones, decimos que:
EL METAMODELO ES UN CONJUNTO DE ARTEFACTOS AGRUPADOS PARA UN OBJETIVO ESPECFICO.
Segn lo que aqu estamos planteando, entonces, para un metamodelo, requeriremos utilizar la notacin (UML) necesaria que se ajuste al objetivo planteado a travs de un conjunto de artefactos (diagramas o documentos) que tengan las vistas que cumplan con el objetivo. Es as como UML tiene bien especificados los metamodelos necesarios en cada etapa del desarrollo y la notacin en cada modelo que debe ser utilizada.
VISIN GENERAL DE LOS METAMODELOS UML APLICADOS AL A/DOO

Segn lo expresado en la parte anterior, y llevndolos al mbito del A/DOO, los metamodelos nos ayudan a graficar, con un notacin conocida (UML), nuestros modelos de anlisis y propuestas de diseo (de software) para un problema particular que queremos resolver. 29
Ahora bien, si esto lo cruzamos con la metodologa UP que ya vimos la clase pasada, tenemos que para cada una de las disciplinas que son parte esencial del UP podemos asociar uno o ms modelos. Es as como se plantea una visin de los modelos en UML de la siguiente forma:
ILUSTRACIN 7. METAMODELOS APLICADOS A LA METODOLOGA
Como se puede observar, no es fcil separar el modelado del negocio del anlisis de requerimientos, ya que con ambos podemos completar toda la informacin necesaria para realizar un diseo de software. Adems, al no ser un proceso lineal, es probable que dentro del tiempo del anlisis que se utiliza, el modelado del negocio pueda realizarse en forma paralela. Veamos ahora qu son cada uno de los metamodelos planteados en esta grfica y cules son sus objetivos. MODELO DE DOMINIO Este primer modelo lo podemos definir de la siguiente forma:
ES UNA REPRESENTACIN VISUAL (DIAGRAMA) DE LAS CLASES CONCEPTUALES U OBJETOS DEL MUNDO REAL EN UN DOMINIO DE INTERS.
30
La idea central de estos modelos es representar las clases conceptuales y no los componentes de software, utilizando un lenguaje ms cercano al negocio o dominio en el cual est inmersa la solucin en vez de centrarse en explicar desde el punto de vista tecnolgico el problema (para eso est el Modelo de Diseo). DIAGRAMAS DE CLASES CONCEPTUALES La notacin que utilizan es muy similar a la que se usan en los Diagramas de Clase del modelo de diseo, sin embargo a diferencia de estos diagramas, la representacin de las clases tiene ms que ver con conceptos que con el modelamiento de objetos a travs de clases de software. Es informacin relevante para el modelo de dominio todo lo que tiene que ver con los casos de uso (Especificacin de Casos de Uso), ya que en ella se muestran los procesos elementales que se desean resolver. De esta misma manera, el uso de la informacin modelada en este diagrama es de gran utilidad para incorporar informacin para los Contratos de las Operaciones, Glosario y para el Modelo de Diseo. DIAGRAMAS DE ACTIVIDADES Es una forma especial de diagrama de estado usado para modelar una secuencia de acciones y condiciones tomadas dentro de un proceso. La especificacin del UML define un diagrama de actividad como: una variacin de una mquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la realizacin de las acciones o subactividades. El propsito del diagrama de actividad es modelar un proceso de flujo de trabajo y/o modelar operaciones (del negocio). MODELO DE CASOS DE USO Antes de mirar el objetivo del modelo, definamos algo ms bsico an y que es el trmino Caso de Uso:
ES UNA COLECCIN DE ESCENARIOS RELACIONADOS, QUE DESCRIBE A LOS ACTORES Y LA INTERACCIN QUE ELLOS REALIZAN CON EL SISTEMA PARA CONSEGUIR Y SATISFACER UN OBJETIVO ESPECFICO.
Este concepto es el centro del modelo, ya que intenta explicar que, en otras palabras, un caso de uso no es ms que el uso particular (escenario) que le puede dar el usuario final (actor) al sistema para resolver su problema. Con este concepto claro, podemos definir que el modelo:
ES EL CONJUNTO DE TODOS LOS CASOS DE USO DEL SISTEMA, EN DONDE SE DETALLA LA FUNCIONALIDAD Y EL ENTORNO DE STE.
Despus de esta definicin, podemos decir que en realidad el modelo de casos de uso no es ms que un grupo de modelos que definen tanto las funcionalidades del sistema como de los detalles tiles para el diseo de software. 31
Para entender mejor, expliquemos en forma separada los diferentes diagramas y artefactos que son parte importante de este modelo. ESPECIFICACIN DE CASOS DE USO Una de las actividades principales que se deben realizar en la disciplina de anlisis de requisitos es especificar el detalle de los requerimientos funcionales en casos de uso. De esta forma, este artefacto es la documentacin detallada de dichos requerimientos, a travs de una estructura completa que incluye objetivos de los actores, escenarios de xito, escenarios alternativos, variantes tecnolgicas, restricciones, etc. Este artefacto bsicamente es un documento y no es una grfica, como pasa con los diagramas, sino que ms bien es un detalle (escrito en espaol) con cierta estructura fija que UML define. La fuente de informacin necesaria para la especificacin deben ser los requerimientos funcionales directamente obtenidos del cliente (con su lenguaje natural) y su resultado es parte esencial para el resto de artefactos del modelo de casos de uso. DIAGRAMA DE CASOS DE USO Uno de los primeros artefactos grficos utilizados en el proceso de desarrollo es el diagrama de casos de uso. Este artefacto tiene por objetivo el de organizar, en forma visual, cules son los casos de uso del sistema, su contexto, los lmites y la relacin que tienen con respecto a los actores del mismo. La notacin que utilizan los diagramas de casos de uso por lo general es muy simple, con tipos de relaciones bsicas y sin un detalle que muestre implementacin (como corresponde). Adems, es importante recordar que la parte importante de los casos de uso es su especificacin y no el de llenarse de diagramas que muestren su contexto. GLOSARIO Es un documento que pone en comn toda la terminologa y su utilizacin dentro del dominio de anlisis. Su propsito es poder comprender mejor el negocio en el cual se va a disear el sistema para que todos los actores involucrados mantengan un nivel de entendimiento similar. MODELO DE ANLISIS El modelo de anlisis o de comportamiento se puede definir de la siguiente forma:
ES UN CONJUNTO DE ARTEFACTOS QUE PERMITEN IDENTIFICAR EL COMPORTAMIENTO DEL SISTEMA O PARTES DEL MISMO A TRAVS DE LOS ESCENARIOS PRESENTADOS EN EL MODELO DE CASOS DE USO Y EN FUNCIN DE LAS CLASES CONCEPTUALES.
Es claro identificar que este modelo es el que da pie a identificar los primeros elementos de diseo del sistema. Sin embargo, la mayora de los anlisis se hacen a travs del concepto de caja negra que nos permite abstraernos de la implementacin.
32
Los artefactos asociados a este modelo son: DIAGRAMAS DE SECUENCIA Es un artefacto creado de manera rpida y fcil, que muestra los eventos de entrada y salida relacionados con el sistema que se est estudiando. De esta manera, el diagrama de secuencia muestra el comportamiento como si fuera una caja negra, es decir, sin entender la lgica implementada dentro, sino que desde el punto de vista externo. Desde el punto de vista del anlisis, los actores que se relacionan con el sistema generan diferentes eventos. Estos eventos, organizados como parte de un escenario especfico de uso, son los llamados diagramas de secuencia del sistema, y nos ilustran esta interaccin tanto con los actores (tal como dijimos anteriormente) como con otros sistemas externos. La visin que se utiliza en estos diagramas debe ser para entender el comportamiento del sistema, y no de definir su implementacin, es por eso que la abstraccin nos ayuda a elaborar mejor estos diagramas. La informacin necesaria para estos diagramas se obtiene de los casos de uso (especificacin). CONTRATOS DE LAS OPERACIONES Los contratos de las operaciones del sistema describen el resultado de la ejecucin de las operaciones en funcin de los cambios de estado de los objetos del dominio. Cada una de las operaciones es vista como una caja negra que recibe cierta informacin de entrada y que produce cierta informacin de salida, sin la necesidad de saber cmo se produce esta ltima. El artefacto UML que define un contrato, es un documento que contiene algunos campos sencillos de llenar. De esta manera, el analista puede determinar informacin adicional para el anlisis desde el punto de vista funcional. La informacin esencial para construir estos artefactos son necesariamente las operaciones detectadas en los diagramas de secuencia y a partir del detalle de los casos de uso (especificacin de casos de uso). DIAGRAMA DE ESTADOS Este diagrama nos muestra el comportamiento de objetos, clases, procesos y casos de uso a travs de sus cambios de estados. Es utilizado para describir el comportamiento a diferentes niveles de detalle, dependiendo de lo que se quiere entender. La aplicacin de este artefacto ser para describir dinmicamente el comportamiento del sistema o partes de l a travs de los casos de uso o elementos conceptuales del sistema, es por eso que es muy relevante en este modelo. MODELO ARQUITECTNICO Este modelo podemos definirlo de la siguiente manera:
33
EL MODELO ARQUITECTNICO DEFINE LA ORGANIZACIN Y LAS INTERFACES QUE DEBE REUTILIZABLE Y MODULAR. TENER EL SISTEMA PARA HACERLO
Es fcil ver que en este modelo, tambin conocido como Arquitectura de Software, se definir la modularidad de nuestro sistema. A pesar de que en el proceso estricto, la arquitectura tiene ms informacin que los mdulos del sistema, para efectos acadmicos solo veremos esa dimensin del modelo2. DIAGRAMA DE COMPONENTES Un diagrama de componentes representa cmo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, libreras compartidas, mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema. Debido a que estos son ms parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista esttica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. MODELO DE DISEO El modelo de diseo lo podemos definir como:
EL PROCESO A TRAVS DEL CUAL SE DEFINEN LAS CLASES DE SOFTWARE, SE LES AADEN ATRIBUTOS, OPERACIONES Y EL PASO DE MENSAJES PARA SATISFACER LOS REQUISITOS DEL PROBLEMA.
Con esta definicin, podemos decir que el modelo de diseo define cmo lograr el objetivo del sistema, incorporando las clases de diseo que se deben implementar y por supuesto entregando detalles que van a apoyar el proceso de implementacin. REALIZACIN DE CASOS DE USO Y DIAGRAMAS DE COLABORACIN Una definicin formal de lo que es una realizacin dice que la realizacin describe el cmo se realiza un caso de uso particular en el modelo de diseo, en funcin de los objetos que colaboran. De esta forma, en el diseo, el concepto de realizacin de caso de uso en realidad no es ms que una forma de relacionar los casos de uso analizados con el diseo de objetos que satisface los requisitos.
La definicin formal de la arquitectura es un conjunto de decisiones significativas sobre la organizacin del sistema, la seleccin de elementos estructurales y sus interfaces, el comportamiento dado por la colaboracin de sus elementos y las motivaciones o fundamentos sobre el diseo del mismo.
34
Por otro lado, la forma de realizar los casos de uso es utilizando diagramas de colaboracin los cuales grafican en forma visual cules son las operaciones e interacciones entre los diferentes objetos del dominio. La informacin necesaria para realizar los casos de uso es, principalmente, las especificaciones de los casos de uso. Sin embargo, para aquellas operaciones que se hayan definido contratos, este detalle nos especifica mayor informacin tambin para la realizacin. DIAGRAMA DE CLASES DE DISEO Es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. A pesar que la notacin es similar al usado en el modelo de dominio, el diagrama de clases de diseo incorpora notacin adicional y por supuesto un detalle mayor desde el punto de vista de la implementacin, ya que el objetivo es especificar con el mximo de detalle posible la estructura, su composicin y la relacin de los objetos que componen el sistema. La informacin usada en el DCD para la definicin de las clases y sus operaciones sale en su mayora como parte de las realizaciones de casos de uso. En efecto, de los diagramas de interaccin, podemos obtener de manera sencilla las operaciones de cada clase, ya que es fcil encontrarlas como interacciones entre sus instancias de objetos. MODELO DE IMPLEMENTACIN Este modelo se define como:
UN CONJUNTO DE ARTEFACTOS DE IMPLEMENTACIN COMO EL CDIGO FUENTE, DEFINICIONES DE BASES DE DATOS, PGINAS, PROGRAMAS, ETC.
Tal como queda definido, el modelo de implementacin se preocupa de contener el cdigo a travs de diferentes estrategias. Por ejemplo, una tcnica es la transformacin de diseos en cdigos desde las definiciones de las clases e interfaces y la definicin de los mtodos desde el DCD. Es claro ver que el principal alimentador de este modelo es el modelo de diseo, quien ha llevado el detalle de cmo es el software hasta detallar las operaciones. Una gua rpida de este modelo es la siguiente: Crear definiciones de las clases a partir de los DCDs. Con esto podemos definir rpidamente la estructura de nuestras clases fsicas o programas, sin lograr detallar el funcionamiento del sistema todava. Crear los mtodos a partir de los diagramas de interaccin. Con esto podemos entender el funcionamiento de cada una de las operaciones en su mecnica interna, lo que nos
35
permite encontrar fcilmente la secuencia lgica de las instrucciones dentro de los mtodos de los objetos. Ordenar la implementacin. Con esto es importante que tengamos un orden de implementacin definido desde la menos a la ms acoplada. Programar probando primero. Con esto se puede minimizar la cantidad de errores, ya que las pruebas de unidad se van haciendo antes de que ya est desarrollado el cdigo completo. De esta manera la mayor cantidad de errores tpicos es resuelto en la codificacin.
36
UNIDAD II. EL ANLISIS ORIENTADO AL OBJETO

Durante este captulo veremos cmo recolectar los requerimientos y cmo ellos van agregando informacin, a travs de modelos desarrollados en UML, para recabar y recolectar el mximo detalle necesario para construir nuestros diseos de software.
37
FUNDAMENTOS DEL ANLISIS DE SOFTWARE

Segn la definicin de Wikipedia se entiende por necesidad una carencia o la exigencia de un objeto. Si esto lo llevamos al plano informtico, una necesidad es la respuesta a la carencia o la exigencia de algo dentro de un contexto de negocio (dominio). Para comenzar a describir un buen modelo de software, es importante distinguir respecto a la necesidad un concepto que ser el respaldo de lo que debemos de disear. Definamos entonces el concepto de Requerimiento o Requisito:
UN REQUERIMIENTO O REQUISITO ES UNA NECESIDAD
DOCUMENTADA SOBRE EL CONTENIDO, FORMA O FUNCIONALIDAD DE UN PRODUCTO O SERVICIO.
Es muy importante comprender que se habla de una necesidad documentada, porque muchas veces se confunden las necesidades con los requerimientos. De esta forma, podemos dejar muy en claro que un requerimiento es la respuesta a la necesidad que un cliente busca satisfacer con alguna funcionalidad o capacidad del sistema.
CARACTERSTICAS DE LOS REQUERIMIENTOS

Los requerimientos poseen algunas caractersticas que necesitamos destacar y diferenciar. De esta forma podemos decir que un requerimiento, que se aprecie como tal, debe ser: Necesario: Lo que pida un requerimiento debe ser necesario para el producto. Sin ambigedad: El texto debe ser claro, preciso y tener una nica interpretacin posible. Conciso: Debe redactarse en un lenguaje comprensible para los usuarios en lugar de uno de tipo tcnico y especializado, aunque an as debe referenciar los aspectos importantes. Consistente: Ningn requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos tambin debe ser consistente. Completo: Los requerimientos deben contener en s mismos toda la informacin necesaria, y no remitir a otras fuentes externas que los expliquen con ms detalle. Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles. Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificacin puede lograrse mediante inspeccin, anlisis, demostracin o testeo.
CLASIFICACIN DE LOS REQUERIMIENTOS

Existen 2 grandes grupos de requerimientos:
38
Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar. Los requerimientos del sistema establecen con detalle las funciones, servicios y restricciones operativas del sistema. Los requerimientos de sistema adems pueden ser clasificados a travs de un modelo denominado FURPS+, el cual es un acrnimo de las categoras escritas en ingls, las que logran realizar una clasificacin de una manera amplia. Esta es la clasificacin: Funcional (Functional): relacionados con caractersticas, capacidades y seguridad del sistema. Usabilidad (Usability): relacionado con factores humanos, ayuda y documentacin. Fiabilidad (Reliability): relacionado con la frecuencia de cadas, capacidad de recuperacin y previsin de ellas. Rendimiento (Performance): relacionado con los tiempos de respuesta, productividad, precisin, disponibilidad y uso eficiente de los recursos. Soporte (Supportability): relacionado con la adaptabilidad, facilidad de mantenimiento, multi-lenguaje y configurabilidad. Y el signo + corresponde a: Implementacin: relacionado con la limitacin de los recursos, lenguajes, herramientas, hardware, etc. Interoperabilidad: relacionado con las restricciones impuestas para la interaccin con sistemas externos. Operacin: relacionado con la gestin del sistema en su puesta en marcha. Empaquetamiento: relacionado con la capacidad de empaquetar el sistema. Legales: relacionado con las licencias de uso, instalacin de componentes, etc. Es bastante til trabajar con una categorizacin de los requerimientos. Esta es una base con la cual se puede comenzar, sin embargo, existen otras clasificaciones muchas veces ms simples, pero que dejan fuera una buena distincin. Dependiendo del estilo de anlisis que se utiliza, realizar una u otras es bastante indiferente, porque la real distincin que uno debe tener es de los requerimientos funcionales (caractersticas y comportamiento del sistema) con los requerimientos no funcionales (usabilidad, fiabilidad, rendimiento, soporte, etc). Por qu est ltima distincin? Los requerimientos funcionales son los prcticamente definen las funciones del sistema.
ESPECIFICACIN DE REQUISITOS
39
A pesar de que no es parte del UML, la formalizacin de los requerimientos es una gran ayuda desde el punto de vista de claridad de lo que realmente necesita el cliente. Es por eso que aqu se definen algunos artefactos recomendados para esta fase previa al anlisis3.
TCNICA DE ESPECIFICACIN DE REQUISITOS

PASO 1: DEFINIR EL PANORAMA GENERAL Este elemento permite definir el entorno del sistema, es decir, el marco en el cual se desenvolver ste. Por ejemplo, un panorama general sera algo como: D&S, distribuidor de alimentos a travs de distintos formatos y que agrupa los supermercados Express de Lder, Hiper Lder y Ekono. PASO 2: IDENTIFICAR EL O LOS CLIENTES DEL SISTEMA Lo que se quiere definir en este punto es quienes son los principales usuarios finales del sistema, de manera de que se puedan identificar aquellas fuentes del negocio ricas en informacin (stakeholders). En esta parte se incluyen organizaciones y personas. Por ejemplo, Los cajeros, el rea de finanzas, inventario y SecurePay. PASO 3: DEFINIR LOS OBJETIVOS Y METAS Las metas definen qu es lo que se espera mejorar con este sistema. En esta parte es importante que se detalle claramente lo que el cliente espera obtener con la implementacin. Por ejemplo, la meta es una mayor automatizacin del pago en las cajas registradoras, dar soporte a los servicios ms rpido, ms baratos y mejores y a los procesos de negocio a travs de un sistema de terminal para el punto de venta que se utilizar en las ventas del supermercado . PASO 4: IDENTIFICAR LAS FUNCIONES DEL SISTEMA Esta es la parte medular de esta definicin, ya que debe contener lo que debe hacer el Sistema en anlisis. Es importante no solo identificarlas, sino que tambin listarlas en grupos cohesivos y lgicos. De esta forma, se propone ingresar las funciones del sistema en una tabla con el siguiente formato:
# Ref: Funcin: Descripcin: Categora: ILUSTRACIN 8. PLANTILLA DE ESPECIFICACIN DE FUNCIONES
En cada campo se debe indicar el detalle de la siguiente forma: Ref #: Indicar una referencia, como por ejemplo R1.1, R2.4, etc. El primer nmero indica el grupo y el segundo es un correlativo dentro de ese grupo.
3
Existen otros artefactos que pueden detallar estos requerimientos, pero no sern abordados en el curso
40
Funcin: Se debe dar un nombre autoexplicativo que haga referencia a lo que sta realiza. Descripcin: Se debe describir en forma sinttica y exacta la funcin que debe realizar el sistema frente a las necesidades del usuario final. Categora: Es necesario indicar un cierto nivel de prioridad clasificada por su significado y que pueden consumir tiempo cuando no son formalizadas. Estas categoras son: o Evidente: Debe realizarse y el usuario debera estar consciente de ello. o Oculta: Debe realizarse, pero no necesariamente es visible para el usuario (procesos de soporte, por ejemplo). o Superflua: Son opcionales ya que su inclusin no repercute significativamente en las otras funciones. PASO 5: IDENTIFICAR LOS ATRIBUTOS DEL SISTEMA Estos no son funciones, sino que valores que pueden abarcar algunas o todas las funciones del sistema. Por lo general tienen que ver con aquellos requerimientos no funcionales. Se propone el siguiente formato4:
Atributo Detalles y Restricciones Categora
ILUSTRACIN 9. CONTINUACIN DE LA PLANTILLA DE ESPECIFICACIN DE FUNCIONES
Cada uno de los atributos tiende a tener un detalle que contiene valores discretos, confusos o simblicos. Adems, podra tener restricciones de frontera, que son las condiciones obligatorias, generalmente en un rango de valores, de un atributo. Por ltimo, se debe indicar qu tipo de categora o de requerimientos estamos hablando (referido al FURPS+ por ejemplo). Supongamos por un momento que el problema que se nos plantea resolver con un sistema es hacer un aplicativo para administrar la caja de un supermercado, tambin conocido como Punto de Venta (PDV). En una primera reunin se recogen algunos requerimientos: La caja debe permitir el ingreso del cdigo de los productos en forma manual o a travs de una pistola lectora de cdigos de barra. Si la caja se cae por algn motivo (prdida de conectividad con el servidor, corte de energa, error en el procesamiento del medio de pago o producto defectuoso, etc), el sistema debe retomar el proceso inmediatamente despus del ltimo paso realizado. Solo se aceptan pagos con efectivo, cheques y tarjetas bancarias. El cajero debe identificarse siempre al principio de su jornada, de modo que podamos llevar control de las ventas que realiz.
Se estila que la tabla de funciones y de atributos se unan en una sola.
41
De esta manera, se puede definir un documento con la informacin de especificacin general del sistema y sus funciones de la siguiente forma:
Nombre del Sistema: Panorama: Clientes: Metas: Sistema Punto de Venta (SPDV) D&S a travs de distintos formatos y que agrupa supermercados como Express de Lder, Hiper Lder y Ekono. Los cajeros, rea de finanzas, sistema de inventario y SecurePay Crear un sistema de terminal para el punto de venta que se utilizar en las ventas del supermercado de manera de: Entregar mayor automatizacin del pago en las cajas registradoras Dar soporte a los servicios ms rpido, ms baratos y mejores y a los procesos de negocio R1.1 Identificacin del Cajero El cajero debe identificarse siempre al principio de su jornada, de modo que podamos llevar control de las ventas que realiz. Evidente Detalles y Restricciones Categora
# Ref: Funcin: Descripcin: Categora: Atributo
# Ref: Funcin: Descripcin: Categora: Atributo Ingreso de Cdigos Recuperacin de la Venta
R2.1 Registrar los Productos de la Venta La caja debe permitir que el cajero vaya registrando todos los productos que el cliente traiga en su carro o canasto y asociarlos a la misma venta. Evidente Detalles y Restricciones Categora Debe ser manual o por pistola lectora de cdigos de Usabilidad barras. Implementacin Debe permitir recuperar una venta desde el punto Fiabilidad anterior a la cada.
# Ref: Funcin: Descripcin:
R2.2 Registrar el Pago de la Venta La caja debe permitir que el cajero ingrese el pago de la venta con cualquier medio de pago habilitado. Categora: Evidente Atributo Detalles y Restricciones Categora Medios de Pago Habilitados Solo se aceptan pagos con efectivo, cheque y tarjetas Implementacin bancarias. ILUSTRACIN 10. PLANTILLA DE ESPECIFICACIN DE FUNCIONES PARA EL SPDV
MODELO DE CASOS DE USO

Para diferenciar y entregar ms elementos que nos hagan entender el modelo de casos de uso, veamos la definicin que ya planteamos en la unidad de conceptos y metodologas vista anteriormente:
42
EL MODELO DE CASOS DE USO ES, BSICAMENTE, EL CONJUNTO DE TODOS LOS CASOS DE USO, MODELO DE LA FUNCIONALIDAD Y DEL ENTORNO DEL SISTEMA.
Con esto, nos referimos en que el Modelo de Casos de Uso, definido en la disciplina de Requerimientos del UP nos habla sobre las funcionalidades del sistema y cmo se comporta con el entorno, bajo los distintos escenarios en los cuales se desenvuelve. Es preciso destacar que el modelo de casos de uso siempre usa una visin externa, es decir la del usuario que utiliza el sistema (usuario final).
CONCEPTOS BSICOS
Pero para entender cmo utilizar y construir los Modelos de Casos de Uso es importante comprender algunos conceptos relacionados con el tema. ACTOR De manera informal, podemos decir que:
ACTORES SON ELEMENTOS QUE POSEEN COMPORTAMIENTO
PROPIO, COMO UNA PERSONA, UN SISTEMA INFORMATIZADO U ORGANIZACIN QUE INTERACTA CON NUESTRO SISTEMA A MODELAR.
Antes de identificar los casos de uso que componen el modelo, se identifican los actores que van a participar en este modelo. Pronto veremos cmo los representamos en UML, por ahora nos quedamos solo con la definicin. ESCENARIO Al igual que lo que hicimos con el actor, podemos decir que:
ESCENARIO ES UNA SECUENCIA DE ACCIONES ENTRE LOS ACTORES Y EL SISTEMA EN ESTUDIO.
Con esto nos referimos a una historia particular de uso del sistema, es decir, alguna serie de eventos que pueden ocurrir en una ejecucin de nuestra aplicacin que estamos diseando. A esto tambin se le conoce como Instancia de Caso de Uso. CASO DE USO Finalmente, y al parecer el concepto ms esperado, con el que decimos que:
43
UN
CASO
DE
USO
ES
UNA
COLECCIN
DE
ESCENARIOS
RELACIONADOS, QUE DESCRIBE A LOS ACTORES UTILIZANDO EL SISTEMA PARA UN OBJETIVO ESPECFICO.
Al ver esta definicin podemos decir que el Caso de Uso define las relaciones y acciones de los actores hacia el sistema, bajo el prisma de un objetivo especfico. En particular, podemos decir que los Casos de Uso en realidad son requisitos, ante todo son requisitos funcionales (como la F de los requisitos FURPS+) o de comportamiento. Sin embargo, en algunos casos, los otros requerimientos aparecer como Casos de Uso tambin, pero ya es poco comn. Lo general es que sean funcionales. RESPONSABILIDAD Lo primero es saber qu es una responsabilidad:
RESPONSABILIDAD ES UNA METFORA CON LA CUAL SE ESPECIFICA LOS REQUISITOS FUNCIONALES.
Estas metforas se refieren a indicar el qu debe hacer el sistema (anlisis) y no el cmo lo debe hacer (diseo). A veces ocurre que los analistas tratan de especificar los pasos a seguir en el caso de uso como si fuese un pseudocdigo o programa, pero eso se debe dejar al diseo. FORMALIDAD Los casos de uso definen sus responsabilidades con distintos tipos de formalidad. Estos tipos son: Breve: Es un resumen conciso de un solo prrafo, normalmente indicando cul es el escenario principal con xito. Informal: Es un formato de mltiples prrafos que comprenden varios escenarios, o uno solo que toma la idea general de esos escenarios. Completo: Es donde se escriben todos los pasos y variaciones, con secciones de apoyo como precondiciones y garantas de xito de los escenarios presentados.
Aqu podemos ver que las formas de especificar los casos de uso generalmente varan, y tambin dependen de la situacin en la que se est trabajando. As en algunos casos nos conviene usar una formalidad breve, en cambio en otras es una formalidad completa.
ARTEFACTOS DEL MODELO

De la misma forma, encontraremos que el modelo de casos de uso se puede construir a travs de 2 artefactos del lenguaje: Especificacin de Casos de Uso: Documento que permite describir en detalle y lenguaje natural las particularidades de cada caso de uso identificado.
44
Diagramas de Casos de Uso: Diagrama que muestra el contexto de todos los casos de uso del sistema en relacin a los actores del mismo.
PROCESO DE DESARROLLO DEL MODELO

Para crear los entregables del modelo (es decir, los artefactos de ste), se necesita proceder a travs del uso de tcnicas o recetas. Veamos la tcnica de identificacin y especificacin de los casos de uso: IDENTIFICACIN DE CASOS DE USO Adems de saber cmo se identifican los casos de uso, es importante entender que debemos mirar el entorno para ver la relacin que tiene el sistema con los actores y sus objetivos. De esta forma, se describe una receta que nos ayudar a encontrar estos elementos claves en la definicin de los casos de uso: PASO 1: ELEGIR EL LMITE DEL SISTEMA Al comenzar a definir los casos de uso, es importante saber hasta dnde llega el sistema, cul es el alcance de ste. El problema es que no siempre es fcil determinar el lmite, porque se confunden responsabilidades del sistema con las funcionalidades desde el punto de vista del usuario. Es por eso que siempre es ms fcil determinar primero lo que est fuera (actores externos y de apoyo). Una vez que estos agentes externos al sistema estn claramente identificados, descubrir los lmites de ste se torna un poco ms sencillo. Por ejemplo, existe alguna responsabilidad del sistema de caja de supermercado de autorizar y gestionar los pagos con tarjetas de crdito?, la respuesta es no, porque ese servicio lo da Transbank, lo que dejara tanto ese objetivo como el actor fuera de nuestro sistema en anlisis. PASO 2: IDENTIFICAR LOS ACTORES PRINCIPALES Y DE APOYO Luego de tener claro el lmite del sistema, debemos identificar los actores del modelo. Estos actores se dividen en tres grupos: Actores Principales: Son aquellos actores o personas externas al sistema que requieren un servicio para cumplir sus objetivos especficos. Por ejemplo: El Cajero es un actor que desea procesar una venta. Actores de Apoyo: Son actores de segunda categora que prestan servicios de apoyo al sistema, como otros sistemas (Sistema de Inventario, como por ejemplo para el sistema de venta). Actores Pasivos: Son actores que estn interesados en el comportamiento del caso de uso, pero que no interacta con l. Por ejemplo: SII es un actor pasivo.
En la mayora de los casos, los actores principales son los que nos importaran, ya que ellos interactan con el sistema a travs de los casos de uso para satisfacer sus objetivos. PASO 3: IDENTIFICAR LOS OBJETIVOS DE LOS ACTORES
45
Con los actores, es fcil saber cul es su objetivo para utilizar el sistema, ya que ellos se desprenden de la formalizacin de los requerimientos anteriormente vista. Es por eso, que se recomienda que cuando se genere la lista de actores, inmediatamente poner al costado el o los objetivos que tiene. Una forma es en una tabla como la siguiente:
Actor ... Objetivo ... ILUSTRACIN 11. TABLA DE IDENTIFICACIN DE ACTORES Y OBJETIVOS
Los objetivos pueden ser ms de uno, ya que los actores tienen ms de una esperanza del sistema. De esta forma iremos desarrollando el modelo. Otra forma de encontrar los objetivos es a travs de eventos externos, los cuales son gatillados como respuesta a estos objetivos. Por ejemplo, un evento externo es ingresar el producto a la lista de compras, este evento lo realiza el Cajero cuando pasa el producto por el lector de barras y corresponden a un grupo de eventos que llamamos procesar una venta. Este ltimo corresponde a uno de los objetivos del Cajero. PASO 4: DEFINIR LOS CASOS DE USO Despus de este proceso, lo que se requiere es identificar cules son los casos de uso del problema. Este paso puede durar desde minutos (solo descubrir cules son) hasta das (especificar el detalle de ellos). Generalmente definiremos los casos de uso por objetivo de cada actor principal. Por ejemplo, si el objetivo es procesar una venta, entonces el caso de uso asociado ser Procesar Venta. Fjate que el nombre comienza por un verbo en infinitivo, lo que indica que es una accin del sistema que satisface el objetivo del actor. ESPECIFICACIN DE CASOS DE USO Existen 2 formas de describir los casos de uso dependiendo del detalle y la audiencia que van a tener. As, los casos de uso sern los siguientes:
CASO DE USO DE ALTO NIVEL
El CU de Alto Nivel describe de manera muy general el objetivo del Caso de Uso y alguna informacin adicional como los actores y el tipo. Su objetivo es solo mostrar, desde un punto de vista simple, la funcionalidad sin entrar en el detalle. La notacin propuesta para este tipo de especificacin es:
Caso de Uso: Actores: Tipo: Descripcin: ILUSTRACIN <Nombre de Caso de Uso> <Lista de agentes externos indicando quin inicia el CU> <Primario, Secundario u Opcional> <Descripcin general del proceso que est resolviendo el CU> 12. DOCUMENTO DE ESPECIFICACIN DE CASO DE USO DE ALTO NIVEL
En el caso de los tipos de CU, estos son:
46
Primario: Representan los procesos comunes ms importantes del sistema. Secundario: Representan los procesos menores o menos recurrentes (raros). Opcional: Representan los procesos que pueden no ocurrir.
CASO DE USO EXPANDIDO
El CU Expandido describe en detalle, paso a paso, cmo se cumple el objetivo de este CU. Esta forma de describir el CU no se usa para todos los casos, sino que solo se utiliza para aquellos que son los principales o aquellos que aportan mayor complejidad al problema. La notacin propuesta para este tipo de especificacin es:
<Nombre del Caso de Uso> <Lista de agentes externos indicando quin inicia el CU> <Intencin del CU> <Descripcin general del CU, que es la misma que se usa en Alto Nivel> <Primario, Secundario u Opcional> y <Esencial o Real> <CU y funciones relacionadas> Curso Normal <Detalle de la conversacin interactiva entre los actores y el sistema> Cursos Alternos <Detalle de la conversacin interactiva entre los actores y el sistema> ILUSTRACIN 13. DOCUMENTO DE ESPECIFICACIN DE CASO DE USO EXPANDIDA Caso de Uso: Actores: Propsito: Resumen: Tipo: Ref. Cruzadas:
En el caso de los tipos de CU, adems de los ya vistos en el CU de Alto Nivel, son: Real: Concretos y que utilizan la tecnologa real con la cual se desarrolla el CU. Esencial: Tericos y que no poseen detalles de la tecnologa e implementacin.
Adems, la forma de describir los cursos, tanto normal como alternos, debe realizarse en un formato especfico de modo de que se explique cmo se resuelve el CU. En el caso del curso normal de eventos, se describe a 2 columnas: Una para las acciones o interacciones del actor, y la otra para las respuestas del sistema:
1. 2. 4. Accin del Actor Accin del actor Accin del actor Accin del actor Respuesta del Sistema 3. Respuesta del Sistema
Por otro lado, los cursos alternos deben hacer referencia al paso del curso normal de eventos en donde ocurre el evento y la descripcin de ste. Paso 3.
1. 2. 3. Accin alterna Accin alterna
47
DIAGRAMA DE CASOS DE USO Para complementar el modelo se utiliza una sola la visin general del sistema, actores y la relacin o interaccin que tienen stos con los Casos de Uso. Esto lo podemos hacer mediante el Diagrama de Casos de Uso, el que nos permite definir el detalle de todos los CU del Sistema como si fueran un conjunto de cajas negras. De esta forma, la visin general de las especificaciones, quedan en una sola mirada para el lector. La notacin del diagrama es la siguiente:
ILUSTRACIN 14. NOTACIN DE LOS DIAGRAMAS DE CASOS DE USO
Algunas consideraciones respecto a la notacin: La Asociacin puede utilizar multiplicidad en su definicin (1 a *), en donde es posible indicar en cada extremo si se relacionan 1 a 1 o 1 a muchos casos de uso para el mismo actor. Respecto a las relaciones especficas entre CU, podemos encontrar las siguientes (segunda columna): o Inclusin: Define un subcaso, es decir, cuando el CU referenciado est dentro de el caso general. o Extensin: Define un caso que, adems de realizar todas las especificaciones del caso original, define algunos pasos adicionales. Es equivalente a utilizar especializacin.
48
o Equivalencia: Define cuando los casos de uso poseen los mismos flujos, pero son realizados por actores diferentes. o De Requisito: Define cuando un caso de uso debe ser completado antes de que contine el referenciado. o Semejanza: Define cuando los casos de uso son similares (en objetivos), pero poseen actividades diferentes. Por ejemplo, si continuamos con lo visto sobre el problema del SPDV, podemos disear y definir un modelo de casos de uso claro con los artefactos mencionados. Vamos paso a paso tal como nos ensea esta clase:
Nombre del Sistema: Lmites: Sistema Punto de Venta (SPDV) Estados financieros de las ventas. Administracin de recursos humanos. Devoluciones y cambios de productos. Administracin de los medios de pago. Administracin de inventario.
Actores y Objetivos Actor Cliente Cajero
SecurePay Sistema de Inventario Sistema de Finanzas
Objetivo Realizar una compra de los productos seleccionados. Pagar el monto de la compra. Identificarse en el terminal. Registrar los productos de la venta. Obtener el valor total de la venta. Registrar el pago de la venta. Imprimir el recibo de la venta. Recibir solicitudes de validacin de cheques. Recibir transacciones con tarjetas de crdito y dbito. Recibir notificaciones de los productos egresados de la tienda. Recibir la informacin de cada venta realizada en un terminal de la tienda.
Especificacin de Casos de Uso Caso de Uso: CU1: Autenticar en el Sistema Actores: Cajero (I), Cliente Tipo: Primario Descripcin: Le permite al cajero ingresar su identificacin (usuario y contrasea) de manera de tener control de quin est realizando una venta. Caso de Uso: Actores: Tipo: Descripcin: CU2: Registrar Productos de una Venta Cajero (I), Cliente, Sistema de Inventario Primario Le permite al cajero ingresar cada producto a travs de los cdigos de barra a la venta actual.
Caso de Uso: Actores: Tipo: Descripcin:
CU3: Validar Medio de Pago Cajero (I), Cliente, SecurePay Primario Le permte al cajero validar en lnea aquellos medios de pago vlidos (cheque, tarjeta de crdito y dbito). ILUSTRACIN 15. PLANTILLA DE ESPECIFICACIN DE CASOS DE USO Y GLOSARIO
49
En esta plantilla est el problema del SPDV parcialmente especificado (falta trabajo). De todas maneras da una idea de cmo se vera la especificacin del problema despus del proceso de anlisis. Ahora bien, revisemos cmo se vera esto en un Diagrama de Casos de Uso:
System CU1: Autenticar en el Sistema
Sistema de Inventario CU2: Registrar Productos de una Venta Cajero
CU3: Validar Medio de Pago SecurePay
ILUSTRACIN 16. DIAGRAMA DE CASOS DE USO DEL SPDV
GLOSARIO
El glosario tiene por objetivo poner en comn entre los diferentes lectores del A/DOO la terminologa a utilizar, tanto del negocio como de la parte tcnica. Este artefacto tiene la importancia que, gracias a su informacin, podemos comenzar a definir un diccionario de datos antes de disear componentes. No existe una tcnica para encontrar el glosario, pero es recomendable de comenzar a especificarlo despus de descritas las funciones del sistema o incluso cuando se estn especificando los casos de uso, ya que van a ir saliendo en forma natural los trminos no reconocidos por el equipo. Una estructura bsica (plantilla) se sugiere a continuacin para el glosario:
Trmino ILUSTRACIN 17. DOCUMENTO DEL GLOSARIO Definicin
50
Por ejemplo, aqu est parte del glosario al problema que hemos visto durante las secciones anteriores.
Glosario Trmino Punto de Venta Caja Medio de Pago ... Definicin Lugar del supermercado donde se deben registrar las ventas del local. Dispositivo fsico que le permite al cajero ingresar datos de la venta. Forma equivalente a dinero que sirve para realizar pagos sin tener efectivo. ... ILUSTRACIN 18. GLOSARIO PARA EL PROBLEMA DEL SPDV
MODELO DE DOMINIO
Un paso importante en el anlisis y diseo OO es el modelo de dominio, el cual se utiliza como inspiracin para el diseo y como entrada para otros artefactos de UP como del diagrama de secuencia y los contratos. De esta forma, lo definimos como:
EL MODELO DE NEGOCIO, MODELO DE DOMINIO O MODELO CONCEPTUAL ES UN CONJUNTO DE ARTEFACTOS QUE DEFINEN EL DOMINIO DE ANLISIS A TRAVS DEL PROCEO Y DE LAS CLASES CONCEPTUALES, DESCRIBIENDO SUS ASOCIACIONES Y ATRIBUTOS.
An cuando los modelos de dominio son propios de la disciplina de modelado del negocio y no del anlisis como tal, son requisito del diseo y de otros artefactos del mismo anlisis, es por esa razn que es importante estudiarlos. Adems, salta a la vista que las disciplinas de UP se van entrelazando entre s dependiendo de lo que se va haciendo en el anlisis y diseo, como ahora, que a pesar de que estamos analizando los requisitos funcionales y casos de uso, necesitamos definir el modelo de dominio para poder continuar.
CONCEPTOS BSICOS
A continuacin algunos conceptos importantes que son necesarios de entender para este modelo. DOMINIO Se dice que:
EL DOMINIO O NEGOCIO ES EL ESPACIO EN EL CUAL SE EXTIENDE EL PROBLEMA PRESENTADO.
Esta sencilla definicin nos permite enmarcar nuestro problema dentro de un ambiente totalmente controlado. Por ejemplo, si hablamos del dominio sobre el problema del Punto de Venta en un Supermercado, el dominio se enmarca solo en eso, lo que corresponde al entorno al punto de venta, no ms ni menos, de manera de que todo lo que definamos tendr que ver con ese contexto.
51
CLASES CONCEPTUALES La base del modelo de dominio est primeramente en las clases conceptuales. Es por ello que se define este concepto como:
UNA CLASE CONCEPTUAL ES UNA IDEA, COSA U OBJETO DEL NEGOCIO DE ANLISIS Y QUE DEFINEN PARTE DE L A TRAVS DE SU SMBOLO, INTENSIN Y EXTENSIN.
Como podemos ver, en esta definicin estamos definiendo parte de la notacin UML de las clases conceptuales a travs de los elementos que la componen. Estos elementos son: Smbolo: palabras o imgenes que representan una clase conceptual. Intensin: la definicin de la clase conceptual. Extensin: el conjunto de ejemplos a los que se aplica la clase conceptual. Por ejemplo, si consideramos el evento de transaccin de compra de producto como una clase conceptual, desde el punto de vista del sistema podramos bautizarlo como Venta. Desde el punto de vista prctico en la construccin del modelo del dominio, solo el smbolo y la intensin suelen tener la mayor importancia. Es importante tener clara la diferencia entre estas clases y las clases de componentes de software que veremos en el diseo, ya que pueden confundirnos, adems de que los modelos de dominio no sirven en la implementacin. De esta manera, debemos tener claro que un modelo de dominio no debe contener: Artefactos de Software, como bases de datos, ventanas, a menos que en el dominio se estn modelando componentes de software. Responsabilidades o mtodos de las clases conceptuales, ya que no deben representar las funcionalidades que tienen. Una diferencia importante cuando realizamos el anlisis desde el punto de vista de objetos, en vez de un proceso estructurado, es que centramos el modelo en los objetos y no en las funciones. PROCESO Una segunda derivada de este modelo es el anlisis del dominio a travs del proceso que se ve impactado por el problema planteado, y para ello definiremos que:
UN PROCESO ES CONJUNTO DE ACTIVIDADES O EVENTOS QUE DEBEN OCURRIR DENTRO DEL DOMINIO PARA SATISFACER EL OBJETIVO O FIN DE LOS USUARIOS DE STE.
52
A pesar de que esta definicin es ms especfica que la que tiene la palabra original proceso es porque la estamos especificando dentro del concepto del modelo. De esta manera, consideraremos al proceso como una vista dinmica del dominio que estamos analizando, y que ser necesario modelar, de manera de tener la visin completa de qu estamos afectando con nuestro sistema.

Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos artefactos son: Diagrama de Actividades: Diagrama que muestra cmo es el proceso de negocio que se est interviniendo con el sistema que est en anlisis. Diagrama de Clases Conceptuales: Diagrama que muestra la relacin de los conceptos importantes del domino tienen en forma esttica dentro del proceso intervenido por el sistema en anlisis.
Veamos ahora cmo se desarrollan estos artefactos.

Para crear los entregables del modelo (es decir, los artefactos de ste), se necesita proceder a travs del uso de tcnicas o recetas. Veamos la tcnica de identificacin y descripcin del proceso y de las clases conceptuales: ESPECIFICACIN DEL PROCESO DE NEGOCIO La sintaxis de los diagramas de actividad es muy sencilla ya que se asemeja a lo que en otras metodologas o notaciones se conocen como diagramas de flujo, pero con la salvedad que la orientacin de estos ltimos se refiere al flujo de datos y los de actividad su centro es el flujo funcional o de actividades del proceso.
53
Sintaxis Diagrama de Actividad

Accin
Accin
Decisin / Merge
Nodo Inicial
Fork
Nodo Final de Flujo
Join
Flujo de Control
<sin accin enviar>
Envo de Seal
Nodo Conector
<sin accin recibir>
Receptor de Seal
Objeto
Objeto
Seal de Tiempo
Accin Info <<precondicion>> (condicion)
Pines
Excepcin
Precondicin
Calle
Nodo Final de Actividad
<<postcondicion>> (condicion)
Postcondicin
Calle (Swimlane)
ILUSTRACIN 19.NOTACIN DE LOS DIAGRAMAS DE ACTIVIDADES
Su utilizacin ser un poco ms especfica que respecto a los casos de uso ya identificados. Es importante notar que, cuando definimos los CU es posible que hayamos encontrado algunos casos en donde tengamos inclusin, dependencia o generalizacin, pero que desde el punto de vista del EBP esto no es relevante. Por ejemplo, en el caso de la caja de supermercado, podemos haber encontrado el siguiente diagrama de casos de uso:
System
CU2: Registrar Productos de una Venta Sistema de Inventario
Cajero CU3: Validar Medio de Pago
SecurePay
ILUSTRACIN 20. DIAGRAMA DE CASOS DE USO DEL SPDV
54
Podemos ver que CU2: Registrar Productos en la Venta no tiene conexin con el CU3: Validar Medio de Pago ya que la importancia est en focalizar en que sean casos reusables. Sin embargo, desde el punto de vista del proceso solo es necesario definir el Proceso de Venta, la cual si incorpora la validacin y proceso pago. De esta manera, cuando queremos confeccionar el diagrama de actividad del proceso de venta, nos centraremos en todos los pasos necesarios para realizar una venta especfica:
Iniciar Venta
Ingresar Producto
[cod valido]
Venta
Obtener Informacin
[cod no valido]
Registrar Producto
Rechazar Cdigo [hay mas productos] [no hay mas productos] Calcular Total
[cliente paga] Registrar Pago
Pago
Imprimir Comprobante
ILUSTRACIN 21. DIAGRAMA DE ACTIVIDADES PARA EL SPDV
Es importante identificar el proceso para el conocimiento del dominio, de manera de que el diagrama de actividades entregue mayor informacin al problema. IDENTIFICACIN DE CLASES CONCEPTUALES Antes de comenzar a descubrir las clases conceptuales, es importante saber que debemos identificar las clases de los mismos casos de uso ya especificados en el modelo de casos de uso. En cada iteracin se va definiendo cul o cules son los escenarios a estudiar y referente a ellos se comienza a definir el modelo de dominio.
55
PASO 1. IDENTIFICAR LAS CLASES CONCEPTUALES No existe la forma correcta de obtener las clases conceptuales, sino ms bien existen un grupo de recomendaciones al respecto que nos permiten utilizar las herramientas entregadas por el negocio para ste proceso prctico. La literatura menciona dos formas de obtener las clases conceptuales: por clasificacin en categoras de clases y por identificacin de frases nominales en las especificaciones de casos de uso. Veamos cada una de estas formas complementndolas con algunos ejemplos:
MTODO 1: IDENTIFICACIN POR CLASIFICACIN DE CLASES CONCEPTUALES
La primera tcnica postula la utilizacin de una lista de categoras de clases conceptuales. Esta lista comprende un conjunto de clases candidatas a ser conceptuales, acompaadas de ejemplos tpicos para esas clases, dentro de dominios similares al que estamos analizando. Estas categoras son: Objetos tangibles o fsicos: Todos los objetos o elementos fsicos que participan directamente en el dominio. Especificaciones, diseos o descripciones de las cosas: Caractersticas o descripciones que sean de vital importancia para el dominio. Lugares: Espacios fsicos en donde el dominio toma sentido. Lneas de la transaccin: Entradas necesarias para la ejecucin del dominio. Roles de las personas: Roles que puede tomar la gente que participa en el dominio. Contenedores de otras cosas: Elementos fsicos que sean agrupadores de otros elementos. Cosas en un contenedor: Objetos que pueden ser contenidos en un contenedor. Otros sistemas externos: Sistemas que estn fuera del dominio pero que se requieren para l. Conceptos abstractos: Conceptualizaciones u objetos no fsicos que representan un valor agregado al dominio. Organizaciones: Secciones y organizaciones que participen en el dominio. Hechos: Interacciones o eventos que entregan un valor o participan del dominio. Procesos: Serie de acciones que sean parte del dominio de anlisis. Reglas y polticas: Restricciones o intereses que puedan ser relevantes en algn proceso. Catlogos: Contenedores lgicos de informacin.
56
Registro de finanzas, trabajo, contratos, asuntos legales: Elementos de tipo legal o de validez tributaria. Instrumentos y servicios financieros: Elementos de importancia que tengan que ver con las finanzas. Manuales, documentos, artculos de referencia, libros: Documentacin relacionada con el dominio. Por ejemplo, si utilizamos el listado de categoras habituales para el dominio de la venta de un supermercado, podemos encontrar algunos candidatos para cada categora, los cuales los ubicaremos en la siguiente tabla:
Categora de Clase Conceptual Objetos tangibles o fsicos Ejemplos Registro Caja Producto Boleta Especificaciones, diseos o descripciones de las cosas NombreDelProducto Lugares Tienda Departamento Lneas de la transaccin LneaDeVenta Roles de la gente Cajero Supervisor Cliente Contenedores de otras cosas Tienda CarroDeCompras Cosas en un contenedor Producto Otros sistemas externos SistemaPagoTransbank SistemaInventario Conceptos abstractos ColaDeClientes Organizaciones DepartamentoDePersonal ProveedorDeProductos Hechos Venta Pago Empaque Procesos Venta ImpresinDeBoleta EliminacinDeProducto Reglas y polticas ComisionesPorVenta Catlogos N/A Registro de finanzas, trabajo, contratos, asuntos legales Boleta Factura ContratoDeEmpleo SolicitudDeReposicin Instrumentos y servicios financieros Stock Manuales, documentos, artculos de referencia, libros ListaDePrecios CatastroDeCajeros ILUSTRACIN 22.TABLA DE IDENTIFICACIN DE CLASES CONCEPTUALES SEGN CATEGORAS
Como podemos ver en el ejemplo, tenemos muchos candidatos a ser clases del dominio, sin embargo, tal como dice su definicin, ellos son solo posibles clases conceptuales que debemos determinar su validez dentro del dominio de anlisis.
57
MTODO 2. IDENTIFICACIN POR FRASES NOMINALES EN LAS ESPECIFICACIONES
Otra tcnica es identificar candidatas a clases conceptuales desde el escenario, utilizando las frases nominales de ella. Esto se realiza haciendo un anlisis lingstico de las especificaciones de los casos de uso del sistema en anlisis. Por ejemplo, si tomamos el escenario principal de xito del caso de uso Procesar Venta del ejemplo de la caja del supermercado, tenemos el siguiente escenario:
1. 2. 3. 4. El Cliente llega a la caja con los productos. El Cajero comienza una nueva venta en el Sistema. El Cajero ingresa el producto al Sistema. El Sistema registra el producto en la lnea de venta indicando el precio y la suma parcial.
Se repiten los pasos 3 y 4 mientras existan productos por ingresar a la venta. 5. 6. 7. 8. 9. El Cajero solicita el total de la venta al Sistema. El Sistema presenta el valor total de la venta. El Cajero le dice al Cliente el total de la venta para que pague. El Cliente paga al Cajero. El Cajero ingresa el pago en el Sistema.
10. El Sistema registra la venta en el Sistema de Contabilidad, y la informacin de los productos vendidos en el Sistema de Inventario. 11. El Sistema emite la boleta/recibo y cierra la venta. 12. El Cajero entrega el recibo al Cliente. 13. El Cliente se retira con el recibo y los productos comprados. ILUSTRACIN 23.ANLISIS DE CLASES CONCEPTUALES POR FRASES NOMINALES
En este caso solo tomamos el escenario principal de xito a modo de ejemplo, sin embargo es importante tomar tambin las extensiones del caso de uso, ya que pueden ser fuente de nuevas clases conceptuales y que servirn en el diseo. Ntese que hemos subrayado conceptos que despus pueden convertirse en clases conceptuales. Sin embargo, dependiendo del lenguaje se puede llegar a conceptos diferentes para representar clases conceptuales equivalentes. Es por eso que la recomendacin que realizan algunos autores al respecto es que se mezcle esta tcnica con la anterior de lista de categoras.
OTRAS RECOMENDACIONES PARA REFINAR EL MODELO
Un grupo de recomendaciones para la identificacin de las clases conceptuales se puede enumerar de la siguiente forma: Utilice siempre los nombres existentes en el dominio en cuestin. Trate de no usar conceptos que no sean parte del dominio de anlisis, ya que estos pueden traer consigo confusin desde el punto de vista conceptual. 58
Excluya siempre las caractersticas y clases conceptuales que sean consideradas irrelevantes para el negocio de anlisis. No incluya conceptos o atributos que sean irreales en el domino. Esto quiere decir, que es importante excluir todo aquellos conceptos que no existan realmente en el domino. Utilice el concepto de informe solo cuando ste sea un elemento que no redunde en la informacin entregada por las otras clases conceptuales. En muchos casos, el reporte o informe (como el recibo) en realidad son un medio de informacin obtenida desde otras clases conceptuales, lo que llevara a dejarlo fuera del modelo. Cuando descubra una candidata a clase conceptual en donde posea una caracterstica que sea un nmero o un nombre que identifica otro concepto, es probable de que en realidad no sea una clase conceptual sino que un atributo. Utilice clases conceptuales de especificacin de objetos para mantener la informacin en la memoria del sistema. Estas clases son tiles considerando siempre que todos en el negocio tienen amnesia, de manera que esas especificaciones (como el detalle de un objeto particular) queden como parte de la memoria sistmica del negocio, reduciendo as la informacin duplicada. Estas recomendaciones no son nada ms que una gua para ayudar al proceso de identificacin de las clases conceptuales. PASO 2. IDENTIFICAR ASOCIACIONES ENTRE CLASES CONCEPTUALES Las asociaciones, segn UML, son la relacin semntica entre dos o ms clasificadores que implica conexiones entre sus instancias. Tal como se detall en la sintaxis de los modelos de dominio, la asociacin debe ir acompaada de un nombre que define qu tipo de asociacin es. Este nombre indica cul es la relacin entre las instancias asociadas de alguna forma. Estos nombres son escritos separados por un guin y no por espacios, por ejemplo, para indicar la asociacin entre la caja y la venta, podemos decir que la caja registra la actual venta, lo que se traducira en la asociacin registra-la-actual. Adems del nombre, en algunos casos se puede especificar con una cabeza de flecha la navegabilidad de la asociacin, es decir, en qu sentido se lee dicha asociacin. Por ejemplo:
contiene Venta 1 1..*
LineaDeVenta
ILUSTRACIN 24.EJEMPLO DE ASOCIACIN DE CLASES CONCEPTUALES
Este ltimo detalle generalmente se excluye, porque basta mirar el modelo para darse cuenta de la navegabilidad del mismo.
59
Por ltimo, en los extremos de las asociaciones van lo que se conoce como Roles. Estos elementos definen cul es la relacin que se tiene con dicho objeto, por ejemplo, nmero de elementos (multiplicidad) como veremos ms adelante.
MULTIPLICIDAD DE ASOCIACIONES
Cuando especificamos la multiplicidad debemos indicar en cada lado de la asociacin la cantidad de objetos con las cuales se relaciona. Estas multiplicidades pueden ser: A 1 1 B
1 objeto de A se relaciona con 1 y solo 1 objeto de B. Ambos objetos deben existir (obligatorio)
1..*
1 objeto de A se relaciona con 1 o ms objetos de B. En este caso el mnimo de objetos de B debe ser 1 (obligatorio).
0..1
1 objeto de A se puede relacionar o no con 1 objeto de B. En este caso, si no existe el objeto B, A puede seguir existiendo (optativo).
1 objeto de A se puede relacionar o no con objetos de B. En este caso, no existe un mnimo ni un lmite de objetos de B (optativo).
ILUSTRACIN 25.TABLA DE CLASIFICACIN DE MULTIPLICIDAD
Algunos diagramas requieren multiplicidades ms especficas. En ese caso, el indicador de multiplicidad es el nmero exacto de objetos relacionados (o en su defecto, los nmeros exactos, si pueden ser ms de uno). Por ejemplo, A almacena 3 objetos de B en forma obligatoria, por lo que en la asociacin pondremos un 3 al lado de B.
CRITERIO PARA DEFINIR LAS ASOCIACIONES
La definicin de las asociaciones corresponde a una labor muy delicada, ya que en un anlisis podra aparecer que todo es relevante para todo, o que todas las clases poseen alguna relacin con las otras. Es por eso que al momento de definir las asociaciones, es importante definir: Asociaciones en donde es necesario conservar el conocimiento de la relacin por algn tiempo. Asociaciones comunes que son de alta prioridad (parte-de, contenida-en, registra-a). Otras asociaciones comunes que cumplan con las especificaciones del dominio en anlisis. No es recomendable poner muchas asociaciones o sobrecargar el modelo con asociaciones redundantes, porque el beneficio es realmente marginal. Por otro lado, es ms importante definir las clases conceptuales que las asociaciones (adems, nos daremos cuenta que saltan a la vista las asociaciones a partir de las clases conceptuales). El listado de las asociaciones ms comunes es: A es una parte de B A est contenido en B 60
A es una descripcin de B A es una lnea de una transaccin o informe de B A se conoce/registra/recoge/informa/captura en B A es miembro de B A es una subunidad organizativa de B A utiliza/gestiona B A se comunica con B A est relacionado con una transaccin B A es una transaccin relacionada con otra transaccin B A est al lado de B A es propiedad de B A es un evento relacionado con B PASO 3. AADIR ATRIBUTOS Los atributos, en general, son valores de datos lgicos de los objetos. En el modelo de dominio, los atributos se presentan solo con el nombre, y en algunos casos particulares, podran presentarse tambin con sus tipos (pero eso es opcional y es poco usado en la prctica), indicndolo despus del atributo con :. Para agregar los atributos, debe especificar aquellos valores que son relevantes para entender el modelo de dominio. Esto quiere decir, que cuando se estn definiendo los atributos, no ponga todos los valores que se le vengan a la cabeza, sino que los ms importantes para el problema. De esta forma, y considerando el ejemplo mencionado de Procesar Venta, podemos identificar los atributos de las clases conceptuales descritas anteriormente. Estos son: Tienda Producto direccin: El recibo requiere la direccin de la sucursal. cdigo: El producto debe tener un cdigo que lo hace nico. nombre: El detalle que describe el producto en pantalla. precio: El precio se usa para calcular el total de la venta. Venta Pago fecha, hora: El recibo mostrar la fecha y la hora de la venta. LneaDeVenta cantidad: Esta entrada se indica en la venta la cantidad comprada. cantidad: Sirve para calcular el cambio, si es que excede el valor total.
Ntese que muchas clases conceptuales no las especificamos aqu, an cuando si las usaremos en el ejemplo final. Solo hemos descrito aquellas a las que le agregaremos los atributos. Las dems, no requieren algn atributo en particular. Para concluir, todas las asociaciones y atributos deben ser agregado al diagrama parcial para completarlo de manera tal que represente el dominio de anlisis.
61
DIAGRAMA DE CLASES CONCEPTUALES A diferencia de lo visto en el modelo de casos de uso, en este caso la tcnica o proceso se mezcla con el diagrama, ya que finalmente no hay artefactos intermedios (excepto la tabla de identificacin de clases conceptuales por categoras) que puedan agregar valor al modelo. Es por eso que es recomendable que una vez establecidas las candidatas a clases conceptuales se comience inmediatamente con el diagrama. La notacin del diagrama es la siguiente:
Notacin Diagramas de Clases Conceptuales

metaclass Nombre -a
Metaclase
1..1 0..* -a
Asociacin
Nombre -atrib : byte
Agregacin Clase
1..1 0..* -a
Composicin
1 Objeto 0..*
Objeto/Instancia Herencia/Generalizacin
interface Interfaz
Interfaz Implementacin de Interfaz

Interfaz
ILUSTRACIN 26.NOTACIN DE LOS DIAGRAMAS DE CLASES CONCEPTUALES
La notacin UML de estos diagramas es similar a la que se utiliza para los diagramas de clases, porque en realidad eso son, pero sin definir operaciones y solo enumerando atributos. Sin embargo, la gran diferencia es que las clases definidas en este diagrama son en realidad conceptos del dominio y no clases de software. Por esta razn, a estas clases se las llama clases conceptuales ya que son, en realidad una idea, cosa u objeto que representan en forma abstracta los elementos que participan en dominio de inters. De la misma manera como hicimos entonces con el Modelo de Casos de Uso, podemos continuar el ejemplo con el Diagrama de Actividades. En este caso, este diagrama nos define el proceso de venta, que comienza desde que el cliente llega a la caja, hasta que se retira de ella con los productos comprados. El proceso quedara de la siguiente forma:
62
Iniciar Venta
Ingresar Producto
[cod valido]
Obtener Informacin
[cod no valido]
Registrar Producto
Rechazar Cdigo [hay mas productos] [no hay mas productos] Calcular Total
[cliente paga] Registrar Pago
Imprimir Comprobante
ILUSTRACIN 27.DIAGRAMA DE ACTIVIDADES DEL SPDV
As mismo, el diagrama de clases conceptuales del problema es el siguiente:

Cliente 1 inicia 1 Venta Pago 1 genera 1 se-valida-en Cajero 1 1 SecurePay Tienda 1 1 SistemaDeInventario 1 1 genera utiliza registra Caja informa 1 1..* alberga 1..* 1 Catalogo contiene 1 0..* 1 0..* contiene 1..* 1 1 registra
LineaDeVenta
0..1
Producto
ILUSTRACIN 28.DIAGRAMA DE CLASES CONCEPTUALES DEL SPDV
63
MODELO DE COMPORTAMIENTO
Segn lo que ya hemos dicho, el modelo de comportamiento lo podemos definir como:
UN CONJUNTO DE ARTEFACTOS QUE PERMITEN IDENTIFICAR EL COMPORTAMIENTO DEL SISTEMA O PARTES DEL MISMO A TRAVS DE LOS ESCENARIOS PRESENTADOS EN EL MODELO DE CASOS DE USO Y EN FUNCIN DE LAS CLASES CONCEPTUALES.
Como podemos reafirmar, la idea ahora es analizar el sistema desde el punto de vista funcional tomando en cuenta los requerimientos y conceptos del dominio como si fuera una o ms cajas negras.
CONCEPTOS BSICOS
A continuacin algunos conceptos importantes que son necesarios de entender para este modelo. EVENTO Diremos que:
UN EVENTO ES UNA INTERACCIN QUE EXISTE ENTRE UN ACTOR EXTERNO Y EL SISTEMA.
Esta definicin tan sencilla tiene su base en lo que ya hemos definido como mensaje al principio del curso, pero con un matiz especial: no es una interaccin entre objetos sino que entre un actor y el sistema. CONTRATO Una definicin enciclopdica nos indica que:
UN CONTRATO ES UN ACUERDO DE VOLUNTADES QUE GENERAN DERECHOS Y OBLIGACIONES.
Bsicamente esta definicin puede ser aplicada directamente al modelamiento de comportamiento, ya que se refiere a una serie de acciones y restricciones que se deben cumplir. En el contexto del modelo en s, hablaremos siempre de contratos de las operaciones (lo que veremos en detalle cuando hablemos del artefacto respectivo). ESTADO Podemos decir que:
64
UN ESTADO ES UNA CONFIGURACIN NICA DE INFORMACIN EN UN PROGRAMA O MQUINA.
Como podemos ver el concepto es bastante amplio, ya que hace referencia a un estado en su forma genera. Sin embargo, tambin podemos encontrar una definicin ms ad-hoc que dice que es un conjunto particular de instrucciones las cuales sern ejecutadas en respuesta a la entrada de la mquina.

Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos artefactos son: Diagrama de Secuencia: Diagrama que muestra cules son los eventos del sistema a partir de los escenarios descritos en los casos de uso. Contratos de las Operaciones: Documentos que describen cada operacin del sistema (eventos entre el actor principal y el sistema) como si fuera una mquina de estados de tipo caja negra. Diagrama de Estados: Diagrama que muestra una visin de mquina de estados para objetos o procesos del dominio.

Para crear los entregables del modelo (es decir, los artefactos de ste), se necesita proceder a travs del uso de tcnicas o recetas. Veamos cada una de ellas en detalle. DIAGRAMAS DE SECUENCIA DE LOS EVENTOS DE CASOS DE USO Los Casos de Uso describen cmo interactan los actores externos con el sistema de software que estamos estudiando. Estas interacciones generalmente gatillan eventos sobre el sistema a travs de operaciones y alguna respuesta que ste le da. Con esta motivacin, UML define que:
EL DIAGRAMA DE SECUENCIA DEFINE GRFICAMENTE PARA UN ESCENARIO ESPECFICO DE UN CASO DE USO LOS EVENTOS QUE GENERAN LOS ACTORES EXTERNOS, EL ORDEN Y LOS EVENTOS ENTRE LOS SISTEMAS DE APOYO.
Todos los sistemas se ven como cajas negras, es decir, no entramos a mirar cul es su implementacin o cmo funcionan, sino que interactuamos directamente con ellos.
65
Pero cmo y cundo hacer un diagrama de secuencia del sistema? La teora dice que el diagrama debe ser hecho tanto para el escenario de xito como para los escenarios alternativos complejos o frecuentes (por ejemplo, utilizando los medios de pago en nuestro modelo de caja de supermercado). Para hacer estos diagramas, se necesita entender algo de la anatoma de ellos. Es por eso que definimos la notacin UML de los diagramas a continuacin:
Notacin Diagramas de Secuencia
Mensaje :Objeto
Objeto (Actor/Sistema)
Mensaje o Interaccin
Lnea de Vida
Mensaje
Autodelegacin
Retorno
Activacin
Mensaje
Mensaje de Retorno
Nota / Restriccin
Mensaje Asncrono
Loop Loop
[cond]
[cond1]
Ciclo
[cond2]
Flujos Alternos
ILUSTRACIN 29. NOTACIN DE LOS DIAGRAMAS DE SECUENCIA
Como es de esperar, existen tambin mensajes en los cuales se puedan crear nuevos objetos. Estos mensajes se les dice de Creacin y se interpretan como una flecha a una caja de instancia nueva (a la misma altura). Es decir, no todas las instancias del sistema se ven a la misma altura (arriba) sino que algunas aparecen dependiendo se van creando.
: Caja : Venta 2 : nuevo()
ILUSTRACIN 30. MENSAJE DE CREACIN DE OBJETO
Otra particularidad son los llamados Autodelegacin, las cuales corresponde a una autollamada de alguna actividad o mensaje que se realiza en el mismo objeto.
66
: Pago
5 : registrarPago()
ILUSTRACIN 31. MENSAJE DE AUTODELEGACIN
A partir de toda esta notacin podemos generar los diagramas de secuencia a cualquier nivel del proyecto, pensando en un anlisis inicial (como en el ejemplo), como as en un anlisis un poco ms avanzado, con objetos y mensajes entre ellos. Por ejemplo, el mismo ejemplo que ya habamos visto, lo podemos separar un poco con algunos objetos conceptuales bien claros:
: Cajero : Caja : Venta 2 : nuevo() : Catalogo
1 : iniciarVenta()
4 Loop [p] 5 : ingresarProducto()
6 : p := obtenerProducto()
8 : agregar()
9 10 11 : finalizarVenta() 12 : t := obtenerTotal() 13 : calcularTotal()
14 15
ILUSTRACIN 32. DIAGRAMA DE SECUENCIA PARA EL PROCESO DE VENTA (SIN PAGO) DEL TPDV.
Como podemos observar en el ejemplo, el flujo se parece mucho al que inicialmente habamos planteado como solucin, con la diferencia en que incluimos un elemento llamado Venta y otro 67
Caja, en lo que representamos los principales elementos de la venta. En este caso, la caja representa el aparato fsico con el cul interacta el Cajero y la Venta es un objeto que representa el carro de compras que trae el Cliente y que permite calcular el valor de la compra y el detalle del recibo. CONTRATOS DE LAS OPERACIONES Hasta ahora, nuestro anlisis se ha basado en una metodologa basada en los casos de uso, y esto muchas veces es suficiente para describir el comportamiento del sistema que se est analizando. Sin embargo, existen otro tipo de artefactos que, en casos particulares, nos sirven para describir en detalle ciertas operaciones. De esta forma, definimos:
LOS CONTRATOS DE LAS OPERACIONES DEL SISTEMA DESCRIBEN EL RESULTADO DE LA EJECUCIN DE LAS OPERACIONES DEL SISTEMA EN FUNCIN DE LOS CAMBIOS DE ESTADO DE LOS OBJETOS DEL DOMINIO.
Con esta definicin de libro podemos comenzar por preguntarnos cules son las operaciones del sistema. Ahora bien, veamos primero la sintaxis del contrato antes de pasar al ejemplo de cmo se describe uno. Al igual que las especificaciones de los casos de uso, los contratos se escriben como textos bajo cierta estructura o anatoma. Esta estructura se compone de las siguientes secciones:
Operacin: <Operacin del sistema>
Responsabilidad: <Objetivo de la operacin>
Tipo o Clase: <Sistema, Concepto, Interfaz, Clase> Ref. Cruzadas: <CU donde aparece> Notas: <Notas de diseo, algoritmos e informacin> Excepciones: <Casos excepcionales> Salida: <Salidas hacia fuera del sistema> Precondiciones: <Suposiciones acerca del estado antes> Postcondiciones: <Estado despus de la aplicacin de la operacin>
ILUSTRACIN 33. NOTACIN PARA LOS CONTRATOS DE LAS OPERACIONES
Veamos como ejemplo el CU1. Realizar Venta. El diagrama se secuencias de ese caso de uso sera el siguente:
68
: Cajero : Caja : Venta 2 : nuevo() : Catalogo
1 : iniciarVenta()
CO1
4 Loop [p] 5 : ingresarProducto() 3
6 : p := obtenerProducto()
CO2
8 : agregar()
9 10 11 : finalizarVenta() 12 : t := obtenerTotal() 13 : calcularTotal()
CO3
14 15
ILUSTRACIN 34. DIAGRAMA DE SECUENCIA CON LAS OPERACIONES DE LA VENTA
Como podemos ver hemos destacado los 3 posible contratos a travs de las operaciones del sistema (las que vienen del mundo exterior). Utilicemos la operacin ingresarProducto de nuestro diagrama de secuencia antes mostrado.
Operacin: CO2. ingresarProducto(cod : CodigoBarras, cant : Int) Responsabilidad: Ingresar un producto representado por cod a la venta en curso. Tipo o Clase: Sistema Ref. Cruzadas: CU1. Realizar Venta Notas: Excepciones: - Si cod no existe, error. Salida:
69
Operacin: CO2. ingresarProducto(cod : CodigoBarras, cant : Int)

Precondiciones: - Exista una instancia v de tipo Venta. - Exista una instancia c de CatalogoDeProductos. Postcondiciones: - Se haya encontrado una instancia p de Producto en el catlogo c que tenga como valor del atributo cdigo igual al valor cod entregado. - Se haya creado una nueva instancia ldv de LneaDeVenta. - Se haya asociado p a ldv. - Se haya cambiado el valor cantidad de ldv por n entregado. - Se haya asociado ldv a v.
ILUSTRACIN 35. CONTRATO PARA LA OPERACIN INGRESARPRODUCTO DEL TPDV
Como podemos ver en el ejemplo, el contrato describe el funcionamiento desde el punto de vista lgico de la operacin en estudio. Es importante hacer notar que las postcondiciones que se describen en el contrato deben ser consistentes con lo especificado en el Modelo de Dominio, ya que los tipos y objetos a los cuales se hace referencia, adems de las asociaciones que aparecen, representan lo especificado en este modelo. TIPOS DE POSTCONDICIONES Las postcondiciones son solo de 3 tipos: De creacin de instancias, que indican cuando se genera una nueva instancia de una clase. De formacin o rotura de asociaciones, que indican cuando se asocian o desasocian instancias. De cambio en atributo, que indican asignaciones de informacin dentro de las instancias. En nuestro ejemplo, [Creacin de Instancia] Se crea una instancia de LneaDeVenta ldv. [Formacin de Asociacin] ldv se asocia a la Venta actual. [Cambio de Atributo] La cantidad de la ldv pasa a ser igual a cant. [Formacin de Asociacin] Se asocia un DetalleDelProducto a ldv que corresponde al detalle del producto identificado por cod. RECOMENDACIONES Cuando se estn describiendo los contratos, se tienen que tener en cuenta algunas recomendaciones bsicas que nos ayudarn a obtener un buen anlisis de las operaciones del sistema. Estas recomendaciones son: Utilice los mismos nombres de los eventos utilizados en el diagrama se secuencia como nombres de las operaciones a estudiar. 70
Los parmetros exprselos en una forma simple, indicando un tipo primitivo o una clase conceptual del modelo de dominio. Identifique si los contratos pueden ser utilizados en otros casos de uso, ya que esto le permitir reutilizar esta informacin en el diseo y mejor an, encontrar patrones comunes entre los casos de uso. Las precondiciones deben ser expresadas en verdades absolutas y no supuestos condicionales, ya que en el contrato no se pone en duda su validez. Las postcondiciones exprselas siempre como tiempo pasado, es decir, destaque que la postcondicin es un resultado de una operacin que se realiza antes de que acabe la ejecucin de la misma. Para identificar las postcondiciones, realice el siguiente ejercicio mental: tome una fotografa del escenario antes de la operacin, luego ejecute la operacin a ojos cerrados como en una caja negra y saque otra nueva fotografa del escenario al finalizar. Compare ambas fotografa y obtendr las postcondiciones expresadas como un cambio de estado del escenario. Por ltimo, no utilice los contratos como requisito de sus anlisis. Los contratos son tiles cuando describen detalles que no se pueden inferir del modelo de casos de uso ya desarrollado, por lo que debemos saber elegir cundo utilizarlos y cuando no. LOS CONTRATOS Y LOS CAMBIOS AL MODELO CONCEPTUAL Es normal, y tengan la certeza que se toparn con esta situacin, que a partir de los contratos sea necesario interferir el modelo de dominio o conceptual definido. Es por eso que, cuando describimos nuestros contratos, podemos encontrar algunos detalles que cambiar. Por ejemplo, para el contrato de la operacin de finalizarIngreso() del diagrama que hemos estado estudiando tenemos que hemos incorporado un flag de validacin que avisa cuando la venta es completa. Este atributo debe estar indicado en el modelo conceptual, ya que desde el punto de vista del anlisis es un detalle importante, por lo que en la clase Venta del modelo deberemos incorporarlo como atributo de la clase con alguna notacin adicional: esCompleta: ValorDeVerdad DIAGRAMAS DE ESTADO Para complementar la el modelo de comportamiento, se puede definir:
EL DIAGRAMA DE ESTADO REPRESENTA LOS EVENTOS Y ESTADOS INTERESANTES DE UN OBJETO Y EL COMPORTAMIENTO DE UN OBJETO COMO REACCIN A UN EVENTO.
esCompleta: Boolean
Con esta definicin, podemos inferir que los diagramas de estado cobran mucho sentido cuando queremos ver el comportamiento de los objetos o del mismo caso de uso desde un punto de vista de caja negra. La notacin que utilizan los diagramas de estado es:
71
Notacin Diagramas de Estado

Estado
Estado
evento [cond] / actividad
Actividad Regular
Estado Inicial / Cruce
Estado entry/accion do/accion exit/accion
Actividad de Estado
Estado Final
Estado de Trmino
Historial Superficial
Decisin
H*
Historial Recursivo
Estado
Compuesto No Ortogonal
Compuesto Ortogonal
ILUSTRACIN 36. NOTACIN DE LOS DIAGRAMAS DE ESTADO
En el caso de las acciones, stas pueden ser condicionadas (usando la misma nomenclatura del diagrama de secuencia, con la condicin entre corchetes) y tambin automticas, las cuales se representan sin ninguna accin sobre la flecha. Entonces, cul es la utilidad de estos diagramas?. La respuesta a esta pregunta no es fcil. Si nos vamos a ver directamente los artefactos UML que participan en el UP, nos encontraremos que no existe un Modelo de Estados que represente algo en particular. Los diagramas de estado ms bien son complementarios a los artefactos definidos para cada disciplina, ya que permiten incorporar mayor detalle y entendimiento a algunos procesos o clases complejas para el entendimiento del pblico objetivo. De esta forma, para mantener el orden en el proceso unificado adaptado al curso, utilizaremos los diagramas de estado para un uso muy particular: describir los estados y eventos para los objetos principales del sistema identificados en el modelo de comportamiento. Por ejemplo, para nuestro ejemplo de la caja de supermercado, podremos ver que a travs de los contratos la Venta (o sea las instancias de Venta) son las que ms sufren cambios de estado. En efecto, en el CO1 el objeto v es creado, en el CO2 se le agrega una instancia de LineaDeVenta (tantas veces como se realiza esa operacin) y en el CO3 se cambia el estado y se deja como cerrada. Veamos el diagrama que define estos estados para un mayor entendimiento:
72
agregar crearVenta Creada entry/fijarFecha En Construccin do/asociarLineaDeVenta
calcularTotal
Pagada exit/asociarPago exit/cambiarEstado registrarPago
Calculada exit/fijarTotal
ILUSTRACIN 37. DIAGRAMA DE ESTADOS PARA EL OBJETO VENTA DEL TPDV
Como se observa en el diagrama, los eventos saltan a la vista en el diagrama de estados como las operaciones que los gatillan en el diagrama de secuencias, y las actividades de estado aparecen como los cambios de estado que se describen en los contratos respectivos. Por otro lado, no todas las transiciones tienen un evento definido, en ese caso no se requiere un evento, sino que es una transicin automtica (una vez que es Creada, pasa automticamente a En Construccin). Es importante, entonces, que los eventos se definan de la misma forma como fueron identificados en los diagramas de secuencia y las actividades como fueron identificadas en los contratos de las operaciones.
CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP)

El Centro Mdico de Especialidades y Laboratorios Clnicos, conocido como CEMELAB, es un servicio que de atencin mdica (consultas) de diferentes especialidades y laboratorio para diferentes exmenes mdicos a lo largo de todo el pas. CEMELAB posee convenio con casi todas las ISAPRES lo que la hace una excelente alternativa. El gerente general ha decidido implantar un sistema electrnico de fichas mdicas e historial de pacientes (SEFP) para realizar todo el seguimiento de los pacientes independientemente de donde se atiendan o realicen los procedimientos indicados por los especialistas. Este sistema de ficha electrnica est reemplazando al sistema actual de fichas de atencin que tiene cada centro. Para el diseo del SEFP se ha contratado a su consultora, la cual ha realizado una primera entrevista obteniendo una descripcin aproximada del proceso y ciclo de vida de la ficha en cuestin. Esta informacin incluye la siguiente: 1) Cuando un paciente nuevo llega a cualquier centro, se le crea una nueva ficha mdica, la cual debe ser completada con la informacin bsica del individuo (nombre completo, rut, direccin, telfono de contacto y correo electrnico si tuviera). Estos datos deben ser
73
ingresados en la recepcin correspondiente (ya sea en el laboratorio como en la recepcin de atencin mdica). 2) Cuando un especialista atiende a un paciente, ste podr ver la ficha completa del individuo para poder realizar un seguimiento completo. Esto lo hace a travs del terminal ubicado en cada box de atencin. 3) Una vez que ha terminado la atencin del especialista, ste debe llenar con la anamnesis realizada en la entrevista y posterior anlisis realizado. Esta informacin debe incluir fecha de la atencin, datos de la inspeccin (peso, talla, IMC, temperatura y presin arterial), observaciones del examen fsico obtenido, diagnstico e indicaciones (alimentaria y conductual, medicamentos y/o procedimientos clnicos, derivaciones u hospitalizacin). 4) Adems, en cada atencin, el SEFP debe conectarse con un servicio web de la Agenda Mdica para informar cuando se realizan las atenciones de los especialistas, de manera de llevar el control y poder cancelar los honorarios mdicos respectivos. 5) Algo similar pasa cuando un paciente va a laboratorio por un procedimiento. En este caso el tecnlogo mdico o enfermera podr ver la informacin referente a la ltima entrevista con especialista o aquella que le deriv a dicho procedimiento. As mismo, deber ingresar cualquier observacin y los resultados obtenidos en el procedimiento (ya sea in situ o posterior anlisis de los resultados). 6) En caso de ser derivado a un centro asistencial para hospitalizacin, el especialista que lo deriva podr imprimir un informe mdico que deber presentar en el hospital o clnica que asista para que lleve toda la informacin de manera ms expedita. 7) El SEFP no debe realizar cobros por bonos o servicios prestados, ni tampoco el control de remuneraciones y honorarios mdicos del personal. Lo primero que se debe realizar es un anlisis de los requerimientos en bruto entregados por el cliente del proyecto (gerente general de CEMELAB). En este caso, esos requerimientos es bruto se encuentran en el texto entregado como enunciado. Veamos cmo vamos obteniendo la informacin a travs de los artefactos solicitados.
ESPECIFICACIN DE FUNCIONES
Vamos a realizar una clasificacin preliminar de los requerimientos tomando uno por uno de los puntos indicados y revisando si podemos identificar de qu tipo son cada una de las situaciones (segn FURPS+). En un anlisis simple, podemos obtener que los requerimientos 1 al 6 son del tipo funcional y el nmero 7 es una restriccin del sistema. Por otro lado, el requerimientos 4 tiene una componente de interoperatividad con el sistema de agendamiento mdico. Ahora, especifiquemos los 6 requerimientos funcionales con la tcnica de especificacin de funciones.
74
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana Nombre del Sistema: Panorama: Clientes: Metas: Sistema Electrnico de Fichas de Paciente (SEFP) CEMELAB, a travs de sus centros mdicos y laboratorios a lo largo del pas Recepcionistas, Mdicos y Laboratoristas Crear un sistema de registro electrnico de fichas nicas de pacientes del centro para: Centralizar la informacin mdica de cada paciente registrado en el centro Mantener la informacin en lnea de manera de que cualquier especialista pueda consultarla en forma oportuna Entregar la informacin requerida al paciente en caso de hospitalizacin y/o traslado a otro centro de atencin. R1.1 Registro de un Paciente El sistema debe permitir el registro de un paciente con los datos bsicos de ste (nombre completo, rut, direccin, telfono de contacto y correo electrnico). Evidente Detalles y Restricciones Categora
R1.2 Registro de Anamnesis El sistema debe permitir que el mdico tratante ingrese el detalle de la atencin en box incluyendo los procedimientos y medicamentos indicados. Evidente Detalles y Restricciones Categora
R1.3 Registro de Observaciones en un Procedimiento El sistema debe permitir que la enfermera o mdico a cargo ingrese las observaciones durante el procedimiento mdico de un paciente. Evidente Detalles y Restricciones Categora
R1.4 Registro de Resultados de un Procedimiento El sistema debe permitir que el tecnlogo mdico ingrese los resultados y las inferencias segn sea el caso de los procedimientos realizados por el paciente. Evidente Detalles y Restricciones Categora
# Ref: Funcin: Descripcin: Categora: Atributo Informacin Segmentada
R2.1 Consulta de Historial del Paciente El sistema debe permitir al profesional consultar sobre la historia reciente del paciente registrada en su ficha. Evidente Detalles y Restricciones Categora La informacin debe ser segmentada segn el nivel de Poltica acceso del profesional consultante. R2.2 Actualizacin de Agenda Mdica
# Ref: Funcin:
75
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana Descripcin: Categora: Atributo Servicio Web El sistema debe actualizar el sistema de agendamiento cuando el especialista cierra la ficha luego de terminada la consulta de un paciente. Oculto Detalles y Restricciones Categora La actualizacin debe realizarse a travs de un servicio Interoperatividad web prestado por el sistema de agenda mdica. ILUSTRACIN 38. ESPECIFICACIN DE FUNCIONES DEL SEFP
Con esto ya tenemos gran parte del trabajo hecho, ya que hicimos la primera clasificacin de lo obtenido de parte del cliente.

A continuacin definiremos el modelo de casos de uso del problema. ESPECIFICACIN DE CASOS DE USO A pesar de que no siempre es as, en este caso los casos de uso se parecern mucho a lo que encontramos como funciones. Veamos la tcnica de a poco para que vayamos descubriendo el por qu de esta afirmacin tan adelantada. LMITES DEL SISTEMA Si observamos las metas de la especificacin funcional, podemos decir que el lmite del sistema est la creacin y registro del historial mdico de un paciente que ingresa y se atiende en algn centro de CEMELAB. Sin embargo, tambin podemos decir que excluye: La administracin de la agenda La compra de bonos y el pago de los servicios prestados por el centro El control de remuneraciones y honorarios de profesionales
ACTORES A partir de los clientes y del texto entregado, podemos decir que los actores del sistema son:
Actor Recepcionista Objetivo Registrar un paciente nuevo para atencin Imprimir detalle de ficha mdica en caso de derivacin o traslado Especialista Consultar ficha del paciente a ser atendido Ingresar a la ficha del paciente la anamnesis Enfermera Consultar ficha del paciente a ser atendido Ingresar observaciones en procedimiento Tecnlogo Ingresar resultados y diagnstico de un procedimiento Paciente Ser atendido Agenda Mdica Actualizar las horas mdicas cuando se cierre una atencin ILUSTRACIN 39. TABLA DE ACTORES Y OBJETIVOS DEL SEFP
ESPECIFICACIN DE CASOS DE USO DE ALTO NIVEL Por ltimo, con los objetivos e intersectados con la especificacin de funciones, describiremos los casos de uso del sistema: 76
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana Caso de Uso: Actores: Tipo: Descripcin: CU1: Registrar Paciente Recepcionista (I), Paciente Primario Cuando llega un paciente nuevo, ste debe ser registrado en el sistema y su ficha ser creada. La informacin necesaria para este registro es nombre completo, rut, direccin, telfono y correo electrnico. CU2: Consultar Historial Especialista/ Enfermera (I) Primario Antes de la atencin, el encargado deber revisar la ficha del paciente. CU3: Registrar Anamnesis Especialista (I), Paciente Primario Al terminar la atencin mdica, el mdico tratante ingrese el detalle de la atencin en box incluyendo los procedimientos y medicamentos indicados. CU4: Registrar Observaciones por Procedimiento Enfermera (I) Secundario Durante un procedimiento, la enfermera puede ingresar observaciones que le parezcan relevantes para el anlisis del mismo. CU5: Registrar Resultado de Procedimiento Tecnlogo (I) Primario Al analizar una muestra, el tecnlogo debe ingresar los resultados clnicos en la ficha, as como tambin el diagnstico preliminar si procede. CU6: Generar Traslado Recepcionista (I), Especialista, Paciente Opcional En caso de un traslado (derivacin u hospitalizacin), se debe emitir un informe indicando el ltimo diagnstico y procedimientos asociados a ste.
Caso de Uso: Actores: Tipo: Descripcin: Caso de Uso: Actores: Tipo: Descripcin:
CU7: Actualizar Agenda Mdica Especialista (I) Primario Cada vez que el especialista cierra una atencin mdica, sta debe ser actualizada en la agenda mdica. ILUSTRACIN 40. ESPECIFICACIN DE CASOS DE USO DE ALTO NIVEL PARA EL SEFP
Con estos 7 CU vamos a trabajar, pero solo 5 usaremos su forma expandida. ESPECIFICACIN DE CASOS DE USO EXPANDIDOS A continuacin, especificaremos los casos de uso expandidos para aquellos que sean de tipo primario.
Caso de Uso: Actores: Propsito: Resumen: CU1: Registrar Paciente Recepcionista (I), Paciente Realizar el registro de un paciente nuevo en el SEFP. Cuando llega un paciente nuevo, ste debe ser registrado en el sistema y su ficha
77
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana ser creada. La informacin necesaria para este registro es nombre completo, rut, direccin, telfono y correo electrnico. Tipo: Primario y Esencial Ref. Cruzadas: R1.1 Curso Normal Acciones de los Actores Respuestas del Sistema 1. Paciente llega al mesn de atencin y entrega su RUT. 2. Recepcionista ingresa RUT en el sistema para 3. Sistema confirma que el paciente es nuevo y confirmar que es nuevo. solicita informacin bsica. 4. Recepcionista solicita al paciente informacin. 5. Paciente entrega a Recepcionista informacin solicitada. 6. Recepcionista ingresa la informacin en el 7. Sistema registra la informacin y crea la ficha sistema. electrnica informando accin. 8. Recepcionista entrega RUT al Paciente. Cursos Alternos (3a) Si el paciente ya existe, informa al Recepcionista y termina el CU. (7a) Si el RUT ya est registrado con otra informacin, alerta al Recepcionista y solicita confirmacin para actualizar informacin. CU2: Consultar Historial Especialista/Enfermera (I) Consultar aspectos relevantes de la ficha previos a la atencin. Antes de la atencin, el encargado deber revisar la ficha del paciente utilizando el RUT de ste. Tipo: Primario y Esencial Ref. Cruzadas: R2.1 Curso Normal Acciones de los Actores Respuestas del Sistema 1. Especialista/Enfermera ingresa el RUT del 2. Sistema obtiene ficha del paciente y muestra paciente en el sistema. informacin. Cursos Alternos (2a) Si el paciente no existe, lo informa y termina el CU. CU3: Registrar Anamnesis Especialista (I), Paciente Registrar la informacin resultante de la consulta mdica. Al terminar la atencin mdica, el mdico tratante ingrese el detalle de la atencin en box incluyendo los procedimientos y medicamentos indicados. Tipo: Primario y Esencial Ref. Cruzadas: R1.2, CU7 Curso Normal Acciones de los Actores Respuestas del Sistema Especialista ingresa el RUT del paciente. 2. Sistema encuentra la ficha mdica, abre la atencin mdica y solicita informacin sobre los datos de la inspeccin y observaciones al examen fsico. Especialista ingresa datos de peso, talla, presin 4. Sistema registra informacin de la inspeccin y arterial, temperatura, etc. y las observaciones si solicita informacin sobre diagnstico del las hubiera. paciente. Especialista ingresa el diagnstico. 6. Sistema registra el diagnstico y solicita informacin sobre procedimientos, Caso de Uso: Actores: Propsito: Resumen: Caso de Uso: Actores: Propsito: Resumen:
1.
3.
5.
78
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana medicamentos e indicaciones. Especialista ingresa los procedimientos, 8. Sistema registra informacin y cierra la atencin medicamentos e indicaciones entregadas al mdica (CU7). paciente. Cursos Alternos (2a) Si la ficha no existe, informa al Especialista y termina el CU. 7. CU5: Registrar Resultado de Procedimiento Tecnlogo (I) Registrar la informacin de anlisis y diagnstico del procedimiento realizado. Al analizar una muestra, el tecnlogo debe ingresar los resultados clnicos en la ficha, as como tambin el diagnstico preliminar si procede. Tipo: Primario y Esencial Ref. Cruzadas: R1.4 Curso Normal Acciones de los Actores Respuestas del Sistema 1. Tecnlogo ingresa el RUT del paciente. 2. Sistema encuentra la ficha mdica, solicita informacin sobre la fecha de la muestra, los resultados del examen y diagnstico en caso de ser necesario. 3. Tecnlogo ingresa datos obtenidos de la 4. Sistema registra informacin y cierra la ficha. muestra y en caso de que aplique se ingresa el diagnstico. Cursos Alternos (2a) Si la ficha no existe, informa al Tecnlogo y termina el CU. CU7: Actualizar Agenda Mdica Especialista Enviar un mensaje al Sistema de Agenda Mdica (SAM) de cierre de atencin. Al cerrar una ficha por atencin mdica, el sistema debe generar un mensaje al SAM para informar que el especialista ha dado trmino a la atencin. Tipo: Primario y Esencial Ref. Cruzadas: R2.2, CU3 Curso Normal Acciones de los Actores Respuestas del Sistema 1. Especialista cierra la atencin mdica (CU3). 2. Sistema registra el cierre de la ficha y enva un mensaje al SAM indicando el cierre de la atencin. 3. Sistema recibe confirmacin de parte del SAM de que se ha realizado la transaccin y termina el CU. Cursos Alternos (3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una alerta al administrador del sistema, quin debe cursar manualmente el proceso. ILUSTRACIN 41. ESPECIFICACIN DE CU EXPANDIDOS PARA EL CASO SEFP Caso de Uso: Actores: Propsito: Resumen: Caso de Uso: Actores: Propsito: Resumen:
En este ltimo CU, en el Curso Alterno (3a) se menciona que debe existir un administrador del sistema. Esto es porque no se ha mencionado que pasa con la conectividad y comunicacin entre ambos sistema (SAM y SEFP), de modo que ha sido una sugerencia en los requerimientos. Es importante validarlo con el cliente final antes de cerrar la iteracin y utilizar dicha informacin para el anlisis del sistema.
79
DIAGRAMA DE CASOS DE USO Para este caso, el Diagrama de Casos de Uso no es muy simple, ya que incorpora conexiones entre casos de uso (CU3 y CU7, tal como aparece en su especificacin expandida). Veamos el resultado:
System CU1: Registrar Paciente
CU6: Generar Traslado Recepcionista
CU3: Registrar Anamnesis
Especialista <<include>> CU7: Actualizar SAM CU2: Consultar Ficha
Agenda Mdica
Enfermera CU4: Registrar Observaciones
CU5: Registrar Resultados Tecnlogo
ILUSTRACIN 42. DIAGRAMA DE CASOS DE USO DEL SEFP
El hecho de que aparezca el include entre el CU3 y el CU7 quiere explicar de que el CU7 est siempre incluido en el CU3 (es un subproceso, pero en este caso es sobre otro sistema).
GLOSARIO
A continuacin, veamos un glosario para el problema:
Trmino Ficha Mdica Registro Box Anamnesis Datos de la Inspeccin Diagnstico Procedimiento Agenda Mdica (SAM) Definicin Registro electrnico (en este caso) en donde queda almacenada toda la historia mdica de un paciente. Proceso a travs del cual se guarda la informacin ingresada por un usuario. Espacio fsico donde se realiza la anamnesis. Proceso de revisin que realiza un especialista en un box de atencin a un paciente. Informacin que resulta de un examen fsico realizado por un especialista en un box de atencin (peso, talla, temperatura y presin arterial). Inferencia que realiza el especialista como resultado del examen fsico. Cualquier tipo de examen fsico o psicolgico que puede solicitar el especialista. Sistema externo necesario para registrar cuando un especialista cierra una atencin mdica. ILUSTRACIN 43. GLOSARIO PARA EL SEFP
80
Este glosario resumido (ya que podramos encontrar muchos ms trminos para este problema) solo muestra un ejemplo de cmo van describindose las diferentes definiciones de, en este caso, los conceptos del dominio.
MODELO DE DOMINIO
Para este modelo comenzaremos con los Diagramas de Actividades que representan los procesos relacionados con el caso, y luego realizaremos un Diagrama de Clases Conceptuales que soporte el dominio en cuestin. DIAGRAMA DE ACTIVIDADES El enfoque que utilizaremos ser el ver el diagrama de actividades global a partir de las transiciones que tiene la ficha de un paciente desde su generacin y su uso posterior. De esta manera, el diagrama nos muestra los diferentes carriles-de-nado para los actores y entidades que utilizan la ficha o realizan actividades como resultado del uso de la ficha. As, el diagrama comienza por el recepcionista (ya sea en el laboratorio como en la consulta mdica) el cual registra la informacin bsica de la ficha (crear). A continuacin hemos indicado un conector de decisin para diferenciar si el siguiente flujo (por consulta mdica o por procedimiento). De esta manera diferenciamos el paso dependiendo del actor principal. Cada uno de esos flujos termina en un conector con una X de manera de que podamos volver al flujo principal en la decisin para el siguiente flujo. Finalmente, notaremos que no tiene una actividad de trmino, ya que la ficha no se destruye en el dominio, sino que una vez que el paciente ingresa al esquema, se mantendr desde ese momento en adelante.
81
Recepcionista Especialista Sistema de Agenda Mdica Laboratorista
[paciente ingresa al centro] Crear Ficha de Paciente
[paciente entra a toma de muestra] [paciente entra a consulta] Ver Ficha de Paciente Ver Ficha de Paciente
Realizar el Procedimiento Realizar la Consulta
[no hay observaciones] Registrar la Anmnesis [hay observaciones] Registrar Observaciones Registrar Trmino de Atencin
[derivacin a centro asistencial] Realizar Anlisis
[no hay derivacin] Imprimir Informe Mdico Registrar Resultados
ILUSTRACIN 44. DIAGRAMA DE ACTIVIDADES DEL SEFP
DIAGRAMA DE CLASES CONCEPTUALES Tal como vimos en clases, lo que vamos a realizar es utilizar ambos mtodos de identificacin de clases conceptuales para luego ir dibujando el diagrama general. Veamos primero entonces la lista de categoras:
Categora de Clase Conceptual Objetos tangibles o fsicos Especificaciones, diseos o descripciones de las cosas Ejemplos InformeDeDerivacion DetalleDeInforme ResultadoProcedimiento DetalleAnamnesis CentroMedico Recepcin ConsultaMedica BoxDeProcedimiento Anamnesis Procedimiento Recepcionista Especialista Laboratorista
Lugares
Lneas de la transaccin Roles de la gente
82
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana Ejemplos Paciente Contenedores de otras cosas Cosas en un contenedor Otros sistemas externos AgendaMedica Conceptos abstractos Anamnesis Procedimiento FichaDePaciente Organizaciones Hechos Procesos Anamnesis Procedimiento Reglas y polticas Catlogos RegistroDeFichas Registro de finanzas, trabajo, contratos, asuntos legales Instrumentos y servicios financieros Manuales, documentos, artculos de referencia, libros InformeDeDerivacion ILUSTRACIN 45. IDENTIFICACIN DE CLASES CONCEPTUALES SEGN CATEGORAS PARA EL SEFP Categora de Clase Conceptual
Note que aparecen las mismas clases en varias categoras. Veamos ahora las frases nominales de los escenarios de casos de uso:
CU1: Registrar Paciente Curso Normal Acciones de los Actores Respuestas del Sistema 9. Paciente llega al mesn de atencin y entrega su RUT. 10. Recepcionista ingresa RUT en el sistema para 11. Sistema confirma que el paciente es nuevo y confirmar que es nuevo. solicita informacin bsica. 12. Recepcionista solicita al paciente informacin. 13. Paciente entrega a Recepcionista informacin solicitada. 14. Recepcionista ingresa la informacin en el 15. Sistema registra la informacin y crea la ficha sistema. electrnica informando accin. 16. Recepcionista entrega RUT al Paciente. Cursos Alternos (3a) Si el paciente ya existe, informa al Recepcionista y termina el CU. (7a) Si el RUT ya est registrado con otra informacin, alerta al Recepcionista y solicita confirmacin para actualizar informacin. CU2: Consultar Historial Curso Normal Acciones de los Actores Respuestas del Sistema 3. Especialista/Enfermera ingresa el RUT del 4. Sistema obtiene ficha del paciente y muestra paciente en el sistema. informacin. Cursos Alternos (2a) Si el paciente no existe, lo informa y termina el CU. CU3: Registrar Anamnesis Curso Normal Acciones de los Actores Respuestas del Sistema Especialista ingresa el RUT del paciente. 10. Sistema encuentra la ficha mdica, abre la atencin mdica y solicita informacin sobre los datos de la inspeccin y observaciones al Caso de Uso: Caso de Uso: Caso de Uso:
9.
83
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana 11. Especialista ingresa datos de peso, talla, presin arterial, temperatura, etc. y las observaciones si las hubiera. 13. Especialista ingresa el diagnstico. examen fsico. 12. Sistema registra informacin de la inspeccin y solicita informacin sobre diagnstico del paciente. 14. Sistema registra el diagnstico y solicita informacin sobre procedimientos, medicamentos e indicaciones. 16. Sistema registra informacin y cierra la atencin mdica (CU7).
15. Especialista ingresa los procedimientos, medicamentos e indicaciones entregadas al paciente. Cursos Alternos (2a) Si la ficha no existe, informa al Especialista y termina el CU. Caso de Uso:
CU5: Registrar Resultado de Procedimiento Curso Normal Acciones de los Actores Respuestas del Sistema 5. Tecnlogo ingresa el RUT del paciente. 6. Sistema encuentra la ficha mdica, solicita informacin sobre la fecha de la muestra, los resultados del examen y diagnstico en caso de ser necesario. 7. Tecnlogo ingresa datos obtenidos de la 8. Sistema registra informacin y cierra la ficha. muestra y en caso de que aplique se ingresa el diagnstico. Cursos Alternos (2a) Si la ficha no existe, informa al Tecnlogo y termina el CU. CU7: Actualizar Agenda Mdica Curso Normal Acciones de los Actores Respuestas del Sistema 4. Especialista cierra la atencin mdica (CU3). 5. Sistema registra el cierre de la ficha y enva un mensaje al SAM indicando el cierre de la atencin. 6. Sistema recibe confirmacin de parte del SAM de que se ha realizado la transaccin y termina el CU. Cursos Alternos (3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una alerta al administrador del sistema, quin debe cursar manualmente el proceso. ILUSTRACIN 46. FRASES NOMINALES PARA ESCENARIOS DEL SEFP Caso de Uso:
Como podemos ver, en los diferentes escenarios encontramos un lenguaje mixto, en donde nos podemos referir de diferentes formas a los mismo conceptos, por lo que es importante no solo tomar lo que dice, sino que formalizar tambin el concepto como tal, ya que en el diagrama de clases conceptuales es donde debe quedar finalmente el concepto que ser utilizado finalmente en el sistema. Ahora, completemos con los otros 2 pasos de la tcnica el diagrama de clases conceptuales y veamos el resultado final:
84
DetalleDeFicha +rut +nombre +direccion +telefono +email 1 1 es-descrita-por FichaDePaciente 1 1 1 0..1
1 posee
Paciente
crea 1
Recepcionista
contiene 0..* Laboratorista Procedimiento 1 ingresa es-descrita-por 1 DetalleProcedimiento +observaciones 0..1 +resultados +diagnostico
+cotiene 0..* Anamnesis Especialista
1 1
1 es-descrita-por 0..1 ingresa
DetalleAnamnesis +datos_inspeccion +observaciones +indicaciones +otros
ILUSTRACIN 47. DIAGRAMA DE CLASES CONCEPTUALES DEL SEFP
Este diagrama puede ser la primera aproximacin para el futuro diseo de clases y por supuesto un insumo importante para los siguientes artefactos y modelos de anlisis y diseo.
En este caso comenzaremos con los Diagramas de Secuencia que representan los eventos que ocurren en cada caso de uso, luego realizaremos los Contratos asociados a las operaciones principales del sistema y por ltimo algunos Diagramas de Estado para los objetos principales del sistema. DIAGRAMAS DE SECUENCIA Para especificar los diagramas de secuencia es importante hacerlos a travs de los escenarios encontrados en los casos de uso. Segn lo expuesto en este problema, los escenarios alternos son sencillos, as que, donde corresponda, se utilizarn los cursos alternos como parte del mismo diagrama. Veamos el escenario del primer caso de uso:
85
: Recepcionista
Sistema
CatalogoDePacientes
1 : validarRut()
2 : pacienteExiste()
3 : ack 4 5 : ingresarDetalle() : DetalleDeFicha 6 : nuevo()
7 8 : asociarDetalle()
10
ILUSTRACIN 48. DIAGRAMA DE SECUENCIA PARA EL CU1. REGISTRAR PACIENTE
Es posible observar en este diagrama que gran parte de la carga se la estara llevando el objeto DetalleDeFicha (adelantndonos para cuando lleguemos a los diagramas de estado). Sigamos con los dems CU y sus respectivos diagramas:
Funcionario
Sistema
CatalogoDePacientes
1 : consultar()
2 : buscar()
3 4
ILUSTRACIN 49. DIAGRAMA DE SECUENCIA PARA EL CU2. CONSULTAR HISTORIAL
Al igual que en el caso anterior, este diagrama no es ms que una traduccin del escenario realizado para el CU. Veamos el siguiente:
86
: Especialista
Sistema
CatalogoDePacientes
d : DetalleDeFicha
1 : consultar() 2 : buscar()
4 5 : registrarInformacin()
3:d : DetalleAnamnesis 6 : crear() 7 : det 8 : registrarAnamnesis()
10
ILUSTRACIN 50. DIAGRAMA DE SECUENCIA PARA EL CU3. REGISTRAR ANAMNESIS
En este caso podemos ver que se complejiza un poco la lgica, sin embargo debemos destacar un par de puntos. 1. Resumimos los 3 ingresos que existen en el escenario en 1 sola operacin (con la lgica de que la filla se llena sin registrar la informacin hasta el final). 2. La creacin del objeto DetalleAnamnesis es porque segn el modelo de dominio, DetalleDeFicha solo sabe registrar DetalleAnamnesis a travs de una Anamnesis (la cual puede ser generad dentro de DetalleFicha como una lnea de transaccin). 3. Las operacines de consultar, en realidad es la misma utilizada en el CU2. Sigamos con el siguiente CU:
87
: Laboratorista
Sistema
CatalogoDePacientes
d : DetalleDeFicha
1 : consultar()
2 : buscar()
3:d 4 5 : registrarInformacion() 6 : crear() : DetalleProcedimiento
7 : det 8 : registrarProcedimiento()
10
ILUSTRACIN 51. DIAGRAMA DE SECUENCIA PARA CU5. REGISTRAR RESULTADO DE PROCEDIMIENTO
En este caso vemos una similitud muy obvia con el CU3, tanto as que a estas alturas podramos generalizarlo de manera de que sea ms reutilizable. Sin embargo, para efectos prcticos, sigamos con el anlisis tal cual.
: Especialista
Sistema
AgendaMedica
1 : cerrarAtencin() 2 : cierreFicha()
3 : ack
ILUSTRACIN 52. DIAGRAMA DE SECUENCIA PARA EL CU7. ACTUALIZAR AGENDA MDICA
En el ltimo CU analizado solo tenemos el hecho del cierre de la atencin mdica y en este caso son operaciones hacia fuera del sistema, as que es poca la interaccin. Con estos diagramas completamos el anlisis del comportamiento a travs de las secuencias, y pasaremos a ver los contratos.
88
CONTRATOS DE LAS OPERACIONES Una vez que ya se han realizado todos los diagramas de secuencia, se debe comenzar identificado cules son las operaciones principales para luego ir describindolas a travs de la estructura planteada para los contratos. Veamos entonces los contratos del problema.
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: CO1. validarRut(rut) Validar que el RUT exista dentro del catalogo de pacientes Sistema CU1 Si el RUT existe, se aborta el resto del CU - Exista una instancia r de tipo CatalogoDePacientes - No se haya encontrado una instancia f de FichaDePaciente dentro de r que tenga asociada una instancia d de DetalleDeFicha que tenga como atributo rut el valor del parmetro rut. CO2. ingresarDetalle(rut, nombre, direccion, fono, email) Crear y agregar la informacin bsica del paciente a la ficha Sistema CU1 - Se haya creado una instancia d de tipo DetalleDeFicha - Se hayan fijado los atributos rut, nombre, direccin, telfono e email con los valores entregados por parmetro. - Se haya creado una instancia f de tipo FichaDePaciente - Se haya asociado d a f CO3. consultar(rut) Obtiene la informacin de la ficha del paciente a partir del rut ingresado. Sistema CU2, CU3, CU5 Si la ficha no existe, devuelve un valor nulo. - Exista una instancia r de CatalogoDePacientes - Se haya encontrado una instancia p de DetalleDePaciente cuyo atributo rut sea igual al valor del parmetros rut. CO4. registrarInformacion(objeto) Registra en la ficha del paciente la informacin entregada en forma de objeto. Sistema CU3, CU5 Objeto puede tomar valores de DetalleAnamnesis y DetalleProcedimiento -
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones:
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones:
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones:
89
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana Salidas: Precondiciones Postcondiciones: Operacin: Responsabilidad: - Exiasta una instancia d de DetalleDePaciente - Se haya asociado objeto a d.
CO5. cerrarAtencion(especialista) Enva una notificacin al sistema de agenda mdica indicando el trmido de la atencin del especialista. Tipo o Clase: Sistema Ref. Cruzadas: CU7 Notas: Utiliza XML para construir la llamada al SAM. Excepciones: Salidas: Un mensaje intersistemas para el SAM Precondiciones Postcondiciones: ILUSTRACIN 53. CONTRATOS DE LAS OPERACIONES DEL SEFP
Como podemos ver en los contratos expuestos, se hicieron varias optimizaciones en las operaciones, generalizando las que habamos originalmente encontrado en los diagramas. Esto permitir un menor riesgo desde el punto de vista del diseo e implementacin futura. DIAGRAMAS DE ESTADOS Como ltima parte del anlisis vamos a realizar algunos diagramas de estados que nos permiten identificar los cabios de estado de los objetos principales. En particular, uno de los objetos que sufre cambios es la instancia de FichaDePaciente que representa a un paciente particular. Veamos cmo queda el diagrama de estados en este caso (considerando todos los contratos del modelo).
nuevo
Disponible entry/fijarDetalleDePaciente
[es atendido]
En Llenado do/asociarDetalle
ILUSTRACIN 54. DIAGRAMA DE ESTADOS PARA FICHADEPACIENTE DEL SEFP
Como podemos ver en el diagrama, los estados en realidad son pocos, ya que no pasa por muchos cambios (solo se ven las asociaciones dadas por los contratos). Es importante hacer notar que, a pesar de que este sea una visin del anlisis del comportamiento no necesariamente es la nica. Esto es muy importante desde el punto de vista del problema final, ya que si la consistencia es buena, no requiere mayor perfeccionamiento.
90
UNIDAD III. EL DISEO ORIENTADO AL OBJETO

Durante este captulo veremos cmo realizar el diseo de software y componentes a partir del dominio analizado en la unidad anterior.
91
FUNDAMENTOS DEL DISEO DE SOFTWARE

El diseo del software se encuentra en el ncleo tcnico de la ingeniera del software y se aplica independientemente del modelo de diseo de software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseo del software es la primera de las tres actividades tcnicas -diseo, generacin de cdigo y pruebas- que se requieren para construir y verificar el software. La visin que hasta este punto se ha obtenido del software es mayormente realizada desde el punto de vista funcional, lo que por supuesto es muy til cuando se trata de comprender el dominio y tambin el cmo va a funcionar el sistema. Sin embargo, el resultado del A/DOO (Anlisis y Diseo Orientado al Objeto) debe ser un modelo cuya orientacin sea, tal como dice su nombre, orientado a objetos, lo que permitira luego a los programadores realizar una construccin en lenguajes que utilizan ese paradigma (Java, C++, C#, Eiffel, etc). De esta manera, el Diseo Orientado al Objeto no es ms que una disciplina que permite aproximar a los programadores el sistema de anlisis en un entorno orientado al objeto. As, los artefactos principales de sta tiene como finalidad describir las componentes y objetos del sistema para su construccin (arquitectura).
LA ARQUITECTURA DEL SOFTWARE

La arquitectura del software alude a la estructura global del software y a las formas en que la estructura proporciona la integridad conceptual de un sistema. En su forma ms simple, la arquitectura es la estructura jerrquica de los componentes del programa (mdulos), la manera en que los componentes interactan y la estructura de datos que van a utilizar los componentes. Sin embargo, en un sentido ms amplio, los componentes se pueden generalizar para representar los elementos principales del sistema y sus interacciones. Un objetivo del diseo del software es derivar el anlisis en una representacin arquitectnica de un sistema. Esta representacin sirve como marco de trabajo desde donde se llevan a cabo actividades de diseo ms detalladas como la especificacin de las clases del sistema. Un conjunto de patrones arquitectnicos permiten que el ingeniero del software reutilice los conceptos del dominio a nivel de diseo y obtener informacin de ms bajo nivel en forma natural. En textos sobre ingeniera de software se describe un conjunto de propiedades que debern especificarse como parte de un diseo arquitectnico: Propiedades estructurales: Este aspecto de la representacin del diseo arquitectnico define los componentes de un sistema y la manera en que esos componentes se empaquetan e interactan unos con otros. Propiedades extra-funcionales: La descripcin del diseo arquitectnico deber ocuparse de cmo la arquitectura de diseo consigue los requisitos para el rendimiento, capacidad, fiabilidad, seguridad, capacidad de adaptacin y otras no funcionales. 92
Familias de sistemas relacionados: El diseo arquitectnico deber dibujarse sobre patrones repetibles que se basen comnmente en el diseo de familias de sistemas similares.
Adems, la arquitectura se basa en diferentes vistas de la arquitectura del sistema desde una perspectiva dada. Cada vista es una ventana a travs de la cual se observa a la arquitectura para identificar informacin relevante o ideas claves, ignorando todo lo que no sea parte del punto de vista elegido. Se sugieren 6 tipos bsicos de vistas de la arquitectura: Vista Lgica: Muestra la organizacin conceptual del software en funcin de las capas, subsistemas, paquetes, frameworks, clases e interfaces ms importantes. Resume la funcionalidad de los elementos del software importantes, como cada subsistema. Muestra los escenarios de realizacin de casos de uso destacados que ilustran aspectos claves del sistema. Esta vista utiliza diagramas de paquetes, diagramas de clases y diagramas de interaccin en UML. Vista de Proceso: Muestra los procesos e hilos de ejecucin, sus responsabilidades, colaboraciones y la asignacin a ellos de los elementos lgicos (capas, subsistemas, clases, etc). Esta vista utiliza diagramas de clases y diagramas de interaccin en UML. Vista de Despliegue: Muestra el despliegue fsico de los procesos y componentes sobre los nodos de proceso y la configuracin de la red fsica entre los nodos. Esta vista utiliza diagramas de despliegue en UML. Vista de Datos: Muestra la vista global de datos persistentes, la correspondencia del esquema de objetos a datos persistentes (normalmente en una base de datos relacional), el mecanismo de correspondencia de objetos a una base de datos, procedimientos almacenados y disparadores (triggers). Esta vista utiliza diagramas de clases para representar el modelo de datos en UML. Vista de Casos de Uso: Muestra un resumen de los casos de uso ms significativos para los requisitos no funcionales, es decir, aquellos casos de uso que, mediante la implementacin, cubren parte significativa de la arquitectura o que influyen en muchos elementos de ella. Esta vista utiliza diagramas de casos de uso en UML. Vista de Implementacin: Muestra el modelo de implementacin del sistema en funcin de una descripcin resumida de los entregables y cosas que crean entregables (como el cdigo fuente). Esta vista utiliza diagramas de paquetes, diagramas de componentes y texto que representa el modelo.
Todas estas vistas son opcionales, pero se sugiere encarecidamente documentar las vistas lgica, de proceso, de casos de uso y de despliegue. En algunos casos es posible identificar otras vistas como la de seguridad, por lo que en este caso se deja abierta la opcin de agregar las vistas necesarias para definir la arquitectura del problema en estudio. Es fcil ver que gran parte de la arquitectura de software es abarcado con el anlisis y diseo que hacemos en este curso, pero depende mucho donde y cundo iremos describiendo eso. En
93
particular, la arquitectura se define en un documento llamado Software Architectural Document (SAD) el cual permite ver las diferentes vistas del sistema. En este caso, solo nos vamos a referir a la Vista de Implementacin, ya que es la nica que nos permitir mostrar la informacin relevante para el diseo de software.
MODELO ARQUITECTNICO
El diseo arquitectnico pretende orientar al arquitecto en algunas lneas de trabajo, como las siguientes: Organizar el sistema de acuerdo a la arquitectura elegida. Descomponer modularmente el sistema. Incorporar medidas de control frente a los mdulos definidos.
A continuacin veremos algunos aspectos bsicos con los cuales debe trabajar el arquitecto antes de llegar a obtener un diseo completo5.
CONCEPTOS BSICOS
A continuacin algunos conceptos importantes que son necesarios de entender para este modelo. REFINAMIENTO Podemos definir que:
EL REFINAMIENTO ES UN PROCESO DE ELABORACIN, EN DONDE SE COMIENZA CON UN ALTO NIVEL DE ABSTRACCIN PARA LUEGO DAR LA CAPACIDAD DE IR DETALLANDO MS Y MS CADA FUNCIN DEL SISTEMA.
El refinamiento paso a paso es una estrategia de diseo descendente propuesta originalmente por Niklaus Wirth. En cada paso (del refinamiento), se descompone una o varias instrucciones del programa dado en instrucciones ms detalladas. Esta descomposicin sucesiva o refinamiento de especificaciones termina cuando todas las instrucciones se expresan en funcin de cualquier computadora subyacente o de cualquier lenguaje de programacin. De la misma manera que se refinan las tareas, los datos tambin se tienen que refinar, descomponer o estructurar, y es natural refinar el programa y las especificaciones de los datos en paralelo.
En muchos casos, dentro del modelo arquitectnico tambin se incluye el modelamiento de datos, sin embargo para la ingeniera de software son modelos diferentes.
94
Todos los pasos del refinamiento implican decisiones de diseo. Es importante que el programador conozca los criterios subyacentes (para decisiones de diseo) y la existencia de soluciones alternativas. COMPONENTE Diremos que:
UN COMPONENTE ES UNA PORCIN DEL SISTEMA CUYO
FUNCIONAMIENTO NO DEPENDE DE LOS SERVICIOS OFRECIDOS POR OTROS COMPONENTES Y DEFINE INTERFACES PARA COMUNICARSE CON ELLOS.
Este concepto bsico, cuya descripcin tambin se le conoce como subsistema, es la unidad a travs de las cuales vamos a ir refinando nuestro diseo.

Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos artefactos son: Factores de la Arquitectura: Documento que describe cules son las influencias que tienen los factores crticos en las variaciones en el sistema. Decisiones de la Arquitectura: Documento que describe las soluciones a los factores de la arquitectura y cmo afectan al diseo de software. Diagrama de Componentes: Diagrama que muestra una visin tcnica de la organizacin de los componetes segn la arquitectura realizada.

El anlisis de la arquitectura se realiza a travs de 2 artefactos bsicos mencionados. A continuacin veremos cmo se construyen cada uno de manera de mostrar la ruta con la cual llegaremos al diseo detallado (de clases).
ESPECIFICACIN DE LOS FACTORES DE LA ARQUITECTURA Los Factores de la Arquitectura se definen a travs de una tabla en donde se especifican cules son las influencias que tienen los factores crticos en las variaciones en el sistema. Esta informacin viene directamente del anlisis de requisitos, ya que se basa en la clasificacin FURPS+ de requerimientos para identificar los factores crticos que pueden afectar el diseo del software (por
95
lo general, todo lo que tiene que ver con la usabilidad, rendimiento, fiabilidad, soporte y el resto de las categoras no funcionales de requerimientos). La sintaxis del documento es la siguiente tabla:
Factor Medidas y Escenarios de Calidad Variabilidad Impacto Prioridad para el Exito Dificultad o Riesgo
ILUSTRACIN 55. TABLA DE FACTORES DE LA ARQUITECTURA
Segn la especificacin de la tabla de factores, cada campo corresponde a: Factor: Indica cul es el factor que se est especificando. Medidas y Escenarios de Calidad: Indica cuales son las medidas en los cuales ese factor es crtico para el sistema, indicando restricciones necesarias para eso. Variabilidad: Indica la flexibilidad actual y la evolucin que puede tener el factor a travs del tiempo. Impacto: Indica el impacto que tiene el factor en las personas involucradas, arquitectura del sistema y en otros factores. Prioridad para el xito: Indica cul es la prioridad que tiene este factor para el xito del sistema. Dificultad o Riesgo: Indica el nivel de riesgo que tiene este factor si no es considerado.
Adems, los factores van agrupado por la categora FURPS+ a la cual pertenecen, de manera de abordar cada uno de ellos con soluciones respectivas. Por ejemplo, en el caso del problema del TPDV, la definicin de uno de los principales factores de la arquitectura quedara de la siguiente forma.
Medidas y Escenarios de Variabilidad Impacto Prioridad Calidad para el Exito Factores de Implementacin Lector de Cuando un producto pasa Debe tener ingreso Bajo Alta Cdigos de por la caja, el lector de alternativo va teclado Barras cdigos debe leer directamente el cdigo de barras de la etiqueta ILUSTRACIN 56. TABLA DE FACTORES DE LA ARQUITECTURA DEL SPDV Factor Dificultad o Riesgo Media
Veamos ahora el complemento a este documento. ESPECIFICACIN DE LAS DECISIONES DE LA ARQUITECTURA Luego de obtenida la tabla de factores, se deben indicar las soluciones que se plantearn por cada categora de factores y as detectar aquellas que afectan directamente al diseo.
96
Para ello, se debe completar un documento de la siguiente forma:

Categora: <Nombre de la categora de factores> Resumen: <Resumen del factor y de la solucin propuesta> Factores: <Enumeracin de los factores relacionados> Solucin: <Detalle de la solucin propuesta> Motivacin: <Justificacin del problema y la solucin> Temas Abiertos: <Factores que no quedan resueltos y que se relacionan con el tema> Alternativas: <Alternativas a la solucin propuesta> ILUSTRACIN 57. TABLA DE DECISIONES DE LA ARQUITECTURA
Es fcil ver que es importante dejar en un solo documento ambos artefactos, ya que son complementarios. Desde el punto de vista acadmico los seguiremos viendo en forma separada. DIAGRAMA DE COMPONENTES El tercer artefacto, un poco independiente a los anteriores, define la visin ms cercana al diseo de clases, que es la de definir los componentes del sistema. Tal como dice su nombre, el modelo de componentes ilustra los componentes de software que se usarn para construr el sistema, ya sean desde el punto de vista de organizacin de elementos del diseo (clases) como tambin la identificacin de componentes reusables que no sea necesario re-hacer. De esta manera, este artefacto tiene dos objetivos bsicos: Organizar el sistema en componentes independientes y que permitan la reusabilidad. Reutilizar componentes de acuerdo a su funcionalidad dentro del problema.
La sintaxis es la siguiente:
ILUSTRACIN 58. NOTACIN DE LOS DIAGRAMAS DE COMPONENTES
En el proceso de desarrollo utilizado en el curso, este artefacto lo matizaremos de manera tal que nos permita organizar nuestro sistema antes de desarrollar el modelo de diseo como tal. De esta manera es importante determinar cmo vamos a identificar la componentes. Para ello diremos que son componentes o paquete de clases: 97
El conjunto de clases que permiten acceder a los datos del sistema (clases que representan temes y catlogos, por ejemplo). El conjunto de clases que est relacionado con la interfaz del sistema (controladores). El conjunto de clases que representa un grupo de requerimientos de una misma naturaleza (modularmente hablando).
Sin embargo a este nivel no tenemos que saber qu clases componen cada conjunto nombrado, ya que solo lo estamos organizando de manera funcional. De esta manera, la regla general sera la tercera de la lista, ya que podra cumplir con las otras anteriores fcilmente. Adems, distinguimos entre paquete o componente solo conociendo el estilo de programacin que usaremos. Por ejemplo, si usamos Java, podemos hacer nuestro diagrama considerando paquetes de clases (con la notacin de paquete) y en el caso de usar ActiveX o libreras compiladas, podemos hablar de componentes. Con estas sencillas reglas, generalizando el problema del supermercado podramos determinar el siguiente diagrama de componentes:
ILUSTRACIN 59. DIAGRAMA DE COMPONENTES DEL SPDV
Como vemos en este diagrama, agrupamos por tipo de requerimientos dentro del supermercado: lo que tiene que ver con la operacin de la tienda dentro del paquete Tienda, lo que tiene que ver con la operacin de la bodega dentro del paquete Bodega, y lo que tiene que ver con las operaciones financieras en el paquete Finanzas. Adems, se definieron unas interfaces que casualmente representan los conceptos del dominio que nos enlazan con dichos paquetes (CatlogoDeProductos y RegistroDeVentas), lo que por supuesto nos define el tipo de interaccin que tendr Tienda con los paquetes vinculados (Bodega y Finanzas).
MODELO DE DISEO
El Modelo de Diseo es, por esencia, el principal modelo en la fase de diseo del UP, sin embargo contiene varios artefactos y tcnicas necesarias para completar el diseo. Principalmente, y lo que veremos en este curso, el Modelo de Diseo se centrar en 2 artefactos: Diagramas de Colaboracin y Diagrama de Clases. 98
CONCEPTOS BSICOS
Veamos algunos conceptos bsicos con los que nos toparemos al desarrollar este modelo. REALIZACIN DE CASO DE USO Podemos decir que:
LA REALIZACIN DE UN CASO DE USO DESCRIBE CMO SE REALIZA EL CASO DE USO PARTICULAR EN EL MODELO DE DISEO, EN FUNCIN DE LOS OBJETOS DEL SISTEMA QUE COLABORAN ENTRE S.
Si analizamos un poco ms esta definicin, lo que queremos decir es que en la realizacin, el arquitecto se preocupa de describir el diseo de uno o ms escenarios de un caso de uso, utilizando los objetos del sistema. De esta forma, los casos de uso nos definen los eventos del sistema, que se muestran explcitamente en los diagramas de secuencia de eventos (en el anlisis). Luego de eso, estos eventos pueden ser descritos en contratos de las operaciones del sistema (tambin del anlisis). As, los eventos del sistema representan los mensajes que inician los diagramas de interaccin, los cuales representan el modo en el que los objetos interactan para llevar a cabo las tareas requeridas (realizacin). Por ltimo, la estas interacciones ocurren entre objetos que se inspiran en las clases conceptuales del modelo de dominio, adems de otras clases de objetos. RESPONSABILIDAD Podemos definir inmediatamente que:
LA RESPONSABILIDAD ES UN CONTRATO U OBLIGACIN DE UN OBJETO EN CUANTO A SU COMPORTAMIENTO.
En efecto, las responsabilidades nos definen ciertos parmetros de las obligaciones que poseen los objetos dentro del modelo de diseo. En este contexto, se definen 2 tipos de responsabilidades: Conocer: Con esta responsabilidad, el objeto tiene el conocimiento de los datos privados encapsulados, objetos relacionados y cosas que puede derivar o calcular (ej: La Venta conoce la fecha y la hora de la venta, las Lneas de Venta asociadas a la venta y el precio total de la venta). Hacer: Con esta responsabilidad, el objeto tiene el poder de hacer algo l mismo como crear un objeto o realizar un clculo, iniciar una accin en otros objetos y controlar y coordinar actividades en otros objetos (ej: La Venta es responsable de crear Lneas de Venta y generar un descuento en el Inventario). Las responsabilidades del conocer generalmente se pueden inferir desde el modelo de dominio, ya que es fcil detectarlas con los atributos de las clases conceptuales. 99
Sin embargo, las responsabilidades no son lo mismo que los mtodos, an cuando tienen una estrecha relacin: los mtodos se implementan para llevar a cabo responsabilidades. En efecto, para que se cumplan las responsabilidades identificadas, es necesario implementarlas a travs de uno o ms mtodos que actan solos o colaboran entre ellos. Por ejemplo, para cumplir con la responsabilidad de la clase Venta que conoce el total de la venta, podemos definir un mtodo getVenta, el cual utiliza los mtodos getSubtotal de la clase Lnea de Venta quien le entrega el valor total de cada lnea de venta (precio x cantidad) para calcular el total de la venta. PATRONES DE DISEO En el contexto de la tecnologa de objetos, podemos definir que:
UN PATRN ES UN PAR PROBLEMA - SOLUCIN CON NOMBRE QUE SE PUEDE APLICAR EN NUEVOS CONTEXTOS, CON CONSEJOS ACERCA DE CMO APLICARLO EN NUEVAS SITUACIONES Y DISCUSIONES SOBRE SUS COMPROMISOS.
Algo elevado, no?. Pues si analizamos un poco esta definicin, podemos inferir lo que los autores nos intentan decir. Los patrones son una especificacin analtica reutilizable, con una estructura que responde a la siguiente: Nombre Solucin Problema [que resuelve] Ms que especificar ideas nuevas, los patrones pretender codificar conocimiento, estilos y principios existentes y que se han probado que son realmente vlidos. Esto quiere decir, que entre ms trillados y extendidos, mejor. Todos los patrones poseen nombres sugerentes, ya que definen en un solo concepto lo que estn resolviendo. Es por eso que los autores han procurado en definir estos nombres de una forma estndar para que los diseadores los utilicen como lenguaje comn. De esta forma, encontraremos nombres tan esotricos y descriptivos como Experto en Informacin, Creador, Factora, Variaciones Protegidas, etc. Los patrones de diseo nos ayudan a determinar las clases conceptuales que son ms aptas o que realmente compondrn nuestro software. Ahora bien, utilizar cualquiera de las clases conceptuales es un verdadero crimen, ya que estas clases representan el mundo real, por lo que no necesariamente corresponden a las clases de software. Es por eso que, como el proceso de desarrollo es iterativo, se define una regla bsica: Si hay clases relevantes en el Modelo de Diseo previo, considerar esa como posible clase de diseo real.
100
Si no hay clases relevantes, o no hay Modelo de Diseo previo, mire en el Modelo de Dominio e intente utilizar (o ampliar) sus representaciones para inspirar la creacin de las correspondientes clases de diseo. He aqu nuestro primer indicio de donde podemos encontrar las clases de diseo. Por otro lado, para comenzar el diseo por responsabilidades, primero debemos definir las responsabilidades del Sistema en general para luego delegar o desarrollar responsabilidades internas utilizando los patrones. Es por eso que podemos relacionar los artefactos convenientemente diciendo: El Caso de Uso sugiere los eventos del sistema que se muestran explcitamente en los Diagramas de Secuencia del sistema. Opcionalmente, podran describirse los detalles de los efectos de los eventos del sistema en trminos de los cambios de los objetos del dominio en los Contratos de las Operaciones del sistema. Los eventos del sistema representan los mensajes que inician los Diagramas de Interaccin, los cuales representan el modo en el que los objetos interactan para llevar a cabo las tareas requeridas (Realizacin de Casos de Uso). Los Diagramas de Colaboracin comprenden la interaccin de mensajes entre objetos de software cuyos nombres se inspiran algunas veces en los nombres de las clases del Modelo del Dominio, adems de otras clases de objetos. Ms adelante, cuando analicemos los patrones de diseo GRASP y GoF veremos cmo esta definicin se concreta en una lista de reglas que podemos usar al realizar nuestros casos de uso.

Para construir este modelo es necesario desarrollar los artefactos que lo conforman. Estos artefactos son: Diagrama de Colaboracin: Diagrama que muestra cules son las operaciones y cmo interactan entre s los objetos de diseo del sistema. Diagrama de Clases de Diseo: Diagrama que muestra una visin esttica de las clases del sistema, representando los tipos de objetos que se requieren para realizar la interaccin modelada en los diagramas de colaboracin.

Para crear los entregables del modelo (es decir, los artefactos de ste), se necesita proceder a travs del uso de tcnicas o recetas. Veamos cada una de ellas en detalle. DIAGRAMAS DE COLABORACIN UML nos dice que: 101
EL DIAGRAMA DE COLABORACIN DEFINE GRFICAMENTE PARA UN ESCENARIO ESPECFICO DE UN CASO DE USO LAS RESPONSABILIDADES GENERADAS ENTRE LOS OBJETOS DE DISEO DEL SISTEMA A PARTIR DE LAS OPERACIONES DEL SISTEMA.
Como podemos ver en la definicin encontramos cosas parecidas a los diagramas de secuencia, y esto tiene que ver porque vienen de un mismo tipo de diagramas (en UML se conocen como diagramas de interaccin). Sin embargo, el hincapi de estos diagramas o su motivacin tiene que ver en disear las responsabilidades delegadas a partir de la operacin de sistema (que ya conocemos) en los objetos internos del sistema. A este proceso de inferencia de responsabilidades se le conoce como aplicacin de responsabilidades. Para hacer estos diagramas, se necesita entender algo de la anatoma de ellos. Es por eso que definimos la notacin UML de los diagramas a continuacin:
Notacin Diagramas de Colaboracin/Comunicacin

:Objeto
Objeto
n: Expresion
Mensaje
:Objeto
Objeto Mltiple
n: [cond] Expresion
Mensaje Condicionado
{ ... }
Cdigo
n*: [cond] Expresion
Mensaje Cclico
n: var := mensaje(param: Tipo, ...) : TipoRetorno
Sintaxis de los mensajes
ILUSTRACIN 60. NOTACIN DE LOS DIAGRAMAS DE COLABORACIN
Debemos destacar que los diagramas de colaboracin los utilizaremos para describir las operaciones del sistema identificadas en los diagramas de secuencia con el detalle de operacin y diseo interno tal como ya lo hemos dicho. De esta manera, tendremos diagramas por cada una de las operaciones. Un ejemplo de diagrama podemos verlo en el caso del TPDV (caja de supermercado). Si elegimos la operacin de agregarProducto(cod, cant) en donde se agrega a la venta en curso una cantidad determinada de cierto cdigo de producto podemos obtener el siguiente diagrama:
102
ILUSTRACIN 61. DIAGRAMA DE COLABORACIN DE INGRESAR PRODUCTO PARA TPDV
Este diagrama es el reflejo de la lista de postcondiciones que se definen en el contrato de la operacin indicada. Estas postcondiciones son: Que se haya encontrado una instancia p de tipo Producto en c (de tipo Catalogo) cuyo atributo codigo tenga el mismo valor que el parmetro cod (responsabilidades 2 y 3). Que se haya creado una instancia ldv de tipo LineaDeVenta (responsabilidad 5). Que se haya asociado p a ldv (responsabilidad 7). Que se haya cambiado el atributo cantidad de ldv por el valor del parmetro cant (responsabilidad 6). Que se haya asociado ldv a v (responsabilidad 4, solo por entregar el control de la creacin a Venta).
La intensin de mostrar el diagrama no es dar la frmula de cmo se realizan sino ms bien ilustrar la forma cmo se utiliza la notacin anteriormente mostrada, ya que debemos seguir un proceso con el cual obtendremos este diagrama a partir del uso de patrones de diseo. PATRONES DE DISEO GRASP Los Patrones Generales de Software para la Asignacin de Responsabilidades (GRASP) no son ms que un conjunto patrones de diseo que nos ayudarn a definir nuestras responsabilidades,
El programa StarUML no permite poner mensajes sin secuencia, por lo que el diagrama qued con la operacin del sistema indicada por la responsabilidad nmero 1. Sin embargo, segn lo visto en clases, no es relevante.
103
es decir, describen los principios fundamentales del diseo de objetos y la asignacin de responsabilidades, expresados en forma de patrones. La asignacin habilidosa de responsabilidades es extremadamente importante en el diseo de objeto, ya que a menudo tiene lugar durante la creacin de los diagramas de interaccin, tal como dijimos antes, pero adems con mayor seguridad se realizar durante la programacin. A travs de patrones, este trabajo se hace mucho ms fcil, ya que no requieren de una validacin antes de ser implementados porque se est tan seguro de su validez gracias a su vasta utilizacin en diferentes problemas. En un principio, analizaremos algunos patrones bsicos y que se refieren a aspectos fundamentales del diseo. Sin embargo, existen otros que podran aparecer durante el estudio posterior. Para la definicin de cada patrn utilizaremos la pseudo-notacin sugerida anteriormente (Nombre, Solucin, Problema [que resuelve]). PATRN DE EXPERTO DE INFORMACIN
NOMBRE: EXPERTO DE INFORMACIN (O EXPERTO)
Solucin: Asignar una responsabilidad al experto en informacin la clase que tiene la informacin necesaria para realizar la responsabilidad. Problema: Quin debera ser el responsable de conocer una informacin particular? La informacin es una parte importante de los objetos, ya que definen sus caractersticas y su naturaleza. Es por ello que identificar el objeto que realmente debe contener una informacin particular se convierte en una preocupacin que durante la realizacin de los casos de uso debe ser resuelta. De esta manera, al identificar estos objetos, estaremos definiendo informacin relevante para el diagrama de clases de diseo. Por ejemplo, veamos el contrato de la operacin ingresarProducto:
104
Operacin: CO2. ingresarProducto(cod : CodigoBarras, cant : Int) Responsabilidad: Ingresar un producto representado por cod a la venta en curso. Tipo o Clase: Sistema Ref. Cruzadas: CU1. Realizar Venta Notas: Excepciones: - Si cod no existe, error. Salida: Operacin: CO2. ingresarProducto(cod : CodigoBarras, cant : Int)
Precondiciones: - Exista una instancia v de tipo Venta. - Exista una instancia c de CatalogoDeProductos. Postcondiciones: - Se haya encontrado una instancia p de Producto en el catlogo c que tenga como valor del atributo cdigo igual al valor cod entregado. - Se haya creado una nueva instancia ldv de LneaDeVenta. - Se haya asociado p a ldv. - Se haya cambiado el valor cantidad de ldv por n entregado. - Se haya asociado ldv a v.
ILUSTRACIN 62. CONTRATO DE OPERACIN INGRESAR PRODUCTO DEL SPDV
Para poder encontrar un producto dentro del catlogo, es importante saber quin tiene los cdigos de cada producto de manera de compararlo con el cdigo entregado por el cajero a travs de la caja (lector de cdigos o teclado). De esta manera, preguntamos entonces quin debe ser el responsable de conocer el cdigo de un producto?. Parece una pregunta sencilla de responder, porque el modelo conceptual de este problema lo plantea de forma explcita, pero en realidad debemos hacer la pregunta de todas maneras. La respuesta, entonces, queda claramente respondida diciendo que la clase Producto (que en este caso es clase conceptual) es el responsable de saber cul es su propio cdigo, ya que es parte de su definicin desde los requisitos. Sin embargo, como la operacin llega a la caja, debemos delegar la responsabilidad de realizar la bsqueda del producto que tenga el cdigo indicado en el contrato a la clase que trabaja ms estrechamente con el producto: la clase Catlogo. De esta manera, el diagrama se comienza a dibujar de la siguiente forma:
105
ILUSTRACIN 63. DELEGACIN DE RESPONSABILIDAD DE EXPERTO DE INFORMACIN
A pesar de que a travs del patrn es muy claro en asignar las responsabilidades de experto, existen algunos casos en los cuales la solucin propuesta por ste vaya en contra de otros patrones de asignacin de responsabilidad. Es por eso que es importante tener una visin general de todos los patrones antes de comenzar a dar responsabilidades indiscriminadamente (si lo vemos recursivamente, es una gran responsabilidad entregar responsabilidades). Los buenos diseadores no son aquellos que se cien al pie de la letra a recetas, sino ms bien, aquellos que poseen la visin de considerar todos los factores del problema para disear la mejor de las soluciones, o al menos la que mejor se ajusta a l. PATRN DE CREADOR
NOMBRE: CREADOR DE INSTANCIAS (O CREADOR)
Solucin: Asignar la responsabilidad a la clase B de crear instancias de la clase A si cumple uno o ms de los siguientes casos: B agrega objetos de A B contiene objetos de A B registra instancias de objetos de A B utiliza ms estrechamente objetos de A B tiene los datos de inicializacin que se pasar a un objeto de A cuando sea creado B es un creador de los objetos A Si se puede aplicar ms de una opcin, inclnese por una clase B que agregue o contenga la clase A. Problema: Quin debera ser el responsable de la creacin de una nueva instancia de alguna clase? La creacin de instancias es una actividad muy comn en sistema orientados a objetos, por lo que esta responsabilidad parecera algo trivial. Sin embargo, una asignacin adecuada de ella puede
106
hacer que nuestros diseos puedan soportar bajo acoplamiento, mayor claridad y alta reutilizacin. Por ejemplo en el mismo ejemplo de ingresarProducto, podemos buscar al creador de instancias de la clase LineaDeVenta. Si solo nos basamos en lo que dice el contrato y continuando con cada postcondicin, la creacin de la lnea de venta quedara en manos de Caja. Si aplicamos las condiciones del patrn tendramos que: Caja tiene los datos de inicializacin de LineaDeVenta (producto y cantidad) Sin embargo esto no es suficiente ya que debemos cumplir con al menos 2 caractersticas listadas. Si seguimos bajando en el diagrama de clases conceptuales, podemos consultar por Venta, ya que por naturaleza es contenedor de LineaDeVenta. Listemos las caractersticas que cumple Venta para ser creador: Venta contiene objetos de LineaDeVenta Venta utiliza estrechamente objetos de LineaDeVenta (de hecho lo requiere para varias operaciones del sistema) Venta no tiene los datos de inicializacin de LineaDeVenta, pero puede tenerlo (por delegacin de la caja) De esta forma, podemos rpidamente hacer que Venta tenga 3 caractersticas convirtindola en un mejor candidato para ser creador de LineaDeVenta. Si tratamos de buscar otro no encontraremos una clase que tenga mejores condiciones, as que el diagrama sera el siguiente:
ILUSTRACIN 64. DELEGACIN DE RESPONSABILIDAD DE CREADOR DE INSTANCIAS
107
Al igual que todos los patrones que estamos viendo, ellos definen una gua ms que una receta, por lo que el arquitecto es quien definir si lo que se presume a travs del patrn es en realidad un buen candidato. Esto puede pasar cuando analizamos el patrn de Creador en casos en donde requerimos utilizar instancias recicladas. PATRN DE CONTROLADOR
NOMBRE: CONTROLADOR
Solucin: Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa una de las siguientes opciones: Representa el sistema global, dispositivo o subsistema (controlador de fachada). Representa un escenario de caso de uso en el que tiene lugar el evento del sistema (controlador de sesin o de caso de uso). A menudo este es nombrado como <Nombre>Controlador, <Nombre>Manejador o <Nombre>Coordinador. Problema: Quin debe ser responsable de gestionar un evento de entrada al sistema? Antes que todo, un evento de entrada al sistema no es ms que un evento generado por un actor externo. Se asocian con las operaciones del sistema que son las respuestas a esos eventos, tal como se relacionan los mensajes y los mtodos. Es importante tener en claro que las clases de tipo Controlador se refiere a clases que no pertenecen a la interfaz del usuario (la caja), sino que define el mtodo para la operacin del sistema. Siguiendo con el ejemplo de ingresarProducto, tenemos que la operacin del sistema debe ser recibida por alguien. En este caso tenemos 2 alternativas: a) Caja es la clase que representa el sistema completo (en esta caso la clase sera CajaControlador) b) Venta es la clase que representa el CU Registrar Venta (y en este caso quedara como VentaControlador) La eleccin es del arquitecto, por lo que la mejor opcin depende de la complejidad. Si el sistema es grande, a lo mejor separar el controlador lo hace ms especializado para cada uno de los subproblemas, pero si no, si el problema no es muy grande, un controlador nico es ms sencillo de implementar. En este caso quedara el diagrama:
108
ILUSTRACIN 65. IDENTIFICACIN DEL CONTROLADOR DE LAS OPERACIONES DEL SISTEMA
Como vemos en el diagrama, en realidad lo nico que estamos incorporando es la primera clase, pero sin cambiar responsabilidades internas, an cuando es ms recomendable el anlisis antes de cualquier otro patrn. Adems, cuando analicemos las otras operaciones, lo primero que deberemos preguntar es si el controlador anteriormente identificado aplica a las nuevas operaciones o no, por lo general si (sobre todo si representa al sistema completo como el de ingresarProducto). De los patrones que veremos en este curso, este es uno de los complejos de utilizar, porque posee muchas aristas. Sin embargo, existen algunas recomendaciones al respecto que pueden ser tiles de analizar: Siempre utilice controladores de bajo acoplamiento y alta cohesin, algo que aprenderemos en los siguientes patrones. No trate de saturar los controladores con funciones de todo tipo. Recuerde que puede utilizar controladores modulares dependiendo del caso de uso o componente determinada. Antes de crear una clase controlador, siempre verifique que su diseo ya no tiene una que, en forma innata, puede tomar ese rol. No entregue funciones del controlador a la interfaz del usuario. PATRN DE ALTA COHESIN
NOMBRE: ALTA COHESIN
Solucin: Asignar una responsabilidad de manera que la cohesin permanezca alta. Problema: Cmo mantener la complejidad manejable? Antes de poder responder a esta pregunta, nos preguntamos qu es la cohesin. Este concepto tiene relacin a la fuerza con la que se relacionan y el grado de focalizacin de las responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas y que no hace gran cantidad de trabajo tiene una alta cohesin. Para nosotros, es mucho ms importante que nuestros objetos posean una alta cohesin, ya que los objetos una baja cohesin nos complica ms el problema. Los objetos de baja cohesin son difciles de entender, reutilizar, mantener y delicados, es decir, constantemente afectados por los cambios.
109
Por ejemplo, en el caso de la operacin ingresarProducto, tenemos que la complejidad de las clases se mantienen en un nivel bajo, ya que cada una de las responsabilidades asignadas son de una naturaleza innata a la concepcin de la clase respectiva (el controlador solo controla, la Venta solo crea LineaDeVenta, el Catlogo solo consulta Productos, etc). Existen en la literatura muchas recomendaciones con respecto a la cohesin en el diseo orientado a objetos, es por eso que debe ser un factor muy importante cuando se trabajo con l. Sin embargo, y como ya hemos querido destacar a travs de estas pginas, el nivel de cohesin debe ser considerado siempre con la compaa de otros patrones como el de acoplamiento y experto. De hecho, el ejemplo utilizado, adems de ser de Alta Cohesin, cumple con la condicin de Bajo Acoplamiento segn lo que vamos a ver a continuacin. PATRN DE BAJO ACOMPLAMIENTO
NOMBRE: BAJO ACOPLAMIENTO
Solucin: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo. Problema: Cmo soportar bajas dependencias, bajo impacto al cambio e incremento de la reutilizacin? Grandes preguntas que todos nos hacemos cuando diseamos software. Lo primero es entender que acoplamiento se refiere a una medida de fuerza con que un elemento est conectado a, tiene conocimientos de y confa en otros elementos. En otras palabras, un bajo (o dbil) acoplamiento de un elemento es cuando ste no dependen mucho de otros elementos. De esta forma, si tuviramos elementos con alto acoplamiento, se presentan problemas de que los cambios en las clases relacionadas fuerzan a cambios locales, son difciles de entender en forma aislada y de reutilizar puesto que su uso requiere la presencia adicional de las clases de las que depende. Por ejemplo, tal como dijimos en el patrn anterior, la asignacin de responsabilidades de ingresarProducto, adems de ser de alta cohesin, es de bajo acoplamiento en algunas partes, ya que la dependencia de clases que hay entre el Controlador y las clases relacionadas con la venta (Venta LineaDeVenta Producto) y la coleccin de productos (Catlogo Producto) es baja. En estos casos de hecho son independientes entre s, porque una de ellas no afecta a la otra. Al igual como hemos mencionado, es importante utilizar este patrn en relacin a los dems, ya que, como vimos en el ejemplo, estn estrechamente relacionados. Por otro lado, algunos indicadores de acoplamiento en algunos lenguajes se pueden detectar en los siguientes casos: A tiene un tributo que hace referencia a una instancia de B. Un objeto de A invoca los servicios de un objeto de B. A tiene un mtodo que referencia a una instancia de B, o al propio B de alguna forma (parmetro o tipo de retorno).
110
A es una subclase directa o indirecta de B. A es una interfaz y B implementa esa interfaz. Estos indicadores deben ser considerados solo como eso, ya que si fusemos extremadamente rigurosos, la orientacin al objeto no podra ser realizada, ya que no usaramos interfaces, asignaciones de objetos, etc. Es por eso que el diseador debe tener en cuenta estos detalles para mantener un Bajo Acoplamiento pero nunca intentar eliminarlo (usar lo mnimo necesario para el sistema en desarrollo). Un tema particular en donde el acoplamiento no es malo es cuando se utilizan libreras estables y extendidas, es decir, aquellas libreras en donde estamos seguros que si cambia algo funcional dentro, nuestros desarrollos no se vern afectados mayormente. OTROS PATRONES GRASP Los 5 patrones antes vistos corresponden a los bsicos que se utilizan en el GRASP para determinar responsabilidades en las realizaciones. A continuacin enumeraremos otros patrones que son importantes ya que entregan informacin o definen tcnicas para la implementacin y que complementan nuestro anlisis de operaciones.
NOMBRE: POLIMORFISMO
Solucin: Cuando una responsabilidad posee varias alternativas para comportamientos similares, se asignarn a los tipos en que el comportamiento presenta las variantes. Problema: Cmo manejar las alternativas basadas en el tipo?
NOMBRE: FABRICACIN PURA
Solucin: Asignar un conjunto altamente cohesionado de responsabilidades a una clase artificial que no pertenece al dominio. De esta manera, lo que estamos haciendo es crear un nuevo tipo o clase que no tiene otra funcin ms que mantener nuestro sistema altamente cohesivo, de bajo acoplamiento y potenciando la reutilizacin de componentes. Problema: Quin es el responsable de mantener la alta cohesin y el bajo acoplamiento cuando ya no tenemos ms alternativas en nuestro modelo? Cuando para el problema planteado el uso de las clases del dominio nos provoca que nuestro modelo se est transformando en uno con mala cohesin y acoplamiento, es necesario buscar una solucin an cuando esta no se encuentre en el alcance conceptual.
NOMBRE: INDIRECCIN
Solucin: Se asigna la responsabilidad a un objeto intermedio, de manera tal que medie entre componentes o servicios para que no terminen directamente acoplados. De esta manera ese intermediario crea una indireccin entre el resto de los componentes o servicios. Problema: De qu manera podemos desacoplar los objetos para as mantener una potencial reutilizacin y un bajo acoplamiento? Quin debe tener la responsabilidad de mediar para mantener la indireccin entre las componentes? 111
NOMBRE DEL PATRN: NO HABLES CON EXTRAOS Solucin: Se asigna la responsabilidad a un objeto directo del cliente para que colabore con un objeto indirecto, de modo que el cliente no necesite saber nada del objeto indirecto. Este patrn establece que en un mtodo, los mensajes solo deberan enviarse a los siguientes objetos: El objeto this. Un parmetro del mtodo. Un atributo de this. Un elemento de una coleccin que sea atributo de this. Un objeto creado al interior del mtodo. De esta manera, los objetos directos con conocidos del cliente, en cambio los indirectos son extraos, y un cliente solo debera tener conocidos, pero no extraos. Por lo tanto, con este patrn estamos no acoplando el conocimiento de los objetos indirectos ni las representaciones internas de los objetos directos al cliente. Problema: Quin debe ser el responsable de evitar conocer la estructura de los objetos indirectos? Si un objeto cliente conoce la estructura interna de otros objetos presenta alto acoplamiento. Si un objeto cliente conoce las conexiones y representacin interna de otros, cmo podr entonces hacerlo sin acoplarse al conocimiento de la estructura de su objeto servidor o de los indirectos? PATRONES DE DISEO GOF Los Patrones de Diseo GoF (Gang of the Four7) son un grupo de patrones que los autores actualmente utilizan en su mayora como la base para el diseo. Si bien es cierto, GRASP daba algunos indicios de cmo hacer el diseo OO, con GoF se incluyen conceptos mucho ms especficos como constructores, adaptadores, puentes, entre otros y que son muy tiles al momento de disear un sistema orientado al objeto. A diferencia de GRASP, los patrones GoF se describen en base a una estructura un poco ms compleja, pero la base es la misma, y es la siguiente: Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la comunidad (normalmente se expresa en ingls). Clasificacin del patrn: creacional, estructural, de comportamiento o de sistema. Intencin: Qu problema pretende resolver el patrn?
Gang of The Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
112
Tambin conocido como: Otros nombres de uso comn para el patrn. Motivacin: Escenario de ejemplo para la aplicacin del patrn. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrn. Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que participan en el patrn. Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del patrn. Im<plementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn. Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn. Usos conocidos: Ejemplos de sistemas reales que usan el patrn. Patrones relacionados: Referencias cruzadas con otros patrones.
Para que no entremos en tanto detalle veamos ahora una pequea descripcin de los patrones GoF segn su clasificacin: PATRONES CREACIONALES Los patrones de diseo creacionales son todos aquellos que se aplican en la creacin de instancias de objetos en general. Estos patrones son: Abstract Factory (Fbrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre s y haciendo transparente el tipo de familia concreta que se est usando. Builder (Constructor virtual): Abstrae el proceso de creacin de un objeto complejo, centralizando dicho proceso en un nico punto. Factory Method (Mtodo de fabricacin): Centraliza en una clase constructora la creacin de objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica para elegir el subtipo que crear. Prototype (Prototipo): Crea nuevos objetos clonndolos de una instancia ya existente. Singleton (Instancia nica): Garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso global a dicha instancia.
113
PATRONES ESTRUCTURALES Los patrones de diseo estructurales define objetos como estructuras de control que sirven en diferentes formas. Estos patrones incluyen: Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podra utilizarla. Bridge (Puente): Desacopla una abstraccin de su implementacin. Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente. Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema. Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idntica informacin. Proxy: Mantiene un representante de un objeto.
PATRONES DE COMPORTAMIENTO Los patrones de diseo de comportamiento definen algunos tipos de comportamientos de los objetos y entregan informacin de cmo realizar dichos comportamientos. Estos patrones son: Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma. Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas necesarias para interpretarlo. Iterator (Iterador): Permite realizar recorridos independientemente de la implementacin de estos. sobre objetos compuestos
Mediator (Mediador): Define un objeto que coordine la comunicacin entre objetos de distintas clases, pero que funcionan como un conjunto. Memento (Recuerdo): Permite volver a estados anteriores del sistema. Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automticamente todos los objetos que dependen de l. State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. 114
Strategy (Estrategia): Permite disponer de varios mtodos para resolver un problema y elegir cul utilizar en tiempo de ejecucin. Template Method (Mtodo plantilla): Define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar las clases sobre las que opera.
PATRONES DE SISTEMA Los patrones de diseo de sistema definen algunas caractersticas que dependen de la arquitectura y que deben ser reflejadas en las realizaciones. Estos patrones son: MVC (Modelo Vista Controlador): Divide un componente o un subsistema en tres partes lgicas: modelo, vista y controlador, facilitando la modificacin o personalizacin de cada parte. Session (Sesin): Ofrece una forma de que los servidores de sistemas distribuidos sean capaces de distinguir los clientes, permitiendo que las aplicaciones asocien el estado con la comunicacin entre el cliente y el servidor. Worker Thread (Thread trabajador): Mejora la productividad y minimiza la latencia media. Callback (Retrollamada): Permite que un cliente se registre en un servidor para ciertas operaciones. De esta forma, el servidor puede notificar al cliente cuando la operacin ha finalizado. Succesive Update (Actualizacin Sucesiva): Ofrece a los clientes una forma de recibir actualizaciones continuas. Router (Encaminador): Desacopla mltiples fuentes de informacin de los objetos de esa informacin. Transaction (Transaccin): Agrupa una coleccin de mtodos de forma que todos ellos finalicen correctamente o fallen de forma colectiva.
DIAGRAMA DE CLASES DE DISEO El resultado del diseo (y que por supuesto es de todo nuestro trabajo en este curso) por excelencia es el Diagrama de Clases de Diseo (DCD). Por eso, comenzaremos diciendo que:
LOS DIAGRAMAS DE CLASES DE DISEO SON FIGURAS QUE MUESTRAN LA ESPECIFICACIN DE LAS CLASES E INTERFACES DE SOFTWARE QUE PARTICIPAN EN LA SOLUCIN.
115
A partir de esta definicin podemos entender, por lo tanto, que el DCD contiene realmente el software como debe ser programado. En ellos encontramos toda la especificacin necesaria para la implementacin, ya que en ellos se describen los atributos, tipos relevantes y mtodos que responden a las responsabilidades que cada clase posee. As, lo que encontraremos en este detalle es: Clases, asociaciones y atributos Interfaces, con sus operaciones y constantes Mtodos Tipos de datos Navegabilidad Dependencias Por lo tanto, el nivel de detalle es alto porque a partir de este diagrama se deben escribir las estructuras de clases que compondrn el sistema a implementar, y tambin gran parte de la lgica interna de cada uno de los mtodos. De esta manera, la construccin del sistema est muy completa, dejando poco trabajo para la fase de implementacin real. La notacin que se utiliza en estos diagramas es muy parecida a la que usamos en el diagrama de clases conceptuales. Sin embargo, es importante diferenciarlos, ya que en los DCD estamos especificando las clases de software que sern implementadas y no solo conceptos que representan elementos del negocio. Esta notacin UML es la siguiente:
116
Notacin Diagramas de Clases

metaclass Nombre -a
Metaclase
1..1 0..* -a
Asociacin
Nombre -atrib : byte +oper() : char
Agregacin Clase
1..1 0..* -a
Composicin
1 Objeto 0..*
Objeto/Instancia Herencia/Generalizacin
datatype TipoDeDatos
Tipo de Dato Implementacin de Interfaz
interface Interfaz
Interfaz
Interfaz Dependencia
Param Clase
Tipo Parametrizado Nota
Paquete
Paquete
{}
Restriccin
ILUSTRACIN 66. NOTACIN PARA LOS DIAGRAMAS DE CLASES DE DISEO
Veamos un ejemplo en el cual se nota la diferencia entre el modelo conceptual y las clases de diseo. Tomemos la asociacin que hay entre Caja y Venta en el problema del supermercado. Para el diagrama de clases conceptuales, tenemos lo siguiente:
ILUSTRACIN 67. ASOCIACIN A NIVEL DE CLASES CONCEPTUALES
Despus de las realizaciones, este diagrama se convierte en algo ms parecido a:
ILUSTRACIN 68. ASOCIACIN A NIVEL DE CLASES DE DISEO
117
Ms adelante descubriremos notacin adicional para otro tipo de situaciones especficas y que se relacionan con nuevos patrones de asignacin de responsabilidades. Slo es importante recordar: Considerar cul es la audiencia del DCD nos dar el nivel de detalle. El DCD es un apoyo y una base para la implementacin, por lo es necesario evitar el detalle exhaustivo cuando ste pueda provocar confusin. TCNICA DE CONSTRUCCIN DE LOS DCD En el proceso normal de generacin del DCD, todo comienza por identificar las clases de diseo a partir de los diagramas de interaccin. An cuando esto ya lo hemos hecho de manera parcial, es bueno que reunamos toda la informacin en un solo diagrama.
PASO 1: IDENTIFICACIN DE LAS CLASES DE DISEO Y SUS ATRIBUTOS
Lo primero que hacemos es dibujar las clases que se encuentran en los diagramas de interaccin y les ponemos los atributos identificados en el Modelo de Dominio:
ILUSTRACIN 69. IDENTIFICACIN DE LAS CLASES DE DISEO
IDENTIFICANDO LOS NOMBRES DE LOS MTODOS DE LAS CLASES DE DISEO
Una vez que eso se encuentra dibujado, comenzamos aadiendo los nombres de los mtodos de manera anloga a las responsabilidades identificadas en las realizaciones. De esta forma, los mensajes que encontramos en los diagramas de interaccin se convierten en mtodos fsicos de la clase:
ILUSTRACIN 70. IDENTIFICACIN DE UN MTODO A PARTIR DE UNA COLABORACIN
118
De esta forma, nuestro DCD va creciendo y se convierte en:
ILUSTRACIN 71. IDENTIFICACIN DE MTODOS DE LAS CLASES
Algo muy importante al bautizar los mtodos es tener en cuenta algunas cuestiones que definen un buen diseo: La instanciacin o inicializacin de objetos no es una cuestin estndar para todos los lenguajes orientados al objeto, por lo que generalmente se omiten en los DCD (en Java, nos referimos a los constructores). Cuando se hace referencia a la obtencin de valores de un objeto (mtodo de obtencin o de acceso) o al cambio de valores de un objeto (mtodo de mutacin o de cambio) se utiliza generalmente el nombre como get/set ms el atributo que acceden. Por ejemplo, existe el mtodo getCodigo en la clase Producto que entrega el total de la venta. Sin embargo, no se requiere especificar en el DCD todos los mtodos accesadores o mutadores, ya que implicara tener una lista muy grande de mtodos que son irrelevantes para el diseo, es por eso que solo aparecen aquellos que son relevantes o que generan algn valor para el diseo. La sintaxis que se utilice en los DCD debera corresponder a la sintaxis bsica de UML y no a alguna en particular del lenguaje de implementacin. Idealmente la traduccin se debe realizar cuando se implemente el cdigo que representa el diseo deseado. Sin embargo, en ninguna parte UML niega el uso de otra sintaxis en sus diagramas, por lo que queda a criterio del diseador finalmente.
AGREGANDO INFORMACIN DE LOS TIPOS DE DATOS
La informacin de tipos de datos en los DCD es relevante, ya que agrega informacin de bajo nivel para los desarrolladores o para las herramientas que generan el cdigo en forma automtica. Sin embargo, la decisin de agregar los tipos de datos y los parmetros a los mtodos pasa por una definicin del diseador considerando que: Si se est utilizando una herramienta CASE que genera cdigo en forma automtica, el detalle de los tipos debe ser exhaustivo y concordante con el lenguaje que se utilizar en la implementacin. 119
Si el DCD es solo para que lo vean los desarrolladores, agregar muchos detalles de tipos y parmetro podra complicar el modelo ms que aclararlo porque se convierte en mucho ruido para ellos. En este caso la recomendacin es utilizar tipos de datos lgicos que representen la informacin a guardar (por ejemplo, Texto, Nmero, CdigoDeBarras, etc). Sin embargo, tomar la decisin en si agregar o no el detalle debe ser considerado la audiencia que deber utilizar este modelo, ya que si para la audiencia son obvios algunos de los tipos y parmetros del DCD, es posible omitirlos.
ASOCIACIONES Y NAVEGABILIDAD EN LOS DCD
Como es de esperar, el DCD no est completo si no asociamos las clases entre ellas. Estas asociaciones son similares y contrastadas con las que generamos en el Modelo Conceptual, ya que responden al mismo principio con las que se generaron esas. De esta forma, antes de poner una asociacin, es necesario preguntarse qu asociaciones se requieren para satisfacer la visibilidad y las necesidades de memoria actuales que se indican en los diagramas de interaccin?. Esta visibilidad requerida es necesaria en los siguientes casos comunes: Cuando A enva un mensaje a B. Cuando A crea una instancia de B. Cuando A necesita mantener una conexin a B. Una vez que se ha encontrado la asociacin, es necesario adems darle el concepto de navegabilidad. Con esto, se le da un nivel de dependencia a la asociacin, lo que se traduce en visibilidad de atributo:
ILUSTRACIN 72. AGREGANDO ASOCIACIONES CON NAVEGABILIDAD
De esta forma, CajaControlador tiene una visibilidad de atributo de Venta, lo que se traduce que la clase CajaControlador posea un atributo de tipo Venta. Pero dnde queda ese atributo en el DCD?. Es posible que opcionalmente se ponga ese atributo sobre la flecha hacia el lado del tipo de destino (Venta), pero no es absolutamente necesario ya que se puede nombrar posteriormente en la implementacin. En nuestro ejemplo de la caja del supermercado, el DCD se convierte en:
120
ILUSTRACIN 73. DIAGRAMA DE CLASES DE DISEO PARCIAL PARA EL SPDV
Como ven en el ejemplo, el DCD es bastante simple de ver, sin embargo se ha construido a partir de los diagramas de interaccin de las realizaciones. No se incluyeron los tipos de datos ni parmetros de mtodos, porque la audiencia es acadmica y no nos entrega un valor agregado ms que confundirnos en el modelo de diseo. Ntese adems que el DCD que es mucho menos extenso que el modelo conceptual, porque se basa netamente en el diseo del sistema que responde a los eventos del mismo.
RELACIONES DE DEPENDENCIA ADICIONALES
As mismo como la navegabilidad representa la visibilidad de atributo, debemos de alguna forma representar la visibilidad de parmetro, local o global. Esto se hace con flechas punteadas que indican cules son las clases que requieren esa relacin. De esta forma, nuestro diagrama ejemplo pasa a conformarse de la siguiente forma:
Se han omitido los tipos de datos en el diagrama de manera totalmente intencional, para la visin completa de ste en el documento.
121
ILUSTRACIN 74. DIAGRAMA DE CLASES DE DISEO REFINADO PARA EL SPDV
En el ejemplo, aparece una visibilidad de parmetro entre Venta y Producto, ya que el mtodo crearLineaDeVenta requiere una instancia de Producto para ser asociada en LineaDeVenta (en donde si est la visibilidad de atributo explcita en el DCD).
VISIBILIDAD DE ATRIBUTOS Y MTODOS
Hasta ahora todos los diagramas que hemos visto muestran unos pequeos signos en su definicin. Estos signos no son adornos ni tampoco es casualidad que ah estn, sino que representan la visibilidad que tienen los atributos y la visibilidad que tienen los mtodos en el modelo. UML no obliga a utilizar esto modificadores, pero nos daremos cuenta que algunos CASE los ponen por defecto como - a los atributos y + a los mtodos. Por qu es esto? El modificador - indica que el atributo o mtodo es privado, esto quiere decir que el alcance que tiene es solo dentro de la clase en la cual est definido. El modificador + indica que el atributo o mtodo es pblico, lo que significa que el alcance que tiene es dentro y fuera de la clase. Por defecto en UML, si estos modificadores no se especifican en el DCD, se supondr que los atributos son privados y los mtodos son pblicos.
CUERPO DE LOS MTODOS
Por ltimo, y opcionalmente, es posible utilizar cuerpos de cdigo en los mtodos que especifiquen cmo se implementan con pseudocdigo o algn lenguaje en particular. Sin embargo, debemos recordar que todo el detalle que pongamos en el DCD es para apoyar la etapa de implementacin y no debe significar mayor complejidad para los desarrolladores. Desde el punto de vista de notacin, el cuerpo de los mtodos va sin la firma del mtodo (encabezado) y solo se describe el contenido, de la siguiente forma:
122
ILUSTRACIN 75. REPRESENTACIN EN LA CODIFICACIN DE LA CLASE
TEMAS COMPLEMENTARIOS
GENERALIZACIN
La generalizacin se refiere a la definicin de subtipos a raz de una definicin similar respecto a diferentes objetos. Esta definicin se puede utilizar a partir del modelo conceptual, sin embargo tampoco es tarde utilizarlo en el diseo. Para la notacin se agrega la utilizacin de un nuevo tipo de asociacin. La clase B es un subtipo de la clase A cuando sta ltima posee caractersticas comunes, pero la primera posee caractersticas y/u operaciones que le permiten realizar acciones particulares para dicha clase. En ese sentido, la definicin de la clase B contiene el 100% de las caractersticas y operaciones de A, pero no al revs. Por ejemplo, si definimos los tipos de pago en el punto de venta, podramos decir que existe una jerarqua de tipos respecto a las clases de pagos que se pueden utilizar (PagoEnEfectivo, PagoConTarjeta, PagoConCheque). De esta forma el modelo quedara definido como:
ILUSTRACIN 76. GENERALIZACIN DE LOS TIPOS DE PAGO EN EL SPDV
Existe una regla simple para definir si existe una razn para definir un subtipo.
123
El subtipo tiene algn atributo particular de inters. El subtipo tiene alguna operacin particular de inters. El subtipo se opera con un concepto diferente para el subtipo, en relacin a lo relevante de ste. El subtipo representa alguna entidad fsica que se comporta en manera diferente al supertipo.
AGREGACIN
La agregacin se utiliza cuando existe una dependencia directa entre dos clases, de manera de que la clase dependiente no puede existir sin su generadora. Para la notacin se utiliza un rombo pintado indicando la clase generadora: La clase A agrega uno o ms objetos de B. Es importante definir la agregacin cuando sta corresponda. Por ejemplo en el caso del Punto de Venta podemos encontrar agregacin en algunas clases del DCD como Venta y LineaDeVenta, ya que no pueden existir referencias a una LineaDeVenta si no existe la Venta primero. Es por eso que la relacin queda as:
ILUSTRACIN 77. AGREGACIN DE PRODUCTOS EN EL SPDV
COMPOSICIN
La composicin se utiliza cuando no existe una dependencia directa entre dos clases, pero si se requiere tener una referencia de la otra. Para la notacin se utiliza un rombo en blanco indicando la clase que necesita tener relacin: La clase A compone uno o ms objetos de B. Al igual como lo hicimos con la agregacin, la definicin se debe realizar correctamente solo cuando una de ellas requiere tener una referencia de la otra en su definicin (atributos). Por ejemplo en el caso del Punto de Venta podemos encontrar composicin en el DCD entre Catalogo y Producto, ya que los productos de la tienda siempre deben existir por si solos, pero el catlogo es solamente el medio para que puedan acceder a l. Es por eso que la relacin queda as:
124
ILUSTRACIN 78. COMPOSICIN DE LNEAS DE VENTA EN EL SPDV

Ahora continuaremos la realizacin del ejemplo del sistema electrnico de ficha de pacientes que comenzamos a desarrollar la unidad anterior, complementando lo que se refiere a los modelos de diseo y los componentes del sistema.
En este ejemplo solo nos referiremos al diagrama de componentes del modelo. DIAGRAMA DE COMPONENTES La primera premisa para nuestro diagrama es que separaremos las capas de interfaz grfica de las funcionales (negocio) y operativa, es decir, utilizaremos un modelo de 3 capas de diseo arquitectnico. CAPA FUNCIONAL La capa funcional estar compuesta de 3 componentes bsicos y que son separados por su naturaleza: Gestin de la Ficha (creacin y consulta de la ficha de un paciente) Gestin de la Consulta Mdica (ingreso de anamnesis) Gestin de los Procedimientos (ingreso de observaciones y resultados)
Ahora bien, tanto la capa Consulta Mdica como la capa Procedimiento requieren trabajar con la ficha, por lo que tambin existirn algunas dependencias entre ellas:
125
ILUSTRACIN 79. ASOCIACIONES ENTRE LOS COMPONENTES FUNCIONALES
Como podemos ver, las interfaces que exponemos para la comunicacin entre los paquetes nos definen algunas operaciones que se realizarn en los diagramas de colaboracin. De esta manera, estamos obligando que las clases las debamos discriminar de acuerdo a la naturaleza del componete: Componente Ficha: Todas las clases que operen con la ficha. Componente Consulta Mdica: Todas las clases que operen con la anamnesis. Componente Procedimiento: Todas las clases que operen con los procedimientos.
Es fcil ver que el centro del negocio est en las clases que controlan las fichas de los pacientes y que el resto en realidad no es tan relevante como habamos pensado, por lo que nos sugiere que en realidad no necesitamos tantos componentes, sino que solo uno principal y que contenga todas las operaciones del sistema con la ficha, sin embargo, para el ejemplo, mantendremos la consistencia con el diseo realizado y seguiremos mantenindolo por separado. Lo que nos queda ahora es exponer los servicios que van hacia la interfaz grfica y completar el diagrama con la capa completa:
ILUSTRACIN 80. CAPA FUNCIONAL DEL SEFP
CAPA DE INTERFAZ Las operaciones expuestas en la capa funcional (que particularmente son solo las de sistema) no son para que las use el usuario final directamente, sino que para que sean gatilladas a partir de la interfaz. De esta manera, podramos (y optimizando el diagrama anterior) organizar el sistema de la siguiente manera: 126
ILUSTRACIN 81. CAPAS DE INTERFAZ Y FUNCIONAL DEL SEFP
Lo que finalmente describimos es una componente grfica por lugar donde funcionar el sistema y relacionamos con qu servicio expuesto se comunican dichas componentes directamente. As podemos discriminar cmo organizar tambin los programas de la interfaz grfica fcilmente. CAPA DE DATOS Por ltimo, debemos tambin comunicarnos con la capa de datos, la cual es la que gestiona las tablas de la base de datos y muestra los servicios expuestos necesarios para trabajar con la capa funcional. Este sera entonces el diagrama final de componentes del sistema:
ILUSTRACIN 82. CAPAS DE COMPOENTES DEL SEFP
127
Como podemos notar, el Registro de Fichas es una componente que representa la interaccin con la base de datos directamente. De esta manera, cuando se desea, por ejemplo, realizar una bsqueda de una ficha por el rut, es necesario que se obtenga la ficha desde la base (a travs de un select de la tabla respectiva). En particular, solo se exponen 2 servicios bsicos que son consultar y registrar (similar a un select y un update en SQL), los cuales son consumidos solo por la componente de Ficha.
MODELO DE DISEO
Para poder realizar el diseo es necesario que recordemos un artefacto que no da el primer indicio del diseo del sistema: el diagrama de clases conceptuales:
DetalleDeFicha +rut +nombre +direccion +telefono +email 1 1 es-descrita-por FichaDePaciente 1 1 1 0..1 crea 1 contiene 0..* Laboratorista Procedimiento 1 ingresa es-descrita-por 1 DetalleProcedimiento +observaciones 0..1 +resultados +diagnostico +cotiene 0..* Anamnesis Especialista Recepcionista 1 posee Paciente
1 1
1 es-descrita-por 0..1 ingresa
DetalleAnamnesis +datos_inspeccion +observaciones +indicaciones +otros
ILUSTRACIN 83. DIAGRAMA DE CLASES CONCEPTUALES DEL SEFP
En la construccin del modelo de diseo, comenzaremos con los Diagramas de Colaboracin que representan las realizaciones de las operaciones del sistema a partir de los objetos de diseo que participan. Para esto utilizaremos los Patrones de Diseo (GRASP y GoF) de manera de normalizar la asignacin de responsabilidades a un buen diseo. Finalmente transformaremos esta informacin en un Diagrama de Clases de Diseo completo en donde se describe el detalle del sistema antes de su implementacin.
128
DIAGRAMAS DE COLABORACIN Los diagramas de colaboracin realizan las interacciones necesarias para que lo objetos colaboren bajo el objetivo de cumplir las operaciones de cada caso de uso. Por lo tanto, el diseo de responsabilidades lo realizaremos en funcin de cada contrato descrito en el modelo de comportamiento.
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: CO1. validarRut(rut) Validar que el RUT exista dentro del catalogo de pacientes Sistema CU1 Si el RUT existe, se aborta el resto del CU - Exista una instancia r de tipo CatalogoDePacientes - No se haya encontrado una instancia f de FichaDePaciente dentro de r que tenga asociada una instancia d de DetalleDeFicha que tenga como atributo rut el valor del parmetro rut. ILUSTRACIN 84. CONTRATO DE LA OPERACIN VALIDARRUT
Lo primero que debemos buscar en este caso es qu objeto debe ser el controlador de la operacin. Es fcil ver que como no tuvimos nunca una clase que represente nada fsico del sistema, siempre utilizamos Sistema como tal. As que, como estamos hablando de aplicar el patrn de controlador, deberemos decidir si: Lo utilizamos como un controlador general del sistema (SistemaControlador, por ejemplo). Lo utilizamos como un controlador modular (RegistroControlador, por ejemplo).
Para que podamos probar los controladores modulares, en este caso elegiremos la segunda opcin. Adems, que el ejemplo es bastante bueno para que podamos separar las funciones en cada mbito de la atencin mdica. Si seguimos aplicando otros patrones, por ejemplo, para validar el rut debemos identificar de quin es la responsabilidad de conocer o mantener conocimiento de las fichas de los pacientes. Con el patrn de experto podemos determinar que ese es el CatlogoDePacientes, que ya tenamos identificado anteriormente. Por ltimo, sabiendo que el experto de informacin de conocer el rut de un paciente es DetalleDeFicha, y aplicando el patrn de cadena de responsabilidad (de GoF), podemos llevar la responsabilidad desde el controlador hasta el mismo objeto para entregar el valor del rut pidindole a CatalogoDePacientes, luego a FichaDePaciente y que realice la validacin si existe una ficha (esperamos respuesta negativa por supuesto). De esta manera, el primer diagrama de colaboracin quedara como sigue:
129
ILUSTRACIN 85. DIAGRAMA DE COLABORACIN PARA VALIDARRUT
De una forma anloga, podemos revisar el segundo contrato:

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: CO2. ingresarDetalle(rut, nombre, direccion, fono, email) Crear y agregar la informacin bsica del paciente a la ficha Sistema CU1 - Se haya creado una instancia d de tipo DetalleDeFicha - Se hayan fijado los atributos rut, nombre, direccin, telfono e email con los valores entregados por parmetro. - Se haya creado una instancia f de tipo FichaDePaciente - Se haya asociado d a f ILUSTRACIN 86. CONTRATO DE LA OPERACIN INGRESARDETALLE
Es fcil ver que debemos primero buscar si el anterior controlar de las operaciones aplica en sta, y la respuesta es s, porque seguimos en el mismo mdulo (CU) de registro de paciente. Por otro lado, como debemos crear un DetalleDeFicha, debemos buscar el mejor creador ese tipo de objetos. Como sabemos, la clase que usa ms estrechamente estos objetos es FichaDePaciente, sin embargo tambin es parte del contrato crear un objeto de ese tipo, as que podemos realizar esa creacin en cadena, delegando la responsabilidad al mejor creador de FichaDePaciente, y que se lo podemos entregar de inmediato al CatalogoDePacientes (ya que l es quien necesitar utilizar esas instancias de aqu en adelante). Por ltimo, finalmente necesitamos obtener el experto de la informacin del detalle del paciente y es DetalleDeFicha, lo que nos permite mejorar la creacin de ese tipo de objetos delegndole toda esa informacin a su creador (FichaDePaciente) y permitiendo que la creacin se lleve a cabo en una sola responsabilidad encapsulada. El diagrama de colaboracin quedara as:
130
ILUSTRACIN 87. DIAGRAMA DE COLABORACIN PARA INGRESADETALLE
Notemos que en este caso particular, la existencia de la relacin con el catlogo no estaba definida en el contrato, pero la aplicacin de los patrones de diseo nos permiti descubrir esta relacin. Por otro lado tampoco aparece en forma explcita el cumplimiento de la postcondicin de asociar d a f, pero por la delegacin de la creacin quedan asociadas esas instancias. El siguiente contrato es:
Operacin: Responsabilidad: CO3. consultar(rut) Obtiene la informacin de la ficha del paciente a partir del rut ingresado. Tipo o Clase: Sistema Ref. Cruzadas: CU2, CU3, CU5 Notas: Excepciones: Si la ficha no existe, devuelve un valor nulo. Salidas: Precondiciones - Exista una instancia r de CatalogoDePacientes Postcondiciones: - Se haya encontrado una instancia p de DetalleDePaciente cuyo atributo rut sea igual al valor del parmetros rut. ILUSTRACIN 88. CONTRATO DE LA OPERACIN CONSULTAR
Para buscar el controlador, primero debemos consultarnos si se aplica el anterior. En este caso no lo es, porque no estamos en el registro de un paciente, pero tampoco estamos en algn CU particular, ya que esta operacin es transversal a los CU2, CU3 y CU5. A pesar de ello, como la naturaleza de la operacin tiene que ver con obtener la informacin de la ficha del paciente, podremos crear un nuevo controlador modular llamado FichaControlador, que permite realizar las operaciones bsicas de consulta o manipulacin de la ficha9. Por otro lado, como estamos buscando una ficha particular, debemos aplicar exactamente la misma idea de lo aplicado en el CO1. De esta manera, podemos cambiar nuestra primera realizacin para mejorar y aplicar este contrato en forma equivalente. As, las colaboraciones corregidas para aplicar esta operacin tambin seran:
Note que las operaciones anteriormente analizadas tambin tienen que ver con la ficha, por lo que una mejora sera juntarlas todas en este mismo controlador, quedando 3 operaciones (CO1, CO2 y CO3).
131
ILUSTRACIN 89. DIAGRAMA DE COLABORACIN PARA VALIDARRUT MODIFICADO
ILUSTRACIN 90. DIAGRAMA DE COLABORACIN PARA INGRESARDETALLE MODIFICADO
Por ltimo, la colaboracin del CO3 sera:
ILUSTRACIN 91. DIAGRAMA DE COLABORACIN PARA CONSULTAR
Como podemos ver, la naturaleza de la operacin es la misma, pero la respuesta que se espera es diferente del controlador. El siguiente contrato es:
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: ILUSTRACIN 92. CO4. registrarInformacion(objeto) Registra en la ficha del paciente la informacin entregada en forma de objeto. Sistema CU3, CU5 Objeto puede tomar valores de DetalleAnamnesis y DetalleProcedimiento - Exiasta una instancia d de DetalleDePaciente - Se haya asociado objeto a d. CONTRATO DE LA OPERACIN REGISTRARINFORMACION
132
Primero, esto tiene diferentes matices, ya que est siendo generalizada una operacin que no tendran el mismo controlador, as que seran vistas en forma diferente (como 2 contratos aparte). De esta forma, el primero ser recibido por ConsultaControlador, el cual manejar las operaciones realizadas por el especialista en la consulta mdica. La otra ser gestionada por ProcedimientoControlador, que tiene que ver ms con las operaciones realizadas durante un procedimiento mdico. Ahora si comenzamos a ver el primer caso como registrarAnamnesis() tendremos el detalle necesario para aplicar los patrones de creador y experto que nos lleve al primer diagrama de colaboracin:
ILUSTRACIN 93. DIAGRAMA DE COLABORACIN DE REGISTRARANAMNESIS
De una manera anloga podemos realizar la operacin respecto al registro del procedimiento quedando el diagrama de la siguiente forma:
ILUSTRACIN 94. DIAGRAMA DE COLABORACIN DE REGISTRARPROCEDIMIENTO
Lo relevante de este anlisis, es que como el detalle necesario es por cada una de las clases, es necesario que hayamos separados las operaciones para cada caso, ya que, tal como vimos en clase, se convertirn en los mtodos de cada una de las clases (y las clases destino son las mismas).
133
Por ltimo, veamos el ltimo contrato del dominio:

Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: ILUSTRACIN CO5. cerrarAtencion(especialista) Enva una notificacin al sistema de agenda mdica indicando el trmino de la atencin del especialista. Sistema CU7 Utiliza XML para construir la llamada al SAM. Un mensaje intersistemas para el SAM 95. CONTRATO DE LA OPERACIN CERRARATENCION
Como podemos ver, esta operacin tiene que ver con la consulta mdica (y de hecho es una operacin de secundaria, ya que es una notificacin). Sin embargo, este contrato no aporta informacin al sistema como tal, porque solo elabora un mensaje a un sistema externo, lo que no se ve reflejado en las postcondiciones. DIAGRAMA DE CLASES DE DISEO Una vez analizado por completo las operaciones del sistema, podemos plantear paso a paso el diagrama de clases de diseo. Veamos cmo va quedando: Con un simple paso por los diagramas de colaboracin, podemos identificar las siguientes clases:
ILUSTRACIN 96. IDENTIFICACIN DE CLASES DE DISEO Y ATRIBUTOS
En el diagrama, adems pusimos desde ya los atributos que vienen desde el diagrama de clases conceptuales, ya que a priori sabemos que esos valores se mantendrn para el diseo.
134
El siguiente paso es completar con la informacin de los tipos de datos de los atributos y sus visibilidades correctas:
ILUSTRACIN 97. DETALLE DE VISIBILIDAD Y TIPOS DE DATOS DE ATRIBUTOS
Es fcil detectar que la informacin almacenada es mayormente de texto, ya que todos los datos generados por los especialistas mdicos son de ese tipo. Siguiendo con las definiciones aprendidas en la tcnica de creacin del diagrama de clases de diseo, podemos obtener ahora los mtodos de cada una de las clases a partir de los diagramas de colaboracin dibujados en la seccin anterior. As, podemos asociar los siguientes mtodos encontrados a las siguientes clases: FichaControlador: validarRut, ingresarDetalle, consultar. ConsultaControlador: registrarAnamnesis. ProcedimientoControlador: registrarProcedimiento. CatalogoDePacientes: buscar, crearFichaDePaciente. FichaDePaciente: consultarRut, crear, crearAnamnesis, crearProcedimiento. DetalleDeFicha: getRut, crear. Anamnesis: crear. DetalleDeAnamnesis: crear 135
Procedimiento: crear DetalleDeProcedimiento: crear
De esta manera, el diagrama quedara de la siguiente forma detallado:
ILUSTRACIN 98. DESCRIPCIN DE LOS MTODOS DE LAS CLASES
10
El paso siguiente es incorporar las asociaciones de acuerdo a la cercana de las clases del diagrama. Esto es bastante rpido de identificar porque basta con responder cualquiera de las 3 situaciones indicadas anteriormente: A es un creador de objetos de tipo B A agrega objetos de tipo B A necesita mantener conocimiento de los objetos de tipo B
De esta manera, el diagrama que estamos completando pasara a ser de la siguiente forma:
10
Las clases fueron reorganizadas para alcanzar a ver mayor detalle en el documento.
136
ILUSTRACIN 99. DESCRIPCIN DE ASOCIACIONES ENTRE LAS CLASES
Como podemos ver incorporamos tambin el concepto de composicin en varias de esas asociaciones, por el hecho de ser creadores de otros objetos. Observemos por un momento la relacin entre Procedimiento DetalleDeProcedimiento y Anamnesis DetalleDeAnamnesis. Podemos notar una semejanza con la caja del supermercado, porque en este caso Procedimiento y Anamnesis estn jugando el papel de lnea de venta, por lo que es posible resumir esa sobrecarga de clases (ya que ambas hacen lo mismo) en una sola que permita almacenar ambos tipos de registros. Para hacer esto, y aprovechar de utilizar la generalizacin en el diagrama, incorporaremos la clase RegistroDeFicha (que reemplazar Procedimiento y Anamnesis como lnea de venta) y una clase DetalleDeRegistro que ser la superclase que incorporar ambos tipos de registros. Adems, si vemos la forma en que se comportan las operaciones de las clases, podemos notar que no existen dependencias, por lo que no debemos incorporar ms detalle y podemos mostrar finalmente el siguiente diagrama de clases de diseo como una primera versin de nuestro SEFP:
137
ILUSTRACIN 100. DIAGRAMA DE CLASES DE DISEO DEL SEFP
138
UNIDAD IV: INTRODUCCIN A LA IMPLEMENTACIN

Gracias a la metodologa UP planteada, la construccin del software se torna un poco ms sencilla, ya que con el diagrama de clases de diseo, ms las especificaciones que se encontraron en las realizaciones a travs de la visibilidad y los mensajes definidos, nos permiten al menos tener una estructura rpida de implementar. En este captulo veremos una tcnica utilizada principalmente por las herramientas CASE en el mbito para transformar estos modelos en cdigos de programas.
139
FUNDAMENTOS DE LA IMPLEMENTACIN DEL SOFTWARE

La implementacin del software es la parte en donde se concretan los diseos realizados y se codifica gran parte del sistema final que se est definiendo.
CODIFICACIN DE CALIDAD
Los especialistas deben perseguir la obtencin de programas de calidad. Para ello se establece una serie de factores que determinan la calidad de un programa: Correccin: Un programa es correcto si hace lo que debe hacer tal y como se estableci en el anlisis y diseo. Claridad: Es muy importante que el programa sea lo ms claro y legible posible, para facilitar as su desarrollo y posterior mantenimiento. Eficiencia: Se trata de que el programa, adems de realizar aquello para lo que fue creado (es decir, que sea correcto), lo haga gestionando de la mejor forma posible los recursos que utiliza. Portabilidad: Un programa es portable cuando tiene la capacidad de poder ejecutarse en una plataforma, ya sea hardware o software, diferente a aqulla en la que se elabor.
ESTNDARES DE CODIFICACIN
Los estndares de codificacin se refieren a un conjunto de reglas y lineamientos que se usan al escribir los cdigos fuentes de un software. El uso de un estndar particular ayuda a los programadores a leer y entender el cdigo evitando los errores de la mejor manera. Un buen estilo de programacin (o estndar) es difcil de definir ya que depende del lenguaje de programacin seleccionado, sin embargo existen algunos aspectos comunes a ellos que ayudan a tener un estndar definido: Apariencia del Cdigo: Los estndares apuntan a que el cdigo debe ser de fcil entendimiento humano. De esta forma se pueden utilizar algunas tcnicas bsicas como indentacin, alineamiento vertical, espaciado y tabuladores. Nombrado de Variables: Una buena seleccin de nombres de variables indica que ellas deben ser nombradas segn su funcin. La utilizacin de nombres deficientes de variables solo complican el entendimiento del cdigo fuente. Valores Booleanos en Estructuras de Decisin: Es mejor siempre evitar la utilizacin de condicionales para obtener un valor booleano. En su lugar, es mejor realizar operatoria de valores de verdad para calcular el resultado booleano. Bucles y Estructura de Control: El uso de estructuras de control para bucles tambin es parte de un buen estilo de programacin. 140
HERRAMIENTAS CASE
Las CASE-Tools o Herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, calculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. A pesar de que las CASE-Tools nacieron en los aos 70, actualmente siguen siendo una gran ayuda en el mbito de la ingeniera de software y sobretodo en etapas menos tcnicas como el anlisis y diseo.
MODELO DE IMPLEMENTACIN
El modelo de implementacin define el mapeo que debemos hacer del diseo de software realizado a travs de los artefactos del UP con la codificacin. De esta manera podemos definirlo en dos partes: Definicin de las Clases (a partir de los DCD) Definicin de los Mtodos (a partir de las colaboraciones)
A continuacin veremos algunos aspectos bsicos con los cuales debe trabajar el arquitecto antes de llegar a obtener un diseo completo.
CONCEPTOS BSICOS
A continuacin algunos conceptos importantes que son necesarios de entender para este modelo. CDIGO Podemos definir que:
EL CDIGO ES LA SINTAXIS DE LOS PROGRAMAS, EN UN LENGUAJE DE MQUINA PARTICULAR, Y QUE REPRESENTAN EL DISEO ESPECIFICADO.
Lo que estamos definiendo tan sencillamente es que utilizaremos cdigo para especificar la implementacin. En este caso, en lenguaje de programacin que usaremos para los ejemplos ser Java por su orientacin al objeto y pertinencia con la carrera.
141

En particular, en este modelo no utilizaremos algn artefacto UML en especfico, sin embargo definiremos como artefactos dos productos que utilizaremos en el curso: Diagrama de Clases de Implementacin: Diagrama complementario que especifica detalle tcnico en el diagrama de clases de diseo (como normalizacin de tipos de datos al lenguaje de programacin) e incorpora informacin de cdigo para las clases. Estructura de Clases: Estructura de programas que se obtiene de la transformacin del diagrama de clases de implementacin en el lenguaje de programacin seleccionado.

El proceso de desarrollo de ambos artefactos se reduce en realidad a una sola tcnica, sin embargo la especificaremos a continuacin de manera segmentada para un mejor entendimiento de ellos. DIAGRAMA DE CLASES DE IMPLEMENTACIN Tal como ya habamos mencionado, el artefacto cumbre de la fase de diseo es el que conocemos como Diagrama de Clases de Diseo (DCD), pero solo lo mencionamos. Ahora tenemos la oportunidad de justificarlo mostrando cmo el DCD se transforma en una estructura de clases. Veamos el DCD del Punto de Venta para que vayamos agregando las definiciones de las clases de implementacin:
ILUSTRACIN 101. DIAGRAMA DE CLASES DE DISEO DEL SPDV
142
Lo primero que debemos hacer es, entonces, adoptar el diagrama y convertir todos aquellos tipos de datos y definiciones funcionales para convertirlas en elementos del lenguaje de programacin seleccionado. Pensemos en Java, entonces el diagrama anterior quedara transformado a:
ILUSTRACIN 102. DIAGRAMA DE CLASES DE NORMALIZADO AL LENGUAJE JAVA
Ahora que ya lo tenemos normalizado, debemos saber de dnde vamos sacando los cdigos respectivos de cada clase. La regla es siempre comenzar desde la menos acoplada (ms especfica) a la ms acoplada. En el ejemplo, podemos definir el siguiente orden de acoplamiento: Producto Pago LneaDeVenta Catalogo Venta CajaControlador
Luego de saber el orden de implementacin, se debe comenzar poniendo los cdigos de las clases desde la definicin que ya se ha encontrado en el DCD, lo que llamaremos atributos y mtodos simples. De esta manera, la clase se va construyendo a partir directamente de la definicin que dice el DCD. Por ejemplo, tomemos LineaDeVenta para comenzar la definicin:
143
LineaDeVenta -cantidad: short +new(p: Producto, cant: short): LineaDeVenta -setProducto(p: Producto) -setCantidad(cant: short) +obtenerSubTotal(): double public class LineaDeVenta { private short cantidad; public LineaDeVenta(Producto p, short cant) { } private void setProducto(Producto p) { } private void setCantidad(short cant) { } public double obtenerSutotal() { } }
ILUSTRACIN 103. DEFINICIN DE CDIGO PARA LA CLASE LINEADEVENTA
Esto lo debemos hacer para todas las clases del DCD, de manera que tenemos una primera estructura bsica de la estructura de clases. Otro tipo de atributos que se derivan de los DCD son los conocidos como de referencia y que representan aquellos atributos que son definidos a raz de la relacin que tienen las clases. De esta manera, cada vez que veamos una asociacin en el diagrama de clases, entonces estaremos pensando que en la implementacin debemos referenciar la clase dependiente a travs de un atributo. Por ejemplo, en la relacin entre LineaDeVenta y Producto podemos obtener claramente un atributo de referencia. Este se ve en la clase Linea de Venta:
Producto -codigo: long -glosa: String -p -precio: double 1 +getCodigo(): long +getPrecio(): double 1 LineaDeVenta -cantidad: short +new(p: Producto, cant: short): LineaDeVenta -setProducto(p: Producto) -setCantidad(cant: short) +obtenerSubTotal(): double public class LineaDeVenta { /* ATRIBUTOS */ private short cantidad; private Producto p; // Atributo de Referencia /* OPERACIONES */ public LineaDeVenta(Producto p, short cant) { } private void setProducto(Producto p) { } private void setCantidad(short cant) { } public double obtenerSutotal() { } }
ILUSTRACIN 104. IDENTIFICACIN DEL ATRIBUTO DE REFERENCIA DE LINEADEVENTA
Para este caso lo estamos haciendo a partir de una composicin. En el caso del lenguaje Java, tanto la composicin como la agregacin se representan de la misma forma, sin embargo, cuando estemos utilizando lenguajes cuya representacin se torna diferente, entonces debemos preocuparnos de si hablamos de composicin y no de agregacin.
144
Otro tema importante es cuando hablamos del nombre del papel que se usa en el DCD. Algunos diagramas utilizan en el extremo dependido un atributo que indica el nombre de la relacin. De esta forma, ese papel debe ser usado como nombre del objeto de referencia. Otra consideracin importante cuando se agregan los atributos de referencia es cuando estamos hablando de los contenedores (como en el caso del ejemplo que son los objetos de tipo Producto sobre el Catalogo o las LineasDeVenta sobre la Venta). Cuando se trata de poner la multiplicidad en el cdigo nos vemos con la complicacin de que no existe forma directa en algunos lenguajes para hacerlo. De esta manera, lo que se hace tradicionalmente, por ejemplo en Java, es utilizar una clase intermediaria que relacione el contenedor con lo contenido de la forma adecuada. As, a pesar de que no aparece en el DCD esta clase, se hace directamente. Por ejemplo, para hacer la relacin entre Venta y LineaDeVenta, podemos agregar la clase Vector, la que en Java permite poner un grupo de objetos en un solo contenedor. De esta forma, la definicin quedara de la siguiente forma:
public class Venta { /* ATRIBUTOS */ private Date fecha; private Vector ldv; // Atributo de grupo private Pago p; /* OPERACIONES */ public Venta (Date fecha) { } private void setFecha(Date fecha) { } public void crearLDV(Producto p, short cant) { } public double obtenerTotal() { } public void crearPago(double monto, byte tipo) { } }
Venta -fecha: Date +new(fecha: Date): Venta -setFecha(fecha: Date) +crearLDV(p: Producto, cant: short) +obtenerTotal(): double +crearPago(monto: double, tipo: byte) 1
1..*
-ldv LineaDeVenta
-cantidad: short +new(p: Producto, cant: short): LineaDeVenta -setProducto(p: Producto) -setCantidad(cant: short) +obtenerSubTotal(): double
ILUSTRACIN 105. ESPECIFICANDO ATRIBUTOS DEL CONTENEDOR VENTA
En este ejemplo, podemos ver que qued puesto un objeto Vector llamado ldv que, conceptualmente, no es ms que un conjunto de objetos de LineaDeVenta agrupados en Venta. De esta manera, cada vez que se cree una nueva LineaDeVenta, tenemos que agregarlo al Vector, no solo referenciando la variable, sino que utilizando las operaciones de ste ltimo. Otro paso que a travs de esta tcnica es posible realizar es describir los mtodos que se encontraron como mensajes y responsabilidades en los diagramas de colaboracin. De esta manera, podemos escribir los cuerpos de los mtodos (al menos en parte) mirando estos diagramas. Veamos el ejemplo de la operacin agregarProducto de CajaControlador. Su diagrama de colaboracin (parte de l) sera:
145
ILUSTRACIN 106. COLABORACIN PARA AGREGARPRODUCTO EN LA VENTA ACTUAL
Ntese que los mensajes que salen de CajaControlador estn representando parte del cuerpo del mtodo agregarProducto de CajaControlador. Por lo tanto, si revisamos la secuencia y vamos agregando las llamadas respectivas a la definicin de la clase, tenemos:
public class CajaControlador { private Catalogo c; private Venta v; public void iniciarVenta() { } public void agregarProducto(long cod, short cant) { Producto p; p = c.buscar(cod); v.crearLDV(p, cant); } public void registrarPago(double monto, byte tipo) {} }
CajaControlador -c +iniciarVenta() +agregarProducto(cod: long, cant: short) +registrarPago(monto: double, tipo: byte) 1 1
Catalogo 1 +buscar(cod: long): Producto
0..*
-v
Venta -fecha: Date +new(fecha: Date): Venta -setFecha(fecha: Date) +crearLDV(p: Producto, cant: short) +obtenerTotal(): double +crearPago(monto: double, tipo: byte)
ILUSTRACIN 107. ESPECIFICACIN DEL CUERPO DE LA OPERACIN AGREGARPRODUCTO
Como se puede ver ac aparecen directamente los mtodos que ya definimos en cada clase y hasta el orden de llamada relativa por supuesto a la responsabilidad en cuestin. En este caso ingresarProducto queda aparentemente definido en su totalidad, por lo tanto no requiere agregar nada ms para que sea un procedimiento programado. Finalmente, con esta documentacin tendremos un gran diagrama de clases con comentarios que especifican cada clase de diseo como si fuera una fuente de informacin tcnica para la programacin.
146
ILUSTRACIN 108. DIAGRAMA DE CLASES DE IMPLEMENTACIN PARA EL SPDV
ESTRUCTURA DEL CDIGO Una vez de aplicados todos los pasos, ahora es importante escribir cada una de las clases. Las herramientas CASE nos ayudan en este proceso y la salida seran las clases formales, pero como ejercicio, en este caso, lo haremos a mano. La tcnica para escribir el cdigo es muy sencilla: basta recorrer el diagrama de clases de implementacin y comenzar a describir las clases con el detalle esperado. El resultado entonces de realizar este proceso completo para el caso del SPDV sera el siguiente: CAJACONTROLADOR
public class CajaControlador { private Catalogo c; private Venta v; public void iniciarVenta() { this.v = new Venta((Date) System.currentTimeMilis()); } public void agregarProducto(long cod, short cant) { Producto p; p = this.c.buscar(cod); this.v.crearLDV(p, cant); } public void registrarPago(double monto, byte tipo) { this.v.crearPago(monto, tipo); } }
147
VENTA
public class Venta { private Date fecha; private Vector ldv; private Pago p; public Venta (Date fecha) { this.setFecha(fecha); } private void setFecha(Date fecha) { this.fecha = fecha; } public void crearLDV(Producto p, short cant) { LineaDeVenta l = new LineaDeVenta(p, cant); this.ldv.addElement(l); } public double obtenerTotal() { double suma = 0.0; for(int i=0; i<this.ldv.size(); i++) { suma += this.ldv.elementAt(i).obtenerSubTotal(); } return suma; } public void crearPago(double monto, byte tipo) { this.p = new Pago(monto, tipo); } }
LINEADEVENTA
public class LineaDeVenta { private short cantidad; private Producto p; public LineaDeVenta(Producto p, short cant) { this.setProducto(p); this.setCantidad(cant); } private void setProducto(Producto p) { this.p = p; } private void setCantidad(short cant) { this.cantidad = cant; } public double obtenerSutotal() { return this.cantidad * this.p.getPrecio(); } }
PAGO
public clas Pago { private double monto; private byte tipo;
148
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana public Pago(double monto, byte tipo) { this.setMonto(monto); this.setTipo(tipo); } private void setMonto(double monto) { this.monto = monto; } private void setTipo(byte tipo) { this.tipo = tipo; } }
CATALOGO
public class Catalogo { private Vector cdp; public Producto buscar(long cod) { for(int i=0; i<this.cdp.size(); i++) { if (this.cdp.elementAt(i).getCodigo() == cod) return this.cdp.elementAt(i); } } }
PRODUCTO
public class Producto { private long codigo; private String glosa; private double precio; public long getCodigo() { return this.codigo; } public double getPrecio() { return this.precio; } }
Luego de esto, es importante que los programadores incorporen en cada uno de los mtodos el detalle y estructuras de control necesarias que permitan que el sistema opere de manera efectiva y correcta segn las especificaciones de requisitos realizadas al principio del curso.

Ahora completaremos la realizacin del ejemplo del sistema electrnico de fichas de pacientes, complementando lo que se refiere al modelo de implementacin del sistema.
En este modelo especificaremos solo la estructura de clases a partir del DCD y usando Java. DIAGRAMA DE CLASES DE IMPLEMENTACIN 149
Describiremos el diagrama de clases de implementacin, utilizando el DCD de la unidad anterior. Para ello entonces pasaremos por los pasos bsicos indicados en la tcnica de desarrollo del modelo respectivo. Primero, comencemos normalizando los tipos de datos al lenguaje elegido (Java). El diagrama de clases quedara algo parecido a lo siguiente:
ILUSTRACIN 109. DIAGRAMA DE CLASES DE DISEO CON TIPOS DE DATOS JAVA DEL SEFP
Luego de realizado esto, se van describiendo las clases a travs de anotaciones en el diagrama considerando no solo los atributos explcitos, sino que tambin operaciones complejas y atributos de asociacin. Para el caso de las asociaciones mltiples que existen en este diagrama, vamos a utilizar una estructura Vector de objetos para que vaya acumulando los objetos del tipo de destino sin necesidad de conocer el nmero de elementos que finalmente vamos a registrar. De esta manera, tendremos un diagram parecido a este:
150
ILUSTRACIN 110. DIAGRAMA DE CLASES DE IMPLEMENTACIN COMPLETO DEL SEFP
El siguiente paso (que aparece en la tcnica vista en este captulo) indica incorporar lgica de programacin en el diagrama, sin embargo, dada la complejidad de ste, vamos a optar por escribir el cdigo (estructura de clases) a partir de lo ya obtenido, y luego incorporar lgica programtica. ESTRUCTURA DE CLASES La estructura obtenida corresponde a las clases, con sus atributos y las firmas de todos los mtodos identificados. Sin embargo, vamos a aprovechar de incorporar lgica en los mtodos de las clases segn corresponda. A continuacin el listado de las clases desde las menos acopladas a las ms acopladas:
public class DetalleDeAnamnesis { private String datos_inspeccion; private String observaciones; private String indicaciones; private String otros; public DetalleDeAnamnesis(String inspeccion, String observaciones, String indicaciones, String otros) { this.setDatos_Inspeccion(inspeccion); this.setObservaciones(observaciones); this.setIndicaciones(indicaciones); this.setOtros(otros); } private void setDatos_Inspeccion(String inspeccion) { this.datos_inspeccion = inspeccion; } private void setObservaciones(String observaciones) { this.observaciones = observaciones; } private void setIndicaciones(String indicaciones) { this.indicaciones = indicaciones; }
151
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana private void setOtros(String otros) { this.otros = otros; } } public class DetalleDeProcedimiento { private String observaciones; private String resultados; private String diagnostico; public DetalleDeProcedimiento(String observaciones, String resultados, String diagnostico) { this.setObservaciones(observaciones); this.setResultados(resultados); this.setDiagnostico(diagnostico); } private void setObservaciones(String observaciones) { this.observaciones = observaciones; } private void setResultados(String resultados) { this.resultados = resultados; } private void setDiagnostico(String diagnostico) { this.diagnostico = diagnostico; } } public class DetalleDeFicha{ private int rut; private String nombre; private String direccion; private String fono; private String email; public DetalleDeFicha (int rut, String nombre, String direccion, String fono, String email) { this.setRut(rut); this.setNombre(nombre); this.setDireccion(direccion); this.setFono(fono); this.setEmail(email); } public int getRut() { return this.rut; } private void setRut(int rut) { this.rut = rut; } private void setNombre(String nombre) { this.nombre = nombre; } private void setDireccion(String direccion) { this.direccion = direccion; } private void setFono(String fono) { this.fono = fono; } private void setEmail(String email) { this.email = email; } }
152
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana public class Procedimiento { private DetalleDeProcedimiento detalle; public Procedimiento(String observaciones, String resultados, String diagnostico) { this.detalle = new DetalleDeProcedimiento(observaciones, resultados, diagnostico); } } public class Anamnesis { private DetalleDeAnamnesis detalle; public Anamnesis(String inspeccion, String observaciones, String indicaciones, String otros) { this.detalle = new DetalleDeAnamnesis(inspeccion, observaciones, indicaciones, otros); } } public class FichaDePaciente { private DetalleDeFicha detalle; private Vector procedimientos; private Vector anamnesis; public FichaDePaciente(int rut, String nombre, String direccion, String fono, String email) { this.detalle = new DetalleDePaciente(rut, nombre, direccion, fono, email); } public DetalleDePaciente consultarRut(int rut) { return this.detalle; } public void crearAnamnesis(String inspeccion, String observaciones, String indicaciones, String otros) { Anamnesis anam = new Anamnesis(inspeccion, observaciones, indicaciones, otros); this.anamnesis.addElement(anam); } public void crearProcedimiento(String observaciones, String resultados, String diagnostico) { Procedimiento proc = new Procedimiento(observaciones, resultados, diagnostico); this.procedimientos.addElement(proc); } } public class CatalogoDePacientes { private Vector fichas; public FichaDePaciente buscar(int rut) { for(int i=0; i<this.fichas.size(); i++) { if (this.fichas.elementAt(i).getRut() == rut) return this.fichas.elementAt(i); } } public void crearFichaDePaciente(int rut, String nombre, String direccion, String fono, String email) { FichaDePaciente ficha = new FichaDePaciente(rut, nombre, direccion, fono, email); this.fichas.addElement(ficha); } }
153
Anlisis y Diseo Orientado al Objeto Apuntes de Modelamiento de Sistemas usando UML y UP Carrera de Ingeniera en Computacin e Informtica Instituto Profesional La Araucana public class ConsultaControlador { private FichaDePaciente paciente; public void registrarAnamnesis(String inspeccion, String observaciones, String indicaciones, String otros) { this.paciente.crearAnamnesis(inspeccion, observaciones, indicaciones, otros); } } public class ProcedimientoControlador { private FichaDePaciente paciente; public void registrarProcedimiento(String observaciones, String restultados, String diagnostico) { this.paciente.crearProcedimiento(observaciones, resultados, diagnostico); } } public class FichaControlador { private CatalogoDePacientes fichas; public void validarRut(int rut) { FichaDePaciente f = this.fichas.buscar(rut); } public void ingresarDetalle(int rut, String nombre, String direccion, String fono, String email) { this.fichas.crearFichaDePaciente(rut, nombre, direccion, fono, email); } public void consultar(int rut) { FichaDePaciente f = this.fichas.buscar(rut); } }
154
ANEXOS
155
PLANTILLA DE DOCUMENTACIN DEL A/DOO

A continuacin se presenta una estructura para documentar el proceso de anlisis y desarrollo orientado al objeto planteado en este documento. Es importante recordar que esta documentacin se realizar para cada iteracin del proceso de desarrollo, por lo que es importante priorizar las funciones a abordar en cada una de ellas.
ESPECIFICACIN DE REQUISITOS
En esta seccin se describe la visin funcional del sistema a la luz de los requerimientos expresados por el cliente final. IDENTIFICACIN DEL SISTEMA El sistema se describe de la siguiente forma:
Nombre del Sistema: Panorama: Clientes: Metas:
ESPECIFICACIN DE FUNCIONES La especificacin funcional del sistema se detalla a travs de las siguientes funciones:
Detalles y Restricciones
Categora

En esta seccin se describen los casos de uso, su detalle y la relacin que tienen con las funciones determinadas en la seccin anterior. Es importante incorporar el detalle de cada iteracin priorizado de manera de mantener coherencia con lo que se realize a travs del proceso de desarrollo complete. ESPECIFICACIN DE CASOS DE USO CASOS DE USO DE ALTO NIVEL Los casos de uso encontrados en esta iteracin son los siguientes:
Es importante destacar que solo los CU principales sern expandidos a continuacin. 156
CASOS DE USO EXPANDIDOS El detalle de los casos de uso identificados es el siguiente:

Caso de Uso: Actores: Propsito: Resumen: Tipo: Ref. Cruzadas: Curso Normal
DIAGRAMA DE CASOS DE USO A continuacin se muestra grficamente la relacin de los actores con los casos de uso especificados. <INSERTAR DIAGRAMA>
GLOSARIO
En esta seccin se describen los conceptos ms importantes del dominio y que impactan en su entendimiento.
Trmino Definicin
MODELO DE DOMINIO
En esta seccin se describen los artefactos que muestran la visin de negocio y el contexto en el cual se desarrollar el sistema. DIAGRAMA DE ACTIVIDADES Los procesos se describen de la siguiente forma: <INSERTAR DIAGRAMAS POR PROCESO> DIAGRAMA DE CLASES CONCEPTUALES El dominio se observa en el siguiente diagram: <INSERTAR DIAGRAMA>
En esta seccin se describen los artefactos que describen el comportamiento del sistema.
157
DIAGRAMAS DE SECUENCIA Los casos de uso se describen en los siguientes diagramas de secuencia: <INSERTAR DIAGRAMAS POR CASO DE USO> CONTRATOS DE LAS OPERACIONES Las operaciones del sistema se describen a travs de los siguientes contraltos:
Operacin: Responsabilidad: Tipo o Clase: Ref. Cruzadas: Notas: Excepciones: Salidas: Precondiciones Postcondiciones: CO1. validarRut(rut)
DIAGRAMAS DE ESTADO Los cambios de estado de los objetos del sistema se describen en los siguientes diagramas: <INSERTAR DIAGRAMAS POR OBJETO>
En esta seccin se describen las decisiones de la arquitectura que afectan a la organizacin de los programas finales. DIAGRAMA DE COMPONENTES El diagrama que define la distribucin de componentes es el siguiente: <INSERTAR DIAGRAMA>
MODELO DE DISEO
En esta seccin se describe en detalle el diseo del sistema a partir de las operaciones de ste y completando con una vision tcnica de las clases de diseo. DIAGRAMAS DE COLABORACIN Las operaciones se realizan en el sistema de la siguiente forma: <INSERTAR DIAGRAMAS POR OPERACION DE SISTEMA> DIAGRAMA DE CLASES DE DISEO El diagrama de clases que define el sistema es el siguiente: <INSERTAR DIAGRAMA> 158
En esta seccin se describen las labores de preparacin de la codificacin. DIAGRAMA DE CLASES DE IMPLEMENTACIN El diagrama de clases normalizado y preparado para la codificacin es: <INSERTAR DIAGRAMA> ESTRUCTURA DE CLASES La estructura bsica de clases que se deriva del diseo es: <INSERTAR ESTRUCTURA DE CLASES>
159
GUA DE USO DE STARUML

Para complementar este apunte, presentamos una gua rpida de uso de StarUML, que es el software con el cual fueron desarrollados todos los modelos grficos que aqu se describen, incluyendo no solo la utilizacin formal, sino que tambin el uso de trucos que nos ayuden a producir modelos de acuerdo a las tcnicas y recomendaciones aqu planteadas. Adems, la idea central es permitir al alumno aprender a utilizar una herramienta CASE de acceso liberado (al menos hasta la creacin de este documento) tanto a nivel acadmico como en su desarrollo profesional.
INTRODUCCIN A LAS HERRAMIENTAS CASE

Las CASE-Tools o Herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, calculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. HISTORIA Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un producto que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem Statemente Analyzer). Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC. Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del software. OBJETIVOS Los objetivos que buscan resolver las herramientas CASE son:
160
Mejorar la productividad en el desarrollo y mantenimiento del software. Aumentar la calidad del software. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos. Mejorar la planificacin de un proyecto Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las pruebas de errores y la gestin del proyecto. Ayudar a la reutilizacin del software, portabilidad y estandarizacin de la documentacin Gestionar globalmente todas las fases de desarrollo de software con una misma herramienta. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.
CLASIFICACIN DE LAS HERRAMIENTAS Las herramientas CASE no tienen una sola clasificacin. De acuerdo a diferentes caractersticas, las herramientas pueden ser agrupadas por: Plataforma Fases del ciclo de vida que cubren Arquitectura de aplicaciones que producen Funcionalidades
Veamos las clasificaciones de cada una: PLATAFORMAS La clasificacin por plataforma indica sobre qu arquitectura fsica trabajan (sistema operativo, hardware, etc). En particular, la clasificacin tradicional al igual que cualquier lenguaje es la siguiente: Multiplataforma Windows Unix/Linux (y sus diferentes sabores) MacOS Otros
161
Tambin existen software compatibles entre plataformas, pero definitivamente depende un poco del fabricante y de la tecnologa que utilicen para hacer cada herramienta. FASES DEL CICLO DE VIDA DEL SOFTWARE Esta es la clasificacin ms habitual de las herramientas, y se ha definido en 3 niveles: Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y diseo de la aplicacin. Lower CASE (L-CASE), herramientas que semiautomatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de desarrollo rpido de aplicaciones11.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente entre s, ni con la anterior: Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde anlisis hasta implementacin. MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin.
ARQUITECTURAS PRODUCIDAS En esta clasificacin se han definido los siguientes tipos de arquitectura producida: Monoltica. Donde el software se estructura en grupos funcionales muy acoplados. Cliente-servidor. Donde el software reparte su carga de cmputo en dos partes independientes pero sin reparto claro de funciones. Arquitectura de Tres Capas. Especializacin de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentacin (interfaz de usuario), otra para el clculo (donde se encuentra modelado el
11
Ver http://es.wikipedia.org/wiki/Desarrollo_r%C3%A1pido_de_aplicaciones
162
negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relacin con la siguiente. Otras arquitecturas menos utilizadas incluyen la de pipeline, entre pares, en pizarra, orientada a servicios y mquinas virtuales. FUNCIONALIDADES De acuerdo a sus funcionalidades, las herramientas se pueden agrupar de la siguiente forma: Herramientas de generacin semiautomtica de cdigo. Editores UML. Herramientas de Refactorizacin de cdigo. Herramientas de mantenimiento como los sistemas de control de versiones.
UML CASE-TOOL: STARUML

FICHA TCNICA Nombre: StarUML Empresa: Ninguna (Proyecto Open Source) Versin Actual: 5.0 Tipo de Licencia: Open Source Costos: Ninguno Plataforma: Microsoft Windows Idiomas: Ingls Pgina Web: http://staruml.sourceforge.net/ DESCRIPCIN Es un proyecto Open Source, por lo que es de descarga gratuita. Su ltima versin liberada a la fecha de construccin de este apunte es la 5.0 y posee soporto para la notacin 2.0 de UML. Estn continuamente en recoleccin de contribuidores quienes son premiados utilizando sus nombres como valores aleatorios cuando se crean objetos. Cada proyecto puede ser utilizado con estndares de diferente naturaleza (estilo Rational, UML estndar, MDA, COM-Compatible, o personalizable). Adems, posee capacidad de generacin de cdigos en C, C++, C#, Java, Visual Basic, VB.Net, Delphi, JScript, VBScript, etc.
163
FUNCIONALIDADES A continuacin veremos las diferentes funcionalidades para trabajar con la herramienta. CREACIN DE UN PROYECTO Al momento de iniciar StarUML, el arquitecto debe crear un nuevo proyecto, el cual define el mbito de desarrollo de los modelos y artefactos que se desea realizar. StarUML organiza los proyectos (modelos-artefactos) de acuerdo un estilo que debe ser seleccionado al momento de ser creado. La idea central es que el estilo posee una organizacin de modelos o vistas que deben ser completadas con los artefactos de UML por el arquitecto.
ILUSTRACIN 111. VENTANA DE INICIO DE STARUML
Los estilos de modelamiento disponible en la versin 5.0 son: Aproximacin Estndar Aproximacin Rational Aproximacin de Componentes UML Aproximacin de Modelo 4+1 Aproximacin Personalizada
El estilo utilizado para el desarrollo de los artefactos presentados en este apunte fue Rational, ya que es el ms cercano al proceso de desarrollo personalizado que se utiliz, sin embargo, no se descarta crear una aproximacin especial adecuada para el curso en el futuro12. Adems, independientemente el tipo de aproximacin, StarUML no limita los artefactos a utilizar en cada estilo, sino que finalmente es el arquitecto quien tiene la labor de organizar de la mejor forma cada proyecto a desarrollar.
12
Este curso seguir siendo impartido y se pretende mejorar con el uso de StarUML.
164
Veamos en detalle cada aproximacin para entender las secciones siguientes:

APROXIMACIN ESTNDAR
La aproximacin estndar organiza el proyecto de acuerdo a 5 modelos: Modelo de Casos de Uso: El centro de este modelo es el Diagrama de Casos de Uso, el cual detalla el ambiente y la interaccin del sistema desde el punto de vista funcional a travs de la utilizacin del artefacto del mismo nombre. Modelo de Anlisis: El centro de este modelo es el Diagrama de Clases, en el cual se define una primera aproximacin de la estructura de clases de diseo del sistema. Modelo de Diseo: El centro de este modelo es el mismo Diagrama de Clases, sin embargo, la utilizacin es para refinar la informacin preparando la implementacin. Modelo de Implementacin: El centro de este modelo es el Diagrama de Componentes, en donde se pueden organizar las clases de diseo modularmente segn lo aprendido en este apunte. Modelo de Despliegue: El centro de este modelo es el Diagrama de Despliegue (no analizado en este apunte), en el cual se describen las componentes fsicas a travs de las cuales ser instalado el sistema en la organizacin del cliente final.
APROXIMACIN RATIONAL
La aproximacin Rational hace referencia al proceso de desarrollo creado por The Three Amigos13 y organiza el proyecto de acuerdo a 4 vistas: Vista de Casos de Uso: Esta vista pretende mostrar la descripcin funcional del proyecto guiado a travs de los Casos de Uso del sistema. Su centro es el Diagrama de Casos de Uso. Vista Lgica: Esta vista pretende mostrar la visin tanto de negocio como de comportamiento del sistema desde el punto de vista lgico (no fsico). Su centro es el Diagrama de Clases (conceptuales). Vista de Componentes: Esta vista pretende mostrar la visin fsica del sistema incluyendo componentes de software que deben ser implementados. Su centro es el Diagrama de Componentes. Vista de Despliegue: Esta vista pretende mostrar los artefactos de despliegue (instalacin) del sistema de acuerdo a las necesidades modulares y funcionales del problema. Su centro es el Diagrama de Despliegue.
APROXIMACIN DE COMPONENTES UML
La aproximacin de componentes UML est basada en la definicin original del lenguaje y organiza el proyecto de acuerdo a 2 mbitos:
13
The Three Amigos: Booch, Jacobson y Rumbaugh, autores tambin del lenguaje de modelamiento UML.
165
mbito de Requerimientos: En este mbito se desarrollan los modelos relacionados con el anlisis funcional del sistema. Incorpora por defecto los modelos de Conceptos del Negocio y Casos de Uso. mbito de Especificaciones: En este mbito se desarrollan los modelos relacionados con el anlisis y diseo del sistema como tal. Incorpora por defecto los modelos de Tipos del Negocio, Especificacin de Interfaz, Especificacin y Arquitectura de Componentes.
APROXIMACIN DE MODELO 4+1
La aproximacin de modelo-vista 4+114 est basada en arquitecturas de software de sistemas intensivos y organiza el proyecto de acuerdo a 5 mbitos o vistas: Escenarios: En este mbito se describen las secuencias de interaccin de objetos y procesos de los casos de uso que definen la arquitectura 4+1 (Diagramas de Casos de Uso). Vista Lgica: En este mbito se describen los diagramas que representan lgica del negocio y del sistema (Diagramas de Comunicacin, Clases Conceptuales y Secuencia). Vista de Desarrollo: En este mbito se describen los diagramas que representan la vista del programador y de administracin del software (Diagramas de Componentes y Paquetes). Vista de Procesos: En este mbito se describen los diagramas que representan los aspectos dinmicos del sistema, a nivel de procesos y comportamiento de ste (Diagramas de Actividades). Vista Fsica: En este mbito se describen los diagramas que representan la visin del ingeniero en sistemas sobre las capas fsicas y la comunicacin entre las componentes (Diagramas de Despliegue).
APROXIMACIN PERSONALIZADA
La aproximacin personalizada no define mbitos ni modelos, sino que un proyecto vaco dejando el trabajo de organizacin del proyecto al arquitecto. Es muy til cuando el arquitecto no se siente cmodo con ninguna de las otras aproximaciones disponibles. ANATOMA DE LA HERRAMIENTA StarUML posee diferentes regiones en donde se muestra informacin. Estas regiones son las siguientes:
14
Men Principal: Men de acciones del programa (File, Edit, Format, Model, View, Tools y Help). Botonera Principal: Acciones disponibles desde la botonera superio. Despliegue del Diagrama Actual: Espacio en donde se ve el diagrama seleccionado.
http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
166
Explorador del Modelo (Model Explorer): Espacio para ver la organizacin del proyecto a partir de la aproximacin seleccionada. Explorador de Diagramas (Diagram Explorer): Espacio para ver los diagramas del proyecto ordenados por tipo de diagrama. Propiedades (Properties): Espacio que muestra las propiedades del proyecto, modelo, diagrama o elemento seleccionado, dependiendo de su tipo. Documentacin (Documentation): Espacio estilo bloc de notas para hacer anotaciones del objeto seleccionado. Adjuntos (Attachments): Espacio que permite adjuntar archivos al objeto seleccionado. Barra de Herramientas (Toolbox): Botonera dinmica que muestra los elementos de la notacin del tipo de diagrama seleccionado. Salidas (Output): Espacio que muestra la bitcora de cambios que se van realizando durante la modificacin del proyecto.
La presentacin de la herramienta es la siguiente:
ILUSTRACIN 112. VENTANA PRINCIPAL DE STARUML
167
CREACIN DE DIAGRAMAS Para crear un diagrama, ste debe ser incorporado a algn mbito del proyecto. Para ello se debe seleccionar el mbito del proyecto, con el men Model o con el botn derecho, hacer clic en Add Diagram y seleccionar el tipo de diagrama a realizar.
ILUSTRACIN 113. AGREGANDO UN DIAGRAMA EN STARUML
El resultado de esta operacin ser que se agregar bajo el mbito el nuevo diagrama del tipo seleccionado y en el despliegue de la herramienta mostrar un lienzo en blanco para que se comience a trabajar en l. Tambin existe un cambio en la barra de herramientas (Toolbox), la cual cambia segn el tipo de diagrama seleccionado.
TIPOS DE DIAGRAMAS
Los diagramas bsicos que vienen con la versin 5.0 son los siguientes: Diagrama de Clases Diagrama de Casos de Uso Diagramas de Secuencia y Colaboracin (con roles y sin roles) Diagrama de Estados Diagrama de Actividades Diagrama de Componentes Diagrama de Despliegue Diagrama de Estructura Compuesta Diagrama de Robustez 168
GENERACIN DE CDIGO FUENTE Para poder generar cdigo fuente es importante incorporar al proyecto el lenguaje en el cual se desea generar el cdigo. Esto se realiza a travs del men Model > Profiles.
ILUSTRACIN 114. VENTANA ADMINISTRADORA DE PERFILES DE STARUML
Al lado izquierdo se encuentran los perfiles disponibles (C++, C# y EJB) y al lado derecho los que ya tiene incorporados el proyecto (Java y UML). Se debe incorporar cada perfil seleccionando su cono a la izquierda y usando el botn Include > quedaran automticamente incorporados. Cabe destacar que la generacin de cdigo se realiza a partir de las clases de diseo del sistema, por lo que es importante que se utilicen tipos de datos acordes al lenguaje en su definicin. Si ambos factores son cumplidos, se puede generar el cdigo en el lenguaje. Esto se realiza con el men Tools luego el lenguaje deseado y Generate Code, lo que abrir una ventana como la siguiente:
ILUSTRACIN 115. VENTANA DEL PASO 1 DE GENERACIN DE CDIGO DE STARUML
169
Es necesario seleccionar la vista, modelo o paquete del proyecto que contiene la definicin de las clases de diseo, y luego presionar Next >.
Luego se requiere seleccionar las clases o paquetes de clases que van a ser utilizadas para generar el cdigo. Como la definicin de las clases queda asociada al elemento, los atributos y operaciones de las clases tambin se ven amarradas a dicha definicin.
Adems, se debe seleccionar la carpeta en donde se desea guardar el cdigo y presionar la accin Next >.
170
Finalmente, es necesario fijar algunas opciones de generacin y estilo, finalizando el proceso con la accin Next >, lo que comenzar a generar el cdigo. Una vez iniciado el proceso de generacin, StarUML construir las clases .java de todos los elementos seleccionados en el paso 2. RECOMENDACIONES Y BUENAS PRCTICAS Para completar esa gua, se puede decir que: Es importante acomodar la aproximacin al modelo ms cmodo que tiene el arquitecto en cuestin. Lo ms probable sea que alguna de las aproximaciones sea suficiente, pero no necesariamente exacto, as que se deber ajustar dicho modelo al que ms le acomode siempre. StarUML no apoya el proceso de generacin de los diagramas, sino que solo los permite dibujar, lo que por supuesto es complejo para arquitectos poco experimentados. Por esta razn es necesario que el arquitecto conozca su propia metodologa antes de dibujar los diagramas. Tal como se expresa en este apunte, los diagramas no lo son todo. StarUML permite adjuntar archivos a los diferentes artefactos (por ejemplo, adjuntar los Casos de Uso en el diagrama de CU lo que es recomendable hacer) para descripciones o artefactos de tipo documento complementarios a los diagramas.
171
BIBLIOGRAFA
El material principal utilizado para estos apuntes es: UML y Patrones Craig Larman Editorial Pearson Education
Adems, como material complementario, existen otros textos interesantes de consulta: UML DeMistifyed: A Self Teaching Guide Paul Kimmel Editorial Mc Graw Hill El Proceso Unificado de Desarrollo de Software Ivar Jacobson, Grady Booch y James Rumbaugh Editorial Pearson Education UML gota a gota Martin Fowler Editorial Addison Wesley Ingeniera de Software Orientado a Objetos Bertrand Meyer Editorial Prentice Hall Utilizacin de UML en Ingeniera del Software con Objetos y Componentes Perdita Stevens, Rob Pooley Editorial Addison Wesley Ingeniera de Software Orientado a Objetos Bernd Bruegge Allen Dutoit Editorial Pearson Education The Unified Modeling Language Reference Manual Grady Booch, James Rumbaugh, Ivar Jacobson Editorial Addison Wesley Gua del Usuario del Lenguaje Unificado de Modelado UML Grady Booch, James Rumbaugh, Ivar Jacobson Editorial Addison Wesley Utilizacin de UML en Ingeniera de Software Perdita Stevens Editorial Prentice Hall Learning UML 2.0 Kim Hamilton, Russell Miles Editorial OReally Manual de UML Paul Kimmel Editorial Mc Graw Hill 172
Object Oriented Analysis and Design Mike ODocherty Editorial Prentice Hall Diseo Orientado a Objetos con UML Ral Alarcn Grupo Eidos Orientacin al Objeto: Conceptos, Terminologa y Lenguajes Miguel ngel Alarcn http://www.javahispano.org
173
TABLA DE ILUSTRACIONES
Ilustracin 1. Notacin del Modelo de Objetos de OMT .................................................................. 19 Ilustracin 2. Notacin del Modelo Dinmico................................................................................... 20 Ilustracin 3. Notacin del Modelo Funcional .................................................................................. 22 Ilustracin 4. Iteraciones del Proceso Unificado de Desarrollo ........................................................ 23 Ilustracin 5. Fases del Proceso Unificado de Desarrollo ................................................................. 25 Ilustracin 6. Carga de Trabajo por Disciplina en el Proceso Unificado de Desarrollo ..................... 27 Ilustracin 7. Metamodelos Aplicados a la Metodologa .................................................................. 30 Ilustracin 8. Plantilla de Especificacin de Funciones ..................................................................... 40 Ilustracin 9. Continuacin de la Plantilla de Especificacin de Funciones ...................................... 41 Ilustracin 10. Plantilla de Especificacin de Funciones para el SPDV.............................................. 42 Ilustracin 11. Tabla de Identificacin de Actores y Objetivos ......................................................... 46 Ilustracin 12. Documento de Especificacin de Caso de Uso de Alto Nivel .................................... 46 Ilustracin 13. Documento de Especificacin de Caso de Uso Expandida ........................................ 47 Ilustracin 14. Notacin de los Diagramas de Casos de Uso ............................................................ 48 Ilustracin 15. Plantilla de Especificacin de Casos de Uso y Glosario ............................................. 49 Ilustracin 16. Diagrama de Casos de Uso del SPDV ......................................................................... 50 Ilustracin 17. Documento del Glosario............................................................................................ 50 Ilustracin 18. Glosario para el Problema del SPDV ......................................................................... 51 Ilustracin 19.Notacin de los Diagramas de Actividades ................................................................ 54 Ilustracin 20. Diagrama de Casos de Uso del SPDV ......................................................................... 54 Ilustracin 21. Diagrama de Actividades para el SPDV ..................................................................... 55 Ilustracin 22.Tabla de Identificacin de Clases conceptuales segn Categoras ............................ 57 Ilustracin 23.Anlisis de Clases conceptuales por Frases Nominales.............................................. 58 Ilustracin 24.Ejemplo de Asociacin de Clases conceptuales ......................................................... 59 Ilustracin 25.Tabla de Clasificacin de Multiplicidad ...................................................................... 60
174
Ilustracin 26.Notacin de los Diagramas de Clases Conceptuales .................................................. 62 Ilustracin 27.Diagrama de Actividades del SPDV ............................................................................ 63 Ilustracin 28.Diagrama de Clases conceptuales del SPDV............................................................... 63 Ilustracin 29. Notacin de los Diagramas de Secuencia .................................................................. 66 Ilustracin 30. Mensaje de Creacin de Objeto ................................................................................ 66 Ilustracin 31. Mensaje de Autodelegacin ...................................................................................... 67 Ilustracin 32. Diagrama de Secuencia para el proceso de venta (sin pago) del TPDV. ................... 67 Ilustracin 33. Notacin para los Contratos de las Operaciones ...................................................... 68 Ilustracin 34. Diagrama de Secuencia con las operaciones de la Venta ......................................... 69 Ilustracin 35. Contrato para la Operacin ingresarProducto del TPDV .......................................... 70 Ilustracin 36. Notacin de los Diagramas de Estado ....................................................................... 72 Ilustracin 37. Diagrama de Estados para el objeto venta del TPDV ................................................ 73 Ilustracin 38. Especificacin de Funciones del SEFP ....................................................................... 76 Ilustracin 39. Tabla de Actores y Objetivos del SEFP ...................................................................... 76 Ilustracin 40. Especificacin de Casos de Uso de Alto Nivel para el SEFP ....................................... 77 Ilustracin 41. Especificacin de CU Expandidos para el caso SEFP ................................................. 79 Ilustracin 42. Diagrama de Casos de Uso del SEFP.......................................................................... 80 Ilustracin 43. Glosario para el SEFP ................................................................................................. 80 Ilustracin 44. Diagrama de Actividades del SEFP ............................................................................ 82 Ilustracin 45. Identificacin de Clases conceptuales segn Categoras para el SEFP...................... 83 Ilustracin 46. Frases Nominales para Escenarios del SEFP .............................................................. 84 Ilustracin 47. Diagrama de Clases conceptuales del SEFP............................................................... 85 Ilustracin 48. Diagrama de Secuencia para el CU1. Registrar Paciente .......................................... 86 Ilustracin 49. Diagrama de Secuencia para el CU2. Consultar Historial .......................................... 86 Ilustracin 50. Diagrama de Secuencia para el CU3. Registrar Anamnesis ....................................... 87 Ilustracin 51. Diagrama de Secuencia para CU5. Registrar Resultado de Procedimiento .............. 88 Ilustracin 52. Diagrama de Secuencia para el CU7. Actualizar Agenda Mdica.............................. 88 175
Ilustracin 53. Contratos de las Operaciones del SEFP ..................................................................... 90 Ilustracin 54. Diagrama de Estados para FichaDePaciente del SEFP............................................... 90 Ilustracin 55. Tabla de Factores de la Arquitectura ........................................................................ 96 Ilustracin 56. Tabla de Factores de la Arquitectura del SPDV ......................................................... 96 Ilustracin 57. Tabla de Decisiones de la Arquitectura ..................................................................... 97 Ilustracin 58. Notacin de los Diagramas de Componentes ........................................................... 97 Ilustracin 59. Diagrama de Componentes del SPDV ....................................................................... 98 Ilustracin 60. Notacin de los Diagramas de Colaboracin .......................................................... 102 Ilustracin 61. Diagrama de Colaboracin de Ingresar Producto para TPDV ................................. 103 Ilustracin 62. Contrato de Operacin ingresar Producto del SPDV............................................... 105 Ilustracin 63. Delegacin de Responsabilidad de Experto de Informacin................................... 106 Ilustracin 64. Delegacin de Responsabilidad de Creador de Instancias ...................................... 107 Ilustracin 65. Identificacin del Controlador de las Operaciones del Sistema.............................. 109 Ilustracin 66. Notacin para los Diagramas de Clases de Diseo.................................................. 117 Ilustracin 67. Asociacin a nivel de Clases Conceptuales ............................................................. 117 Ilustracin 68. Asociacin a nivel de Clases de Diseo ................................................................... 117 Ilustracin 69. Identificacin de las Clases de Diseo ..................................................................... 118 Ilustracin 70. Identificacin de un Mtodo a partir de una Colaboracin .................................... 118 Ilustracin 71. Identificacin de Mtodos de las Clases ................................................................. 119 Ilustracin 72. Agregando Asociaciones con Navegabilidad ........................................................... 120 Ilustracin 73. Diagrama de Clases de Diseo Parcial para el SPDV ............................................... 121 Ilustracin 74. Diagrama de Clases de Diseo Refinado para el SPDV ........................................... 122 Ilustracin 75. Representacin en la Codificacin de la Clase ........................................................ 123 Ilustracin 76. Generalizacin de los Tipos de Pago en el SPDV ..................................................... 123 Ilustracin 77. Agregacin de Productos en el SPDV ...................................................................... 124 Ilustracin 78. Composicin de Lneas de Venta en el SPDV .......................................................... 125 Ilustracin 79. Asociaciones entre los Componentes Funcionales ................................................. 126 176
Ilustracin 80. Capa Funcional del SEFP .......................................................................................... 126 Ilustracin 81. Capas de Interfaz y Funcional del SEFP ................................................................... 127 Ilustracin 82. Capas de Compoentes del SEFP .............................................................................. 127 Ilustracin 83. Diagrama de Clases conceptuales del SEFP............................................................. 128 Ilustracin 84. Contrato de la Operacin validarRut....................................................................... 129 Ilustracin 85. Diagrama de Colaboracin para validarRut ............................................................ 130 Ilustracin 86. Contrato de la Operacin ingresarDetalle............................................................... 130 Ilustracin 87. Diagrama de Colaboracin para ingresaDetalle ...................................................... 131 Ilustracin 88. Contrato de la Operacin consultar ........................................................................ 131 Ilustracin 89. Diagrama de Colaboracin para validarRut modificado ......................................... 132 Ilustracin 90. Diagrama de Colaboracin para ingresarDetalle Modificado ................................. 132 Ilustracin 91. Diagrama de Colaboracin para consultar .............................................................. 132 Ilustracin 92. Contrato de la Operacin registrarInformacion ...................................................... 132 Ilustracin 93. Diagrama de Colaboracin de registrarAnamnesis ................................................. 133 Ilustracin 94. Diagrama de Colaboracin de registrarProcedimiento ........................................... 133 Ilustracin 95. Contrato de la Operacin cerrarAtencion ............................................................... 134 Ilustracin 96. Identificacin de Clases de Diseo y Atributos ....................................................... 134 Ilustracin 97. Detalle de Visibilidad y Tipos de Datos de Atributos .............................................. 135 Ilustracin 98. Descripcin de los Mtodos de las Clases ............................................................... 136 Ilustracin 99. Descripcin de Asociaciones entre las clases .......................................................... 137 Ilustracin 100. Diagrama de Clases de Diseo del SEFP ................................................................ 138 Ilustracin 101. Diagrama de Clases de Diseo del SPDV ............................................................... 142 Ilustracin 102. Diagrama de Clases de Normalizado al Lenguaje Java .......................................... 143 Ilustracin 103. Definicin de Cdigo para la Clase LineaDeVenta................................................. 144 Ilustracin 104. Identificacin del Atributo de Referencia de LineaDeVenta ................................. 144 Ilustracin 105. Especificando Atributos del Contenedor Venta .................................................... 145 Ilustracin 106. Colaboracin para agregarProducto en la Venta Actual ....................................... 146 177
Ilustracin 107. Especificacin del Cuerpo de la Operacin agregarProducto ............................... 146 Ilustracin 108. Diagrama de Clases de Implementacin para el SPDV ......................................... 147 Ilustracin 109. Diagrama de Clases de Diseo con Tipos de Datos Java del SEFP ......................... 150 Ilustracin 110. Diagrama de Clases de Implementacin Completo del SEFP ................................ 151 Ilustracin 111. Ventana de Inicio de StarUML ............................................................................... 164 Ilustracin 112. Ventana Principal de StarUML .............................................................................. 167 Ilustracin 113. Agregando un Diagrama en StarUML .................................................................... 168 Ilustracin 114. Ventana Administradora de Perfiles de StarUML ................................................. 169 Ilustracin 115. Ventana del Paso 1 de Generacin de Cdigo de StarUML .................................. 169 Ilustracin 116. Ventana del Paso 2 de Generacin de Cdigo de StarUML .................................. 170 Ilustracin 117. Ventana del Paso 3 de Generacin de Cdigo de StarUML .................................. 170 Ilustracin 118. Ventana del Paso 4 de Generacin de Cdigo de StarUML .................................. 171
178

Andres Munoz - Analisis y Diseno Orientado Al Objeto

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Andres Munoz - Analisis y Diseno Orientado Al Objeto

Cargado por

Copyright:

Formatos disponibles

ANLISIS Y DISEO ORIENTADO AL OBJETO

UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETO .............. 9

METODOLOGAS DE MODELAMIENTO ......................................................................................... 16 La Tcnica de Modelado de Objetos (OMT).................................................................. 17

El Proceso Unificado (UP) de Desarrollo de Software .................................................. 22

UNIDAD II. EL ANLISIS ORIENTADO AL OBJETO ........................................ 37

MODELO DE CASOS DE USO ..................................................................................................... 42 Conceptos Bsicos ......................................................................................................... 43

Artefactos del Modelo .................................................................................................. 44 Proceso de Desarrollo del Modelo ................................................................................ 45

Artefactos del Modelo .................................................................................................. 53 Proceso de Desarrollo del Modelo ................................................................................ 53

MODELO DE COMPORTAMIENTO............................................................................................... 64 Conceptos Bsicos ......................................................................................................... 64

Artefactos del Modelo .................................................................................................. 65 Proceso de Desarrollo del Modelo ................................................................................ 65

Glosario ......................................................................................................................... 80 Modelo de Dominio ...................................................................................................... 81

Modelo de Comportamiento ........................................................................................ 85

UNIDAD III. EL DISEO ORIENTADO AL OBJETO ......................................... 91

Artefactos del Modelo .................................................................................................. 95 Proceso de Desarrollo del Modelo ................................................................................ 95

MODELO DE DISEO ............................................................................................................... 98 Conceptos Bsicos ......................................................................................................... 99

Modelo de Diseo ....................................................................................................... 128

UNIDAD IV: INTRODUCCIN A LA IMPLEMENTACIN.............................. 139

ANEXOS ................................................................................................... 155

Modelo de Casos de Uso ............................................................................................. 156

Glosario ....................................................................................................................... 157 Modelo de Dominio .................................................................................................... 157

Diagrama de Clases Conceptuales....................................................................................... 157

Modelo de Comportamiento ...................................................................................... 157

Modelo Arquitectnico ............................................................................................... 158

Modelo de Diseo ....................................................................................................... 158

Modelo de Implementacin ........................................................................................ 159

UML Case-Tool: StarUML ............................................................................................ 163

BIBLIOGRAFA ...................................................................................................................... 172 TABLA DE ILUSTRACIONES ...................................................................................................... 174

UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETO

FUNDAMENTOS DE LA ORIENTACIN AL OBJETO

LA TCNICA DE MODELADO DE OBJETOS (OMT) 1

Ver OMT en http://www.monografias.com/trabajos13/metomt/metomt.shtml

La Notacin del Modelo se puede describir en la siguiente cartilla:

ILUSTRACIN 1. NOTACIN DEL MODELO DE OBJETOS DE OMT

ILUSTRACIN 2. NOTACIN DEL MODELO DINMICO

Para la construccin del modelo, es necesario definir y realizar algunas actividades:

Describir las funciones. Identificar restricciones. Especificar criterios de optimizacin.

La notacin se puede resumir en la siguiente cartilla:

ILUSTRACIN 3. NOTACIN DEL MODELO FUNCIONAL

EL PROCESO UNIFICADO (UP) DE DESARROLLO DE SOFTWARE

El Producto va creciendo a medida que se va avanzando en el proyecto

ILUSTRACIN 4. ITERACIONES DEL PROCESO UNIFICADO DE DESARROLLO

La arquitectura sirve para: 24

Construccin Ciclo de Desarrollo

ILUSTRACIN 5. FASES DEL PROCESO UNIFICADO DE DESARROLLO

g) Gestin de Configuraciones y Cambios h) Gestin del Proyecto i) Entorno

ILUSTRACIN 6. CARGA DE TRABAJO POR DISCIPLINA EN EL PROCESO UNIFICADO DE DESARROLLO

EL LENGUAJE UNIFICADO DE MODELAMIENTO (UML)

LA NOTACIN ES LA SINTAXIS DEL LENGUAJE DE MODELADO.

VISIN GENERAL DE LOS METAMODELOS UML APLICADOS AL A/DOO

ILUSTRACIN 7. METAMODELOS APLICADOS A LA METODOLOGA

UNIDAD II. EL ANLISIS ORIENTADO AL OBJETO

FUNDAMENTOS DEL ANLISIS DE SOFTWARE

DOCUMENTADA SOBRE EL CONTENIDO, FORMA O FUNCIONALIDAD DE UN PRODUCTO O SERVICIO.

CARACTERSTICAS DE LOS REQUERIMIENTOS

CLASIFICACIN DE LOS REQUERIMIENTOS

TCNICA DE ESPECIFICACIN DE REQUISITOS

ILUSTRACIN 9. CONTINUACIN DE LA PLANTILLA DE ESPECIFICACIN DE FUNCIONES

Se estila que la tabla de funciones y de atributos se unan en una sola.

# Ref: Funcin: Descripcin: Categora: Atributo

# Ref: Funcin: Descripcin: Categora: Atributo Ingreso de Cdigos Recuperacin de la Venta

# Ref: Funcin: Descripcin:

MODELO DE CASOS DE USO

ARTEFACTOS DEL MODELO

PROCESO DE DESARROLLO DEL MODELO