Titulo: Diagarama de Clases Diagrama Nº 5

Software “Enterprice Architec” V.13

Integrantes:
 Gianmarco Garcia Curo
 Liliana Crispin Bendezu
 Charles Jhoel Aguirre Perez
 Yudith Estela Alejandro Inga
Diagramas de Estructura:
Se trata de los diagramas que enfatizan los elementos que deben existir en el sistema
modelado.
Diagrama de Clases
Diagramas de componentes
Diagramas de objetos
Diagrama de estructura compuesta
Diagrama de despliegue
Diagrama de Paquetes
 Describe la estructura de un sistema mostrando sus clases, atributos
1. Conpectos: y las relaciones entre ellos. Los diagramas de clases son utilizados
durante el proceso de análisis y diseño de los sistemas informáticos,
donde se crea el diseño conceptual de la información que s e manejará
en el sistema, y los componentes que se encargaran del
funcionamiento y la relación entre uno y otro.
Es un tipo de diagrama de estructura estática que describe la
2. Definición: estructura de un sistema mostrando las clases del sistema, sus
atributos, operaciones (o métodos), y las relaciones entre los
objetos.

Los atributos o características de una Clase pueden ser de tres

3. Caracteristicas: tipos, los que definen el grado de comunicación y visibilidad de
ellos con el entorno, estos son:
public (+,): Indica que el atributo será visible tanto dentro
como fuera de la clase, es decir, es accsesible desde todos
lados.
private (-,): Indica que el atributo sólo será accesible
desde dentro de la Clase (sólo sus métodos lo pueden
accesar).
protected (#,): Indica que el atributo no será accesible
desde fuera de la clase, pero si podrá ser accesado por
métodos de la clase además de las subclases que se
deriven (ver Herencia).
Los métodos u operaciones de una clase son la forma en como
ésta interactúa con su entorno, éstos pueden tener las
características:
public (+,): Indica que el método será visible tanto dentro
como fuera de la Clase, es decir, es accsesible desde todos
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 accesar).
protected (#,): Indica que el método no será accesible
desde fuera de la clase, pero si podrá ser accesado por
métodos de la clase además de métodos de las subclases
que se deriven (ver herencia).

4. Herramientas:
 Nos sirve para visualizar las relaciones entre las clases que involucran
5. Funcionalidad: el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
agregación, ya que una clase es una descripción de conjunto de
objetos que comparten los mismos atributos, operaciones, métodos,
relaciones y semántica; mostrando un conjunto de elementos que son
estáticos, como las clases y tipos junto con sus contenidos y
relaciones.
Con el fin de facilitar la comprensión del diagrama, se pueden incluir
paquetes como elementos del mismo, donde cada uno de ellos agrupa
un conjunto de clases.
 Una relación es un término general que abarca los tipos
6. Relaciones específicos de conexiones lógicas que se pueden encontrar en los
diagramas de clases y objetos. UML presenta las siguientes
relaciones:
Relaciones a nivel de instancia
==== Un enlace es la relación más básica entre objetos.
Asociación

Ejemplo de diagrama de clases con una asociación de dos clases

(en inglés)
Una asociación representa a una familia de enlaces. Una
asociación binaria (entre dos clases) normalmente se representa
con una línea continua. Una misma asociación puede relacionar
cualquier número de clases. Una asociación que relacione tres
clases se llama asociación ternaria.
A una asociación se le puede asignar un nombre, y en sus
extremos se puede hacer indicaciones, como el rol que
desempeña la asociación, los nombres de las clases relacionadas,
su multiplicidad, su visibilidad, y otras propiedades.
Hay cuatro tipos diferentes de asociación: bidireccional,
unidireccional, agregación (en la que se incluye la composición)
y reflexiva. Las asociaciones unidireccional y bidireccional son
las más comunes.
Por ejemplo, una clase vuelo se asocia con una clase avión de
forma bidireccional. La asociación representa la relación estática
que comparten los objetos de ambas clases.
Agregación

Ejemplo de diagrama de clases con una agregación entre dos

clases (en inglés)
La agregación es una variante de la relación de asociación “tiene
un”: la agregación es más específica que la asociación. Se trata
de una asociación que representa una relación de tipo parte-todo
o parte-de.
Como se puede ver en la imagen del ejemplo (en inglés), un
Profesor 'tiene una' clase a la que enseña.
Al ser un tipo de asociación, una agregación puede tener un
nombre y las mismas indicaciones en los extremos de la línea.
Sin embargo, una agregación no puede incluir más de dos clases;
debe ser una asociación binaria.
Una agregación se puede dar cuando una clase es una colección
o un contenedor de otras clases, pero a su vez, el tiempo de vida
de las clases contenidas no tienen una dependencia fuerte del
tiempo de vida de la clase contenedora (del todo). Es decir, el
 contenido de la clase contenedora no se destruye
automáticamente cuando desaparece dicha clase.
En UML, se representa gráficamente con un rombo hueco junto
a la clase contenedora con una línea que lo conecta a la clase
contenida. Todo este conjunto es, semánticamente, un objeto
extendido que es tratado como una única unidad en muchas
operaciones, aunque físicamente está hecho de varios objetos más
pequeños.
Es la representación de los aspectos estáticos del sistema, utilizando
7. Objetivo diversos mecanismos de abstracción (clasificación, generalización,
agregación).
Genera: Codigo SQL – Mysql
Genera documentación: Diagramas Conexiones

DIAGRAMA DE CLASES
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema,
las cuales pueden ser asociativas, de herencia, de uso y de agregación, ya que una clase es una
descripción de conjunto de objetos que comparten los mismos atributos, operaciones, métodos,
relaciones y semántica; mostrando un conjunto de elementos que son estáticos, como las clases y
tipos junto con sus contenidos y relaciones. Un diagrama de clases este compuesto por los siguientes
elementos: Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.

El objetivo principal de este modelo es la representación de los aspectos estáticos del sistema,
utilizando diversos mecanismos de abstracción (clasificación, generalización, agregación).

Descripción

El diagrama de clases recoge las clases de objetos y sus asociaciones. En este diagrama se representa
la estructura y el comportamiento de cada uno de los objetos del sistema y sus relaciones con los
demás objetos, pero no muestra información temporal.

Con el fin de facilitar la comprensión del diagrama, se pueden incluir paquetes como elementos del
mismo, donde cada uno de ellos agrupa un conjunto de clases.

Este diagrama no refleja los comportamientos temporales de las clases, aunque para mostrarlos se
puede utilizar un diagrama de transición de estados, otra de las técnicas propuestas en MÉTRICA
Versión 3.

Ventajas y Desventajas
Ventajas
- Genera un código automáticamente.
- Propone soluciones a algunos errores.
- Representa las relaciones entre las clases de sistema.
- Se diseña los componentes de los sistemas.
 - Se protegen los datos.
- Se posibilita una reducción de acoplamiento.
- Más fácil la comunicación entre los programadores, descubrimiento de fallas del
sistema en el diseño Mejor diseño del sistema ofrece más documentación.
Desventajas
- Los diagramas de clases especifican qué clases hay y cómo están relacionadas, pero
no cómo interactúan para alcanzar comportamientos particulares.
- El método tiende hacer muy lento.
- La instalación es muy costosa.
Los elementos básicos del diagrama son:

Clases

Una clase describe un conjunto de objetos con propiedades (atributos) similares y un

comportamiento común. Los objetos son instancias de las clases.

No existe un procedimiento inmediato que permita localizar las clases del diagrama de clases. Éstas
suelen corresponderse con sustantivos que hacen referencia al ámbito del sistema de información
y que se encuentran en los documentos de las especificaciones de requisitos y los casos de uso.

Dentro de la estructura de una clase se definen los atributos y las operaciones o métodos:

Los atributos de una clase representan los datos asociados a los objetos instanciados por esa clase.

Las operaciones o métodos representan las funciones o procesos propios de los objetos de una
clase, caracterizando a dichos objetos.

El diagrama de clases permite representar clases abstractas. Una Clase abstracta es una clase que
no puede existir en la realidad, pero que es útil conceptualmente para el diseño del modelo
orientado a objetos. Las clases abstractas no son instanciables directamente sino en sus
descendientes. Una clase abstracta suele ser situada en la jerarquía de clases en una posición que
le permita ser un depósito de métodos y atributos para ser compartidos o heredados por las
subclases de nivel inferior.

Las clases y en general todos los elementos de los diagramas, pueden estar clasificados de acuerdo
a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificación adicional
se expresa mediante un Estereotipo. Algunos de los autores de métodos OO, establecen una
clasificación de todos los objetos que pueden aparecer en un modelo. Los tipos son:

Objetos Entidad.

Objetos límite o interfaz.

Objetos de control.

Éstos son estereotipos de clases. Un estereotipo representa una la meta-clasificación de un

elemento.
Dependiendo de la herramienta utilizada, también se puede añadir información adicional a las clases
para mostrar otras propiedades de las mismas, como son las reglas de negocio, responsabilidades,
manejo de eventos, excepciones, etc.

RELACIONES

Los tipos más importantes de relaciones estáticas entre clases son los siguientes:

Herencia. Las jerarqui ́as de generalización/especialización se conocen como herencia. Herencia es

el mecanismo que permite a una clase de objetos incorporar atributos y métodos de otra clase,
añ adiéndolos a los que ya posee. Con la herencia se refleja una relación “es_un” entre clases. La
clase de la cual se hereda se denomina superclase, y la que hereda subclase.
La generalización define una superclase a partir de otras. Por ejemplo, de las
clases profesor y estudiante se obtiene la superclase persona. La especialización o especificación es
la operación inversa, y en ella una clase se descompone en una o varias subclases. Por ejemplo, de
la clase empleado se pueden obtener las subclases secretaria, técnico e ingeniero.

Indica que una subclase hereda los métodos y atributos especificados por una superclase, de esta
forma la subclase además de poseer sus propios métodos y atributos, poseerá las características y
atributos visibles de la superclase (public y protected).

_____________________

Agregación. La agregación es un tipo de relación jerárquica entre un objeto que representa la

totalidad de ese objeto y las partes que lo componen. Permite el agrupamiento fi ́sico de estructuras
relacionadas lógicamente. Los objetos “son-parte-de” otro objeto completo. Por
ejemplo, motor, ruedas, carroceri ́a son parte de automóvil.

Para modelar objetos complejos, no es suficiente con 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).

