Análisis y Diseńo de Sistemas.Foro 3: UML

Análisis y Diseño de Sistemas

Universidad Yacambú

Especialización en Gerencia

Mención: Sistemas de Información

Concepto, Caracteristicas, Modelamiento de Clases.
	Resumen Infografìa
Diagrama de Secuencias, Diagrama de Casos de Uso.
	Resumen Infografìa
Sub-Tema: Diagrama de Estrucrura Estática, Diagrama de Colaboración.
	Resumen Infografìa
Diagrama de Estados, Herramientas Case basadas en UML.
	Resumen Infografìa


Arelis Velazco		Sub-Tema: Concepto, Caracteristicas, Modelamiento de Clases

UML (LENGUAJE DE MODELADO UNIFICADO)

El Lenguaje de Modelado Unificado (UML) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso.
Los objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:
• El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).
• Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
• Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
• Manejar los problemas típicos de los sistemas complejos de misión crítica.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo. Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.

El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación. Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño. La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación)

¿Qué es eso del modelado?
Un enfoque sistemático permite construir estos modelos de una forma consistente demostrando su utilidad en sistemas de cierto tamaño. Cuando se trata de un programa de cincuenta, cien líneas, la utilidad del modelado parece discutible pero cuando involucramos a cientos de desarrolladores trabajando y compartiendo información, el uso de modelos y el proporcionar información sobre las decisiones tomadas, es vital no sólo durante el desarrollo del proyecto, sino una vez finalizado éste, cuando se requiere algún cambio en el sistema. En realidad, incluso en el proyecto más simple los desarrolladores hacen algo de modelado, si bien informalmente.
Para la construcción de modelos, hay que centrarse en los detalles relevantes mientras se ignoran los demás, por lo cual con un único modelo no tenemos bastante. Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes

Un modelo representa a un sistema software desde una perspectiva específica. UML recomienda la utilización de nueve diagramas que, para representar las distintas vistas de un sistema. Estos diagramas de UML son los siguientes:

• Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola en descripciones de acciones ejecutadas por un sistema para obtener un resultado.
• Diagrama de Clases: muestra las clases (descripciones de objetos que comparten características comunes) que componen el sistema y cómo se relacionan entre sí.
• Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones.
• Diagrama de Secuencia: enfatiza la interacción entre los objetos y los mensajes que intercambian entre sí junto con el orden temporal de los mismos.
• Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.
• Diagrama de Estados: modela el comportamiento de acuerdo con eventos.
• Diagrama de Actividades: simplifica el Diagrama de Estados modelando el comportamiento mediante flujos de actividades.
• Diagrama de Componentes: muestra la organización y las dependencias entre un conjunto de componentes.
• Diagrama de Despliegue: muestra los dispositivos que se encuentran en un sistema y su distribución en el mismo.

II.2 Elementos Comunes a Todos los Diagramas
Notas: Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada
Dependencias: La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habría que revisar el elemento origen).

Diagrama de Clases

El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones.
El mundo real puede ser visto desde abstracciones diferentes (subjetividad)
Mecanismos de abstracción:
1. Clasificación / Instanciación
2. Composición / Descomposición
3. Agrupación / Individualización
4. Especialización / Generalización

La clasificación es uno de los mecanismos de abstracción más utilizados. La clase define el ámbito de definición de un conjunto de objetos, y cada objeto pertenece a una clase, Los objetos se crean por instanciación de las clases.
La Clase.

Una clase esta representada por un rectángulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los métodos. Cada clase debe tener un nombre único, que las diferencie de las otras.

Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto.

Un método u operación es la implementación de un servicio de la clase, que muestra un comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de la clase que hagan algo.

Para separar las grandes listas de atributos y de métodos se pueden utilizar estereotipos

Cada clase se representa en un rectángulo con tres compartimientos:
• nombre de la clase
• atributos de la clase
• operaciones de la clase

Relaciones entre clases.
Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relación son:
• Asociación y Agregación (vista como un caso particular de asociación): Especifica que los objetos de una clase están relacionados con los elementos de otra clase. Se representa mediante una línea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregación
• Generalización/Especialización: Pues es la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. UML nos permite modificar la relación de Generalización con un estereotipo y dos restricciones
Las relaciones de Agregación y Generalización forman jerarquías de clases.

Relación entre clases

INFOGRAFIA

- Titulo: El Lenguaje de Modelado Unificado

