trabajo programacion

UNIVERSIDAD TECNOLOGICA LENGUAJE DE PROGRAMACION DEL PERU ORIENTADO A OBJETOS

UNIVERSIDAD TECNOLOGIA DEL PERU

CURSO:QUIMICA INDUSTRIAL I – CB 221U

PROFESOR: Petra Rondinel Pineda

INFORME N°01:PARADIGMA DE PROGRAMACION

ORIENTADO A OBJETOS Y HERENCIA

ALUMNO:

FECHA DE ENTREGA:

21 de setiembre del 2015

ÍNDICE

INTRODUCCION.............................................................................................3

1


TEMA 1 : DISEÑO DE DIAGRAMAS DE CLASES EN UML

Unified Modeling Language (UML)...........................................................5

Diagrama de clases......................................................................................5

Elementos de un diagrama de clases............................................................6

Clase....................................................................................................6

Atributos.............................................................................................6

Operaciones-Métodos.........................................................................7

Relaciones entre clases................................................................................7

Herencia..............................................................................................7

Agregación..........................................................................................8

Asociación...........................................................................................9

TEMA 2: ENCAPSULACION

Encapsulamiento........................................................................................11

Modificadores............................................................................................11

Constructores y destructores......................................................................13

Ejercicio desarrollado................................................................................13

TEMA 3: JERARQUIA DE CLASES

Jerarquia de clases.....................................................................................19

Herencia....................................................................................................17

CONCLUSIONES...........................................................................................22

BIBLIOGRAFIA.............................................................................................22

2


INTRODUCCIONUna exigencia de la gran mayoría de instituciones dentro de su Plan Informático estratégico, es que los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguaje estándar y unificado.

Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo software de diseño orientado a objetos, se visualice, especifique y documente con lenguaje común. Se necesitaba un lenguaje que fuese gráfico, a fin de especificar y documentar un sistema de software, de un modo estándar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notación estándar y semánticas esenciales, para el modelado de un sistema orientado a objetos.

En el presente trabajo tocamos 3 puntos importantes en el uso y funciones de UNIFIED MODELING LANGUAGE (UML)

1. Diseño de diagramas de clases en UML2. Encapsulación3. Jerarquía de clases

Conociendo estos conceptos nos van a permitir modelar un sistema orientado a objetos y su vital importancia radica en el desarrollo de software que formalicen y permitar realizar diagramas que nos permitirá visualizar un sistema de software

3


TEMA 1:TEMA 1:

DISEÑO DE DIAGRAMA DEDISEÑO DE DIAGRAMA DECLASES EN UMLCLASES EN UML

Unified Modeling Language (UML):

4


Es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente:

Diagramas de estructura enfatizan en los elementos que deben existir en el sistema modelado:

i. Diagrama de clases ii. Diagrama de componentes

iii. Diagrama de objetos iv. Diagrama de estructura compuesta (UML 2.0) v. Diagrama de despliegue

vi. Diagrama de paquetes

Diagramas de comportamiento enfatizan en lo que debe suceder en el sistema modelado:

i. 7. Diagrama de actividades ii. 8. Diagrama de casos de uso

iii. 9. Diagrama de estados

Diagramas de Interacción, un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

i. 10. Diagrama de secuencia ii. 11. Diagrama de comunicación

iii. 12. Diagrama de tiempos (UML 2.0) iv. 13. Diagrama de vista de interacción (UML 2.0)

Diagrama de clases:

Son diagramas de estructura estática que muestran las clases del sistema y sus interrelaciones (incluyendo herencia, agregación, asociación, etc.). Los diagramas de clase son el pilar básico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido (diseño). El diagrama de clases de más alto nivel, será lógicamente un dibujo de los paquetes que componen el sistema. Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de su propósito, sus objetos que intervienen en la relación y su opcionalidad (cuando un objeto es opcional el que intervenga en una relación). Elementos de un diagrama de clases:

5


1) Clase: Es la unidad básica que encapsula toda la información de un Objeto. Un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones: En donde:

Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica: Balance

Puede realizar las operaciones de: Depositar – Girar - Balance

