UF3: UML Flashcards
(40 cards)
UML
Unified Modeling Languaje.
Lenguaje que se utiliza para documentar.
Es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software.
Se puede utilizar para: modelar sistemas de software, hardware u organizaciones.
Utiliza diagramas.
Existen 2 grandes versiones de UML
- UML1.x (finales de los 90)
- UML2.x (2005)
TIPOS DE DIAGRAMA
- Diagrama de estructura (parte estática del modelo)
- Diagrama de clases
- Diagrama de estructuras compuestas
- Diagrama de componentes
- Diagrama de despliegue
- Diagrama de objetos
- Diagrama de paquetes
- Diagrama de comportamientos (parte dinámica del modelo).
- Diagrama de interacción (se centran en el flujo de control y de datos entre los elementos del sistema modelado)
- Diagrama de secuencia
- Diagrama de resumen de interacción
- Diagrama de comunicación
- Diagrama de tiempo
- Diagrama de actividad
- Diagrama de casos de uso
- Diagrama de máquina de estado
Diagrama de estructura
Parte estática del modelo
Diagramas de comportamiento
Parte dinámica del modelo
OBJETO
Un objeto es la instancia de una clase.
Y está constituido por un conjunto de atributos (valores), métodos (acciones) e identidad propia (que lo distingue de los demás objetos.
La estructura y comportamiento de objetos similares tendrán una clase común.
Una clase es: un conjunto de objetos con estructura y comportamientos similares.
PRINCIPIOS DEL MODELO ORIENTADO A OBJETOS
- Abstracción: características esenciales de un objeto de tal forma que lo distingue de los demás. Indican que trabajo va a realizar ese objeto, como se comunica con los demás, sin necesidad de mostrar como se implementan esas características.
- Encapsulación: conjunto de elementos que pertenecen a la misma entidad y al mismo nivel de abstracción. Gracias a esto, permite una mayor cohesión de sus componentes y separa la parte interna inaccesible para otros objetos de la externa, que sí será accesible. Oculta los métodos y atributos a otros objetos, pasando a ser privados.
- Modularidad: es la capacidad de un sistema o aplicación para dividirse en pequeños módulos independientes.
- Jerarquía o herencia: propiedad que permite que algunas clases tengan propiedades y características de una clase superior. La clase principal se llama clase padre o superclase. La nueva clase se denominará clase hija o subclase, que heredará todos los métodos y atributos de la superclase. Cada subclase estará formada con objetos más especializados.
- Polimorfismo: cuando dos instancias u objetos pertenecientes a distintas clases pueden responder a la llamada a métodos del mismo nombre, cada uno de ellos con distinto comportamiento encapsulado. Ambos responden a una interfaz común (marcada a través del mecanismo de la herencia).
- Tipificación: definición precisa de un objeto de forma que objetos de diferentes tipos no se pueden intercambiar.
- Concurrencia: propiedad de un objeto que está activo respecto de otro que no lo está.
- Persistencia: propiedad de un objeto en virtud de la cual su existencia trasciende en el tiempo y/o el espacio.
DIAGRAMA DE CLASES:
Clase
Una representación gráfica y estática de la estructura general de un sistema, mostrando cada una de las clases (atributos, métodos y visibilidad) y sus interacciones (relaciones: asociación, herencia, agregación, composición, realización y dependencia) representadas en forma de bloques. Vamos a poder visualizar las relaciones que existen entre las clases.
Estará compuesto por los siguientes elementos:
- Clases: atributos, métodos y visibilidad.
- Relaciones: asociación, herencia, agregación, composición y dependencia.
Representación de una clase en UML
DIAGRAMA DE CLASES
Podemos representarla con un rectángulo dividido en tres partes:
- Parte superior: nombre de la clase.
- Parte central: atributos, que caracterizan la clase (private, protected, package o public).
- Parte inferior: métodos u operaciones, forma de interactuar del objeto con el entorno (según visibilidad: private, protected, package o public).
Al representar la clase, podemos obviar señalar los atributos y métodos. La visibilidad de los métodos debe ser por defecto public, y la de los atributos, private.
Atributos y métodos pueden ser
DIAGRAMA DE CLASES
- Public: Visible tanto dentro como fuera de la clase. “+”
- Private: Visible dentro de la clase. “-“
- Protected: No será accesible desde fuera de la clase, pero sí por los métodos de la clase y subclases. “#”.
- Package: Será visible en las clases del mismo paquete. “~”
Relaciones
DIAGRAMA DE CLASE
Los objetos estarán vinculados entre sí, y se corresponden con asociaciones entre objetos En UML estos vínculos se describen a través de asociaciones al igual que los objetos se describen mediante clases.
Poseen un nombre y una cardinalidad llamada multiplicidad, que representa el número de instancias de una clase que se relaciona con las instancias de otra clase: La asociación es similar a la utilizada en el modelo entidad/relación. En cada extremo será posible indicar la multiplicidad mínima y máxima para indicar el intervalo de valores al que tendrá que pertenecer siempre la multiplicidad
Notación:
Tipos de Relaciones
DIAGRAMA DE CLASE
-
ASOCIACIÓN (dependiendo de si una conoce la existencia de la otra, clase cuenta con un rol, que se indica en la parte superior o inferior de la línea que conecta a ambas clases, y, además, este vínculo también tendrá un nombre, representado con una línea que conecta a ambas clases.):
- Unidireccional: la clase destino no sabrá de la existencia de la clase origen y la clase origen contendrá un objeto o set de objetos de la clase destino.
- Bidireccional: se puede recorrer en ambos sentidos entre las dos clases.
Dependiendo de la multiplicidad, podemos pasar de un objeto de una clase a uno o varios de la otra. A este proceso se le llama navegabilidad. En la asociación unidireccional, la navegabilidad es solo en un sentido, desde el origen al destino, pero no al contrario. Algunas clases pueden asociarse consigo mismas, creando así una _asociación reflexiva_. Estas asociaciones unen entre sí instancias de una misma clase.
-
HERENCIA: Podremos organizar las clases de forma jerárquica y, gracias a la herencia, seremos capaces de compartir atributos y operaciones comunes con las demás clases a través de una superclase. Las demás clases se conocen como subclases.
- La subclase hereda los atributos y métodos de la otra. La superclase generaliza a las subclases y las subclases especializan a la superclase. para representar esta asociación se usará una flecha, donde el extremo de la flecha apunta a la superclase.
- La superclase
- Generalización
- Especialización
- CLASE ASOCIACIÓN: Hay asociaciones entre clases que podrán tener información necesaria para dicha relación.
-
COMPOSICIÓN: consiste en que un objeto puede estar compuesto por otros objetos. Existirán dos formas:
- asociación fuerte, conocida como composición (los objetos están constituidos por componentes y la supresión del objeto comporta la supresión de los componentes. La cardinalidad será de uno a varios. Se representa con una línea con un rombo lleno).
- asociación débil, conocida como agregación.
- REALIZACIÓN: Relación de herencia que existe entre la clase interfaz y una subclase que implementa esa interfaz.
- DEPENDENCIA: Muestra la relación entre un cliente y un proveedor de un servicio usado por el cliente.. (Ej. Clase Ecuación - - - - -> Clase Math)
Asociación
DIAGRAMA DE CLASE
- Unidireccional
- Bidireccional
Determina navegabilidad
Asociación reflexiva
DIAGRAMA DE CLASE
Se da cuando una instancia de clase se relaciona con otra instancia de su misma clase (Ej: empleado - empleado jefe)
Clase asociación
DIAGRAMA DE CLASE
Hay asociaciones entre clases que podrán tener información necesaria para dicha relación.
HERENCIA (GENERALIZACIÓN / ESPECIALIZACIÓN)
DIAGRAMA DE CLASE
El extremo de la flecha apuntará a la superclase.
COMPOSICIÓN (FUERTE)
DIAGRAMA DE CLASE
Los componentes no pueden ser compartidos con otros objetos compuestos y nacen y mueren con su objeto.
AGREGACIÓN (DÉBIL)
DIAGRAMA DE CLASE
REALIZACIÓN
DIAGRAMA DE CLASE
Relación de herencia que existe entre la clase interfaz y una subclase que implementa esa interfaz.
DEPENDENCIA
DIAGRAMA DE CLASE
Muestra la relación entre un cliente y un proveedor de un servicio usado por el cliente.. (Ej. Clase Ecuación - - - - -> Clase Math)
NOTACIÓN (CARDINALIDAD/MULTIPLICIDAD)
DIAGRAMA DE CLASE
HERRAMIENTAS PARA EL DISEÑO DE DIAGRAMAS
Papyrus para Eclipse Es una herramienta de modelado UML de código abierto e incluye soporte para todos los diagramas UML
Características
- De código abierto basado en el entorno Eclipse.
- Proporciona un entorno integrado para el usuario para editar cualquier tipo de modelo EFM (metamodelos).
- Proporciona editores de diagramas para lenguajes como UML 2 y SysML.
- Tiene un soporte de perfil de usuario.
- En términos generales, tiene formas de personalización muy potentes que pueden ser definidas por el usuario.
Cuatro paneles principales:
- Panel principal: es donde colocaremos nuestros elementos del diagrama que queramos modelar.
- Panel del proyecto: referencia a la estructura de nuestro proyecto principal.
- Panel de propiedades: en este panel daremos valores a las propiedades de nuestros elementos del diagrama.
- Panel de nodes y edges: en la parte de nodes, podemos elegir el tipo de elemento de nuestro diagrama.En la parte de edges elegiremos qué tipo de relación tendrán nuestros elementos. Por ejemplo, en un diagrama de casos de uso, tendremos relaciones de <> o de <>.
Creación de diagramas de clase 4 partes principales
- Nombre de la clase.
- Atributos de la clase que ya hemos comentado que pueden ser públicos, privados, protegidos o package
- Métodos de la clase exactamente igual que los atributos.
- Nested classifiers: limita la visibilidad del clasificador definido en la clase o interfaz al alcance del namespace para poder encapsular la información.
Dentro del panel de propiedades, podemos encontrar los tipos de modificadores:
- Is Abstract: indica si la clase es abstracta.
- Is Active: indica si la clase es activa. Para que lo sea, debe poseer objetos activos, es decir, que realicen uno o más procesos. Si no realizan ninguna actividad, serán objetos pasivos.
DIAGRAMAS DE COMPORTAMIENTO
Nos permiten modelar la información que hemos manejado anteriormente con los diagramas de clase.
Mostrarán el comportamiento de un sistema.
DIAGRAMAS DE CASOS DE USO
Van a: modelar el sistema desde el punto de vista del usuario. Con esta herramienta vamos a poder obtener los requisitos de software en la fase de análisis de un proyecto.
Objetivos:
- Definir los requisitos funcionales y operativos del sistema.
- Proporcionar descripción clara sobre la interacción entre usuario y sistema.
- Facilitar una base para la validación de pruebas.
Componentes:
- Actores: Cualquier agente que interactúa con el sistema y es externo a él. Aunque se representa con un monigote y un nombre debajo, no tiene por qué ser una persona.
- Casos de uso: Unidad funcional del sistema que realizará una orden de algún agente externo. Se representará con un óvalo o eclipse y una descripción textual.
- Relaciones: Representadas por una línea continua.
- Sistema: Rectángulo que delimita el sistema.
Identificar:
-
Identificar a actores: Son unidades externas que van a interactuar con el sistema. Normalmente son personas, pero pueden ser otros sistemas o incluso dispositivos Para poder interactuar con el sistema hay que conocer la información de cada elemento para saber qué y quién interactúa con el sistema y qué rol tendrá cuando se interactúe con él Puntos a la hora de definir los actores:
- Serán siempre externos al sistema.
- Van a interactuar directamente con el sistema.
- Representan roles de personas o elementos que desempeñan en relación con el sistema. • Necesitan un nombre que describa la función que desempeñan.
- Una misma persona o elemento puede desempeñar varios roles como actores distintos.
- Identificar casos de uso Para identificarlos, será necesario entender el funcionamiento del sistema y lo que quiere hacer. Para ello tendremos que buscar los actores que participan y saber cómo lo usarán. Para documentar los casos de uso, podremos hacerlo a través de una plantilla que nos describa lo que hace el actor y lo que ocurre cuando se interactúa con dicho sistema.