Url:http://www.docirs.cl/uml.htm

- Titulo: UML. El lenguaje estándar para el modelado de software

Url: http://www.ati.es/novatica/2004/168/168-4.pdf

- Titulo: Modelado de Sistemas com UML

Url: http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/

-Titulo: Programación Orientada a Objetos

Url: http://ccc.inaoep.mx/POO/POOuml.ppt

- Titulo: Modelo de Clases

Url: http://www.dcc.uchile.cl/~psalinas/uml/modelo.html

- Titulo: Desarrollo Orientado a Objetos con UML

Url: http://www.clikear.com/manuales/uml/

- Titulo: Introducciòn al UML

Url: http://www.yoprogramo.com/articulo4.php

- Titulo: UML:Unified Modeling Languaje

Url: http://gidis.ing.unlpam.edu.ar/personas/glafuente/uml/uml.html

Titulo: UML

Url: http://usuarios.lycos.es/oopere/uml.htm

Titulo: Diagrama de Clases

Url: http://ccc.inaoep.mx/~dtapia/francisco/UML%20--%20Diagramas%20de%20Clases.htm

Titulo: El Lenguaje Unificado de Modelado.

Url: www.disca.upv.es/enheror/pdf/ActaUML.PDF

Inicio


Marcos Ventre		Sub-Tema: Diagrama de Secuencias, Diagrama de Casos de Uso.

Casos de Usos

Los casos de uso son una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización son relaciones.

Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con él; un ejemplo de actor podría ser un usuario o cualquier otro sistema.

Las relaciones entre casos de uso y actores pueden ser las siguientes:

Un actor se comunica con un caso de uso.
Un caso de uso extiende otro caso de uso.
Un caso de uso usa otro caso de uso

Un diagrama de casos de uso consta de los siguientes elementos:

Elementos de un caso de Uso

Actor

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol , pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones :

• Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Las relaciones de asociación permiten especificar qué objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociación que determina los valores que indican cuales son los valores que se asociarán.

Dicha relación se denota con una flecha simple.

• Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

• Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends : Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses : Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar .

Ejemplo:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el número de ítems ingresados.
Imprimir un recibo cuando el usuario lo solicita:

Describe lo depositado
El valor de cada item
Total

El usuario/cliente presiona el botón de comienzo
Existe un operador que desea saber lo siguiente:

Cuantos ítems han sido retornados en el día.
Al final de cada día el operador solicita un resumen de todo lo depositado en el día.

El operador debe además poder cambiar:

Información asociada a ítems.
Dar una alarma en el caso de que:

Item se atora.
No hay más papel.

Como una primera aproximación identificamos a los actores que interactúan con el sistema:

Luego, tenemos que un Cliente puede Depositar Items y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

Diagramas de Secuencia

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso 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 pasados entre los objetos.

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "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 vectores horizontales. 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.

Cada objeto representa una columna distinta, se pone un símbolo de objeto al final de la flecha que representa el mensaje que ha creado el objeto; está situada en el punto vertical que denota el instante en que se crea el objeto. Esta se conoce como línea de vida del objeto. Se pone una X grande en el punto en que deja de existir el objeto o en el punto en que el objeto se destruye a sí mismo. Para el periodo durante el cual esté activo el objeto, la línea de vida se amplía para ser una línea doble continua. Si el objeto se llama a sí mismo, entonces se superpone otra copia de la doble línea para mostrar la doble activación. El orden relativo de los objetos no tiene significado aún cuando resulta útil organizarlos de modo que se minimice la distancia de las flechas.

Cada mensaje se representa mediante una flecha horizontal que va desde la línea de vida del objeto que envió el mensaje hasta la línea de vida del objeto que ha recibido el mensaje. Si un mensaje requiere un cierto tiempo para llegar a su destino, entonces la flecha del mensaje se dibuja diagonalmente hacia abajo.

Para un flujo de objeto asíncrono entre objetos activos, los objetos se representan mediante líneas dobles continuas y los mensajes se representan como flechas. Se pueden enviar simultáneamente dos mensajes pero no se pueden recibir simultáneamente porque no se puede garantizar una recepción simultánea.

Las bifurcaciones se muestran partiendo la línea de vida del objeto. Cada bifurcación puede enviar y recibir mensajes. Eventualmente las líneas de vida del objeto tienen que fusionarse de nuevo.

