INSTITUTO TECNOLOGICO SUPERIOR DE CALKINI EN EL ESTADO DE CAMPECHE

INGENIERA EN SISTEMAS COMPUTACIONALES 4A

PROGRAMACION ORIENTADA A OBJETOS MASTER MIX Frase:

"Si le das a alguien un programa, lo frustrars un da. Si le enseas a programar, lo frustrars toda la vida."

ALUMN0S:
Ricardo de Jesus Can Couoh Jose Eduardo Cardenas Montero Miguel Angel Chan Cahum Amalti Melisa Lara Tzuc

MATRICULA
2975 2836 2995 2468

MAESTRO: Ing. Marlene Mndez Moreno

Trabajo Documental INDICE

Equipo Master Mix

Contenido
1. INTRODUCCION AL PARADIGMA DE LA PROGRAMACION ORIENTADA A OBJETOS ................... 2 1.1 ELEMENTOS DEL MODELO DE OBJETOS.................................................................................... 3 1.1.1 CLASES, OBJETOS, ABSTRACCIN, MODULARIDAD, ENCAPSULAMIENTO, HERENCIA Y POLIMORFISMO .............................................................................................................................. 6 1.1 LENGUAJE DE MODELADO UNIFICADO ..................................................................................... 8 1.1.2. DIAGRAMA DE CLASES. (UML) ............................................................................................ 11 PROGRAMA EN JAVA EN METODOLOGIA DE OREINTADA A OBJETOS ......................................... 17 PROGRAMA EN JAVA ESTRUCTURADO ......................................................................................... 19 BIBLIOGRAFIA: ............................................................................................................................... 20

Programacin Orientada a Objetos

Pgina 1

Trabajo Documental

Equipo Master Mix

1. INTRODUCCION AL PARADIGMA DE LA PROGRAMACION ORIENTADA A OBJETOS Historia de la Orientacin a Objetos La Orientacin a Objetos (O.O.) surge en Noruega en 1967 con un lenguaje llamado Simula 67, desarrollado por Krinsten Nygaard y Ole-Johan Dahl, en el centro de clculo noruego. Simula 67 introdujo por primera vez los conceptos de clases, corrutinas y subclases (conceptos muy similares a los lenguajes Orientados a Objetos de hoy en da). Uno de los problemas de inicio de los aos setentas era que pocos sistemas lograban terminarse, pocos se terminaban con los requisitos iniciales y no todos los que se terminaban cumpliendo con los requerimientos se usaban segn lo planificado. El problema consista en cmo adaptar el software a nuevos requerimientos imposibles de haber sido planificados inicialmente. Este alto grado de planificacin y previsin es contrario a la propia realidad. El hombre aprende y crea a travs de la experimentacin, no de la planeacin. La Orientacin a Objetos brinda estos mtodos de experimentacin, no exige la planificacin de un proyecto por completo antes de escribir la primer lnea de cdigo. En los 70s cientficos del centro de investigacin en Palo Alto Xerox (Xerox park) inventaron el lenguaje Small talk que dio respuesta al problema anterior (investigar no planificar). Small talk fue el primer lenguaje Orientado a Objetos puro de los lenguajes Orientados a Objetos, es decir, nicamente utiliza clases y objetos (Java usa tipos de datos primitivos, o bien los Wrappers que son clases que encapsulan tipos de datos primitivos). Hasta este momento uno de los defectos ms graves de la programacin es que las variables eran visibles desde cualquier parte del cdigo y podan ser modificadas incluyendo la posibilidad de cambiar su contenido (no existen niveles de usuarios o de seguridad, o lo que se conoce como visibilidad). Quien tuvo la idea fue D. Parnas cuando propuso la disciplina de ocultar la informacin. Su idea era encapsular cada una de las variables globales de la aplicacin en un solo mdulo junto con sus operaciones asociadas, slo mediante las cuales se poda tener acceso a esas variables.

Programacin Orientada a Objetos

Pgina 2

Trabajo Documental

Equipo Master Mix

