Você está na página 1de 11

Resumen En este documento abarcamos la aplicacin de la metodologa orientada a objetos en el diseo y en la implementacin del caso de posicionamiento 2D, ampliamente

resuelto mediante tcnicas de anlisis y diseo estructurado. Para ello, haremos uso del lenguaje Delphi, que es una extensin del Object Pascal, en la implementacin del sistema. En cuanto al diseo, propondremos un modelo de objetos que especificaremos mediante la herramienta Rational Rose. Por ltimo, comentaremos las ventajas e inconvenientes que conlleva la aplicacin de esta metodologa, orientando la explicacin a la elaboracin de sistemas no complejos, como es el caso que nos ocupa.

1.

Introduccin

La Ingeniera de la Programacin se define como la disciplina tecnolgica relacionada con la produccin sistemtica y el mantenimiento de productos software que son desarrollados y modificados en el tiempo previsto y dentro de los costes estimados. [1] Partiendo de esta definicin, definimos el concepto de mtodo en ingeniera de la programacin como un conjunto ordenado de pasos para obtener un resultado especfico, mientras que metodologa es el estudio de una familia de mtodos. A lo largo del documento vamos a hacer hincapi en el uso de la metodologa orientada a objetos de cara a la realizacin del diseo y la implementacin del caso de posicionamiento 2D enunciado en [1] (pgs. 193-194), mientras que el mtodo elegido para la elaboracin del sistema ser UML [2]. La metodologa orientada a objetos establece cmo abordar de un modo sistemtico la construccin de software, y est centrada en el anlisis y diseo, que son las fases del proceso de produccin de software donde se acomete el modelado del sistema. Adems, en estas fases describimos el problema y la solucin mediante una serie de modelos. Esta metodologa se puede concebir desde dos perspectivas dimensionales de distinta naturaleza: Tecnolgica: conceptos, notacin y herramientas usadas para el modelado Proceso: conjunto de pasos a realizar y resultados obtenidos en cada paso En cuanto a nuestra inclinacin por UML como mtodo para la especificacin del sistema, adems de por ser un mtodo estndar y ampliamente difundido en la comunidad cientfica, debemos tener en cuenta las siguientes caractersticas: es un mtodo totalmente apropiado en el contexto de desarrollo en el que estamos introducidos, ya que aporta facilidades para la reingeniera, nuevo software, prototipado o reutilizacin cubre el ciclo de vida en un grado muy amplio, abarcando el anlisis, diseo, implementacin, testing, etc. En los mtodos orientados a objetos la descomposicin del sistema se basa en los objetos o clases de objetos que se descubren en el dominio del problema.

1
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

Problema

Representacin del dominio del problema

Representacin del dominio de la solucin

Figura 1. Relacin entre las fases de anlisis y diseo.

Los objetivos del anlisis son los siguientes: Comprender el problema que el sistema software debe resolver Decidir lo que el sistema debe hacer Asegurar que el sistema satisface las necesidades de los usuarios y definir criterios de aceptacin Proporcionar una base para el desarrollo del sistema

En cuanto al diseo del sistema, distinguimos tres etapas, que son el diseo del sistema, el diseo de objetos y el diseo de la persistencia. En el diseo del sistema se produce una descomposicin del modelo de objetos en subsistemas, y una eleccin de la arquitectura para conectar dichos subsistemas. En el diseo de objetos, modelizamos el dominio de la solucin, lo cual incluye las clases del modelo de anlisis con, posiblemente, algunas modificaciones ms, tales como: Clases de la interface: relacionadas con la interface de usuario, representan la visin del usuario de las clases del modelo conceptual Clases de la aplicacin: son los objetos que comienzan la aplicacin y que controlan la secuenciacin de funciones, es decir, secuencian las llamadas a las funciones que estn dentro del diseo de objetos, eligiendo un orden de dichas funciones segn la accin a realizar Clases base/utilidades: son componentes que son independientes de la aplicacin considerada, como por ejemplo, colecciones, estructuras de datos predefinidas, etc.

En definitiva, las clases propias del diseo son aquellas que no tienen una correspondencia directa con las clases de anlisis, y entre ellas se encuentran el acceso a las bases de datos o las estructuras de datos, clases de la interface de usuario, etc.

2
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

Clases semnticas

Dominio del Problema

Clases Base/Utilidades

Clases de la Aplicacin

Clases de la Interface

Dominio de la solucin

Figura 2. Clases del problema y de la solucin

