Sunteți pe pagina 1din 11

EL LENGUAJE UNIFICADO DE MODELADO (UML)

En todas las disciplinas de la Ingeniera se hace evidente la importancia de los


modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede
existir, estar en un estado de desarrollo o estar, todava, en un estado de
planeacin. Es en este momento cuando los diseadores del modelo deben
investigar los requerimientos del producto terminado y dichos requerimientos
pueden incluir reas tales como funcionalidad, performance y confiabilidad.
Adems, a menudo, el modelo es dividido en un nmero de vistas, cada una de
las cuales describe un aspecto especfico del producto o sistema en construccin.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones
de pequeo tamao se obtienen beneficios de modelado, sin embargo es un
hecho que entre ms grande y ms complejo es el sistema, ms importante es el
papel de que juega el modelado por una simple razn: "El hombre hace modelos
de sistemas complejos porque no puede entenderlos en su totalidad".
UML es una tcnica para la especificacin sistemas en todas sus fases. Naci en
1994 cubriendo los aspectos principales de todos los mtodos de diseo
antecesores y, precisamente, los padres de UML son Grady Booch, autor del
mtodo Booch; James Rumbaugh, autor del mtodo OMT e Ivar Jacobson, autor
de los mtodos OOSE y Objectory. La versin 1.0 de UML fue liberada en Enero
de 1997 y ha sido utilizado con xito en sistemas construidos para toda clase de
industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronutica,
finanzas, etc.
Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o ms).

Modelar sistemas (y no slo de software) utilizando conceptos orientados a


objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de misin


crtica.

Crear un lenguaje de modelado utilizado tanto por humanos como por


mquinas.

Mejor soporte a la planeacin y al control de proyectos.

Alta reutilizacin y minimizacin de costos.

UML, Mtodo o Lenguaje de Modelado?


UML es un lenguaje para hacer modelos y es independiente de los mtodos de
anlisis y diseo. Existen diferencias importantes entre un mtodo y un lenguaje
de modelado. Un mtodo es una manera explcita de estructurar el pensamiento y
las acciones de cada individuo. Adems, el mtodo le dice al usuario qu hacer,
cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras que el lenguaje de
modelado carece de estas instrucciones. Los mtodos contienen modelos y esos
modelos son utilizados para describir algo y comunicar los resultados del uso del
mtodo.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado
consiste de vistas, diagramas, elementos de modelo los smbolos utilizados en
los modelos y un conjunto de mecanismos generales o reglas que indican
cmo utilizar los elementos. Las reglas son sintcticas, semnticas y pragmticas
(figura 1).

figura 1
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista
no es una grfica, pero s una abstraccin que consiste en un nmero de
diagramas y todos esos diagramas juntos muestran una "fotografa" completa del
sistema. Las vistas tambin ligan el lenguaje de modelado a los mtodos o
procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

Vista Use-Case: Una vista que muestra la funcionalidad del sistema como
la perciben los actores externos.

Vista Lgica: Muestra cmo se disea la funcionalidad dentro del sistema,


en trminos de la estructura esttica y la conducta dinmica del sistema.

Vista de Componentes: Muestra la organizacin de los componentes de


cdigo.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los


problemas con la comunicacin y sincronizacin que estn presentes en un
sistema concurrente.

Vista de Distribucin: muestra la distribucin del sistema en la arquitectura


fsica con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las grficas que describen el contenido de una
vista. UML tiene nueve tipos de diagramas que son utilizados en combinacin para
proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de
objetos, de estados, de secuencia, de colaboracin, de actividad, de componentes
y de distribucin.
Smbolos o Elementos de modelo: Los conceptos utilizados en los diagramas
son los elementos de modelo que representan conceptos comunes orientados a
objetos, tales como clases, objetos y mensajes, y las relaciones entre estos
conceptos incluyendo la asociacin, dependencia y generalizacin. Un elemento
de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el
mismo significado y simbologa.
Reglas o Mecanismos generales: Proveen comentarios extras, informacin o
semntica acerca del elemento de modelo; adems proveen mecanismos de
extensin para adaptar o extender UML a un mtodo o proceso especfico,
organizacin o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Anlisis de
requerimientos, Anlisis, Diseo, Programacin y Pruebas.
Anlisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A
travs del modelado de casos de uso, los actores externos que tienen inters en el
sistema son modelados con la funcionalidad que ellos requieren del sistema (los
casos de uso). Los actores y los casos de uso son modelados con relaciones y
tienen asociaciones entre ellos o stas son divididas en jerarquas. Los actores y
casos de uso son descritos en un diagrama use-case. Cada use-case es descrito
en texto y especifica los requerimientos del cliente: lo que l (o ella) espera del
sistema sin considerar la funcionalidad que se implementar. Un anlisis de
requerimientos puede ser realizado tambin para procesos de negocios, no
solamente para sistemas de software.
Anlisis
La fase de anlisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que estn presentes en el dominio del problema. Las clases que se
modelan son identificadas, con sus relaciones y descritas en un diagrama de

