Mdulo IIIFundamentos de la POO

Conceptos bsicos - AbstraccinDe qu hablamos cuando hablamos de abstraccin?Es el proceso de supresin de detalles respecto de un fenmeno, entidad o concepto.El objetivo es concentrarse en los aspectos ms significativos.

Algunas definicionesUn concepto general formado a partir de la extraccin de caractersticas comunes tomadas de ejemplos especficos.El proceso mental donde las ideas son separadas de los objetos concretos.

Conceptos bsicos Abstraccin y O.O.La Programacin Orientada a Objetos nos permite independizarnos del modelo de cmputo subyacente.Luego, podemos concentrarnos en resolver nuestro problema.En la POO la abstraccin se plantea en trminos de similitudes entre fenmenos, conceptos, entidades, etc. De esta manera, logramos identificar conceptos generales (persona, auto, pelota, etc.) que puedan ser traducidos a construcciones bsicas (objetos) en nuestro paradigma.

Conceptos bsicos - ModeloQu es un modelo?Es una versin simplificada de algn fenmeno o entidad del mundo real.

Qu significa modelar?Es un proceso de abstraccin.Tomamos una versin reducida de lo que queremos representar. Slo especificamos aquellas cosas que son relevantes.

Conceptos bsicos Modelo O.O.Los conceptos del dominio se representan como objetos.Los objetos se componen y colaboran con otros objetos para formar un modelo.La ejecucin de un programa OO puede verse como un modelo simulando el comportamiento de una parte del Mundo.

Resea HistricaAos 60: Simula. (Noreweigan Computing System)Inspirado por los problemas involucrados en la simulacin de sistemas de la vida real.Aos 70: Smalltalk (Xerox PARC)Alan Kay y su equipo de investigacin desarrollan Smalltalk basndose en los conceptos que introduca Simula.Aos 80: Smalltalk 80 y C++ (Laboratorios Bells)Casi contemporneo al trabajo de Kay desde los laboratorios Bell desarrollan C++ como extensin del lenguaje C. Comienzan proyectos similares, como Objective-C, Eiffel, Actor, entre otros. Aos 90: Java (Sun Microsystems)Es el resultado de la bsqueda de una plataforma independiente del hardware adoptando los conceptos de OO.2002: C# y .NET (Microsoft)Microsoft lanza su plataforma .NET para el desarrollo de aplicaciones multiplataforma. Junto con la plataforma aparece el lenguaje C#.

Resea histrica - Lnea temporal

Paradigma de ProgramacinConjunto de Elementos.Reglas.Brinda un marco para el diseo y la construccin de Programas.Ejemplos:Estructurado.Funcional.Lgico.Orientado a Objetos.Qu es un programa en un determinado paradigma?

Programacin Orientada a ObjetosLos sistemas estn compuestos por un conjunto de objetos.Los objetos son responsables de llevar a cabo ciertas acciones.Los objetos colaboran para llevar a cabo sus responsabilidades.Principios de la programacin orientada a objetos segn Alan Kay, el creador de Smalltalk:Todo es un objetoLos objetos se comunican enviando y recibiendo mensajesLos objetos tienen su propia memoria (en trminos de objetos)

Programacin Orientada a Objetos (cont.)La principal construccin es la nocin de objetos.

Los objetos pueden componerse o conocer otros objetos.

Los programas estn organizados en base a clases y jerarquas de herencia.

La forma de pedirle a un objeto que lleve a cabo una determinada tarea es por medio del envo de un mensaje.

Programa Orientado a ObjetosUn conjunto de objetos que colaboran envindose mensajes

Elementos Bsicos de la Programacin

Orientada a Objetos

ObjetosQu es un objeto?

Los objetos son los elementos primarios que utilizamos para construir programas.

Todo es un objeto en la programacin orientada a objetos.

Un objeto es una abstraccin de una entidad del dominio del problema.

Caractersticas de los ObjetosUn objeto tiene:Un comportamiento bien determinado.Qu hace el objeto y cmo lo hace?Un estado interno o estructura interna.El conjunto de variables de instancia.Una identidad.Cmo podemos distinguir un objeto de otro?Adems:Todo objeto es instancia de una clase.

El Comportamiento Qu hace el objeto?Un objeto se define en trminos de su comportamiento.El comportamiento indica qu sabe hacer el objeto. Cules son sus responsabilidades.Se especifica a travs del conjunto de mensajes que el objeto sabe responder: protocolo.Ejemplo:

El Comportamiento Cmo lo hace?La implementacin indica cmo hace el objeto para responder a sus mensajes.Se especifica a travs de un conjunto de mtodos.Es privada del objeto. Ningn otro objeto puede accederla.

El estado internoEst compuesto por las variables de instancia del objeto.Las v.i. pueden hacer referencia a:Propiedades intrnsecas del objeto (un nmero, un valor booleano, etc).Otros objetos con los cuales pueda colaborar para llevar a cabo sus responsabilidades.Es privado del objeto. Ningn otro objeto puede accederlo.

Ejemplo Caja de Ahorro

Practica: Identificar objetos y propiedadesAgrupe los elementos de la siguiente lista en objetos y propiedades.Banco,Extraer,Apellido,Depositar,DNI,CuentaBancaria,Cliente,CrearCuenta,Saldo,CerrarCuenta,Nombre.

Identifique, en el siguiente enunciado, objetos y propiedades:

Una computadora est formada por tres partes principales, un monitor, un gabinete y un teclado. Cada una de estas partes posee un modelo y un nmero de serie. Adems el gabinete puede determinar su temperatura y la cantidad de puertos USB que posee (tanto disponibles como en uso).Practica: Identificar objetos y propiedades

Envo de un mensajeEl comportamiento de un objeto est definido en trminos de los mensajes que ste entiende.

Para poder enviarle un mensaje a un objeto, hay que conocerlo.

Envo de un mensajeAl enviarle un mensaje a un objeto, ste responde activando el mtodo asociado a ese mensaje (siempre y cuando exista).

Como resultado del envo de un mensaje puede retornarse un objeto.

Envo de un mensaje - ejemploContamos con un objeto que representa la torre de control de un aeropuerto. La torre desea avisar al avin LV-YPS que debe aterrizar.Primero debe conocerlo.

Envo de un mensaje - ejemploLa torre enva el mensaje aterrizar al avin.El avin activar un mtodo con los pasos necesarios para aterrizar, si el avin no tiene tal mtodo se producir un error.

Envo de un mensaje - ejemploSe tiene modelados una persona, una expendedora y una cafetera. La persona le pide un caf a la expendedora. sta delega la preparacin a la cafetera. Luego, la cafetera retorna el caf a la expendedora que se lo entrega a la persona.

Envo de un mensaje - ejemploLa persona enva el mensaje #dameUnCafe() a la expendedora.La expendedora le pide a la cafetera que le sirva el caf en el vaso que le da.La cafetera retorna el vaso con el caf preparado.La expendedora entrega el vaso con caf a la persona

Envo de un mensaje

Especificacin de un MensajeCmo se especifica un mensaje?Se especifica con el nombre correspondiente al protocolo del objeto receptor.Se indica cules son los parmetros, es decir, la informacin necesaria para resolver el mensaje.Cada lenguaje de programacin propone una sintaxis particular para indicar el envo de un mensaje. A lo largo del curso utilizaremos la siguiente sintaxis:

Ejemplo empleando la sintaxis propuestaDecirle a una cuenta bancaria que deposite $100 se escribe como:. ();unaCuenta.depositar(100);

MtodosQu es un mtodo?Es la contraparte funcional del mensaje.Expresa la forma de llevar a cabo la semntica propia de un mensaje particular (el cmo).

Un mtodo puede realizar bsicamente 3 cosas:Modificar el estado interno del objeto.Colaborar con otros objetos (envindoles mensajes).Retornar y terminar.

Especificacin de un Mtodo

Ejemplo Depositar en Cuenta Bancaria

Ejemplo Cajero

Practica : SaldoCmo sera el mtodo del mensaje saldo?

Envo del mensaje saldo

Cambio del estado interno

Ejemplo Retornar el titularCmo sera el mtodo del mensaje titular()?

Ejercicio Depsito y ExtraccinCmo escribimos el mtodo extraer(unMonto)?

Modelar el proceso de extraccin de dinero de un cajero automtico. El cliente inserta la tarjeta e ingresa su PIN. Luego selecciona la opcin extraccin e ingresa el monto que desea extraer. Con esta informacin, el cajero le pide al banco que se ocupe de realizar la operacin. Practica: Cuenta Bancaria

Practica: Cuenta BancariaEl banco busca la cuenta con el nmero ingresado. Para esto el banco busca la cuenta del cliente, y le pide a la cuenta que realice la operacin (actualiza el saldo de la cuenta).

El banco entiende el mensaje #buscarCuenta: que dado un nmero de cuenta retorna la cuenta que corresponde a ese nmero.

Comportamiento y estado internoDijimos que el comportamiento tiene una implementacin privada.

Tambin que el estado interno es privado.

De qu hablamos cuando hablamos de privacidad?

Encapsulamiento Es la cualidad de los objetos de ocultar los detalles de implementacin y su estado interno del mundo exteriorCaractersticas:Esconde detalles de implementacin.Protege el estado interno de los objetos.Un objeto slo muestra su cara visible por medio de su protocolo.Los mtodos y su estado quedan escondidos para cualquier otro objeto. Es el objeto quien decide qu se publica.Facilita modularidad y reutilizacin.

Encapsulamiento importancia en OOCaracterstica fundamental del paradigma OO.Motiva a que el acoplamiento entre objetos sea bajo.Permite que el software escale mejor frente a cambios.Un objeto debe saber lo mnimo indispensable sobre los objetos que conoce.De esta manera, los cambios internos no impactan en los otros objetos del sistema.Programar en trminos del protocolo:La representacin interna de los objetos tiende a cambiar.

Encapsulamiento

Comportamiento comn entre ObjetosVolvamos al ejemplo del banco: Cuntos objetos Caja de Ahorro habr?Es necesario especificar el comportamiento de cada Caja de Ahorro? O el comportamiento debera ser comn a todas?Qu cosas son comunes a todas las Cajas de Ahorro y qu cosas son particulares de cada una? Entonces Cmo representamos este comportamiento comn, de manera que cada Caja de Ahorro pueda reutilizarlo?

