CASO DE USO

CASO DE USO
En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Pasos para la Definición de un Caso de Uso:

• ID
• NOMBRE
• REFERENCIAS CRUZADAS
• CREADO POR
• ULTIMA ACTUALIZACION POR
• FECHA DE CREACION
• FECHA DE ULTIMA ACTUALIZACION
• ACTORES
• DESCRIPCION
• TRIGGER
• PRE-CONDICION
• POST-CONDICION
• FLUJO NORMAL
• FLUJOS ALTERNATIVOS
• INCLUDES
• FRECUENCIA DE USO
• REGLAS DE NEGOCIO
• REQUERIMIENTOS ESPECIALES
• NOTAS Y ASUNTO

Si lo primordial de los casos de uso (use case) no son los diagramas, entonces ¿que es lo importante? Lo realmente útil de los casos de uso es el documento que describe el caso de uso (use case), en este documento se explica la forma de interactuar entre el sistema y el usuario.

Pero lo más claro es que te presente uno. Este podría ser el caso de uso (use case) de escribir un mensaje en un foro.

ACTORES

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.

Tipos de relaciones

• ``comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso.
• ``usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.
• ``extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura

Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra, utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.

En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido.

En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.

Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.

Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases.

Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a descartarla, si es el caso.

ROLES

Los roles son agrupaciones de permisos. El rol más común es el de “miembro”. Podéis definir roles adicionales cuando necesitéis una unidad de permisos para formar un grupo.

Cuando se asigna un rol, a un usuario éste se mantiene en las carpetas inferiores (roles adquiridos).

Documentos / Archivos / Imagen / Carpetas

Rol de propietario
Tener éste rol sobre una carpeta implica poder visualizar y editar (siempre hablando del mismo nivel e inferiores) el contenido de la misma, tanto si son carpetas o archivos, sea cual sea su estado: Visible, Privado, Publicado.

También se puede acceder a las pestañas de contenidos, visualiza. Edita y comparte.

Si el estado de la carpeta, sobre la que se tiene el rol de Propietario es además privada (es decir su estado es privado), únicamente será visible para aquellos grupos que tengan el rol de Propietario.

Rol de Empleado
Tener el Rol de Empleado sobre una carpeta  implica poder visualizar todo su contenido en los estados Visible o Publicado, tanto si son carpetas o archivos. No se pueden visualizar en los elementos que se encuentren en estado Privado.
El estado en el que debería estar esta carpeta para asignarle un rol de empleado, y poder así visualizar dicho contenido, podria ser el de Visible o Publicado (en este caso no tiene mucho sentido asignar un rol a la carpeta), nunca Privado. 

Rol de Revisor
Tener el Rol de Revisor sobre una carpeta implica poder visualizar todo  su contenido, únicamente si el estado de esta carpeta en cuestión es Visible (o Publicado), si fuese Privada no la vería.

Rol de Gestor
 Tener el Rol de Gestor sobre una carpeta implica poder visualizar todo
 su contenido, tanto si el estado de esta carpeta en cuestión es Visible
 ó Privado, y tanto si el contenido de la misma: carpetas o archivos, es 
 Visible ó Privado.

Y al igual que con el rol de Propietario, se tiene también acceso a las pestañas de contenidos, visualiza. Edita y comparte, a las cuales no se puede acceder con el resto de Roles.

Rol de miembro
Tener el Rol de Miembro sobre una carpeta implica poder visualizar todo su contenido, siempre y cuando este contenido no sea Privado, y podré visualizar esta carpeta en cuestión siempre que el estado de la misma no sea Privado.

Rol de Responsable
Tener el Rol de Responsable sobre una carpeta implica poder visualizar todo su contenido, tanto si el estado de esta carpeta en cuestión es Visible ó Privado, y tanto si el contenido de carpetas o archivos es Visible ó Privado.

Roles de Usuario

Descripción rápida

Un Rol es una clasificación mediante la cual se definen distintos privilegios de operación para los usuarios del sistema.

Los Roles se encuentran predefinidos en el sistema y se detallan a continuación:

Tipos de Roles

Administrador

Un Administrador (Administrator) puede trabajar en tareas de configuración de la aplicación, puede crear usuarios y asignarles roles.

Supervisor

Un Supervisor puede tomar casos no atendidos, trabajar en ellos y transferirlos a otros usuarios. Puede ver todos los casos, pero solo trabajar en aquellos en que es propietario. También puede modificar la categoría de los casos.

Manager

