1. ¿Que son objetos ?
Entender que es un objeto es la clave para entender cualquier lenguaje orientado a objetos.
Existen muchas definiciones que se le ha dado al Objeto. Primero empecemos entendiendo que es un objeto del mundo real. Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor. Digamos que para leer este artículo lo hacemos a través del monitor y una computadora, ambos son objetos, al igual que nuestro teléfono celular, un árbol o un automóvil.
Analicemos un poco más a un objeto del mundo real, como la computadora. No necesitamos ser expertos en hardware para saber que una computadora está compuesta internamente por varios componentes: la tarjeta madre, el chip del procesador, un disco duro, una tarjeta de video, y otras partes más. El trabajo en conjunto de todos estos componentes hace operar a una computadora.
Internamente, cada uno de estos componentes puede ser sumamente complicado y puede ser fabricado por diversas compañías con diversos métodos de diseño. Pero nosotros no necesitamos saber cómo trabajan cada uno de estos componentes, como saber que hace cada uno de los chips de la tarjeta madre, o cómo funciona internamente el procesador. Cada componente es una unidad autónoma, y todo lo que necesitamos saber de adentro es cómo interactúan entre sí los componentes, saber por ejemplo si el procesador y las memorias son compatibles con la tarjeta madre, o conocer donde se coloca la tarjeta de video. Cuando conocemos como interaccionan los componentes entre sí, podremos armar fácilmente una computadora.
Entender que es un objeto es la clave para entender cualquier lenguaje orientado a objetos.
Existen muchas definiciones que se le ha dado al Objeto. Primero empecemos entendiendo que es un objeto del mundo real. Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor. Digamos que para leer este artículo lo hacemos a través del monitor y una computadora, ambos son objetos, al igual que nuestro teléfono celular, un árbol o un automóvil.
Analicemos un poco más a un objeto del mundo real, como la computadora. No necesitamos ser expertos en hardware para saber que una computadora está compuesta internamente por varios componentes: la tarjeta madre, el chip del procesador, un disco duro, una tarjeta de video, y otras partes más. El trabajo en conjunto de todos estos componentes hace operar a una computadora.
Internamente, cada uno de estos componentes puede ser sumamente complicado y puede ser fabricado por diversas compañías con diversos métodos de diseño. Pero nosotros no necesitamos saber cómo trabajan cada uno de estos componentes, como saber que hace cada uno de los chips de la tarjeta madre, o cómo funciona internamente el procesador. Cada componente es una unidad autónoma, y todo lo que necesitamos saber de adentro es cómo interactúan entre sí los componentes, saber por ejemplo si el procesador y las memorias son compatibles con la tarjeta madre, o conocer donde se coloca la tarjeta de video. Cuando conocemos como interaccionan los componentes entre sí, podremos armar fácilmente una computadora.
¿Que tiene que ver esto con la programación?
La programación orientada a objetos trabaja de esta manera. Todo el programa está construido en base a diferentes componentes (Objetos), cada uno tiene un rol específico en el programa y todos los componentes pueden comunicarse entre ellos de formas predefinidas.
Todo objeto del mundo real tiene 2 componentes: características y comportamiento.
Todo objeto del mundo real tiene 2 componentes: características y comportamiento.
Por ejemplo, los automóviles tienen características (marca, modelo, color, velocidad máxima, etc.) y comportamiento (frenar, acelerar, retroceder, llenar combustible, cambiar llantas, etc.).
Los Objetos de Software, al igual que los objetos del mundo real, también tienen características y comportamientos. Un objeto de software mantiene sus características en una o más "variables", e implementa su comportamiento con "métodos". Un método es una función o subrutina asociada a un objeto.

Para redondear estas ideas, imaginemos que tenemos estacionado en nuestra cochera un Ford Focus color azul que corre hasta 260 km/h. Si pasamos ese objeto del mundo real al mundo del software, tendremos un objeto Automóvil con sus características predeterminadas:

Para redondear estas ideas, imaginemos que tenemos estacionado en nuestra cochera un Ford Focus color azul que corre hasta 260 km/h. Si pasamos ese objeto del mundo real al mundo del software, tendremos un objeto Automóvil con sus características predeterminadas:
Marca frdModelo
FocusColor = AzulVelocidad
Máxima = 260 km/h
Cuando a las características del objeto le ponemos valores decimos que el objeto tiene estados. Las variables almacenan los estados de un objeto en un determinado momento.
Definición teórica: Un objeto es una unidad de código compuesto de variables y métodos relacionados.
2.ejemplo de objet
Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase.
3.CLASES
Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término “tipo” en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.
En ¨, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos “compartimentos” dentro del rectángulo
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 UML, una clase es representada por un rectángulo que posee tres divisiones
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).
Balance:
Puede realizar las operaciones de:
Depositar
Girar
y Balance
Girar
y Balance
El diseño asociado es:
Atributos y Métodos:
Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:
public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).
protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ccesado por métodos de la clase además de las subclases que se deriven (ver herencia).
Métodos:
Métodos:
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:
public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos
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 accesar).
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).
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 accesar).
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).
Dependencias
Es una relación de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua va desde la clase utilizadora a la clase utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede afectar al funcionamiento de la clase utilizadora, pero no al contrario. Aunque las dependencias se pueden crear tal cual, es decir sin ningún estereotipo (palabreja que aparece al lado de la línea que representa la dependencia) UML permite dar mas significado a las dependencias, es decir concretar mas, mediante el uso de estereotipos.
Estereotipos de relación Clase-objeto.
Bind: La clase utilizada es una plantilla, y necesita de parámetros para ser utilizada, con Bind se indica que la clase se instancia con los parámetros pasándole datos reales para sus parámetros.
Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento.
Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir podrá ver las interioridades de la clase destino.
InstanceOF: Indica que el objeto origen es una instancia del destino.
Instantiate: indica que el origen crea instancias del destino.
Powertype: indica que el destino es un contenedor de objetos del origen, o de sus hijos.
Refine: se utiliza para indicar que una clase es la misma que otra, pero mas refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
Estereotipos de relación Clase-objeto.
Bind: La clase utilizada es una plantilla, y necesita de parámetros para ser utilizada, con Bind se indica que la clase se instancia con los parámetros pasándole datos reales para sus parámetros.
Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento.
Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir podrá ver las interioridades de la clase destino.
InstanceOF: Indica que el objeto origen es una instancia del destino.
Instantiate: indica que el origen crea instancias del destino.
Powertype: indica que el destino es un contenedor de objetos del origen, o de sus hijos.
Refine: se utiliza para indicar que una clase es la misma que otra, pero mas refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
Generalizacion
Pues es la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. UML soporta tanto herencia simple como herencia múltiple. Aunque la representación común es suficiente en el 99.73% de los casos UML nos permite modificar la relación de Generalización con un estereotipo y dos restricciones.
Estereotipo de generalización.
Implementation: El hijo hereda la implementación del padre, sin publicar ni soportar sus interfaces.
Restricciones de generalización.
Estereotipo de generalización.
Implementation: El hijo hereda la implementación del padre, sin publicar ni soportar sus interfaces.
Restricciones de generalización.
Complete: La generalización ya no permite mas hijos
Incomplete: Podemos incorporar mas hijos a la generalización.
Disjoint: solo puede tener un tipo en tiempo de ejecución, una instancia del padre solo podrá ser de un tipo de hijo.
Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.
Disjoint: solo puede tener un tipo en tiempo de ejecución, una instancia del padre solo podrá ser de un tipo de hijo.
Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.
Asociación
Especifica que los objetos de una clase están relacionados con los elementos de otra clase. Se
representa mediante una línea continua, que une las dos clases. Podemos indicar el nombre,
representa mediante una línea continua, que une las dos clases. Podemos indicar el nombre,
multiplicidad en los extremos, su rol, y agregación
4. Representacion de clases de UML
Representación visual de una asociación en UML
Representación visual de una asociación en UML
Representación visual de una relación de acumulación en UML
5. DIAGRAMA DE CLASES
Un diagrama de Clases representa las clases que serán utilizadas dentro del sistema y las relaciones que existen entre ellas.
Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí, no lo que ocurre cuando.
Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí, no lo que ocurre cuando.

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas “estáticos” porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases “conocen” a qué otras clases o qué clases “son parte” de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.