El resto de los mdulos (objetos) podan acceder a las variables slo de forma indirecta mediante las operaciones diseadas para tal efecto. En los aos 80s Bjarne Stroustrup de AT&T Labs., ampli el lenguaje C para crear C++ que soporta la programacin Orientada a Objetos. En esta misma dcada se desarrollaron otros lenguajes Orientados a Objetos como Objective C, Common Lisp Object System (CIOS), object Pascal, Ada y otros. En el inicio de los 90s se consolida la Orientacin a Objetos como una de las mejores maneras para resolver problemas. Aumenta la necesidad de generar prototipos ms rpidamente (concepto RAD Rapid Aplication Developments). Sin esperar a que los requerimientos iniciales estn totalmente precisos. En 1996 surge un desarrollo llamado JAVA (extensin de C++). Su filosofa es aprovechar el software existente. Facilitar la adaptacin del mismo a otros usos diferentes a los originales sin necesidad de modificar el cdigo ya existente. En 1997-98 se desarrollan herramientas CASE orientadas a Actualmente la orientacin a objetos parece ser el mejor paradigma, no obstante, no es una solucin a todos los problemas. Trata de eliminar la crisis del software. Entre los creadores de metodologas orientadas a objetos se encuentran: G. Booch, Rambaught, Ivar Jacobson y Peter Cheng.

1.1 ELEMENTOS DEL MODELO DE OBJETOS Qu es la Orientacin a Objetos? Es una manera de pensar, otra manera de resolver un problema; lo ms reciente en metodologas de desarrollo de software. Es un proceso mental humano aterrizado en una computadora. Antes se adecuaba el usuario al entendimiento de la computadora. Actualmente, se le ensea a la computadora a entender el problema. La Orientacin a Objetos es un paradigma, es decir, es un modelo para aclarar algo o para explicarlo. La Orientacin a Objetos es el paradigma que mejora el diseo, desarrollo y mantenimiento del software ofreciendo una solucin a largo plazo a los problemas y preocupaciones que han existido desde el comienzo del desarrollo del software: La Orientacin a Objetos est basada en los tres mtodos de organizacin que utilizamos desde la infancia; entre un objeto y sus atributos (automvil > marca, color, nmero de llantas, etc.); Entre un objeto y sus componentes donde incluso otros objetos pueden formar parte de otros objetos (agregacin) (camin > motor, parabrisas, llantas); entre un objeto y su relacin con otros objetos (camin > vehculos automotores; una bicicleta no entrara en esta relacin). La metodologa del software orientado a objetos consiste en: Saber el espacio del problema Programacin Orientada a Objetos Pgina 3

Trabajo Documental Realizar una abstraccin Crear los objetos (espacio de la solucin) Instanciarlos (esto es, traerlos a la vida) Dejarlos vivir (ellos ya saben lo que tienen que hacer)

Equipo Master Mix

Cmo encontrar las clases a partir de un documento de requisitos1 Objetivos: - Complementar los conocimientos sobre bsqueda de clases a partir de un enunciado con algunos consejos y guas prcticas dictadas por autores prestigiosos en el campo de la programacin orientada a objetos. - Confeccionar un documento que sirva de gua prctica a la hora de enfrentarse a un problema que implique la bsqueda de clases. A. Identificacin de clases segn Coad y Yourdon Coad y Yourdon proponen seguir un mtodo que consta de dos etapas: primero buscar las clases candidatas y luego seleccionar de entre ellas las clases vlidas. Para identificar las clases de nuestro sistema, antes identificaremos un conjunto amplio de clases candidatas. Una clase ser considerada candidata, si en el documento de requisitos hay informacin sobre un concepto que se encuadra dentro de los siguientes criterios: Cosas o eventos a recordar: Cosas que el sistema debe recordar (fecha y hora de acceso de una persona a un edificio, operacin de compra con una tarjeta de crdito, etc.) Estructuras: Cuando del enunciado se deduce fcilmente una relacin de agregacin o generalizacin entre dos o ms conceptos, posiblemente estamos ante dos o ms clases candidatas. Otros sistemas: Con qu otros sistemas interacta el sistema en desarrollo? Muchas veces dichos sistemas necesitan interaccin desde nuestro sistema, y sern considerados clases. Dispositivos: Dispositivos que nuestro sistema necesita, siempre que estos sean externos al ordenador que albergar a nuestro sistema (sensores, brazo mecnico, barrera automtica, etc.). Roles: Administrador, alumno, profesor, etc. son diferentes roles que una persona puede desempear cuando inicia una sesin en el campus virtual de la universidad. Aunque una misma persona fsica que conozca tres combinaciones correctas usuario-clave puede conectarse de tres formas diferentes (diferente interfaz, etc.), no hay una clase persona, sino una por cada rol o papel que puede desempear una persona segn el tipo de sesin que inicie. Unidades organizacionales: Sucursal, sede, departamento, etc. siempre que haya que guardar informacin especfica al respecto. Es importante saber que utilizar este criterio por sistema (por ejemplo, siempre pensar en los departamentos de una empresa como clases) provoca errores en la mayora de los casos. Lugares, etc.: laboratorios, aulas, oficinas, etc. siempre, como antes se ha dicho, que haya que guardar informacin especfica al respecto. Un enunciado de un problema puede considerarse un documento de requisitos reducido y refinado. Programacin Orientada a Objetos Pgina 4