ClasesUna clase es una descripcin abstracta de un conjunto de objetos.

Las clases Describen el formato de los objetos.Agrupan comportamiento en comn.Pueden pensarse como moldes de un tipo especfico de objeto

Clases e instanciasUna clase es responsable de crear sus instancias, es decir, las clases se comportan como fbricas.Entonces las clases cumplen tres roles:Agrupan el comportamiento comn a sus instancias.Definen la forma de sus instancias.Crean objetos que son instancia de ellasEn consecuencia todas las instancias de una clase se comportan de la misma maneraCada instancia mantendr su propio estado interno

Ejemplo de clases e instancias

Especificacin de ClasesLas clases se especifican por medio de un nombre, el estado o estructura interna que tendrn sus instancias y los mtodos asociados que definen el comportamientoGrficamente:

Envo de mensajes con clases I

Envo de mensajes con clases II

InstanciacinEs el mecanismo de creacin de objetos.Los objetos se instancian a partir de un molde.La clase funciona como molde.Un nuevo objeto es una instancia de una clase.Todas las instancias de una misma claseTendrn la misma estructura interna.Respondern al mismo protocolo (los mismos mensajes).

Instanciacin uso de newComnmente se utiliza la palabra reservada new para instanciar nuevos objetos.

Segn el lenguajenew es un mensaje que se enva a la clase.new es una operacin especial.

En C# el new es una operacin especial.

Variables de instanciaDefinen una relacin entre un objeto y sus atributos.

Se definen explcitamente como parte de la estructura de la clase.

La relacin dura tanto tiempo como viva el objeto.

Variables de instancia

Parmetros Se refiere a los parmetros de un mensaje.El nombre de la relacin se define explcitamente en el nombre del mtodo.La relacin de conocimiento dura el tiempo que el mtodo se encuentra activo.La ligadura entre el nombre y el objeto no puede alterarse durante la ejecucin del mtodo.

Parmetros

Variables temporalesDefinen relaciones temporales dentro de un mtodo.La relacin con el objeto se crea durante la ejecucin del mtodo.El nombre de la relacin se define explcitamente en el mtodo.La relacin se mantiene dentro del contexto donde fue definida la variable.Durante la ejecucin del mtodo, la ligadura entre el nombre y el objeto puede alterarse.

Variables temporales

La Seudo variable: thisVimos que para mandarle un mensaje a un objeto hay que poder nombrarlo.Cmo hace un objeto para mandarse un mensaje a s mismo?Seudo variable: como una variable ordinaria pero:No se declaraNo puede modificarseCon esta seudo variable el objeto puede hacer referencia a s mismo.

this

Veamos otro ejemplo

Doble encapsulamiento - Ejemplo

Recordemos las clase CajaDeAhorro, supongamos que se le cambia el nombre a la variable saldo por montoInterno.

En cuntos lugares del cdigo hay que cambiar la referencia: saldo por montoInterno?

Cmo se puede solucionar este problema?

UML Bsico

Unified Modeling LanguageLenguaje Unificado de Modelado

Una definicin de modelo: Un modelo es una interpretacin simplificada de la realidad [Eric Evans]Los Modelos:Ayudan a la mejor comprensin de sistemasIndican qu har el sistema pero no cmo lo harContribuyen a la correccin de erroresFavorecen a la evolucin y el reusoEsencial para la comunicacin entre miembros de un equipoModelado

UnificadoUn poco de historia A mediados de los noventa existan muchos mtodos de Anlisis y Diseo OO Mismos conceptos con distinta notacinMucha confusinNo exista un lenguaje lder de modelado

En 1994 deciden unificar sus mtodos: Unified Modeling Language (UML)

Proceso de estandarizacin promovido por OMG en 1997 G. Booch (Mtodo Booch) J. Rumbaugh (OMT) I. Jacobson (Proceso Objectory)

Unificado La unificacin agrupa otros enfoques:RumbaughJacobsonMeyerHarelWirfs-BrockFusionEmblyGamma y otrosShlaer-MellorOdellBoochPre y Post CondicionesDiagramas de EstadoResponsabilidadesDescripcin de operaciones,Numeracin de mensajesClases singletonFrameworks, Patrones, NotasCiclo de vida del objetoClasificacinCasos de UsoOMT

En la unificacin se adopta un Lenguaje Grfico estndar

Como toda definicin de Lenguaje, posee:

Sintaxis: determina los elementos bsicos sintcticos y las reglas de construccin de los diagramas de modelado. Semntica: otorga la descripcin detallada del significado conceptual de cada elemento de modelado.Lenguaje

Qu es entonces UML ?UML es un lenguaje estndar para:

visualizar especificar construir documentar

los artefactos de un sistema.Lenguaje Unificado de Modelado

Diagramas de UML 2.0

Diagrama de Clases

Definicin: Un diagrama de clases muestra las clases del sistema y sus relaciones. Describe la vista esttica de un sistema.

Diagrama de Clases

Qu es una clase? Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos (estado), operaciones (mensajes), relaciones y semntica.

Estructura: NombreClaseAtributos

Operaciones

Diagrama de Clases: claseResponsabilidades

Clase: nombre de la claseSintaxisNombre simple: NombreDeClaseNombres de camino: paq1::paq2::NombreDeClase

EjemplosObraDeTeatroteatro::ObraDeTeatro

La visibilidad puede ser:

Privada (-): objetos donde est definido el atributo u operacinProtegida (#): objetos de las subclasesPaquete (~ ): objetos del mismo paquete de la clase en donde est definido el atributo u operacinPblica (+): objetos de cualquier clase

Visibilidad de atributos y operaciones

Diagrama de clases: relacionesQu son las relaciones entre clases? Una relacin es una conexin semntica entre objetos. Proveen un camino de comunicacin entre ellos.Qu tipos de relaciones existen?

AsociacinGeneralizacinDependencia

Diagrama de clases: relacionesNotacin:

Asociacin

Agregacin

Composicin

Generalizacin

Dependencia

Relaciones: asociacinQu es una Asociacin?

Es una relacin estructural que especifica que los objetos de un elemento estn conectados con los objetos de otro.

EjemploEspectadorEntrada

Rol: son las caras que presenta una clase a su asociada.

Navegabilidad ( ): sirve para limitar la navegacin a una sola direccin.

Asociacin: propiedadesEspectadorReservapropietarioreservaUsuarioClavemiPass

Asociacin: propiedades (cont.)Multiplicidad: indica cuntos objetos pueden conectarse a travs de una instancia de una asociacin.

Se puede indicar una multiplicidad de:

Exactamente Uno:

Cero o Uno:

Muchos:

Uno o Ms:

Nmero Exacto:

Lista:

Rango:AAAAAABBBBBB10..10..*1..*30..1,3..5,7..9AB3..6

Asociacin: propiedades (cont.)Agregacin: es una asociacin especial, una relacin del tipo todo/parte dentro de la cual una o ms clases son partes de un conjunto.Notacin: ( )

Ejemplo:

EquipoMiembroTodoParte1Parte2TodoParte1Parte2TeatroDepartamento

Asociacin: propiedades (cont.)Composicin: es una forma de agregacin, con fuerte sentido de posesin y tiempo de vida coincidentes de las partes con el conjunto.Una parte puede pertenecer solamente a una composicin (un todo).Cuando el todo desaparece, tambin lo hacen sus partes.Notacin: ( )TodoParte

Asociacin: propiedades (cont.)Ejemplos de Composicin

Asociacin: notacin accesoriaNombre: indica la naturaleza de la asociacin. Puede estar acompaado de un tringulo que apunta en la direccin que debe leerse.

Ejemplo

EspectadorEntradacompraFormaDePagopaga

Tips sobre AsociacionesAnte ausencia de cardinalidad se presume 1.El nombre por defecto que toma un rol en una asociacin es el nombre de la clase a la que llega, en letras minsculas.

Relaciones: GeneralizacinQu es una Generalizacin? Es una relacin entre un elemento general (llamado superclase o padre) y un caso ms especfico de ese elemento (llamado subclase o hijo).Ejemplo

En UML puede representarse herencia mltipleReservaReservaIndividualReservaGrupalcd Generalizacin

Generalizacin: matices posiblesEn UML puede enriquecerse una jerarqua (Generalizacin) con discriminantes y restricciones.Ejemplo con restriccin

Elementos de anotacinQu es una nota? Es un smbolo para mostrar restricciones y comentarios junto a un elemento o una coleccin de elementos.cd Notas

Practicas

Ejercicio N 1 Suponga que se quiere modelar una cuenta de un banco.1- La cuenta pertenece a un nico titular y de ella podemos conocer cul es su saldo, adems de poder extraer y depositar montos de dinero.2- Suponga ahora que tenemos ms datos del titular, tales como nombre y apellido, dni, domicilio.3- Un nuevo requerimiento para nuestra cuenta bancaria es que puede tener ms de un titular.4- Ahora tenemos, para el banco que estamos modelando, cajas de ahorro y cuentas corrientes, que tienen el mismo comportamiento que las cuentas que tenamos antes, con la excepcin de que las cajas de ahorro nunca pueden tener su saldo menor a 0.

Ejercicio N 1Suponga que se quiere modelar una cuenta de un banco.1- La cuenta pertenece a un nico titular y de ella podemos conocer cul es su saldo, adems de poder extraer y depositar montos de dinero.

Ejercicio N 1Suponga que se quiere modelar una cuenta de un banco.2- Suponga ahora que tenemos ms datos del titular, tales como nombre y apellido, dni, domicilio.

Ejercicio N 1Suponga que se quiere modelar una cuenta de un banco.

3- Un nuevo requerimiento para nuestra cuenta bancaria es que puede tener ms de un titular.

Ejercicio N 14- Ahora tenemos, para las cuentas que estamos modelando, cajas de ahorro y cuentas corrientes, que tienen el mismo comportamiento que las cuentas que tenamos antes, con la excepcin de que las cajas de ahorro nunca pueden tener su saldo menor a 0.

Bibliografa

The Unified Modeling Language User Guide - G. Booch, J. Rumbaugh, and I. Jacobson - Addison-Wesley.The Unified Modeling Language Reference Manual - G. Booch, J. Rumbaugh, and I. Jacobson - Addison-Wesley UML Distilled - Martin Fowler UML for Java Programmers - Robert Cecil MartinOMG Unified Modeling Language Specification (Version 2.0)Lenguaje UML 2 Manuel ImazApplying UML and Patterns Craig Larman

*AbstraccinProbablemente la abstraccin sea la herramienta ms poderosa con la que cuenta el hombre para comprender fenmenos complejos del mundo real. En el mundo real nos enfrentamos da a da con diferentes fenmenos tales como objetos fsicos, eventos, situaciones y procesos. La abstraccin, en este sentido, es el proceso [intencional] de supresin, u ocultamiento, de detalles respecto de un fenmeno, entidad o concepto, dejando de lado el resto, de manera de concentrarnos en otros aspectos que nos son ms significativos en un determinado contexto.Es importante notar que este proceso de abstraccin es completamente subjetivo y dependiente del contexto; diferentes personas pueden atravesar este proceso de simplificacin de diferentes maneras para un mismo fenmeno o entidad, eliminando diferentes conceptos y, por tanto, llegando a una caracterizacin diferente. Por ejemplo, tomando como objeto de anlisis el concepto de automvil, un observador interesado en la mecnica podra caracterizarlo como un vehculo con cierto tipo de motor, mientras que otro observador, en un contexto diferente, podra caracterizar al mismo automvil como un medio de trasporte, haciendo nfasis en su capacidad de trasportar personas o cosas. Notar que en este caso, deja de importar el tipo de motor que tenga (simplificacin).Diferentes niveles de abstraccinNuestro mundo est conformado por una enorme cantidad de fenmenos y entidades, imposibles de representar y manejar sin alguna herramienta que nos permita caracterizarlos de alguna forma prctica.Una forma de realizar esto es lograr abstraer determinadas caractersticas de las entidades de nuestro dominio, para as modelar un concepto ms general que las abarque. En otras palabras, lo que buscamos es separar efectivamente los objetos concretos de la idea que queremos representar. Esto, que en principio nos puede parecer una tarea difcil, es algo que hacemos inconscientemente en el da a da. A modo de ejemplo, pensemos en la nocin de que un objeto se encuentre sobre otro: si vemos un florero apoyado en una mesa diremos naturalmente que el florero se encuentra sobre la mesa. Asimismo, podemos decir que un lpiz se encuentra sobre un escritorio o que el pan se encuentra sobre la mesada. De estos ejemplos podemos decir que el florero, el lpiz y el pan comparten el concepto de estar sobre algo. De hecho, una vez que logramos abstraer la idea de estar sobre, no slo la podemos extrapolar a otras situaciones sino que podremos hablar en abstracto con otras personas que comprendan esa nocin, sin referirnos a un caso concreto. De forma similar, podramos utilizar una pelota, un aro, una rueda, etc., y a partir de estos objetos explicar lo que significa que un objeto sea redondo. Una vez hecho esto podemos determinar si una o ms entidades pueden ser caracterizadas de esta manera simplemente por comparacin (verificando que el conjunto de propiedades que define al concepto redondo tambin son propias de la entidad en cuestin). Al trabajar con objetos, dos de las ms importantes abstracciones con las que trabajaremos son las nociones es-un y tiene-un:*Tipos de abstracciones: es-un y tiene-un [9] Las nociones de dividir en partes y dividir en especializaciones representan las dos formas de abstraccin ms importantes usadas en la programacin orientada a objetos. Comnmente se las conoce como las abstracciones es-un y tiene-un.La idea de divisin en partes es la abstraccin tiene-un. El significado de este trmino es fcil de comprender; un auto tiene-un motor, tiene-una transmisin, etc.Al concepto de especializacin nos referimos como la abstraccin es-un. Nuevamente, el trmino surge de las sentencias que pueden ser usadas para ilustrar las relaciones. Utilizando este concepto, una bicicleta es-un vehculo rodado, el cual a su vez es-un medio de transporte...

Buscando el nivel de abstraccin correcto [9]En las etapas tempranas del desarrollo de software uno de los problemas crticos es encontrar el nivel de abstraccin correcto o adecuado. Un error comn es hacer hincapi en los niveles ms bajos, preocupndose por los detalles de implementacin de varios componentes claves, en lugar de esforzarse para asegurar que la estructura organizativa de alto nivel promueva una clara separacin de responsabilidades (concerns).El programador (o el equipo de diseo en grandes proyectos) debe tratar de balancear el nivel de abstraccin adecuado en cada momento. Por un lado, uno no quiere ignorar o tirar a la basura demasiados detalles sobre un problema, pero por otro lado, tampoco uno debe mantener muchos detalles que al fin de cuentas opaquen y no nos permitan ver ciertas cuestiones importantes.

En el contexto de la programacin OO, la abstraccin surge como un proceso de reconocimiento de similitudes entre fenmenos, conceptos y entidades, y la decisin de concentrarse en estas similitudes e ignorar las diferencias entre ellos. De esta manera, logramos identificar conceptos generales (persona, auto, pelota, etc.) que puedan ser mapeados directamente a construcciones bsicas (objetos) en nuestro paradigma.

*ModeloUn modelo, es una versin simplificada de algn fenmeno o entidad del mundo real. El modelado, como proceso, est muy ligado a otro concepto muy importante que vimos anteriormente: el de abstraccin. La forma de construir un modelo, ya sea mental, fsico, etc., es a travs de un proceso de abstraccin (simplificacin), mediante el cual descartamos aquellas caractersticas que no nos sean relevantes y nos concentramos en aquellas que s nos interesan. Esas caractersticas relevantes son las que terminarn dando forma a nuestro modelo. En dos lneas, acerca de un modelo podramos decir:Es una abstraccin utilizada para entender y razonar sobre entidades y fenmenos del mundo real.Debe omitir detalles no esenciales y su grado de granularidad debe estar acorde a sus propsitos.

Modelado del mundo realCreamos un sinfn de modelos mentales para poder comprender los fenmenos interesantes y para poder dominarlos. Un modelo es un artefacto creado por un propsito; no puede estar bien o mal, slo puede ser ms o menos til en relacin a su objetivo. La eleccin de los fenmenos y las preguntas que hacemos sobre los mismos dependen de nuestros intereses, los paradigmas de modelado a los que estemos acostumbrados y las herramientas que usemos para expresar nuestras ideas. Si lo que queremos es comunicar de manera precisa nuestras ideas a un colega, nuestro paradigma de modelado y notacin deben ser similares a su paradigma y notacin. Si lo que queremos es comunicarnos con una computadora, nuestro paradigma de modelado debe ser consistente con el lenguaje de computacin apropiado. A medida que seamos ms expertos en un paradigma de modelado en particular, ms difcil ser poder realizar preguntas cuyas respuestas excedan los lmites del paradigma.[16]Como dice Trygve en la referencia anterior, un modelo es creado con un propsito, y por tanto, podemos inferir que hay una subjetividad implcita agregada por el observador que crea este modelo, ya que lo hace motivado por un propsito. Es importante notar que dicho propsito (ya sea propio o inducido) puede ser completamente diferente al de otro observador. Asimismo, un modelo nuca est completo, sino que su grado de completitud depende del uso que le demos a dicho modelo. Las personas creamos modelos justamente para simplificar y generalizar fenmenos ms complejos, con lo cual, en realidad, terminamos ignorando ms detalles de los que incluimos en nuestro modelo.*A pesar de no hacerlo conscientemente, vivimos constantemente utilizando y creando nuevos modelos de todo tipo para representar los fenmenos de la naturaleza; los ejemplos abundan y van desde los modelos fsicos (utilizados en el diseo de represas, puentes, puertos y otras construcciones) hasta los modelos matemticos (utilizados por ejemplo para realizar simulaciones y optimizaciones sobre sistemas reales, como en el campo de la hidrologa). En astronoma se utilizan modelos especficos para representar el movimiento de los cuerpos celestes en el espacio, utilizando elementos de la geometra como son los crculos y las elipses para representar las rbitas que describen los planetas, junto con otros modelos matemticos. Estos modelos permiten a los astrnomos, entre otras cosas, poder estimar la posicin de uno de estos cuerpos celestes en el espacio en un punto determinado en el tiempo y predecir, por ejemplo, las colisiones entre ellos. Es importante notar que al realizar este tipo de modelos se dejan de lado muchos detalles; por ejemplo, los planetas no son esferas perfectas, pero son modelados de esa forma ya que simplifican determinados clculos y la imprecisin que introducen en el resultado final es despreciable.Los modelos tambin nos permiten poder realizar simulaciones para evaluar o estimar cul ser el desempeo del sistema en el mundo real, una vez que sea llevado a la prctica. Este tipo de tcnicas es utilizado en la industria del diseo de vehculos de alta tecnologa (automotriz o aeronutica) para testear, por ejemplo, las caractersticas aerodinmicas de los prototipos, utilizando maquetas a escala y simulando el desempeo del vehculo dentro de un tnel de viento.

Modelos OOLa ejecucin de un programa se puede ver como un modelo fsico simulando el comportamiento de una parte real o imaginaria del Mundo.La palabra clave aqu es fsico. El trmico modelo fsico es utilizado para distinguir estos modelos de, por ejemplo, los modelos matemticos. Parte de la realidad puede ser explicada utilizando ecuaciones matemticas: las leyes de Newton son un ejemplo de esto. Un modelo fsico es un modelo construido a partir de algn material fsico como pueden ser los ladrillos Lego. Los elementos del modelo fsico representan fenmenos del dominio de aplicacin. Los objetos son como el material computarizado que se utiliza para construir modelos fsicos computarizados. Podemos ver a los objetos como un tipo de ladrillos electrnicos de Lego.

* Resea Histrica [9]Comnmente se piensa que la programacin orientada a objetos es un fenmeno relativamente reciente dentro de la ciencia de la computacin. Por el contrario, en realidad, casi todos los conceptos principales actualmente asociados con los programas orientados a objetos, tales como objetos, clases y jerarquas de herencia, fueron desarrollados en los aos 60 como parte de un lenguaje llamado Simula, diseado por investigadores en el Centro de Computacin Noruego (Norwegian Computing Center). Como el nombre lo indica, Simula fue un lenguaje inspirado por los problemas involucrados en la simulacin de sistemas de la vida real. Sin embargo, la importancia de estas construcciones, an para los propios desarrolladores de Simula, fue reconocida parcialmente [10].En la dcada del 70 Alan Kay organiz un equipo de investigacin en Xerox PARC (Palo Alto Research Center o Centro de Investigacin Palo Alto). Con una gran presciencia o previsin, Kay predijo la prxima revolucin en la computacin personal que se desarrollara cerca de una dcada ms tarde (ver, por ejemplo, su artculo de 1977 en Scientific American [11]). Kay estaba interesado en descubrir un lenguaje de programacin que fuera entendible para aquellos profesionales ajenos a la computacin, para la gente comn sin ningn tipo de entrenamiento en el uso de computadoras. Encontr en las nociones de clases y en la computacin como simulacin una metfora que fcilmente podra llegar a ser comprendida por los usuarios principiantes, como luego demostrara mediante una serie de experimentos dirigidos en PARC usando a los chicos como programadores. El lenguaje de programacin desarrollado por su equipo fue llamado Smalltalk. Este lenguaje evolucion a travs de varias revisiones durante la dcada. Un artculo muy popular de la revista Byte de 1981 contribuy para popularizar en gran medida los conceptos desarrollados por Kay y su equipo en Xerox.Casi contemporneo al trabajo de Kay fue otro proyecto llevado a cabo al otro lado del continente. Bjarne Stroustrup, un investigador de los Laboratorios Bell que haba aprendido Simula mientras completaba su doctorado en la Universidad de Cambridge en Inglaterra, se encontraba desarrollando una extensin al lenguaje C que facilitara la creacin de objetos y clases [12]. Esto se transformara luego en el lenguaje C++ [13].Con la difusin de informacin sobre estos y otros proyectos similares, comenz un aumento vertiginoso de la investigacin sobre tcnicas de programacin orientada a objetos. Al momento de producirse la primera conferencia importante sobre programacin orientada a objetos, en 1986, hubo literalmente docenas de nuevos lenguajes de programacin compitiendo para ser aceptados. Entre estos incluidos Eiffel [14], Objective-C [15], Actor, Object Pascal, y varios dialectos de Lisp.En las dos dcadas desde la conferencia de OOPSLA en 1986, la programacin orientada a objetos a pasado de ser revolucionaria a ser el movimiento principal, y en este proceso ha transformado gran parte de la ciencia de la computacin.

*Simula: Por los aos 60, los programadores comprendieron que era necesario descomponer los sistemas de programacin en partes pequeas ms manejables. La introduccin de Simula-67 trajo consigo la primera nocin de objetos, las clases, y una especie de herencia; por lo tanto, Simula es un hito importante en cualquier debate sobre lenguajes de programacin OO. El lenguaje fue diseado por Ole-Johan Dahl, Bjrn Myhrhaug y Kristen Nygaard en el Norwegian Computing Center ubicado en Oslo. La primer versin del lenguaje, Simula-1, fue presentada en 1966. Los mdulos de programacin definidos por Simula no se basaron en procedimientos, sino en objetos fsicos tangibles. Simula tuvo una novedosa manera de plantear los objetos, en donde que cada objeto tiene sus propios datos y comportamiento.Smalltalk: Muchos consideran que el primer lenguaje verdaderamente orientado a objetos fue Smalltalk, desarrollado en el Learning Research Group en Xerox's Palo Alto Research Center a principios de los 70. En Smalltalk, todo es realmente un objeto, lo que impone el paradigma OO y hace que sea prcticamente imposible escribir un programa en Smalltalk que no sea OO.Smalltalk es en realidad un ambiente de programacin interactivo que interpreta cdigo sobre la marcha (on-the-fly) lo que permite cambiar los parmetros y el cdigo de un programa mientras el programa est corriendo.Smalltalk fue el primero en introducir muchos otros conceptos que luego apareceran como revolucionarios al ser implementados en otras aplicaciones, como los buscadores o exploradores (browsers), las ventanas y los mens emergentes (pop-up menus). El ambiente se basa en una mquina virtual, permitiendo a las aplicaciones ser migradas entre diferentes plataformas.C++: Tiene su origen en un proyecto para simular software corriendo en un sistema distribuido. Este simulador, de hecho escrito en Simula, es donde Bjarne Stroustrup concibi la idea de combinar algunas de las caractersticas de Simula con la sintaxis de C. El concepto de clase en C++ brindaba el mecanismo de encapsulamiento, que hoy por hoy es un requisito esencial de cualquier lenguaje OO. Aunque C brind una base slida para C++, tambin se convirti en una carga un tanto pesada. El hecho de hacer a C++ compatible con su predecesor trajo serios inconvenientes. Aunque C++ proporciona construcciones OO, tambin es posible usar tcnicas de programacin estructurada. Por este motivo, C++ no es considerado un lenguaje OO puro, si no un lenguaje hbrido.Java: Los orgenes de Java se encuentran en un lenguaje que se apod Oak. Su creador decidi que basara su lenguaje en el tan exitoso C++, pero que slo incorporara aquellas caractersticas de C++ que parecieran valer la pena. Las caractersticas que elimin de C++ fueron la herencia mltiple, las conversiones automticas de tipos, el uso de punteros, y el esquema de administracin de memoria de C++. Pero el proyecto fue archivado por falta de inters en el mercado.Con la llegada de la Web y el surgimiento de los browsers, la gente de Sun comenz a atar cabos, y as Oak fue rescatado de la inactividad y renombrado como Java. C#: Microsoft respondi a la popularidad de Java produciendo una versin de Java llamada Visual J++. Sin embargo, Microsoft se decidi por una respuesta ms integral. Usando muchas de las innovaciones que implementaba Java, Microsoft desarroll un lenguaje denominado C# que se convirti en la base para la plataforma .NET. De igual manera que Java, C# se bas fuertemente en los xitos y fracasos de lenguajes anteriores. *ParadigmaEtimolgicamente la palabra paradigma deriva del Griego paradigma, que significa patrn o ejemplo. Thomas Kuhn [2] asign a la palabra paradigma [19] el significado aceptado hoy en da en la comunidad cientfica, cuando la adopt para referirse al conjunto de prcticas que definen a una disciplina cientfica durante un perodo de tiempo en particular. Kuhn define tambin el trmino cambio paradigmtico[20], como el proceso y el resultado de un cambio en las hiptesis establecidas por las teoras cientficas reinantes. Un cambio paradigmtico (o revolucin cientfica, como tambin lo llama Kuhn) se origina cuando los cientficos encuentran anomalas que no pueden ser explicadas mediante el paradigma aceptado universalmente sobre el cual debe realizarse el progreso cientfico. Todos los paradigmas presentan anomalas pero las hay de distinto tipo e importancia. Cuando ocurre una serie de anomalas significativas contra un paradigma actual, la disciplina cientfica entra en un estado de crisis, en el cual se prueban nuevas ideas, tal vez descartadas previamente. Eventualmente se forma un nuevo paradigma, que entrar en conflicto con el actual, enfrentando a los seguidores de cada corriente. De producirse la transicin entre el antiguo paradigma y el nuevo, se dice que ha sucedido una revolucin cientfica o cambio paradigmtico, segn Kuhn.Floyd, en The Paradigms of Programming [18] de 1978 habla sobre cmo influyen los paradigmas de programacin en el suceso de los diseadores de programas, sobre cmo deben ser enseados y cmo deben ser incorporados en los lenguajes de programacin. Afirma que por aquella poca existan problemas en cuanto al inventario de paradigmas de programacin disponible, en la manera en que se enseaba estos paradigmas y en la manera en que los lenguajes de programacin soportaban o dejaban de soportar los paradigmas de sus correspondientes comunidades de usuarios. Se refiere al estado de la programacin como un estado de depresin (lo llama depresin del software), en comparacin con la crisis del software de la dcada anterior. Basndose en la visin de Kuhn sobre las revoluciones cientficas y en experiencias llevadas a cabo por l y algunos de sus colegas, concluye que la probabilidad de que se produzca un avance continuo en programacin, requerir de una invencin continua, elaboracin y comunicacin de nuevos paradigmas. *El Paradigma Orientado a ObjetosHasta el momento hemos dado algunas ideas respecto de qu es un paradigma y de los distintos paradigmas de programacin que encontramos hoy en da. Pero por qu es importante sto? En nuestro caso, poder definir el paradigma orientado a objetos nos va a permitir entender claramente cules son las bases sobre las que vamos a trabajar. En breve, al definir el paradigma OO estaremos explicitando cules son los conceptos bsicos con los que trabajaremos y cules son las reglas vlidas que nos permitirn manipular dichos conceptos.Probablemente Alan Kay es quin ha dado la definicin ms concisa del paradigma orientado a objetos. En [27] escribe:para este momento la mayora de los principios de Smalltalk se haban plasmado en seis ideas principales que estaban en consonancia con las premisas iniciales del diseo del intrprete. Las primeras tres hablan sobre que significa ser un objeto cmo son vistos y utilizados desde el exterior. Estas premisas no requirieron de ninguna modificacin durante los aos. Las ltimas tres los objetos vistos desde adentro fueron re-pensadas en cada nueva versin de SmalltalkTodo es un objeto.Los objetos se comunican enviando y recibiendo mensajes.Los objetos tienen su propia memoria (en trminos de objetos).Cada objeto es instancia de una clase (que tambin debe ser un objeto).Las clases contienen el comportamiento compartito por sus instancias.Para evaluar un programa, el control es pasado al primer objeto y el resto es tratado como envo de mensajes.

**Programas Orientados a ObjetosUna vez que hemos sentado el paradigma con el cual vamos a trabajar (o sea, las reglas del juego) es interesante detenernos un momento y analizar que forma tiene un programa en este paradigma. Al utilizar un paradigma estructurado, un programa se basa en el diseo de estructuras de datos, los cuales son bsicamente contenedores de informacin pasivos. Luego, se desarrollan algoritmos que trabajan sobre dichas estructuras realizando algn tipo de transformacin de datos. Al construir programas orientados a objetos, se deja de pensar en trminos de estructuras de datos pasivas y algoritmos y se piensa en trminos de objetos activos; los objetos son entidades que proveen un comportamiento particular y son utilizados para modelar el dominio del problema. Bajo esta ptica, nuestro programa ya no se encuentra dividido entre datos pasivos y algoritmos activos, sino que es una red de objetos que cooperan (envindose mensajes) para llevar determinada tarea a cabo.

*Los objetos son los elementos primarios que utilizaremos para construir programas. Dichos objetos son bsicamente abstracciones de alguna entidad (ya sea tangible o no) del dominio del problema que estamos atacando. Para resolver un problema determinado en el paradigma OO slo tenemos objetos, que se comportan de una determinada manera (definido por sus mensajes) e interactan entre ellos (envindose de mensajes).Cada objeto es una construccin caracterizada por: su comportamiento, el cual est dado por los mensajes a los que puede responder; su estado interno, que, mediante un conjunto de variables de instancia representa las caractersticas intrnsecas de la entidad; y finalmente su identidad. El comportamiento que provee puede verse como los servicios que presta y que determinan su existencia y deben servir para responder preguntas como /para qu quiero a este objeto?/ y /qu servicios me puede brindar?/. Por otro lado, como dijimos antes, el estado interno est representado por variables de instancia que se utilizan para expresar caractersticas del objeto y relaciones de conocimiento con los otros objetos con que va a colaborar.Otra de las propiedades importantes de los objetos es el encapsulamiento, que sostiene que el nico que puede manipular el estado interno de un objeto es el mismo objeto. En otras palabras, un objeto no puede invadir el espacio privado (estado interno) de otro objeto.Pero no debemos perder de vista el hecho de que dentro de un sistema coexisten miles de objetos, lo que conduce a la necesidad de disponer de algn mecanismo que permita identificarlos unvocamente de modo de poder diferenciarlos. Por este motivo, los objetos poseen una identidad que, como se present anteriormente, es una propiedad intrnseca de cada objeto y, por tanto, no puede ser modificada por el programador.

*CaractersticasComportamiento bien determinado. Al disear un objeto lo que uno hace es establecer cules son las responsabilidades de dicho objeto. Estas responsabilidades se materializan en un conjunto de mensajes a los que un objeto puede responder.Estado interno. A nivel de implementacin los objetos poseen una estructura interna que se define en trminos de variables de instancia. Las variables de instancia se utilizan para representar aquellas caractersticas propias del objeto (como puede ser el nmero de una cuenta bancaria) y a los objetos con los que deber colaborar a lo largo de su vida.Identidad. Es una propiedad intrnseca que poseen todos los objetos. La definicin de identidad es la siguiente: Un objeto solo es idntico a si mismo. Notar que identidad no es lo mismo que igualdad; dos tazas pueden ser iguales, pero cada taza solo es idntica a si misma.Todo objeto es instancia de una clase. Las clases son el siguiente nivel de abstraccin, sobre el cual entraremos en detalle mas adelante. Como dijimos anteriormente, un objeto es una abstraccin de una entidad de nuestro modelo. Dado que generalmente nos encontramos con un conjunto de objetos que se comportan en forma similar, el siguiente paso es encontrar una forma de definir el comportamiento de todos estos en forma general. Pensemos por ejemplo en las cuentas bancarias: en un banco habr miles de cuentas bancarias, las que se comportarn de la misma forma. Por este motivo, aparece la nocin de clase cuenta bancaria, la cual se utiliza para describir el comportamiento de todas sus ocurrencias (instancias).*Cuando pensamos en los objetos vistos desde afuera lo que nos interesa es qu es lo que el objeto puede hacer y no cmo lo hace. A continuacin veamos un extracto del libro de Budd [34]:Supongamos que un individuo, llamado Chris, desea enviarle flores a una amiga llamada Robin, que vive en otra ciudad. Debido a la distancia, Chris no puede simplemente recoger las flores y llevrselas a Robin en persona. No obstante, esta tarea puede resolverse fcilmente. Chris puede simplemente caminar hasta la florera ms cercana, la cual es atendida por un florista llamado Fred. Chris le dir a Fred el tipo de flores que desea enviar a Robin, y la direccin donde deben ser entregadas. Luego Chris tendr la seguridad de que las flores sern entregadas de manera expeditiva y automtica. Corriendo el riesgo de volver innecesariamente a algn punto, enfaticemos el hecho de que el mecanismo que fue usado para resolver el problema, fue encontrar un agente apropiado (llamado Fred) y enviarle a este un mensaje con la solicitud. Es responsabilidad de Fred satisfacer esa solicitud. Existe un mtodo (algn algoritmo o conjunto de operaciones) usado por Fred para hacer esto. Chris no tiene que preocuparse en saber las particularidad del mtodo que Fred usar para satisfacer la solicitud, de hecho, a menudo la persona que hace una solicitud no desea saber lo detalles. Esta informacin usualmente se encuentra oculta. Una investigacin, sin embargo, podra mostrar el hecho de que Fred enva un mensaje ligeramente diferente a otro florista en la ciudad donde vive Robin. Ese florista, tal vez tenga un subordinado que hace los arreglos florales. Este florista entonces le pasa las flores, junto con otro mensaje a un repartidor, y as sucesivamente. En un principio, el florista que vive en la ciudad de Robin obtuvo sus flores de un mayorista de flores, el cual interactu con los que cultivan las flores, los cuales deben administrar un equipo de jardineros.Entonces, nuestra primera observacin de la solucin orientada a objetos a un problema, es que la solucin a este problema requiere de la ayuda de otros individuos. Sin su ayuda, el problema no podra ser fcilmente solucionado. Expresaremos esto de la siguiente manera: Un programa orientado a objetos se estructura como una comunidad de agentes interactuando, llamados objetos. Cada objeto tiene un rol para llevar a cabo. Cada objeto provee un servicio, o ejecuta una accin, que es usada por otro miembro de la comunidad. [34]En muchos casos el objeto necesitar otros objetos que lo ayuden a llevar a cabo su tarea. En este caso, al enviar el mensaje, el objeto emisor tambin le enva un conjunto de parmetros para que el objeto pueda resolver el pedido. Por ejemplo, al pedirle al florista que enve las flores, el objeto emisor (Chris) debe indicarle al florista el tipo y cantidad de flores que quiere enviar, as como la direccin de Robin.**Estado interno/estructura internaEl estado interno de un objeto est constituido por un conjunto de variables de instancia. Dichas variables de instancia acompaan al objeto durante todo su ciclo de vida.Una variable de instancia puede hacer referencia a una propiedad intrnseca de la entidad que representa, o bien a otro objeto con el cual pueda colaborar para llevar a cabo sus responsabilidades. A lo largo de la vida del objeto, las propiedades y colaboradores pueden cambiar. Por ejemplo, al depositar $100 en una cuenta bancaria la variable de instancia saldo cambiar su valor.Este estado interno es privado del objeto. Es una de las caractersticas fundamentales del paradigma y, como veremos ms adelante, resulta crucial para lograr software escalable. Por definicin, las variables de instancia (estructura interna) de un objeto es privado a ste. El nico que puede acceder y manipular sus v.i. es el propio objeto. Si un objeto externo quiere acceder a una v.i. lo tiene que hacer por medio del envo de un mensaje. Esto le da la posibilidad al objeto de decidir qu es lo que quiere publicar.IdentidadLa identidad es una propiedad intrnseca que poseen todos los objetos. Por definicin un objeto solo es idntico a si mismo. Es importante notar que identidad no es lo mismo que igualdad; dos sillas pueden ser iguales al punto que, si nos damos vuelta y las cambian de lugar, no podramos distinguir cual es cual. A pesar de esto, cada silla sigue manteniendo su identidad. La identidad sirve para poder distinguir objetos individuales dentro de un sistema. Es decir, dentro de un sistema coexisten una cierta cantidad de objetos, por lo que es necesario poder identificarlos y diferenciarlos entre ellos. La identidad, a nivel prctico, no tiene mayor importancia para el programador ya que los lenguajes orientados a objetos proveen un mecanismo por el cual cada objeto posee un identificador nico y, de hecho, casi nunca es posible obtener dicho identificador. Indirectamente vamos a estar utilizando este concepto cuando comparemos dos objetos por igualdad, pero este concepto se ampliarn a continuacin.

*Objetos:Banco, CuentaBancaria, Cliente.Propiedades:Depositar, Extraer, Saldo, CerrarCuenta, CrearCuenta, Apellido, DNI, Nombre.

Como ejercitacin adicional, y dependiendo de la compresin del tema hasta el momento de los cursantes, puede plantearse la idea de agrupar las propiedades en los objetos que correspondan. La solucin deseada es la siguiente:

Banco: CrearCuenta, CerrarCuenta.Cliente: Apellido, DNI, Nombre.CuentaBancaria: Extraer, Depositar, Saldo.

*Objetos:Computadora, Monitor, Gabinete, Teclado.Propiedades:modelo, numeroDeSerie, modeloTeclado, modeloMonitor, modeloGabinete, numeroDeSerieTeclado, numeroDeSerieMonitor, numeroDeSerieGabinete, temperatura, puertosUSBDisponibles, puertosUSBEnUso, crearCuenta.

Como ejercitacin adicional, y dependiendo de la compresin del tema hasta el momento de los cursantes, puede plantearse la idea de agrupar las propiedades en los objetos que correspondan. La solucin deseada es la siguiente:

Computadora: modeloTeclado, modeloMonitor, modeloGabinete, numeroDeSerieTeclado, numeroDeSerieMonitor, numeroDeSerieGabinete, temperaturaGabinete, puertosUSBDisponibles, puertosUSBEnUso.Monitor: modelo, numeroDeSerie.Teclado: modelo, numeroDeSerie.Gabinete: modelo, numeroDeSerie, temperatura, puertosUSBDisponibles, puertosUSBEnUso.

** Dijimos que el comportamiento de un objeto se define por medio de los mensajes que ste entiende y que para poder enviarle un mensaje a un objeto, hay que conocerlo. Hemos visto tambin que al enviarle un mensaje a un objeto, ste responde activando el mtodo asociado al mensaje, siempre y cuando ste exista. Tambin vimos que un mensaje es enviado a un objeto por otro objeto y como resultado del envo de un mensaje, siempre se retorna un objeto. El mtodo, es decir la implementacin, especifica qu hace el objeto receptor al recibir el mensaje. El mtodo no contiene otra cosa que una serie de mensajes enviados a otros objetos (slo hay objetos y mensajes). Recordemos tambin que los mtodos son privados al objeto y que los objetos slo pueden comunicarse mediante el envo de mensajes. Veamos en qu consiste la ejecucin de comportamiento ante el envo de un mensaje.

Mostrar la importancia de qu mensajes entiende un objeto y no cmo los realiza. Poder mostrar la modularidad y separacin que existe a la hora de programar en POO.** Por ejemplo, supongamos que contamos con un objeto que representa la torre de control de un aeropuerto. Si la torre desea avisar al avin LV-YPS que debe aterrizar, primero debe conocerlo. A su vez, si el avin LV-YPS desea comunicarse con la torre, tambin debe conocerla.* Cuando un objeto (emisor) le enva un mensaje a otro objeto (receptor), el objeto receptor responde activando el mtodo asociado a este mensaje, siempre que el mensaje recibido forme parte del protocolo del objeto receptor. Volviendo al ejemplo, cuando la torre enve el mensaje aterrizar al avin, ste activar un mtodo que contendr el procedimiento de aterrizaje. Podra suceder que el avin no conozca los procedimientos para aterrizar, es decir, podra no existir un mtodo que se corresponda con el mensaje aterrizar. Qu ocurre cuando un objeto no entiende un mensaje recibido? Esto depende del lenguaje: algunos lenguajes pueden evitar esta situacin mediante un sistema de tipos fuerte que chequee estas situaciones en tiempo de compilacin, mientras que otros brindan una mayor libertad en cuanto al envo de mensajes y responden, eventualmente, con un error en tiempo de ejecucin.

* Otro ejemplo de envo de mensajes, usando una versin simplificada del juego de rol.* * Siempre se debe contar con dos objetos para poder resolver el envo de un mensaje, uno cumpliendo el rol de emisor y otro el de receptor (eventualmente podra tratarse del mismo objeto cumpliendo los dos roles). El emisor enva un mensaje al receptor, en este caso el mensaje hacerAlgo. El receptor recibe el mensaje y busca entre sus mtodos aquel que coincida con el nombre del mensaje. Si encuentra el mtodo correspondiente, procede a ejecutarlo (en este caso el objeto receptor tiene un mtodo asociado al nombre hacerAlgo). La ejecucin del mtodo la veremos en detalle ms adelante, en este caso nos interesar saber que al finalizar la misma, el objeto receptor deber retornar un objeto como resultado del envo del mensaje, devolviendo nuevamente el control al objeto emisor.

* Cmo es la manera en que se especifica un mensaje? En primer lugar debemos asignarle un nombre, el mismo debe tener significado en el dominio del problema, esto es de vital importancia para el futuro entendimiento del sistema. Por otro lado, debemos indicar cules son los posibles objetos, u otro tipo de parmetro, requeridos para resolver el mensaje. Cada lenguaje de programacin propone una sintaxis particular para indicar el envo de un mensaje. A lo largo del curso utilizaremos la siguiente sintaxis:

. ();

Por ejemplo, decirle a una cuenta bancaria que deposite $100 se escribe como:

unaCuenta.depositar(100);

* Ejemplificar correctamente la diferencia entre mtodo y mensaje. Mostrar, si es necesario, el #dameCafe(), del ejemplo del juego de rol.** Veamos como ejemplo la implementacin del mtodo depositar del objeto caja de ahorro. El comentario nos indica de manera concisa en qu consiste la resolucin del comportamiento representado por el mtodo. En este caso la resolucin es muy sencilla: la variable de instancia saldo de la caja de ahorro se actualiza con el valor del parmetro unMonto.

* Este caso es muy similar, salvo que se reciben dos parmetros: el saldo y el nro. de cuenta. El cajero conoce al banco por medio de la variable de instancia banco, y lo que hace es delegar en dicho objeto la responsabilidad de buscar la caja de ahorro que corresponde al nro. de cuenta que viene como parmetro. Luego, una vez encontrada la caja de ahorro correspondiente, se le enva el mensaje depositar con el monto como parmetro.

* Ahora ser necesario especificar el mtodo saldo. El objeto caja de ahorro debe devolver su saldo actual como respuesta al envo del mensaje saldo, para lo cual necesitaremos un mecanismo que nos permita indicar cul es el resultado de evaluar un mtodo. Para tal fin contamos con una construccin sintctica especial, el smbolo flecha hacia arriba. El smbolo va seguido de cualquier objeto e indica que ese objeto ser retornado como resultado de la ejecucin del mtodo. La especificacin del mtodo saldo quedara de esta manera. Simplemente se indicara que se debe devolver el colaborador interno saldo, anteponiendo el smbolo al nombre de la variable de instancia que contiene el valor a retornar.

* Forma ms visual e intuitiva de los envos de mensajes en los objetos.*Cambio del objeto titular dentro de la caja de Ahorro* Este caso, en respuesta al mensaje titular(), esperamos obtener el titular de la caja de ahorro. Por lo tanto, cuando la caja de ahorro recibe el mensaje titular, activa el mtodo correspondiente y se retorna el objeto persona Juan Prez.

* Realizar el mtodo #extraer(unMonto), utilizando el mtodo #depositar(unMonto) como ejemplo*Modelar el proceso de extraccin de dinero de un cajero automtico identificando las principales entidades participantes y el conjunto de mensajes que los comunica. Para esto utilizaremos diagramas de secuencia UML.

*** El ocultamiento de la informacin es particularmente importante en la programacin orientada a objetos. Los objetos frecuentemente son complejas estructuras de datos con muchos componentes que no deben ser accedidas por los clientes. Existen algunas razones para tal encapsulamiento:- La representacin de un objeto est sujeta a cambios. Durante el desarrollo de una clase puede suceder que un conjunto diferente de variables de instancia resulte mejor con el propsito de la clase. Si los clientes acceden directamente a las variables de instancia, stos deben ser modificados para que queden consistentes con la nueva representacin.- En contraste con los registros en los programas convencionales, los objetos no son usados principalmente como contenedores cuyo nico objetivo es agrupar datos elementales. Ms bien, las variables de instancia del objeto son utilizadas para representar el estado del mismo. El objeto en si mismo es una entidad activa que puede llevar a cabo ciertas operaciones cuando le es requerido. Las variables de instancia pueden ser consideradas como variables auxiliares que son necesarias para realizar las operaciones.- Los objetos frecuentemente poseen otros objetos. La posesin es privada para el objeto; la relacin entre el objeto y los otros objetos que le pertenecen no debe ser alterada por los clientes.- Los objetos son accedidos mediante referencias polimrficas. Si un objeto es accedido a travs de una variable v, el objeto referenciado por v puede cambiar dinmicamente durante la ejecucin del programa y no podemos estar seguros si la variable v siempre har referencia a un objeto con la misma estructura interna.

* El encapsulamiento es una de las caractersticas fundamentales del paradigma y es uno de los puntos clave para que el software escale en forma suave y se adapte a los cambios. Idealmente, en cualquier sistema, intentamos que el acoplamiento entre las partes que lo componen sea lo ms bajo posible. Esto implica que cada parte sabe lo mnimo indispensable de las otras partes, lo que implica que los cambios en alguna de esas partes no impactan (o lo hacen en forma muy leve) en el resto de las partes del sistema. En un sistema OO las partes bsicas son los objetos, por lo que nos gustara que los cambios en un objeto impacten lo menos posible en el resto de los objetos que hacen al sistema. Uno de las formas de lograr esto es por medio de la separacin entre lo que es pblico de un objeto y lo que es privado. Desde el punto de vista mas puro del paradigma orientado a objetos un objeto se define por los servicios que puede brindar (o sea, por los mensajes que entiende). Luego, lo lgico es que estos mensajes sean la parte pblica del objeto. Por otro lado, la implementacin de estos mensajes (los mtodos, o sea cmo resuelve un requerimiento el objeto) no es algo que le importe al emisor del mensaje, por lo que debe ser privado del objeto que implementa el mtodo. De forma similar, tampoco tiene porque interesarle al resto de los objetos cul es la estructura interna de un determinado objeto ni con qu otros objetos ste tiene que colaborar para llevar a cabo sus responsabilidades. Todo lo que le importa al objeto emisor es cul es el mensaje que tiene que enviar, qu parmetros debe enviar y cual es la semntica asociada al envo del mensaje. El hecho de programar en trminos del protocolo de un objeto, sin saber nada de su estructura interna ni de cmo implementa sus mtodos, es lo que ayuda a mantener los cambios acotados, evitando que un cambio en un objeto se propague por todo el sistema. De aqu la relacin que nombramos anteriormente acerca de los mtodos y el encapsulamiento. Justamente es a travs de los mtodos que el objeto publica la nica manera de interactuar con l. Nada se podr hacer que no est provisto a travs del protocolo. * El mismo grfico que habamos visto anteriormente lo vemos ahora desde el punto de vista del encapsulamiento. Vemos que el titular de la caja de ahorro es slo conocido por la misma caja de ahorro y la nica forma de accederla es a travs del protocolo del objeto. Lo mismo ocurre con el saldo.

* Si pensamos nuevamente en el ejemplo del banco, es evidente que existirn varios objetos de tipo caja de ahorro, uno por cada caja de ahorro existente en el banco. Todos estos objetos debern tener el mismo comportamiento y es de esperar que si hay algn cambio en el comportamiento de las cajas de ahorro, el mismo se refleje por igual en todos los objetos de este tipo. Luego, es necesario contar con algn mecanismo que permita agrupar el comportamiento comn a un conjunto de objetos, de manera que pueda ser reutilizado sin tener que ser especificado individualmente. Por otro lado, el estado interno de cada caja de ahorro ser diferente (los saldos no sern los mismos por ejemplo) pero todas compartirn la misma estructura interna (todas conocen su saldo, titular, etc.). Desde el punto de vista de la reutilizacin, es as como surge la nocin de clase: como una herramienta que me permite factorizar y reutilizar estructura y comportamiento en comn. * Una clase nos permite describir en un slo lugar el comportamiento genrico de un conjunto de objetos. Una vez definido este comportamiento, es posible crear objetos que lo reutilicen y se comporten de la manera all descripta. Las clases nos permiten pensar en un nivel de abstraccin ms alto. Cuando construimos programas nos preguntamos constantemente: qu clases de objetos aparecen en mi sistema? Una clase entonces puede pensarse como un molde para un tipo especfico de objeto. Molde como medio para definir la forma de los objetos. Es natural clasificar objetos por determinadas caractersticas. En muchos casos nos encontramos en situaciones en las que un conjunto de objetos se comportan en forma similar y slo difieren en sus caractersticas bsicas o en los objetos con los que colabora. En estos casos es importante poder abstraer el comportamiento comn de los objetos y especificarlos en forma abstracta, de forma tal de modelar el concepto subyacente. Como definicin de clase se puede tomar la siguiente:

Una clase es una descripcin abstracta de un conjunto de objetos.

Las clases describen el formato de los objetos y agrupan comportamiento en comn. Una clase especifica qu forma tendrn sus instancias (sus variables de instancia) y cmo respondern a los mensajes que se le enven. De esta forma, una clase puede ser vista como una descripcin de sus instancias y como un repositorio de comportamiento. Cuando se le enva un mensaje a un objeto, lo que hace el intrprete es buscar en la clase del objeto receptor un mtodo con el cual responder al envo del mensaje. De sta forma, todos los objetos que comparten una misma clase responden en forma similar al envo de un mensaje. En el caso de la cuenta bancaria, dado que en un banco habr miles de cuentas, lo que hacemos es modelar la nocin de cuenta bancaria en una clase. Esta clase definir qu variables tendrn sus instancias, as como los mensajes a los que puede responder. En nuestro caso la clase se llamar CuentaBancaria, especificar que sus instancias tienen dos variables (saldo y titular) y que pueden responder a los mensajes saldo(), titular(), depositar(unMonto) y extraer(unMonto).* Sabemos que las clases son las encargadas de describir en forma abstracta a sus instancias, luego es lgico que si necesitamos crear una nueva instancia se lo pidamos a la clase. Por ese motivo, la clase tiene la responsabilidad de crear sus instancias. Volviendo al ejemplo de la cuenta bancaria, para crear una nueva cuenta bancaria lo que debemos hacer es pedirle a la clase CuentaBancaria que nos retorne una nueva instancia. Uno de los problemas ms comunes es la confusin entre clases e instancias. Es importante remarcar que una clase es un molde de estructura y comportamiento, as como la encargada de crear a sus instancias. Una vez que se crea una instancia, esta tiene sus propias variables. Por ejemplo, si creamos dos cuentas bancarias, cada una tendr su saldo y su titular. Lo nico que comparten es que ambas son instancia de la misma clase, lo que implica que al enviarles un mensaje, el mtodo que se activar se buscar en la clase CuentaBancaria, que es comn a las dos.* Contamos con una clase CajaDeAhorro, que define el comportamiento y la estructura comn a todas sus instancias. Una CajaDeAhorro sabr extraer(unMonto) de su saldo, depositar(unMonto) y devolver su saldo actual. Adems deber colaborar con un objeto que cumplir el rol de titular de la cuenta. Podemos ver en el ejemplo dos instancias de CajaDeAhorro, cada una con su propio estado interno. Eventualmente podran llegar a compartir el mismo titular de cuenta (un persona es titular de ambas cuentas) o bien tener el mismo saldo. Las dos instancias de la clase CajaDeAhorro comparten el mismo comportamiento, definido en la propia clase. De ahora en ms cuando queramos referirnos a un mtodo de una clase, lo haremos utilizando la siguiente sintaxis, por convencin:NombreDeClase>>mtodo(parmentro1, )Ejemplo:CajaDeAhorro>>depositar(unMonto)

saldo := saldo + unMonto

* Las clases se especifican por medio de un nombre, la estructura interna que tendrn sus instancias y los mensajes y mtodos asociados que definen su comportamiento. El nombre debe comenzar con mayscula y no contener espacios. Las variables de instancia representan el estado o estructura interna de las instancias de la clase. Por ltimo, se detalla el conjunto de mensajes que entender una instancia de dicha clase, tambin llamado protocolo. * Hasta el momento habamos visto que un objeto, ante le envo de un mensaje, buscaba entre sus mtodos aqul que correspondiera con el mensaje en cuestin para proceder con la activacin del mismo. Ahora que hemos introducido las clases como repositorio de comportamiento, la bsqueda del mtodo asociado a un mensaje ya no ser plena responsabilidad de las instancias, sino que este trabajo ser delegado a las clases. En el ejemplo podemos ver cmo el objeto unaCajaDeAhorro delega la bsqueda del mtodo a su clase (CajaDeAhorro) ante la recepcin del mensaje depositar(unMonto). La clase buscar entre su coleccin de mtodos aqul que corresponda con el mensaje depositar(unMonto) y se proceder a ejecutar el mtodo en el contexto del objeto receptor del mensaje (unaCajaDeAhorro).

* * Son las que ms hemos visto hasta el momento. Al definir la clase, se define la estructura que tendrn sus instancias; esta estructura interna viene dada por un conjunto de variables de instancia. Las variables de instancia acompaan al objeto desde su creacin hasta que muere.

** Se utilizan para nombrar objetos que el objeto receptor necesita para cumplir un requerimiento. Por ejemplo, para alquilar una pelcula a un cliente, el video club debe saber qu pelcula y qu cliente. En este caso la pelcula y el cliente son parmetros que se envan junto con el mensaje alquilar para poder cumplir el requerimiento.

* Para transferir de una cuenta a otra, el banco necesita el monto, y las dos cuentas.

* Se definen dentro de un mtodo. Estas variables se utilizan para nombrar objetos temporalmente. Al finalizar la activacin del mtodo dejan de existir.

* En este caso, la variable cuenta se utiliza slo como una referencia auxiliar. No es necesaria ms all de la activacin de este mtodo.

* As como un objeto necesita conocer a otro objeto para enviarle un mensaje, es necesario que tenga una forma de nombrarse a si mismo para poder enviarse mensajes. Esto se hace por medio de la seudo-variable this. Se dice que this es una seudo-variable ya que funciona similar a una variable de instancia, excepto por dos motivos: no est definida en ninguna clase y no pude ser asignada (qu significara hacer algo del estilo this := otherObject?). Si bien la denominacin this es la ms correcta para esta situacin de autoreferenciamiento, en el sentido de que representa al objeto en s mismo y la palabra concuerda con este hecho, existen otros lenguajes donde se ha dado una denominacin distinta para esta misma seudo-variable. * En este caso tenemos a un objeto caja de ahorro con un saldo inicial de 400 (de Juan) y otra con 300 (de Ana). Inicialmente la extraccin se hace sobre la caja de Juan, previo chequeo de ciertas condiciones (por ejemplo que el saldo no quede en descubierto), para lo cual se utiliza el mtodo sePuedeExtraer(unMonto) con el fin de realizar esta validacin. El objeto caja de ahorro deber poder mandarse a s mismo el mensaje sePuedeExtraer(unMonto) en el contexto de una extraccin y en el caso de resultar positivo el chequeo, proceder a realizar la extraccin actualizando su saldo, en caso contrario se obtendr un error. Esto queda reflejado en la especificacin del mtodo extraer(unMonto) perteneciente al objeto caja de ahorro. En este caso el objeto caja de ahorro hizo las veces de Emisor y Receptor para un mismo mensaje, pero como al Receptor no le interesa saber quin es el Emisor, es exactamente lo mismo si el mensaje ha sido enviado por otro objeto o por uno mismo, no se tratan de manera diferente. En el segundo caso, el objeto intenta hacer lo mismo con la caja de Ana, pero se aprecia que la operacin falla debido a que no tiene saldo suficiente.

* **Aqu se trata de definir qu es realmente UML. Tomar y pensar en las tres palabras por separado ayudan a la comprensin del objetivo de este lenguaje y al por qu de su utilidad:- Modelado: nos llevar a presentar la visin y concepcin de MODELOS.- Unificado: nos llevar a mencionar qu se unific en UML - Lenguaje: nos llevar a explicar que para cerrar esta Unificacin de Modelado era importante consensuar un Lenguaje; especificando su sintaxis y su semntica, indicando tambin reglas para conformar modelos grficos vlidos

*Se presenta la idea de modelo porque lo que se va a notar, utilizando UML, es justamente un modelo.Se presentan caractersticas y ventajas de los modelos.

*Booch, Rumbaug y Jacobson, son los creadores de UML, llamado inicialmente Lenguaje de Modelado.

El primer intento de combinar y reemplazar los mtodos existentes se di cuando Rumbaugh se uni a Booch en Rational Software Corporation en 1994.Ellos empezaron combinando conceptos de los mtodos OMT. La metodologa OMT - Object Modeling Technique - fue creada por James Rumbaugh mientras diriga un equipo de investigacin en los laboratorios de la Ca. General Electric) y Booch, obteniendo como resultado una primera propuesta en el ao 1995. En ese momento Jacobson tambin se uni a Rational y comenz a trabajar con el do Booch-Rumbaugh.

El Lenguaje Unificado de Modelado fue adoptado en forma unnime por los miembros de OMG como estndar en noviembre de 1997. All OMG asumi la responsabilidad de futuros desarrollos en el estndar de UML.

Nota:OMG (Object Management Group) es una organizacin que promueve estndares para la industria del software.Puede ampliar informacin en: www.omg.org

*Notar que hubo muchos otros aportes adems de lo propuesto por Rumbaugh, Booch y Jacobson.Todas estas contribuciones sumaron riqueza al lenguaje y graficamente se manifiestan en los diferentes tipos de diagramas que tiene UML.

Mencionar las ventajas buscadas y obtenidas con la unificacin de diferentes enfoques. Algunos de ellos son: Reunir los puntos fuertes de cada mtodo Idear nuevas mejoras Proporcionar estabilidad al mercado Eliminar ambigedad en los usuarios

*Es importante mencionar que la mayora de las personas somos naturalmente visuales. Eso explica por qu entendemos mejor y ms rpidamente un dibujo que parte de un texto.Es por ello que en el criterio de unificacin de las metodologas de modelado se concluy en un lenguaje grfico visual para la especificacin y construccin de modelos.

Aqu vale la pena detenerse en semntica y sintaxis.La sintaxis de UML determina la forma de los elementos bsicos sintcticos. Por ejemplo, un rectngulo con una divisin y nombre es una clase.La semntica de UML especifica el significado de cada elemento de modelado. Siguiendo con el ejemplo de la anterior, la semntica de la clase es la de denotar a un conjunto de objetos, instancias de la misma, que tienen la misma estructura y el mismo comportamiento.Las reglas de construccin o reglas de buena formacin determinan la forma en que los elementos pueden combinarse de manera de obtener modelos correctos. Por ejemplo, que las clases deben tener obligatoriamente un nombre; o que los nombres de los mensajes de una clase no pueden repetirse.

*El Lenguaje Unificado de Modelado se ha convertido en una notacin estndar para el modelado de sistemas con gran cantidad de software.UML sirve adems para el modelado de negocios y sistemas no software [OMG01].

Nota:Artefacto: es una pieza de informacin usada o producida por un proceso de desarrollo de software.*En UML 2.0 se definen una serie de diagramas adicionales a los establecidos en UML 1.x. Aqu se presentan todos los diagramas UML para que el asistente tenga una idea global de lo abarcado por el lenguaje.El conjunto de diagramas se encuentra organizado en torno a dos categoras: Diagramas Estructurales (representados en naranja).Diagramas Dinmicos o de Comportamiento (representados en azul).

Diferentes diagramas se utilizan durante diferentes etapas dentro del desarrollo de software. Se puede asociar como ejemplo alguna etapa con algn diagrama, por ejemplo, la etapa de Anlisis con los diagramas de Casos de Uso, de Actividad y de Estado.

Los diagramas a presentar a continuacin se corresponden con la etapa de Diseo (hay ms diagramas para esta etapa) son los de clases y los diagramas de secuencia.

*El objetivo de este diagrama es el de representar los objetos del sistema, especificando la estructura de las clases, sus relaciones y su comportamiento.Si bien el elemento de modelado que ser presentado es la CLASE, tambin pueden aparecer en el diagrama de Clases, las INTERFACES.Aparte de esos dos (y la nota), no hay otro elemento de modelado que pueda participar de este diagrama.

*Una clase es una plantilla que define una coleccin de conceptos con las mismas caractersticas. Estructura de una clase: Cada uno de los compartimientos es opcional, excepto el del nombre.Nombre de la clase: en la prctica, los nombres de clase son nombres cortos o expresiones nominales extrados del vocabulario del sistema que se est modelando. El nombre de la clase se escribe con mayscula, centrado y en negrita.Atributos: un atributo representa alguna propiedad del elemento que se est modelando Operaciones: son los mensajes que los objetos de la clase entiendenResponsabilidades: es un contrato o una obligacin de una clase. Se utiliza cuando an no se ha definido completamente el comportamiento de la clase, en una etapa previa al diseo.

*Diferenciar lo sintcticamente correcto de lo semnticamente correcto.En UML, lo indicado es que el nombre comience con letra mayscula. Por ej: X o Clase1.Segn el paradigma OO, el nombre de una clase debe ser lo ms representativa posible del concepto que modela. Por ejemplo: CuentaBancaria, TarjetaDeClienteVIP

Se muestran dos formas de escribir el nombre de una clase: escribiendo directamente su nombre y escribiendo su nombre precedido de su ubicacin (teatro es un paquete).

*UML ofrece una serie de elementos para especificar detalles para los atributos y las operaciones. Desde fuera de un objeto slo se puede manipular los datos por medio de llamadas a operaciones mtodos- del objeto.

