ANALISIS Y DISEO ORIENTADO A OBJETOS

Durante los ltimos aos ha ido creciendo en forma considerable el anlisis y diseo orientado a objetos. Se han publicado numerosos libros y muchas organizaciones estn listas para implementar la prctica de esta nueva tecnologa. De un tiempo para ac ha venido presentndose un inters creciente en el campo del anlisis orientado a objetos (AOO) y el diseo orientado a objetos (DOO). Este inters es debido a que la programacin orientada a objetos (POO) se ha impuesto debido a sus enormes ventajas, pero las metodologas de anlisis y diseo tradicional no son aplicables. Con la publicacin de numerosos libros, los mtodos se han estabilizado y ahora las organizaciones pueden moverse con tranquilidad a esta nueva tecnologa. Hay que tener en claro la idea de que un buen anlisis puede acortar considerablemente la fase de desarrollo de programas, por ello, no se debe escatimar horas en organizar y estructurar la aplicacin en cuestin. Este mensaje no slo va dirigido para el analista - programador, sino tambin para algunos jefes de proyecto o gerente de empresas de desarrollo que se ponen literalmente nerviosos cuando ven que sus programadores estn sentados mirando el techo, "sin hacer nada", y por consiguiente, no produciendo. Este es un gran error, sin duda. Que el programador tenga en claro que lo que va hacer es bsico para que la aplicacin sea realmente atractiva y competitiva, sobre todo para el usuario, que es el objetivo principal. Vamos a ver en los prrafos siguientes en qu medida cambia el anlisis y diseo a objetos, respecto del tradicional. Primeramente, desglosemos las diferentes partes en que se divide cada uno de ellos:

Anlisis de Aplicacin Anlisis Funcional Anlisis Orientado a Objetos (AOO) Anlisis de Datos Anlisis de las Reglas del Negocio

Diseo de Aplicacin Esquema de Base de Datos Estructura de Clases (DOO) Interfaces del Usuario

Cuando enfocamos cualquier Aplicacin hecha en un entorno grfico, como un lenguaje visual, debemos tener presente como punto de referencia la interfaz del usuario que manejar los datos. El punto de vista del usuario es fundamental. Por tanto, cualquier suposicin pasar siempre el tamiz de la opinin del mismo. Ahora, no debemos caer tampoco en una dependencia absoluta e intentemos reconducir al usuario por donde ms nos interese. Es tarea del analista educar al usuario e informarle en un lenguaje sencillo de las posibilidades del sistema a implantar.

ANALISIS DE LA APLICACIN

Al llegar a nuestras manos la aplicacin, debemos tomar los datos bsicos que nos pueda darnos una idea del mismo. Objetivo: Dar un comprobante de compra al cliente. Cliente y Usuario: Comercio de ventas de ropa, dedicado principalmente a la venta de ropa de caballeros. Los usuarios sern los vendedores de tienda con ninguna experiencia en el manejo de programas informticos. Hardware y Software: Programa hecho en Power Builder en una mquina Pentium a 200 Mhz. sobre Windows 95. Primera Impresin: Parece un programa sencillo en su dinmica, pero difcil porque tiene que ser muy intuitivo para el usuario. Primer Paso: Hablar con el gerente de la tienda para hacerle ver la implantacin del sistema, que tal vez resulte con problemas al principio. En este punto estaramos en disposicin de recoger toda la informacin posible sobre los productos que comercializa la tienda y cmo trabaja normalmente, haciendo especial hincapi en el deseo de mejora, sin olvidar los posibles temores. Hagamos un pequeo esquema de lo que sera el proceso de mecanizacin, conseguido a travs del tradicional anlisis funcional, luego lo compararemos con al anlisis orientado a objetos

ANALISIS FUNCIONAL Una de las tcnica utilizadas normalmente para el anlisis funcional es el descrito por Allan Albrecht en 1979, que busca y especifica las distintas funciones de trabajo del usuario final. Segn esto, podemos desglosar nuestro ejemplo en los siguientes puntos:

El dependiente entrega el producto

El cliente paga el producto El dependiente hace un recibo

Estas seran las funciones que ataen al objetivo del programa. Veamos ahora cmo se debe matizarlas para un Anlisis Orientado a Objetos