clases. Las colaboraciones entre las clases para ejecutar los casos de uso
tambin se consideran en esta fase a travs de los modelos dinmicos en UML.
Es importante notar que slo se consideran clases que estn en el dominio del
problema (conceptos del mundo real) y todava no se consideran clases que
definen detalles y soluciones en el sistema de software, tales como clases para
interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseo
En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica.
Se agregan nuevas clases que proveen de la infraestructura tcnica: interfaces de
usuario, manejo de bases de datos para almacenar objetos en una base de datos,
comunicaciones con otros sistemas, etc. Las clases de dominio del problema del
anlisis son agregadas en esta fase. El diseo resulta en especificaciones
detalladas para la fase de programacin.
Programacin
En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de
programacin orientado a objetos. Cuando se crean los modelos de anlisis y
diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a
cdigo.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
tpicamente ejecutadas por el programador. Las pruebas de integracin integran
componentes y clases en orden para verificar que se ejecutan como se especific.
Las pruebas de sistema ven al sistema como una "caja negra" y validan que el
sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de
aceptacin conducidas por el cliente verifican que el sistema satisface los
requerimientos y son similares a las pruebas de sistema.
Tabla de Contenido

DIAGRAMA DE CASO DE USO (USE-CASE)


Un modelo de casos de uso es descrito en UML como un diagrama de casos de
uso (diagrama use-case) y dicho modelo puede ser dividido en varios diagramas
de caso de uso. Un diagrama de casos de uso contiene elementos de modelo para
el sistema, los actores y los casos de uso y muestra las diferentes relaciones tales
como generalizacin, asociacin y dependencia entre estos elementos. El
diagrama de caso de uso debe ser fcil de entender por el usuario final (figura 4).

figura 4
Los elementos de un diagrama de casos de uso son:
Sistema
Un sistema en un diagrama de caso de uso es descrito como una caja; el nombre
del sistema aparece arriba o dentro de la caja. sta tambin contiene los smbolos
para los casos de uso del sistema.
Actores
Un actor es alguien o algo que interacta con el sistema; es quien utiliza el
sistema. Por la frase "interacta con el sistema" se debe entender que el actor
enva a o recibe del sistema unos mensajes o intercambia informacin con el
sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor
puede ser una persona u otro sistema que se comunica con el sistema a modelar.

Un actor es un tipo (o sea, una clase), no es una instancia y representa a un rol.


Grficamente se representa con la figura de "stickman".
Encontrando a los actores de un diagrama de casos de uso.
Es posible obtener a los actores de un diagrama de casos de uso a travs de las
siguientes preguntas:

Quin utilizar la funcionalidad principal del sistema (actores primarios)?

Quin necesitar soporte del sistema para realizar sus actividades


diarias?

Quin necesitar mantener, administrar y trabajar el sistema (actores


secundarios)?

Qu dispositivos de hardware necesitar manejar el sistema?

Con qu otros sistemas necesitar interactuar el sistema a desarrollar?

Quin o qu tiene inters en los resultados (los valores) que el sistema


producir?

Casos de uso
Un caso de uso representa la funcionalidad completa tal y como la percibe un
actor. Un caso de uso en UML es definido como un conjunto de secuencias de
acciones que un sistema ejecuta y que permite un resultado observable de valores
para un actor en particular. Grficamente se representan con una elipse y tiene las
siguientes caractersticas:

Un caso de uso siempre es iniciado por un actor.

