Analisis y Diseño Orientado Al Objeto

ANLISIS Y DISEO ORIENTADO AL OBJETOA 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 CONTENIDOINTRODUCCIN ........................................................................................... 7RESUMEN EJECUTIVO ................................................................................................................ 8 AGREDECIMIENTOS ................................................................................................................... 8

UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETO .............. 9FUNDAMENTOS DE LA ORIENTACIN AL OBJETO ........................................................................... 10Objeto .................................................................................................................................... 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).................................................................. 17Fases de la Metodologa........................................................................................................ 17 Los Modelos, Diagramas y Su Notacin ................................................................................ 18

El Proceso Unificado (UP) de Desarrollo de Software .................................................. 22UP 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 .................................... 29Modelo 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 ........................................ 37FUNDAMENTOS DEL ANLISIS DE SOFTWARE ............................................................................... 38 Caractersticas de los Requerimientos .......................................................................... 38 Clasificacin de los Requerimientos ............................................................................. 38 ESPECIFICACIN DE REQUISITOS ................................................................................................ 39 Tcnica de Especificacin de Requisitos ....................................................................... 40Paso 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 ......................................................................................................... 43Actor ...................................................................................................................................... 43 Escenario ............................................................................................................................... 43 Caso de Uso ........................................................................................................................... 43 Responsabilidad .................................................................................................................... 44 Formalidad ............................................................................................................................ 44

Artefactos del Modelo .................................................................................................. 44 Proceso de Desarrollo del Modelo ................................................................................ 45Identificacin 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 ......................................................................................................... 51Dominio ................................................................................................................................. 51 Clases Conceptuales .............................................................................................................. 52 Proceso .................................................................................................................................. 52

Artefactos del Modelo .................................................................................................. 53 Proceso de Desarrollo del Modelo ................................................................................ 53Especificacin del Proceso de Negocio ................................................................................. 53 Identificacin de Clases Conceptuales .................................................................................. 55 Diagrama de Clases Conceptuales......................................................................................... 62

MODELO DE COMPORTAMIENTO............................................................................................... 64 Conceptos Bsicos ......................................................................................................... 64Evento.................................................................................................................................... 64 Contrato ................................................................................................................................ 64 3


Estado .................................................................................................................................... 64

Artefactos del Modelo .................................................................................................. 65 Proceso de Desarrollo del Modelo ................................................................................ 65Diagramas 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 ............................................................................................... 76Especificacin de Casos de Uso ............................................................................................. 76

Glosario ......................................................................................................................... 80 Modelo de Dominio ...................................................................................................... 81Diagrama de Actividades ....................................................................................................... 81 Diagrama de Clases Conceptuales......................................................................................... 82

Modelo de Comportamiento ........................................................................................ 85Diagramas de Secuencia........................................................................................................ 85 Contratos de las Operaciones ............................................................................................... 89 Diagramas de Estados ........................................................................................................... 90

UNIDAD III. EL DISEO ORIENTADO AL OBJETO ......................................... 91FUNDAMENTOS DEL DISEO DE SOFTWARE ................................................................................. 92 La Arquitectura del Software ........................................................................................ 92 MODELO ARQUITECTNICO ..................................................................................................... 94 Conceptos Bsicos ......................................................................................................... 94Refinamiento ......................................................................................................................... 94 Componente .......................................................................................................................... 95

Artefactos del Modelo .................................................................................................. 95 Proceso de Desarrollo del Modelo ................................................................................ 95Especificacin 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 ......................................................................................................... 99Realizacin de Caso de Uso ................................................................................................... 99 Responsabilidad .................................................................................................................... 99 Patrones de Diseo ............................................................................................................. 100

Artefactos del Modelo ................................................................................................ 101 Proceso de Desarrollo del Modelo .............................................................................. 101

4


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 ............................................................................................... 125Diagrama de Componentes ................................................................................................. 125

Modelo de Diseo ....................................................................................................... 128Diagramas de Colaboracin ................................................................................................ 129 Diagrama de Clases de Diseo ............................................................................................ 134

UNIDAD IV: INTRODUCCIN A LA IMPLEMENTACIN.............................. 139FUNDAMENTOS DE LA IMPLEMENTACIN DEL SOFTWARE ............................................................. 140 Codificacin de Calidad ............................................................................................... 140 Estndares de Codificacin ......................................................................................... 140 Herramientas CASE ..................................................................................................... 141 MODELO DE IMPLEMENTACIN............................................................................................... 141 Conceptos Bsicos ....................................................................................................... 141Cdigo.................................................................................................................................. 141

Artefactos del Modelo ................................................................................................ 142 Proceso de Desarrollo del Modelo .............................................................................. 142Diagrama de Clases de Implementacin ............................................................................. 142 Estructura del Cdigo .......................................................................................................... 147

CASO DE ESTUDIO: SISTEMA ELECTRNICO DE FICHAS DE PACIENTES (SEFP) ................................... 149 Modelo de Implementacin ........................................................................................ 149Diagrama de Clases de Implementacin ............................................................................. 149 Estructura de Clases ............................................................................................................ 151

ANEXOS ................................................................................................... 155PLANTILLA DE DOCUMENTACIN DEL A/DOO ........................................................................... 156 Especificacin de Requisitos ....................................................................................... 156Identificacin del Sistema ................................................................................................... 156 Especificacin de Funciones ................................................................................................ 156

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

Glosario ....................................................................................................................... 157 Modelo de Dominio .................................................................................................... 157Diagrama de Actividades ..................................................................................................... 157 5


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

Modelo de Comportamiento ...................................................................................... 157Diagramas de Secuencia...................................................................................................... 158 Contratos de las Operaciones ............................................................................................. 158 Diagramas de Estado ........................................................................................................... 158

Modelo Arquitectnico ............................................................................................... 158Diagrama de Componentes ................................................................................................. 158

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

Modelo de Implementacin ........................................................................................ 159Diagrama de Clases de Implementacin ............................................................................. 159 Estructura de Clases ............................................................................................................ 159

GUA DE USO DE STARUML ................................................................................................... 160 Introduccin a las Herramientas CASE ........................................................................ 160Historia ................................................................................................................................ 160 Objetivos ............................................................................................................................. 160 Clasificacin de las Herramientas........................................................................................ 161

UML Case-Tool: StarUML ............................................................................................ 163Ficha Tcnica ....................................................................................................................... 163 Descripcin .......................................................................................................................... 163 Funcionalidades................................................................................................................... 164 Recomendaciones y Buenas Prcticas ................................................................................ 171

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

6


INTRODUCCIN

7


RESUMEN EJECUTIVOEste 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 [email protected].

AGREDECIMIENTOSAgradezco 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.

8


UNIDAD I. LA BASE DEL MODELAMIENTO ORIENTADO AL OBJETOEl 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.

9


FUNDAMENTOS DE LA ORIENTACIN AL OBJETOPara 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 MODELAMIENTOPara 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) 1La 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.

1

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 OMTEL 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 DINMICOEL 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 FUNCIONALEL 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 SOFTWARETal 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/DOOSegn 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.

2

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 OBJETODurante 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 SOFTWARESegn 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 REQUERIMIENTOSLos 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 REQUERIMIENTOSExisten 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, lenguaje

Analisis y Diseño Orientado Al Objeto

Documents

Transcript of Analisis y Diseño Orientado Al Objeto