______________________

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 tiempo de vida de un objeto no depende
del otro.
Las relaciones de asociación representan un conjunto de enlaces entre objetos o instancias de
clases. Es el tipo de relación más general, y denota básicamente una dependencia semántica. Por
ejemplo, una Persona trabaja para una Empresa.
Cada asociación puede presentar elementos adicionales que doten de mayor detalle al tipo de
relación:

Rol, o nombre de la asociación, que describe la semántica de la relación en el sentido indicado. Por
ejemplo, la asociación entre Persona y Empresa recibe el nombre de trabaja para, como rol en ese
sentido.

Multiplicidad, que describe la cardinalidad de la relación, es decir, especifica cuántas instancias de

una clase están asociadas a una instancia de la otra clase. Los tipos de multiplicidad son: Uno a uno,
uno a muchos y muchos a muchos.

________________________

Composición. La composición es una forma de agregación donde la relación de propiedad es más

fuerte, e incluso coinciden los tiempos de vida del objeto completo y las partes que lo componen.
Por ejemplo, en un sistema de Máquina de café, las relaciones entre la clase máquina y producto, o
entre máquina y depósito de monedas, son de composición.

_________________

Dependencia. Una relación de dependencia se utiliza entre dos clases o entre una clase y una
interfaz, e indica que una clase requiere de otra para proporcionar alguno de sus servicios.

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 denota 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 Gráfica que instancia una ventana (la creación del Objeto Ventana esta condicionado
a la instanciación proveniente desde el objeto Aplicación):