Un caso de uso provee valores a un actor.

Un caso de uso es completo.

DIAGRAMA DE SECUENCIA
Este diagrama muestra la interaccin de los objetos entre ellos. Es
importante comentar que hasta este momento no se han considerado
objetos tcnicos. En UML, durante el Anlisis de los requerimientos y
el Anlisis, no se consideran objetos tcnicos que definan detalles y
soluciones en el sistema de software, tales como objetos para interfaces de
usuario, bases de datos, comunicaciones, etc. Todos esos objetos se
consideran hasta el diseo del sistema (figura 5).

figura 5
En este diagrama se observa que slo se consideran algunos objetos y es
importante aclarar que estos no sern todos los objetos a considerar dentro
del sistema, ya que todava es posible agregar nuevos objetos que no se
haban considerado en el dominio del anlisis as como los objetos
tcnicos, como se mencion anteriormente. Los objetos considerados se
representan en rectngulos con el nombre subrayado y cada uno cuenta
con su lnea de vida vertical que muestra la vida del objeto.
DIAGRAMA DE COLABORACIN

As mismo, se cuenta con el diagrama de colaboracin (figura 6), el cual se


centra tanto en las interacciones y las ligas entre un conjunto de objetos
colaborando entre ellos (una liga es una instancia de una asociacin).
Ambos, el diagrama de secuencia y el diagrama de colaboracin, muestran
interacciones, pero el diagrama de secuencia se centra en el tiempo
mientras que el diagrama de colaboracin se centra en el espacio. Las ligas
muestran los objetos actuales y cmo ellos se relacionan unos con otros.
As como los diagramas de secuencia, los diagramas de colaboracin
pueden ser utilizados para ilustrar la ejecucin de una operacin, una
ejecucin de un use-case o simplemente un escenario de interaccin dentro
del sistema. En este diagrama tambin se representa a los objetos en cajas
rectangulares y con el nombre subrayado. Las ligas se dibujan con lneas y
se puede agregar una etiqueta para un mensaje y un nmero que define la
secuencia de las ligas.

ESTANDARIZACIN UML
El Lenguaje de Modelado Unificado (UML) es la sucesin de una serie de mtodos de anlisis y
diseos orientados a objetos que aparecen a fines de los 80's y principios de los 90s.
Directamente unifica los mtodos de Booch, Rumbaugh (OMT), y Jacobson, y algo ms.
UML es llamado un lenguaje de modelado, no un mtodo. Los mtodos consisten de ambos de
un lenguaje de modelado y de un proceso.
El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para
expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo.
La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal de