Tipos de visibilidad: Privado: (-) significa que slo se puede usar en los objetos donde est definido el atributo u operacin.Protegido: (#) significa que slo los objetos de las subclases de la clase a la que pertenece el atributo u operacin pueden utilizarlo.Paquete: ( ) significa que slo los objetos del paquete en donde est definida la clase a la que pertenece el atributo u operacin pueden utilizarlo.Pblico: (+) significa que los objetos pertenecientes a cualquier clase puede utilizar el atributo u operacin.

No existe un valor por defecto para la visibilidad. Si sta no se indica, est indefinida.*Entre las relaciones que pueden aparecer en un diagrama de Clases, no se menciona aqu a la Realizacin.Una realizacin es una relaciona una interfaz con la clase que la implementa.

**Dada una asociacin entre dos clases, se puede navegar desde un objeto de una clase hasta un objeto de la otra clase, y viceversa. Es legal que ambos extremos de una asociacin estn conectados a la misma clase. Esto significa que, dado un objeto de la clase, se puede conectar con otros objetos de la misma clase.La navegabilidad en las asociaciones es bidireccional.

*Rol: cuando una clase participa en una asociacin, tiene un rol especfico que juega en la asociacin.Un rol es simplemente la cara que la clase de un extremo de la asociacin presenta a la clase del otro extremo. Se puede nombrar explcitamente el rol que juega una clase en una asociacin.Nota: la misma clase puede jugar el mismo o diferentes roles en otras asociaciones.

Navegabilidad: indica qu objeto conoce a quien. En el caso presentado, un usuario conoce una clave, pero una clave no conoce a un usuario.Si se quiere bidireccionalidad puede indicarse indistintamente con una flecha en cada punta de la asociacin o slo con la asociacin, sin flechas en los finales.

*Multiplicidad: el cuntos se denomina multiplicidad del rol de la asociacin, y se escribe como una expresin que se evala a un rango de valores o a un valor explcito.Cuando se indica una multiplicidad en un extremo de una asociacin, se est especificando que cada objeto de la clase conoce a tantos objetos como los indicados en la multiplicidad en este extremo opuesto.

Notar que * indica 0..**Una asociacin entre dos clases representa una relacin estructural entre iguales, es decir, ambas clases estn conceptualmente en el mismo nivel, sin ser ninguna ms importante que la otra.

Agregacin: sirve para modelar una relacin todo/parte, en la cual una clase representa el todo, que se compone de otros elementos (las partes). Este tipo de relacin se denomina agregacin, la cual representa una relacin del tipo tiene-un, o sea, un objeto del todo tiene objetos de la parte.

El rombo vaco distingue el todo de la parte. Esto significa que la agregacin simple no cambia el significado de la navegacin a travs de la asociacin entre el todo y sus partes, ni liga la existencia del todo y sus partes.*Las partes con multiplicidad no fija, se pueden crear despus del elemento compuesto. Pero una vez creadas, viven y mueren con l.

Notar que una parte siempre se asocia a un todo. NO PUDE PASAR que una parte (una instancia de Parte) se asocie a ms de un todo (una instancia de Todo).

Las palabras que mejor definen a este tipo de asociacin son:-exclusividad-dependencia

*Las composiciones a Punto indican que cualquier instancia de Punto puede estar en un Polgono o en un Crculo, pero no en ambos. Sin embargo, una instancia de Estilo puede ser compartida por muchos Polgonos y Crculos. Es ms, esto implica que el borrado de un Polgono provocara el borrado de sus Puntos asociados, pero no del Estilo asociado.Esta restriccin (un Punto puede solamente aparecer en un solo Polgono o Crculo a la vez) no se puede expresar mediante las multiplicidades, nicamente.

Sugerencia: comparar las diferencias entre composicin y agregacin en el ejemplo 1. sta puede estar claramente determinada por el contexto o dominio del problema a representar*Contexto:Nombre: Una asociacin puede tener un nombre, que se utiliza para describir la naturaleza de la relacin. Para que no haya ambigedad en su significado, se puede dar una direccin al nombre por medio de una flecha que apunte en la direccin en la que se pretende que se lea el nombre.Nota: aunque una asociacin puede tener un nombre, normalmente no se necesita incluirlo si se proporcionan explcitamente nombres de rol para la asociacin, excepto si se tiene un modelo con muchas asociaciones y es necesario referirse a una o distinguir unas de otras. Esto es esencialmente cierto cuando se tiene ms de una asociacin entre las mismas clases.*Muchas veces se omite escribir la multiplicidad en un extremo de la asociacin. En dicho caso se asume que la misma corresponde a 1.El modelador puede escribir explcitamente el nombre que juega una clase dentro de una asociacin. Pero si no lo hace, igualmente cada una de las clases juega un rol en la asociacin. Ese rol es el nombre de la clase en letras minsculas.*La generalizacin representa a la relacin es-un: un elemento concreto es-un elemento ms general. La generalizacin especifica que los objetos hijos se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la inversa. Una clase hija hereda las propiedades de sus clases padres (atributos, asociaciones y operaciones). A menudo, no siempre, el hijo aade atributos y operaciones a los que hereda de sus padres. Una operacin de un hijo con la misma signatura que una operacin del padre redefine la operacin del padre.Nota: Una generalizacin puede tener un nombre, aunque es raro que se necesiten los nombres, a menos que se tenga un modelo con muchas generalizaciones y haya que referirse a ellas o distinguirlas.En UML, una clase puede tener ninguno, uno o ms padres. Una clase sin padres y uno o ms hijos se denomina clase raz o clase base. Una clase sin hijos se llama clase hoja. Una clase con un nico padre se dice que utiliza herencia simple; una clase con ms de un padre se dice que utiliza herencia mltiple.*Una generalizacin simple, sin adornos, es suficiente para la mayora de las relaciones de herencia que aparecen en el modelado. Pero si se quieren especificar ciertos matices, UML aporta cuatro restricciones que pueden aplicarse a las generalizaciones.

Descripcin de las restricciones:complete: especifica que todos los hijos en la generalizacin se han especificado en el modelo (aunque puede que algunos se omitan en el diagrama) y no se permiten hijos adicionales.incomplete: especifica que no se han especificado todos los hijos en la generalizacin (incluso aunque se omitan algunos) y que se permiten hijos adicionales. Es la opcin por defecto.disjoint: especifica que los objetos del padre no pueden tener ms de uno de los hijos como tipo.overlapping: especifica que los objetos del padre pueden tener ms de uno de los hijos como tipo.Nota: disjoint y overlapping se aplican en el contexto de herencia mltiple.*Las notas permiten agregar comentarios que se pueden utilizar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo. Se marca por medio de lnea punteada al elemento al cual estn ligados y por lo tanto, comentan.El comentario puede hacerse en lenguaje coloquial o en un lenguaje formal como lo es OCL.Grficamente, una nota se representa como un rectngulo con una esquina doblada, junto con un comentario (no puede estar sin texto).****Contexto:

**