Su diagrama será:

2) Atributos: Son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos serían: la marca, tamaño, color y peso.

Tipos de atributos:

public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden utilizar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

3) Operaciones-Métodos: Son aquellas actividades o verbos que se pueden realizar con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar,

6


cargar. El nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula.

Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

Tipos de métodos:

public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden utilizar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

A. Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Súper Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Súper Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehículo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio atributos como Descapotable no son visibles por ser privados.

7


B.

Agregación:

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto

incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente, en donde se destaca que:

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente.

8


La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.

C. Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas

muchas Órdenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicacion):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

9


TEMA 2:TEMA 2:

ENCAPSULAMIENTOENCAPSULAMIENTO

10


Encapsulamiento:Se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.De esta forma el usuario de la clase puede obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado se evita que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.

Modificadores de Acceso:

Se pueden establecer distintos niveles de encapsulación para los miembros de una clase (atributos y operaciones) en función n de desde dónde queremos que se pueda acceder a ellos:

Visibilidad Significado Java UML

PúblicaSe puede acceder al

miembro de la clase desde cualquier lugar

Public +

Protegida

Solo se puede acceder al miembro de la clase desde la propia clase o desde una

clase que herede de ella

Protected #

Por defecto

Se puede acceder a los miembros de una clase

desde cualquier clase en el mismo paquete

PrivadaSolo se puede acceder al

miembro de la clase desde la propia clase

Private -

11


La encapsulación permite agrupar datos y operaciones en un objeto, de tal forma los detalles del objeto se ocultan a sus usuarios (ocultamiento de información):

A un objeto se accede a través de sus métodos públicos (su interfaz), por lo que no es necesario conocer su implementación.

Para encapsular el estado de un objeto, sus atributos se declaran como variables de instancia privadas.

package economics;

public class Costes{

private double costeInicial; private double costeMarginal;…

}

Como consecuencia, se han de emplear métodos get para permitir que se pueda acceder al estado de un objeto:

public class Costes…

public double getCosteInicial (){

return costeInicial;}

public double getCosteMarginal (){

return costeMarginal;}

Si queremos permitir que se pueda modificar el estado de un objeto desde el exterior, implementaremos métodos set:

public class Costes…

public void setCosteInicial (double inicial){

this.costeInicial = inicial;}

public void setCosteMarginal (double marginal){

this.costeMarginal = marginal;}

OBSERVACIONES:12


Que los miembros de una clase sean privados quiere decir que no se puede acceder a ellos desde el exterior de la clase (ni siquiera desde sus propias subclases), lo que permite mantener la encapsulación de los objetos.

La visibilidad protegida relaja esta restricción ya que permite acceder a los miembros de una clase desde sus subclases.

No obstante, su uso tiende a crear jerarquías de clases fuertemente acopladas, algo que procuraremos evitar.

public class Figura{

protected double x; protected double y; protected Color color; protected Panel panel;…

}

public class Cuadrado extends Figura{

…/ Desde cualquier sitio de la implementación / de la clase Cuadrado se puede acceder a los / miembros protegidos de la clase Figura …

}

p.ej. Si tuviésemos que localizar un error que afectase al color de la figura no bastaría con examinar el có digo de la clase Figura. También tendríamos que analizar el uso que se hace del atributo color en todas las subclases de Figura.

Constructores y Destructores:

Son métodos que permiten establecer el estado inicial y final de un objeto. Los constructores se pueden definir con un conjunto de argumentos arbitrario, pero no pueden devolver nada. Y los destructores no pueden recibir ni devolver ningún valor.

El constructor debe llamarse igual que la clase, y el destructor el nombre de la clase precedido del carácter ~

Un constructor se ejecuta cuando se crea un nuevo objeto: 1) por declaración, ó 2) cuando se crea dinámicamente con el operador new. Un destructor se ejecuta cuando el objeto deja de existir: 1) porque su ámbito acaba, ó 2) cuando se libera explícitamente con el operador delete.

13