Trabajo Documental

Equipo Master Mix

La regla de oro es: Convertir en clase candidata todo aquel concepto del que haya que almacenar informacin en el sistema, bien a corto o a largo plazo. Despus, en un segundo paso, seleccionaremos aquellas clases que sean aplicables al dominio de nuestro problema. Para ello, una vez que hayamos seleccionado las clases candidatas, debemos escoger las que sean vlidas segn los siguientes criterios de filtrado: Necesidad de recordar: Las clases deben tener informacin asociada. Necesidad de comportamiento: Las clases deben tener operaciones. Una clase sin comportamiento Mltiples atributos: Las clases suelen tener ms de un atributo. Las clases que slo cuentan con un atributo son sospechosas de no ser clases, sino atributos de otras. Ms de una Objeto por Clase: Generalmente identificamos clases porque existe ms de un objeto de la misma. Es posible que una clase que slo tiene un objeto sea vlida, pero no es normal. Sospechar. Atributos y Servicios siempre aplicables: Todos los objetos de una clase deben tener los mismos atributos y operaciones. Si identificamos objetos de la misma clase con atributos y/o mtodos diferentes, pueden ser que en realidad exista ms de una clase, las cuales posteriormente relacionaremos mediante generalizacin. B. Formas de identificar las clases segn Meyer Segn Bertrand Meyer, No existe una receta milagrosa para identificar clases que pueda sustituir a la destreza individual o a la experiencia del propio desarrollador de aplicaciones. No obstante, propone las siguientes fuentes donde buscar clases: Documento de requisitos Trminos que aparezcan con frecuencia. Trminos a los cuales el texto dedica definiciones explcitas. Trminos que no estn definidos con precisin pero que se dan por sentado a lo largo de la presentacin. Discusin con los clientes y futuros usuarios Abstracciones importantes del dominio de la aplicacin. Jerga especfica del dominio de la aplicacin. Recordar que las clases que provienen del mundo exterior pueden describir tanto objetos conceptuales como objetos materiales. Literatura sobre algoritmos y estructuras de datos Estructuras de datos conocidas que soporten algoritmos eficientes. Discusiones con diseadores experimentados Clases de diseo que hayan sido utilizadas con xito en desarrollos previos de naturaleza similar.

Programacin Orientada a Objetos

Pgina 5

Trabajo Documental

Equipo Master Mix

