jueves, 15 de abril de 2010

Programación Orientada a Objetos

Fundamentos de la programación orientada a objetos.



Introducción



Resumen

Introducción

Desarrollo

Conclusiones

Bibliografía


Resumen:

En este artículo el autor hace una sucinta descripción de los fundamentos de la programación orientada a objetos, necesaria para aquellos que no poseen nociones sobre esta materia, y material de consulta para los que la conocen o dominan.

Introducción:

En el universo de la programación actual, es de amplio consenso que la programación orientada a objetos es el mejor paradigma disponible para enfrentar las cada vez más complejas tareas de la programación. Sin embargo, no todos los programadores tienen claro los fundamentos de este paradigma, y tienden a confundir la programación usando objetos con la programación orientada a objetos.

En Visual Basic, por ejemplo, se usan objetos (componentes) sin que ello implique que estemos en presencia de un lenguaje orientado a objetos.

Programamos orientado a objetos cuando, usando un lenguaje de programación, somos capaces de modelar el problema en términos de objetos y sus relaciones.
Es decir cuando cada entidad en el programa es un objeto que brinda determinados servicios.

En este trabajo se hace una sucinta descripción de los fundamentos de la programación orientada a objetos, necesaria para aquellos que no poseen nociones sobre esta materia, y material de consulta para los que la conocen o dominan.

Desarrollo:

La programación orientada a objetos es la expresión de uno de los más avanzados paradigmas en el campo de la programación, y es, al mismo tiempo, el resultado de la evolución experimentada por los paradigmas anteriores.

A diferencia de otros paradigmas de programación, que intentan, al abordar un problema, representarlo o modelarlo empleando entidades cercanas a la computadora (arreglos, subrutinas, módulos) la programación orientada a objetos se propone emplear entidades lo más cercanas posibles a la realidad.

La programación orientada a objetos tiene como conceptos fundamentales los conceptos de objeto y clase.

Un objeto es un ente que posee sus características propias (propiedades) y un conjunto de acciones que es capaz de realizar (métodos).

Una clase es un ente abstracto que permite declarar las propiedades y los métodos de objetos similares.

Un lenguaje de programación orientado a objetos debe permitir al programador realizar definiciones de clases, y construir objetos a partir de esas clases.
Para resolver un problema bajo el paradigma de la programación orientada a objetos basta con determinar y caracterizar los diferentes objetos que intervienen en el problema, definir sus propiedades y métodos y ponerlos a interactuar entre sí.

Conclusiones:

Para entender cómo funciona el paradigma de la programación orientada a objetos es necesario ver un programa como una colección de objetos que interactúan entre sí enviándose mensajes y cambiando su estado durante la ejecución.

Resolver un problema bajo el paradigma de la programación orientada a objetos implica determinar y caracterizar los diferentes objetos que intervienen en el problema, definir sus propiedades y métodos y ponerlos a interactuar.

Bibliografía:

Rivero Errico, Alfonso J. Introducción a la programación para Windows con Visual Basic.-- Ciudad de la Habana : Editorial Pueblo y Educación, 2001
Díaz Iglesias, Jack y Pérez González, Franklin. Delphi 5 Básico.-- Ciudad de la Habana: Editorial Pueblo y Educación, 2001
Curso por correo electrónico sobre Borland Delphi.


Autor:
Asistente Juan Antonio Fonseca Hernández.
jfonseca@ispgrm.rimed.cu
Monografías

miércoles, 14 de abril de 2010

Modificadores de Acceso

Modificadores:

Los modificadores son elementos del lenguaje que se colocan delante de la definición de variables locales, dato miembro, métodos o clases y que alteran o condicionan el significado del elemento.

Modificadores de acceso

Uno de los principios de la programación orientada a objetos es la encapsulación, que es un proceso por el que se ocultan las características internas de un objeto a aquellos elementos que no tienen porque conocerla. Los modificadores de acceso sirven para indicar los permisos que tendrán otros objetos para acceder a sus métodos y propiedades.

Los modificadores de acceso permiten al diseñador de una clase determinar quien accede a los datos y métodos miembros de una clase.
Los modificadores de acceso preceden a la declaración de un elemento de la clase (ya sea dato o método), de la siguiente forma:
[modificadores] tipo_variable nombre;
[modificadores] tipo_devuelto nombre_Metodo ( lista_Argumentos );

- Los modificadores de acceso son palabras clave que especifican la accesibilidad declarada de un miembro o un tipo.

- Son palabras clave agregadas a la clase, estructura o declaración de miembro para especificar estas restricciones.

1- Modificador public

Es el nivel de acceso más permisivo. Sirve para indicar que el método o atributo de la clase es público. En este caso se puede acceder a ese atributo, para visualizarlo o editarlo, por cualquier otro elemento de nuestro programa. Es el modificador que se aplica si no se indica otra cosa.

Todo el mundo puede acceder al elemento. Si es un dato miembro, todo el mundo puede ver el elemento, es decir, usarlo y asignarlo. Si es un método todo el mundo puede invocarlo.

Veamos un ejemplo de clase donde hemos declarado como public sus elementos, un método y una propiedad. Se trata de la clase "dado", que tiene un atributo con su puntuación y un método para tirar el dado y obtener una nueva puntuación aleatoria.