Un Gerente (Manager) puede tomar casos no atendidos y derivar casos de unos usuarios a otros sin importar quién es el propietario del mismo. Tiene acceso a editar cualquier caso. También puede modificar la categoría de los casos.

Operador

Un Operador (Operator) puede tomar casos no atendidos (si la configuración del sistema lo permite) y puede transferirlos a otros usuarios. Puede ver solamente los casos en que participó, y solo puede trabajar en sus propios casos.

Analista

Un Analista (Analyst) puede leer cualquier información y acceder a cualquier reporte, pero no puede editar ningún caso.

¿Cuántos roles puede tener un usuario?

Creación -Modificación -visualización /por separado

Dependiendo del tipo de usuario que sea

¿Para quien está dirigido los diagramas de casos de uso?

Para los clientes

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

Actores

Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.

Casos de Uso

Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.

Relaciones entre Casos de Uso

Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura 16 se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

Tipos de Diagramas en UML

, los diagramas de clases, distan mucho de ser los únicos definidos en el lenguaje. De hecho en la versión UML 2 existen trece (13) diagramas concretos y varias categorías de diagramas abstractos, creados como toda clase abstracta, para articular la presentación de los diagramas.

DIAGRAMA DE CLASE: Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

DIAGRAMAS DE ESTRUCTURA

DIAGRAMA DE ESTRUCTURA COMPUESTA: Un diagrama de estructura compuesta es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.

DIAGRAMA DE COMPONENTES: Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
DIAGRAMA DE DESPLIEGE: El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.
En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.
Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales

Debido a que estos son más parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista estática y dinamica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
DIAGRAMA DE OBJETOS: Los diagramas de objetos usan un sub conjunto de elementos de un diagrama de clase para enfatizar la relación entre las instancias de las clases en algún punto en el tiempo. Estos son útiles para entender los diagramas de clases. Estos no muestran nada diferente en su arquitectura a los diagramas de secuencia, pero reflejan multiplicidad y roles.DIAGRAMA DE PAQUETES: En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.
Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.
DIAGRAMAS DE COMPORTAMIENTOS
DIAGRAMA DE ACTIVIDAD: En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general
La especificación del Lenguaje de Modelado Unificado OMG define un diagrama de actividad como: “… una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o sub actividades y las transiciones se provocan por la realización de las acciones o sub actividades.” ^[1] El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones. Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz. Una Interfaz es un grupo de operaciones relacionadas con la semántica.
DIAGRAMA DE INTERACCION: Son diagramas que describen como grupos de objetos colaboran para conseguir algún fin, estos diagramas muestran objetos así como los mensajes que pasan  entre ellos dentro del caso de uso

• DIAGRAMA DE CASOS DE USO: La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

• La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherente, consistente promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

Es práctica común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

Diagrama de Máquina de EstadosUn diagrama de máquina de estado modela el comportamiento de un solo objeto, especificando la secuencia de eventos que un objeto atraviesa durante su tiempo de vida en respuesta a los eventos.

¿Qué hacer cuando el diagrama de caso de uso es muy grande y no cabe en una sola hoja?

Agrupar los casos de usos por modulos

   ¿Cuando se tiene un diagrama de casos de uso muy complejo qué recomendarías?

 Explicarlo de forma más detallada, ser mas especifico
¿Qué es una clase?
En la programación orientada a objetos, una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto, por ejemplo, una instancia del objeto de la clase "Personas" sería del tipo "Personas
Que es un Objeto?
Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
¿Qué es una Instancia?
INSTANCIA: En programación, una instancia se produce con la creación de un objeto perteneciente a una clase (se dice que se instancia la clase). El objeto que se crea tiene los atributos, propiedades y métodos de la clase a la que pertenece. Los objetos y sus características se usan en la construcción de programas, ya sea como contenedores de datos o como partes funcionales del programa.
¿Qué es UML?
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

QUE ES ENCAPSULACIÒN: La encapsulación es un mecanismo que consiste en organizar datos y métodos de una estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el acceso a datos por cualquier otro medio distinto a los especificados. Por lo tanto, la encapsulación garantiza la integridad de los datos que contiene un objeto.

Existen tres niveles de acceso:

         Público: funciones de toda clase pueden acceder a los datos o métodos de una clase que se define con el nivel de acceso público. Este es el nivel de protección de datos más bajo

         Protegido: el acceso a los datos está restringido a las funciones de clases heredadas, es decir, las funciones miembro de esa clase y todas las subclases

         Privado: el acceso a los datos está restringido a los métodos de esa clase en particular. Este es nivel más alto de protección de datos (10)