Imaginemos que se crea una clase, una docena de programadores tienen acceso a dicha clase y la utilizan a discreción, posteriormente dicha clase comienza a comportarse de una manera inesperada debido a que los valores que algunas variables han tomado no fueron anticipados y todo comienza a desmoronarse. Para corregir el problema se crea una versión más nueva de dicha clase y listo.

Bueno, a esto le llamamos flexibilidad y capacidad de mantenimiento, ambas son características y beneficios de la programación Orientada a Objetos (OO) pero para que una clase pueda cumplir dichas funciones los programadores debemos de hacer algo. Imaginemos que creamos una clase con variables de instancia públicas a las cuales podemos acceder sin problemas desde fuera de la misma clase...

Analizando el código anterior podemos darnos cuenta de que las variables enteras tipo y clase son públicas y pueden ser accedidas directamente a través de una instancia de la clase MiClase, esto compila sin ningún problema, digamos que es 'legal', sin embargo, ¿qué pasa si ingresamos un valor que no se supone debe de tener una variable (en este caso el -5 que le asignamos a tipo)?, simplemente no hay nada que nos detenga para hacerlo. La única manera de proteger el código es escribiendo un método que nos permita regular los valores que cada variable puede tener y escondiendo las variables para que no se pueda acceder a ellas de manera directa, esto es el principio básico de encapsulamiento.

Si se desea flexibilidad, buen mantenimiento y extensibilidad, nuestro diseño en el código debe de incluir encapsulamiento, para ello debemos de hacer lo siguiente:

1. Mantener las variables de instancia protegidas (puede ser con un modificador de acceso, p.ej., private).

2. Hacer métodos de acceso públicos para forzar al acceso a las variables por medio de dichos métodos en lugar de acceder directamente.

3. Utilizar las convenciones de código para los nombres de los métodos, p. ej., set y get.

14


El ejemplo anterior modificado para un buen encapsulamiento quedaría así:

Si nos fijamos un poquito, en el método setTipo() no existen validaciones para prevenir que un valor no válido sea asignado a la variable, sin embargo, el proveer de un método de este tipo desde el diseño inicial de la aplicación nos permite posteriormente modificar el comportamiento de la misma sin afectar los métodos utilizados, tal vez en un futuro se desee que dicha variable solamente pueda tener uno entre un rango de valores y se podrán aplicar posteriormente los cambios sin que haya repercusiones negativas.

15


TEMA 3:TEMA 3:

JERARQUIA DE CLASESJERARQUIA DE CLASES

JERARQUÍA DE CLASES16


Según el Dictionary of OT la jerarquía es “cualquier clasificación u ordenación de abstracciones en una estructura de árbol. Algunos tipos de Jerarquía son: Jerarquía de agregación, jerarquía de clases, jerarquía de herencia, jerarquía de partición, jerarquía de especialización, jerarquía de tipo. Éste concepto es sumamente importante ya que con ello conocemos la importancia de dividir los problemas en una jerarquía de ideas.

Los dos tipos importantes de jerarquía son: la de generalización/especialización y la de todo/parte.

La jerarquía de generalización/especialización se basa en que las propiedades de una categoría general se transmiten a todas las categorías que se especializan o subcategorías. En la OO, la jerarquía de clases significa un conjunto de clases relacionadas por la jerarquía de generalización/especialización.

A continuación se muestra un ejemplo en el que se describen tres figuras las cuales poseen diferentes niveles de jerarquía:

Consideremos las figuras planas cerradas como el rectángulo, y el círculo. Tales figuras comparten características comunes como es la posición de la figura, de su centro, y el área de la figura, aunque el procedimiento para calcular dicha área sea completamente distinto dependiendo del nivel de las clases. Podemos por tanto, diseñar una jerarquía de clases, tal que la clase base denominada Figura, tenga las características comunes y cada clase derivada las específicas. Como se muestra en el ejemplo cada figura tiene su nivel de jerarquía a continuación se explicará más detalladamente cada nivel.

La clase Figura es la que contiene las características comunes a dichas figuras concretas por tanto, no tiene forma ni tiene área. Esto lo expresamos declarando Figura como una clase abstracta, declarando la función miembro area abstract.

