diseño orientado a objetos cap_1

GUA Anlisis y Diseo de Sistemas- Diagrama de Clases

Instructor: Ing. Leonardo Javier Bastidas Moreno

Servicio Nacional de Aprendizaje SENA Centro de Comercio y Servicios, Regional Cauca Popayn, Cauca (Colombia) 2012

Leonardo Javier Bastidas Moreno

Diseo Orientado a ObjetosEn el desarrollo de software, el diseo a menudo se considera el paso hecho antes programacin. Esto no es cierto, en realidad, el anlisis, programacin y diseo tienden a superponerse, combinar y entrelazan. En este captulo, aprender: Qu significa orientados a objetos La diferencia entre el diseo orientado a objetos y la programacin orientada a objetos Los principios bsicos del diseo orientado a objetos Lenguaje de Modelado Unificado Bsico y cuando no es malo

Qu significa orientados a objetos Todo el mundo sabe lo que es un objeto: un "algo" tangible que podemos sentir, s y manipular. Los primeros objetos con los que interactuamos suelen ser juguetes para bebs de madera bloques, figuras de plstico, las piezas de rompecabezas son comunes los primeros objetos. Los bebs aprenden rpidamente que ciertos objetos hacen ciertas cosas. Los tringulos encajan agujeros con forma de tringulo. Los redondos en las formas de Anillo , si en un juguete se pulsan los botones y palancas estos producen sonidos o movimientos. La definicin de un objeto en el desarrollo de software no es muy diferente. Los objetos no son tpicamente tangibles que se puede recoger, tienen sentido, o se sienten, pero son modelos que pueden hacer ciertas cosas y ciertas cosas se pueden hacer con ellos. Formalmente, un objeto es una coleccin de datos y comportamientos asociados. As que sabiendo lo que es un objeto, qu significa ser orientado a objetos? Orientada significa simplemente , "funcionalmente dirigidos a los objetos de modelado ". Es una de muchas tcnicas utilizadas para el modelado sistemas complejos mediante la descripcin de una coleccin de objetos que interactan a travs de sus datos y el comportamiento. Si usted ha ledo algo sobre los trminos: anlisis orientados a objetos, diseo orientado a objetos, anlisis y diseo orientado a objetos y programacin orientada a objetos. Todos estos son conceptos muy relacionados. De hecho, el anlisis, diseo y programacin son todas las etapas de desarrollo de software. Llamarlos orientado a objetos simplemente especifica qu es el estilo de desarrollo de software que se persigue.


Anlisis orientado a objetos (OOA) es el proceso de mirar un problema, el sistema, o tarea que alguien quiere convertir en una aplicacin y la identificacin de los objetos y las interacciones entre estos objetos. La etapa de anlisis tiene que ver con lo que hay por hacer. La salida de la etapa de anlisis es un conjunto de requisitos. Si tuviramos que completar la fase de anlisis en un solo paso, nos han hecho la tarea, como por ejemplo: "Yo Necesito un sitio web ", en un conjunto de requisitos, tales como: Los visitantes del sitio web Tienen que ser capaces de ( cursiva representa acciones, negrita representa objetos):

revisar nuestro historial aplicar para puestos de trabajo buscar, comparar y ordenar nuestros productos

Diseo Orientado a Objetos (OOD) es el proceso de convertir estos requisitos en una especificacin de implementacin. El diseador debe nombrar los objetos, definir los comportamientos, y formalmente especificar qu objetos puede activar comportamientos especficos en otros objetos. La etapa de diseo se trata acerca de cmo deben hacerse las cosas. La salida de la etapa de diseo es una especificacin de implementacin. Si tuviramos que completar la escenografa en un solo paso, nos han convertido a los requisitos en un conjunto de clases e interfaces que podran ser implementadas en (idealmente) cualquier lenguaje de programacin orientado a objetos. Programacin orientada a objetos (POO) es el proceso de convertir perfectamente lo que se define en el diseo del programa y que hace exactamente lo que el CEO (cliente) ha solicitado originalmente. S, claro! Sera maravilloso si el mundo se uniera en este ideal y podramos seguir estas etapas una a una, en perfecto estado, como todos los viejos libros de texto nos lo indique. Como es habitual, el mundo real es mucho ms oscuro. No importa cunto nos esforcemos para separar estas etapas, siempre vamos a encontrar cosas que requieren mayor anlisis ya que estamos diseando. Cundo estamos programando, encontramos caractersticas que deben aclararse en el diseo. en la el vertiginoso mundo moderno, la mayora del desarrollo que ocurre en un modelo de desarrollo iterativo. En el desarrollo iterativo, una pequea parte de la tarea se modela se disea, y se programa, entonces el programa es revisado y ampliado para mejorar cada funcin y as incluir nuevas funciones en una serie de ciclos cortos. Objetos y clases Por lo tanto, un objeto es una coleccin de datos con comportamientos asociados. Cmo le decimos a dos tipos de objetos que son separados? Manzanas y naranjas son ambos objetos, pero no se pueden comparar. Las manzanas y las


naranjas no se modelan con mucha frecuencia en la programacin de computadores, pero vamos a suponer que estamos haciendo una aplicacin de inventario para una granja de frutas! A modo de ejemplo, podemos suponer que las manzanas van en cajas y las naranjas en cestas. Ahora, tenemos cuatro tipos de objetos: manzanas, naranjas, cestos y cajas. En modelado orientado a objetos, el trmino utilizado para las estructurar objetos es la clase. As, en trminos tcnicos, ahora tenemos cuatro clases de objetos. Cul es la diferencia entre un objeto y una clase? Las Clases describen objetos. Ellos son como planos para la creacin de un objeto. Es posible que haya tres naranjas puestas en una mesa frente a usted. Cada naranja es un objeto distinto, pero los tres tienen los atributos y los comportamientos asociados a una clase: la clase general de naranjas. La relacin entre las cuatro clases de objetos en nuestro sistema de inventario puede describirse utilizando un lenguaje de modelado unificado (siempre referido como UML, porque estas tres siglas son ms fciles) diagrama de clases. Aqu est esta el primer diagrama de clase que como observamos es muy sencillo:

