• Author / Uploaded
• Juan Fidel Choque Coaquira

Citation preview

Lenguaje Unificado de Modelado (UML)

PDF generado usando el kit de herramientas de fuente abierta mwlib. Ver http://code.pediapress.com/ para mayor información. PDF generated at: Sat, 25 Jun 2011 16:40:54 UTC

Contenidos Artículos Lenguaje Unificado de Modelado

1

Diagrama de clases

4

Diagrama de componentes

6

Diagrama de objetos

7

Diagrama de estructura compuesta

7

Diagrama de despliegue

9

Diagrama de paquetes

10

Diagrama de actividades

11

Diagrama de casos de uso

12

Diagrama de estados

14

Diagrama de secuencia

15

Diagrama de comunicación

16

Diagrama de colaboración

17

Diagrama de tiempos

19

Diagrama global de interacciones

20

Referencias Fuentes y contribuyentes del artículo

22

Fuentes de imagen, Licencias y contribuyentes

23

Licencias de artículos Licencia

24

Lenguaje Unificado de Modelado

1

Lenguaje Unificado de Modelado Este artículo o sección necesita referencias que aparezcan en una publicación acreditada, como revistas especializadas, monografías, prensa diaria o páginas de Internet fidedignas. [1] Puedes añadirlas así o avisar al autor principal del artículo en su página de discusión pegando: {{subst:Aviso referencias|Lenguaje Unificado de Modelado}} ~~~~

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Collage de diagramas UML.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Lenguaje Unificado de Modelado

2

Diagramas En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha. Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado: • • • •

Diagrama de clases Diagrama de componentes Diagrama de objetos Diagrama de estructura compuesta (UML 2.0)

Jerarquía de los diagramas UML 2.0, mostrados como un diagrama de clases

• Diagrama de despliegue • Diagrama de paquetes Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado: • Diagrama de actividades • Diagrama de casos de uso • Diagrama de estados Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: • • • •

Diagrama de secuencia Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración (UML 1.x) Diagrama de tiempos (UML 2.0) Diagrama global de interacciones o Diagrama de vista de interacción (UML 2.0)

Estandarización de UML Desde el año 2005, UML es un estándar aprobado por la ISO como ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2.

Críticas a UML Este artículo o sección necesita referencias que aparezcan en una publicación acreditada, como revistas especializadas, monografías, prensa diaria o páginas de Internet fidedignas. [1] Puedes añadirlas así o avisar al autor principal del artículo en su página de discusión pegando: {{subst:Aviso referencias|Lenguaje Unificado de Modelado}} ~~~~

A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado. Sin embargo, UML sí acepta la creación de nuestros propios componentes para este tipo de

Lenguaje Unificado de Modelado modelado. • • • • • •

Entorno de desarrollo integrado Herramienta CASE Técnica de Modelado a Objetos Programación orientada a objetos XMI, un formato estándar basado en XML para el intercambio de modelos UML. OCL, Lenguaje de especificación para los diferentes modelos en UML.

EEYORE¹ • Webml, Metodología para el diseño de Sistemas de Información Web. • Categoría:Herramientas UML

Historia Antes de UML 1.x Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañíá se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingenieríá de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prácticas metodológicas. En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba simbolos de nubes. Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si se adoptó la capacida de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integrados al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0. Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.

3

Lenguaje Unificado de Modelado

4

Referencias • Martin Fowler, Kendall Sccott, "UML Gota a Gota", 1999. • Utilización de UML en Ingeniería del Software con Objetos y Componentes. Perdita Stevens, Rob Pooley. Addison Wesley. 2002.

Enlaces externos • • • • • • •

Wikimedia Commons alberga contenido multimedia sobre Lenguaje Unificado de Modelado.Commons Grupo Oficial del lenguaje Modelado [2] (en inglés) Especificación oficial [3] (en inglés) Introducción a UML 2.0, partes uno [4] y dos [5] Listados de herramientas [6] (en inglés) Listado de herramientas CASE de modelado UML [7] Listados de herramientas [8]

Referencias [1] http:/ / en. wikipedia. org/ wiki/ Lenguaje_unificado_de_modelado?action=history [2] [3] [4] [5] [6] [7] [8]

http:/ / www. uml. org http:/ / www. omg. org/ technology/ documents/ formal/ uml. htm http:/ / www. epidataconsulting. com/ tikiwiki/ tiki-read_article. php?articleId=15 http:/ / www. epidataconsulting. com/ tikiwiki/ tiki-read_article. php?articleId=31 http:/ / www. umltools. net/ http:/ / case-tools. org/ uml_modeling. html http:/ / modeling-languages. com/ es/ content/ herramientas-para-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, 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. Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos

Ejemplo de diagrama de clases de una Universidad.

Diagrama de clases

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 comùnmente llamados mètodos, 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 que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto. Hace referencia a polimorfismo. • 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 especializarse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además cada uno 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 de balurdes 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.

5

Diagrama de componentes

Diagrama de componentes Este artículo o sección necesita referencias que aparezcan en una publicación acreditada, como revistas especializadas, monografías, prensa diaria o páginas de Internet fidedignas. [1] Puedes añadirlas así o avisar al autor principal del artículo en su página de discusión pegando: {{subst:Aviso referencias|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 compartidas, módulos, ejecutables, 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 estos son más parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista estática y dinamica 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.

Referencias [1] http:/ / en. wikipedia. org/ wiki/ Diagrama_de_componentes?action=history

6

Diagrama de objetos

Diagrama de objetos Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML. Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase. Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase. Por ejemplo, Miguel: Persona.

Diagrama de estructura compuesta Un diagrama de estructura compuesta es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase 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, y conectores 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, una superclase 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.

7

Diagrama de estructura compuesta

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 Como ejemplo, considere un modo posible de modelar la producción de la Sucesión de Fibonacci. 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 Diagrama de estructura compuesta UML 2.0 por el rol que ellas juegan dentro de instancias del FibonacciSystem – el rol NMinus2, el rol NMinus1, 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 diagramas de estructura compuesta 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.

8

Diagrama de despliegue

Diagrama de despliegue Este artículo o sección necesita referencias que aparezcan en una publicación acreditada, como revistas especializadas, monografías, prensa diaria o páginas de Internet fidedignas. [1] Puedes añadirlas así o avisar al autor principal del artículo en su página de discusión pegando: {{subst:Aviso referencias|Diagrama de despliegue}} ~~~~

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado 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. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entre los nodos y por ejemplo con una base de datos. 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.

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.

9

Diagrama de despliegue

Véase también • UML • Deployment Diagrams [2]

Enlaces externos • • • •

Introducción a UML [3] Tutorial de UML2 - Diagrama de Despliegue [4] Definición de UML 2.0 (en inglés) [5] Uso avanzado de UML - Diagramas de Despliegue (en inglés) [6]

Referencias [1] [2] [3] [4] [5] [6]

http:/ / en. wikipedia. org/ wiki/ Diagrama_de_despliegue?action=history http:/ / en. wikipedia. org/ wiki/ Deployment_diagram http:/ / tvdi. det. uvigo. es/ ~avilas/ UML/ UML. html http:/ / www. sparxsystems. com. ar/ resources/ tutorial/ uml2_deploymentdiagram. html http:/ / www. omg. org/ spec/ UML/ 2. 1. 2/ Superstructure/ PDF/ http:/ / advanceduml. wordpress. com/ the-unified-modeling-language/ deployment-diagrams/

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.

Enlaces externos • Introduction to UML 2 Package Diagrams [1] by Scott W. Ambler • UML 2 Package Diagram Guidelines [2] by Scott W. Ambler

Referencias [1] http:/ / www. agilemodeling. com/ artifacts/ packageDiagram. htm [2] http:/ / www. agilemodeling. com/ style/ packageDiagram. htm

10

Diagrama de actividades

11

Diagrama de actividades En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general. En SysML el diagrama de Actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.

Descripción En UML 1.x, un diagrama de Actividades es una variación del Diagrama de estados UML donde los "estados" representan operaciones, y las transiciones representan las actividades que ocurren cuando la operación es completa.. El diagrama de Actividades UML 2.0, mientras que es similar en aspecto al diagrama de Actividades UML 1.x, ahora tiene semánticas basadas en redes de Petri. En UML 2.0, el diagrama general de Interacción está basado en el diagrama de Actividades. Diagrama de actividad. Es una forma especial de diagrama de estado usado para modelar una secuencia de acciones y condiciones tomadas dentro de un proceso. Diagrama de Actividades para un loop (bucle).

La especificación del Lenguaje de Modelado Unificado UML define un diagrama de actividad como: “… una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la realización de las acciones o subactividades.” [1] El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones. Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz. Una Interfaz es un grupo de operaciones relacionadas con la semántica.

Referencias [1] Bellows, Jeannie, Castek (2000). Activity Diagrams and Operation Architecture. Technologies Group Inc..

Véase • Diagrama de flujo • Diagrama de secuencia

Enlaces externos • Wikimedia Commons alberga contenido multimedia sobre Diagrama de actividades.Commons • Documentos de la Especificación UML 2.0 (http://www.omg.org/technology/documents/formal/uml.htm) • Introducción a los Diagramas de Actividades UML 2 (http://www.agilemodeling.com/artifacts/ activityDiagram.htm)

Diagrama de casos de uso

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 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 Componentes de un diagrama de casos de uso. 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 • La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. 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, 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.

12

Diagrama de casos de uso

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. 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. 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 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. La notación es de una flecha de punta abierta con línea discontinua 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. Aqui tambien podemos decir que éste va de padre a hijo. 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." 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. esto es gran mentira

13

Diagrama de casos de uso

Véase también • UML

Enlaces externos • • • • •

(en) Creating Use Case Diagrams [1] (en) Understanding Use Case Modeling [2] (en) Conduciendo el desarrollo con Casos de Uso [3] (es) Relación de Inclusión [4] (es) Relación de Extensión [5]

Referencias [1] [2] [3] [4] [5]

http:/ / www. developer. com/ design/ article. php/ 2109801 http:/ / www. methodsandtools. com/ archive/ archive. php?id=24 http:/ / www. parlezuml. com/ tutorials/ usecases. htm http:/ / synergix. wordpress. com/ 2008/ 06/ 07/ casos-de-uso-avanzados-relacion-de-inclusion/ http:/ / synergix. wordpress. com/ 2008/ 06/ 05/ casos-de-uso-avanzados-relacion-extend/

Diagrama de estados En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso. Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación. El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.

Enlaces externos • Diagramas de estado en UML [1] Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso. Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transición es una relación entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.

Referencias [1] http:/ / jms32. eresmas. net/ tacticos/ UML/ UML08/ UML0801. html

14

Diagrama de secuencia

15

Diagrama de secuencia El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"[1]

Utilidad Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

Ejemplo de Diagrama de Secuencia

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. 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.

Tipos de mensajes Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta. También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas • De instancia: describe un escenario especifico (un escenario es una instancia de la ejecución de un caso de uso). • Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.

Diagrama de secuencia

16

Véase • Diagrama de flujo • Diagrama de actividades • Diagrama de casos de uso

Referencias [1] OBM (2005) (http:/ / georgewbush-whitehouse. archives. gov/ omb/ egov/ documents/ CRM. PDF) FEA Consolidated Reference Model Document. May 2005. p.91.

Enlaces externos • Wikimedia Commons alberga contenido multimedia sobre Diagrama de secuencia. Commons • Especificación UML actual (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML) • Sequence Diagram Editor: herramienta para crear diagramas de secuencia (http://sdedit.sourceforge.net/ index.html#''Quick)

Diagrama de comunicación En el Lenguaje Unificado de Modelado (UML) 2.0, un diagrama de comunicación es una versión simplificada del diagrama de colaboración de la versión de UML 1.x. Un diagrama de comunicación modela las interacciones entre objetos o partes en términos de mensajes en secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el diagrama de clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.

Ejemplo de un diagrama de comunicación.

Los diagramas de comunicación y de secuencia describen información similar, y con ciertas transformaciones, pueden ser transformados unos en otros sin dificultad. Para mantener el orden de los mensajes en un diagrama de comunicación, los mensajes son etiquetados con un número cronológico y colocados cerca del enlace por el cual se desplaza el mensaje. Leer un diagrama de comunicación conlleva comenzar en el mensaje 1.0, y seguir los mensajes desde un objeto hasta el siguiente, sucesivamente.

Diagrama de comunicación

Enlaces externos • Introduction to UML 2 Communication Diagrams [1] From Agile Modeling, por Scott W. Ambler • The Communication Diagram [2] por Francois Coetzee • Communication Diagram (formerly Collaboration Diagram) [3] por Sparx Systems

Referencias [1] http:/ / www. agilemodeling. com/ artifacts/ communicationDiagram. htm [2] http:/ / www. xpdian. com/ Thecommunicationdiagram. html [3] http:/ / sparxsystems. com. au/ EAUserGuide/ index. html?communicationdiagram. htm

Diagrama de colaboración Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de comunicación muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes. • Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común. • Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace". Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

Usos Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La comunicación muestra los parámetros y las variables locales de la operación, así como asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa. Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica, pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales están menos claras.

17

Diagrama de colaboración

Tipos Es útil marcar los objetos en cuatro grupos: los que existen con la interacción entera; los creados durante la interacción (restricción {new}); los destruidos durante la interacción (restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción {transient}). Aunque las comunicaciones muestran directamente la implementación de una operación, pueden también mostrar la realización de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles múltiples que los objetos pueden desempeñar en varias operaciones.

Mensajes Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un número de secuencia, una lista opcional de mensajes precedentes, una condición opcional de guarda, un nombre y una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explícita.

Flujos Generalmente, un diagrama de comunicación contiene un símbolo para un objeto durante una operación completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explícitos. Por ejemplo, un objeto pudo cambiar de localización o sus asociaciones pudieron diferenciarse. Los diferentes símbolos de objeto que representan un objeto se pueden conectar usando flujos "become" o "conversion". Un flujo "become" es una transición, a partir de un estado de un objeto a otro. Se dibuja como una flecha de línea discontinua con el estereotipo "become" o "conversión" y puede ser etiquetado con un número de serie para mostrar cuando ocurre. Un flujo de conversión también se utiliza para mostrar la migración de un objeto a partir de una localización a otra distinta para otro lugar tambien se deben marcar con el numero en secuencias.

Cambios en versiones recientes de UML En versiones recientes de UML este diagrama ha sido reemplazado por el diagrama de comunicación.

18

Diagrama de tiempos

Diagrama de tiempos Un diagrama de tiempos o cronograma es una gráfica de formas de onda digitales que muestra la relación temporal entre varias señales, y cómo varía cada señal en relación a las demás. Un cronograma puede contener cualquier número de señales relacionadas entre sí. Examinando un diagrama de tiempos, se puede determinar los estados, nivel alto o nivel bajo, de cada una de las señales en cualquier instante de tiempo especificado, y el instante exacto en que cualquiera de las señales cambia de estado con respecto a las restantes. El propósito primario del diagrama de tiempos es mostrar los cambios en el estado o la condición de una línea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cuándo se desea mostrar el evento que causa el cambio en la condición o en el estado.

Diagramas de Tiempos UML En el estándar de Lenguaje de Modelado Unificado de OMG los diagramas de tiempo son una representación especial de interacción que se enfoca en el tiempo de los mensajes enviados entre objetos. Se pueden usar estos diagramas para mostrar restricciones detalladas sobre el tiempo, ó para mostrar los cambios con líneas de vida respecto al tiempo. Los diagramas de tiempo son generalmente utilizados con sistemas en tiempo real o en sistemas embebidos.

Véase también • Señal digital • Lenguaje de Modelado Unificado

19

Diagrama global de interacciones

20

Diagrama global de interacciones Un diagrama global de las interacciones (en inglés: interaction overview diagram) es una de las trece clases de diagramas en el Lenguaje de Modelado Unificado (UML), un lenguaje de modelamiento para software y otros sistemas.

Descripción El diagrama global de las interacciones es un diagrama de comportamiento, más precisamente, uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque un diagrama global de las interacciones es una representación gráfica de una interacción, éste se distingue fuertemente de los diagramas de secuencia y de comunicación, dos de los otros diagramas de interacción. De hecho, algunos elementos gráficos del diagrama global de las interacciones están tomados del diagrama de actividades, otro diagrama de comportamiento para el modelado de actividades. Los modelos de interacción pueden llegar a ser muy grandes para sistemas complejos. Si el número de líneas de vida participantes y el número de mensajes intercambiados excede una cierta medida, se impone “modularizar” las interacciones y dividir en partes pequeñas, más manejables, de acuerdo a principios universales del diseño de sistemas, que también pueden ser visualizadas con la ayuda de un clásico diagrama de secuencias. La visión de conjunto de toda la interacción, de manera que la Big Picture o bien el cuadro global, puede entonces ser representada con la ayuda del diagrama global de las interacciones, provisto para eso.

Ejemplo La figura muestra un ejemplo de un diagrama global de interacciones con un encabezado y un área de contenido. La palabra clave en el área de encabezado, en el caso de un diagrama global de interacciones, es sd ó interaction. En este ejemplo, el diagrama global de interacciones combina un diagrama de secuencia, que está definido en el lugar (inglés inline), con una interacción (Drehtür für einen Durchgang freigeben o en español, Desbloquear la puerta giratoria para un libre paso), que está modelada en otra parte y que aquí está solo referenciada, reconocible en la palabra clave ref. El flujo de control entre estas dos interacciones es modelada con elementos de los diagramas de actividades. El proceso comienza en un nodo inicial y finaliza en un nodo terminal para actividades. Un nodo de ramificación entre las interacciones embebidas (el diagrama de secuencia y el de interacción) modela la decisión de si la entrada se abre o si debe permanecer cerrada.

Ejemplo de un diagrama global de interacciones.

Diagrama global de interacciones

Diferencias con UML 1.4 El diagrama global de interacciones fue introducido nuevamente en la versión 2.0 de UML.

Bibliografía • Christoph Kecher: UML 2.0 - Das umfassende Handbuch. Galileo Computing, 2006, ISBN 3-89842-738-2

21

Fuentes y contribuyentes del artículo

Fuentes y contribuyentes del artículo Lenguaje Unificado de Modelado  Fuente: http://es.wikipedia.org/w/index.php?oldid=47361569  Contribuyentes: 3coma14, A000zzzaaa, Adelpine, Aleator, Alejandrosilvestri, Alexan, Alhen, Aloriel, Amana, Angus, Anoryat, Artemor, ArturoJL, Ascánder, Avm, Axxgreazz, Barbara.galarce, Bernard77, BiG FooT, BlackBeast, Boja, Carutsu, Cesarsorm, Cinabrium, Clon1x, Diegospina, Dodo, Dreitmen, Eloy, Enric Naval, Etnas, Falcoxcalibur, Fgonfel, Galio, GermanX, Gnovaro, HUB, Icvav, Ivan.Romero, Javispedro, Jcarlos77, Jesusguerrero15, Jomesias, JorSol, JorgeGG, Jorgelrm, Jstitch, Jvilalta, Jvlivs, Karj, Kurnosem, Lahi, Lazamazu, Leonpolanco, LordT, Lourdes Cardenal, Magister Mathematicae, Mahadeva, Maldoror, ManoloKosh, ManuelGR, Marmux, Matdrodes, Migue1 ange1, Muro de Aguas, Nicoguaro, Nioski, PeiT, Penelopina, Pilaf, PoLuX124, Porao, Racso, Rolandovanegas, RoyFocker, Rαge, Sabbut, Sanbec, Shooke, Superzerocool, Taichi, Tano4595, Tin nqn, Tirithel, Tostadora, Triku, Txopi, VMatheu, Valyag, Villamota, Wazaraki, Wilfredor, X.Cyclop, Xjres, Zenemix, 356 ediciones anónimas Diagrama de clases  Fuente: http://es.wikipedia.org/w/index.php?oldid=46281841  Contribuyentes: Aalvarez12, Airunp, Anthemfor182, Banfield, Cantero, Cvielma, Der Kreole, Diegusjaimes, Dusan, Equi, Ezarate73, Gerkijel, GermanX, Ignacio Icke, Isha, Jareyes, Jarke, Jlchavez, JulGor, Keres, Matdrodes, Rometern2, Taichi, Vgrunberg, Victoriano Román, Wilfredor, 104 ediciones anónimas Diagrama de componentes  Fuente: http://es.wikipedia.org/w/index.php?oldid=44890080  Contribuyentes: Adelpine, Cvielma, Erkow, Ezarate, Galio, GermanX, Osbiury, Pichdig, Satin, Shiningp, Sunsinron, Tin nqn, 17 ediciones anónimas Diagrama de objetos  Fuente: http://es.wikipedia.org/w/index.php?oldid=36312976  Contribuyentes: Airunp, Alvaro qc, Axxgreazz, Gerkijel, GermanX, Humberto, Matdrodes, Petronas, Vanbasten 23, Zanaqo, 13 ediciones anónimas Diagrama de estructura compuesta  Fuente: http://es.wikipedia.org/w/index.php?oldid=36313042  Contribuyentes: Adelpine, Aleposta, 1 ediciones anónimas Diagrama de despliegue  Fuente: http://es.wikipedia.org/w/index.php?oldid=47413243  Contribuyentes: Adelpine, Cvielma, Ezarate, FrancoGG, GermanX, Tin nqn, 13 ediciones anónimas Diagrama de paquetes  Fuente: http://es.wikipedia.org/w/index.php?oldid=40845202  Contribuyentes: Er Komandante, Jvlivs, Matdrodes, Vitamine, 17 ediciones anónimas Diagrama de actividades  Fuente: http://es.wikipedia.org/w/index.php?oldid=44845785  Contribuyentes: BlackBeast, Jose figueredo, Jvlivs, MaBy25, Matdrodes, Mpeinadopa, Wilfredor, 18 ediciones anónimas Diagrama de casos de uso  Fuente: http://es.wikipedia.org/w/index.php?oldid=47287445  Contribuyentes: Aeris17, Andreasmperu, Armando.Mejia, Açipni-Lovrij, Camilo, Developer, Diario, Diegusjaimes, Emiduronte, Farisori, Fmariluis, Hermzz, Hprmedina, Humberto, Julie, Jvlivs, Kelovy, Lourdes Cardenal, Marvelshine, Matdrodes, Pipepupo, Prometheus, Richy, Saloca, Super braulio, SuperJoe, Tirithel, Tono campos, Vitamine, 151 ediciones anónimas Diagrama de estados  Fuente: http://es.wikipedia.org/w/index.php?oldid=46389135  Contribuyentes: Farisori, Mecamático, 13 ediciones anónimas Diagrama de secuencia  Fuente: http://es.wikipedia.org/w/index.php?oldid=46535414  Contribuyentes: Doctor seisdedos, El Pantera, Ezarate73, Jlbox, Jose figueredo, Juanvicfer, Omerta-ve, Santiperez, Ugly, X3mboy, 48 ediciones anónimas Diagrama de comunicación  Fuente: http://es.wikipedia.org/w/index.php?oldid=31370704  Contribuyentes: Humberto, 7 ediciones anónimas Diagrama de colaboración  Fuente: http://es.wikipedia.org/w/index.php?oldid=46954981  Contribuyentes: Alejandro Lodes, Dhidalgo, Er Komandante, Hoenheim, Ialad, Javierito92, Mutari, Santiperez, Tano4595, Wikante, 33 ediciones anónimas Diagrama de tiempos  Fuente: http://es.wikipedia.org/w/index.php?oldid=44824346  Contribuyentes: Biasoli, Kved, Patricio.lorente, Rosarinagazo, Shiningp, Tano4595, Wikante, 5 ediciones anónimas Diagrama global de interacciones  Fuente: http://es.wikipedia.org/w/index.php?oldid=35194104  Contribuyentes: Adelpine, Mercenario97

22

Fuentes de imagen, Licencias y contribuyentes

Fuentes de imagen, Licencias y contribuyentes Imagen:Question book.svg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Question_book.svg  Licencia: GNU Free Documentation License  Contribuyentes: Diego Grez, Javierme, Loyna, Remember the dot, Victormoz, Wouterhagens, 5 ediciones anónimas Archivo:UML Diagrams.jpg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:UML_Diagrams.jpg  Licencia: Creative Commons Attribution-ShareAlike 3.0 Unported  Contribuyentes: Kishorekumar 62 Archivo:Uml diagram-es.svg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Uml_diagram-es.svg  Licencia: Creative Commons Attribution-Sharealike 2.5  Contribuyentes: Uml_diagram.svg: Dave A Ryan derivative work: Wazaraki (talk) Imagen:Commons-logo.svg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Commons-logo.svg  Licencia: logo  Contribuyentes: SVG version was created by User:Grunt and cleaned up by 3247, based on the earlier PNG version, created by Reidab. Archivo:Diagrama de clases.svg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Diagrama_de_clases.svg  Licencia: Creative Commons Attribution-Sharealike 3.0  Contribuyentes: Wilfredor Archivo:Composite Structure Diagram.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Composite_Structure_Diagram.png  Licencia: Public Domain  Contribuyentes: [:w:User:KenSWebb Archivo:For-loop-diagram.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:For-loop-diagram.png  Licencia: Creative Commons Attribution-Sharealike 2.5  Contribuyentes: Bináris, CountingPine, Faxe, Ma-Lik, Mdd, 1 ediciones anónimas Archivo:Notacion Caso de Uso.svg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Notacion_Caso_de_Uso.svg  Licencia: Creative Commons Attribution-Sharealike 3.0  Contribuyentes: Notacion_Caso_de_Uso.png: Wilfredo R. Rodriguez H. derivative work: ApokalipsyS (talk) Archivo:UML diagrama caso de uso.svg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:UML_diagrama_caso_de_uso.svg  Licencia: GNU Free Documentation License  Contribuyentes: UML_diagrama_caso_de_uso.png: en:User:Poor Yorick derivative work: ApokalipsyS (talk) Archivo:Sequencia.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Sequencia.png  Licencia: Public Domain  Contribuyentes: Juanvicfer Archivo:Commons-logo.svg  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Commons-logo.svg  Licencia: logo  Contribuyentes: SVG version was created by User:Grunt and cleaned up by 3247, based on the earlier PNG version, created by Reidab. File:Kommunikations diagramm-5.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Kommunikations_diagramm-5.png  Licencia: Public Domain  Contribuyentes: Gubaer Archivo:Diagrama de tiempos.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Diagrama_de_tiempos.png  Licencia: Public Domain  Contribuyentes: Boninerd Archivo:Iau-diagramm-1.png  Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Iau-diagramm-1.png  Licencia: GNU Free Documentation License  Contribuyentes: Original uploader was Gubaer at de.wikipedia

23

Licencia

Licencia Creative Commons Attribution-Share Alike 3.0 Unported http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/

24