A. LAS CLASES ABSTRACTAS: Solamente se pueden usar como clases base para otras clases. No se pueden crear objetos pertenecientes a una clase abstracta. Sin embargo, se pueden declarar variables de dichas clases.

La característica de hacer una Clase/Método abstract reside en que no puede ser generada una instancia de la misma, este comportamiento se demuestra en el método principal (main). Como se muestra en las figuras cada clase tiene diferentes niveles, por decirlo así, de importancia de ahí se desprenden los términos de Superclase y Subclases.

17


SUPERCLASE Y SUBCLASE

2 Ejemplo

En éste segundo ejemplo podemos ver que al contrario del anterior del anterior, que de una subclase pueden desprenderse otras subclases lo que convierte a ésta Subclase en una Superclase:

A es la superclase de B, C y D. D es la superclase de E. B, C y D son subclases de A. E es una subclase de D.

Una de las características que no se pueden apreciar en éstas figuras es que cada Subclase obtiene “hereda”, características de su Clase Padre de aquí proviene el término de herencia que detallaré a continuación.

18

FIGURA

La clase “Padre” o Superclase se llama de ese modo debido a que de la misma se desprenden otras clases llamadas “Subclases” las cuales heredarán sus atributos y operaciones, una Superclase puede contener cualquier número de Subclases.

CIRCULO

La Clase Circulo es una de las Subclases de la Superclase Figura, ésta a su vez puede convertirse en una Superclase si de ella se desprenden otras clases. La misma posee su nivel de importancia y a su vez hereda los métodos y atributos de la superclase.


HERENCIA

Es una propiedad esencial de la Programación Orientada a Objetos que consiste en la creación de nuevas clases a partir de otras ya existentes éstas nuevas clases obtienen propiedades de sus clases padres, las cuales propagan sus atributos y operaciones a sus subclases. Las Subclases admiten la definición de nuevos atributos, así como crear, modificar o inhabilitar propiedades.

La herencia ofrece una ventaja importante, ya que permite la reutilización del código. Hay dos tipos de herencia las cuales son: Herencia Simple y Herencia Múltiple. La primera indica que se pueden definir nuevas clases solamente a partir de una clase inicial mientras que la segunda indica que se pueden definir nuevas clases a partir de dos o más clases iniciales. Java sólo permite herencia simple.

En la herencia los constructores no son heredados.

El termino Herencia ha sido tomado prestado de la Biología donde por ejemplo afirmamos que un niño tiene la cara de su padre, que ha heredado ciertas facetas físicas o del comportamiento de sus progenitores. Entre otras palabras son las diferentes características que comparten unas clases con las otras y así sucesivamente como se nos explica en el ejemplo de un hijo con su padre.

Ejemplo de Jerarquía:

Las Superclase definida con el nombre de Mamíferos Las Subclases se definen con los nombres: Coyote y Perro.

public class Mamifero

{ private String clase="Mammalia"; private String cientifname_clase="Animales Vertebrados"; private String reino="Animal";

19

MAMÍFEROS

COYOTE PERRO


private String taxonomia;

/*Taxonomia: Los mamíferos vivientes en la actualidad se pueden agrupar en dos sub clases las cuales son: Prototheria y Theria.

public Mamifero (String dar_Taxonomia)

{

/* En ésta parte se simula por ejemplo que el investigador después de haber investigado utiliza su software para indicar cual es la taxonomía de la especie por eso utiliza el constructor para inicializar esta variable y asignarle ésta característica*/

taxonomia=_dar_Taxonomia;}

// métodos get y set correspondientes//…

}

// Fin de la Clase

La clase Mamífero quedará definida de la siguiente manera:

class Coyote extends Mamifero{

// Éstas serán las nuevas variables que tendrá ésta clase además de los atributos y métodos heredadas de la clase Padre o Superclase.

20

- clase- cientifname_clase- reino- taxonomía

getclase (...)getreino(...)gettaxonomia(...)

MAMÍFERO


private String cientific_name="Canis Latrans";private String color;

public Coyote(String clase)

{ // El uso de la palabra “super” es importante ya que con ello es que le asignamos los atributos y métodos de la clase padre.

super(clase);

}

public String getcientificname()

{return(cientific_name);

}

Como se puede ver la Subclase Coyote hereda los atributos y métodos de

la Superclase Mamíferos. además ella posee “nuevos atributos” y

“métodos” diferentes a los de la clase Padre.

CONCLUSIONES:

Hoy en día, UML ("Unified Modeling Language") está consolidado como el lenguaje estándar en el análisis y diseño de sistemas de cómputo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir código.

21

- clase- cientifname_clase- reino- taxonomía- nacimiento- cientific_name- colorgetclase (...)

getreino(...)gettaxonomia(...)getcientificname(…)

COYOTE


El diseño de diagramas de clase en UML es muy importante debido a que:1) Posee características más visuales que programáticas, por lo cual facilita la comunicación entre los analistas y los interesados.2)Facilita el proceso de desarrollo del software para el programador, ya que anteriormente logró visualizar de manera gráfica lo que quiere plasmar en códigos, es más fácil traducir de este concepto visual que directamente.3)Facilita la documentación del sistema desarrollado, el cual debe pasar de igual forma por su proceso de QA.4) Determina la mejor manera de solucionar la situación propuesta (requerimientos --> sistema), ya que realizando el Diagrama de UML se puede visualizar de mejor manera las acciones que suelen repetirse, los objetos, clases, métodos, funciones, entre otros que son similares y de esta manera se acorta el tiempo de desarrollo y se pone en práctica la "reutilización", término muy bien visto en esta época de libre información - software libre y de programación orientada a objetos.

La importancia que vemos en la Jerarquía de es algo de suma importancia para la Programación orientada a objetos es que se asemeja mucho más a la realidad las clases que se crean. Es algo que facilita al programador, además de reducir el tiempo, un ejemplo es en la reutilización de código la cual ahorra tiempo al programar.

Para la utilización de la Jerarquía de clases, ya que nos brinda y ayuda a realizar un código mucho más fácil es indispensable su buena utilización ya que ayuda a manejar y dar un mejor mantenimiento debido a que se puede identificar más fácilmente las diferentes clases, y su nivel de Jerarquía.

Al crear una clase se debe tener presente las diferentes características que debe poseer la misma y cuales son los diferentes atributos y métodos que se van a crear puesto que la POO es una programación que pretende reducir al mínimo el nivel de dificultad de los códigos.

BIBLIOGRAFIA:

users.dcc.uchile.cl/~psalinas/uml/modelo.html https://docs.kde.org/trunk4/es/kdesdk/umbrello/uml-basics.html elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf www.usmp.edu.pe/publicaciones/boletin/fia/info67/UML.pdf http://profesores.fi-b.unam.mx/carlos/java/java_basico3_3.html http://es.scribd.com/doc/55839805/Encapsulamiento-UML-Diagrama-de-Clases-

java#scribd https://stringinarray.files.wordpress.com/2012/09/tema3.pdf www.sel.unsl.edu.ar/licenciatura/ingsoft2/ConceptosObjetos.pdf gl-epn-programacion-ii.blogspot.com/2010/.../constructor-y-destructor.htlm https://msdn.microsoft.com/es-es/library/bb972214.aspx www.ctr.unican.es/asignaturas/mc_oo/doc/m_estructural.pdf

22

https://msdn.microsoft.com/es-es/library/bb972214.aspx

http://www.sel.unsl.edu.ar/licenciatura/ingsoft2/ConceptosObjetos.pdf

https://stringinarray.files.wordpress.com/2012/09/tema3.pdf

http://es.scribd.com/doc/55839805/Encapsulamiento-UML-Diagrama-de-Clases-java#scribd

http://es.scribd.com/doc/55839805/Encapsulamiento-UML-Diagrama-de-Clases-java#scribd

http://profesores.fi-b.unam.mx/carlos/java/java_basico3_3.html

https://docs.kde.org/trunk4/es/kdesdk/umbrello/uml-basics.html

trabajo programacion

Documents