Este diagrama muestra simplemente que una naranja de alguna manera esta asociada con una cesta y que una manzana tambin est de alguna manera relacionada con una caja. La Asociacin es la forma ms bsica de relacionar dos clases . UML es muy popular entre los administradores y, en ocasiones menospreciada por programadores. La sintaxis de un diagrama UML es en general bastante obvia: usted no tiene que leer un tutorial (en su mayora) a entender lo que est pasando cuando vea un diagrama. UML es tambin bastante fcil de dibujar y bastante intuitivo. Despus de todo, muchas personas, cuando estn describiendo las clases y sus relaciones, se basarn naturalmente en cajas con lneas entre ellas. Tener un estndar basado en estos diagramas intuitivos hace que sea fcil para los programadores de comunicarse con los diseadores, gerentes, y entre s.


Sin embargo, algunos programadores piensan UML es una prdida de tiempo. Citando el desarrollo iterativo, argumentarn que las especificaciones formales hechas en UML son una fantasa y que los diagramas van a ser despedidos antes de que se implementen, y que el mantenimiento de esos diagramas formales slo ser un desperdicio de tiempo y no beneficia a nadie. Este es el caso de algunas organizaciones y otras tonteras en las culturas corporativas. Sin embargo, cada equipo de programacin formado por ms de una persona de vez en cuando tiene que sentarse y discutir a fondo los detalles de la parte del sistema que estn trabajando actualmente. UML es extremadamente til, en estas sesiones de lluvia de ideas, para comunicacin rpida y fcil. Incluso las organizaciones que se burlan de los diagramas de clases formal tienden a utilizar una versin informal de UML en sus reuniones de diseo, o las discusiones del equipo. Adems, la persona ms importante con la que tiene que comunicarse es con usted mismo. Todos pensamos que podemos recordar las decisiones de diseo que hemos hecho, pero siempre hay un "Por qu hice eso?" momentos escondidos en nuestro futuro. Si mantenemos los trozos de papel en que hicimos nuestro primer diagrama de cuando empezamos un proyecto, al final encontrar que son una referencia til. Este captulo, sin embargo, no pretende ser un tutorial en UML. Hay muchos de los que estn disponibles en Internet, as como numerosos libros disponibles sobre el tema. UML abarca mucho ms que los diagramas de clase y diagramas de objetos, sino que tambin tiene una sintaxis para los casos de uso, implementacin, cambios de estado y actividades. Vamos a estar tratando con una sintaxis comn para Diagramas de clase en este debate de diseo orientado a objetos. Usted encontrar que usted puede recoger la estructura con el ejemplo, y va a elegir inconscientemente la sintaxis UML en su propio equipo o sesiones personales de diseo. Nuestro diagrama inicial, si bien es correcto, no nos recuerda que las manzanas van en cajas o cuntas si en las cajas hay una sola manzana slo nos dice que las manzanas estn de alguna manera asociadas con cajas. La asociacin entre las clases es a menudo obvia y no necesita mayor explicacin, pero la opcin de aadir ms aclaraciones siempre est ah. La belleza de UML es que la mayora de las cosas son opcionales. Tan slo hay que especificar que cantidad de informacin en un diagrama tiene sentido para la situacin actual. En una sesin de pizarra rpida, podramos simplemente rpidamente dibujar lneas entre las cajas. En un documento formal que tiene que tener sentido en seis meses, podramos entrar en ms detalles. En el caso de las manzanas y cajas, podemos estar bastante seguros de que la asociacin es: "muchas manzanas van en una caja", pero slo para asegurarse de que nadie lo confunde con "una manzana estropea un caja", podemos mejorar el diagrama como se muestra:


Este diagrama nos dice que en las cestas van a ir naranjas con una pequea flecha que muestra lo que va en qu. Tambin nos dice la multiplicidad (nmero del objeto que se puede utilizar en la asociacin) a ambos lados de la relacin. Una cesta puede contener muchos (representado por un *) objetos de Naranja. Cualquier Naranja puede ir exactamente en la misma cesta. Puede ser fcil confundir qu lado de la relacin de la multiplicidad contina. La multiplicidad es el nmero de objetos de esa clase que pueden ser asociados con cualquier objeto en el otro extremo de la asociacin. Para la manzana va en asociacin con caja, leyendo de izquierda a derecha, muchos objetos de la clase de manzana puede ir en cualquier caja. Leyendo de derecha a izquierda, exactamente una caja puede estar asociada con una o muchas manzanas. Especificacin de atributos y comportamientos Ahora tenemos una idea bsica sobre la terminologa de orientado a objetos. Los objetos son instancias de clases que se pueden asociar entre s. Un objeto es una instancia objeto especfico con su propio conjunto de datos y comportamientos; una naranja sobre una mesa delante de nosotros se dice que es una instancia de la clase general de naranjas. Eso es suficiente, pero qu son estos datos y comportamientos que estn asociados a cada objeto? Datos que describen a los objetos Vamos a empezar con los datos. Los datos tpicamente representan las caractersticas individuales de un determinado objeto. Una clase de objetos se pueden definir las caractersticas especficas que son compartidos por todas las instancias de esa clase. Cada instancia puede entonces tener valores de datos diferentes para las caractersticas dadas. Por ejemplo, si tenemos tres naranjas en la mesa (si no nos hemos comido alguna) podran tener cada una un peso diferente. La clase naranja entonces podra tener un atributo peso. Todas las instancias de la clase de naranja tienen un atributo de peso, pero cada naranja podra tener un valor diferente para este peso. Los atributos no tienen por qu ser nicos sin embargo, cualquiera de las dos naranjas puede pesar la misma cantidad. Como un ejemplo ms realista, dos objetos que representan diferentes clientes pueden tener el mismo valor para un primer nombre del atributo.


