CARACTERSTICAS DEL MODELO ORIENTADO A OBJETOS 1.-ABSTRACCION: Denota las caractersticas esenciales de un objeto, donde se capturan sus comportamientos.

sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar. 2.-Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar la cohesin de los componentes del sistema. 3.-Modularidad: Propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), tan independiente como sea posible de la aplicacin en s y de las restantes partes. Estos mdulos se pueden compilar por separado, pero tienen conexiones con otros mdulos. 4.-PRINCIPIO DE OCULTACION Cada objeto est aislado del exterior, es un mdulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especfica cmo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. 5.-POLIMORFISMO Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en una referencia producir el comportamiento correcto para el tipo real del objeto referenciado. 6.-HERENCIA se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. 7.-RECOLECCION DE BASURA Garbage Collector es la tcnica por la cual el entorno de objetos se encarga de destruir automticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la

asignacin o liberacin de memoria, ya que el entorno la asignar al crear un nuevo objeto y la liberar cuando nadie lo est usando. En la mayora de los lenguajes hbridos que se extendieron para soportar el Paradigma de Programacin Orientada a Objetos como C++ u Object Pascal, esta caracterstica no existe y la memoria debe desasignarse manualmente. MODELO ORIENTADO A OBJETOS 8.-objetos Todo el programa est construido en base a diferentes componentes (Objetos) Todo objeto del mundo real tiene 2 componentes: caractersticas y comportamiento. 9.-clase Una clase es una plantilla genrica para un conjunto de objetos de similares caractersticas. 10.-envio de mensajes Los mensajes son invoaciones aq los mtodos de los objetos. 11.- Anlisis orientado a objetos El modelo del anlisis orientado a objetos ilustra informacin, funcionamiento y comportamiento. 12.- Diseo orientado a objetos El diseo orientado a objetos transforma el modelo del anlisis en un modelo de diseo que sirve como anteproyecto para la construccin de software. 13.- Modelos del diseo Estticos. Estructura de subsistemas y/o clases y sus relaciones. Dinmicos. Se describen las estructuras que muestran la interaccin entre objetos. Ejemplos de UML: diagramas de secuencia, diagramas de estado 14.- Patrones del diseo Son soluciones simples y elegantes a problemas especficos y comunes del diseo orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan. Tipos: de creacin, estructurales, de comportamiento. Metodos: 15.-El mtodo de Booch: este mtodo abarca un micro proceso de desarrollo y un macro proceso de desarrollo tanto para el anlisis como para el diseo. El nivel micro define un conjunto de tareas de anlisis que se reaplican en cada etapa en el macro proceso.

16.-El mtodo de Rumbaugh: Este mtodo mejor conocido como OMT, se utiliza para el anlisis, diseo del sistema y diseo a nivel de objetos.