class dado{
public $puntos;

function __construct(){
srand((double)microtime()*1000000);
}

public function tirate(){
$this->puntos=$randval = rand(1,6);
}
}

$mi_dado = new dado();

for ($i=0;$i<30;$i++){
$mi_dado->tirate();
echo "
Han salido " . $mi_dado->puntos . " puntos";
}

Vemos la declaración de la clase dado y luego unas líneas de código para ilustrar su funcionamiento. En el ejemplo se realiza un bucle 30 veces, en las cuales se tira el dado y se muestra la puntuación que se ha obtenido.

Como el atributo $puntos y el método tirate() son públicos, se puede acceder a ellos desde fuera del objeto, o lo que es lo mismo, desde fuera del código de la clase.


2 - Modificador Private

Es el nivel de acceso más restrictivo. Sirve para indicar que esa variable sólo se va a poder acceder desde el propio objeto, nunca desde fuera. Si intentamos acceder a un método o atributo declarado private desde fuera del propio objeto, obtendremos un mensaje de error indicando que no es posible a ese elemento.

Sólo se puede acceder al elemento desde métodos de la clase, o sólo puede invocarse el método desde otro método de la clase.

Si en el ejemplo anterior hubiéramos declarado private el método y la propiedad de la clase dado, hubiéramos recibido un mensaje de error.

Aquí tenemos otra posible implementación de la clase dado, declarando como private el atributo puntos y el método tirate().


class dado{
private $puntos;

function __construct(){
srand((double)microtime()*1000000);
}

private function tirate(){
$this->puntos=$randval = rand(1,6);
}

public function dame_nueva_puntuacion(){
$this->tirate();
return $this->puntos;
}
}

$mi_dado = new dado();

for ($i=0;$i<30;$i++){
echo "
Han salido " . $mi_dado->dame_nueva_puntuacion() . " puntos";
}

Hemos tenido que crear un nuevo método público para operar con el dado, porque si es todo privado no hay manera de hacer uso de él. El mencionado método es dame_nueva_puntuación(), que realiza la acción de tirar el dado y devolver el valor que ha salido.

3 - Modificador Protected

Este indica un nivel de acceso medio y un poco más especial que los anteriores. Sirve para que el método o atributo sea público dentro del código de la propia clase y de cualquier clase que herede de aquella donde está el método o propiedad protected. Es privado y no accesible desde cualquier otra parte. Es decir, un elemento protected es público dentro de la propia clase y en sus heredadas.

Más adelante explicaremos la herencia y podremos ofrecer ejemplos con el modificador protected.

Conclusión

Muchas veces el propio desarrollador es el que fija su criterio a la hora de aplicar los distintos modificadores de acceso a atributos y métodos. Poca protección implica que los objetos pierdan su encapsulación y con ello una de las ventajas de la POO. Una protección mayor puede hacer más laborioso de generar el código del programa, pero en general es aconsejable.

LA HERENCIA

La herencia es uno de los mecanismos fundamentales de la programación orientada a objetos. Por medio de la herencia, se pueden definir clases a partir de la declaración de otras clases. Las clases que heredan incluyen tanto los métodos como las propiedades de la clase a partir de la que están definidos.

Por ejemplo, pensemos en la clase "vehículo". Esta clase general puede incluir las características generales de todos los vehículos (atributos de la clase), como la matrícula, año de fabricación y potencia. Además, incluirá algunas funcionalidades (métodos de la clase) como podrían ser, arrancar() o moverse().

Ahora bien, en la práctica existen varios tipos de vehículos, como los coches, los autobuses y los camiones. Todos ellos tienen unas características comunes, que han sido definidas en la clase vehículo. Además, tendrán una serie de características propias del tipo de vehículo, que, en principio, no tienen otros tipos de vehículos. Por ejemplo, los camiones pueden tener una carga máxima permitida o los autobuses un número de plazas disponibles. Del mismo modo, las clases más específicas pueden tener unas funcionalidades propias, como los camiones cargar() y descargar(), o los autobuses aceptar_pasajeros() o vender_billete().

Lo normal en sistemas de herencia es que las clases que heredan de otras incluyan nuevas características y funcionalidades, aparte de los atributos y métodos heredados. Pero esto no es imprescindible, de modo que se pueden crear objetos que hereden de otros y no incluyan nada nuevo.

La programación orientada a objetos nos ofrece una serie de mecanismos para definir este tipo de estructuras, de modo que se puedan crear jerarquías de objetos que heredan unos de otros. Para ello, continuando con nuestro ejemplo de video club, vamos a crear los distintos tipos de elementos que se ofrecen en alquiler.

Como todo el mundo conoce, los videos club ofrecen distintos tipos de elementos para alquiler, como pueden ser las películas (cintas de vídeo o DVD) y los juegos. Cada elemento tiene unas características propias y algunas comunes. Hemos llamado "soporte" a la clase general, que incluye las características comunes para todos los tipos de elementos en alquiler. Luego hemos creado tres tipos de soportes distintos, que heredan de la clase soporte, pero que incluyen algunas características y funcionalidades nuevas. Estos tipos de soporte serán "cinta_video", "dvd" y "juego".

El esquema de herencia que vamos a realizar en este ejemplo se puede ver en la siguiente imagen.


Empezamos por la clase soporte. Su código será el siguiente:

class soporte{
public $titulo;
protected $numero;
private $precio;

function __construct($tit,$num,$precio){
$this->titulo = $tit;
$this->numero = $num;
$this->precio = $precio;
}

public function dame_precio_sin_iva(){
return $this->precio;
}

public function dame_precio_con_iva(){
return $this->precio * 1.16;
}

public function dame_numero_identificacion(){
return $this->numero;
}

public function imprime_caracteristicas(){
echo $this->titulo;
echo "
" . $this->precio . " (IVA no incluido)";
}
}

Los atributos que hemos definido son, título, numero (un identificador del soporte) y precio. Hemos aplicado a cada uno un modificador de acceso distinto, para poder practicar los distintos tipos de acceso.

Hemos definido un constructor, que recibe los valores para la inicialización del objeto. Un método dame_precio_sin_iva(), que devuelve el precio del soporte, sin aplicarle el IVA. Otro método dame_precio_con_iva(), que devuelve el precio una vez aplicado el 16% de IVA. El método dame_numero_identificacion(), que devuelve el número de identificador y imprime_caracteristicas(), que muestra en la página las características de este soporte.

Nota: Como se ha definido como private el atributo precio, este atributo sólo se podrá acceder dentro del código de la clase, es decir, en la propia definición del objeto. Si queremos acceder al precio desde fuera de la clase (algo muy normal si tenemos en cuenta que vamos a necesitar el precio de un soporte desde otras partes de la aplicación) será necesario crear un método que nos devuelva el valor del precio. Este método debería definirse como public, para que se pueda acceder desde cualquier sitio que se necesite.

En todos los métodos se hace uso de la variable $this. Esta variable no es más que una referencia al objeto sobre el que se está ejecutando el método. En programación orientada a objetos, para ejecutar cualquiera de estos métodos, primero tenemos que haber creado un objeto a partir de una clase. Luego podremos llamar los métodos de un objeto. Esto se hace con $mi_objeto->metodo_a_llamar(). Dentro de método, cuando se utiliza la variable $this, se está haciendo referencia al objeto sobre el que se ha llamado al método, en este caso, el objeto $mi_objeto. Con $this->titulo estamos haciendo referencia al atributo "titulo" que tiene el objeto $mi_objeto.


Si queremos probar la clase soporte, para confirmar que se ejecuta correctamente y que ofrece resultados coherentes, podemos utilizar un código como el siguiente.
$soporte1 = new soporte("Los Intocables",22,3);
echo "" . $soporte1->titulo . "";
echo "
Precio: " . $soporte1->dame_precio_sin_iva() . " euros";
echo "
Precio IVA incluido: " . $soporte1->dame_precio_con_iva() . " euros";