Los atributos se refieren con frecuencia como propiedades. Algunos autores sugieren que los dos trminos tienen significados diferentes, por lo general que los atributos son configurables, mientras que propiedades son de slo lectura. En Python, el concepto de "slo lectura" no es realmente utilizado. La palabra clave propiedad tiene un significado especial en Python para un determinado tipo de atributo. En nuestra aplicacin de inventario de la fruta, el fruticultor puede querer saber de qu huerto el vino la naranja, cuando fue elegido, y lo cuanto pesa. Podran Tambin queremos hacer un seguimiento de dnde se almacena cada canasta. Las manzanas pueden tener un atributo de color y las cajas pueden venir en diferentes tamaos. Algunas de estas propiedades tambin pueden pertenecer a varias clases (puede querer saber cuando las manzanas se recogen, tambin), pero para este primer ejemplo, vamos a aadir algunas caractersticas diferentes para nuestro diagrama de clases:


Dependiendo de qu tan detallado nuestro diseo sea, tambin puede especificar el tipo de cada atributo. Los tipos de atributos son a menudo primitivas que son estndar para la mayora de lenguajes de programacin, como nmero entero (int), nmero de punto flotante (float), cadena de bytes, o booleano. Sin embargo, tambin pueden representar estructuras de datos como listas, rboles o grficos, o, sobre todo, a otras clases. Esta es un rea en la etapa de diseo se puede solapar con la fase de programacin. Las primitivas o varios objetos disponibles en un lenguaje de programacin pueden ser algo diferente de lo que est disponible en otros lenguajes. Por lo general, no es necesario que nos preocupemos por esto en la etapa de diseo, esto es inherente a la fase de implementacin estos detalles son elegidos durante la fase de programacin. Use nombres genricos le saldr todo mejor. Si nuestro diseo requiere de un tipo de contenedor de la lista, los programadores de Java pueden elegir usar una LinkedList ArrayList o cuando sta se aplique, mientras que los programadores de Python (nosotros!) Puede elegir entre la lista incorporada y una tupla. En nuestro ejemplo el cultivo de frutas, hasta ahora, nuestros atributos son todos primitivas bsicas. hay atributos implcitos que podemos hacer explcito: las asociaciones. Para una naranja dada, podramos tener un atributo que contiene la canasta donde est la naranja. Alternativamente, una cesta podra contener una lista de las naranjas que contiene. el prximo diagrama agrega estos atributos, tambin incluye descripciones con las propiedades actuales:

Los comportamientos son acciones Ahora sabemos qu son los datos, pero Que son los comportamientos? Los comportamientos son acciones que pueden ocurrir en un objeto. Los comportamientos que se pueden realizar en una clase especfica de objetos se


denominan mtodos. A nivel de programacin, los mtodos son como las funciones en la programacin estructurada, pero mgicamente tienen acceso a todos los datos asociados con ese objeto. Al igual que las funciones, los mtodos tambin pueden aceptar parmetros y los valores de retorno. Los parmetros de un mtodo son una lista de objetos que deben transferirse al mtodo que se est llamando. Estos objetos son utilizados por el mtodo para realizar cualquier tarea que est destinado a hacer. Los valores de retorno son el resultado de esa tarea. He aqu un ejemplo concreto: si nuestros objetos son nmeros, la clase nmero puede tener un mtodo adicionar que acepta un segundo nmero como parmetro. El mtodo adicionar adiciona el objeto primer nmero del devolver la suma cuando el segundo nmero se le haya pasado. Dado un objeto y el nombre del mtodo, un objeto puede llamar o invocar el mtodo en el objeto de destino. La invocacin de un mtodo, a nivel de programacin, es el proceso tomar el mtodo para ejecutarse pasndole los parmetros necesarios como argumentos. Hemos extendido el ejemplo bsico "comparar manzanas y naranjas" en la aplicacin. Vamos a extenderlo un poco ms all y ver si este deja de funcionar. Una de las acciones que se pueden asociar con las naranjas es la accin de seleccionarla. Si pensamos en la ejecucin de seleccionar pondras colocar la naranja de una cesta, actualizando el atributo naranja en la cesta y aadiendo la naranja en la lista de naranjas de la Cesta. As que para seleccionar la naranja se tiene que saber si existen en la cesta y cuantas naranjas hay. Hacemos esto dando usando el mtodo de seleccinar con un parmetro cesta. Por otra parte el fruticultor tambin vende jugos, podemos aadir un mtodo de compresin de naranja. Cuando se aprietan se podra devolver la cantidad de jugo recuperado, al mismo tiempo que la eliminacin de la naranja dentro de la cesta Cesta puede tener una accin de venta. Cuando se vende una cesta, nuestro sistema de inventario puede actualizar algunos datos sobre los objetos que an no se especifican para clculos de contabilidad y el beneficio. Por otra parte, nuestras cestas de naranjas puede estar daadas antes de que podamos venderlas, por lo que aadiremos un mtodo de descarte. Vamos a aadir estos mtodos a nuestro diagrama:


Adicionar modelos y mtodos a los objetos individuales nos permite crear un sistema donde los objetos interacten. Cada objeto en el sistema es un miembro de una clase determinada. Estas clases especifican qu tipo de datos debe tener el objeto y qu mtodos definen su comportamiento. Los datos de cada objeto puede estar en un estado diferente a los de otros objetos de la misma clase, y cada objeto puede reaccionar a las llamadas del mtodo de forma diferente debido a la diferencias en el estado. En el anlisis orientado a objetos y el diseo tiene que ver con averiguar lo que esos objetos son y cmo deben interactuar. En la siguiente seccin se describen los principios que se pueden utilizar para hacer esas interacciones tan simple e intuitiva como sea posible. Ocultando Detalles y Creando Interfaces Publicas El propsito fundamental de modelar un objeto en diseo orientado a objetos es determinar cul es la interfaz pblica de ese objeto. La interfaz es la coleccin de atributos y mtodos que otros objetos pueden utilizar para interactuar con ese objeto. En el mundo real un ejemplo comn es la televisin. Nuestra interfaz de la televisin es el control remoto. Cada botn en el mando a distancia representa un mtodo que se puede llamar al objeto televisin. Cuando nosotros usamos el objeto televisor, se accede a estos mtodos, no sabe ni le importa si el televisor est recibiendo la seal proveniente de una antena, una conexin por cable o una antena parablica. No nos importa que las seales electrnicas se estn enviando para ajustar el volumen, o si ese volumen se est enviando a los altavoces o un conjunto de auriculares. Si abrimos el televisor para acceder y ver cmo trabaja internamente, por ejemplo, ver como se producen los pixeles dentro de la pantalla o para dividir la seal de salida a los dos altavoces externos y un par de auriculares, se anular la garanta.