1.1.1 CLASES, OBJETOS, ABSTRACCIN, MODULARIDAD, ENCAPSULAMIENTO, HERENCIA Y POLIMORFISMO Clases: define los atributos y comportamientos comunes que comparte un tipo de objeto. Las clases actan de una forma muy parecida a una plantilla o un molde para galletas, en el sentido de que una clase se utiliza para crear o instanciar objetos. Objeto: es la abstraccin de algo que forma parte del dominio del problema reflejando las posibilidades de un sistema para mantener la informacin sobre l. Representa una entidad real o abstracta con un papel bien definido dentro de nuestro mundo y con dos caractersticas que son sus atributos y su comportamiento. Ejemplos de objetos pueden ser un celular, lentes, pluma, computadora, pizarrn, perro, etc. Abstraccin: Es una especificacin del sistema que enfatiza sobre algunos de los detalles o propiedades del mismo mientras suprime a otros. Una buena abstraccin es aquella que enfatiza sobre detalles significativos al lector y al usuario y suprime detalles que son al menos por el momento irrelevantes o que causan distraccin. Existen cuatro tipos de abstracciones la primera es la abstraccin de entidades; este tipo de abstraccin representa una entidad ya sea del dominio del problema o del dominio de la solucin. El segundo tipo de abstraccin es la abstraccin de acciones, es la abstraccin de comportamiento, esta abstraccin proporciona un conjunto especializado de operaciones y todas ellas desempean funciones del mismo tipo. El tercer tipo de abstraccin es el de maquinas virtuales, este tipo de abstraccin agrupa operaciones virtuales utilizadas por un nivel superior de control u operaciones que utilicen un conjunto de operaciones de nivel inferior. Por ejemplo, una abstraccin que utilice el cdigo "x" cuando la aplicacin se ejecute en Latinoamrica, o utilice el cdigo "y" cuando se ejecute el Norteamrica. El ltimo tipo de abstraccin es el de coincidencia, que almacena un conjunto de operaciones que no tienen relacin entre s, esto es, toma actividades que aparentemente no tienen una relacin como las clases hombre (con mtodos como come(), camina(), etc.), las clases transporte areo (volar()) y ave (volar()) y creamos una subclase de hombre llamada superhombre que come(), camina() y vuela(); esto se logra tomando comportamientos que no tienen que ver entre s y no se atribuyen a la herencia sino a la interfaz. Padre Interfaz \ / Hijo Por definicin una interfaz es abstracta, por lo tanto no tiene un comportamiento, slo la declaracin de este.

Modularidad: Divide un sistema, de acuerdo a su complejidad, en varios subsistemas hasta cubrir toda la complejidad del sistema inicial. Cada subsistema toma una actividad muy bien definida y delimitada. Programacin Orientada a Objetos Pgina 6

Trabajo Documental

Equipo Master Mix

La modularidad basada en paquetes consiste en juntar clases con direccin o comportamiento en comn y juntarlas en un slo paquete. Por ejemplo para una GUI se pueden agrupar en un paquete los elementos: botones, listas de seleccin, etc. En un paquete de Base de Datos se pueden agrupar: base de datos, conexin, peticin, resultado de la BD, Query, etc. Modularidad segn varios autores: Liskov establece que la modularizacin consiste en dividir un programa en mdulos que pueden compilarse separadamente pero que tienen conexiones con otros mdulos. Parnas dice que la modularidad se da cuando los mdulos hacen suposiciones acerca de lo que los otros mdulos hacen Booch dice que la modularidad es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados. Encapsulamiento: Protege los atributos que conforman al objeto, y permite o niega informacin al publico. Encapsulamiento. Se consigue al ocultar informacin. Oculta todos los secretos de un objeto que no contribuyen a sus caractersticas esenciales, tpicamente la estructura de un objeto se encuentra oculta y la implantacin de sus mtodos es visible. Herencia: Polimorfismo: es una nueva caracterstica aportada por la OOP. Esta propiedad indica la posibilidad de definir varias operaciones con el mismo nombre, diferencindolas nicamente en los parmetros de entrada. Dependiendo del objeto que se introduzca como parmetro de entrada, se elegir automticamente cual de las operaciones se va a realizar.

Programacin Orientada a Objetos

Pgina 7

Trabajo Documental 1.1 LENGUAJE DE MODELADO UNIFICADO

Equipo Master Mix

Cualquier rama de ingeniera o arquitectura ha en-contrado til desde hace mucho tiempo la representa-cin de los diseos de forma grfica. Desde los inicios de la informtica se han estado utilizando distintas formas de representar los diseos de una forma ms bien personal o con algn modelo grfico. La falta de estandarizacin en la manera de representar grfica-mente un modelo impeda que los diseos grficos realizados se pudieran compartir fcilmente entre distintos diseadores.