En este caso hemos creado una instancia de la clase soporte, en un objeto que hemos llamado $soporte1. Luego imprimimos su atributo titulo (como el título ha sido definido como public, podemos acceder a él desde fuera del código de la clase.
Luego se llaman a los métodos dame_precio_sin_iva() y dame_precio_con_iva() para el objeto creado.

Nos daría como resultado esto:
Los Intocables Precio: 3 euros
Precio IVA incluido: 3.48 euros
DIAGRAMAS:


DIAGRAMAS DE SECUENCIA:

A pesar de que a partir de los diagramas de casos de uso y de los diagramas de robustez ya tenemos entre un 75 y 80 por ciento de atributos de nuestras clases identificados, es hasta el diagrama de secuencia donde se empiezan a ver que métodos llevaran las clases de nuestro sistema. Esto se debe que hasta que vemos interactuando a los objetos de nuestras clases con los actores y con otros objetos de manera dinámica, hasta ese momento tenemos suficiente información como para poder empezar a especificar los métodos de nuestras respectivas clases.

El diagrama de secuencias es el núcleo de nuestro modelo dinámico, y muestra todos los cursos alternos que pueden tomar todos nuestros casos de uso. Los diagramas de secuencias se componen de 4 elementos que son: el curso de acción, los objetos, los mensajes y los métodos (operaciones). Estos 4 elementos son los que ya han sido analizados en clase con anterioridad dentro de la primera unidad.

Los 4 pasos a seguir:

A continuación se dará una muy breve descripción de los 4 pasos que se deben de seguir para dibujar correctamente diagramas de secuencia de ICONIX:

-Paso 1: Copia el texto de la especificación de tu caso de uso y pégalo en la parte superior de tu diagrama de secuencia. Con esto siempre se tendrá en cuenta que es lo que debe de hacer el diagrama de secuencia.

-Paso 2: Cada uno de los objetos entidad de tu diagrama de robustez es una instancia de la clase que debe de ser agregada a tu diagrama de secuencias ya que representa tu modelo estático. Hay que ser muy meticuloso con este paso, ya que representa el último de tu modelo estático antes de codificar.

-Paso 3: Agrega las interfaces del diagrama de robustez. Con esto ya tenemos el diagrama de secuencias construido. Ahora, el cuarto paso es para decidir cuales métodos irían en cuales clases, lo cual es la esencia del modelo de iteraciones.

-Paso 4: Pon los métodos en las clases, lo cual significa convertir los controles uno por uno de tu diagrama de robustez en métodos y mensajes. Verifica que para cada control dibujado le pertenecen los mensajes correctos dentro del diagrama de secuencias.

Top Ten de errores de los diagramas de secuencia:

A continuación se presentan algunos errores mas comúnmente cometidos por los estudiantes al intentar hacer sus diagramas de secuencia.

1.- No hacen un diagrama de secuencia para cada caso de uso: Hacer esto es muy importante, ya que solo así se puede saber cual es el rol y las responsabilidades de cada objeto.

2.- No ponen el texto del caso de uso en el diagrama de secuencia: El poner de vuelta este texto al margen del diagrama de secuencia provee de la visión necesaria para poder hacer diagramas de secuencia correctos de acuerdo al caso de uso que se esta modelando.

3.- No identifican todos los objetos necesarios desde el diagrama de robustez: Si tienes problemas al realizar los diagramas de secuencia es por que tienes mal modelados tus casos de uso o tus diagramas de robustez están incompletos.

Diagramas de Actividad:

El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado.
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes.

Usando Diagramas de Actividad para modelar Casos de Uso:

Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad.

Usando Diagramas de Actividad para modelar Clases:

Cuando se modela el comportamiento de una clase, un diagrama de estado de UML se suele usar normalmente para modelar situaciones donde ocurren eventos asincrónicos. El diagrama de actividad se usa conado todos o la mayoría de los elementos representan el desarrollo de los pasos dados por las acciones generadas internamente. Deberías asignar actividades a las clases antes de terminar con el diagrama de actividad.

Los mensajes se muestran como flechas entre líneas de vida. Un diagrama de secuencia puede mostrar un escenario, es decir, una historia individual de transacción. Un uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso.
Un diálogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interacción. En general, el tiempo avanza hacia abajo dentro de la página (se pueden invertir los ejes si se desea). Con frecuencia sólo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una métrica. La ordenación horizontal de los objetos no tiene ningún significado.

Diagrama de Secuencia:

Diagrama que muestra las interacciones entre los objetos organizadas en una secuencia temporal. En particular muestra los objetos participantes en la interacción y la secuencia de mensajes intercambiados.

Representa una interacción, un conjunto de comunicaciones entre objetos organizadas visualmente por orden temporal. A diferencia de los diagramas de colaboración, los diagramas de secuencia incluyen secuencias temporales pero no incluyen las relaciones entre objetos. Pueden existir de forma de descriptor (describiendo todos los posibles escenarios) y en forma de instancia (describiendo un escenario real).
Dentro del conjunto de mensajes representados dispuestos en una secuencia temporal, cada rol en la secuencia se muestra como una línea de vida, es decir, una línea vertical que representa el rol durante cierto plazo de tiempo, con la interacción completa

Los mensajes se muestran como flechas entre líneas de vida. Un diagrama de secuencia puede mostrar un escenario, es decir, una historia individual de transacción. Un uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso.

Un diálogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interacción. En general, el tiempo avanza hacia abajo dentro de la página (se pueden invertir los ejes si se desea). Con frecuencia sólo son importantes las secuencias de mensajes pero en
Aplicaciones de tiempo real el eje temporal puede ser una métrica. La ordenación horizontal de los objetos no tiene ningún significado.
Un diálogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interacción. En general, el tiempo avanza hacia abajo dentro de la página (se pueden invertir los ejes si se desea). Con frecuencia sólo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una métrica. La ordenación horizontal de los objetos no tiene ningún significado.
Cada objeto representa una columna distinta, se pone un símbolo de objeto al final de la flecha que representa el mensaje que ha creado el objeto; está situada en el punto vertical que denota el instante en que se crea el objeto. Esta se conoce como línea de vide del objeto. Se pone una X grande en el punto en que deja de existir el objeto o en el punto en que el objeto se destruye a sí mismo. Para el periodo durante el cual esté activo el objeto, la línea de vida se amplía para ser una línea doble continua. Si el objeto se llama a sí mismo, entonces se superpone otra copia de la doble línea para mostrar la doble activación. El orden relativo de los objetos no tiene significado aún cuando resulta útil organizarlos de modo que se minimice la distancia de las flechas.

Cada mensaje se representa mediante una flecha horizontal que va desde la línea de vida del objeto que envió el mensaje hasta la línea de vida del objeto que ha recibido el mensaje. Si un mensaje requiere un cierto tiempo para llegar a su destino, entonces la flecha del mensaje se dibuja diagonalmente hacia abajo.
Para un flujo de objeto asíncrono entre objetos activos, los objetos se representan mediante líneas dobles continuas y los mensajes se representan como flechas. Se pueden enviar simultáneamente dos mensajes pero no se pueden recibir simultáneamente porque no se puede garantizar una recepción simultánea.
Las bifurcaciones se muestran partiendo la línea de vida del objeto. Cada bifurcación puede enviar y recibir mensajes. Eventualmente las líneas de vida del objeto tienen que fusionarse de nuevo.

Un diagrama de secuencia también se puede mostrar en forma de descriptor, en el cual los constituyentes son roles en lugar de objetos. Este diagrama muestra en el caso general, no una sola ejecución del mismo. Los diagramas del nivel de descriptores se dibujan sin subrayados porque los símbolos denotan roles y no objetos individuales.

Diagrama de Estado:

Un Diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama está contenido dentro de un paquete.
La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas. La información está sobre todo en la topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en un gráfico en la forma analizada de la notación.
La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie bidimensional.

Hay cuatro clases de construcciones gráficas que se usan en la notación de UML: íconos, símbolos bidimensionales, rutas y cadenas.
Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como símbolos independientes que puedan o no conectar con las rutas.

Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas.

Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular gráficamente. Un segmentó no debería existir separado de su ruta. Las rutas siempre van conectadas en ambos extremos.
Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información del modelo subyancente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en un diagrama.

Diagramas de Objetos:

Objeto es una entidad discreta con límites bien definidos y con identidad, es una unidad atómica que encapsula estado y comportamiento. La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento. el Objeto es reconocido también como una instancia de la clase a la cual pertenece.

La encapsulación presenta tres ventajas básicas:

1. Se protegen los datos de accesos indebidos
2. El acoplamiento entre las clases se disminuye
3. Favorece la modularidad y el mantenimiento

Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un determinado instante de tiempo que posee un valor específico (Un objeto puede caracterizar una entidad física -coche-) y como un poseedor de identidad que tiene distintos valores a lo largo del tiempo (abstracta -ecuación matemática-).
Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a él mediante una denominación exclusiva que permite accederle. El Modelado de Objetos permite representar el ciclo de vida de los objetos a través de sus interacciones. En UML, un objeto se representa por un rectángulo con un nombre subrayado.
• Objeto = Identidad + Estado + Comportamiento
• El estado está representado por los valores de los atributos.
• Un atributo toma un valor en un dominio concreto.
La regla general para la notación de instancias consiste en utilizar el mismo símbolo geométrico que el descriptor. En la instancia se muestran los posibles valores pero las propiedades compartidas sólo se ponen de manifiesto en el descriptor. La notación canónica es un rectángulo con tres compartimientos. En el primero va el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones. Este último puede ser omitido si así se prefiere.
Oid (Object Identifier)

Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes características:
• Constituye un identificador único y global para cada objeto dentro del sistema.
• Es determinado en el momento de la creación del objeto.
• Es independiente de la localización física del objeto, es decir, provee completa independencia de localización.
• Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura.
• No cambia durante toda la vida del objeto. Además, un oid no se reutiliza aunque el objeto deje de existir.
No se tiene ningún control sobre los oids y su manipulación resulta transparente. Sin embargo, es preciso contar con algún medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos).

