You are on page 1of 10

DIAGRAMA DE CLASE

LUIS ENRIQUE BETANCOURT RODRIGUEZ


Diagrama de clase:

Un diagrama de clase es el corazón de UML. Representa los propósitos


fundamentales de UML porque separa los elementos de diseño de la codificación del
sistema. UML ha sido establecido como un modelo estandarizado para describir un
enfoque de programación orientado a objetos. Dado que las clases son el bloque de
construcción de los objetos, los diagramas de clase son los bloques de construcción
de UML. Los componentes de creación de diagramas en un diagrama de clase
pueden representar las clases que realmente van a ser programadas, los objetos
principales, o las interacciones entre clases y objetos. La biblioteca de formas UML
en Lucidchart puede ayudarle a crear casi cualquier diagrama de clase personalizado.

ELEMENTOS DE LOS DIAGRAMAS DE CLASES:

1.- CLASE: Es la unidad básica que encapsula toda la información de un Objeto (un
objeto es una instancia de una clase). A través de ella podemos modelar el entorno
en estudio (una Casa, un Auto, una Cuenta Corriente, etc.)
2.- 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).
3.- Atributos: son valores que corresponden a un objeto, como color, material,
cantidad, ubicación. Generalmente se conoce como la información detallada del
objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos serían: la marca,
◦ public (+, ): Indica que el atributo será
visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. ◦
private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo
sus métodos lo pueden utilizar). ◦ protected (#, ): Indica que el atributo no será
accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase
además de las subclases que se deriven (ver herencia).
5. Operaciones/Métodos: son aquellas actividades o verbos que se pueden realizar
con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar,
cargar. El nombre de una operación se escribe con minúsculas si consta de una sola
palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la
anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que
comenzará en minúscula. Por ejemplo: abrir Puerta, cerrar Puerta, buscar Puerta,
etc. Tipos de métodos: ◦ public (+, ): Indica que el método será visible tanto dentro
como fuera de la clase, es decir, es accesible desde todos lados. ◦ private (-, ): Indica
que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la
clase lo pueden utilizar). ◦ protected (#, ): Indica que el método no será accesible
desde fuera de la clase, pero si podrá ser acceder por métodos de la clase además de
métodos de las subclases que se deriven (ver herencia).

SIMBOLOGIA:

6.-Cardinalidad de relaciones: indica el grado y nivel de dependencia de las


7. -Herencia (Especialización/Generalización):Indica que una subclase hereda
los métodos y atributos especificados poruna Super Clase (también llamada clase
padre), por ende la Subclase además de poseer sus propios métodos y atributos,
poseerá las características y atributos visibles de la Super Clase (public y protected).

8.- Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos
que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se
requiere componer objetos que son instancias de clases definidas por el desarrollador
de la aplicación, tenemos dos posibilidades: ◦ Por Valor: Es un tipo de relación
estática, en donde el tiempo de vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada
Composición (el Objeto base se construye a partir del objeto incluido, es decir, es
"parte/todo"). ◦ Por Referencia: Es un tipo de relación dinámica, en donde el tiempo
de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación
es comúnmente llamada Agregación (el objeto base utiliza al incluido para su
funcionamiento).
9.- Asociación: La relación entre clases conocida como Asociación, permite asociar
objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir,
el Ejemplo: Un cliente puede
tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo
puede tener asociado un cliente.

10.- Dependencia o Instanciación (uso):Representa un tipo de relación muy


particular, en la que una clase es instanciada (su instanciación es dependiente de otro
objeto/clase). Se de nota por una flecha punteada. El uso más particular de este tipo
de relación es para denotar la dependencia que tiene una clase de otra, como por
ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto
Ventana esta condicionado a la instanciación proveniente desde el objeto
Aplicación):Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se
almacena dentro del objeto que lo crea (en este caso la Aplicación).
DIAGRAMA DE OBEJETOS:

¿Qué es un diagrama de objetos en UML?


Un diagrama de objetos UML representa una instancia específica de un diagrama de
clases en un determinado momento en el tiempo. Cuando se lo representa
gráficamente, verás muchas similitudes con el diagrama de clases. Usamos el mismo
ejemplo de clase de coche de la página de diagramas de clases para ilustrar los
diagramas de objetos. Nuestra biblioteca de figuras UML puede ayudarte a diseñar
cualquier diagrama de objetos personalizado por medio de nuestra herramienta
UML en línea.
Diagrama de objetos vs. diagrama de clases