Por ltimo, comentar que en el diseo de la persistencia se trabajan detalles relativos a que el sistema tenga la capacidad necesaria para poder trabajar frente a una base de datos relacional, y para ello las clases se transforman en tablas y las relaciones entre clases se representan en el modelo relacional mediante claves ajenas.

2.

Diseo del Sistema

En este apartado vamos a especificar conceptualmente el sistema que estamos resolviendo, y para ello procederemos a la elaboracin de un diagrama de clases que capture y reproduzca fielmente el propsito del caso de posicionamiento 2D. El diagrama de clases refleja la estructura esttica del sistema, y es la herramienta principal de la mayor parte de los mtodos OO, ya que contiene clases relacionadas con otras clases, mediante asociaciones, ordenadas en jerarquas de agregacin y de generalizacin/especializacin. Cuando sea conveniente, se pueden utilizar tambin diagramas que contengan objetos, entendidos como una entidad de programacin con dos componentes; por una parte est el estado del objeto, que contiene la informacin que puede almacenar el objeto y que puede variar con respecto al tiempo, y por otra el comportamiento del objeto, que es el conjunto de acciones que puede realizar. Cada objeto posee una interfaz que contiene los servicios que ofrece al mundo exterior. Adems, en un lenguaje orientado a objetos, con ocultacin de informacin, no se puede acceder libremente a los campos de un objeto. La mayor parte de los sistemas orientados a objetos distinguen entre la descripcin de un objeto y el objeto en s. Como muchos objetos similares pueden ser descritos por una misma definicin o esquema general, a esta definicin o descripcin se le llama clase.

3
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

Una clase en el diagrama de clases es la descripcin de un grupo de objetos con estructura, comportamiento y relaciones similares. Realmente se trata de una abstraccin, ya que un objeto es una manifestacin concreta de esa abstraccin. A continuacin presentamos el diagrama de clases del sistema que estamos desarrollando:

En este diagrama estn expresadas las clases semnticas, es decir, las clases que definen las reglas del negocio que forman parte del proceso del sistema que estamos modelando. De igual forma, como se ha comentado antes, existen las clases de interface, de la aplicacin y las clases relativas a la persistencia de los datos, aunque para estos casos no hay estndares en cuanto al modelado propiamente dicho se refiere. Podemos observar la figura central de la clase Mapa, la cual tiene una perspectiva global del sistema y desde la cual, estableciendo contextos navegacionales, podemos navegar a cualquier informacin que se encuentre en el sistema, es decir, que desde la clase Mapa accedemos a cualquier otra clase que se halle presente en el sistema. En trminos ms cercanos a la jerga del problema que estamos considerando, podemos decir, siempre teniendo en cuenta el modelo que acabamos de presentar, que un mapa est formado por 400 celdas, las cuales forman una matriz 20x20. Adems, asociado a un mapa

4
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

tenemos una ruta. Por otra parte, tenemos rutas que estn asociadas a un mapa, dichas rutas pueden ser reales o estimadas. Cada ruta est formada por uno o ms avances, los cuales estn asociados a una posicin. Esta sera la descripcin general de lo que estamos modelando. Si echamos un vistazo a los atributos, obtenemos nueva informacin de la realidad que estamos modelando. De este modo, un mapa tiene asociada una ruta real y una ruta estimada; a una celda la caracterizamos por su marca (una celda marcada formar parte de la ruta, estos aspectos ya los veremos en implementacin); un avance est formado por una direccin y por unos pasos; y una posicin tiene una coordenada X y una coordenada Y. Hasta aqu tenemos toda la informacin del sistema que podemos extraer del modelo atendiendo a la parte esttica, pero si nos fijamos en las operaciones obtendremos informacin de la parte dinmica o de comportamiento del sistema. As, vemos que desde el mapa podemos validar la direccin y los pasos del avance, calcular la direccin estimada de la ruta estimada, unir los puntos que forman parte de la ruta real, unir los puntos que forman parte de la ruta estimada, o imprimir el mapa por pantalla. De una celda podemos saber si est marcada y cul es su marca, de una ruta real podemos calcular la nueva posicin despus de que se haya producido un avance, de una ruta estimada podemos calcular las nuevas coordenadas que se estiman, mientras que de un avance y de una posicin podemos obtener informacin sobre los atributos de la clase. Con la informacin esttica y de comportamiento del sistema, poco a poco vamos comprendiendo y acercndonos ms a la propia naturaleza del sistema de informacin que estamos modelando. Es decir, que en este punto ya hemos abarcado, dentro de la fase de diseo, el diseo del sistema y el diseo de objetos. Ahora slo nos queda por cumplimentar el diseo de la persistencia.