comunicacin. Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje
de modelado y no as el proceso que se sigui para obtenerlo.
Una de la metas principales de UML es avanzar en el estado de la industria proporcionando
herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr
un intercambio exitoso de modelos de informacin entre herramientas, se requiri definirle una
semntica y una notacin.
La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de
modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los
elementos y conceptos como son: una clase, una asociacin y una multiplicidad. Y qu significa
exactamente una asociacin o multiplicidad en una clase?. Un metamodelo es la manera de
definir sto (un diagrama, usualmente de clases, que define la notacin).
Para que un proveedor diga que cumple con UML debe cubrir con la semntica y con la
notacin.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo
modelo. Bajo esta definicin una herramienta que solo dibuje, no puede cumplir con la notacin
de UML.
Software libre para modelado en UML [editar]ArgoUML, Herramienta de modelado UML escrito en
java (enlace externo)
BOUML, Ligera herramienta de modelado UML y generacin de cdigo C++, Java e IDL.
Disponible para Windows, Unix/Linux y Mac OS X (Sitio Oficial)
Fujaba, No solo sirve para modelar sino que puede generar cdigo Java automticamente.
Tambin es capaz de hacer ingenieria inversa y crear los diagramas a partir del cdigo Java [1].
Dia Puede ser usado para modelar varios tipos de diagramas UML (enlace externo)
gModeler Herramienta para modelado de UML basada en Flash (utilizable desde el navegador),
que permite generar cdigo Action Script 2.0 Compatible (enlace externo)
MonoUML Herramienta CASE para la plataforma mono (Sitio Oficial)
Papyrus, Herramienta grfica basada en Eclipse para el modelado con UML2, es de cdigo
abierto y se ofrece bajo licencia EPL (Sitio Oficial)
StarUML Herramienta de modelado para Windows desarrollada en Delphi. Bastante estable y
usable (enlace externo)
TCM, Toolkit for Conceptual Modeling, herramienta para crear diversos tipos de diagramas
incluidos UML [http://wwwhome.cs.utwente.nl/~tcm/ Web oficial)
Umbrello Herramienta para modelado UML para el entorno KDE
UMLet Herramienta para modelado rpido de UML tambin escrita en Java

Vistas de UML:
Una vista es un subconjunto de construcciones de modelado que se enfocan en un
aspecto en particular del sistema.
Las vistas pueden dividirse en tres reas :

Clasifiacin Estructural.

Comportamiento Dinmico.

Gestin del Modelo.


Los clasifiacin estructural describe los elementos del sistema y sus relaciones con
otros elementos.

Los clasificadores incluyen clases, casos de uso, componentes y nodos. Los


clasificadores proveen la base sobre la que se construye el comportamiento dinmico.
Las vistas de clasificacin estructural incluyen:

Vista Esttica: Diagramas de Clase.

Vista de Casos de Uso: Diagramas de Caso de Uso.

Vista de implementacin: Diagrama de Componentes, Diagrama de Despliegue.


El comportamiento dinmico describe el comportamiento del sistema a travs del
tiempo. El comportamiento puede ser descripto como una serie de cambios a fotos del
sistema tomadas desde la vista esttica.
Las vistas de Comportamiento Dinmico Incluyen:

Vista de la Mquina de Estados: Diagrama de Estados (ciclo vida objeto)

Vista de Actividades: Diagrama de Actividades.

Vista de Interaccin: Diagramas de Secuencia, Diagramas de Colaboracin.


La gestin de modelo describe a organizacin de los modelos mismos en unidades
jerrquicas. El paquete es la unidad de organizacin para los modelos. Tipos especiales
de paquetes son los modelos y subsistemas.

Vista de Gestin.

2.3. Extensiones UML 1.1


Los mecanismos de de extensibilidad incorporados permiten a UML ser una
especie de especificacin abierta que puede cubrir aspectos de modelado no
especificados en el documento 1.1. Estos mecanismos permiten extender la
notacin y semtica de UML.

2.3.1. Esteroetipos
Los estereotipos son el mecanismo de extensibilidad incorporado ms utilizado
dentro de UML. Un estereotipo respresenta una distincin 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. Una clase patrn
es modelada como una clase con estereotipo parametrizado, lo que significa que
puede contener parmetros.

2.3.2. Extensiones de Modelado de Negocio


Un documento separado dentro de la especificacin UML define clases y
estereotipos de asociacin especficos que extienden UML hasta cubrir conceptos
de modelado de negocio. Esto incluye 'stereotyping' una clase como un actor, un
trabajador ('both internal and case'), o una entidad, y 'stereotyping' una asociacin
como una comunicacin simple, o una subcripcin entre un origen y un objetivo.

2.3.3. Lenguaje restrictivo (constraint) de objetos (OCL)


Una imagen puede describir muchas palabras. De igual modo, un modelo grfico
puede describir una cierta parte del comportamiento, despus de la cual es
necesario rellenar detalles adicionales con palabras. Describiendo algo con
palabras, sin embargo, casi siempre desemboca en ambiguedades; por ejemplo,
"que quera decir cuando escribi eso?". El Lenguaje Restrictivo (constraint) de
Objetos (OCL) est incorporado en UML como un estndar para especificar
detalles adicionales, o precisar detalles en la estrucutura de los modelos.
Desarrollado dentro de la IBM Insurace Division como un lenguaje de modelado
de negocio, el OCL es un lenguaje formal diseado para ser fcil de leer y de
escribir. OCL es ms funcional que el lenguaje natural, pero no tan preciso como
un lenguaje de programacin - no puede ser usado para escribir lgicas de lgica
de programacin o control de flujo. Puesto que OCL es un lenguaje para la
expresin pura, sus declaraciones estn garantizadas de no tener efectos laterales
- simplemente transportan un valor y nunca pueden cambiar el estado del sistema.

S-ar putea să vă placă și