Este proceso de ocultar la implementacin, o detalles funcionales, de un objeto es apropiadamente llamado ocultamiento de informacin. Tambin se refiere a veces como la encapsulacin, pero en realidad la encapsulacin abarca ms. Los datos encapsulados no estn necesariamente ocultos. La encapsulacin es, literalmente, la creacin de una cpsula, por lo que pensar en crear una cpsula del tiempo. Si usted pone un montn de informacin en una cpsula del tiempo, bloquear y enterrarlo, es a la vez encapsulado y la informacin oculta. Por otro lado, si la cpsula del tiempo no ha sido enterrada y se desbloquea o est hecha de plstico transparente, los elementos dentro de ella todava estn encapsulados, pero no hay ninguna ocultacin de informacin. La distincin entre la encapsulacin y ocultacin de informacin es en gran medida irrelevante, sobre todo a nivel de diseo. Muchas referencias prcticas utilizan los trminos indistintamente. Como programadores de Python, que en realidad no tiene o necesita cierto ocultamiento de informacin, (vamos a discutir las razones de esto en el captulo 2) La definicin global para la encapsulacin es adecuada. La interfaz pblica, sin embargo, es muy importante. Se necesita ser cuidadosamente en el diseo, ya que es difcil de cambiar en el futuro. Cambiar la interfaz no romper los llamados de objetos cliente. Podemos cambiar el funcionamiento interno todos los que nos gusta, por ejemplo, para que sea ms eficiente, o para acceder a datos a travs de la red, as como a nivel local, y los objetos de cliente todava ser capaz de hablar con l, sin modificar, utilizando la interfaz pblica. Por otro lado, si se cambia la interfaz, mediante el cambio de nombres de atributo que den acceso pblico o alterando el orden o tipos de argumentos que un mtodo puede aceptar, todos los objetos de cliente tambin tendr que ser modificado. Recuerde, los objetos de un programa representan objetos reales, pero no son objetos reales. Son modelos. Uno de los grandes dones de modelado es la capacidad de pasar por alto detalles que no vienen al caso. Un modelo de automvil puede parecer un verdadero Thunderbird 1956 en el exterior, pero no se puede ver como se enciende el motor o como empieza a girar el eje de transmisin, ya que estos datos son demasiado complejos e irrelevantes para la concepcin del nuevo modelo. El modelo es una abstraccin de un concepto real. La abstraccin es otra palabra de moda orientada a objetos que enlaza con la encapsulacin y la ocultacin de informacin. En pocas palabras, la abstraccin significa tratar con el nivel de detalle que es ms apropiado para una tarea dada. Es el proceso de extraccin de una interfaz pblica de los detalles internos. El conductor de un coche tiene que interactuar con la direccin, acelerador y frenos. El funcionamiento del motor, la marcha, y el subsistema de freno no tienen importancia para el conductor. Un mecnico, las acciones que realizara estn en otro nivel diferente de abstraccin, afinar el motor y revisar la caja de cambios. He aqu un ejemplo de dos niveles de abstraccin para un automvil:


Ahora tenemos nuevos trminos que se refieren a conceptos similares. Para condensar toda esta jerga en una sola frase, diramos que, la abstraccin es el proceso de encapsulacin de informacin con diferentes interfaces pblicas y privadas. Las interfaces privadas pueden ser objeto de ocultacin de informacin.

Lo importante es traer de todas estas definiciones es hacer que nuestros modelos comprensible para los dems objetos que tienen que interactuar con ellos. esto significa prestar especial atencin a los pequeos detalles. Asegurar que los mtodos y las propiedades tienen nombres sensibles. Al analizar un sistema, los objetos suelen ser representados por los sustantivos en el problema original, mientras que los mtodos son normalmente los verbos. Atributos a menudo pueden ser recogidos como adjetivos, aunque si el atributo se refiere a otro objeto que forma parte del objeto actual, todava ser probablemente ser un sustantivo. Nombre clases, atributos y mtodos en consecuencia. No trate de objetos de modelo o acciones que pueden ser tiles en el futuro. Se modela exactamente las tareas que el sistema necesita para llevar a cabo el diseo y naturalmente gravitan hacia uno que tenga un nivel adecuado de abstraccin. Esto no quiere decir que no debemos pensar en las posibles modificaciones de diseo en el futuro. Nuestros diseos deben ser de composicin abierta para que las futuras necesidades puedan ser satisfechas. Sin embargo, cuando se hace la abstraccin interfaces, se intenta modelar exactamente lo que necesita ser modelada y nada ms. Composicin y herencia Hasta el momento, hemos aprendido a disear sistemas como un conjunto de objetos que interactan, donde cada interaccin se vieron los objetos involucrados en un nivel apropiado de abstraccin. Pero no sabemos an cmo crear esos niveles de abstraccin. Hay una variedad de maneras de hacer esto, Pero la mayora, incluso los patrones de diseo se basan en dos principios bsicos conocidos como la composicin y la herencia.


