Clase:
es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces.
Interfaz:
es una colección de operaciones que especifican un servicio de una clase o componente.
Por lo tanto, una interfaz describe el comportamiento visible externamente de ese elemento.
Una interfaz puede representar el comportamiento completo de una clase o componente o sólo una parte de este comportamiento. Una interfaz define un conjunto de especificaciones de operaciones (o sea, sus signaturas), pero nunca sus implementaciones. Una interfaz raramente se encuentra asilada, más bien, suele estar conectada a la clase o componente que la realiza.
Colaboración:
define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Por lo tanto las colaboraciones tienen dimensión tanto estructural como de comportamiento. Una clase dada puede participar en varias colaboraciones.
Caso de uso:
Es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo. Un caso de uso es realizado por una colaboración.
Existen otros tres elementos estructurales que son similares a las clases: clase activa, componente, y nodo.
Clase activa:
es una clase cuyos objetos tienen uno o más procesos o hilos que constituyen flujos de control independientes pero concurrentes con otros flujos de control (con los que muy probablemente se deberán sincronizar). Una clase activa es igual que una clase, excepto en que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.
Un componente es una parte física de un sistema que ofrece un conjunto de interfaces y proporciona la implementación de dicho conjunto. En un sistema, se pueden encontrar diferentes tipos de componentes de despliegue, tales como componentes COM+, JavBeans, así como componentes que sean artefactos del proceso de desarrollo, tales como archivos de código fuente.
Componente:
representa típicamente el empaquetamiento físico de diferentes elementos lógico, como clases interfaces y colaboraciones.
Nodo:
es un elemento físico que existe en tiempo de ejecución, representando un recurso computacional que, por lo general, dispone de algo de memoria y con frecuencia capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo y puede también migrar de un nodo a otro.
Elementos de comportamiento
Interacción:
es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito específico. Una interacción involucra muchos otros elementos, incluyendo mensajes, secuencias de acción y enlaces.
Máquina de estados:
es un comportamiento que especifica la secuencia de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos. Una máquina de estados involucra a otros elementos, incluyendo estados, transiciones, eventos y actividades.
Elementos de agrupación
Son las partes organizativas de los modelos UML. Hay un elemento de agrupación principal, los paquetes. Un paquete es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, e incluso otros elementos de agrupación pueden incluirse en un paquete. Al contrario de los componentes (que existen en tiempo de ejecución), un paquete es puramente conceptual (sólo existe en tiempo de desarrollo).
Elementos de anotación
Son las partes explicativas de los modelo UML. Hay un tipo principal llamado Nota. Una nota es simplemente un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos. Las notas se utilizan para adornar los diagramas con restricciones o comentarios que se expresan mejor en texto informal o formal.
Relaciones en UML
Dependencia:
es una relación semántica entre dos elementos, en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semántica del otro elemento (el dependiente). Las dependencias generalmente representan relaciones de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que la utiliza, pero no necesariamente a la inversa. Por ejemplo un refinamiento de un elemento de diseño a un elemento de implementación. La mayoría de las veces se utilizan en el contexto de las clases o paquetes, aunque también son habituales en la vinculación de notas.
Asociación:
es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación, que representa una relación estructural entre un todo y sus partes.
Generalización:
es un a relación de especialización generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma el hijo comparte la estructura y el comportamiento del padre.
Realización:
es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización: entre interfaces y las clases o componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan.
Diagramas en UML
Un diagrama es la representación gráfica de un conjunto de elementos, visualizando la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar el sistema desde diferentes perspectivas, de forma que un diagrama es una proyección de un sistema. En teoría un diagrama puede contener cualquier combinación de elementos y relaciones, sin embargo en la práctica solo surge un peque no número de combinaciones:
Diagrama de clases.
Diagrama de objetos.
Diagrama de casos de uso.
Diagrama de secuencia.
Diagrama de colaboración.
Diagrama de estados.
Diagrama de actividades.
Diagrama de componentes.
Diagrama de despliegue
Diagrama de Actividades
Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un caso de uso, así como las distintas rutas que pueden irse desencadenando en el caso de uso.
Un diagrama de actividad es utilizado en conjunción de un diagrama casos de uso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y cómo reacciona en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solución.
Composición
Inicio:
El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.
Actividad:
Una actividad representa la acción que será realizada por el sistema la cual es representada dentro de un ovalo.
Transición:
Una transición ocurre cuando se lleva a cabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección.
Ramificación (Branch):
Una ramificación ocurre cuando existe la posibilidad que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento es representado a través de un rombo.
Uníón (Merge):
Una uníón ocurre al fusionar dos o más transiciones en una sola transición o actividad. Este elemento también es representado a través de un rombo.
Expresiones Resguardadas (Guard Expressions):
Una expresión resguardada es utilizada para indicar una descripción explicita acerca de una transición. Este tipo de expresión es representada mediante corchetes ([…] y es colocada sobre la línea de transición.
Fork:
Un fork representa una necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por ambos o más caminos, mientras que una ramificación (Branch) representa una transición u otra para la actividad (como una condicional). Un fork es representado por una línea negra solida, perpendicular a las líneas de transición .
Join:
Una join ocurre al fusionar dos o más transiciones provenientes de un fork, y es empleado para dichas transiciones en una sola, tal y como ocurría antes de un fork .Un fork es representado por una línea negra solida, perpendicular a las líneas de transición.
Fin:
El fin de un diagrama de actividad es representado por un círculo, con otro círculo concéntrico de color negro sólido.
Canales (Swimlanes):
En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que está llevando a cabo la actividad.
Diagrama Casos de Usos
Un diagrama caso de uso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.
Determinación de Requerimientos:
Por lo general nuevos requerimientos de sistema generan nuevos usos-casos, conforme es analizado y diseñado el sistema.
Comunicación con el Cliente:
Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto.
Generación de pruebas de Sistemas:
A través de los diagramas uso-caso se pueden generar una serie de pruebas de sistema.
Componente de un diagrama de casos de uso.
Actor:
Un actor representa quien o que inicia una acción dentro del sistema, en otras palabras, es simplemente un rol que es llevado a cabo por una persona o cosa. Un Actor en un diagrama casos de usos es representado por una figura en forma de persona.
Uso-Caso:
El caso de uso en sí es representado por un ovalo que describe la funcionalidad a grosso modo que se requiere por el sistema.
Comunicación:
Este elemento representa la relación que existe entre un caso de uso y un Actor, dicho elemento es representado simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del caso de uso.
Limite de Sistema (System Boundry):
Empleado para delimitar los límites del sistema, y representado por un rectángulo con color de fondo distintivo.
Generalización:
Una generalización indica que un caso de uso (ovalo) es un caso especial de otro caso, en otros términos, representa una relación padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento. Este elemento es representado por una línea con flecha que se extiende del caso de uso hijo hacia el caso de uso padre (general).
Inclusión:
Una inclusión es utilizada para indicar que un caso de uso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una línea punteada con flecha y comentario > que se extiende del caso de uso base hacia el caso de uso de inclusión.
Extensión:
Una extensión representa una variación de un caso de uso a otro, aunque similar a una generalización, una extensión representa una dependencia especifica, mientras una generalización no implica que los casos de usos dependen uno del otro. Este elemento es representado por una línea punteada con flecha y comentario > que origina del caso de uso base hacia el caso de uso de extensión.