Comentarios


Java_Printing.jpg
Los comentarios sirven en UML para anotar excepciones o restricciones que no se pueden representar de otra forma en los diagramas UML.

Paquetes


Java_Priga.jpg
Un paquete es una colección de elementos del modelo. Hay varias razones para querer empaquetar algunos elementos del modelo:
  • Se puede hacer por pura conveniencia, para ocultar algunos detalles irrelevantes en un diagrama
  • Se puede hacer para definir las partes de un sistema a implementar por cada uno de los equipos.
  • Puede ser necesario especificar y diseñar un componente, asegurando que se entienden las interacciones entre el componente y el contexto que se utiliza.

En un diagrama de cualquier tipo aparece un paquete como un rectángulo con otro pequeño rectángulo en el borde superior izquierdo (véase la imagen).
Los elementos contenidos en un paquete pueden dibujarse dentro del símbolo del mismo, pero no es necesario.Los símbolos del paquete se pueden usar en todos los tipos de diagrama.Los paquetes pueden contener casi cualquier elemento del modelo que se quiera agrupar.



Modelo de Casos de Uso


El modelo de casos de uso captura los requisitos de un sistema. Los casos de uso son un medio de comunicación con los usuarios y otros interesados acerca de lo que se piensa hacer del sistema.

Actores
Un diagrama de casos de uso muestra la interacción entre el sistema y entidades externas al sistema. Estas entidades externas se referencian como actores. Los actores representan los roles que pueden incluir usuarios humanos, un hardware externo u otros sistemas. Un actor usualmente se dibuja como una figura o alternativamente como una clase con la palabra clave «actor».


external image uc01.gif external image uc02.GIF

Los actores pueden generalizar otros actores como se detalla en el siguiente diagrama.


external image uc05.GIF


Casos de Uso
Un caso de uso es una sola unidad de trabajo significativo. Este provee una vista de alto nivel de comportamiento observable para alguien o algo fuera del sistema. La notación por un caso de uso es una elipse.



external image uc10.GIF

La notación para usar un caso de uso es una línea de conexión con una punta de flecha opcional mostrando la dirección del control. El siguiente diagrama indica que el actor Customer (cliente) usa el caso de uso withdraw (retirar).



external image uc09.GIF


El conector “use” puede tener opcionalmente valores múltiples en cada final, como en el siguiente diagrama que muestra que el cliente puede tener solo una sesión de “withdraw” (retiro) a la vez, pero un banco puede tener cualquier cantidad de clientes haciendo retiros concurrentemente.

external image uc07.GIF


Definiciones de Casos de Uso
Un Caso de Uso normalmente incluye:
  • Nombre y Descripción
  • Requisitos
  • Restricciones
  • Escenarios
  • Diagramas de escenarios
  • Información adicional.
Nombre y Descripción
Un caso de uso normalmente se nombra como una frase verbal y se le da una descripción textual informal.
Requisitos
Los requisitos definen los requisitos funcionales formales que un caso de uso debe proveer al usuario final. Estos corresponden a las especificaciones funcionales encontradas en las metodologías estructuradas. Un requisito es un contrato o promesa de que el caso de uso realizará una acción o proveerá algún valor al sistema.
Restricciones
Una restricción es una condición o restricción bajo la cual opera un caso de uso y que incluye pre, y post condiciones y condiciones invariantes. Una pre condición especifica las condiciones que se necesitan cumplir antes de que el caso de uso pueda proceder. Una post condición se usa para documentar el cambio en condiciones que deben ser verdaderas después de la ejecución del caso de uso. Una condición invariante especifica las condiciones que son verdaderas a través de la ejecución del caso de uso.
Escenarios
Un escenario es una descripción formal del flujo de eventos que ocurren durante la ejecución de una instancia de casos de uso. Este define la secuencia específica de eventos entre el sistema y los actores externos. Este normalmente se describe en el texto y corresponde a la representación textual del diagrama de secuencia.
Incluyendo Casos de Uso
Los casos de uso pueden contener la funcionalidad de otro caso de uso como parte de su proceso normal. En general se asume que cualquier caso de uso incluido se llamará cada vez que se ejecute una ruta básica. Un ejemplo de esto tiene la ejecución de Caso de uso <Card Identification> para ejecutar como parte de un caso de uso <Withdraw>.


external image uc06.GIF


Los casos de uso se pueden incluir por uno o más casos de uso, ayudando a reducir el nivel de duplicación de la funcionalidad realizando un factoreo del comportamiento común en casos de uso que se usan muchas veces.
Casos de Uso extendidos
Un caso de uso se pude usar para extender el comportamiento de otro, esto normalmente se usa en circunstancias. Por ejemplo, si antes de modificar un tipo particular de orden del cliente, un usuario debe obtener la aprobación de una autoridad superior, luego el caso de uso <Get Approval> puede opcionalmente extender el caso de uso <Modify Order>.