Un diagrama de secuencia también se puede mostrar en forma de descriptor, en el cual los constituyentes son roles en lugar de objetos. Este diagrama muestra en el caso general, no una sola ejecución del mismo. Los diagramas del nivel de descriptores se dibujan sin subrayados porque los símbolos denotan roles y no objetos individuales.

Los elementos fundamentales de un diagrama de secuencia son los siguientes:

Línea de vida de un objeto ( lifeline ): La línea de vida de un objeto representa la vida del objeto durante la interacción. En un diagrama de secuencia un objeto se representa como una línea vertical punteada con un rectángulo de encabezado y con rectángulos a través de la línea principal que denotan la ejecución de métodos (activación).
Activación : Muestra el período de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.
Mensaje : El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.
Tiempos de transición : En un entorno de objetos concurrentes o de demoras en la recepción de mensajes, es útil agregar nombres a los tiempos de salida y llegada de mensajes
Caminos alternativos de ejecución y concurrencia : En algunos casos sencillos los caminos alternativos pueden expresarse en un diagrama de secuencias alternativas de ejecución. Estas alternativas pueden representar condiciones en la ejecución o diferentes hilos de ejecución ( threads ).
Destrucción de un objeto Se representa como una X al final de la línea de ejecución del objeto; indicando la finalización del objeto.
Métodos recursivos . Es un rectángulo adyacente a la activación principal y con líneas de llamada de mensajes, que indican la entrada y salida de la recursión.

Ejemplo de un Diagrama de Secuencia.

Este diagrama describe la secuencia (simplificada) de mensajes de un sistema de restaurante. El diagrama representa a un cliente pidiendo comida y pagando.

INFOGRAFIA

- Titulo: Casos de Uso (Use Case)

Url: http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html

- Titulo: Conceptos de un diagrama de Casos de Uso

Url: http://www.cs.ualberta.ca/~pfiguero/soo/uml/casos_uso01.html

- Titulo: Ingenieria de SoftwareUML

Url: http://www.monografias.com/trabajos5/insof/insof.shtml

- Titulo: Diagramas de Secuencia.

Url: http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x194.html

- Titulo: Lenguaje Unificado de Modelado.

Url: http://es.wikipedia.org/wiki/UML

- Titulo: Diagramas de Secuencia.

Url: http://www.creangel.com/uml/secuencia.php

- Titulo: Diagramas de Secuencia.

Url: http://www-gris.det.uvigo.es/~avilas/UML/node42.html

Inicio


Gustavo Romero		Sub-Tema: Diagrama de Estrucrura Estática, Diagrama de Colaboración

Diagrama de Estructura Estática

Un diagrama de estructura estática muestra el conjunto de clases y objetos importantes que hacen parte de un sistema, junto con las relaciones existentes entre estas clases y objetos. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con las demás en el modelo.

Los Diagramas de Estructura Estática de UML se utilizan para representar tanto Modelos Conceptuales como Diagramas de Clases de Diseño. Ambos usos son distintos conceptualmente, mientras los primeros modelan elementos del dominio los segundos presentan los elementos de la solución software. Ambos tipos de diagramas comparten una parte de la notación para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). Además existen diversos elementos de notación que son exclusivos de uno u otro tipo de diagrama, entre los cuales destacan:

Clases

Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemática, con los atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase.

Objetos: Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase.
Asociaciones: Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación.
Herencia: La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase “padre”.
Elementos Derivados: Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como decisión de diseño. Se representa con una barra “/” precediendo al nombre del elemento derivado.

En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.

Un diagrama de colaboración es una forma alternativa al diagrama de secuencia de mostrar un escenario. Este tipo de diagrama muestra las interacciones entre objetos organizadas entorno a los objetos y los enlaces entre ellos.

