miércoles, 30 de julio de 2014

Diagrama de casos de uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado(UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar mas de un caso de uso para poder identificar que es lo que hace un caso de uso.
  • La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.
En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.
La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:

Inclusión (include o use)

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual(si el actor realiza el caso de uso base tendra que realizar tambien el caso de uso incluido), desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones esto no sirve.

Extensión (extend)

Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. El caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión .
"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."
documentan el comportamiento de un sistema desde el punto de vista de un usuario
En otras palabras será utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones, un ejemplo claro es que se necesite comprar azucar y podemos seleccionar de entre azucar rubia,blanca o su unidad de medida bolsa , kilo.

Generalización

"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."
En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Diagrama de despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar la disposición física de los artefactos software en nodos (usualmente plataforma de hardware)1 

Elementos


Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

Aspectos Generales

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Usos

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:
  • Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.
  • Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.
  • Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema

Diagrama de paquetes

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones.
Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.
Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

Diagrama de estructura compuesta

Un diagrama de estructura es un tipo de diagrama en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de unaclase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, yconectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.

Conceptos de estructura compuesta

Las entidades de estructura compuesta claves identificadas en la especificación UML 2.0 son: clasificadores estructurados, partes, puertas, conectores, y colaboraciones.

Parte

Una parte representa un rol jugado en tiempo de ejecución por una instancia de una clase o por una colección de instancias. La parte puede nombrar solamente un rol, unasuperclase abstracta, o puede nombrar una clase concreta específica. La parte puede incluir un factor de multiplicidad (cardinalidad), tal como el [0..*] mostrado para Viewer en el diagrama.

Puerta

Una puerta es un punto de interacción que puede ser usado para conectar clasificadores estructurados con sus partes y con el ambiente. Las puertas pueden opcionalmente especificar los servicios que proveen y los servicios que requieren de otras partes del sistema. En el diagrama, cada uno de los cuadrados pequeños es una puerta. Cada puerta tiene un tipo y esta etiquetado con un nombre, tal como "var", "indVar1", or "view" en el diagrama. Las puertas pueden contener un factor de multiplicidad, por ejemplo [3].
Las puertas pueden ya sea delegar los requerimientos recibidos a partes internas, o pueden entregarlos directamente para el comportamiento del clasificador estructurado en el que la puerta está contenido. Las puertas públicas que son visibles en el ambiente son mostradas sobre el borde (límite o frontera), mientras que las puertas protegidas que no son visibles en el ambiente son mostradas dentro de la frontera (borde o límite). Todas las puertas en el diagrama son privadas, excepto por la puerta view a lo largo del límite derecho de FibonacciSystem.

Conector

Un conector une dos o más entidades, permitiéndoles interactuar en tiempo de ejecución. Un conector es representado por una línea que une una combinación de partes, puertas y clasificadores estructurados. El diagrama muestra tres conectores entre puertas, y un conector entre un clasificador estructurado y una parte.

Colaboración

Una colaboración es generalmente más abstracta que un clasificador estructurado. Ésta es mostrada como un óvalo sin relleno conteniendo los roles que las instancias pueden jugar en la colaboración.

Clasificador estructurado

Un ClasificadorEstructurado representa una clase, frecuentemente una clase abstracta, cuyo comportamiento puede ser completa o parcialmente descrito mediante interacciones entre partes.
Un ClasificadorEncapsulado es un tipo de clasificador estructurado que contiene puertas. En el diagrama abajo, ambos FibonacciSystem y Variable son clasificadores encapsulados, porque ambos tienen puertas a lo largo de sus límites.

Ejemplo de diagrama de estructura compuesta

Este diagrama de estructura compuesta UML 2.0 especifica que las instancias de la clase 'FibonacciSystem' están compuestas de varias partes. La superior de estas partes está identificada como teniendo el clasificador 'FibonacciFunction'. Tres de las partes son identificadas por el rol que ellas juegan dentro de instancias del FibonacciSystem – el rol NMinus2, el rolNMinus1, y el rol N. La quinta parte, identificada por su clasificador Viewer, incluye una especificación de multiplicidad. En tiempo de ejecución puede haber 0 o más instancias de Viewer o de alguna subclase concreta de Viewer.
En tiempo de ejecución las instancias de clase que implementan estos tres roles deben proveer los servicios especificados por la interfaz IVar mediante sus puertas var. Una de tales clases es Variable, mostrada sobre el diagrama con una puerta llamada var de tipo Var que realiza la interfaz IVar.
La puerta llamada "view" es una puerta no-pública que puede ser usada por una instancia de FibonacciSystem para acceder a la(s) instancia(s) opcional(es) de Viewer

Trabajando con hp

Las Herramientas de modelado UML 2.0 debiesen proveer un diagrama de estructura compuesta separado. Los iconos de dibujo son típicamente etiquetados Classifier (clasificador estructurado o clasificador encapsulado), Part, Port, Connector, y Collaboration.

Diagrama de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidasmódulosejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.
Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Diagrama de objetos

En UML, diagrama que muestra una vista completa o parcial de los objetos de un sistema en un instante de ejecución específico.

Descripción Formal

El Object Management Group, en la especificación UML (versiones 2.1 y anteriores), definía al diagrama de objetos como:
"Un diagrama de objetos es un gráfico de instancias, incluyendo objetos y datos. Un diagrama de objetos es una instancia de un diagrama de clases; muestra una 'foto' del estado de un sistema en un punto de tiempo determinado."
Los diagramas de objeto están ligados a los diagramas de clase y comparten virtualmente los mismos símbolos para la notación. Los diagramas de objetos pertenecen a la categoría de diagramas estructurales en UML.

Generación y Uso

Los diagramas de objetos se generan en las disciplinas de Arquitectura y diseño. Se utilizan para mostrar estructuras de datos y las interacciones que existen entre objetos en tiempo de ejecución.

Tipos de Diagramas de UML

  • Diagrama de clases
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, orientados a objetos.

Definiciones

  • Propiedad de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.
  • El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.
  • Presenta las clases del sistema con sus relaciones estructurales y de herencia.
  • El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.