El diseo de la persistencia trata sobre la ubicacin de los datos que va a necesitar el sistema, tanto para consultas como para almacenamiento o manipulacin de los mismos. En estos casos, lo aconsejable y razonable es utilizar una base de datos relacional para almacenar dichos datos. Hemos escogido una tecnologa relacional para la base de datos por ser la que ms asentada se encuentra en el mercado en este momento, aunque tambin podramos haber hecho uso de una tecnologa objeto-relacional. Debido a la mnima complejidad del sistema que estamos desarrollando, la informacin a almacenar va a ser muy escasa, ya que en trminos prcticos slo necesitamos guardarnos la informacin relativa a las posiciones que forman parte de la ruta que posteriormente podremos visualizar. Si as lo queremos, tambin podemos almacenar la direccin y el nmero de pasos de cada avance vinculado a una posicin; de esta manera podremos extraer estadsticas de la ruta. Con todo lo comentado, podemos extraer como conclusin que necesitamos almacenar informacin de las posiciones y de los avances. Ello nos hara pensar en la elaboracin de dos tablas, una correspondiente a la clase Posicin y otra para la clase Avance, pero como la relacin entre ambas clases es una asociacin uno a uno, podemos fusionar toda esta

5
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

informacin en una nica tabla que conglomere los atributos de dichas clases. En pocas palabras, con slo una tabla garantizamos la persistencia del sistema de informacin. Por ltimo, slo queda comentar que como cada tupla que forma parte de la tabla debe estar perfectamente identificada, nos vemos en la obligacin de aadir un nuevo campo de la tupla, que es un cdigo identificador precisamente de esa tupla. De esta manera, podemos utilizar este campo como la clave primaria de la tabla que estamos diseando. De este modo, cada tupla de nuestra tabla Ruta est compuesta por los siguientes campos: identificador de avance direccin del avance nmero de pasos del avance coordenada X asociada al avance coordenada Y asociada al avance

Con todos estos detalles expuestos, ya slo nos queda por hablar de la implementacin del sistema. 3. Implementacin

De cara a la implementacin del sistema, hemos optado por el lenguaje Delphi, que no es ms que una extensin del Object Pascal. Por ello, Delphi soporta los conceptos fundamentales de la programacin orientada a objetos: clases, herencia y polimorfismo. Una clase es un tipo de datos definido por el usuario que contiene: un estado (representacin) y un comportamiento (operaciones). Las clases las utiliza el programador para introducir nuevos tipos de datos en el sistema. Un objeto es una instancia de una clase, o una variable del tipo de datos definido por la clase. Aqu ponemos como ejemplo la clase Avance: type TAvance = Class private direccion : string; // direccin del avance pasos : integer; // pasos del avance posicion : TPosicion; // posicin del mapa asociado al avance public constructor crear(d : string; p : integer); procedure crearPosicion(x, y : integer); function obtenerDireccion : string; function obtenerPasos : integer; function obtenerX : integer; // coordX de la posicin asociada function obtenerY : integer; // coordY de la posicin asociada procedure destruir; end;

6
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

Delphi utiliza un modelo de referencias para ubicar los objetos en memoria, es decir, las variables de tipo clase contienen una referencia a un objeto de tipo class. Los objetos se crean y se destruyen utilizando mtodos especiales llamados constructores y destructores. Ejemplo del constructor de la clase Avance: constructor TAvance.crear(d: string; p : integer); begin direccion := d; pasos := p; end;

Cuando un constructor se invoca se producen las siguientes acciones: reserva de espacio en el montculo (heap) para la instancia inicializacin de los atributos del objeto ejecucin del cdigo del constructor finalmente, se devuelve una referencia al nuevo objeto

Los destructores sirven para destruir objetos, producindose las siguientes acciones: se ejecuta el cdigo situado dentro del destructor se libera la memoria donde estaba almacenado el objeto

En cuanto a la herencia, Delphi dispone de herencia simple y se declara de forma explcita. En nuestra aplicacin utilizamos la herencia en las clases Real y Estimada, las cuales heredan de la clase Ruta. A continuacin ponemos un ejemplo de uso de la herencia, para ello presentamos la definicin de la clase Ruta y de la clase Real: TRuta = Class protected avance : array [0..MaxAvances] of TAvance; // avances de la ruta numAvances : integer; public constructor crear; virtual; function obtenerAvances : integer; function obtenerX(indice : integer) : integer;//coordX del avance i-esimo function obtenerY(indice : integer) : integer;//coordY del avance i-esimo procedure destruir; end;

TReal = Class (TRuta) public constructor crear; override;

7
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

procedure calcularNuevaPosicion(pos : TPosicion; dir : string; pasos, id integer); procedure obtenerRuta; end;

Delphi proporciona dos mecanismos de ocultacin de informacin: unidad de compilacin y clase. Unit Unidad; Interface { caractersticas pblicas de la unidad de compilacin} Implementation { implementacin de caractersticas pblicas + privadas } begin end.

Ello posibilita que podamos definir una clase del sistema por unidad, facilitando la modularidad y el encapsulamiento de la informacin. En cuanto a las interfaces de usuario, principalmente hemos diseado las siguientes: una inicial que le ofrece al usuario las distintas opciones presentes en el programa otra para la introduccin de la ruta otra para la visualizacin de la ruta y una ltima para la visualizacin de las estadsticas de la ruta Aqu tenemos una muestra de la interfaz inicial del sistema:

A continuacin mostramos un ejemplo de la interfaz de visualizacin de la ruta:

8
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

Por ltimo, mostramos la interfaz de estadsticas, que accede directamente a la base de datos:

4.

Conclusiones

9
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

La aplicacin de un lenguaje visual a la hora de implementar un sistema software dota al producto final de un entorno muy agradable y amigable, lo cual produce un impacto grande en el usuario que est utilizando el producto. Ahora bien, detrs de ese aspecto impecable que deja a las aplicaciones, un lenguaje visual est compuesto por jerarquas muy amplias de clases, ya que hay multitud de eventos, lo cual desemboca en un indeseado aumento de las transacciones debido a la complejidad de la interfaz de usuario. Es decir, que al realizar una programacin dirigida por eventos, la dificultad de implementacin aumenta, ya que no slo tenemos que prestar atencin a la lgica interna del producto y asegurarnos que implementa correctamente las reglas del negocio, si no que adems tenemos que prestar atencin a detalles como la interfaz de usuario y a accesos a bases de datos, en lo que se conoce como una arquitectura de 3 capas. En los sistemas de informacin de complejidad mnima, como es el caso que nos ocupa, se obtiene una mayor eficiencia utilizando un lenguaje de 3 generacin, el cual utiliza ficheros planos para acceder a la informacin y no hace uso de bases de datos; y adems no se implementa interfaz grfica alguna. Desde este punto de vista, usar un lenguaje de este tipo consume muchos menos recursos que el uso de un lenguaje visual. Adems, la aplicacin de la metodologa orientada a objetos en este sistema tampoco es la ptima en cuanto al consumo de memoria se refiere. Con orientacin a objetos tambin aumenta el consumo de recursos de una manera notable. Por poner un ejemplo, en nuestro sistema, slo con inicializar el mapa, se cargan en memoria 20x20 = 400 objetos de tipo celda, los cuales en una metodologa estructurada seran fcilmente implementables en una estructura sencilla, tal como puede ser el vector. Como conclusin final, resaltar la importancia de aplicar una metodologa orientada a objetos en el sentido de que dota de una mayor trazabilidad a las diferentes fases que forman parte del proceso de produccin de software, y nos acerca la ingeniera del software a una verdadera actividad de ingeniera. Pero tambin es cierto que el esfuerzo realizado a lo largo de todo el proceso es enorme, limitando de esta manera el tiempo de entrega del producto final, por lo que es conveniente aplicar dicho proceso a sistemas de informacin con una complejidad lo suficientemente elevada que nos permita justificar que el esfuerzo empleado no ha sido en vano.

5.

Referencias

[1] Molina A., Letelier P., Snchez P., Snchez J., Metodologa y Tecnologa de la Programacin, Servicio de Publicaciones UPV-97.498, 1997. [2] Rational Software Corporation, The Unified Modeling Language Notation Guide v.1.3. [http://www.rational.com], 2000. [3] www.dsic.upv.es/~uml. Un curso en espaol de Anlisis y Diseo Orientado a Objetos con UML. [4] Teixeira, F., Programacin en Delphi 4, Ed. Prentice-Hall, 1998.

10
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

11
Laboratorio de Sistemas de Informacin Facultad de Informtica Universidad Politcnica de Valencia

Você também pode gostar