En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que “circulan”, y con el nombre del mensaje y los parámetros (si los tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar alternativas con condiciones entre corchetes . También se puede mostrar el anidamiento de mensajes con números de secuencia.

Además muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente.
Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.

Un enlace es una instancia de una asociación que conecta dos objetos de un diagrama de colaboración. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.

Los diagramas de interacción indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples, sincrónicos, balking, timeout y asíncronos. Durante la ejecución de un diagrama de colaboración se crean y destruyen objetos y enlaces.

INFOGRAFIA

- Titulo: Diagrama de clases (estructura estática)

En UML los paquetes se representan como carpetas que pueden presentar relaciones de dependencia o de generalización entre ellos. 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.

Url: http://www-gris.det.uvigo.es/~avilas/UML/node37.html

- Titulo: Conceptos avanzados en un diagrama de estructura estática

Entre los conceptos avanzados en un diagrama de estructura estática predominan el estereotipo, interfaz, Asociación or, Clase de Asociación, Asociación n-aria, Calificador, Compartimiento de Nombre y de Lista, Propiedad, Expresión de Tipo, Elemento acotado, Tipo, Utilidad, Metaclase, Caminos de composición de clases, Relación de refinamiento, Elemento derivado y Expresión de navegación.

Url: http://www.cs.ualberta.ca/~pfiguero/soo/uml/estr_estatica02.html

- Titulo: Diagramas de Estructura Estatica (1)

Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación, por otra parte la multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase.

Url: http://www.wikilearning.com/diagramas_de_estructura_estatica_1-wkccp-6321-3.htm

- Titulo: Patron Iterator

Diagrama de Estructura estática representado mediante un ejemplo muy sencillo relacionado con la implementación de una clase Lista y dos recorridos sobre ella: Recorrido hacia adelante y recorrido hacia atrás.

Url: http://agamenon.uniandes.edu.co/~pfiguero/soo/PatronesDiseno/Iterator/ejemplo2.htm

- Titulo: Diagramas de Estructura Estatica (1)

Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como decisión de diseño. Se representa con una barra “/” precediendo al nombre del elemento derivado.

Url: http://www.wikilearning.com/diagramas_de_estructura_estatica_2-wkccp-6321-4.htm

- Titulo: Diagramas de Colaboración

Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje y la visibilidad de un objeto con respecto a los otros.

Url: http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x208.html

- Titulo: Conceptos avanzados en un Diagrama de Colaboración

Un diagrama de colaboración puede especificar un contrato entre objetos, parte esencial para la descripción de un patrón de diseño. . Una "instanciación" del patrón se representa como una elipse unida mediante flechas puenteadas a los objetos o clases que participan realmente en el patrón.

Url: http://www.cs.ualberta.ca/~pfiguero/soo/uml/colaboracion02.html

- Titulo: Diagramas de Colaboración

Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La colaboració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 mesajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa

Url: http://www.creangel.com/uml/colaboracion.php

- Titulo: Diagramas de Colaboración

Url: http://www-gris.det.uvigo.es/~avilas/UML/node43.html

- Titulo: Conceptos avanzados en un diagrama de estructura estática

Url: http://www.cs.ualberta.ca/~pfiguero/soo/uml/estr_estatica02.html

- Titulo: Diagramas de Estructura Estatica (1)

Url: http://www.wikilearning.com/diagramas_de_estructura_estatica_1-wkccp-6321-3.htm

Inicio


Alexis Velazco		Sub-Temas: Diagrama de Estados, Herramientas Case basadas en UML.

Diagramas de Estado

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. Un estado identifica un período de tiempo (no instantáneo) en la vida del objeto durante el cual está esperando alguna operación, tiene cierto comportamiento característico o puede recibir cierto tipo de estímulos. En notación UML, un estado se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimentos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente).

Elementos del Diagrama de Estado.

Estado

situación en la vida de un elemento durante la cual se satisface alguna condición, se realiza alguna actividad o se espera algún suceso (Inicial, Intermedio, Final)

– Transición: relación entre dos estados que indica que un elemento que esté en un primer estado realizará ciertas acciones y entrará en el segundo estado cuando se produzca un suceso especificado y se satisfacen las condiciones indicadas

– Suceso o Evento: especificación de algún acontecimiento que ocupa espacio y tiempo. Es la aparición de un estímulo que puede disparar la transición de un estado a otro

Actividad: ejecución no atómica en curso, dentro de una máquina de estados. Lo que se hace en el estado

– do: operación que toma un tiempo en el estado. Puede interrumpirse por un suceso, externo o interno, o terminar en transición automática

• Acción: computación atómica ejecutable que produce un cambio de estado del modelo o devuelve algún valor (deben ser operaciones de la clase)

– entry: instantáneamente a la entrada del estado

– exit: instantáneamente a la salida del estado

– eventos

Eventos

Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas:

* Condición que toma el valor de verdadero o falso

* Recepción de una señal de otro objeto en el modelo