Se necesitaba por tanto un lenguaje no slo para comunicar las ideas a otros desarrolladores sino tambin para servir de apoyo en los procesos de anlisis de un problema. Con este objetivo se cre el Lenguaje Unificado de Modelado (UML: Unified Modeling Lan-guage). UML se ha convertido en ese estndar tan ansiado para representar y modelar la informacin con la que se trabaja en las fases de anlisis y, especialmente, de diseo. El lenguaje UML tiene una notacin grfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informtico: desde el anlisis con los casos de uso, el diseo con los diagramas de clases, objetos, etc., hasta la implementacin y configuracin con los diagramas de des-pliegue.

Historia de UML El lenguaje UML comenz a gestarse en octubre de 1994 [1], cuando Rumbaugh se uni a la compaa Rational fundada por Booch (dos reputados investiga-dores en el rea de metodologa del software). El ob-jetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo Booch y el OMT (Object Mode-lling Tool ). El primer borrador apareci en octubre de 1995. En esa misma poca otro reputado investigador, Jacobson, se uni a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los tres amigos. Adems, este lenguaje se abri a la colabora-cin de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definicin de la primera versin de UML. Qu es UML?

El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesin de una serie de mtodos de anlisis y diseo orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un mtodo. Los mtodos consisten de ambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de la orientacin a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementa la capacidad de lo que se puede hacer con otros mtodos de anlisis y diseo orientados a objetos. Los autores de UML apuntaron tambin al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.

Programacin Orientada a Objetos

Pgina 8

Trabajo Documental

Equipo Master Mix

El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo. La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicacin que requieren todos los agentes involucrados en un proyecto informtico. Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje de modelado y no as el proceso que se sigui para obtenerlo.

Una de la metas principales de UML es avanzar en el estado de la integracin institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de informacin entre herramientas, se requiri definir a UML una semntica y una notacin. La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociacin y una multiplicidad. Y qu significa exactamente una asociacin o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notacin). Para que un proveedor diga que cumple con UML debe cubrir con la semntica y con la notacin. Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definicin una herramienta que solo dibuje, no puede cumplir con la notacin de UML. El lenguaje est dotado de mltiples herramientas para lograr la especificacin determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:
Programacin Orientada a Objetos Pgina 9

Trabajo Documental

Equipo Master Mix

Los diagramas de clases de UML forman la vista lgica. Los diagramas de interaccin de UML constituyen la vista de proceso. La vista de desarrollo captura el software en su entorno de desarrollo. Los diagramas de despliegue integran la vista fsica . Los escenarios: el modelo de casos de uso.

Modelamiento de Clases Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de acontecimiento.

Programacin Orientada a Objetos

Pgina 10

Trabajo Documental 1.1.2. DIAGRAMA DE CLASES. (UML)

Equipo Master Mix

El lenguaje UML (en ingls, Unified Modeling Language) es un lenguaje para la especificacin, visualizacin, construccin y documentacin de las partes de un sistema de software. Consiste en una coleccin de las mejores prcticas de ingeniera que mostraron ser exitosas en el modelamiento de sistemas complejos, a tal punto que muchas empresas estn actualmente incorporando UML para el desarrollo de sus productos. Fu creado en 1996, por el Object Mangement Group1 con sucesivas modificaciones y agregados para permitir mayor funcionalidad, gracias al aporte y la participacin de empresas como IBM, Hewlett Packard, Microsoft, Unisys y Oracle, entre otras.

UML es un lenguaje predominantemente visual, que consiste de varios diagramas, cada uno modelando un parte esencial del sistema a construir. La especificacin completa de UML incluye doce diagramas, divididos en tres categoras. Cuatro diagramas son utilizados para representar la estructura esttica de la aplicacin en desarrollo, cinco diagramas representan diferentes aspectos del comportamiento dinmico y tres representan la forma en que se organizan los mdulos de la aplicacin. Nos centraremos aqu nicamente en el Diagrama de Clases, el cual nos permite disear la estructura del programa en funcin de las clases que lo componen. Anlisis orientado a objetos. Durante el anlisis OO las clases y objetos se derivan usualmente de los siguientes conceptos: Cosas tangibles (autos, sensores, ?) Papeles que representan (madre, profesor, ?) Eventos que ocurren (aterrizaje, peticin,? ) Interaccin (prstamos, encuentro, ?) Organizaciones (UAM, ONU, ?) Conceptos (negociacin, comunicacin, ?) Convencin para signar nombres a los objetos y clases: Objeto. Sustantivo (el sensor, un slido, ?) Clase. Nombre comn (sensores, slidos, ?) Operaciones que modifican. Verbos activos (dibujar, mover, ?) Operaciones de seleccin. Preguntas (esta abierto? ?) Mecanismos de interaccin. Determinan de qu manera interactan las instancias de las clases. La definicin de los mecanismos es una decisin estratgica en el diseo de un sistema. Nota: Es importante no perder de vista el diagrama de jerarquas. Mtodo de diseo. Para especificar el diseo de un sistema complejo es necesario especificar la estructura esttica (clases, objetos, mdulos, procesos), y la dinmica del sistema (transicin de estados, tiempo). Especificacin Esttica.