Características alrededor de un objeto:

Estado:

El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estímulo externo representado como mensaje enviado desde otro objeto.
Persistencia:
La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo, podremos después reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecución (materialización del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debería ser transparente, un objeto existe desde su creación hasta que se destruya.
Comunicación:

Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan de manera coordinada en la consecución de un fin específico. El comportamiento global se basa pues en la comunicación entre los objetos que la componen.

Categorías de objetos:

• Activos o Pasivos
• Cliente -- Servidores, Agentes
1. Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una actividad.
2. Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se le solicita un servicio.
3. Cliente es el objeto que solicita un servicio.
4. Servidor es el objeto que provee el servicio solicitado.
5. Los agentes reúnen las características de clientes y servidores. Son la base del mecanismo de delegación. Introducen indirección: un cliente puede comunicarse con un servidor que no conoce directamente.

Mensajes:

La unidad de comunicación entre objetos se llama mensaje. El mensaje es el soporte de una comunicación que vincula dinámicamente los objetos que fueron separados previamente en el proceso de descomposición. Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinámico. Un estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de una señal. Un mensaje es la especificación de un estímulo.

Tipos de flujo de control:

1. Llamada a procedimiento o flujo de control anidado
2. Flujo de control plano
3. Retorno de una llamada a procedimiento
4. Otras variaciones
5. Esperado (balking)
6. Cronometrado (time-out)

Diagramas de Clases:

El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones.
El mundo real puede ser visto desde abstracciones diferentes (subjetividad)

Mecanismos de abstracción:

1. Clasificación / Instanciación
2. Composición / Descomposición
3. Agrupación / Individualización
4. Especialización / Generalización

La clasificación es uno de los mecanismos de abstracción más utilizados. La clase define el ámbito de definición de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por instanciación de las clases.
Cada clase se representa en un rectángulo con tres compartimientos:
• nombre de la clase
• atributos de la clase
• operaciones de la clase
Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son:
• (-) Privado: es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++)
• (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original.
• (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)
Relaciones entre clases:
Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relación son:
• Asociación y Agregación (vista como un caso particular de asociación)
• Generalización/Especialización.
Las relaciones de Agregación y Generalización forman jerarquías de clases.

Asociación:

La asociación expresa una conexión bidireccional
Entre objetos. Una asociación es una abstracción de la relación existente en los enlaces entre los objetos. Puede determinarse por la especificación de multiplicidad (mínima...máxima)
• Uno y sólo uno
• 0..1 Cero o uno
• M..N Desde M hasta N (enteros naturales)
• * Cero o muchos
• 0..* Cero o muchos
• 1..* Uno o muchos (al menos uno)

Agregación:

La agregación representa una relación parte de/ entre objetos. En UML se proporciona una escasa caracterización de la agregación. Esta relación puede ser caracterizada con precisión determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes.
Una agregación se podría caracterizar según:
Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado?
No => inclusiva
Si => no inclusiva
Puede cambiar La composición del objeto agregado?
Si => dinámica
No => estática

Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una parte del dominio. Un Diagrama de Objetos representa una situación concreta del dominio. Las clases abstractas no son instanciadas.

Generalización:

Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases, se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización. La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general. Los nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas. La Generalización y Especialización son equivalentes en cuanto al resultado: la jerarquía y herencia establecidas. Generalización y Especialización no son operaciones reflexivas ni simétricas pero sí transitivas. La especialización es una técnica muy eficaz para la extensión y reutilización.

La noción de clase está próxima a la de conjunto. Dada una clase, podemos ver el conjunto relativo a las instancias que posee o bien relativo a las propiedades de la clase. Generalización y especialización expresan relaciones de inclusión entre conjuntos.

Diagramas de Caso de Uso:

Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, es una técnica para captura de requisitos.
• Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario.
• Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
• Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación.
• Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.
• Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos.
• Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo.
• Están basados en el lenguaje natural, es decir, es accesible por los usuarios.
Actores
• Principales: personas que usan el sistema.
• Secundarios: personas que mantienen o administran el sistema.
• Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados.
• Otros sistemas: sistemas con los que el sistema interactúa.
La misma persona física puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeñado.

Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario. Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso. Un escenario es una instancia de un caso de uso.

UML define cuatro tipos de relación en los Diagramas de Casos de Uso:

• Comunicación
• Inclusión: una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino. «include» reemplazó al denominado «uses»
• Extensión: el Caso de Uso origen extiende el comportamiento del Caso de Uso destino. «extend»
• Herencia: el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía.

Parámetros para la construcción de un caso de uso:

Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada Caso de Uso.

Preguntas clave:

1. cuáles son las tareas del actor?
2. qué información crea, guarda, modifica, destruye o lee el actor?
3. debe el actor notificar al sistema los cambios externos?
4. debe el sistema informar al actor de los cambios internos?

La descripción del Caso de Uso comprende:

1. el inicio: cuándo y qué actor lo produce?
2. el fin: cuándo se produce y qué valor devuelve?
3. la interacción actor-caso de uso: qué mensajes intercambian ambos?
4. objetivo del caso de uso: qué lleva a cabo o intenta?
5. cronología y origen de las interacciones
6. repeticiones de comportamiento: qué operaciones son iteradas?
7. situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso?

Diagrama de Actividades:

El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las acciones y usado para especificar:
• Un método
• Un caso de uso

Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad.
Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Los parámetros de entrada y salida de una acción se pueden mostrar usando las relaciones de flujo que conectan la acción y un estado de flujo de objeto.
• Un proceso de negocio (Workflow)
Un grafo de actividades contiene estados de actividad que representa la ejecución de una secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera la terminación de su cómputo. Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad dentro del diagrama. una transición de terminación es activada en un diagrama de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explícitos, peor pueden ser abortados por transiciones en estados que los incluyen.
Un grafo de actividades puede contener también estados de acción, que son similares a los de actividad pero son atómicos y no permiten transiciones mientras están activos. Los estados de acción se deben utilizar para las operaciones cortas de mantenimiento.

Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en hilos concurrentes. Los hilos concurrentes representan actividades que se pueden realizar concurrentemente por los diversos objetos o personas. La concurrencia se representa a partir de la agregación, en la cual cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o en cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que permite el control de concurrencia además del control secuencial.

Notación:

Un estado de actividad se representa como una caja con los extremos redondeados que contiene una descripción de actividad. Las transacciones simples de terminación se muestran como flechas. Las ramas se muestran como condiciones de guarda en transiciones o como diamantes con múltiples flechas de salida etiquetadas. Una división o una unión de control se representan con múltiples flechas que entran o salen de la barra gruesa de sincronización.
Cuando es necesario incluir eventos externos, la recepción de un evento se puede mostrar como un disparador en una transición, o como un símbolo especial que denota la espera de una señal.
A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase de asignación puede mostrarse organizando las actividades en regiones distintas separadas por líneas en el diagrama. Debido a su aspecto, esto es conocido como Calles.

Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para un valor de salida, se dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de entrada, se dibuja una flecha con línea discontinua desde el objeto a una actividad.

Diagramas de Estado:

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro.
Los Diagramas de Estado representan autómatas de estados finitos, desde el p.d.v. de los estados y las transiciones. Son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los valores algunos de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un evento.

Estado:

Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente)

