Está en la página 1de 25

DIAGRAMA DE CLASES

Es un diagrama de estructura estática que muestra el conjunto de


clases y objetos importantes que hacen parte de un sistema,
junto con las relaciones existentes entre estas clases y objetos.
Muestra de una manera estática la estructura de información del
sistema y la visibilidad que tiene cada una de las clases, dada por
sus relaciones con las demás en el modelo.
Clase.
Representada por un rectángulo con tres divisiones internas, son los
elementos fundamentales del diagrama. Una clase describe un conjunto
de objetos con características y comportamiento idéntico.

Nombre de la clase

Atributos

Métodos u operaciones
Atributo.
Identifican las características propias de cada clase. Generalmente son de tipos simples, ya que los
atributos de tipos compuestos se representan mediante asociaciones de composición con otras
clases.

La sintaxis de un atributo es

visibility name : type-expression = initial-value { property-string }

Donde visibility es uno de los siguientes:


+ public visibility
# protected visibility
- private visibility
Operación.
El conjunto de operaciones describen el comportamiento de los objetos de una clase. La
sintaxis de una operación en UML es

visibility name ( parameter-list ) : return-type-expression { property-string }


cada uno de los parámetros en parameter-list se denota igual que un atributo. Los
demás elementos son los mismos encontrados en la notación de un atributo.
DIAGRAMA DE CASOS DE USO
El diagrama de casos de uso representa la forma en cómo un cliente (actor)
opera con el sistema en desarrollo, además de la forma, tipo y orden en como
los elementos interactúan (operaciones o casos de uso). Un diagrama de casos
de uso consta de los siguientes elementos:
• actor.
• Casos de uso.
• Relaciones de uso, herencia y comunicación
Actor.
Una definición previa, es que un actor es un rol que un usuario juega
con respecto al sistema. Es importante destacar el uso de la palabra
rol, pues con esto se especifica que un actor no necesariamente
representa a una persona en particular, sino más bien la labor que
realiza frente al sistema. Como ejemplo a la definición anterior,
tenemos el caso de un sistema de ventas en que el rol de vendedor
con respecto al sistema puede ser realizado por un vendedor o bien
por el jefe de local.
Caso de Uso.
Es una operación/tarea específica que se realiza tras una orden de
algún agente externo, sea desde una petición de un actor o bien
desde la invocación desde otro caso de uso.

CASO DE USO
Relaciones.
Es el tipo de relación más básica que indica la invocación
desde un actor o caso de uso a otra operación (caso de uso).
Asociación de
Dicha relación se denota con una flecha simple.
Comunicación
Se recomienda utilizar cuando un caso de uso es similar a
otro (características).
Extensión
<<extends>> Se recomienda utilizar cuando se tiene un conjunto de
características que son similares en más de un caso de uso y
Inclusión no se desea mantener copiada la descripción de la
característica. De lo anterior cabe mencionar que tiene el
<<include>>
mismo paradigma en diseño y modelamiento de clases, en
donde está la duda clásica de usar o heredar.

Generalización Este tipo de relación es uno de los más utilizados, cumple una
doble función dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o de Herencia (<<extends>>).
• Cada caso de uso se centra en
describir cómo alcanzar una única
meta o tarea. Desde una
perspectiva tradicional de la
ingeniería de software, un caso de
uso describe una característica del
sistema.
LIMITACIONES

Los casos de uso pueden ser útiles para establecer requisitos de


comportamiento, pero no establecen completamente los requisitos
funcionales ni permiten determinar los requisitos no funcionales. Los casos de
uso deben complementarse con información adicional como reglas de
negocio, requisitos no funcionales, diccionario de datos que complementen los
requerimientos del sistema. Sin embargo la ingeniería del funcionamiento
especifica que cada caso crítico del uso debe tener un requisito no funcional
centrado en el funcionamiento asociado.
EJEMPLOS DE DIAGRAMAS
EJEMPLO DE DIAGRAMA DE CLASE
EJEMPLO DE DIAGRAMA DE CLASE
Como ejemplo de caso de uso, está el caso de una máquina recicladora: sistema que
controla una máquina de reciclamiento de botellas, latas y papel. El sistema debe controlar
y/o aceptar:
• registrar el número de ítems ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada ítem
c. Total
• el usuario/cliente presiona el botón de comienzo
• existe un operador que desea saber lo siguiente: a. Cuantos ítems han sido retornados en
el día. B. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
• El operador debe además poder cambiar: a. Información asociada a ítems. B. Dar una
alarma en el caso de que:
i. Ítem se atora.
ii. No hay más papel.
Como una primera aproximación identificamos a los actores que interactúan
con el sistema:
Luego, tenemos que un cliente puede depositar ítems y un operador puede
cambiar la información de un ítem o bien puede imprimir un informe:
Además podemos notar que un ítem puede ser una botella, una lata o papel.
Otro aspecto es la impresión de comprobantes, que puede ser realizada
después de depositar algún ítem por un cliente o bien puede ser realizada a
petición de un operador.
Entonces, el diseño completo del diagrama use case es:
DIAGRAMA DE SECUENCIA
• Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación
a través del tiempo.

• El diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los


objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los
objetos.

• Típicamente se examina la descripción de un caso de uso para determinar qué objetos son
necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de
uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para
descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de
secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales,
y los mensajes pasados entre los objetos como flechas horizontales.
TAREA PARA LA SEMANA

•Revisar aula digital y participar del


foro

También podría gustarte