Fundamentos de UML

Fundamentos de UML

1. Qué es un Objeto

   • Los objetos mantienen su estado en uno o más atributos, que son simplemente datos identificados por un nombre, y exhiben su comportamiento a través de métodos, que son trozos de funcionalidad asociados al objeto.
   • - Qué es una Clase
     • Una vez creado el objeto, pasa a ser una instancia particular de la clase a la que pertenece y sus atributos tienen unos valores concretos, que podrán variar de un objeto a otro (dos objetos distintos pertenecientes a la misma clase, pueden tener exactamente los mismos valores en todos sus atributos).
       • Hay atributos que, sin embargo, no varían de un objeto a otro, es decir todas las instancias de la clase a la que pertenecen, tienen el mismo valor para ese atributo
     • - Qué es la Herencia
       • La clase patrón se conoce con el nombre de superclase o clase padre, mientas que la que hereda se conoce como clase hija. La herencia no está limitada simplemente a padre-hija(s), la jerarquía puede ser todo lo profunda que sea necesario, hablando en términos de nietas, biznietas, etc
       • Qué es una Interfaz
         • Una interfaz es un mecanismo que emplean dos objetos para interactuar. En nuestro ejemplo de la tostadora, el humano emplea el botón de tostar a modo de interfaz para pasar el mensaje “tuesta el pan que tienes en la bandeja”.
         • El Lenguaje Unificado de Modelado, UML
           • El UML es un lenguaje de modelado cuyo vocabulario y sintaxis están ideados para la representación conceptual y física de un sistema

2. Bloques básicos de construcción de UML

   • Los bloques básicos de construcción de UML son tres, los elementos, las relaciones y los diagramas.
     • Los elementos
       • Los elementos de comportamiento son las partes dinámicas de los modelos y representan comportamientos en el tiempo y en el espacio. Los elementos de agrupación son las partes organizativas de UML, establecen las divisiones en que se puede fraccionar un modelo. Sólo hay un elemento de agrupación, el paquete, que se emplea para organizar otros elementos en grupos
         • Los elementos de notación son las partes explicativas de UML, comentarios que pueden describir textualmente cualquier aspecto de un modelo. Sólo hay un elemento de notación principal, la nota.
     • Las relaciones
       • son abstracciones que actúan como unión entre los distintos elementos. Hay cuatro tipos, la dependencia, la asociación, la generalización y la realización.
     • Los diagramas
       • s son la disposición de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas

3. - Elementos

   • • • • Relaciones
           • - Diagramas
             • - Diagrama de Clases y Diagrama de Objetos
               • Los diagramas de clases muestran un resumen del sistema en términos de sus clases y las relaciones entre ellas. Son diagramas estáticos que muestran qué es lo que interactúa, pero no cómo interactúa o qué pasa cuando ocurre la interacción.
               • Los atributos y métodos estáticos (de clase) se representan mediante un subrayado (en el caso de los métodos se puede emplear el estereotipo <<static>>, los estereotipos se ven más adelante).
                 • • Relación de dependencia en Diagramas de Clase El siguiente diagrama muestra una auto-relación de agregación. Un “Departamento” puede estar compuesto a su vez por más sub-departamentos, o ninguno, con la restricción de que el mínimo número de personas en los sub-departamentos debe ser dos. Las restricciones son condiciones que deben ser cumplidas siempre, se expresan entre llaves “{condición }”.
                     • • Los diagramas de objetos son análogos a los de clases, con la particularidad de que en lugar de encontrar clases, encontramos instancias de éstas. Son útiles para explicar partes pequeñas del modelo en las que hay relaciones complejas.
                     • Diagrama de Componentes y Diagrama de Despliegue
                       • Los componentes son módulos de código, así que los diagramas de componentes vienen a ser los análogos físicos a los diagramas de clases. Muestran como está organizado un conjunto de componentes y las dependencias que existen entre ellos.
                         • Los diagramas de despliegue sirven para modelar la configuración hardware del sistema, mostrando qué nodos lo componen.
                       • Diagrama de Casos de Uso
                         • Los diagramas de Casos de Uso describen lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qué más que el cómo. Plantean escenarios, es decir, lo que pasa cuando alguien interactúa con el sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el escenario de preparar su café y el pan tostado
                           • En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempeñan. Se representan mediante un “hombre de palitos”, de modo que en el ejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de óvalos y las líneas que unen Actores con Casos de Uso representan una asociación de comunicación.
                             • • “Carlos tuesta el pan en la tostadora, después lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojándolo en un café.”
                               • Los Casos de Uso suelen venir delimitados por fronteras o límites, que definen una separación entre lo que es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeño. En las figuras, esta separación viene representada por medio de la caja que encapsula los óvalos.
                                 • Los Casos de Uso son acompañados por una explicación textual que clarifica las posibles cadencias del lenguaje meramente gráfico. De esta manera, combinando Casos de Uso y explicación textual, se puede obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su sencillez de comprensión incluso por quien no está familiarizado con UML
               • Encontramos dos estereotipos <<include>> y <<extend>>. El primero indica que el Caso de Uso “Tostar pan” requiere de “Usar tostadora” para poder ser llevado a cabo. Esta es una forma muy adecuada de sacar factor común entre Casos de Uso, o incluso de fraccionar Casos de Uso muy grandes
                 • • “Carlos va a desayunar. Para ello debe hacer dos actividades distintas, pero relacionadas. La primera consisten en tostar pan, para lo cual necesita emplear una tostadora. Una vez tostado el pan, lo unta de mantequilla y mermelada de fresa (untar pan no es muy distinto de untar otro tipo de alimentos). La segunda consiste en preparar el café, par lo cual necesita calentar leche y añadir café y azuzar. Terminadas ambas actividades, Carlos puede proceder a alimentarse, comiendo el pan tostado y bebiendo el café. El orden en que realice las actividades da igual y también da igual si se realizan a la vez.”
                   • - Diagrama de Secuencia y Diagrama de Colaboración
                     • Los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de interacción que detalla como las operaciones se llevan a cabo, qué mensajes son enviados y cuando, organizado todo en torno al tiempo
                       • • Las líneas verticales o “líneas de la vida” representan el tiempo de vida del objeto. La vida del objeto “carlos” no termina en este diagrama, sin embargo la del objeto “tosty” sí y esto viene representado mediante el aspa al final de su línea de la vida.
                     • Los mensajes síncronos son todo lo contrario, el emisor debe esperar a que termine el tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. UML emplea los siguientes convenios para representar el tipo de mensaje.
                       • • Los diagramas de colaboración son otro tipo de diagramas de interacción, que contiene la misma información que los de secuencia, sólo que se centran en las responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son enviados. Cada mensaje de un diagrama de colaboración tiene un número de secuencia.
                           • • Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que esté llevando a cabo o de alguna condición.
                             • Los estados de un diagrama de estados pueden anidarse, de forma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto puede ser necesario cuando una actividad involucra subactividades asíncronas o concurrentes.
                               • • • Los diagramas de actividades son básicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados
                               • Cada rama muestra la condición que debe ser satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o más actividades paralelas.
                                 • Cómo utilizar UML
                                   • UML es simplemente un lenguaje de modelado. Define un conjunto de elementos y relaciones entre ellos, que se emplean en la definición de modelos
                                     • Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es seleccionar una metodología de desarrollo que defina la naturaleza concreta del proceso a seguir. El modelo a definir en base al proceso elegido, se divide en realidad en varios tipos de modelo o vistas, cada una centrada en un aspecto o punto de vista del sistema

Images and files in the map