Umbrello UML Modeller mostrando un diagrama de clases
6.Mapeo de clases de uml
La declaracion es muy simple y claramente igual a JAVA.
// Definimos una interface IMapeable que representa el
// comportamiento de los objetos que son persistibles
// Definimos una interface IMapeable que representa el
// comportamiento de los objetos que son persistibles
interface IMapeable
{
public function cargar($id);
public function guardar();
public function eliminar();
}
Como pueden ver estan declarados los metodos, pero no lo que hacen “;”Ya esta creada la interface, ahora hay que indicarle a una clase que va a “implementar” la interface IMapeable, por ejemplo, un cliente
// Un cliente es persistente, osea que naturalmente va a
// poder guardarse, cargarse y eliminarse/darse de baja
// por lo tanto es una buena practica dejar escrito parte
// de su comportamiento
class Cliente implements IMapeable
{
// Definimos el comportamiento de cargar
public function cargar($id)
{ ... }
// Definimos el comportamiento de guardar
public function guardar()
{ ... }
// Definimos el comportamiento de eliminar
public function eliminar()
{ ... }
}
Para implementarlo usamos la palabra reservada implements, igual que java? si si, por suerte, menos que aprender.Es decir, todos los metodos definidos en la interface usada tienen que si o si ser definidos en la clase, aunque no hagan nada , tienen que estar.Para finalizar, una clase puede implementar mas de una interface separandolas con coma de la siguiente manera:
class Cliente exteds Persona implements IMapeable, IPersona
{
...
}
Para terminar, acá tenemos la notación de UML del ejemplo:
{
public function cargar($id);
public function guardar();
public function eliminar();
}
Como pueden ver estan declarados los metodos, pero no lo que hacen “;”Ya esta creada la interface, ahora hay que indicarle a una clase que va a “implementar” la interface IMapeable, por ejemplo, un cliente
// Un cliente es persistente, osea que naturalmente va a
// poder guardarse, cargarse y eliminarse/darse de baja
// por lo tanto es una buena practica dejar escrito parte
// de su comportamiento
class Cliente implements IMapeable
{
// Definimos el comportamiento de cargar
public function cargar($id)
{ ... }
// Definimos el comportamiento de guardar
public function guardar()
{ ... }
// Definimos el comportamiento de eliminar
public function eliminar()
{ ... }
}
Para implementarlo usamos la palabra reservada implements, igual que java? si si, por suerte, menos que aprender.Es decir, todos los metodos definidos en la interface usada tienen que si o si ser definidos en la clase, aunque no hagan nada , tienen que estar.Para finalizar, una clase puede implementar mas de una interface separandolas con coma de la siguiente manera:
class Cliente exteds Persona implements IMapeable, IPersona
{
...
}
Para terminar, acá tenemos la notación de UML del ejemplo:
7. Ejemplos de Java
// La declaración de la clase Punto representa un par de coordenadas x-y.
public class Punto {
private int x; // parte x de un par de coordenadas
private int y; // parte y de un par de coordenadas
// constructor sin argumentos
public Punto()
{
// la llamada implícita al constructor de Object ocurre aquí
}
// constructor
public Punto( int valorX, int valorY )
{
// la llamada implícita al constructor de Object ocurre aquí
x = valorX; // no hay necesidad de validación
y = valorY; // no hay necesidad de validación
}
// establecer x en el par de coordenadas
public void establecerX( int valorX )
{
x = valorX; // no hay necesidad de validación
}
// devuelve x del par de coordenadas
public int obtenerX()
{
return x;
}
// establecer y en el par de coordenadas
public void establecerY( int valorY )
{
y = valorY; // no hay necesidad de validación
}
// devuelve y del par de coordenadas
public int obtenerY()
{
return y;
}
// devuelve la representación String del objeto Punto
public String toString()
{
return "[" + x + ", " + y + "]";
}
} // fin de la clase Punto
8. Diagramas de clases de RATIONAL ROSE
a) Con el botón derecho del ratón y estando en el navegador sobre el paquete de la Vista de Casos de Uso, haga new-package y cree un paquete que se llame Actividad 1.
b) Estando sobre el paquete recién creado haga click con el botón derecho y cree dos nuevos paquetes que se llaman Ventanas y Editor, estos se crearán como paquetes dentro del paquete Actividad 1.
c) Repita la operación anterior y cree los subpaquetes Motif y MSWindows como subpaquetes de Ventanas y Controlador, Dominio, Elementos, Núcleo Motif, Núcleo Windows como subpaquetes de Editor.
d) Sobre el paquete Actividad 1 realice new-Use Case Diagram, creando el diagrama Actividad 1. Haga doble click en el icono del diagrama e introduzca el diagrama mostrado en la Figura 1.1. Para ello arrastre desde el navegador los paquetes involucrados.
e) Repita el paso anterior para los paquetes Ventanas y Editor obteniendo los diagramas mostrados en las Figuras 1.2 y 1.3, respectivamente. En cada oportunidad arrastre desde el navegador los paquetes indicados.
Consejo: Cuando quiera asociar un nuevo diagrama a un paquete basta con hacer doble clic sobre él y luego renombrar el diagrama obtenido (por defecto se denomina Main).Consejo: Utilice los botones
b) Estando sobre el paquete recién creado haga click con el botón derecho y cree dos nuevos paquetes que se llaman Ventanas y Editor, estos se crearán como paquetes dentro del paquete Actividad 1.
c) Repita la operación anterior y cree los subpaquetes Motif y MSWindows como subpaquetes de Ventanas y Controlador, Dominio, Elementos, Núcleo Motif, Núcleo Windows como subpaquetes de Editor.
d) Sobre el paquete Actividad 1 realice new-Use Case Diagram, creando el diagrama Actividad 1. Haga doble click en el icono del diagrama e introduzca el diagrama mostrado en la Figura 1.1. Para ello arrastre desde el navegador los paquetes involucrados.
e) Repita el paso anterior para los paquetes Ventanas y Editor obteniendo los diagramas mostrados en las Figuras 1.2 y 1.3, respectivamente. En cada oportunidad arrastre desde el navegador los paquetes indicados.
Consejo: Cuando quiera asociar un nuevo diagrama a un paquete basta con hacer doble clic sobre él y luego renombrar el diagrama obtenido (por defecto se denomina Main).Consejo: Utilice los botones
Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son también la base para un par de diagramas relacionados: Diagramas de Componente y Diagramas de Instalación(Deployment).
Los diagramas de clase son importantes no solo para la visualización, especificación y documentación del modelo estructural, pero también para la construcción de sistemas ejecutable
Los diagramas de clase son importantes no solo para la visualización, especificación y documentación del modelo estructural, pero también para la construcción de sistemas ejecutable
Consejo: Utilice los botones para ir al diagrama padre o al diagrama anterior, respectivamente.








No hay comentarios:
Publicar un comentario