Si no puedes ver el video, dale en ver video para poder visualizar la instalación del Rational Rose 2007.
ver video
martes, 26 de octubre de 2010
martes, 5 de octubre de 2010
DETALLE A FONDO DE UML 2.0
Modelado de casos de uso
Comenzamos el modelado de un sistema trabajando en la vista de casos de uso, introduciendo a través del explorador:
• Los elementos del modelo de casos de uso del negocio (si consideramos conveniente realizar un modelado del negocio)
• Los elementos del modelo de casos de uso del sistema
Vamos a crear el modelo de casos de uso del sistema. Para ello, primero crearemos a través del explorador los elementos del modelo de casos de uso (actores y casos de uso), y después crearemos los diagramas de casos de uso que mostrarán el modelo.
Comenzamos interactuando directamente con el explorador, para crear los actores y casos de uso que hay en el diagrama de casos de uso de la Figura 1. (Sólo los actores y casos de uso, no el diagrama.)
Para crear un actor en el explorador:
1. Clic con el botón derecho del ratón sobre la carpeta Use Case View.
2. Seleccionar New:Actor. En el explorador aparece un nuevo actor denominado NewClass.
3. Selecciónalo y cámbiale el nombre por defecto por el nombre apropiado.
4. Haz doble clic sobre el actor, y observa cómo se edita como una clase, con sus atributos y operaciones, pero con el estereotipo <<actor>>.
Para documentar un actor:
1. Si la ventana de documentación no es visible, ábrela seleccionando el menú View y activando la opción Documentation.
2. Selecciona el actor en el explorador.
3. Pon el cursor en la ventana de documentación y escribe el texto que describa el actor.
Para crear un caso de uso a través del explorador, y añadirle una breve descripción textual, se sigue los mismos pasos que para crear un actor, pero con New:Use Case.
 |
Figura Nº 1: Diagrama de Caso de Uso |
Crea un diagrama de casos de uso
Cada sistema tiene normalmente un Main Use Case Diagram, que representa los límites del sistema (actores) junto con las principales funciones del mismo (casos de uso). Por supuesto, se pueden construir otros diagramas de casos de uso con otros objetivos, por
ejemplo:
• para mostrar todos los casos de uso de un paquete
• para mostrar todos los casos de uso para un actor determinado
• para mostrar todos los casos de uso que son implementados en una iteración
• para mostrar un caso de uso y todas sus relaciones
Para crear un diagrama de casos de uso:
Con botón derecho sobre la carpeta correspondiente, New:Use Case Diagram.
Crea ahora un diagrama denominado Diagrama Casos de Uso TPV, y arrastra sobre él los actores y casos de uso de la Figura 1, los cuales has creado mediante el explorador.
Por supuesto, los actores y casos de uso se pueden crear también directamente en la ventana usando la barra de herramientas.
Establece relaciones entre casos de uso.
Crea un caso de uso Pago con Tarjeta y establece una relación include de Realizar Venta a este nuevo caso de uso. Cambia después la relación por una extend.
Relaciones entre casos de uso
Tenemos tres relaciones principales entre casos de uso en Rose:
<<include>>
<<extend>>
Generalización
(En Rose también se proporciona el estereotipo <<communicate>>, que representa la
comunicación entre un actor y un caso de uso, y se muestra de manera opcional. Esta
relación es poco utilizada.)
Para crear relaciones entre casos de uso
1. Pinchar el icono Dependency or instantiates
2. Arrastrar la línea en el sentido adecuado
3. Doble clic sobre la línea para hacer visible Specification/General
4. Seleccionar el valor adecuado en el campo Stereotype puedes poner o quitar la flecha de la relación con botón derecho/Navigable sobre la relación, cerca del extremo adecuado.
Crea un Diagrama de Secuencia del Sistema
(Para el caso de uso Realizar Venta)
Como sabemos, los diagramas de secuencia del sistema son diagramas de interacción de tipo diagrama de secuencia. Denominaremos a este diagrama DSS1 (ver Figura 2).
• Crea el diagrama desde el explorador con botón derecho sobre el caso de uso /New:Sequence Diagram.
• Ábrir con doble clic.
• Para cada actor u objeto en el escenario:
o Selecciona el actor en el explorador, y arrástralo al diagrama.
o Selecciona el icono Object de la barra de herramientas, e introduce el objeto (Sistema en este caso).
o Para asignar el objeto a una clase, puedes seleccionar la clase en el explorador y arrastrarla sobre el objeto.
• Usa el icono Object Message para introducir los mensajes.
 |
