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.


GRÁFICO Nº 2: Diagrama de Clases en Rational Rose


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.


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