La abstracción es uno de los medios más importantes mediante el cual nos enfrentamos con la complejidad inherente al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto sin preocuparse de las restantes características ( no esenciales ). La abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementación.

RELACIONES ENTRE CLASES
Las relaciones entre clases juegan un papel muy importante en el modelo de objetos. Las clases, al igual que los objetos, no existen de modo aislado. Por esta razón existirán relaciones entre clases y entre objetos.
Las relaciones entre clases, se deben a dos razones: 1) una relación de clases puede indicar algún tipo de compartición 2) una relación entre clases puede indicar algún tipo de conexión semántica.
Los tres grandes tipos de relaciones entre clases son:

Cuantos niveles de Diagramas de Casos de uso existen y menciónelos.

·         Generalización / especialización (es-un)

·         Agregación (todo-parte//tiene-un)

·         Asociación.

HERENCIA: En términos simples la herencia en la P.O.O. es la capacidad que tiene los objetos para heredar todas o algunas de sus características (datos) y comportamiento (procedimientos) a sus descendientes o herederos, permitiendo así la reutilización de código lo que en la práctica se traduce en una herramienta muy potente de programación.
Esta herencia puede ser a nivel de estado (características) o protocolo (métodos y procedimientos) o ambas. La herencia en la P.O.O tiene sus raíces en el concepto de registros anidado

MODULARIDAD: Descomponer un programa en un número pequeño de abstracciones coherentes que pertenecen al dominio del problema y enmascaran la complejidad interna.

 Modularizar es dividir un programa en módulos que pueden ser compilados separadamente pero existiendo conexiones entre los módulos.
Parnas dice además que deben (las conexiones) seguir el criterio de ocultación.
Booch piensa que la modularización deber ser propiedad de un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados.

POLIMORFISMO: Otra propiedad importante de la programación orientada a objetos es el polimorfismo. Esta propiedad, en su concepción básica, se encuentra en casi todos los lenguajes de programación. El polimorfismo, en su expresión más simple, es el uso de un nombre o un símbolo para representar o significar mas de una acción.
Esta propiedad permite que un mismo método se comporte de forma distinta dependiendo de que objeto lo esta ejecutando. Por ejemplo, todos los mamíferos tienen el método comer, pero este método se efectuara de forma distinta si este mamífero es un ciervo comiendo hierba, un león comiendo carne, una ballena comiendo plancton o un niño comiéndose un caramelo.
La gran ventaja ofrecida por el polimorfismo es permitir que los nuevos tipos de datos sean manipulados de forma similar que los tipos de datos predefinidos, logrando así ampliar el lenguaje de programación de una forma más ortogonal.

MENSAJES: Corresponde a la forma que tienen los objetos para comunicarse entre sí, de esta forma, el objeto que activa el mensaje se llama objeto emisor y el que lo recibe objeto receptor. Cabe señalar que un mensaje debe ser activado o generado desde un método hacia un objeto. En términos generales equivale a la llamada a un procedimiento o función.
Forma general de un mensaje:
receptor_mensaje.selector_mensaje [(parámetros)]
P/e ventana_editor.maximizar; documento1.imprimir (2);

AGREGACION:cuando una clase se compones de otras

Extensión (Extend)

EEs otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. uso extensión puede ser insertada en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."

SOBRECARGA: En programación orientada a objetos la sobrecarga se refiere a la posibilidad de tener dos o más funciones con el mismo nombre pero funcionalidad diferente. Es decir, dos o más funciones con el mismo nombre realizan acciones diferentes. El compilador usará una u otra dependiendo de los parámetros usados. A esto se llama también sobrecarga de funciones.
También existe la sobrecarga de operadores que al igual que con la sobrecarga de funciones se le da más de una implementación a un operador.
Sobrecarga es la capacidad de un lenguaje de programación, que permite nombrar con el mismo identificador diferentes variables u operaciones
El mismo método dentro de una clase permite hacer cosas distintas en función de los parámetros
Java no permite al programador implementar sus propios operadores sobrecargados, pero sí utilizar los predefinidos como el +. • C++, por el contrario si permite hacerlo.

ESTRUCTURA DE UN OBJETO

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:

1 - RELACIONES

2 - PROPIEDADES

3 - METODOS

Cada uno de estos componentes desempeña un papel totalmente independiente:

Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por punteros a otros objetos.

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedadde que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.

Los métodos son las operacionesque pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.