ANALISIS ORIENTADO A OBJETOS(AOO) Como su propio nombre indica, lo que nos importa en este anlisis es distinguir cules sern los objetos que van a ser parte de la aplicacin. Tal vez sta es la tarea ms complicada del analista. En un primer momento, no debemos intentar enfocar con rigurosidad los objetos que nos puedan hacer falta en nuestra aplicacin. Lo que haremos, un Brain Storming (tormenta de ideas que depuremos con posterioridad). El primer paso que debemos hacer en un AOO ser explicar con mayor claridad los puntos funcionales anteriormente definidos. Utilizamos para ello los escenarios.

ANALISIS MEDIANTE ESCENARIOS Esta determinacin viene a analizar la realidad como si de una pelcula se tratase, viendo qu escenario se producen. Normalmente derivarn de los puntos funcionales. El dependiente toma el producto del almacn y lo entrega al cliente El dependiente comprueba el precio del producto, se lo dice al cliente y ste lo paga. El dependiente rellena un recibo con los datos del producto y lo entrega al cliente.

DETERMINACION DE OBJETOS La programacin orientada a objetos se basa en la definicin de clases. Una clase no es ms que una abstraccin de un objeto, o lo que es lo mismo, las caractersticas comunes de un grupo de objetos. Elegir qu conjunto de objetos son susceptibles de crear una abstraccin, o sea, una clase, ser la labor del analista. Por tanto buscaremos las clases que componen la aplicacin, que luego se convertir en objetos.

Una forma fcil de localizar objetos es encontrar en la aplicacin: Cosas

Lugares Personas o funciones Eventos Conceptos Organizaciones

Segn esto, en nuestro ejemplo podemos conseguir los siguiente objetos: Cosas Recib (ticket) Conceptos Productos Lugares Almacn Personas Dependiente, Clientes

Podramos, por lo tanto, a partir de aqu, crear unas clases candidatas, es decir que posiblemente sern las clases utilizadas en la aplicacin. Cuando definimos las clases tenemos que indicar cules van a ser los mtodos y sus propiedades, as como los trminos especficos de la programacin orientada a objetos. Para aquellos que no estn acostumbrados a esta terminologa lo podemos comparar con estos procedimientos y variables que deben contener un mdulo, donde podemos tomarnos la licencia de igualar clase con mdulo, procedimiento con mtodo y variable con propiedad.

El siguiente esquema podra ser vlido para la definicin de clases:

Clases Ticket

Propiedades Fecha Dependiente Importe Desglose Venta

Mtodos CogerCliente CogerDescripcinProducto CogerPrecioProducto CogerFechaHoy CogerDependiente ComprobarExisteProducto QuitarProductoAlmacen CrearTicket

Modelo Producto Color Talla Precio Marca Nombre Dependiente Direccin Telfono Ventas Antigedad

CreaProducto BorraProducto BuscaProducto

CrearDependiente EliminarDependiente BuscarDependiente

Comprobamos que no todas las clases previamente encontradas se convierten en clases reales. Por ejemplo, comprobamos un producto y almacn es realmente lo mismo y que en esta aplicacin importa poco quin es el cliente, ya que es una tienda y stos suelen ser ocasionales y no recurrentes.

ANALISIS DE DATOS Las tablas resultantes de agrupar los distintos datos de nuestro ejemplo seran: Productos Tickets Lnea de Tickets Dependientes

Despus de este anlisis, seguramente se habr dado cuenta el lector, que las clases puedan ser perfectamente base de datos y que las propiedades podran ser los campos. Por lo tanto, si hicisemos el anlisis de datos, ste debera coincidir con el Anlisis Orientado a Objetos, por lo que podramos sacar la conclusin de que ambos son similares Sin embargo, hay una diferencia que no est reflejada en esta comparacin: el AOO debe pensar tambin desde el punto de vista de la interfaz de usuario, en la que haremos referencia a la fase del diseo.

ANALISIS DE LAS REGLAS DEL NEGOCIO Es interesante que algunas aplicaciones tcnicas puedan documentar todos los algoritmos empleados por el usuario. Estas son las reglas del negocio. Una de las particularidades del trabajo del analista es que debe saber "un poco de todo" y el usuario siempre supone que nosotros slo sabemos ese poco, si no estamos al corriente de en qu consiste su trabajo. Es aqu donde debemos recopilar todas las peculiaridades del "modos operandi" del usuario. En nuestra aplicacin, por ejemplo, hablaremos de tallas grandes, medianas y pequeas ; de una codificacin de almacn, etc. En otros programas, tal vez tengamos que trabajar siempre en dlares en vez de soles , o siempre en centmetros, por lo que debemos tener unos algoritmos de conversin que ser la regla del negocio. Una idea interesante. Si stas son muchas, es crear una tabla con dichas reglas y acudir a ella cuando haga falta.