Figura Nº 2: Diagrama de Secuencia |
INTRODUCCION
Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños con algún modelo gráfico. La falta de estandarización en la representación gráfica de un modelo impedía que los diseños gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores, con este objetivo se creó el Lenguaje Unificado de Modelado (UML: Unified Modeling Language).
UML es el lenguaje de modelado de sistemas de software más conocido en la actualidad; es el estándar internacional aprobado por la OMG (Object Managment Group), consorcio creado en 1989 responsable de la creación, desarrollo y revisión de especificaciones para la industrial del software.
En el presente blog se va a analizar los diagramas que componen la Metodología UML 2.0 para un caso particular de aplicación que servirá de base para la elaboración de los diagramas usados para modelar sistemas complejos.
En el presente blog se va a analizar los diagramas que componen la Metodología UML 2.0 para un caso particular de aplicación que servirá de base para la elaboración de los diagramas usados para modelar sistemas complejos.
martes, 21 de septiembre de 2010
PERSPECTIVA GENERAL DE UML
Una vuelta por un caso de uso
Una vez más, UML es una notación, no un método. No preescribe un proceso para modelar un sistema.
No obstante, como UML incluye los diagramas de casos de uso, se le considera estar dotado de una aproximación al diseño centrada en el problema con los casos de uso. El Diagrama de Caso de Uso nos da el punto de entrada para analizar los requisitos del sistema, y el problema que necesitamos solucionar.
Casos de Uso y Diagramas de Interacción
Un caso de uso se modela para todos los procesos que el sistema debe llevar a cabo. Los procesos se describen dentro del caso de uso por una descripción textual o una secuencia de pasos ejecutados.
Una vez que el comportamiento del sistema está captado de esta manera, los casos de uso se examinan y amplían para mostrar qué objetos se interrelacionan para que ocurra este comportamiento.
Los Diagramas de Colaboración y de Secuencia se usan para mostrar las relaciones entre los objetos.
 |
| GRÁFICO Nº 1: Relación de Actor - Caso de Uso en Rational Rose |
Clases y Diagramas de Implementación
Conforme se van encontrando los objetos, pueden ser agrupados por tipo y clasificados en un Diagrama de Clase.
Es el diagrama de clase el que se convierte en el diagrama central del análisis del diseño orientado a objetos, y el que muestra la estructura estática del sistema.
El diagrama de clase puede ser dividido en capas: aplicación, y datos, las cuales muestran las clases que intervienen con la interfaz de usuario, la lógica del software de la aplicación, y el almacenamiento de datos respectivamente.
Los Diagramas de Componentes se usan para agrupar clases en componentes o módulos. La distribución general del hardware del sistema se modela usando el Diagrama de Implementación.
 | |
|
Diagramas de Estado
El comportamiento en tiempo real de cada clase que tiene comportamiento dinámico y significativo, se modela usando un Diagrama de Estado.
Implementando el diseño
La implementación del sistema trata de traducir información desde múltiples modelos UML en código y estructura de bases de datos. Cuando se modela un sistema grande, es útil fragmentar el sistema en su capa ’business’ (incluyendo los objetos de la interfaz de usuario), su capa de aplicación (incluyendo los objetos de implementación), y su capa de datos (incluyendo la estrucutra de la base de datos y el acceso a objetos).
Implementando la aplicación
El Diagrama de Clase se usa para generar una estructura base del código en el lenguaje escogido.
Información de los diagramas de interacción, estado, y actividad, puede ofrecer detalles de la parte procedimental del código de implementación.
Implementando el diseño de Bases de Datos
La capa de datos del diagrama de clase se puede usar para implementar directamente un diseño orientado a objetos de una base de datos, o, como extensión de UML, puede ser referenciado en un diagrama de relación de entidad para más análisis de relaciones de entidad. Está en el diagrama de relación de entidad el cual relaciona entre entidades que pueden ser modeladas basadas en atributos clave.
Probar teniendo en cuenta los requisitos
Los casos de uso se utilizan también para probar el sistema y ver si satisface los requisitos iniciales. Los pasos de los casos de uso van llevando a cabo para determinar si el sistema está satisfaciendo los requisitos del usuario.
lunes, 6 de septiembre de 2010
¿QUÉ ES UML 2.0?
UML 2.0 (Lenguaje Unificado de Modelado) es un conjunto de herramientas, que permite modelar (analizar y diseñar) sistemas orientados a objetos.
Abarca notaciones y diagramas estándar para el modelado de sistemas orientados a objetos y además describe lo que estos diagramas y símbolos significan.
• Diagramas de Casos de Uso: para modelar los procesos ’business’.
• Diagramas de Secuencia: para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración: para modelar interacciones entre objetos.
• Diagramas de Estado: para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad: para modelar el comportamiento de los Casos de Uso.
• Diagramas de Clases: para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos: para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes: para modelar componentes.
• Diagramas de Implementación: para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más usados orientados a objetos.
2.1. NOTACIÓN SEMÁNTICA ESTÁNDAR
UML preescribe una notación estándar para el modelado de un sistema orientado a objetos. Previamente, un diseño orientado a objetos podría haber sido modelado con cualquier metodología conocida, causando a los revisores tener que aprender la sintaxis de la metodología empleada antes que intentar entender el diseño en sí.
Ahora con UML, diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de los otros.
2.2. ¿QUÉ NO ES UML?
Hay que tener en cuenta que UML no preescribe un proceso o método estándar para desarrollar un sistema.
No te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.
Esteroetipos
2.3. EXTENSIONES EN UML
Los mecanismos de de extensibilidad incorporados permiten a UML ser una especie de especificación abierta que puede cubrir aspectos de modelado. Estos mecanismos permiten extender la notación y semántica de UML.
Esteroetipos
Los estereotipos es un mecanismo de extensibilidad incorporado, el más utilizado dentro de UML. Un estereotipo representa una distinción de uso.
Puede ser aplicado a cualquier elemento de modelado, incluyendo clases, paquetes, relaciones de herencia, etc.
Por ejemplo, una clase con estereotipo ’actor’ es una clase usada como un agente externo en el modelado de negocio.
 |
| GRÁFICO Nº 1: Definición de Actor / Caso de Uso |
 |
| GRÁFICO Nº 2: Definición de un actor en Rational Rose |
Suscribirse a:
Entradas (Atom)