Eventos:

Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas:
• Condición que toma el valor de verdadero o falso
• Recepción de una señal de otro objeto en el modelo
• Recepción de un mensaje
• Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular
El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo nombre.
Envío de mensajes
Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.

Transición simple:

Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puede venir acompañada de un texto con el siguiente formato:
event-signature "[" guard-condition] "/" action-expression "^"send-clause
event-signature es la descripción del evento que da lugar la transición, guard-condition son las condiciones adicionales al evento necesarias para que la transición ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transición y el cambio de estado y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envío de eventos a otros paquetes o clases.

Transición interna:

Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado.

Acciones:

Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento.
Generalización de Estados:
Podemos reducir la complejidad de estos
• diagramas usando la generalización de estados.
• Distinguimos así entre superestado y subestados.
• Un estado puede contener varios subestados disjuntos.
• Los subestados heredan las variables de estado y las transiciones externas.
• La agregación de estados es la composición de un estado a partir de varios estados independientes.

La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.

Subestados
Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.

Transacción Compleja

Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.
Transición a estados anidados
Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).
Transiciones temporizadas
• Las esperas son actividades que tienen asociada cierta duración.
• La actividad de espera se interrumpe cuando el evento esperado tiene lugar.
• Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado.

Diagramas de Interacción:
Diagramas de Secuencia
Diagramas de Colaboración

