La explicaci�n se basar� en los diagramas, en lugar de en vistas o anotaci�n, ya que son estos la esencia de UML. Cada diagrama usa la anotaci�n pertinente y la suma de estos diagramas crean las diferentes vistas. Las vistas existentes en UML son:
- Vista casos de uso: Se forma con los diagramas de casos de uso, colaboraci�n, estados y actividades.
- Vista de dise�o: Se forma con los diagramas de clases, objetos, colaboraci�n, estados y actividades.
- Vista de procesos: Se forma con los diagramas de la vista de dise�o. Recalcando las clases y objetos referentes a procesos.
- Vista de implementaci�n: Se forma con los diagramas de componentes, colaboraci�n, estados y actividades.
- Vista de despliegue: Se forma con los diagramas de despligue, interacci�n, estados y actividades.
Se Dispone de dos tipos diferentes de diagramas los que dan una vista est�tica del sistema y los que dan una visi�n din�mica. Los diagramas estaticos son:
- Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los m�s comunes y dan una vista est�tica del proyecto.
- Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visi�n de casos reales.
- Diagrama de componentes: Muestran la organizaci�n de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
- Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e �ndice.
- Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.
Lo diagramas din�micos son:
- Diagrama de secuencia, Diagrama de colaboraci�n: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se env�an entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de informaci�n, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacci�n.
- Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son �tiles en sistemas que reaccionen a eventos.
- Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
Como podemos ver el n�mero de diagramas es muy alto, en la mayor�a de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dar� una breve explicaci�n de todos, ampli�ndose para los m�s necesarios.
�Diagramas recomendados
Los diagramas a representar depender�n del sistema a desarrollar, para ello se efectuan las siguientes recomendaciones dependiendo del sistema. Estas recomendaciones se deber�n adaptar a las caracter�sticas de cada desarrollo, y seguramente ser� la practica lo que nos diga las cosas que echamos en falta o los diagramas que parecen ser menos necesarios.
- Aplicaci�n monopuesto
- Diagrama de casos de uso.
- Diagrama de clases.
- Diagrama de interacci�n.
- Aplicaci�n monopuesto, con entrada de eventos:
- A�adir: Diagrama de estados.
- Aplicaci�n cliente servidor:
- A�adir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
- Aplicaci�n compleja distribuida:
- Todos.
As� tenemos que para una aplicaci�n sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicaci�n compleja unos nueve tipos. �Es esto demasiado trabajo? En un principio no lo parece, ya que el tiempo dedicado a la realizaci�n de los diagramas es proporcional al tama�o del producto a realizar, no entraremos en la discusi�n de que el tiempo de dise�o no es tiempo perdido si no ganado. Para la mayor�a de los casos tendremos suficiente con tres o cuatro diagramas. Debemos pensar que UML esta pensado para el modelado tanto de peque�os sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de l�neas de c�digo y ser realizados por equipos de centenares de programadores. As� que no debemos preocuparnos, el mayor de nuestros proyectos, desde el punto de vista de UML no deja de ser un proyecto mediano tirando a peque�o.