diagrama de caso de uso

Diagrama de casos de uso

En el lenguaje de unificaciod, un diagrama de casos de uso es una especie de diagrama de comportamiento.

El lenguaje define una notacion cientifica 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.

Diagramas de Casos de Uso UML

El estándar de lenguaje unificado mod. 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 son importantes, ellos forman parte de la documentación de un caso de uso --un propósito para el que el actor puede usar el sistema.

El valor verdadero de un caso de uso reposa en dos áreas:

La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negosio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

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, consistentes promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

Es práctica 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 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 representados por las figuras humanas. El actor Crítico de comidas puede Probar la comida, Pagar la comida, o Beber vino. Sólo el actor Chef puede Preparar la comida. Podría ser que ambos Patrón y Cajero estén involucrados en el caso de uso Pagar la comida. El marco define los limites del sistema Restaurante, 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.

Inclusión (include o use)

Es una forma de interacción, un caso de uso dado puede "incluir" otro. 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, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Este uso se asemeja a una expansión de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parámetros o valores de retorno.

Extensión

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 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 se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusió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."

Generalizació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 solida 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.

"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 intensión y extensión."

CASO DE USO

Definición y Usos

Un diagrama Uso-Caso 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.

Un Uso-Caso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interactúa con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo".

Un Uso-Caso es empleado con más frecuencia en alguna de las siguientes etapas :

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.

En la siguiente sección se describen los diversos elementos que componen un diagrama Uso-Caso.

Uso-Caso: El uso-caso 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 Uso-Caso y un Actor, dicho elemento es representado simplemente por una linea recta que se extiende de la figura del actor hacia el ovalo del uso-caso.

Limite de Sistema (System Boundry): Empleado para delimitar los limites del sistema, y representado por un rectángulo con color de fondo distintivo.

Generalización : Una generalización indica que un uso-caso (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 linea con flecha que se extiende del uso-caso hijo hacia el uso caso padre (general).

Inclusión : Una inclusión es utilizada para indicar que un uso-caso (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 linea punteada con flecha y comentario <> que se extiende del uso-caso base hacia el uso caso de inclusión. Extensión : Una extensión representa una variación de un uso-caso a otro, aunque similar a una generalización, una extensión representa una dependencia especifica, mientras una generalización no implica que los usos-casos dependen uno del otro. Este elemento es representado por una linea punteada con flecha y comentario <> que origina del uso-caso base hacia el uso caso de extensión.

:

Diagramas de Casos de Uso

Un diagrama de casos de uso (Use Case Diagram) es una representación gráfica de parte o el total de los actores y casos de uso del sistema, incluyendo sus interacciones. Todo sistema tiene como mínimo un diagrama Main Use Case, que es una representación gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso).

Un diagrama de casos de uso muestra, por tanto, los distintos requisitos funcionales que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones). Se muestra como ejemplo los casos de uso de una máquina de café.

Un caso de uso, denotando un requisito funcional exigido al sistema, se representa en el diagrama por una elipse y un nombre significativo, . En el caso del ejemplo se tienen como casos de uso de la máquina de café RecibirDinero, PedirAzucar, PedirProducto, DarVueltas y Cancelar

Un actor es una entidad que utiliza alguno de los casos de uso del sistema. Se representa mediante el símbolo de la figura 2.1 acompa nado de un nombre significativo, si es necesario. En el ejemplo observamos un único actor representando al usuario de la máquina de café, aunque en un modelo de casos de uso más detallado se podría incluir otro actor para responsable del mantenimiento de la máquina. Un actor en un caso de uso representa un rol que alguien o algo podría desempe nar y no un alguien o algo específico.

Entre los elementos de un diagrama de casos de uso se pueden presentar tres tipos de relaciones, representadas por líneas dirigidas o no entre ellos:

comunica'' (<>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso. En el diagrama del ejemplo de la figura todas las líneas que salen del actor denotan este tipo de asociación (en realidad estereotipada como <>). usa'' ( <>) (o <> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro. En el caso del ejemplo el caso de uso Cancelar incluye en su comportamiento al de DarVueltas y PedirProducto incluye también DarVueltas.

extiende'' (<<>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura.

Se utiliza una relación de tipo <> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra, utilizaremos una relación tipo <<>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.

En una relación <<>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <> el actor que realiza el caso de uso base también realiza el caso de uso incluido.

En general utilizaremos <> cuando se presenta una variación del comportamiento normal, y <> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.

Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<> y <>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.

Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompa nar por un glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases.

Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a descartarla, si es el caso.

diagramas de clases

Diagrama de clases

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

Definiciones

Propiedades también llamados atributos o características, son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso.

Operaciones son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

Interfaz es un conjunto de operaciones y/o propiedades que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto.

Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede subdividirse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario del empleado, etc.

Al diseñar una clase se debe pensar en cómo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se diseña. Durante el proceso del diseño de las clases se toman las propiedades que identifican como único al objeto y otras propiedades adicionales como datos que corresponden al objeto. Con los siguientes ejemplos se definen tres objetos que se incluyen en un diagrama de clases:

Ejemplo 1: Una persona tiene número de documento de identificación, nombres, apellidos, fecha de nacimiento, género, dirección postal, posiblemente también tenga número de teléfono de casa, del móvil, FAX y correo electrónico.

Ejemplo 2: Un sistema informático puede permitir administrar la cuenta bancaria de una persona, por lo que tendrá un número de cuenta, número de identificación del propietario de la cuenta, saldo actual, moneda en la que se maneja la cuenta.

Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dónde las operaciones bancarias de una cuenta (como en el ejemplo 2) se manejarán realizando diferentes operaciones que en el diagrama de clases sólo se representan como operaciones, que pueden ser:

Abrir

Cerrar

Depósito

Retiro

Acreditar Intereses

Estos ejemplos constituyen diferentes clases 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.

Diagrama de clases (estructura estática)

Los diagramas de clases son diagramas de estructura estática que muestran las clases del sistema y sus interrelaciones (incluyendo herencia, agregación, asociación, etc). Los diagramas de clase son el pilar básico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido (dise no). El diagrama de clases de más alto nivel (main class diagram), será lógicamente un dibujo de los paquetes que componen el sistema. A su vez cada paquete tendrá un main class diagram que muestra las clases del paquete

Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de su propósito, su cardinalidad (cuantos objetos intervienen en la relación) y su opcionalidad (cuando un objeto es opcional el que intervenga en una relación). La descripción de clases complejas se puede documentar con diagramas de estados (sección ).

Figura: Diagrama de clases de la máquina de café

>

Supongamos el modelado de una máquina de café. Un diagrama de estructura estática inicial podría ser el representado en la figura 3.2. En dicha figura vemos que la representación gráfica UML para las clases es un rectángulo con compartimentos internos, siendo dichos rectángulos (clases) los elementos fundamentales del diagrama. Los compartimentos de una clase contienen su nombre, atributos y operaciones. En el ejemplo de la figura encontramos las clases Ingrediente, Producto, Maquina, DepositoMonedas y DepositoMonedasIguales. Los atributos, como hemos mencionado, identifican las características propias de cada clase. Generalmente son de tipos simples, ya que los atributos de tipos compuestos se representan mediante relaciones de composición con otras clases. La sintaxis textual UML para un atributo es:

visibility name : type-expression = initial-value { property-string}

Donde visibility puede ser public, protected y private; y type-expression es el tipo del atributo con nombre name. Además puede especificarse un valor inicial y un conjunto de propiedades del atributo. La visibilidad de un atributo (o operación puede ser):

public +: Cualquier clase externa con visibilidad hacia la clase dada puede utilizar la característica (ya se atributo u operación).

protected #: Cualquier descendiente de la clase puede utilizar la característica.

private -: Sólo el propio clasificador puede utilizar la característica.

En el modelo de la máquina de café (fig.), la clase Ingrediente tiene dos atributos: cantidad, de tipo float y con valor inicial 0; y nombre de tipo string sin valor inicial. En la herramienta CASE Rational Rose se utiliza para la representación de la visibilidad los símbolos que se muestran en la figura .

Figura: Símbolos en Rose para visibilidad privada, protegida y pública

La sintaxis de una operación en UML es:

visibility name (parameter-list) : return-type-expression {property-string}

Donde cada uno de los parámetros en parameter-list se denota igual que un atributo. Los demás elementos son los mismos que encontramos en la notación de un atributo.

Otro detalle importante que se puede especificar en los atributos y operaciones de una clase es su alcance. El alcance de propiedad de una característica especifica si la propiedad aparece en cada instancia de la clase o si sólo hay una instancia la propiedad para todas las instancias de la clase. En UML se pueden especificar dos tipos de alcance de propiedad:

instancia: Cada instancia de la clase tiene su propio valor.

clasificador: Sólo hay un valor para todas las instancias del clasificador.

Un atributo u operación con alcance de clasificador se denota subrayando la característica. El alcance de clasificador se corresponde con lo que en C++ son atributos y operaciones estáticas.

Una relación en un diagrama de clases, se representa mediante una línea que une dos o más clases. La línea puede ir acompa nada de diferentes tipos de adornos que definen su semántica y características. Como hemos ido viendo en esta sección las relaciones más comunes entre las clases presentes en un diagrama estático pueden ser: asociación (binaria o n-aria), agregación, generalización, dependencia, composición y clasificación.

Los elementos adicionales que pueden aparecer en la representación de una relación son:

Rol: Identifica con nombres a los elementos que aparecen en los extremos de la línea que denota la relación, dicho nombre describe la semántica que tiene la relación en el sentido indicado. Por ejemplo, la asociación de composición entre Maquina e Ingrediente recibe el nombre de existencias como rol en ese sentido.

Multiplicidad: Indica la cardinalidad de la relación. En el ejemplo se utilizan 1, 1 ..*, 5, *, como indicadores de multiplicidad.

Una asociación binaria se representa mediante una línea sólida que une dos clases, se trata de una relación entre las dos clases no muy fuerte, es decir, no se exige dependencia existencial ni encapsulamiento. Un ejemplo de asociación de este tipo es la que existe entre una compa nía y sus empleados (fig.). En este caso la asociación binaria recibe el nombre Trabaja Para, y en ella intervienen una o más instancias (objetos) de la clase Persona denominadas empleado. Además cada empleado se asocia a un empleador que en este caso es único.

Una agregación de composición o simplemente composición (composite aggregation) es una agregación más fuerte que implica:

Dependencia existencial: El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo.

Pertenencia fuerte: Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene.

No compartición: Los objetos contenidos no son compartidos, esto es, no forman parte del estado de otro objeto.

La composición se representa mediante un rombo relleno del lado de la clase que contiene a la otra en la agregación. En el ejemplo de la máquina de café vemos composiciones entre Maquina y Producto, Maquina y DepositoMonedas y, Maquina y DepositoMonedasIguales. La relación de generalización, denotando herencia entre clases, se representa mediante un triángulo sin rellenar del lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase. En el ejemplo encontramos generalización entre DepositoMonedas (superclase) y DepositoMonedasIguales (subclase).

Una clase paramétrica (parametrized class) se corresponde con el concepto de clases molde (template) en C++. Se representa acompa nando la clase con un rectángulo en la esquina superior derecha donde estarían los parámetros. Por ejemplo, la clase Lista que utiliza un parámetro formal Tipo se representaría como en la figura, pudiendo representar una lista de diferentes tipos de objetos dependiendo del valor del parámetro.

En UML los paquetes se representan como carpetas (fig ) que pueden presentar relaciones de dependencia o de generalización entre ellos.

En el ejemplo de la figura 1.11 existen tres paquetes (que aparecen vacíos, es decir, con su contenido encapsulado), con dos de ellos dependiendo del Modelo del Mundo. Una dependencia puede ir acompa nada de una explicación del tipo de dependencia de que se trate, utilizando estereotipos (ver ).

Una interfaz (interface) especifica un conjunto de operaciones en un elemento del modelo, en este clase, que describe el comportamiento visible de dicho elemento fuera del elemento. La representación gráfica es una línea terminada en un círculo. En el ejemplo de la figura , la clase String se utiliza dentro de hastable, gracias a que implementa la interfaz Hashable (el método hash) y la interfaz Comparable (el método isEqual). Ejemplo de interfaz

>

En algunas ocasiones es necesario describir que una clase está relacionada bien con un objeto de una o bien (exclusivo) con un objeto de otra. Este tipo de relación xor exclusiva se representa es una línea punteada que une dos asociaciones junto con la aclaración de la restricción que rige sobre ellas. En la figura 3.8 un automovil puede tener como due no una persona o una empresa, pero no ambos.

Una clase asociación (association class) es un elemento de modelado que tiene propiedades tanto de asociación como de clase. Una clase asociación puede ser vista tanto como una asociación que también tiene propiedades de clase, o como una clase que también tiene propiedades de asociación. Se representa gráficamente como una clase unida por una línea punteada a una asociación.

En la figura 3.9 existe una relación entre Muro y Ventana, la cual tiene como detalle un objeto de la clase Posición. Cabe notar que este objeto no podría tomarse como atributo de Muro o Ventana, ya que el contexto de su existencia está dado precisamente por la relación entre las dos clases.

Aunque las asociaciones suelen ser binarias la forma más general de asociación es una asociación n-aria (n-ary association). Se trata de una forma de expresar una relación entre tres o más clases. Cada instancia de la asociación es una n-tupla de valores de las clases respectivas. Se representa como un rombo del cual salen líneas de asociación a las clases. En la figura 3.10 podemos ver una relación ternaria entre las clases Year, Team y Player. A cada terna de objetos a no, equipo, jugador corresponde un objeto de tipo Record (clase de asociación).

diagrama de estado

Los Diagramas de Estados se usan para representar gráficamente máquinas del estado finita. Las Tablas de Transiciones son otra posible representación.

Hay muchas formas de diagramas de estados que difieren levemente y tienen semánticas diferentes.

Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna acción o se espera por un evento. El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, además, el estado de un objeto también se puede caracterizar por la existencia de un enlace con otro objeto.

Una transición entre estados representa un cambio de un estado origen a un estado sucesor destino que podría ser el mismo que el estado origen, dicho cambio de estado puede ir acompañado de alguna acción
Diagrama de estados

•.

Los diagramas de estados clásicos son llamados diagramas "or" de esta manera no se muebe de ningun modo.

Diagrama de paquetes

En un lenguaje unificado , un diagrama de paquetes muestra como 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 del Paquete
Los Diagramas de Paquetes se usan para reflejar la organización de los paquetes y sus elementos, y para proveer una visualización de sus correspondientes nombres de espacio. El ejemplo siguiente muestra un diagrama de Paquetes básico. El conector anidado entre ConnSeq y Controller refleja lo que revela el contenido del paquete. El contenido del Paquete se puede listar accediendo en el fondo del diagrama par amostrar la ventana de programacion, seleccionando la pestaña Elementos y seleccionando la Casilla de contenidos del paquete. El conector «import» indica que los elementos en el paquete Entero destino, que en este ejemplo es una única clase, Entero, se importará en el paquete Controlador. El nombre de espacio del Controlador obtendrá acceso a la clase Entero; el nombre de espacio de Entero no se afecta. El conector «merge» indica que los elementos del paquete Controlador se importarán en GenApply, incluyendo los contenidos anidados e importados de Controlador. Si un elemento ya existe en GenApply, tal como Cargador y Tiempo, las definiciones de estos elementos se expandirán por aquellas que se incluyen en el paquete Controlador. Todos los elementos agregados o actualizados por la mezcla son representados por una relación de generalización de vuelta a este paquete. Tenga en cuenta: Los elementos privados de un paquete no se pueden importar o mezclar. elementos y conectores de la herramienta Seleccione los elementos y conectores del diagrama de Paquetes desde las página Clase de la caja de herramientas del UML de EA Consejo: Haga clic sobre los siguientes elementos y conectores para obtener más información. el uml.. La especificación del UML del OMG (UML 2.0 Superstructure, p. 12) establece: "Un diagrama que presenta cómo se organizan los elementos de modelado en paquetes y las dependencias entre ellos, incluyendo importaciones y extensiones de paquetes."

diagrama de despliegue

El Diagrama de Despliegue es un tipo de diagrama del lenguaje moderado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

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.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.

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.

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 Despliegue

Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardware y software en el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software (procesos y objetos que se ejecutan en ellos). Estarán formados por instancias de los componentes software que representan manifestaciones del código en tiempo de ejecución (los componentes que sólo sean utilizados en tiempo de compilación deben mostrarse en el diagrama de componentes).

Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un nodo puede contener instancias de componentes software, objetos, procesos (caso particular de un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a un mainframe. Las instancias de componentes software pueden estar unidas por relaciones de dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).

diagramas de seceuncias

Es uno de los diagramas mas efectivos para modelar interacción entre objetos en un sistema.§Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.§Los mensajes se dibujan desde la parte superior del diagrama a la parte inferior.
§Es uno de los diagramas mas efectivos para modelar interacción entre objetos en un sistema.§Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.§Los mensajes se dibujan desde la parte superior del diagrama a la parte inferior.
PASO A SEGUIR
Acontinuacion se dara una muy breve descripcion de los 4 objetos que se deben seguir para dibujar correctamente diagramas de secuencia de ICONIX.PASO 1: Copia el texto de la especificacion de tu caso de uso y pegalo en la parte superior de tu diagrama de secuencia.PASO 2: Cada uno de los objetos entidad de tu diagrama de es una instancia de la clase que debe ser agregada a tu diagrama de secuencias ya que representa tu modelo estatico.PASO 3: Agrega las interfaces del diagrama. Con esto ya tenemos el diagrama de secuencias construido.Ahora el cuarto paso es para decidir cuales metodos irian en cuales clases,lo cual es la esencia del modelo de iteraciones.PASO 4: Pon los metodos en las clases, lo cual significa convertir los controles uno por uno de tu diagrama en metodos y mensajes.Verifica que para cada control dibujado le pertenecen los mensages correcos dentro del diagrama de secuencias.
-Activación: muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operación bien sea por si misma o por medio de delegaciones a alguno de sus atributos ,se denota cono un rectángulo delgado sobre la línea de vida del objeto .-Tiempo de transición: en un entorno de objetos concurrentes o de demoras en la recepción de mensajes.-Destrucción de un objeto: se representa con una “x” al final de la línea de ejecución del objeto.-Métodos recursivos: es un rectángulo adyacente que indica la entrada y salida de la recursión .
Tipos de mensajes
- linea continua con flecha : simple
- linea continuab con triangulo : sincronico
- linea continua con flecha media : asincronico
- linea descontinua con triangulo : retorno