La composicin es la accin de recoger varios objetos juntos para componer un nuevo objeto. La composicin es generalmente una buena opcin cuando un objeto es parte de otro objeto. Ya hemos visto un primer indicio de la composicin en el ejemplo mecnico. Un automvil est compuesto de un motor, transmisin, motor de arranque, faros y parabrisas, entre muchas otras partes. El motor, a su vez, se compone de pistones, un cigeal, y las vlvulas. En este ejemplo, la composicin es una buena manera de proporcionar niveles de abstraccin. El objeto automvil puede proporcionar la interfaz requerida por un conductor, mientras que tambin proporciona acceso a sus componentes internos, que ofrece un mayor nivel de abstraccin adecuado para un mecnico. Esos componentes pueden, por supuesto, ser subdivididos si el mecnico necesita ms informacin para diagnosticar un problema o ajustar el motor. Este es un ejemplo comn de composicin, pero no aporta mucho cuando se trata de disear sistemas informticos. Los objetos fsicos son fciles de romper en objetos componentes. La gente ha estado haciendo por lo menos desde los antiguos griegos originalmente postulado que los tomos eran la unidad ms pequea de la materia (que, por supuesto, no tenan acceso a los aceleradores de partculas). Los sistemas informticos son generalmente menos complicado que los objetos fsicos, sin embargo, la identificacin de los objetos componentes en estos sistemas no sucede con tanta naturalidad. Los objetos en un sistema orientado a objetos de vez en cuando representan objetos fsicos, como las personas, libros o telfonos. Ms a menudo, sin embargo, representan ideas abstractas. Las personas tienen nombres, los libros tienen ttulos, y los telfonos se utilizan para realizar llamadas. Llamadas, ttulos, cuentas, nombres, citas, y los pagos no se consideran objetos en el mundo fsico, pero son todos los componentes modelados con frecuencia en los sistemas informticos. Vamos a tratar de modelar un ejemplo ms o orientado a ver la composicin en accin. Bien vamos a disear un juego de ajedrez computarizado. Esto fue un pasatiempo muy popular entre los acadmicos en los aos 80 y 90. La gente estaba prediciendo que las computadoras un da sera capaz de derrotar a un maestro de ajedrez humano. Cundo ocurri esto? en 1997 (Deep Blue de IBM derrot a campen mundial de ajedrez, Gary Kasparov), el inters en el problema disminuy, aunque todava hay contiendas entre el ordenador y los jugadores humanos de ajedrez, y el programa todava no se ha escrito que puede derrotar a un maestro de ajedrez humano 100% de las veces. Como base, anlisis de alto nivel: un juego de ajedrez se juega entre dos jugadores, usando un tablero de ajedrez que contiene sesenta y cuatro posiciones en una cuadrcula de 8x8. La tarjeta puede tener dos conjuntos de diecisis piezas que se pueden mover, en la alternancia de turnos por los dos jugadores de diferentes maneras. Cada pieza puede tomar (matar) otras piezas.


El tablero deber re-dibujarse en la pantalla del computador despus de cada turno. Habr identificado algunos de los objetos posibles en la descripcin mediante cursiva, y algunos mtodos mediante letra negrita. Este es un paso comn en convertir primero un anlisis orientado a objetos en un diseo. En este punto, se debe hacer hincapi en la composicin, nos centraremos en el tablero, sin preocuparse demasiado por los jugadores o los diferentes tipos de piezas. Vamos a empezar por el ms alto nivel de abstraccin posible. Tenemos dos jugadores interactuando con un juego de ajedrez por turnos haciendo movimientos.

Qu es eso? No son muy parecemos a nuestros diagramas de clases anteriores. Eso es porque no es un diagrama de clases! Este es un diagrama de objetos, tambin llamado un diagrama de ejemplo. Se describe el sistema en un estado especfico en el tiempo, y se describen ejemplos especficos de los objetos, no la interaccin entre las clases. Recuerde que ambos jugadores son miembros de la misma clase, por lo que el diagrama de clases se ve un poco diferente:

El diagrama muestra que exactamente dos jugadores pueden interactuar con un juego de ajedrez. Tambin indica que solo un jugador puede jugar con un juego de ajedrez en un momento del tiempo. Pero estamos hablando de composicin, no de UML, as que vamos a pensar en lo que el compone al juego de ajedrez. No nos importa de se compone el jugador en este momento. Podemos suponer que el jugador tiene un corazn y cerebro,


entre otros rganos, pero stas son irrelevantes para nuestro modelo. De hecho, no hay nada dicho para un jugador computador como Deep Blue en s, que no tiene ni un corazn ni el cerebro. El juego de ajedrez, se compone de un tablero y las piezas treinta y dos. El tablero est compuesto adems de sesenta y cuatro posiciones. Se podra argumentar que las piezas no son parte del juego de ajedrez, ya que podra reemplazar las piezas en un juego de ajedrez con un conjunto diferente de piezas. Si bien esto es poco probable o imposible en una versin computarizada de ajedrez, nos introduce a la agregacin. La agregacin es casi exactamente igual composicin. La diferencia es que los objetos agregados pueden existir independientemente. Sera imposible para una posicin que se asociara con un tablero de ajedrez diferente, Pero las piezas pueden existir independientemente del juego de ajedrez, se dice que estn en una relacin de agregado a dicho conjunto. Otra manera de diferenciar entre la agregacin y la composicin es pensar en la vida til del objeto. Si la composicin (exterior) que el objeto controla est relacionada (dentro de) con los objetos que son creados y destruidos, la composicin es la ms adecuada. Si el objeto relacionado se crea independientemente del objeto compuesto, o puede sobrevivir a ese objeto, una relacin de agregacin tiene ms sentido. Tambin hay que tener en cuenta que la composicin es una agregacin, la agregacin es simplemente una forma ms general de la composicin. Cualquier relacin composicin es tambin una relacin de agregacin, pero no viceversa. Vamos a describir nuestra actual composicin en el juego de ajedrez y aadir algunos atributos a los objetos para mantener las relaciones de composicin:

La relacin de composicin es representada en UML como un diamante slido. El


diamante hueco representa la relacin de agregacin. Se dar cuenta de que el tablero y las piezas se guardan como parte del juego de ajedrez exactamente de la misma manera que se almacena una referencia a ellos como un atributo en el juego de ajedrez. Esto demuestra una vez ms que, en la prctica, la distincin entre la agregacin y la composicin es a menudo irrelevante una vez que pasas la etapa de diseo. Cuando se implementa, se comportan de la misma manera. Sin embargo, puede ayudar a diferenciar entre los dos cuando su equipo est estudiando cmo los objetos interactan entre s. A menudo se puede tratar como una misma cosa, pero cuando es necesario distinguir entre ellos, es bueno saber la diferencia (esta es la abstraccin en el trabajo). Herencia Hemos hablado de tres tipos de relaciones entre los objetos: asociacin, composicin y agregacin. Pero no hemos especificado totalmente nuestro juego de ajedrez, y estas herramientas no parece que nos dar toda la energa que necesitamos. Hemos discutido la posibilidad de que un jugador puede ser un ser humano o puede ser una pieza de software con inteligencia artificial. No parece correcto decir que un jugador est asociado con un ser humano, o que la aplicacin de inteligencia artificial es parte del objeto Jugador. Lo que realmente necesitamos es la capacidad de decir que "Deep Blue es un jugador" o que Gary Kasparov " es un jugador ". La relacin es un est formada por herencia. La herencia es el ms famoso, bien conocido, y usado en exceso en relacin programacin orientada a objetos. La herencia es algo as como un rbol genealgico. El Apellido de mi abuelo era Bastidas y mi padre hered este apellido. Yo lo hered de l (junto con los ojos cafs y una aficin por la televisin). En programacin orientada a objetos, en lugar de heredar caractersticas y comportamientos de una persona, una clase puede heredar los atributos y mtodos de otra clase. Por ejemplo, hay treinta y dos piezas de ajedrez en nuestro juego de ajedrez, pero slo hay seis tipos diferentes de piezas (peones, torres, alfiles, caballos, rey y reina), cada uno de los cuales se comporta de forma diferente cuando se mueve. Todas estas clases de pieza tienen propiedades, como el color y el juego de ajedrez de que son parte , pero tambin tienen formas nicas cuando se dibuja en el tablero de ajedrez, y hacer movimientos diferentes. Ver cmo los seis tipos de piezas se pueden heredar de una clase Pieza:


Las flechas huecas, por supuesto, indican que las clases individuales de piezas hereda de la clase Pieza. Todos los subtipos tienen automticamente un atributo de color y juegoAjedrez que heredan de la clase base. Cada pieza proporciona una propiedad de forma diferente (que se dibuja en la pantalla cuando se representa el tablero), y un mtodo de mover diferente para desplazar la pieza a una nueva posicin en el tablero en cada turno. En realidad sabemos que todas las subclases de la clase Pieza necesitan tener un mtodo de movimiento, de lo contrario cuando en el tablero se trata mover la pieza que se confundir. Es posible que desee crear una nueva versin del juego de ajedrez que tiene una pieza adicional (el asistente). Nuestro diseo actual nos permitira disear esta pieza sin darle un mtodo de movimiento. El tablero entonces podra bloquearse cuando se pregunta qu pieza debe moverse.

Podemos implementar esto mediante la creacin de un mtodo vacio en la clase Pieza. En las subclases se puede sobreescribir este mtodo con una aplicacin ms especfica. La implementacin por defecto puede ser, por ejemplo, un mensaje de error que dice: Esa pieza no se puede mover. Reemplazar estos mtodos en subtipos permite una muy potente forma de desarrollar sistemas orientados a objetos. Por ejemplo, si quisiramos implementar una clase de jugador con inteligencia artificial, podramos proporcionar un mtodo calcular_movimineto que toma un objeto del tablero y decide dnde mover una


pieza. Y otra donde una clase muy bsica mueve la pieza al azar (randomicamente). Entonces podramos reemplazar este mtodo en una subclase de la aplicacin Deep Blue. La primera sera adecuada para jugar contra un gran maestro, esta ltima retara a un principiante. Lo importante es que otros mtodos en la clase, tales como las que informar al tablero como se mueven elegido la pieza elegida no tendra que ser cambiado, esta aplicacin puede ser compartido entre las dos clases. En el caso de piezas de ajedrez, no tiene mucho sentido para proporcionar una implementacin predeterminada del mtodo mover. Todo lo que necesitas hacer es especificar que el mtodo es requerido en las subclases. Esto se puede hacer haciendo de la clase Pieza una clase abstracta. Los mtodos abstractos bsicamente dicen "Necesitamos este mtodo en una subclase, pero se declina a especificar una implementacin de esta clase." De hecho, es posible hacer una clase que no implementa mtodos en absoluto. Esta clase simplemente nos dicen lo que la clase debe hacer, pero no proporciona absolutamente ningn consejo sobre cmo hacerlo. En el programacin orientada a objetos, Estas clases son llamadas interfaces. La Herencia Proporciona Abstraccin Ahora es el momento para otra palabra de moda. El polimorfismo es la capacidad de tratar una clase diferente en funcin a la subclase implementa. Ya hemos visto en accin con el sistema de piezas que hemos descrito. Si miramos mejor el diseo , probablemente volveramos a ver que el objeto del Tablero puede aceptar un movimiento del jugador y llamar a la funcin mover de la pieza. El tablero no tiene por qu saber qu tipo de pieza se trata. Todo lo que tiene que hacer es llamar al mtodo mover y la subclase apropiada se har cargo de moverlo como un caballo o un pen. El polimorfismo es muy bueno, pero es una palabra que se utiliza muy poco en la programacin Python. Python va un paso ms all de lo que permite una subclase de un objeto a ser tratado como una clase padre. A tablero implementado en Python podra tomar cualquier objeto que tenga un mtodo mover, si se trata de una pieza alfil, un coche, o un pato. Cuando se llama a mover, el Alfil se mueve en diagonal en el tablero, el coche va a conducir a algn lugar, y el pato va nadar o volar, dependiendo de su estado de nimo. Este tipo de polimorfismo en Python se suele denominar como pato escribiendo: "Si camina como un pato o nada como un pato, es un pato". No nos importa si realmente es un pato (herencia), slo que nada o camina. Gansos y cisnes fcilmente podra ser capaz de proporcionar el comportamiento de pato que estamos buscando. Esto permite a los futuros diseadores crear nuevos tipos de aves sin tener que especificar una jerarqua de herencia para las aves acuticas. Tambin les permite crear diferentes comportamientos completamente distintos que nunca los diseadores originales previstos para. Por ejemplo, los diseadores de futuros podra ser capaz de hacer una caminata, la natacin pingino que