Diagrama de procesos. Especificacin Dinmica. Diagrama de transicin de estados. (ntimamente relacionado con instancias)

Programacin Orientada a Objetos

Pgina 11

Trabajo Documental
Diagrama de tiempo. Diagrama de Clases. Se usa para mostrar la existencia de clases y las relaciones entre ellas.

Equipo Master Mix

Categoras de Clases. Cuando un sistema incluye muchsimas clases, es importante agrupar las clases en categoras y hacer diagramas de las mismas.

Cuando una categora de clase es visible para las dems, se recomienda anotar la palabra "global" en la esquina izquierda del recuadro. Ejemplo.

Aqu implica que todo lo que esta dentro de la clase "polica" es pblico, i.e. podramos crear un nuevo objeto de nombre "Polica Federal de Caminos", que heredara las propiedades bsicas de "polica", pero se le agregaran nuevas caractersticas a la nueva categora. Esquemas de Clases. Para complementar la informacin de los diagramas de clases, es importante incluir la documentacin o esquema de clases. De manera general podemos incluir: Nombre: identificador de la clase. Descripcin: texto. Jerarqua: Superclases: lista de nombres de clases. Metaclase: nombre de clase. Parmetros: lista de parmetros. Interfaz: (pblico, protegido, privado). *Usa: Lista de nombres de clases.

Programacin Orientada a Objetos

Pgina 12

Trabajo Documental
*Campos: lista de declaraciones.

Equipo Master Mix

Esquema de Operaciones. En fases avanzadas del diseo se requiere de una definicin ms precisa de las operaciones que forman parte de la clase. Nombre: Identificador Descripcin: Texto Categora: Nombre Parmetros formales: Lista Resultado: lista Acciones: lista Excepciones: lista de declaraciones Concurrencia: secuencial / paralelo. Hint: Es muy importante ir trabajando y documentando nuestro programa. No dejar a ultima hora. Diagramas de transicin de estados. Se usan para mostrar el estado de una instancia de una clase dada, los eventos que causan una transicin de un estado a otro y las acciones que resultan del cambio de estado.

Ejemplo. Proceso de inscripcin a la maestra. Diagrama de objetos. Las clases son estticas, mientras que los objetos son dinmicos. Los diagramas de objetos reflejan las interacciones dinmicas entre objetos relacionados con el envo de mensajes.

Programacin Orientada a Objetos

Pgina 13

Trabajo Documental

Equipo Master Mix

Esquemas de objetos y mensajes.

Documentacin para el diseo de objetos. Diagrama de tiempos. Un diagrama de tiempo es una grfica de tiempo contra los objetos involucrados en la interaccin. Ejemplo.

Proceso de diseo orientado a objetos ( OOP) Es interactivo e incremental. Se compone por las siguientes actividades. 1. Identificar clases y objetos. 2. Identificar la semntica de clases y objetos. 3. Identificar interrelaciones de clases y objetos. 4. Implementar clases y objetos. Identificar clases y objetos. Se descubren las abstracciones de clases y objetos. Se les asignan nombres significativos. Se dibujan los diagramas de clases y objetos.

Programacin Orientada a Objetos

Pgina 14

Trabajo Documental
Identificar la semntica de las clases y objetos.

Equipo Master Mix

Se establece el significado de las clases y objetos. Se trabaja sobre el refinamiento de las interfaces de las clases y sobre las acciones que pueden hacer sus objetos. Identificar interrelaciones de clases y objetos. Establecer exactamente como interactan las cosas dentro del sistema. Se establecen las relaciones de uso, herencia y otras. Se refinan los diagramas de los pasos anteriores. Implementar clases y objetos. Buscar una representacin de clases y objetos. Alojar las clases y objetos en mdulos, y los programas y procesos. Implementar las clases y objetos en un lenguaje OO. Ejemplo de un diagrama de clases.