* Recepción de un mensaje

* Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular

El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo nombre.

Envío de mensajes

Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.

Transición

Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Las transiciones se representan mediante flechas. Se acostumbra poner un estado inicial (círculo negro), que puede venir acompañada de un texto con el nombre del evento respectivo con el siguiente formato:

event-signature "[" guard-condition] "/" action-expression "^"send-clause

event-signature es la descripción del evento que da lugar la transición, guard-condition son las condiciones adicionales al evento necesarias para que la transición ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transición y el cambio de estado y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envío de eventos a otros paquetes o clases.

Transición interna

Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado.

Acciones:

Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento.

Generalización de Estados:

Ejemplo

* Podemos reducir la complejidad de estos diagramas usando la generalización de estados.

* Distinguimos así entre superestado y subestados.

* Un estado puede contener varios subestados disjuntos.

* Los subestados heredan las variables de estado y las transiciones externas.

* La agregación de estados es la composición de un estado a partir de varios estados independientes.

La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.

Subestados

Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.

Transacción Compleja

Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.

Transición a estados anidados

Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).

Transiciones temporizadas

* Las esperas son actividades que tienen asociada cierta duración.

* La actividad de espera se interrumpe cuando el evento esperado tiene lugar.

* Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado.

Herramientas CASE

CASE es una sigla, que corresponde a las iniciales de: Computer Aided Software Engineering; y en su traducción al Español significa Ingeniería de Software Asistida por Computación.

El concepto de CASE es muy amplio; y una buena definición genérica, que pueda abarcar esa amplitud de conceptos, sería la de considerar a la Ingeniería de Software Asistida por Computación (CASE), (Computer Aided Software Engineering) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero.

Concentrando nuestra atención en el uso de estas herramientas, para el desarrollo de proyectos informáticos que tengan como objetivo la automatización de procedimientos adiministrativos; podemos decir que:

Las herramientas CASE representan una forma que permite Modelar los Procesos de Negocios de las empresas y desarrollar los Sistemas de Información Gerenciales.

Objetivos del CASE

1. Aumentar la productividad de las áreas de desarrollo y mantenimiento de los sistemas informáticos.

2. Mejorar la calidad del software desarrollado.

3. Reducir tiempos y costes de desarrollo y mantenimento del software.

4. Mejorar la gestión y dominio sobre el proyecto en cuanto a su planificación, ejecución y control.

5. Mejorar el archivo de datos (enciclopedia) de conocimientos (know-how) y sus facilidades de uso, reduciendo la dependencia de analistas y programadores.

6. Automatizar :

* El desarrollo del software

* La documentación

* La generación del código

* El chequeo de errores

* La gestión del proyecto

7. Permitir

* La reutilización (reusabilidad) del software

* La portabilidad del software

* La estandarización de la documentación

8. Integrar las fases de desarrollo (ingeniería del software) con las herramientas CASE

9. Facilitar la utilización de las distintas metodologías que desarrollan la propia ingeniería del software.

Estructura general de una herramienta case

La estructura CASE se basa en la siguiente terminología:

* CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas.

* CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas.

* CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación.

Clasificación de las herramientas case

No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:

- Las plataformas que soportan.

- Las fases del ciclo de vida del desarrollo de sistemas que cubren.

- La arquitectura de las aplicaciones que producen.

- Su funcionalidad.

Una primera clasificación del CASE es considerando su amplitud :

TOOLKIT: es una colección de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informático: Planificación estratégica, Análisis, Diseño, Generación de programas.

WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable y su documentación.

Una segunda clasificación es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan:

UPPER CASE: Planificación estratégica, Requerimientos de Desarrollo Funcional de Planes Corporativos.

MIDDLE CASE: Análisis y Diseño.

LOWER CASE: Generación de código, test e implantación

INFOGRAFIA

- Titulo: Herramientas Case

Url: http://www.monografias.com/trabajos14/herramicase/herramicase.shtml

- Titulo: Herramientas Case.

Url: http://www.ilustrados.com/publicaciones/EpykZkulZZsYzwABxh.php

-Titulo: Herramientas Case

Url: http://www.monografias.com/trabajos14/herramicase/herramicase.shtml

- Titulo: Herramientas Case.

Url: http://es.wikipedia.org/wiki/Herramienta_CASE

- Titulo: Introducción a los Sistemas y Herramientas Case.