external image uc03.GIF


Puntos de extensión
El punto al cual un caso de uso extendido se agrega se puede definir por medio de un punto de extensión.


external image uc04.GIF


Límite del sistema
Usualmente se usa para mostrar casos de uso dentro del sistema y actores fuera del sistema.


external image uc08.GIF
||

Clases


ejemplo.JPG

¿Qué es?

Es la unidad básica que encapsula toda la información de un objeto (un objeto es una instancia de una clase). A través de ella podemos modelar
el entorno en estudio (ejemplo una casa, un auto, una cuenta corriente, etc…)
En UML las clases son representadas como por un rectángulo dividido en tres partes, cada una de ellas representan las 3 partes de una clase
“Nombre de la clase”, “Atributo” y “operaciones o métodos”.
Las partes:

  • Nombre: contiene el nombre de la clase.
  • Atributos: contiene los atributos , es decir, las características de la clase (estas pueden ser prívate, protected o public)
  • Operaciones o métodos: contiene los metodos u operaciones de la clase, es decir, la forma que la clase interactua con su entorno (también puden ser prívate, protected o public)

Atributos:

Las sintaxis de un atributo es: Visibilidad <nombre>: tipo = valor{ propiedades}
Atributo: Son valores que corresponden aun objeto, comocolor, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una persona, sus propiedades serían: nombre, edad, sexo,etc.
  • Tipo: Puede llegar a depender del lenguaje de programación a utilizar.
  • Valor inicial: Valor que poseerá el atributo al crear un objeto.
  • Visibilidad: Está relacionado con el encapsulamiento.
  • Multiplicidad: Determinar si una tributo debe estar o no, y si posee un único valor o una lista de valores.

Métodos:

Los métodos u operaciones de una clase son la forma en cómo ésta interactúa con su entorno, éstos pueden tener las mismas características de los atributos public, prívate y protected.
Para cada método debe especificarse:
  • Tipo devuelto: Puede llegara de pender del lenguaje de programación a utilizar.
  • Parámetros: Especificación del tipo de datos y la información que determina el funcionamiento del método.
  • Visibilidad: Está relacionada con el encapsulamiento (-,#,+).


Asociaciones --> Mario y Jesus

ASOCIACIONES

I1.JPG
- Las asociaciones son conexiones conceptuales entre clases. Por ejemplo la asociación, entre trabajador y empresa.
“Un trabajador labora en una empresa” la asociación conectara con una línea a trabajador y empresa, si vemos los roles de cada uno podemos decir que el trabajador es un empleado y la empresa es la empleadora.
“Labora en” es el nombre de la asociación y la colocamos sobre la linea, mientras que los roles (empleado, empleador) los colocamos bajo la línea a cada lado según corresponda. Así nuestra relación “Un trabajador labora en una empresa” en UML se vería así:
I3.JPG
- Las asociaciones pueden funcionar en ambos sentidos. Si vemos el ejemplo anterior desde la perspectiva de la empresa, la asociación sería “Una empresa emplea trabajadores”
I3.JPG
- Notemos que para comprender el sentido de la asociación añadimos una flecha.
Las asociaciones no se limitan conectar una clase con otra, pueden conectarse varias clases con una.
I4.JPG
- Cuando necesitamos especificar mas detalles en las asociaciones como restricciones podemos especificarlas encerrándolas entre llaves. Por ejemplo un cajero atiende a un cliente, pero cada cliente es atendido en el orden de su llegada.
I5.JPG
- La restricción del tipo “O” se la representa con una línea entrecortada que una las 2 relaciones. Por ejemplo un estudiante de educación media superior puede elegir entre un curso académico o uno comercial.


Generalización -->

Generalización --> MariaGeneralización o Herencia



Indica que una clase hereda los métodos y atributos especificados por una clase, por lo cual una clase derivada además de tener sus propios métodos y atributos, podrá acceder a las características y atributos visibles de su clase base (public y protected).

Permite representar la especialización de un caso de uso.Ejemplo:

Dibujo.jpg



En este ejemplo se especifica que las clase Alumno y Profesor heredan de la clase Persona, es decir, Alumno y Profesor podrán acceder a las características de Persona. También puede tener su respectiva diferenciación, ya que un Alumno puede obtener sus notas previa evaluación realizada por parte de un Profesor.

Agragación ----> Dick
Composición

Relación de agregación o de referencia

agregacion1.jpg

Esto, es una parte muy sencilla, pero al mismo tiempo básica para el diseño de un diagrama de clases UML, la forma de representar que un objeto tiene como contenido a otro, esto quiere decir que un objeto de un tipo, puede contener a otro, en un sentido abstracto de posesión, es decir, por ejemplo un objeto de tipo, por ejemplo, ciudad tiene una lista de objetos de tipo aeropuerto, esto quiere decir, que una ciudad, tiene un número de aeropuertos, destacar, que la cardinalidad del extremo que lleva el rombo, es siempre uno, ahí va un ejemplo:


Relación de composición o de valor

compocicion1.jpg
En la misma línea, la composición, es una relación más fuerte de los objetos, así como la agregación, es el hecho de que un objeto posea a otro, la composición es cuando la relación entre ambos objetos es tal, que el agregado es una parte importante del agregador, de tal forma que el primero no tiene sentido suelto, y el segundo, necesita definir al primero para ampliar su significado, ya sé que esto suena un tanto etéreo, pero con un ejemplo se ve mejor:
El avión tiene sentido por si solo, pero está claro que está compuesto de 2 alas, esta relación es de mucha fuerza, mucho más que el caso de los aeropuertos, y está claro, que un avión siempre tendrá sus dos alas, y estas siempre serán del mismo avión. El caso de los aeropuertos, es claramente más suave la relación.




Dependencias --> Diego


NAVEGABILIDAD


La navegabilidad es una propiedad de un rol (un extremo de una asociación) que indica que es posible “navegar” unidireccionalmente a través de la asociación, desde objetos de la clase origen a objetos de la clase destino. Como se vio en la parte II, se representa en UML mediante una flecha.
La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la clase origen. En la implementación se traducirá en la clase origen como un atributo que sea una referencia a la clase destino.
Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una función, deben ser necesarias, si no es así deben eliminarse.
Las situaciones más comunes en las que parece que se necesita definir una asociación con navegabilidad de A a B son:
- A envía un mensaje a B.
- A crea una instancia B.
- A necesita mantener una conexión con B.


CARDINALIDAD o MULTIPLICIDAD

En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia ( representa el número de objetos que pueden conectarse a través de una relación de asociación), se anotan en cada extremo de la relación y éstas pueden ser:

- uno o muchos: 1..* (1..n)
- 0 o muchos: 0..* (0..n)
- número fijo: m (m denota el número).
external image moz-screenshot-1.png
external image moz-screenshot-2.png



Clase de asociación
David Luis, Luis Antonio, David Peces
Sin_título.png
lgunas veces es tan importante la manera en que están asociados dos, tanto objetos como los objetos entre sí. Piense, por ejemplo, en la asociación entre Estudiante y Módulo. ¿Dónde debería almacenar el sistema las notas del estudiante en eses curso? Las notas están relacionadas realmente con el par formado por un estudiante y un módulo. Se podría pensar en implementar un objeto por cada par: el objeto almacenaría las notas del estudiante en ese curso, o con las notas de ese estudiante en otro curso. Esto significa tratar la asociación entre las clases Estudiante y Módulo como una clase; por supuesto una instancia de la asociación relaciona un estudiante con un módulo, y entonces se dice que son datos adjuntos a ese enlace. Probablemente se quieran también operaciones, aunque sólo sea para obtener y establecer las notas.
El resultado es algo que es tanto una clase como una asociación, que se denomina clase de asociación.


El icono de la clase y la línea de asociación tienen que tener el mismo nombre, ¡porque son lo mismo! Esto representa un pequeño problema, ya que las asociaciones normalmente tienen como nombre frases verbales y las clases, frases nominales. (También, si se utiliza la convención en mayúsculas y minúsculas, que dice que los nombres de las asociaciones se escriben en minúscula y los nombres de las clases en mayúscula, hay que tener un caso especial para las clases de asociación, ¡ya que no se pueden cumplir ambas convenciones a la vez!) Se puede pensar un nombre mejor que está cursando ambos.

Visibilidad
Cristina Campillo
diagrama.png
La visibilidad de una característica especifica si puede ser utilizada por otros objetos. Hay tres niveles de visibilidad en UML:

  • public (cualquiera la puede usar, la característica es precedida por el símbolo +),
  • protected (cualquier descendiente la puede utilizar, se especifica con el símbolo #),
  • private (solamente la propia clase la usa, se especifica con el símbolo - ). El alcance de una característica define si la característica aparece en cada instancia de la clase, o si sólo hay una característica para todas las instancias. Para definir alcance de clase, las características se subrayan. Por defecto, las características tienen alcance de instancia.