----------------------------------------

Interfaces

Una interfaz es una especificación de la semántica de un conjunto de operaciones de una clase o

paquete que son visibles desde otras clases o paquetes. Normalmente, se corresponde con una
parte del comportamiento del elemento que la proporciona.

Paquetes

Los paquetes se usan para dividir el modelo de clases del sistema de información, agrupando clases
u otros paquetes según los criterios que sean oportunos. Las dependencias entre ellos se definen a
partir de las relaciones establecidas entre los distintos elementos que se agrupan en estos paquetes.
CLASES
Una clase se representa como una caja, separada en tres zonas por li ́neas horizontales.

En la zona superior se muestra el nombre de la clase y propiedades generales como el estereotipo.

El nombre de la clase aparece centrado y si la clase es abstracta se representa en cursiva. El
estereotipo, si se muestra, se sitúa sobre el nombre y entre el si ́mbolo: << .... >>.

La zona central contiene una lista de atributos, uno en cada li ́nea. La notación utilizada para
representarlos incluye, dependiendo del detalle, el nombre del atributo, su tipo y su valor por
defecto, con el formato:

visibilidad nombre : tipo = valor-inicial { propiedades }

La visibilidad será en general publica (+), privada (-) o protegida (#), aunque puede haber otros tipos
de visibilidad dependiendo del lenguaje de programación empleado.

En la zona inferior se incluye una lista con las operaciones que proporciona la clase. Cada operación
aparece en una li ́nea con formato:

visibilidad nombre (lista-de-parámetros): tipo-devuelto { propiedad }

La visibilidad será en general publica (+), privada (-) o protegida (#), aunque como con los atributos,
puede haber otros tipos de visibilidad dependiendo del lenguaje de programación. La lista de
parámetros es una lista con los parámetros recibidos en la operación separados por comas. El
formato de un parámetro es:

nombre : tipo = valor-por-defecto

La notación especificada se puede simplificar según el nivel de detalle con el que se quiera trabajar
en un momento dado.

Relaciones

Una relación de asociación se representa como una li ́nea continua entre las clases asociadas. En una
relación de asociación, ambos extremos de la li ́nea pueden conectar con la misma clase, indicando
que una instancia de una clase, está asociada a otras instancias de la misma clase, lo que se conoce
como asociación reflexiva.

La relación puede tener un nombre y un estereotipo, que se colocan junto a la li ́nea. El nombre suele
corresponderse con expresiones verbales presentes en las especificaciones, y define la semántica
de la asociación. Los estereotipos permiten clasificar las relaciones en familias y se escribirán entre
el si ́mbolo: << ... >>.

Las diferentes propiedades de la relación se pueden representar con la siguiente notación:

Multiplicidad: La multiplicidad puede ser un número concreto, un rango o una colección de

números. La letra ‘n’ y el si ́mbolo ‘*’ representan cualquier número.

Orden: Se puede especificar si las instancias guardan un orden con la palabra clave ‘{ordered}’. Si el
modelo es suficientemente detallado, se puede incluir una restricción que indique el criterio de
ordenación.

Navegabilidad: La navegación desde una clase a la otra se representa poniendo una flecha sin
relleno en el extremo de la li ́nea, indicando el sentido de la navegación.

Rol o nombre de la asociación: Este nombre se coloca junto al extremo de la li ́nea que esta unida a
una clase, para expresar cómo esa clase hace uso de la otra clase con la que mantiene la asociación.
Además, existen notaciones especi ́ficas para los otros tipos de relación, como son:

Agregación: Se representa con un rombo hueco en la clase cuya instancia es una agregación de las
instancias de la otra.

Composición: Se representa con un rombo lleno en la clase cuya instancia contiene las instancias
de la otra clase.

Dependencia: Una li ́nea discontinua con una flecha apuntando a la clase cliente. La relación puede
tener un estereotipo que se coloca junto a la li ́nea, y entre el si ́mbolo: << ... >>.

Herencia: Esta relación se representa como una li ́nea continua con una flecha hueca en el extremo
que apunta a la superclase.

DIAGRAMA DE CLASES

Una clase es una descripción de conjunto de objetos que comparten los mismos atributos,
operaciones, métodos, relaciones y semántica.
Las clases son gráficamente representadas por cajas con compartimentos para:
Nombre de la clase, atributos y operaciones / métodos
Responsabilidades, Reglas, Historia de Modificaciones, etc
Los diseñadores desarrollan clases como conjuntos de compartimentos que crecen en el
tiempo agregando incrementalmente aspectos y funcionalidades.
Clases parametrizadas.

Template no es directamente utilizable.

Parámetros, nbre [: expTipo]
Utilidad: es una agrupación de variables globales y procedimientos en la forma de
declaración de clase.
Metaclase: clase cuyas instancias son clases.
Objeto: Subrayado con valores particulares.
Notación Notación: Interface
Iortografía
• Una interface es una colección de operaciones que especifican un servicio de una clase o
componente, es decir, un comportamiento externamente visible de ese elemento.
• Se especifican las operaciones externamente visibles sin especificación de la estructura
interna.
Modelado de Clases
• Una Responsabilidad es un contrato u obligación de una clase.
• Modelado del Vocabulario
– Identificar los conceptos que usan los usuarios (Tarjetas CRC - casos de uso)
– Para cada abstracción, identificar el conjunto de responsabilidades. Cada clase debe estar
bien definida y un buen reparto de responsabilidades.
– Proporcionar atributos y operaciones necesarios para cumplir con dichas
responsabilidades.
• Clases muy grandes (varias responsabilidades) -> dificil de cambiar y no reutilización.
• Clases muy pequeñas -> modelo dificil de entender.
•Modelado de conceptos que no son software.
- Se modela como una clase
- Para distinguirla de clases del sistema se usa un nuevo bloque de construcción con
estereotipos.
- Si es un hardware que tiene software > nodo. -
•Modelado de tipos primitivos.
- Se modela como una clase con el estereotipo adecuado.
- Si se necesita especificar el rango, se usa restricciones.
•Una clase debe:
- proporcionar una abstracción bien definida de algo del dominio del problema o de la
solución
- Contiene un conjunto pequeño de responsabilidades
- Muestra una clara distinción entre la implementación y la especificación de la
abstracción.
- Ser sencilla, entendible, extensible y adaptable.
Final de asociación:
- multiplicidad
- orden {unordered} (default), {ordered}
- navegación
 - agregación. Diamante lleno es composición.
- Nombre del rol
- cambiable (default) {frozen} {addOnly}
- visibilidad
Asociación binaria. Opcional {or}. Asociación n aria. n-
Clase asociación: es una asociación que tiene propiedades de una clase.
Composición. Tpo de vida. Multiplicidad del contenedor=1
Generalización. Discriminador.
- Restricción: {ovelapping},{disjoint},{complete},{incomplete}
Relación de dependencia
- <<amport>> <<access>> <<become>>, <<bind>>
Dependencia
- Parámetro de una operación. Si se muestra la signatura no es necesario la relación
de dependencia
Generalización
- Dado un cjto de clases, se busca responsabilidades, atributos y operaciones
comunes.
- Se elevan a una clase más general (nueva o no). No crear demasiados niveles.
Asociación.
- Relación estructural. Relación bilateral. Diferencia con dependencia y
Generalización.
- Equilibradas. Ni muy profundas (<=5 niveles) ni muy anchas.
- Herencia múltiple se puede reemplazar por agregación.
Elementos del Diagrama de Clase
Estático: Diagrama de Clase
• Utilizado para la estructura estática del modelo conceptual / Dominio
• El diagrama de clase describe
– Tipos de objetos en la aplicación / dominio
– Relaciones estáticas entre objetos
• El diagrama de clase contiene
– Clases: Objetos Objetos, Atributos and Responsabilidades
– Paquetes: Agrupación de clases
– Subsistemas: Agrupación de clases/paquetes.

MODELO CONCEPTUAL/DEL DOMINIO

 Un Modelo Conceptual /Dominio es el conjunto de diagramas de estructura estático
con clases, atributos y asociaciones, pero no operaciones.
 Construcción del Modelo Conceptual / Dominio
- Representa un aspecto de la realidad
- Ayuda a los Ingenieros de Sofware a gestionar la complejidad
- Es más simple que la realidad

 Un Modelo Conceptual / Dominio debería:

- Organizar Datos dentro de Objetos y Clases
- Estructurar Datos vía herencia y asociaciones
 - Especificar comportamiento e interfaces públicas
- Describir el comportamiento global
- Describir Restricciones

Relaciones entre Paquetes

• Importación. Relación de dependencia con:
– <<import>> añade el contenido del destino al espacio de nombres del origen.
– <<access>> no lo añade. Se deben calificar los nombres.
– La dependencia de importación no es transitiva.
• Exportación. Se especifica el elemento con su visibilidad.
– Visibilidad: +, #, -.
• Generalización.
– Heredan los elementos públicos y privados.
– Pueden redefinir elementos y añadir nuevos.
–Un paquete especializado puede usarse en cualquier lugar que se utilice un paquete más
general.
• Estereotipos: facade (vista), framework framework, , stub stub, , subsystem subsystem, ,
system system.
Diagramas de Objetos
- Muestra instancias compatibles con un diagrama de clase particular.
- Incluye sus objetos y los valores de sus datos.
- Snapshot del estado detallado del sistema en un punto del tipo.