Ejemplo de diagrama de objetos

Ejemplo de diagrama de clases

Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo


esos objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama de objetos,
las tres cuentas bancarias están ligadas al banco mismo. Los títulos de clase muestran
el tipo de cuentas (ahorros, corriente y tarjeta de crédito) que un cliente dado podría
tener con este banco en particular. Los atributos de clase son diferentes para cada
tipo de cuenta. Esto se ilustra por el hecho de que el objeto de tarjeta de crédito tiene
un límite de crédito, mientras que las cuentas de ahorros y corriente tienen tasas de
interés. El diagrama de objetos no está limitado a casos de uso bancario. Puedes
crear un diagrama de objetos para árboles genealógicos, departamentos corporativos,
es decir, cualquier sistema con partes interrelacionadas.

ELEMENTOS DE DIAGRAMA DE OBJETOS:

Los diagramas de objetos son sencillos de crear: se componen de objetos,


representados por rectángulos, conectados mediante líneas. Estos son los elementos
principales de un diagrama de objetos:
 Objetos - son instancias de una clase. Si un coche es una clase, un Altima 2007 de
Nissan es un objeto de una clase. Los objetos en la clase "Padres" son tus padres
específicos, por ejemplo, Elaine y Gary.
 Títulos de clases - los atributos específicos de la clase. En el diagrama de objetos de
árbol genealógico, se trata del nombre, género y edad de los integrantes de la familia.
Se pueden enumerar como elementos en el objeto o incluso en las propiedades del
propio objeto (p. ej., color).
 Atributos de clases - un rectángulo con dos pestañas que indica un elemento de
software.
 Enlaces - se trata de las líneas que conectan un objeto con otro. El diagrama de
objetos corporativo siguiente muestra cómo los departamentos están conectados en
un estilo de organigrama tradicional.

SIMBOLOGIA:
DIAGRAMAS DE CASO DE USO:
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma
de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado
Unificado (UML), define una notación gráfica para representar casos de uso llamada
modelo de casos de uso. UML no define estándares para que el formato escrito
describa los casos de uso, y así mucha gente no entiende que esta notación gráfica
define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo
dar una vista general simple de un caso de uso o un conjunto de casos de uso.
Los diagramas de casos de uso son a menudo confundidos con los casos de uso.
Mientras los dos conceptos están relacionados, los casos de uso son mucho más
detallados que los diagramas de casos de uso. En los conceptos se debe detallar más
de un caso de uso para poder identificar qué es lo que hace un caso de uso.

ELEMENTOS DE CASO DE USO:


Elementos de un caso de uso:

Conjunto de secuencias de acciones, cada secuencia representa un posible


comportamiento del sistema.
Actores, se tratan de los roles que pueden jugar los agentes que interactúan con el
sistema. Los roles son jugados por personas, dispositivos, u otros sistemas.
Podríamos distinguir entre actores primarios, para los cuales el objetivo del caso de
uso es esencial y actores secundarios, que interactúan con el caso de uso, pero cuyo
objetivo no es esencial.
Variantes, son versiones especializadas, un caso de uso que extiende a otro o un caso
de uso que incluye a otro
Como veremos a continuación, en los diagramas de casos de uso se muestran: casos
de uso (representados en forma de elipses), actores (en forma de personajes) y
relaciones (en forma de líneas y/o flechas). UML define cuatro tipos de relaciones en
los diagramas de casos de uso:

Comunicación: Relación (asociación) entre un actor y un caso de uso. El estereotipo


de la relación de comunicación es: <<communicate>> aunque generalmente no se
estipula ningún nombre, como podemos apreciar en el siguiente ejemplo de
comunicación:

Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de otro


en algún lugar de su secuencia. La relación de inclusión sirve para enriquecer un caso
de uso con otro y compartir una funcionalidad común entre varios casos de uso,
también puede utilizarse para estructurar un caso de uso describiendo sus
subfunciones. El caso de uso incluido existe únicamente con ese propósito, ya que no
responde a un objetivo de un actor.

You might also like