¿Qué es UML?
Es una herramienta que ayuda a capturar mediante un conjunto de símbolos y
diagramas a comunicar la idea de un sistema (software orientado a objetos), a
quien esté involucrado en su proceso de desarrollo sirviendo de apoyo en los
procesos de análisis y diseño de un problema.
¿Para qué se utiliza?
Capturar las partes esenciales del sistema mediante notaciones graficas.
¿Por qué es importante en el desarrollo de software?
Permite crear una representación visual de un sistema antes de comenzar a escribir
código.
• Diagrama de clases
El diagrama de clases es un diagrama puramente orientado al modelo de
programación orientado a objetos, ya que define las clases que se
utilizarán cuando se pase a la fase de construcción y la manera en que se
relacionan las mismas. Se podría equiparar, salvando las distancias, al
famoso diagrama de modelo Entidad-Relación (E/R), no recogido en UML,
tiene una utilidad similar: la representación de datos y su interacción. Ambos
diagramas muestran el modelo lógico de los datos de un sistema.
Elementos del diagrama de clases:
❖ Clases: Son el elemento principal del diagrama y representa, como su
nombre indica, una clase dentro del paradigma de la orientación a
objetos. Este tipo de elementos normalmente se utilizan para
representar conceptos o entidades del «negocio». Una clase define
un grupo de objetos que comparten características, condiciones y
significado. La manera más rápida para encontrar clases sobre un
enunciado, sobre una idea de negocio o, en general, sobre un tema
concreto es buscar los sustantivos que aparecen en el mismo. Es un
concepto muy amplio y resulta fundamental identificar de forma
efectiva estas clases, en caso de no hacerlo correctamente se
obtendrán una serie de problemas en etapas posteriores, teniendo
que volver a hacer el análisis y perdiendo parte o todo el trabajo que
se ha hecho hasta ese momento.
Una clase está compuesta por tres elementos: nombre de la clase,
atributos, funciones. Estos elementos se incluyen en la
representación (o no, dependiendo del nivel de análisis).
Para representar la clase con estos elementos se utiliza una caja que
es dividida en tres zonas utilizando para ello líneas horizontales:
✓ La primera de ellas se utiliza para el nombre de la clase. En
caso de que la clase sea abstracta se utilizará su nombre en
cursiva.
✓ La segunda, por otra parte, se utiliza para escribir
los atributos de la clase, uno por línea y utilizando el siguiente
formato:
visibilidad nombre_atributo : tipo = valor-inicial { propiedades }
✓ La última de las zonas incluye cada una de las funciones que
ofrece la clase. De forma parecida a los atributos, sigue el
siguiente formato:
visibilidad nombre_funcion { parametros } : tipo-devuelto {
propiedades }
De la misma manera que con los atributos, se suele simplificar
indicando únicamente el nombre de la función y, en ocasiones,
el tipo devuelto.
❖ Relaciones: Una relación identifica una dependencia. Esta
dependencia puede ser entre dos o más clases (más común) o una
clase hacía sí misma (menos común, pero existen), este último tipo de
dependencia se denomina dependencia reflexiva. Las relaciones se
representan con una linea que une las clases, esta línea variará
dependiendo del tipo de relación.
Las relaciones en el diagrama de clases tienen varias propiedades,
que dependiendo la profundidad que se quiera dar al diagrama se
representarán o no. Estas propiedades son las siguientes:
✓ Multiplicidad. Es decir, el número de elementos de una clase
que participan en una relación. Se puede indicar un número, un
rango… Se utiliza n o * para identificar un número cualquiera.
✓ Nombre de la asociación. En ocasiones se escriba una
indicación de la asociación que ayuda a entender la relación
que tienen dos clases.
Tipos de relaciones:
➢ Asociación: Este tipo de relación es el más común y se
utiliza para representar dependencia semántica. Se
representa con una simple línea continua que une las
clases que están incluidas en la asociación.
➢ Agregación: Es una representación jerárquica que
indica a un objeto y las partes que componen ese objeto.
Es decir, representa relaciones en las que un objeto es
parte de otro, pero aun así debe tener existencia en sí
mismo.
Se representa con una línea que tiene un rombo en la
parte de la clase que es una agregación de la otra clase.
➢ Composición: Es similar a la agregación, representa
una relación jerárquica entre un objeto y las partes
que lo componen, pero de una forma más fuerte. En
este caso, los elementos que forman parte no tienen
sentido de existencia cuando el primero no existe. Es
decir, cuando el elemento que contiene los otros
desaparece, deben desaparecer todos ya que no tienen
sentido por sí mismos, sino que dependen del elemento
que componen. Además, suelen tener los mismos
tiempos de vida. Los componentes no se comparten
entre varios elementos, esta es otra de las diferencias
con la agregación.
Se representa con una línea continua con un rombo
relleno en la clase que es compuesta.
➢ Dependencia: Se utiliza este tipo de relación
para representar que una clase requiere de otra para
ofrecer sus funcionalidades. Es muy sencilla y se
representa con una flecha discontinua que va desde la
clase que necesita la utilidad de la otra flecha hasta esta
misma.
➢ Herencia: Este tipo de relaciones permiten que una
clase (clase hija o subclase) reciba los atributos y
métodos de otra clase (clase padre o superclase).
Estos atributos y métodos recibidos se suman a los que
la clase tiene por sí misma.
➢ Interfaces: Una interfaz es una entidad que declara
una serie de atributos, funciones y obligaciones. Es
una especie de contrato donde toda instancia asociada
a una interfaz debe de implementar los servicios que
indica aquella interfaz.
Dado que únicamente son declaraciones no pueden ser
instanciadas.
Las interfaces se asocian a clases. Una asociación entre
una clase y una interfaz representa que esa clase
cumple con el contrato que indica la interfaz, es decir,
incluye aquellas funciones y atributos que indica la
interfaz.
EJEMPLO:
• Diagrama de componentes
Los diagramas de componentes UML representan las relaciones entre los
componentes individuales del sistema mediante una vista de diseño estática.
Pueden ilustrar aspectos de modelado lógico y físico.
En el contexto del UML, los componentes son partes modulares de un
sistema independientes entre sí, que pueden reemplazarse con
componentes equivalentes. Son autocontenidos y encapsulan estructuras de
cualquier grado de complejidad. Los elementos encapsulados solo se
comunican con los otros a través de interfaces. Los componentes no solo
pueden proporcionar sus propias interfaces, sino que también pueden utilizar
las interfaces de otros componentes, por ejemplo, para acceder a sus
funciones y servicios. A su vez, las interfaces de un diagrama de
componentes documentan las relaciones y dependencias en una
arquitectura de software.
Los componentes suelen encapsular clases y, por lo tanto, también se los
conoce como subformas o especializaciones de clases. Al igual que las
clases, tienen una estructura compuesta y pueden definirse en más detalle
por medio de atributos, métodos y operaciones, por ejemplo. Los
componentes pueden ser una compilación de clases y, por ejemplo, ser
implementados simultáneamente por varias clases en tiempo de ejecución.
Aunque los componentes se equiparan a menudo con las clases, no son lo
mismo. Si bien los componentes suelen requerir interfaces para la
interacción, una clase también puede acceder directamente a un método.
Un diagrama de componentes proporciona una visión general del sistema y
documenta la organización de los componentes del sistema y sus relaciones
y dependencias mutuas. Los diagramas de componentes proporcionan
una visión orientada a la ejecución, es decir, dan al desarrollador información
sobre si un sistema funciona de forma coherente y cumple sus tareas y
objetivos.
Los objetivos y propósitos más importantes de este tipo de diagrama son el
modelado de sistemas de software basados en componentes, la
especificación de arquitecturas de software y la división de sistemas en
subsistemas (por ejemplo, interfaz gráfica de usuario/IGU, ámbito
empresarial y capa de persistencia con base de datos relacional). Asimismo,
se asignan tareas y funciones concretas a las subáreas y sus
interfaces dentro del sistema.
Ejemplo:
• Diagrama de implementación
Un Diagrama de Implementación es una representación visual que muestra
cómo se despliegan los artefactos del sistema en el hardware y software de
un entorno de ejecución. Este diagrama ilustra la distribución física de
componentes, nodos y recursos de software en una infraestructura
específica. Muestra la relación entre los elementos del sistema y los nodos
de procesamiento, comunicación y almacenamiento. Además, proporciona
detalles sobre la configuración de red, los servidores, los servicios y las
conexiones entre ellos. Los Diagramas de Implementación son esenciales
para planificar y comprender la arquitectura tecnológica y garantizar una
implementación eficiente y escalable de sistemas informáticos y de software.
Los diagramas de implementación tienen varias aplicaciones valiosas. Se
pueden utilizar para:
➢ Mostrar qué elementos de software se implementan mediante qué
elementos de hardware.
➢ Ilustrar el procesamiento en tiempo de ejecución para el hardware.
➢ Proporcionar una vista de la topología del sistema de hardware.
Ejemplo:
¿QUÉ ES? CLASES Y OBJETOS
Es una herramienta que
ayuda a capturar Las clases son
mediante un conjunto plantillas, y los
de símbolos y objetos son
diagramas a comunicar instancias de estas RELACIONES
la idea de un sistema clases
APLICACION EN EL Define cómo
DESARROLLO DE SOFTWARE interactúan las
Analisis de requisitos clases y los
Diseño del sistema objetos entre sí
Documentación de software en el sistema
Comunicación entre equipos
Detección de errores y
UML
mejoras
TIPOS DE DIAGRAMAS
UML incluye
múltiples tipos de
DIAGRAMA DE diagramas que
IMPLEMENTACIÓN representan
Es una representación visual diferentes aspectos
que muestra cómo se DIAGRAMA DE DIAGRAMA DE CLASES
en el sistema
despliegan los artefactos del COMPONENTES
sistema en el hardware y Representan las Es un diagrama
software de un entorno de relaciones entre los puramente
ejecución componentes individuales orientado al modelo
del sistema mediante una de programación
vista de diseño estática orientado a objetos