trabaja con la misma interfaz sin tener que sugiere que los pinginos son patos La herencia mltiple Cuando pensamos en la herencia de nuestro propio rbol genealgico, podemos ver que heredamos caractersticas de ms de un solo de nuestros padres. Cuando alguien le dice a una madre que su hijo tiene "los ojos de su padre", ella responde tpicamente a lo largo de las lneas de, "s, pero tiene mi nariz". En el diseo orientado a objetos tambin se pueden caracterizar por existir herencia mltiple, que permite a una subclase de heredar la funcionalidad de las clases de padres mltiples. En la prctica, la herencia mltiple puede ser un negocio difcil, y algunos lenguajes de programacin, (en particular, Java) estrictamente lo prohben. Pero la herencia mltiple puede tener sus usos. Muy a menudo, se puede utilizar para crear objetos que tienen dos conjuntos distintos de comportamientos. Por ejemplo, un objeto diseado para conectarse a un escner y enviar un fax del documento escaneado se puede crear mediante la herencia de dos objetos separados escner y fax. Mientras dos clases tengan interfaces distintas, normalmente no es daino para una subclase de heredar de ambas. Pero se complica si se hereda de dos clases que proporcionan interfaces de superpuestas. Por ejemplo, si tenemos una clase motocicleta que tiene un mtodo de movimiento, y una clase de barco tambin cuenta con un mtodo de movimiento, y queremos unirlos en un vehculo anfibio, cmo sabe la clase resultante qu hacer cuando llamamos a mover? A nivel de diseo, esto debe ser explicado, y en el nivel de ejecucin, cada lenguaje de programacin tiene formas diferentes de decidir que mtodo de la clase padre se llama, o en qu orden. A menudo, la mejor manera de lidiar con esto es evitarlo. Si usted tiene un diseo que se muestra de esta manera, probablemente este mal. Hay que dar un paso atrs, analizar el sistema de nuevo, y ver si se puede eliminar la relacin de herencia mltiple en alguna relacin como otra asociacin o composicin. La herencia es una herramienta muy poderosa para extender el comportamiento. Tambin es uno de los avances ms emocionantes del diseo orientado a objetos a travs de los paradigmas anteriores. Por lo tanto, a menudo es la primera herramienta que programadores orientados a objetos usan. Sin embargo, es importante reconocer que la posesin de un martillo sirve para girar tornillos. La herencia es la solucin perfecta para una relacin obvia es, pero puede ser abusada. Los programadores suelen utilizar la herencia para compartir cdigo entre dos tipos de objetos que slo una relacin distante, sin una relacin a la vista. Si bien esto no es necesariamente un mal diseo, se trata de una excelente oportunidad para preguntar por qu se decidieron a disear esa manera, y si existe una relacin diferente o patrn de diseo habra sido ms adecuado.


Caso de Estudio Vamos a atar todos nuestros nuevos conocimientos orientados a objetos juntos yendo a travs de unas pocas iteraciones de diseo orientado a objetos en un ejemplo algo del mundo real. El sistema que va a ser modelado es un catlogo de la biblioteca. Las bibliotecas han tenido el seguimiento de su inventario durante siglos, originalmente usando catlogos de fichas, y, ms recientemente, los inventarios electrnicos. Bibliotecas modernas tienen catlogos basados en la web que pueden consultar desde nuestra casa. Vamos a empezar con un anlisis. El bibliotecario local nos ha pedido que escriba un nuevo programa de tarjetas de catlogo, ya que su antiguo programa basado en DOS es feo y anticuado. Eso no nos da mucho detalle, pero antes de empezar a pedir ms informacin, vamos a considerar lo que ya sabemos acerca de los catlogos de la biblioteca: Los catlogos contienen listas de libros. La gente busca a encontrar libros sobre ciertos temas, con ttulos especficos, o de un autor en particular. Los libros pueden ser identificados por un nmero del Libro Internacional Estndar (ISBN). Cada libro cuenta con un Sistema Decimal Dewey (DDS) asignado para ayudar a encontrar en un estante en particular. Este simple anlisis nos dice algunos de los objetos obvios en el sistema. Rpidamente nos identifican libro como el objeto ms importante, con varios atributos ya mencionados, como autor, ttulo, tema, ISBN, y el nmero de DDS, y el catlogo como una especie de manera ordenada de catalogar libros. Tambin notamos algunos objetos que pueden o no deben ser modelados en el sistema. A los efectos de catalogacin, todo lo que necesita para buscar un libro del autor es un atributo AUTHOR_NAME en el libro. Pero los autores tambin son objetos, y lo que se quiere es almacenar algunos otros datos sobre el autor. Al meditar sobre esto, podramos recordar que algunos libros tienen mltiples autores. De repente, la idea de tener un atributo AUTHOR_NAME solo en los objetos parece un poco tonto. Una lista de los autores asociados con cada libro es claramente una idea mejor. La relacin entre el autor y el libro es claramente de asociacin, ya que nunca dira "el libro es un autor" (no es la herencia), y diciendo: "El libro tiene un autor", aunque gramaticalmente correcto, no implica que los autores son parte de los libros (no es agregacin). En efecto, cualquier autor uno puede estar asociado con mltiples libros. Tambin debemos prestar atencin a los sustantivos (los sustantivo son siempre buenos candidatos para objetos). Estante un objeto que debe ser modelado en un sistema de catalogacin? Cmo identificamos un objeto individual. Qu ocurre si un libro se guarda en el extremo de un estante, y ms tarde se traslad al comienzo del siguiente estante porque otro libro fue insertado en el estante anterior? DDS fue diseado para ayudar a localizar fsicamente los libros en una biblioteca. Como tal, almacenar un atributo DDS con el libro debe ser suficiente para localizar, independientemente del estante donde se almacenan. As que podemos,


