lunes, 9 de diciembre de 2013

diagramas de paquetes

Diagramas de Paquetes
Permiten dividir un modelo para agrupar y encapsular sus 
elementos en unidades lógicas individuales
En general, pueden tener una interfaz (métodos de clases e 
interfaces exportadas) y una realización de éstas interfaces 
(clases internas que implementan dichas interfaces)
Se pueden utilizar para plantear la arquitectura del sistema a 
nivel macro.






diagramas de estructura compuesta

Diagrama de Estructura Compuesta UML 2


Diagramas de Estructura CompuestaUn diagrama de estructura compuesta es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus puntos de interacción a otras partes del sistema. Esto muestra la configuración y relación de las partes que juntas realizan el comportamiento de clasificador contenido.

Los elementos de clase han sido descriptos en gran detalle en la sección en los diagramas de clase. Esta sección describe la forma en que las clases se pueden mostrar como elementos compuestos exponiendo interfaces y conteniendo puertos y partes.
Una parte es un elemento que representa un conjunto de una o más instancias que pertenecen a una instancia del clasificador contenida. Por ejemplo, si una instancia de diagrama se apropia de un conjunto de elementos gráficos, luego los elementos gráficos se pueden representar como partes, si fuera útil hacer eso para modelar algún tipo de relación entre ellos. Tener en cuenta que una parte se puede quitar de sus padres antes de que el padre se elimine, para que la parte no se elimine al mismo tiempo.
Una parte se muestra como un rectángulo no adornado dentro del cuerpo de una clase o del elemento componente.

Una parte se muestra como un rectángulo no adornado dentro del cuerpo de una clase o del elemento componente.
Un Puerto se muestra como un rectángulo nombrado en el borde del límite de su clasificador apropiado.

Un Puerto se muestra como un rectángulo nombrado en el borde del límite de su clasificador apropiado.
Una interfaz es similar a una clase pero con un número de restricciones. Todas las operaciones de la interfaz son públicas y abstractas, y no proveen ninguna implementación predeterminada. Todos los atributos de la interfaz deben ser constantes. Sin embargo, mientras que una clase puede solo heredar de una sola super-clase, puede implementar interfaces múltiples.
Una interfaz, cuando esta sola en un diagrama, se muestra como un rectángulo del elemento clase con  la clave «interfaz» y con su nombre en itálica para denotar que es abstracto, o se muestra como un circulo.

Una interfaz, cuando esta sola en un diagrama, se muestra como un rectángulo del elemento clase con  la clave «interfaz» y con su nombre en itálica para denotar que es abstracto, o se muestra como un circulo.
Una interfaz provista se muestra como una “pelota en un palo” adjuntada al borde de un elemento clasificador. Una interfaz requerida se muestra como una “copa en un palo” adjuntada al borde de un elemento clasificador.

Una interfaz provista se muestra como una “pelota en un palo” adjuntada al borde de un elemento clasificador. Una interfaz requerida se muestra como una “copa en un palo” adjuntada al borde de un elemento clasificador.
Un conector delegar se usa para definir los trabajos internos de los puertos e interfaces externas del componente. Un conector delegar se muestra como una flecha con un estereotipo «delegar». Esto conecta un contrato externo de un componente como se muestra por sus puertos a la realización interna del comportamiento de la parte del componente.
Una colaboración define un conjunto de roles co-operativos usados colectivamente para ilustrar una funcionalidad especifica. Una colaboración debería solo mostrar los roles y los atributos requeridos para lograr sus tareas o funciones definidas. Aislar los roles primarios es un ejercicio de simplificar la estructura y clasificar el comportamiento, y también provee para poder re- usarlo. Un elemento colaboración a menudo implementa un patrón.
Un elemento colaboración se muestra como un elipse

Un elemento colaboración se muestra como un elipse
Un conector enlace de roles se dibuja desde una colaboración a un clasificador que completa el rol. Esto se muestra como una línea de trazos con una punta de flecha y el estereotipo «enlace de roles».
Un conector representa se puede dibujar desde una colaboración a un clasificador para mostrar que una colaboración se usa en el clasificador. Se muestra como una línea de trazos con una punta de flecha y el estereotipo «representa».
Un conector ocurrencia se puede dibujar desde una colaboración a un clasificador para mostrar que la colaboración representa (sic) el clasificador. Esto se muestra como una línea de trazos y el estereotipo «ocurrencia».


Parte
Puerto
Un Puerto es un elemento escrito que representa una parte visible externa de una instancia del clasificador contenido. Los puertos definen la interacción entre un clasificador y su entorno. Un Puerto puede aparecer en el límite de la parte contenida, una clase o una estructura compuesta. Un Puerto puede especificar los servicios que un clasificador provee así como también los servicios que este requiere de su entorno.
Interfaces

Tener en cuenta que la notación del círculo no muestra las operaciones de la interfaz. Cuando las interfaces se muestran como si fueran apropiadas por las clases, se refieren a ellas como interfaces expuestas. Una interfaz expuesta se puede definir como provista o requerida. Una interfaz provista es una afirmación que el clasificador contenido provee a las operaciones definidas por el elemento de la interfaz nombrada y se define dibujando un vínculo de realización entre la clase y la interfaz. Una interfaz requerida es un estado que el clasificador puede comunicar con algún otro clasificador que provee operaciones definidas por el elemento de la interfaz nombrada y se define dibujando un vínculo de dependencia entre la clase y la interfaz