(**) Restriccin: Si pedido. cliente. calificacin. crdito es "pobre", entonces pedido: prepagado debe ser verdadero.

Se vale que algunas clases no incluyan mtodos o variables de instancia. UML Booch Clase Clase Asociacin Uso Generalizacin Hereda Agregacin Contiene

Otro ejemplo:

Programacin Orientada a Objetos

Pgina 15

Trabajo Documental

Equipo Master Mix

Ahora vamos a aplicarlo al ejemplo que hemos venido desarrollando.

Programacin Orientada a Objetos

Pgina 16

Trabajo Documental

Equipo Master Mix

PROGRAMA EN JAVA EN METODOLOGIA DE OREINTADA A OBJETOS Este programa lee una oracin y te indica cuantas vocales hay ejemplo: MASTER MIX Total de a: 1 Total de e: 2 Total de i: 2 Total de o: 1 Total de u: 1 public class Vocales{ //atributos String frase; //variables char cadena[]; String fr; int contadorA=0,contadorE=0,contadorI=0,contadorO=0,contadorU=0; public void setfrase(String frase){ fr=frase; } public String getfrase(){ return fr; } public void Contar_Vocales(){ cadena=getfrase().toCharArray(); for(int i=0;i<cadena.length;i++){ //System.out.print(cadena[i]); if((cadena[i]=='a') ||(cadena[i]=='A')){ contadorA++; } if((cadena[i]=='e') ||(cadena[i]=='E')){ contadorE++; } if((cadena[i]=='i') ||(cadena[i]=='I')){ contadorI++; } if((cadena[i]=='o') ||(cadena[i]=='O')){ contadorO++; } if((cadena[i]=='u') ||(cadena[i]=='U')){ Programacin Orientada a Objetos Pgina 17

Trabajo Documental contadorU++; } } System.out.println("Total de a:" +contadorA); System.out.println("Total de e:" +contadorE); System.out.println("Total de i:" +contadorI); System.out.println("Total de o:" +contadorO); System.out.println("Total de u:" +contadorU); } public static void main(String arg[]){ Vocales voc =new Vocales(); voc.setfrase("EQUIPO MASTER MIX"); voc.Contar_Vocales(); } }

Equipo Master Mix

Programacin Orientada a Objetos

Pgina 18

Trabajo Documental PROGRAMA EN JAVA ESTRUCTURADO public class VocalesEstructurado{

Equipo Master Mix

public static void main(String arg[]){ String frase; char cadena[]; int contadorA=0,contadorE=0,contadorI=0,contadorO=0,contadorU=0; frase = " EQUIPO MASTER MIX "; System.out.println("la frase es: " +frase); cadena=frase.toCharArray(); for(int i=0;i<cadena.length;i++){ //System.out.print(cadena[i]); if((cadena[i]=='a') ||(cadena[i]=='A')){ contadorA++; } if((cadena[i]=='e') ||(cadena[i]=='E')){ contadorE++; } if((cadena[i]=='i') ||(cadena[i]=='I')){ contadorI++; } if((cadena[i]=='o') ||(cadena[i]=='O')){ contadorO++; } if((cadena[i]=='u') ||(cadena[i]=='U')){ contadorU++; } } System.out.println("Total de a:" +contadorA); System.out.println("Total de e:" +contadorE); System.out.println("Total de i:" +contadorI); System.out.println("Total de o:" +contadorO); System.out.println("Total de u:" +contadorU); } }

Programacin Orientada a Objetos

Pgina 19

Trabajo Documental BIBLIOGRAFIA:

Equipo Master Mix

http://capacinet.gob.mx/Cursos/Tecnologia%20amiga/desarrolladordesoftware /POO_SE.pdf http://elvex.ugr.es/decsai/builder/intro/5.html http://www.disca.upv.es/enheror/pdf/ActaUML.PDF http://www.docirs.cl/uml.htm

Programacin Orientada a Objetos

Pgina 20