La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de un objeto, que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase. Esta visión proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista de interacción se exhibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados en objetos cooperantes.
Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una interacción. Existen dos tipos de diagramas de interacción: el Diagrama de Colaboración y el Diagrama de Secuencia.

El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los enlaces de comunicación entre objetos, muestra las relaciones entre objetos y son mejores para comprender todos los efectos que tiene un objeto y para el diseño de procedimientos. El diagrama de Colaboración puede obtenerse automáticamente a partir del correspondiente diagrama de Secuencia (o viceversa).

Diagramas de Secuencia:

1. Muestra la secuencia de mensajes entre objetos durante un escenario concreto
2. Cada objeto viene dado por una barra vertical
3. El tiempo transcurre de arriba abajo
4. Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua

Diagramas de Colaboración:

1. Son útiles en la fase exploratoria para identificar objetos.
2. La distribución de los objetos en el diagrama permite observar adecuadamente la interacción de un objeto con respecto de los demás
3. La estructura estática viene dada por los enlaces; la dinámica por el envío de mensajes por los enlaces

Qué es una Colaboración?

Es una descripción de una colección de objetos que interactúan para implementar un cierto comportamiento dentro de un contexto. Describe una sociedad de objetos cooperantes unidos para realizar un cierto propósito. Una colaboración contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecución. Una ranura de colaboración se llama Rol porque describe el propósito de un objeto o un enlace dentro de la colaboración.
Un rol clasificador representa una descripción de los objetos que pueden participar en una ejecución de la colaboración, un rol de asociación representa una descripción de los enlaces que pueden participar en una ejecución de colaboración. Un rol de clasificador es una asociación que está limitada por tomar parte en la colaboración. Las relaciones entre roles de clasificador y asociación dentro de una colaboración sólo tienen sentido en ese contexto. En general fuera de ese contexto no se aplican las mismas relaciones.

Una Colaboración tiene un aspecto estructural y un aspecto de comportamiento. El aspecto estructural es similar a una vista estática: contiene un conjunto de roles y relaciones que definen el contexto para su comportamiento. El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a los roles. Tal conjunto de mensajes en una colaboración se llama Interacción. Una colaboración puede incluir una o más interacciones.

Qué es una Interacción?

Es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles de asociación. Un mensaje es una comunicación unidireccional entre dos objetos, un flujo de objeto con la información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores entre objetos. Un mensaje puede ser una señal (comunicación explícita entre objetos, con nombre y asíncrona) o una llamada (la invocación sincrona de una operación con un mecanismo para el control, que retorna posteriormente al remitente). Un patrón de intercambios de mensajes que se realizan para lograr un propósito específico es lo que se denomina una interacción.

Qué es Patrón?

Un patrón es una colaboración parametrizada, junto con las pautas sobre cuándo utilizarlo. Un parámetro se puede sustituir por diversos valores, para producir distintas colaboraciones. Los parámetros señalan generalmente las ranuras para las clases. El uso de un patrón se representa como una elipse de línea discontinua conectada con cada una de las clases por una línea discontinua, que se etiqueta con el nombre del rol.

Diagramas de Despliegue:

Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del equipo:
• Dispositivos
• Procesadores
• Memoria

Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos. Las instancias de los nodos pueden contener instancias de ejecución, como instancias de componentes y objetos. El modelo puede mostrar dependencias entre las instancias y sus interfaces, y también modelar la migración de entidades entre nodos u otros contenedores.
Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia muestra la localización de las instancias de los componentes específicos en instancias específicas del nodo como parte de una configuración del sistema. La forma de descriptor muestra qué tipo de componentes pueden subsistir en qué tipos de nodos y qué tipo de nodos se pueden conectar, de forma similar a un diagrama de clases, esta forma es menos común que la primera.

Diagramas de Componentes:

Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones. Muestran las opciones de realización incluyendo código fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente.

Un diagrama de componentes representa las dependencias entre componentes software, incluyendo componentes de código fuente, componentes del código binario, y componentes ejecutables. Un módulo de software se puede representar como componente. Algunos componentes existen en tiempo de compilación, algunos en tiempo de enlace y algunos en tiempo de ejecución, otros en varias de éstas.
Un componente de sólo compilación es aquel que es significativo únicamente en tiempo de compilación. Un componente ejecutable es un programa ejecutable.
Un diagrama de componentes tiene sólo una versión con descriptores, no tiene versión con instancias. Para mostrar las instancias de los componentes se debe usar un diagrama de despliegue.
Un diagrama de componentes muestra clasificadores de componentes, las clases definidas en ellos, y las relaciones entre ellas. Los clasificadores de componentes también se pueden anidar dentro de otros clasificadores de componentes para mostrar relaciones de definición.

Un diagrama que contiene clasificadores de componentes y de nodo se puede utilizar para mostrar las dependencias del compilador, que se representa como flechas con líneas discontinuas (dependencias) de un componente cliente a un componente proveedor del que depende. Los tipos de dependencias son específicos del lenguaje y se pueden representar como estereotipos de las dependencias.
El diagrama también puede usarse para mostrar interfaces y las dependencias de llamada entre componentes, usando flechas con líneas discontinuas desde los componentes a las interfaces de otros componentes.
El diagrama de componente hace parte de la vista física de un sistema, la cual modela la estructura de implementación de la aplicación por sí misma, su organización en componentes y su despliegue en nodos de ejecución. Esta vista proporciona la oportunidad de establecer correspondencias entre las clases y los componentes de implementación y nodos. La vista de implementación se representa con los diagramas de componentes.