17.-El mtodo de Jacobson: tambin llamado OOSE (que en espaol significa ingeniera del Software Orientada a Objetos este mtodo, en el anlisis, se diferencia de los otros por la importancia que da al caso de uso. Paso 1: Realizar un Diagrama de Casos de Uso. Hay que tener en cuenta que cada Caso de Uso representa una funcionalidad del software que vamos a construir. Paso 2: Priorizar los Casos de Uso a trabajar. Pongamos los casos de uso en una lista colocando los mas importantes al inicio y los menos importantes al final. Paso 3: Generar los Documentos de Caso de Uso. Ese documento debe ser generado por el Analista del proyecto y debe tener mas o menos la siguiente estructura: Descripcin Breve. Precondiciones. Flujo Bsico. Flujo Alternativo. PostCondiciones. Interfaz Grfica. Paso 4: Generar los Diagramas de Secuencia. Permiten conocer la forma en la que los objetos se comunicarn en una pantalla para cumplir su objetivo. Paso 5: Disear el FrameWorkdel proyecto. Esto significa que el Arquitecto de Software del proyecto har su trabajo, el cual consiste en disear las clases que se usarn en todo el Software. Paso 6: Creacin de la Base de Datos.

El diagrama de Clases de UML puede servir como Base para el diseo de la Base de Datos del proyecto, claro, solo utilizando la Capa de Datos, es decir, las clases de estereotipo Entidad.

Paso 7: Construir la mscara Mientras los pasos 4, 5 y 6 se estn realizando, el personal a cargo del Diseo del Sistema, pueden ir desarrollando las plantillas para la creacin del sistema. Paso 8: Programar las funcionalidades de los Casos de Uso. Trabajo de los programadores. Escribirn el cdigo necesario para que el caso de uso funcione. Paso 9: Probar los Requerimientos del Software. No deben ser hechos por las personas que programaron los Casos de Uso, es mucho mejor que lo haga otra persona. Paso 10: Integrar los requerimientos concluidos. Ahora si, ya es momento de unir lo que se hizo y ponerlo a disposicin de los usuarios. Diseo de clases

18.-Diagrama de Clases Muestran un conjunto de clases y sus relaciones

19.-Relaciones Las relaciones existentes entre las distinta clases nos indican cmo se comunican los objetos de esas clases entre s: Existen distintos tipos de relaciones: Asociacin

Una asociacin en general es una lnea que une dos o ms smbolos. Pueden tener varios tipos de adornos, que definen su semntica y caractersticas. Los tipos de asociaciones entre clases presentes en un diagrama esttico son: Asociacin binaria

Una asociacin binaria se representa mediante una lnea slida que une dos clases, se trata de una relacin entre las dos clases no muy fuerte, es decir, no se exige dependencia existencial ni encapsulamiento. Asociacin reflexiva Una asociacin binaria se representa mediante una lnea slida que recae sobre la misma clase de forma recursiva, se trata de una relacin no muy fuerte, es decir, no se exige dependencia existencial ni encapsulamiento. Asociacin n-aria Es una forma de expresar una relacin entre tres o ms clases. La clase de asociacin es dependiente en existencia de las otras clase Agregacin

Asociacin de agregacin

La agregacin representa una relacin dbil parte de entre objetos. En UML se proporciona una escasa caracterizacin de la agregacin. Esta relacin puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes. Es un tipo de relacin dbil, el objeto agregado puede existir de forma independiente. Las partes pueden forma parte de distintos agregados. Grficamente, se muestra con un rombo vaco en uno de los extremos. Asociacin de composicin

La composicin representa una relacin fuerte parte de entre objetos. En UML se proporciona una escasa caracterizacin de la composicin. Esta relacin puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto compuesto y cada uno de sus objetos componentes. Es un tipo de relacin fuerte, el objeto agregado no puede existir de forma independiente. Agregacin disjunta y estricta: Las partes slo existen asociadas al compuesto (slo se accede a ellas a travs del compuesto). Grficamente, se muestra con un rombo lleno en uno de los extremos (compuesto). Asociacin de dependencia Relacin (ms dbil que una relacin) que muestra la relacin entre un cliente y el proveedor de un servicio usado por el cliente: Cliente es el objeto que solicita un servicio.

Servidor es el objeto que provee el servicio solicitado.

Grficamente, la dependencia se muestra como una lnea discontinua con una punta de flecha que apunta del cliente al proveedor. Si un paquete A depende de un paquete B, entonces hay una o ms clases en el paquete A que inician comunicacin con una o ms clases pblicas del paquete B. Ejemplo: Un objeto de la clase A enva un mensaje a un objeto de la clase B. Un objeto de la clase A crea un objeto de la clase B. Un objeto de la clase A recibe un mensaje con un objeto de la clase B como argumento aun sin tenerlo como atributo.

Asociacin de generalizacin/especializacin

Permite gestionar la complejidad mediante un ordenamiento taxonmico de clases, se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin. La Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general. Los nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre estn disponibles en sus clases hijas. La Generalizacin y Especializacin son equivalentes en cuanto al resultado: la jerarqua y herencia establecidas. Generalizacin y Especializacin no son operaciones reflexivas ni simtricas pero s transitivas. La especializacin es una tcnica muy eficaz para la extensin y reutilizacin. Las subclases heredan caractersticas de las clases de las que se derivan y aaden caractersticas especficas que las diferencian. Navegacin de las asociaciones

Aunque las asociaciones suelen ser bidireccionales (se pueden recorrer en ambos sentidos), en ocasiones es deseable hacerlas unidireccionales (restringir su navegacin en un nico sentido). Grficamente, cuando la asociacin es unidireccional, la lnea termina en una punta de flecha que indica el sentido de la asociacin. Paquetes Definen contextos de denominacin para evitar colisin de nombres.

Sirven para definir bibliotecas de clases e interfaces (reutilizacin: no volver a inventar la rueda). Permiten organizar el cdigo de una gran aplicacin. Un paquete determina un subdirectorio del disco. Las declaraciones de los paquetes tienen que estar al principio de los ficheros fuente. Slo se permite la declaracin de un paquete en cada fichero fuente. Los nombres de los paquetes estn jerarquizados separados por puntos. La palabra reservada package debe aparecer en la primera lnea del fichero fuente. Por lo general el nombre de los elementos de un paquete es todo en minsculas. El nombre de las clases empieza en mayscula y la primera letra de cada palabra aadida al nombre tambin. Los paquetes pueden anidarse (define una jerarqua) paquete.subpaquete.subpaquete.clase

Convencin para el nombrado de paquetes (para conseguir nombres nicos): dominio.empresa.departamento.proyecto

La sentencia import Por defecto las clases slo se pueden comunicar con clases del mismo paquete donde se encuentran definidas. import permite acceder a una clase declarada en un paquete distinto del actual. Indica al compilador dnde encontrar las clases. Debe preceder a todas las declaraciones de las clases. Para importar clases de un paquete se usa el comando import. Se puede importar una clase individual: import java.util.Date ; o bien, se puede importar las clases declaradas pblicas de un paquete completo, utilizando un arterisco (*) para reemplazar los nombres de clase individuales: import java.util.* ; La sentencia import static (jdk 1.5)

Los miembros estticos (atributos o mtodos) de una clase pueden ser accedidos sin necesidad de una instancia previa de la misma. import static permite incorporar como propio cualquier miembro esttico; a nivel de bytes codes no existe relacin de uso, se libera la dependencia con la clase que define el miembro esttico. La importaciones pueden ser por miembro: import static java.lang.Math.pow ; O por clase: import static java.lang.Math.* ;