Delegar

Colaboración

Enlace de Roles

Representa

Ocurrencia



  • Clase. Para mostrar la parte de la cual se ilustra su composición interna (ejemplo: carro o Barco)
  • Parte. Se muestra con un rectángulo, e indica los objetos que conforman al objeto principal. Ejemplo: el motor y las llantas en el carro, o el motor y el propulsor en el Barco. Si se coloca una parte dentro de una clase significa, en un diagrama de clases, que la clase contenedor tiene una relación de composición con dicho elemento.
  • Conector. Indica la relación entre las parte internas de la clase que se analiza.
  • Puertos. Se pueden mostrar puertos para indicar la entrada o salida de una parte hacia otra parte. Se muestran como pequeños cuadrados al final de un conector entre dos partes. No son obligatorias, pero son recomendables si se quiere encapsular el funcionamiento de las partes.
Este diagrama de estructura compuesta UML 2.0 especifica que las instancias de la clase 'FibonacciSystem' están compuestas de varias partes. La superior de estas partes está identificada como teniendo el clasificador 'FibonacciFunction'. Tres de las partes son identificadas por el rol que ellas juegan dentro de instancias del FibonacciSystem – el rol NMinus2, el 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 el mundo real, el mundo de los objetos, algo normal que nos encontramos son objetos que están compuestos por más objetos. UML nos permite modelar dicha información por medio de relaciones de composición entre los objetos contenedores y sus partes.
Dicha relación se muestra tradicionalmente con un diamante relleno en la orilla del contenedor, en una relación entre el contenedor y la parte. En el siguiente diagrama podemos ver que un carro tiene un motor, y dicho motor no puede ser parte de otro carro en un momento determinado en el tiempo.
Pero, modelar en UML composiciones de objetos podía volverse muy complejo en ciertas situaciones. Como en el caso de un carro y un barco que estuvieran compuestos por motor, pero donde para el primero el motor ayudara a mover las ruedas delanteras y en el segundo caso el motor sirviera para mover el propulsor del barco. Habría que realizar un modelo complejo para aclarar (a quien pudiera leer el diagrama), que había una diferencia entre el motor que tenía el carro y el motor del barco.
El diagrama anterior intenta explicar esto, pero tiene deficiencias, pues aunque aclara con la multiplicidad de las conexiones de carro y barco (0..1) como contenedores del motor, que sólo puede estar la instancia del motor en uno de los dos; por otra parte parece decirnos que el motor del carro puede mover tanto propulsor como llantas. Lo cual es equivocado, pues el motor del barco sólo mueve el propulsor y el del carro sólo mueve sus llantas. Tampoco aclara que las dos llantas que mueve el motor en el carro son las delanteras, y no las dos traseras.
Para modelarlo correctamente en un diagrama de clases tendríamos que elaborar toda una jerarquía de herencia entre clases para distinguir entre los motores de barcos y carros, y entre las llantas delanteras y traseras de un carro, o marcando dependencias entre las relaciones.
Con UML 2 ahora contamos con un nuevo diagrama, llamado diagrama de estructura compuesta, que nos permite contextualizar las partes que componen a una clase. Así podemos armar un diagrama donde aclaremos que el carro tiene un motor que mueve las dos llantas delanteras (pero, no las traseras ni el propulsor), y otro diagrama del mismo tipo que nos permitiría mostrar el barco con un motor que exclusivamente mueve su propulsor (y no las llantas).
El contexto lo define la clase contenedora, que con fines de este ejemplo serían el carro o el barco. Y dentro de dicha clase modelamos las partes que lo componen, como se muestra a continuación. Cada uno de estos diagramas muestra la estructura interna de una instancia de carro y de barco respectivamente.
En este caso nos queda mucho más claro que cada uno tiene un motor, pero que funciona de manera diferente. Incluso es claro que el motor del carro mueve exclusivamente las dos llantas delanteras, y no las dos traseras.
Los elementos que tradicionalmente se muestran en este tipo de diagrama son:
Un uso adicional que se puede dar a los diagramas de estructura compuesta es para mostrar las partes que colaboran, por ejemplo, en un caso de uso. Aunque en esta ocasión no explicaremos esta perspectiva, consideramos importante mencionarlo y mostrar un pequeño ejemplo.
En este ejemplo podemos ver que son tres las clases que colaboran en el caso de uso “Participar en curso”: el estudiante, el curso y el seminario. Esta forma nos permitiría modelar patrones de diseño indicando los roles que juega cada clase en la colaboración.

Como ejemplo, considere un modo posible de modelar la producción de la Sucesión de Fibonacci.
Diagrama de estructura compuesta UML 2.0

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.




diagrama de componentes

Diagramas de componentes de UML