al menos por el momento, eliminar estante de nuestra lista de objetos contendientes. Otro objeto cuestionable en el sistema es el usuario. Necesitamos saber algo acerca de un usuario especfico? Su nombre, direccin, o una lista de libros atrasados? Hasta ahora, el bibliotecario nos ha dicho que slo quieren un catlogo, que no dijo nada acerca de las suscripciones de seguimiento o avisos de vencimiento. En el interior de nuestras mentes, tambin tomamos nota de que los autores y los usuarios son los dos tipos especficos de personas, podra haber una relacin de herencia til aqu en el futuro. Para fines de catalogacin, decidimos que no es necesario para identificar al usuario, por ahora. Podemos suponer que un usuario va a estar buscando en el catlogo, pero no tiene que intervenir activamente en el sistema, ms all de proporcionarle una interfaz que le permita la bsqueda. Qu se sabe acerca del comportamiento del sistema? El catlogo debe, obviamente, tener un mtodo de bsqueda, posiblemente separados para los autores, ttulos y materias. Hay comportamientos en los libros? Se necesita un mtodo de vista previa? O podra vista previa ser identificado como un atributo en lugar de un mtodo? Las preguntas de la discusin precedente, son parte de la fase de anlisis orientado a objetos. Pero entremezclados con las preguntas, ya hemos identificado algunos objetos clave que son parte del diseo. De hecho, lo que acabas de ver es de varios micro-iteraciones entre el anlisis y el diseo. Probablemente, todas estas iteraciones ocurriran en una reunin inicial con el bibliotecario. Antes de esta reunin, sin embargo, ya podemos esbozar un diseo ms bsico de los objetos que hemos identificado concretamente:

Armado con este esquema bsico y un lpiz para interactivamente mejorarlo, nos encontramos con el bibliotecario. Nos dicen que este es un buen comienzo, pero


las bibliotecas no tienen slo libros, sino que tambin tienen DVDs, revistas y CDs, ninguno de los cuales tiene un nmero ISBN o DDS. Todos estos tipos de elementos pueden ser identificada por un nmero UPC, sin embargo. Recordamos que el bibliotecario que tienen que encontrar los elementos por el mismo y estos elementos probablemente no est organizadas por la UPC. El bibliotecario explica que cada tipo est organizado de una manera diferente. Los CDs son en su mayora libros de audio y slo tienen un par de docenas en stock, por lo que son organizados por el apellido del autor. Los DVD se dividen en gneros y se organizan por ttulo. Las revistas estn organizadas por ttulos y caracterizadas luego por nmero de volumen y edicin. Los libros como nos habamos imaginado, organizada por nmero DDS. Sin ninguna experiencia anterior a diseo orientado a objetos, se podra considerar la adicin de listas separadas de DVDs, CDs, revistas y libros de nuestro catlogo, y buscar en cada uno de ellas. El problema es que, a excepcin de ciertos atributos extendidos, y la identificacin de la ubicacin fsica del elemento, estos elementos se comportan casi de la misma forma. Este es un trabajo para la herencia! Rpidamente nos actualizamos nuestro diagrama UML:

El bibliotecario entiende la esencia de nuestro esquema esbozado, pero es un poco confuso por la funcionalidad de localizacin. Le explicamos con un caso de uso especfico en el que el usuario est buscando la palabra "conejitos". El primer usuario enva una solicitud de bsqueda al catlogo. El catlogo consulta su lista interna de artculos y encuentra un libro y un DVD con "conejitos" en el ttulo. En este punto, el catlogo no importa si se est retornando un DVD, un libro, revista o CD; todos los elementos son los mismos, para lo que el catlogo se refiere. Pero el usuario quiere saber cmo encontrar los objetos fsicos, por lo que el catlogo sera negligente si simplemente devuelve una lista de ttulos. As se llama al mtodo de localizar los dos elementos que ha descubierto. El Mtodo del libro de


localizacin devuelve un nmero que puede DDS que es usado para encontrar el estante que sostiene el libro. El DVD se encuentra con la devolucin del gnero y el ttulo del DVD. El usuario puede visitar la seccin de DVD, busca la seccin que contiene ese gnero, y encontrar el DVD especfico ordenado por ttulo. Explicaremos nuestro diagrama UML por medio de un Diagrama de secuencia donde observaremos varios objetos comunicandose.


Ejercicios 1. En primer lugar, piense en el proyecto de programacin reciente que hayas completado . Identificar el objeto ms prominente en el diseo. Trate de pensar en tantos atributos de este objeto como sea posible. Se tiene: Color? Peso? Tamao? Beneficio? Costo? Nombre? Nmero de identificacin? Precio? Style? Piense en los tipos de atributos. Eran primitivas o clases? Fueron algunos de esos atributos en realidad comportamientos ocultos? A veces lo que parecen ser datos en realidad se estn calculado a partir de otros datos sobre el objeto, y se puede utilizar un mtodo para hacer esos clculos. Qu otros mtodos o comportamientos el objeto tiene? Qu objetos llamados esos mtodos. Qu tipo de relaciones tiene este objeto? 2. Despus de Realiza el anlisis respetivo cree el diagrama de clases del sistema


diseño orientado a objetos cap_1

Documents