Qué es Componente?

Es una parte física reemplazable de un sistema que empaqueta su implementación y es conforme a un conjunto de interfaces a las que proporciona su realización.
Algunos componentes tienen identidad y pueden poseer entidades físicas, que incluyen objetos en tiempo de ejecución, documentos, bases de datos, etc. Los componentes existentes en el dominio de la implementación son unidades físicas en los computadores que se pueden conectar con otros componentes, sustituir, trasladar, archivar, etc.

Los componentes tienen dos características: Empaquetan el código que implementa la funcionalidad de un sistema, y algunas de sus propias instancias de objetos que constituyen el estado del sistema. Los llamados últimos componentes de la identidad, porque sus instancias poseen identidad y estado.

Código:

Un componente contiene el código para las clases de implementación y otros elementos. Un componente de código fuente es un paquete para el código fuente de las clases de implementación. Algunos lenguajes de programación distinguen archivos de declaración de los archivos de método, pero todos son componentes. Un componente de código binario es un paquete para el código compilado. Una biblioteca del código binario es un componente.
Cada tipo de componente contiene el código para las clases de implementación que realizan algunas clases e interfaces lógicas. La relación de realización asocia un componente con las clases y las interfaces lógicas que implementan sus clases de implementación. Las interfaces de un componente describen la funcionalidad que aporta. Cada operación de la interfaz debe hacer referencia eventualmente a un elemento de la implementación disponible en el componente.
La estructura estática, ejecutable de una implementación de un sistema se puede representar como un conjunto interconectado de componentes. Las dependencias entre componentes significan que los elementos de la implementación en un componente requieren los servimos de los elementos de implementación en otros componentes. Tal uso requiere que dichos elementos sean de visibilidad pública.
Identidad:
Un componente de identidad tiene identidad y estado. Posee los objetos físicos que están situados en él. Puede tener atributos, relaciones de composición con los objetos poseídos, y asociaciones con otros componentes. Desde este punto de vista es una clase. Sin embargo la totalidad de su estado debe hacer referencia a las instancias que contiene.

Estructura:

Un componente ofrece un conjunto de elementos de implementación, esto significa que el componente proporciona el código para los elementos. Un componente puede tener operaciones e interfaces. Un componente de identidad es un contenedor físico para las entidades físicas como bases de datos. Para proporcionar manejadores para sus elementos contenidos, puede tener atributos y asociaciones salientes, que deben ser implementadas por sus elementos de implementación. Este componente se representa con un rectángulo con dos rectángulos más pequeños que sobresalen en su lado izquierdo.
Las operaciones e interfaces disponibles para los objetos exteriores se pueden representar directamente en el símbolo de clase. Estos son su comportamiento como clase. Los contenidos del subsistema se representan en un diagrama separado.
Las dependencias de un componente con otros componentes o elementos del modelo se representan usando líneas discontinuas con la punta de flecha hacia los elementos del proveedor. Sí un componente es la realización de una interfaz, se representa con un círculo unido al símbolo del componente por un segmento de línea.

Paquetes:

Cualquier sistema grande se debe dividir en unidades más pequeñas, de modo que las personas puedan trabajar con una cantidad de información limitada, a la vez y de modo que los equipos de trabajo no interfieran con el trabajo de los otros.
Un paquete es una parte de un modelo. Cada parte del modelo debe pertenecer a un paquete. Pero para ser funcional, la asignación debe seguir un cierto principio racional, tal como funcionalidad común, implementación relacionada y punto de vista común. UML no impone una regla para componer los paquetes.
Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Los paquetes son unidades de organización jerárquica de uso general de los modelos de UML. Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión de la configuración y la construcción de bibliotecas que contengan fragmentos reutilizables del modelo.
Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está definido en) sólo un paquete.
Los paquetes contienen elementos del modelo al más alto nivel, tales como clases y sus relaciones, máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones; atributos, operaciones, estados, líneas de vida y mensajes están contenidos en otros elementos y no aparecen como contenido directo de los paquetes.

Dependencias en los paquetes:

Las dependencias que se presentan entre elementos individuales, pero en un sistema de cualquier tamaño, deben ser vistas en un nivel más alto. las dependencias entre paquetes resumen dependencias entre los elementos internos a ellos, es decir, las dependencias del paquete son derivables a partir de las dependencias entre los elementos individuales.

La presencia de una dependencia entre paquetes implica que existe en un enfoque ascendente (una declaración de existencia), o que se permite que exista más adelante en un enfoque descendente (una restricción que limita cualquier otra relación), por lo menos un elemento de relación con el tipo de dependencia indicado entre elementos individuales dentro de los paquetes correspondientes.
Las dependencias múltiples del mismo tipo entre elementos individuales se agregan a una sola dependencia entre los paquetes que contienen los elementos. Si las dependencias entre elementos contienen estereotipos, éste puede ser omitido en la dependencia del paquete, para dar una sola dependencia de alto nivel.