Puede usar un diagrama de componentes para describir un diseño que se implemente en cualquier lenguaje o estilo. Solo es necesario identificar los elementos del diseño que interactúan con otros elementos del diseño a través de un conjunto restringido de entradas y salidas. Los componentes pueden tener cualquier escala y pueden estar interconectados de cualquier manera.
Para obtener más información acerca de cómo se utilizan los diagramas de componentes en el proceso de diseño.
Forma
Elemento
Descripción y propiedades principales
1
Componente
Elemento de funcionalidad del sistema reutilizable. Un componente proporciona y utiliza el comportamiento a través de las interfaces y puede hacer uso de otros componentes.
Los elementos internos de un componente se pueden mostrar u ocultar con el control de expandir y contraer (9).
Un componente es un tipo de clase.
  • Is Indirectly Instantiated. Si es true (valor predeterminado), el componente solo existe como artefacto de diseño. Solo existen sus elementos en tiempo de ejecución.
2
Puerto de interfaz proporcionada
Representa un grupo de mensajes o llamadas que un componente implementa y que otros componentes o sistemas externos pueden utilizar. Un puerto es una propiedad de un componente que tiene una interfaz como tipo.
3
Puerto de interfaz necesaria
Representa un grupo de mensajes o llamadas que el componente envía a otros componentes o sistemas externos. El componente está diseñado para que se acople a los componentes que proporcionan al menos estas operaciones. El puerto tiene una interfaz como tipo.
4
Dependencia
Se puede utilizar para indicar que una interfaz necesaria de un componente se puede satisfacer mediante una interfaz proporcionada de otro.
Las dependencias también se pueden utilizar con más frecuencia entre los elementos del modelo para mostrar que el diseño de uno depende del diseño del otro.
5
Parte
Atributo de un componente cuyo tipo normalmente es otro componente. Los elementos se utilizan en el diseño interno de su componente primario.Los elementos se muestran de forma gráfica, anidados dentro del componente primario.
Para crear un elemento de un tipo del componente existente, arrastre el componente del Explorador de modelos UML al componente propietario.
Para crear un elemento de un nuevo tipo, haga clic en la herramienta Componente y, a continuación, en el componente propietario.
Por ejemplo, un componente Car tiene los elementos engine:CarEnginebackLeft:WheelfrontRight:Wheel, etc.
Varios elementos pueden tener el mismo tipo y varios componentes distintos pueden tener elementos del mismo tipo.
  • Tipo. Tipo del elemento, que se define en otra parte del modelo. Normalmente, el tipo es otro componente.
  • Multiplicity. El valor predeterminado es 1. Puede establecerse en 0..1 para indicar que el elemento puede tener el valor null, en * para indicar que el elemento es una colección de instancias del tipo especificado, o en cualquier expresión que se pueda evaluar como un intervalo de números.
6
Ensamblado de elementos
Conexión entre los puertos de la interfaz necesaria de un elemento y los puertos de la interfaz proporcionada de otro. La implementación de un ensamblado de elementos puede variar de un componente a otro. Los elementos conectados deben tener el mismo componente primario.
7
Delegación
Vincula un puerto a una interfaz de uno de los elementos del componente. Indica que los mensajes enviados al componente se administran en el elemento o que los mensajes enviados desde el elemento se envían fuera del componente primario.
(no se muestra)
Generalización
Indica que un componente hereda de otro componente. Los elementos y las interfaces se heredan.
9
Control de expandir y contraer
Utilice este control para mostrar u ocultar los elementos internos de un componente.
(no se muestra)
Comment
Se utiliza para agregar notas adicionales. Puede vincular un comentario a cualquier número de elementos del diagrama mediante la herramientaConector.


diagrama de objetos

Diagramas de objetos


Los diagramas de objetos representan las instancias de su proyecto de desarrollo

Los diagramas de objetos de representan un único ejemplo de una clase y se utilizan para ilustrar un punto de datos en su aplicación. Cuando cree un objeto nuevo, llamado especificación de instancia, UModel le permite asignar una clase ya existente representada por la instancia. UModel ofrece automáticamente al objeto instancias de las propiedades pertinentes desde la clase y el usuario puede insertar valores de muestras para el objeto.
Los diagramas de objetos UML utilizan una notación similar a los diagramas de clases y se utilizan para ilustrar una instancia de una clase en un momento dado. Imagine que desea dibujar un diagrama de objetos para ilustrar un ejemplo real de una clase y de sus relaciones.
Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A veces se dibujan durante el proceso de planificación de clases o para ayudar a partes interesadas para quienes los diagramas de clases sean demasiado abstractos.
Puesto que los diagramas de objetos utilizan notaciones muy similares a los diagramas de clases, la barra de herramientas de diagramas de objetos usan algunos de los iconos de la barra de herramientas de diagramas de clases. Para editar los atributos y valores de un objeto puede utilizar la barra de herramientas, el diálogo de propiedades o editarlos directamente en el diagrama.

diagrama 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, orientados a objetos.

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




























martes, 3 de diciembre de 2013

UML

UML
Lenguaje Unificado de Modelado

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, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.





HISTORIA
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML. 

OBJETIVO

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo.


TIPOS DE DIAGRAMAS 



Estructura

Comportamiento

Interacción


ejemplo: