Herramienta CASE

Las herramientas CASE (Computer Aided Software Engineering,Ingeniera de

Software Asistida por Computadora) son diversasaplicaciones informticas destinadas a
aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en
trminos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del
ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del
proyecto, clculo de costos, implementacin de parte del cdigo automticamente con el
diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. Ya
en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un producto que
analizaba la relacin existente entre los requisitos de un problema y las necesidades que
stos generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement Language)
y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem
Statement Analyzer).
Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos
proyectos informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el
ao 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la
que IBM haba conseguido una alianza con la empresa de software AD/Cycle para trabajar
con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban
todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos
utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el
mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del
software.

Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informticos.
4. Mejorar la planificacin de un proyecto
5. Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la
bsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las
pruebas de errores y la gestin del proyecto.
7. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la
documentacin

8. Gestin global en todas las fases de desarrollo de software con una misma
herramienta.
9. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.

Clasificacin
Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se
pueden clasificar teniendo en cuenta los siguientes parmetros:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que
cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases

de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre
otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en

el anlisis y diseo de la aplicacin.

Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de cdigo,

crean programas de deteccin de errores, soportan la depuracin de programas y
pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden
incluirse las herramientas de Desarrollo rpido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin
excluyente entre s, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo

software, desde anlisis hasta implementacin.

MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de

modelado, los elementos permitidos del metamodelo generado se guardan en un

repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos
nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.

CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de

software.

IPSE (Integrated Programming Support Environment), herramientas que soportan todo

el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la
configuracin activa.

Por funcionalidad podramos diferenciar algunas como:

Herramientas de generacin semiautomtica de cdigo.

Editores UML.

Herramientas de Refactorizacin de cdigo.

Herramientas de mantenimiento como los sistemas de control de versiones

Lista de Herramientas CASE

En esta seccin se mostrarn las herramientas CASE expuestas, su link a estos productos y con una
breve descripcin.
NetBeans

NetBeans

Herramienta muy buena

con caractersticas buenas
como desarrollo intuitivo
gratis y open source dragand-drop para mayor
rapidez Principalmente
para desarrollo de
escritorio Web Mobile y
enterprise con
compatibilidad con java
C/C++ Ruby PHP
javascript tiene algunas
mejoras con UML aunque
no es el mas optimo tiene
algo muy interesante
creador de juegos para
celulares

Es una potente
Eduardo Galicia /
herramienta pero no para Gerardo Valencia
el desarrollo UML ya que
no genera cdigo por si
solo hay que instalar una
seria de plugins que no
son compatibles con las
diferentes versiones por
hay seria un poco el
problema. creo que una
ves instalado el
complemento podra
posicionarse como una
herramienta optima para
poder desarrollar
diagrama de clases de una
manera muy eficaz

Microsoft Visio

Visio

Herramienta de
diagramacin avanzada
con gran variedad de
plantillas que permiten
simplificar las tareas
complejas con elementos

En general es una
Herramienta potente con
grandes caractersticas
aunque limitan-tes en
cuanto a generar cdigo e
Ingeniera inversa por

Eduardo Galicia Soto /

Gerardo Valencia

visuales dinmicos
basados en datos, UML
Bases de Datos
Arquitectura ect con
SharePoint con ms
facilidad sin generar
cdigo Pero bastante
atractiva para hacer
distintos diagramas

compatibilidad y
bsicamente seria solo
para hacer diagramas
simples de DFD
principalmente

Eclipse/Omondo

Eclipse/ Omondo

Eclipse dispone de un
Editor de texto . La
compilacin es en tiempo
real. Tiene pruebas
unitarias con JUnit,
control de versiones con
CVS, Como ya sabemos
cdigo abierto Sobre el
cual se pueden montar
herramientas de
desarrollo para cualquier
lenguaje mediante la
implementacion de los
plugins adecuados como
omondo para la
realizacin de diagramas
UML generando cdigo

En lo personal me parece Eduardo Galicia Soto/

muy potente como ya lo
Gerardo Valencia
haba dicho con la
implementacion de
plugins adecuados se
puede llevar a cavo
distintos proyectos, con
distintas herramientas lo
nico que retrasa es la
compatibilidad con las
versiones y eso puede que
le quite algunos puntos
ala aplicacin pero en lo
general muy poderosa

OmniGraffle

OmniGraffle

Es una herramienta de
diagramacin disponible
para OS, muy prctica y
fcil de usar, con muchos
elementos que facilitan la
creacin de DFD. Esta
herramienta brinda la
posibilidad de exportar en
varios formatos, es
accesible y se puede
adquirir directamente en
el Appstore

Es muy buena, sencilla

pero el inconveniente es
que es nicamente para
Mac OS

Gabriela Gonzlez y
Ernesto Urritia

Serena Composer

Serena Composer

Esta herramienta ayuda

en el diseo de la interfaz
grfica y las definiciones
iniciales del sistema, el
producto final de este
software es un reporte no
funcional que detalla el
funcionamiento del
sistema y una visin no
funcional del sistema
(prototipo) que no puede
ser reutilizado para la
etapa de desarrollo

Serena Composer no nos

pareci una buena opcin
pues el resultado de
utilizar este sistema es
nicamente un reporte
(No cdigo)

Gabriela Gonzlez y
Ernesto Urrutia

Erwin

Erwin

Esta herramienta es de las

ms eficientes y
completas, para la tarea
de realizar ingeniera
inversa esta herramienta
es sumamente sencilla,
basta con darle la orden,
no hubo mucho que
explicar pues es

Muy eficiente , es un
software bsico.

Gabriela Gonzlez y
Ernesto Urrutia

realmente sencilla
GUI Design Studio

GUI Design Studio

Es una herramienta
enfocada solamente en el
diseo de interfaces
grficas para
aplicaciones, es muy
sencillo de usar y
contiene muchos
elementos para modelar
pantallas de aplicaciones
botones, cajas de texto,
contraseas, tablas,
iconos y es capaz de
simular el paso de
ventanas.

Es una herramienta facil

de usar, se puede usar
para hacer manuales de
usuario o demostraciones
de como seria una
aplicacion

Hctor Alfredo Jurez

Albarrn / Mauro
Abraham Romero
Moreno

Eclipse Indigo *Plug-in

"UML 2 Tools"

UML 2 Tools

Para la generacin de
diagramas de clases en
Ecplise se necesita un
plug-in, este tiene una
facilidad de uso muy
buena y es fcil de
realizar diagramas de
Clases con todos los
atributos necesarios.

El Plug-in se adapta
perfectamente a Eclipse,
permitiendo ademas del
diagrama de clases, hacer
diagramas de secuencia,
casos de uso, etc., es muy
eficiente ya que no es
muy pesado y no
consume mucha
memoria.

Hctor Alfredo Jurez

Albarrn / Mauro
Abraham Romero
Moreno

Expression Web 4

Expression Web 4

Esta herramienta de
Microsoft permite hacer
paginas web muy fcil ya
que no es necesario
meterse al codigo HTML,
si no permite seleccionar
los elementos de una
paleta y solo arrastrarlos
para crear nuestra pgina.
Permite el uso de cdigo
PHP para hacer
aplicaciones Web
poderosas.

Microsoft Expression
Web 4 Es una herramienta
muy eficiente ya que
cuenta con todo lo
necesario para hacer un
diseo de una pagina Web
incluyendo las
caractersticas de servidor
FTP y cdigo del lado del
servidor, ademas que es
capaz de verificar la
compatibilidad con los
navegadores

Hctor Alfredo Jurez

Albarrn / Mauro
Abraham Romero
Moreno

Edraw

Edraw

Es un programa muy
completo para realizar
diferentes tipos de
diagramas de varias
metodologas, Es muy
sencillo de usar ya que
tiene una interfaz muy
parecida a la de Microsoft
Visio.

Es una herramienta muy

eficaz para el modelado
de DFD, ya que es muy
sencillo de usar, y se
pueden poner todos los
atributos que lleva el
diagrama con mucha
faclilidad

Hctor Alfredo Jurez

Albarrn / Mauro
Abraham Romero
Moreno

ERwin

ERwin

Esta herramienta es muy

eficaz cuando se busca
hacer el diseo de una
Base de Datos ya que
permite crear
paralelamente el modelo
fsico y lgico de la BD.
As mismo permite crear
Triggers, Indices Stored
Procedures, en bastantes
Manejadores de Base de
Datos tanto para hacer
una ingeniera inversa o

ERwin es una
herramienta muy
poderosa que permite
hacer de todo en cuanto a
diseo de BD se refiere,
ademas que soporta la
colaboracin de usuarios
y servicio en la nube

Hctor Alfredo Jurez

Albarrn / Mauro
Abraham Romero
Moreno

pasar el diseo a un
manejador.
MOCKFLOW

MOCKFLOW

Herramienta CASE
enfocada a la etapa de
diseo ya sea web, mvil
o desktop. Tiene servicio
en la nube.

Ofrece muchas ventajas

de exportacin, manejo
fcil y accesible. Solo
sirve para
documentacin.

Mishelle Eduardo
Bermudez Domnguez,
Miguel ngel Flores
Saldvar, Ivn Garca
Messner

yUML

yUML

Herramienta CASE
enfocada a diagramacin
de UML, servicio de la
nube, con diagramas de
clase, actividad y casos de
uso.

La herramienta es muy
interesante ya que ofrece
muchas formas de
diagramar y tiene servicio
de la nube.

Mishelle Eduardo
Bermudez Domnguez,
Miguel ngel Flores
Saldvar, Ivn Garca
Messner

Oracle SQL Developer

Oracle SQL Developer

Herramienta CASE
especializada en Base de
Datos, tiene varios
mdulos de modelado de
datos entre otras y tiene
compatibilidad con
distintos manejadores de
Base de Datos.

Es muy prctica y
sabindola usar se tienen
una gran herramienta
potente no solo a la base
de datos de ORACLE, si
no que a otros
manejadores de base de
datos.

Mishelle Eduardo
Bermudez Domnguez,
Miguel ngel Flores
Saldvar, Ivn Garca
Messner

DIA

DIA

Es una herramienta CASE

(proyecto de GNOME)
tanto enfocada para UML
como para Base de
Datos.

Observamos que es una

herramienta muy bsica,
hecha solamente con fines
educativos.

Mishelle Eduardo
Bermudez Domnguez,
Miguel ngel Flores
Saldvar, Ivn Garca
Messner

CASE Studio 2

Case studio2

es una herramienta case

que es principalmente
orientada al diseo y
modelado de diagramas
de entidad relacin.

En si la herramients es
muy buena ya que te
permite realizar
facilmente los diagramas
y es poderosa ya que
cuenta con una buena
barra de herramientas que
la hacen una buena
herramienta para
presentarte los resultados
esperados

Pedro Antonio Gonzlez

Rivas/Manuel Alejandro
Avalos Aviles

SQL server

sql server

herramienta para realizar

ingenieria inversa

Esta herramienta nos

Pedro Antonio Gonzlez
muestra como se reducen Rivas/Manuel Alejandro
o aumentan el
Avalos Aviles
rendimiento del equipo ya
sea por el tipo de query
que se introduzca y asi
estasr monitoriando y el
objetivo es reducir costo y
rendimiento. Es muy facil
la herramienta de utilizar
y muy util

EASY CASE

easy case

herramienta para realizar

de analisis y diseo

es buena la herramienta
Pedro Antonio Gonzlez
por que te permite obtener Rivas/Manuel Alejandro
los resultados esperados y Avalos Aviles
que es facil de manejar ya
que esta bien definida su
barra de herramientas y es
especifica a lo que se
realiza para el analisis y
diseo

Poseidon

Poseidon

herramienta para realizar

diagramas UML

la herramienta no es muy
buena ya que es

Pedro Antonio Gonzlez

Rivas/Manuel Alejandro

Sharepoint workflow

sharepoint

plataforma de microsoft
de colaboracin
empresarial, funciones de
colaboracin, basado en
el explorador web,
mdulos de
administracin de
proceso, mdulos de
bsqueda y una
plataforma de
administracin de
documento.

complicada realizar los

diagrams ya que la
manipulacin es dificil y
no te cuenta con todo lo
necesario los uml muy
poderosos.

Avalos Aviles

Se muestra que la
herramienta es poderosa,
pero te pide muchos
complementos y no sabes
cuantos son en total, ya
que hast te llega a pedir
un server, y que tengas
instalado varios enlaces
de versiones anteriore. En
lo minimo que se utilizo
la herramienta se mostro
que se entrelazan muy
bien y si se puede
desarrollar buenos
diagramas.

Pedro Antonio Gonzlez

Rivas/Manuel Alejandro
Avalos Aviles

Mostrando 20 elementos

Herramientas CASE (Computer Aided Software Engineering, Ingeniera de SoftwareAsistida por

Computadoras). Son diversas Aplicaciones informticas destinadas a aumentar la productividad en el
Desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas
herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas
como el diseo de proyectos, clculo de costes, implementacin de parte del cdigo automticamente con el
diseo dado, Compilacin automtica, documentacin o deteccin de errores entre otras.
Es un sistema de software que intenta proporcionar ayuda automatizada a las actividades del proceso de
desarrollo de software. Los sistemas CASE a menudo se utilizan como apoyo al mtodo. La primera
herramienta CASE como hoy la conocemos fue Excelerator en 1984, era para PC. Actualmente la oferta de
herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT .

Historia
Ya en los aos 70, un proyecto llamado ISDOS dise un lenguaje y por lo tanto un producto que analizaba la
relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en
cuestin se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las
necesidades de los diseadores PSA (Problem Statement Analyzer).
Aunque esos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos
informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y trabajaba bajo
una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba
conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos
gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a
poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto

completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de
vida del software.

Tecnologa de las herramientas CASE

La tecnologa CASE supone la automatizacin del desarrollo del software, contribuyendo a mejorar la calidad
y la productividad en el desarrollo de sistemas de informacin a la hora de construir software se plantean los
siguientes objetivos:
Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser realizadas con una
herramienta conseguimos agilizar el trabajo.
Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento de los programas.
Mejorar y estandarizar la documentacin.
Aumentar la portabilidad de las aplicaciones.
Facilitar la reutilizacin de componentes software.
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilizacin de grficos.

Componentes de una herramienta CASE

De una forma esquemtica podemos decir que una herramienta CASE se compone de los siguientes
elementos:
Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y
cuya gestin se realiza mediante el apoyo de un Sistema de Gestin de Base de Datos (SGBD) o de
un sistema de gestin de ficheros.
Metamodelo (no siempre visible), que constituye el marco para la definicin de las tcnicas y metodologas
soportadas por la herramienta.
Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con
datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de
datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona as un
medio de comunicacin con otras herramientas.
Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de la
exactitud, integridad y consistencia de los esquemas generados por la herramienta.
Interfaz de usuario, que constar de editores de texto y herramientas de diseo grfico que permitan,
mediante la utilizacin de un sistema de ventanas, iconos y mens, con la ayuda del ratn, definir los
diagramas, matrices, etc. que incluyen las distintas metodologas.

Estructura general de una herramienta CASE

La estructura CASE se basa en la siguiente terminologa :

 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 planificacin de sistemas, el anlisis de sistemas y el diseo
de
sistemas.
CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del
ciclo de vida como el diseo detallado de sistemas, laimplantacin 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 gestin de proyectos y la estimacin.

Clasificacin
Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar
teniendo en cuenta los siguientes parmetros:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La clasificacin basada en las fases del ciclo de desarrollo cubre:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin, anlisis de requisitos
y estrategia del desarrollo, usando, entre otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y diseo de la

aplicacin.

Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de cdigo, crean

programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems
automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de
Desarrollo rpido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente
entre s, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde
anlisis hasta implementacin.

MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los
elementos permitidos del metamodelogenerado se guardan en un repositorio y pueden ser usados por
otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos,
restricciones y relaciones posibles.

CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.

IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de
vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin.

Por funcionalidad podramos diferenciar algunas como:

Herramientas de generacin semiautomtica de cdigo.

Editores UML.

Herramientas de Refactorizacin de cdigo.

Herramientas de mantenimiento como los sistemas de control de versiones.

Ejemplos de Herramientas Case ms utilizadas.

ERwin
PLATINUM ERwin es una herramienta de diseo de base de datos. Brinda productividad en diseo,
generacin, y mantenimiento de aplicaciones. Desde un modelo lgico de los requerimientos de informacin,
hasta el modelo fsico perfeccionado para las caractersticas especficas de la base de datos diseada, ERwin
permite visualizar la estructura, los elementos importantes, y optimizar el diseo de la base de datos. Genera
automticamente las tablas y miles de lneas de stored procedure y triggers para los principales tipos de base
de datos.

EasyCASE
EasyCASE Profesional, el centro de productos para procesos, modelamiento de datos y eventos, e Ingeniera
de Base de Datos, es un producto para la generacin de esquemas de base de datos e ingeniera reversa,
trabaja para proveer una solucin comprensible para el diseo, consistencia y documentacin del sistema en
conjunto.

Oracle Designer
Oracle Designer es un juego de herramientas para guardar las definiciones que necesita el usuario y
automatizar la construccin rpida de aplicaciones cliente/servidor flexibles y grficas. Integrado con Oracle
Developer, Oracle Designer provee una solucin para desarrollar sistemas empresariales cliente/servidor
de segunda generacin.

PowerDesigner

PowerDesigner es una suite de aplicaciones de Powersoft para la construccin, diseo y modelado de datos a
travs de diversas aplicaciones. Es la herramienta para el anlisis, diseo inteligente y construccin slida de
una base de datos y un desarrollo orientado a modelos de datos a nivel fsico y conceptual, que dan a los
desarrolladores de aplicaciones Cliente/Servidor la ms firme base para aplicaciones de alto rendimiento.

System Architect
System Architect posee un repositorio nico que integra todas las herramientas, y metodologas usadas. En la
elaboracin de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos
asociados, comentarios,reglas de validaciones, normalizacin, etc. Posee control automtico de diagramas y
datos, normalizaciones y balanceo entre diagramas "Padre e Hijo", adems de balanceo horizontal, que
trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el
Modelo Funcional.

SNAP
SNAP es un CASE para el desarrollo de aplicaciones en Sistemas AS/400 de IBM. Proporciona el ambiente
integral de trabajo, brindando la posibilidad de construir sistemas de inmejorable calidad, adheridos a los
estndares S.A.A de IBM., totalmente documentados y ajustados a los requerimientos especficos de la
organizacin, en una fraccin del tiempo y coste del que se invertira, si se utilizaran herramientas
tradicionales.

Futuro de las Herramientas CASE

Las herramientas CASE evolucionan hacia tres tipos de integracin:
1. La integracin de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios
locales para el intercambio de datos.
2. La integracin de presentacin confiere a todas las herramientas CASE el mismo aspecto.
3. La integracin de herramientas permite disponer de herramientas CASE capaces de invocar a otra
herramienta CASE.

Glosario de Definiciones Bsicas de CASE

CASE: Ayuda por Computadora a la Ingeniera de Software.

TECNOLOGIA CASE: Una tecnologa del software que mantiene una disciplina de la ingeniera
automatizada para el desarrollo de software, mantenimiento y direccin
incluye metodologas estructuradas, automatizadas y herramientas automatizadas.

de

proyecto,

HERRAMIENTA CASE: Una herramienta del software que automatiza (por lo menos en parte) una
parte del ciclo de desarrollo de software.

SISTEMA CASE: Un conjunto de herramientas CASE integradas que comparten una interface del
usuario comn y corren en un ambiente computacional comn.

KIT de HERRAMIENTAS CASE: Un conjunto de herramientas CASE integradas que se han diseado
para trabajar juntas y automatizar (o proveer ayuda automatizada al ciclo de desarrollo de software,
incluyendo el anlisis, diseo, codificacin y prueba).

METODOLOGIA CASE:metodologa estructurada que define una disciplina e ingeniera como un

acercamiento a todos o algunos aspectos del desarrollo y mantenimiento de software.

PUESTO DE TRABAJO para CASE: Una estacin de trabajo tcnica o computadora personal
equipada con Herramientas Case que automatiza varias funciones del Ciclo de desarrollo de software.

PLATAFORMA de HARDWARE para CASE: Una arquitectura de hardware con uno, dos o tres
sistemas puestos en lnea, que proveen unaplataforma operativa para las Herramientas Case.

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.

Modelado de Sistemas con UML

1.
2.
3.
Una
4.
Un
5.
Uso
6.
7.
8. Bibliografa

El
perspectiva
estudio
de
una
Proceso

lenguaje
general
fondo
herramienta
de

de
de
de

Introduccin
UML
UML
UML
modelado
desarrollo
Conclusiones

Introduccin
En el presente mdulo se permite entregar un material de apoyo que le permita al
alumno poder definir diagramas propios como tambin poder entender el
modelamiento de diagramas ya existentes, y finalmente se analiza los diagramas que
componen UML y ofrece acercamientos a casos de uso guiados sobre cmo estos
diagramas se usan para modelar sistemas, toda vez que el Lenguaje de
Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje
grfico para visualizar, especificar y documentar cada una de las partes que
comprende el desarrollo de software. UML entrega una forma de modelar cosas
conceptuales como lo son procesos de negocio y funciones de sistema, adems de

cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas

de base de datos y componentes de software reusables.

El lenguaje UML
Cualquier rama de ingeniera o arquitectura ha encontrado til desde hace mucho
tiempo la representacin de los diseos de forma grfica. Desde los inicios de la
informtica se han estado utilizando distintas formas de representar los diseos de
una forma ms bien personal o con algn modelo grfico. La falta de
estandarizacin en la manera de representar grficamente un modelo impeda que
los diseos grficos realizados se pudieran compartir fcilmente entre distintos
diseadores.
Se necesitaba por tanto un lenguaje no slo para comunicar las ideas a otros
desarrolladores sino tambin para servir de apoyo en los procesos de anlisis de un
problema. Con este objetivo se cre el Lenguaje Unificado de Modelado (UML:
Unified Modeling Lan-guage).
UML se ha convertido en ese estndar tan ansiado para representar y modelar la
informacin con la que se trabaja en las fases de anlisis y, especialmente, de
diseo.
El lenguaje UML tiene una notacin grfica muy expresiva que permite representar
en mayor o menor medida todas las fases de un proyecto informtico: desde el
anlisis con los casos de uso, el diseo con los diagramas de clases, objetos, etc.,
hasta la implementacin y configuracin con los diagramas de despliegue.
1.1. MODELADO VISUAL
Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una
simplificacin de la realidad. El objetivo del modelado de un sistema es capturar las
partes esenciales del sistema. Para facilitar este modelado, se realiza una abstraccin
y se plasma en una notacin grfica. Esto se conoce como modelado visual.
El modelado visual permite manejar la complejidad de los sistemas a analizar o
disear. De la misma forma que para construir una choza no hace falta un modelo,
cuando se intenta construir un sistema complejo como un rascacielos, es necesario
abstraer la complejidad en modelos que el ser humano pueda entender.
UML sirve para el modelado completo de sistemas complejos, tanto en el diseo de
los sistemas software como para la arquitectura hardware donde se ejecuten.
Otro objetivo de este modelado visual es que sea independiente del lenguaje de

implementacin, de tal forma que los diseos realizados usando UML se pueda
implementar en cualquier lenguaje que soporte las posibilidades de UML
(principalmente
lenguajes
orientados
a
objetos).
UML es adems un mtodo formal de modelado. Esto aporta las siguientes
ventajas:

Mayor
rigor
en
la
especificacin.
Permite realizar una verificacin y validacin del modelo realizado.
Se pueden automatizar determinados procesos y permite generar cdigo a partir de
los modelos y a la inversa (a partir del cdigo fuente generar los modelos). Esto
permite que el modelo y el cdigo estn actualizados, con lo que siempre se puede
mantener la visin en el diseo, de ms alto nivel, de la estructura de un proyecto.
1.2. HISTORIA DE UML
El lenguaje UML comenz a gestarse en octubre de 1994 [1], cuando Rumbaugh se
uni a la compaa Rational fundada por Booch (dos reputados investigadores en el
rea de metodologa del software). El objetivo de ambos era unificar dos mtodos
que haban desarrollado: el mtodo Booch y el OMT (Object Mode-lling 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". Adems, este lenguaje se abri a la
colaboracin de otras empresas para que aportaran sus ideas. Todas estas
colaboraciones condujeron a la definicin de la primera versin de UML.
Esta primera versin se ofreci a un grupo de tra-bajo para convertirlo en 1997 en
un estndar del OMG (Object Management Grouphttp://www.omg.org). Este grupo,
que gestiona estndares relacionados con la tecnologa orientada a objetos
(metodologas, bases de datos objetuales, CORBA, etc.), propuso una serie de
modificaciones y una nueva versin de UML (la 1.1), que fue adoptada por el OMG
como estndar en noviembre de 1997. Desde aquella versin han habido varias
revisiones que gestiona la OMG Revision Task Force. La ltima versin aprobada es
la 1.4. En estos momentos se est desarrollando una nueva versin en la que se
incluirn cambios importantes (principalmente aadir nuevos diagramas) que
conducirn a la versin 2.0 planificada para fines del 2002.
1.3. Qu es UML?
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y
diagramas estndar para modelar sistemas orientados a objetos, y describe la

semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha

habido muchas notaciones y mtodos usados para el diseo orientado a objetos,
ahora los modeladores slo tienen que aprender una nica notacin.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software,
sistemas
de
hardware,
y
organizaciones
del
mundo
real.
UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y una reglas
para permitir una comunicacin. En este caso, este lenguaje se centra en la
representacin
grfica
de
un
sistema.
Este lenguaje nos indica cmo crear y leer los modelos, pero no dice cmo crearlos.
Esto ltimo es el objetivo de las metodologas de desarrollo.
Las objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
Visualizar: UML permite expresar de una forma grfica un sistema de forma que
otro
lo
puede
entender.
Especificar: UML permite especificar cules son las caractersticas de un sistema
antes
de
su
construccin.
Construir: A partir de los modelos especifica-dos se pueden construir los sistemas
diseados.
Documentar: Los propios elementos grficos sirven como documentacin del
sistema desarrollado que pueden servir para su futura re-visin.
Aunque UML est pensado para modelar sistemas complejos con gran cantidad de
software, el lenguaje es los suficientemente expresivo como para modelar sistemas
que no son informticos, como flujos de trabajo (workflow ) en una empresa, diseo
de la estructura de una organizacin y por supuesto, en el diseo de hardware.
Un modelo UML est compuesto por tres clases de bloques de construccin:
Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos,
acciones,
etc.)

Relaciones:
relacionan
los
elementos
entre
s.
Diagramas: Son colecciones de elementos con sus relaciones.
1.4. DIAGRAMAS UML
Un diagrama es la representacin grfica de un conjunto de elementos con sus
relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para
poder representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas UML ofrece nueve
diagramas
en
los
cuales
modelar
sistemas.
Diagramas de Casos de Uso para modelar los procesos 'business'.
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

 Diagramas de Colaboracin 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,
objetos
u
operaciones.
Diagramas de Clases para modelar la estructura esttica de las clases en el sistema.
Diagramas de Objetos para modelar la estructura esttica de los objetos en el
sistema.

Diagramas
de
Componentes
para
modelar
componentes.
Diagramas de Implementacin para modelar la distribucin del sistema.
Los diagramas ms interesantes (y los ms usados) son los de casos de uso, clases y
secuencia, por lo que nos centraremos en stos. Pare ello, se utilizar ejemplos de un
sistema
de
venta
de
entradas
de
cine
por
Internet.
El diagrama de casos de usos representa grficamente los casos de uso que tiene un
sistema. Se define un caso de uso como cada interaccin supuesta con el sistema a
desarrollar, donde se representan los requisitos funcionales. Es decir, se est
diciendo lo que tiene que hacer un sistema y cmo. En la figura 3 se muestra un
ejemplo de casos de uso, donde se muestran tres actores (los clientes, los taquilleros
y los jefes de taquilla) y las operaciones que pueden realizar (sus roles).
El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones.
ste es el diagrama ms comn a la hora de describir el diseo de los sistemas
orientados a objetos. En la figura 4 se muestran las clases globales, sus atributos y
las relaciones de una posible solucin al problema de la venta de entradas.
En el diagrama de secuencia se muestra la interaccin de los objetos que componen
un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 5
muestra la interaccin de crear una nueva sala para un espectculo.
El resto de diagramas muestran distintos aspectos del sistema a modelar. Para
modelar el comportamiento dinmico del sistema estn los deinteraccin,
colaboracin, estados y actividades. Los diagramas de componentes y
despliegue estn enfocados a la implementacin del sistema.

Figura 3: Diagrama de casos de uso

Figura 4: Diagrama de clases

Figura 5: Diagrama de secuencia.

1.5. UML ofrece notacin y semntica estndar
UML preescribe una notacin estndar y semnticas esenciales para el modelado de
un sistema orientado a objetos. Previamente, un diseo orientado a objetos podra
haber sido modelado con cualquiera de la docena de metodologas populares,
causando a los revisores tener que aprender las semnticas y notaciones de la
metodologa empleada antes que intentar entender el diseo en s. Ahora con UML,
diseadores diferentes modelando sistemas diferentes pueden sobradamente
entender cada uno los diseos de los otros.
1.6. UML no es un Mtodo
Aun as, UML no preescribe un proceso o mtodo estndar para desarrollar un
sistema. Hay varias metodologas existentes; entre las ms populares se incluyen las
siguientes:
Catalysis: Un mtodo orientado a objetos que fusiona mucho del trabajo reciente
en mtodos orientados a objetos, y adems ofrece tcnicas especficas para modelar
componentes
distribuidos.
Objetory: Un mtodo de Caso de Uso guiado para el desarrollo, creado por Ivar

Jacobson.
Shlaer/Mellor: El mtodo para disear sistemas de tiempo real, puesto en marcha
por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos,
modelando el Mundo en Estados y Ciclos de vida de Objetos, Modelando el mundo
en Datos (Prentice Hall). Shlaer/Mellor continan actualizando su mtodo
continuamente (la actualizacin ms reciente es el OOA96 report), y recientemente
publicaron una gua sobre cmo usar la notacin UML con Shlaer/Mellor.
Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer
intento de un mtodo de diseo orientado a objetos estndar. Combina OMT y
Booch
con
tarjetas
CRC
y
mtodos
formales.
(www.hpl.hp.com/fusion/file/teameps.pdf)
OMT: La Tcnica de Modelado de Objetos fue desarrollada por James Rumbaugh
y otros, y publicada en el libro de gran influencia "Diseo y Modelado Orientado a
Objetos" (Prentice Hall, 1991). Un mtodo que propone anlisis y diseo 'iterative',
ms
centrado
en
el
lado
del
anlisis.
Booch: Parecido al OMT, y tambin muy popular, la primera y segunda edicin de
"Diseo Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y
1994), (Object-Oriented Design, With Applications), detallan un mtodo ofreciendo
tambin diseo y anlisis 'iterative', centrndose en el lado del diseo.
Adems, muchas organizaciones han desarrollado sus propias metodologas internas,
usando diferentes diagramas y tcnicas con orgenes varios. Ejemplos son el mtodo
Catalyst por Computer Sciences Corporation (CSC) o el Worlwide Solution Design
and Delivery Method (WSDDM) por IBM. Estas metodologas difieren, pero
generalmente combinan anlisis de flujo de trabajo, captura de los requisitos, y
modelado de negocio con modelado de datos, con modelado de objetos usando
varias notaciones (OMT, Booch, etc), y algunas veces incluyendo tcnicas
adicionales de modelado de objetos como Casos de Uso y tarjetas CRC. La mayora
de estas organizaciones estn adoptando e incorporando el UML como la notacin
orientada
a
objetos
de
sus
metodologas.
Algunos modeladores usarn un subconjunto de UML para modelar 'what they're
after', por ejemplo simplemente el diagrama de clases, o solo los diagramas de clases
y
de
secuencia
con
Casos
de
Uso.
Otros usarn una suite ms completa, incluyendo los diagramas de estado y
actividad para modelar sistemas de tiempo real, y el diagrama de implementacin
para modelar sistemas distribuidos. Aun as, otros no estarn satisfechos con los
diagramas ofrecidos por UML, y necesitarn extender UML con otros diagramas
como modelos relacionales de datos y 'CRC cards'.

1.7. XML Schemas en UML extendido

Un XML Schema es un documento que define el contenido y la estructura de un tipo
de documento XML, es decir, describe los elementos y atributos que puede contener
un documento y la forma en la que se pueden definir dentro de una estructura
jerrquica
de
un
documento
vlido.
Dado que XML Schema no tiene su propia notacin grfica se ha decidido utilizar
UML. Sin embargo, este lenguaje no permite representar directamente estos
esquemas, con lo que ser necesario realizar una extensin al mismo.
UML ha sido diseado para que pueda extenderse de una forma controlada,
mediante sus propios mecanismos de extensin. Dichos mecanismos permiten crear
nuevos bloques de construccin por medio de estereotipos, valores etiquetados y
restricciones. Una extensin de UML debera contener : una breve descripcin, la
lista y descripcin de los estereotipos, valores etiquetados y restricciones, y un
conjunto de reglas que permitan determinar si un modelo est bien construido.
La Tabla 1 resume la propuesta de extensin de UML para la representacin de
XML Schemas.

Tabla 1. Extensin de UML para representacin grfica de XML Schemas

Icono: FRPSOH[7\SH

Icono: VLPSOH7\SH

Restricciones: Debe estar

Restricciones: Debe estar
relacionado por medio de una relacionado por medio de una
asociacin <<Compose>>
asociacin <<Compose>> con
con los elementos que
el elemento o atributo que lo
forman el tipo complejo.
usa.
Valores Etiquetados: Ninguno Valores Etiquetados: Tipo base,
Restricciones propias del tipo
base.

Asociacin Compose

Asociacin BelongTo

Clase del Metamodelo:

Clase del Metamodelo:
Asociacin
Asociacin
Descripcin: Una asociacin Descripcin: Una asociacin
<<Compose>> es un tipo
<<BelongTo>> es un tipo
especial de asociacin
especial de asociacin
unidireccional que enlaza una unidireccional que enlaza una
clase <<ELEMENT>> con la clase <<ELEMENT>> con la
clase referenciada por un
clase que
atributo IDREF/IDREFS o un
representa a su elemento padre.
tipo simple o complejo que lo La parte de la asociacin con el
sea utilizado por el
rombo representa el elemento
<<ELEMENT>>. Si el atributo padre. En el extremo opuesto
es de tipo IDREFS, la flecha
pueden aparece el mnimo
estar rellena.
nmero y/o mximo de
Si se trata de un atributo
ocurrencias Un nmero mximo
IDREF, la flecha estar sin
de ocurrencias ilimitado se
rellenar. La direccin de la
representar mediante una N.
asociacin se representar
Icono: Ninguno
con la flecha al final de la
Restricciones: Slo se puede
clase, que se referencia por usar para unir dos
el tipo ELEMENT.
<<ELEMENTS>>, siendo uno el
Icono: Ninguno
padre del otro.
Restricciones: Slo se puede Valores Etiquetados: Ninguno
usar para unir dos tipos
<<ELEMENT>>, uno de los
cuales debe tener un atributo
cuyo tipo sea IDREF/S, que
haga referencia a otro tipo
ELEMENT.
Valores Etiquetados: Ninguno

Reglas que ha de cumplir un diseo bien

formado

Cada tipo <<ELEMENT>> tiene que estar enlazado con una

asociacin de <<Compose>> o
<<BelongTo>> con otro <<ELEMENT>>, <<complexType>>
o <<simpleType>>.
Un atributo de tipo <<IDREF>> o <<IDREFS>> en un
<<ELEMENT>> implica una asociacin de
<<Compose>> con otro <<ELEMENT>>. Un <<ELEMENT>>
puede contener una coleccin de atributos.

Se ha presentado una extensin a UML para representar un esquema en XML

Schema. Esta propuesta se enmarca dentro de MIDAS/DB, una metodologa para la
creacin de bases de datos Web que propone utilizar UML como notacin nica para
la definicin de todo el sistema. Existen diferentes extensiones a UML para distintas
tcnicas de modelado Web, sin embargo, no son suficientes para representar todas
las
tcnicas
que
se
proponen
en
MIDAS/DB.
Para validar la extensin propuesta se han desarrollado distintos casos de prueba.
Adems tambin se est realizando la implementacin de una extensin a Rational
Rose, que permitir la representacin en notacin grfica en UML de todo el sistema
en todas las etapas de desarrollo de MIDAS/DB, as como la transformacin
semiautomtica entre las distintas etapas. Actualmente, se est trabajando en la
definicin de otras extensiones a UML necesarias para poder respresentar todo el
sistema con una nica notacin, y de guas de transformacin para pasar de una
etapa a la siguiente de forma sistemtica.

Una perspectiva general de UML

2.1. Una vuelta por un caso de uso
Una vez ms, UML es una notacin, no un mtodo. 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 aproximacin al diseo 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.
La Figura 1 muestra un flujo general de cmo los diagramas de UML, con
extensiones, interactuan en una aproximacin al diseo con los casos de uso.
2.2. Casos de Uso y Diagramas de Interaccin

Un caso de uso se modela para todos los procesos que el sistema debe llevar a cabo.
Los procesos se describen dentro de el caso de uso por una descripcin textual o una
secuencia de pasos ejecutados. Los Diagramas de Actividad se pueden usar tambin
para modelar escenarios grficamente. Una vez que el comportamiento del sistema
est captado de esta manera, los casos de uso se examinan y amplian para mostrar
qu objetos se interrelacionan para que ocurra este comportamiento. Los Diagramas
de Colaboracin y de Secuencia se usan para mostrar las relaciones entre los objetos.
2.3. Clases y Diagramas de Implementacin
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 anlisis del diseo orientado a objetos, y el que muestra la
estructura esttica del sistema. El diagrama de clase puede ser dividido en capas:
aplicacin, y datos, las cuales muestran las clases que intervienen con la interfaz de
usuario, la lgica del software de la aplicacin, y el almacenamiento de datos
respectivamente. Los Diagramas de Componentes se usan para agrupar clases en
componentes o mdulos. La distribucin general del hardware del sistema se modela
usando el Diagrama de Implementacin.
2.4. Tarjetas CRC (CRC cards) - Una extensin informal de UML
Como una extensin informal a UML, la tcnica de las tarjetas CRC se puede usar
para guiar el sistema a travs de anlisis guiados por la responsabilidad. Las clases
se examinan, se filtran y se refinan en base a sus responsabilidades con respecto al
sistema, y las clases con las que necesitan colaborar para completar sus
responsabilidades.
2.5. Diagramas de Estado
El comportamiento en tiempo real de cada clase que tiene comportamiento dinmico
y significativo, se modela usando un Diagrama de Estado. El diagrama de actividad
puede ser usado tambin aqu, esta vez como una extensin del diagrama de estado,
para mostrar los detalles de las acciones llevadas a cabo por los objetos en respuesta
a eventos internos. El diagrama de actividad se puede usar tambin para representar
grficamente las acciones de mtodos de clases.

Figura 1: Aproximacin a un caso de uso guiado para el desarrollo orientado a

objetos con UML, incluyendo las extensiones de tarjetas CRC y extensiones de
modelado de datos.

2.6. Implementando el diseo

La implementacin del sistema trata de traducir informacin desde mltiples
modelos
UML
en
cdigo
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 aplicacin (incluyendo los objetos de implementacin), y su
capa de datos (incluyendo la estructura de la base de datos y el acceso a objetos).
2.7. Implementando la aplicacin
El Diagrama de Clase se usa para generar una estructura base del cdigo en el
lenguaje
escogido.
Informacin de los diagramas de interaccin, estado, y actividad, puede ofrecer
detalles de la parte procedimental del cdigo de implementacin.
2.8. Implementando el diseo de Bases de Datos
La capa de datos del diagrama de clase se puede usar para implementar directamente
un diseo orientado a objetos de una base de datos, o, como extensin de UML,
puede ser referenciado en un diagrama de relacin de entidad para ms anlisis de
relaciones de entidad. Est en el diagrama de relacin de entidad (ER diagram,
entity relationship) el cual relaciona entre entidades que pueden ser modeladas
basadas en atributos clave. El diagrama de relacin de entidad lgico ofrece una
base desde la cual construir un diagrama fsico representando las tablas y relaciones
actuales de la base de datos relacional.
2.9. Probar teniendo en cuenta los requisitos
Los casos de uso se utilizan tambin 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.

Un estudio a fondo de UML

Las siguientes secciones presentan una vista ms detallada al modelado con UML.
Un sistema de reserva de aerolneas simple se va a usar para mostrar los diagramas y
tcnicas de modelado con UML. Se cubren los siguientes puntos:

Organizando
tu
sistema
con
paquetes

 Modelando con Casos de Uso, y usndolos para averiguar los requisitos del
sistema

Modelando
con
Diagramas
de
Secuencia
y
Colaboracin
Analizando y diseando con el Diagrama de Clase, y extendiendo UML con la
tcnica
de
las
tarjetas
CRC
Modelando comportamiento con Diagramas de Actividad y de Estado
Modelando componentes de software, distribucin e implementacin
Extendiendo UML con el diseo de Bases de Datos relacionales
Una de las tareas clave para modelar un sistema de sofware de grandes dimensiones
es dividirlo primero en reas manejables. Aunque estas reas se llaman dominios,
categoras o subsistemas, la idea es la misma: dividir el sistema en reas que tengan
competencias
parecidas.
UML introduce la nocin de un paquete como el tem universal para agrupar
elementos, permitiendo a los modeladores subdividir y categorizar sistemas. Los
paquetes pueden ser usados en cualquier nivel, desde el nivel ms alto, donde son
usados para subdividir el sistema en dominios, hasta el nivel ms bajo, donde son
usados para agrupar casos de uso individuales, clases, o componentes.

3.1. Modelado de Casos de Uso

El modelado de Casos de Uso es la tcnica ms efectiva y a la vez la ms simple

para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos
de Uso se utilizan para modelar cmo un sistema o negocio funciona actualmente, o
cmo los usuarios desean que funcione. No es realmente una aproximacin a la
orientacin a objetos; es realmente una forma de modelar procesos. Es, sin embargo,
una manera muy buena de dirigirse hacia el anlisis de sistemas orientado a objetos.
Los casos de uso son generalmente el punto de partida del anlisis orientado a
objetos
con
UML.
El modelo de casos de uso consiste en actores y casos de uso. Los actores
representan usuarios y otros sistemas que interaccionan con el sistema. Se dibujan
como "muecos" de palo. Actualmente representan el tipo de usuario, no una
instancia de usuario. Los casos de uso representan el comportamiento del sistema,
los escenarios que el sistema atraviesa en respuesta a un estmulo desde un actor. Se
dibujan como elipses.

Figura 3: Modelado de Casos de Uso.

Cada caso de uso se documenta por una descripcin del escenario. La descripcin
puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso
puede ser tambin definido por otras propiedades, como las condiciones pre- y postdel escenario --- condiciones que existen antes de que el escenario comience, y
condiciones que existen despus de que el escenario se completa. Los Diagramas de
Actividad ofrecen una herramienta grfica para modelar el proceso de un Caso de
Uso. stos son descritos en una seccin posterior de este documento.

3.1.1. Estudiar y descubrir los requisitos

El objetivo final en cualquier diseo de software es satisfacer los requisitos del
usuario
para
el
sistema.
Estos requisitos pueden ser requisitos de software, requisitos de productos, o
requisitos de pruebas. La meta de capturar y comprobar los requisitos del usuario es
asegurar que todos los requisitos son completados por el diseo, y que el diseo es
acorde
con
los
requisitos
especificados.
Muchas veces los requisitos del sistema ya existen en forma de documentos de
requisitos. Los casos de uso se utilizan para correlacionar cada escenario con los
requisitos que completa. Si los requisitos no existen, modelar el sistema a travs de
los Casos de Uso, permite el descubrimiento de estos requisitos.
3.1.2. Organizacin de Diagramas de Casos de Uso
Durante el anlisis de negocio (business) del sistema, puedes desarrollar un modelo
de caso de uso para este sistema, y construir paquetes para representar los varios
dominios
de
negocio
(business)
del
sistema.
Puedes descomponer cada paquete con un Diagrama de Caso de Uso que contenga
los Casos de Uso de un dominio, con interacciones de actor.
3.1.3. Un Caso de Uso para cada escenario
El objetivo es construir un Diagrama de Caso de Uso para cada tipo de escenario
diferente en el sistema. Cada escenario muestra una secuencia diferente de
interacciones entre actores y el sistema, sin condiciones 'or'.
3.1.4. Modelar secuencias alternas a travs de la relacin "Extiende" (extends)
Tpicamente, uno modela cada Caso de Uso con una secuencia normal de acciones.
El usuario entonces considera condiciones "que si" para cada paso, y desarrolla
Casos de Uso basados en estas secuencias alternas de eventos. Las secuencias
alternas se modelan en casos de uso separados, los cuales estn relacionados con el
caso de uso original mediante una relacin "Extiende" (extends). Las relaciones
Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia,
en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso
de
uso
original.
En UML la relacin de extensin es un elemento especial de modelado, por lo tanto
la relacin aparece explcitamente en las siguientes definiciones.

Definicin
4:
Extensin
de
Casos
de
Uso
Un Caso de Uso UC es la extensin de UC1 por UC2 a travs de una relacin
"extend" ext; es decir, UC = UC1 ext UC2 si se cumple:
a- Aplicabilidad: El Caso de Uso UC1 es extendible por ext si se cumple la
siguiente
condicin:
Para cada punto de extensin de ext debe existir una accin que coincida con l
dentro
de
las
secuencias
de
acciones
del
Caso
de
Uso:
i OE ext. extensionPoint. $uo OE UC1.operation . $uotOE uo.actionSequence .
i.location
OE
uot
b- UC1-Completitud: cada secuencia de acciones en UC1 es extendida en todas las
formas
posibles:

o1
OE
UC1.operation
.
$o
OE
UC.operation
.
( o.name=o1.name ("s1OEo1.actionSequence. extensions(s1,ext,UC2)
o.actionSequence
)
)
c- UC1-Correccin: cada secuencia de acciones en UC es una extensin de alguna
secuencia
de
acciones
en
UC1.
oOEUC.operation .$o1OE UC1.operation . (o.name=o1.name (
sOEo.actionSequence.
$s1OEo1.actionSequence.
sOEextensions(s1,ext,UC2)
)
)
Definicin
5:
isExtensible:
ActionSequence
x
Extend
El predicado es verdadero si la secuencia de acciones contiene algn punto de
extensin de la relacin extend y est definido de la siguiente forma:

s:ActionSequence

ext:Extend
.
isExtensible(s,ext)

$
iOEext.extensionPoint
.
i.locationOEs
Definicin
6:
extensions: ActionSequence x Extend x UseCase -> Set(ActionSequence)
La funcin extensions(s,ext,uc) retorna el conjunto de todas las posibles extensiones
de la secuencias dadas por la relacin ext y el Caso de Uso uc. La funcin se define
por
casos
de
la
siguiente
forma:
Case
1:

isExtensible(s,ext)
extensions(s,ext,uc)={s}
Case
2:
isExtensible(s,ext)
extensions(s,ext,uc)={before(s,i.location);
s2;
after(s,
i.location)
/
iOEext.extensionPoint

i.locationOEs

s2OEuc.actionSequence
}
Definicin 7: UC extiende a UC1 si existe un Caso de Uso UC2 tal que UC es la
extensin de UC1 por UC2 a travs de una relacin ext:
UC extendsext UC1 $ UC2:UseCase . ( UC = UC1 ext UC2 )

3.1.5. Eliminar el modelado redundante a travs de la relacin "Incluir" (Include)

Para eliminar el modelado redundante de buena parte del comportamiento que
aparezca en varios casos de uso, la parte del comportamiento puede ser modelada en
un caso de uso separado que est relacionado con los otros casos de uso mediante la
relacin "Incluir" (Include). La relacin Incluir (Include) se puede pensar como un
caso
de
uso
equivalente
'of
aggregation'.
La
relacin
Include
Una relacin include entre dos Casos de Uso indica que el comportamiento definido
en el Caso de Uso a adicionar, es includo en un lugar dentro de la secuencia del
comportamiento realizado por una instancia del Caso de Uso base. Cuando una
instancia del Caso de Uso llega al lugar donde el comportamiento de otro Caso de
Uso debe ser includo, ejecuta todo el comportamiento descripto por el Caso de Uso
includo y luego contina de acuerdo a su Caso de Uso original. El Caso de Uso
includo no depende del Caso de Uso base. En este sentido, el Caso de Uso includo
representa comportamiento encapsulado que puede ser reusado en varios Casos de
Uso.
Definicin
1:
Inclusin
de
Casos
de
Uso
Un Caso de Uso UC es el resultado de incluir UC2 dentro de UC1; es decir UC =
UC1
inc
UC2
si
se
cumple
lo
siguiente:
a- Aplicabilidad: dentro de UC1 existe una llamada a UC2
$oOE
UC1.operation
.
$utOE
o.actionSequence
.
UC2.nameOEut
b- Completitud: UC contiene todas las posibles formas de incluir UC2 dentro de
UC1
o1OEUC1.operation . $oOE UC.operation . (o.name=o1.name (
s1OEo1.actionSequence.
inclusions(s1,UC2)

o.actionSequence
)
)
c- Correccin: todas las secuencias de acciones de UC provienen de incluir a UC2
dentro
de
alguna
secuencia
de
acciones
de
UC1.
oOEUC.operation . $o1OE UC1.operation . (o.name=o1.name (
sOEo.actionSequence.
$s1OEo1.actionSequence.
sOEinclusions(s1,UC2)
)
)
Definicin
2:
isIncluible:
ActionSequence
x
UseCase
El predicado isIncluible(s,uc) es verdadero si la secuencia de acciones s contiene
alguna invocacin al Caso de Uso uc y est definido de la siguiente forma:
s:ActionSequence uc:UseCase . isIncluible(s,uc) uc.name OEs
Definicin
3:

inclusions:
ActionSequence
x
UseCase
->
Set(ActionSequence)
La funcin inclusions(s, uc) retorna el conjunto de todas las posibles inclusiones del
Caso de Uso uc en la secuencia s y esta definida por casos, de la siguiente forma.
Case
1:

isIncluible(s,
uc)
inclusions(s,
uc)={s}
Case 2: isIncluible(s, uc) inclusions(s, uc)={ before(s,a);s2;after(s,a) / a=uc.name
s2OEuc.actionSequence }

Figura 4: Relacin caso de uso Extiende (extends) frente a relacin de caso Usa
(uses=Include).
3.1.6. Ayuda en casos de uso probando el sistema frente a los requisitos
Los Casos de Uso tambin se utilizan para construir scripts de prueba que se usan a
su vez para comprobar que la aplicacin satisface los requisitos de negocio y de
sistema.
Cuando has llegado al caso de uso del nivel ms bajo, podras crear un Diagrama de
Secuencia para el Caso de Uso. Con los Diagramas de Secuencia y de Colaboracin
puedes modelar la implementacin del escenario.

3.2. Diagramas de Secuencia

El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar
interaccin 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
implementacin del escenario, incluyendo los objetos y clases que se usan para
implementar el escenario, y mensajes pasados entre los objetos.
Tpicamente uno examina la descripcin de un caso de uso para determinar qu
objetos son necesarios para la implementacin del escenario. Si tienes modelada la
descripcin 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
lneas discontinuas verticales, y los mensajes pasados entre los objetos como
vectores horizontales. Los mensajes se dibujan cronolgicamente desde la parte
superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es
arbitraria.

3.3. Diagramas de Colaboracin

El Diagrama de Colaboracin presenta una alternativa al diagrama de secuencia para

modelar interacciones entre objetos en el sistema. Mientras que el diagrama de
secuencia se centra en la secuencia cronolgica del escenario que estamos
modelando, el diagrama de colaboracin se centra en estudiar todos los efectos de un
objeto dado durante un escenario. Los objetos se conectan por medio de enlaces,
cada enlace representa una instancia de una asociacin entre las clases implicadas.
El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje
(sincrnico, asincrnico, simple, blanking, y 'time-out'), y la visibilidad de un objeto
con respecto a los otros.

Figura 6:Diagrama de Colaboracin para un grupo de Objetos

3.4. Anlisis y Diseo con el Diagrama de Clase
El Diagrama de Clase es el el diagrama principal de diseo y anlisis para un
sistema. En l, la estructura de clases del sistema se especifica, con relaciones entre
clases y estructuras de herencia. Durante el anlisis del sistema, el diagrama se
desarrolla buscando una solucin ideal. Durante el diseo, se usa el mismo
diagrama, y se modifica para satisfacer los detalles de las implementaciones.
3.4.1. Desarrollo de Diagramas de Clase durante el anlisis
3.4.1.1. Aproximacin a un Caso de Uso guiado
En una aproximacin a un Caso de Uso guiado hacia el anlisis orientado a objetos,
el diagrama de clases se desarrolla a travs de informacin obtenida en los Casos de
Uso, Diagramas de Secuencia y Diagramas de Colaboracin. Los objetos
encontrados durante el anlisis son modelados en trminos de la clase a la que
instancian, y las interacciones entre objetos son referenciados a relaciones entre las
clases instanciadas.

Figura 7: Diagrama de Clase durante la fase de anlisis

3.4.1.2. Extensin guiada por la responsabilidad
La tcnica de la tarjeta CRC se usa a veces como una extensin a UML para anlisis
guiados por la responsabilidad. Las definiciones de clase son refinadas basndose en
las responsabilidades de clase y en otras clases con las que colabora para completar
sus
responsabilidades.
Cada clase se representa en una tarjeta ndice (index card), y los diseadores
establecen los papeles (roles) de las clases en el sistema para definir su trabajo, y
con qu otras necesitan colaborar para completar sus responsabilidades. Esta
informacin se pasa directamente a un diagrama de clase; las responsabilidades
coinciden con los mtodos de clase, las colaboraciones se traducen en asociaciones
entre clases.

Figura 8: Extensin informal de UML -- Tarjetas CRC para anlisis guiados por la
responsabilidad.
3.4.2. Diseo del sistema con Diagramas de Clase
Durante el diseo, el Diagrama de Clase se elabora para tener en cuenta los detalles
concretos de la implementacin del sistema.
3.4.2.1. Arquitecturas Multicapas
Una vez concienciados del diseo, estableceremos la arquitectura del sistema. Esto
incluye establecer si ser un sistema simple diseado para correr en una sola
mquina, un sistema 'two-tiered' consistente en un cliente y un servidor, o un sistema
'multi-tiered' con objetos interfaz de usuario separados de los objetos 'business',
separado de la base de datos, cada uno corriendo en plataformas distintas.
Una aproximacin a dirigir el diagrama de clase para un sistema complejo es separar

el diagrama en secciones que muestren la lgica de la aplicacin, el diseo de la

interfaz de usuario, y las clases implicadas con el almacenamiento de los datos. Esto
se puede hacer fsicamente segmentando el diagrama de clase, usando diagramas
separados para cada seccin, o simplemente aadiendo una propiedad a cada clase
que 'tracks' cada 'tier' al cual pertenece.
3.4.2.2. Diseo de Componentes
Un componente es un grupo de objetos o componentes ms pequeos que
interaccionan entre ellos y se combinan para dar un servicio. Un componente es
similar a una caja negra, en la cual los servicios del componente se especifican por
su interface o interfaces, sin ofrecer conocimiento del diseo e implementacin
internas del componente. El desarrollo basado en componentes es el proceso de
ensamblar la combinacin correcta de componentes en la configuracin correcta
para llevar acabo la funcionalidad deseada para un sistema. Los componenetes se
representan en el diagrama de clases de UML especificando la interfaz de una clase
o paquete. Hay dos notaciones para mostrar una interfaz - una es mostrar la interfaz
como una 'regular class symbol' con el estereotipo "interfz", con una lista de
operaciones soportadas por esta interfaz, detalladas en el 'operation department'
(departamento de operacin). 'The alternate, shortcut notation' es mostrar la interfaz
como un circulo pequeo junto con la clase con una lnea slida, con el nombre de la
interfaz
en
el
crculo.
El ejemplo de la Figura 9 muestra que la clase 'Pasajero' ofrece la operacin move(x
coord, y coord) para su apariencia en un GUI, a travs de su interfaz 'Displayable'.
Ambas notaciones UML de interfaz, se muestran en la figura. Adems, la clase
Pasajero tambin ofrece una opcin save(store at) a travs de su interfaz Persistente.
Una clase de o componente para conectar con una base de datos podra usar esta
interfaz.

Figura 9: Diseo de Componentes: Especificando la Interfaz de la Clase

3.4.2.3. Anlisis y diseo 'Iterative'
El diagrama de clase se puede desarrollar en una 'iterative fashion', a travs de un
ciclo repetido de anlisis, diseo e implementacin, y despus vuelta al anlisis, para
empezar el ciclo de nuevo. Este proceso se suele llamar 'round-trip engineering'. El
modelado de herramientas como System Architect 2001 puede facilitar este proceso
permitindote implementar el diseo en un lenguaje como C++ o Java, y despus
traer de vuelta al cdigo a al diagrama de clase, automticamente actualizando la
informacin contenida en el diagrama y en el 'underlying repository'.

Figura 10: Anlisis, diseo y documentacin 'Iterative' con el Diagrama de Clase

3.5. Modelando el comportamiento de las Clases con Diagramas de Estado
Mientras los diagramas de interaccin y colaboracin modelan secuencias dinmicas
de accin entre grupos de objetos en un sistema, el diagrama de estado se usa para
modelar el comportamiento dinmico de un objeto en particular, o de una clase de
objetos.
Un diagrama de estado se modela para todas las clases que se consideran con un
comportamiento dinmico. En l, modelas la secuencia de estado que un objeto de la
clase atraviesa durante su vida en respuesta a los estmulos recibidos, junto con sus
propias
respuestas
y
acciones.
Por ejemplo, un comportamiento de un objeto se modela en trminos de en qu
estado est inicialmente, y a qu estado cambia cuando recibe un evento en
particular. Tambin modelas qu acciones realiza un objeto en un estado en
concreto.
Los estados representan las condiciones de objetos en ciertos puntos en el tiempo.
Los eventos representan incidentes que hacen que los objetos pasen de un estado a
otro. Las lneas de transicin describen el movimiento desde un estado hasta otro.
Cada lnea de transicin se nombre con el evento que causa esta transicin. Las
acciones ocurren cuando un objeto llega a un estado.

Figura 11: Modelando Comportamiento Dinmico de un objeto 'Vuelo' con un

diagrama de estado
3.6. Diagramas de Actividad
El Diagrama de Actividad es un diagrama de flujo del proceso multi-propsito que
se usa para modelar el comportamiento del sistema. Los diagramas de actividad se
pueden usar para modelar un Caso de Uso, o una clase, o un mtodo complicado.
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es
que los diagramas de actividad pueden mostrar procesado paralelo (parallel
processing). Esto es importante cuando se usan diagramas de actividad para modelar
procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar
varios hilos en los programas concurrentes.
3.6.1. Usando Diagramas de Actividad para modelar Casos de Uso
Los Diagramas de Actividad ofrecen una herramienta grfica para modelar el
proceso de un Caso de Uso. Se pueden usar como un aadido a una descripcin
textual del caso de uso, o para listar los pasos del caso de uso. Una descripcin
textual, cdigo, u otros diagramas de actividad pueden detallar ms la actividad.

3.6.2. Usando Diagramas de Actividad para modelar Clases

Cuando se modela el comportamiento de una clase, un diagrama de estado de UML
se suel usar normalmente para modelar situaciones donde ocurren eventos
asincrnicos. El diagrama de actividad se usa conado todos o la mayora de los
elementos representan el desarrollo de los pasos dados por las acciones generadas
internamente. Deberas asignar actividades a las clases antes de terminar con el
diagrama de actividad.

Figura 12: Diagrama de Actividad

3.7. Modelando Componentes de Software
El Diagrama de Componentes se usa para modelar la estructura del software,
incluyendo las dependencias entre los componentes de software, los componentes de

cdigo binario, y los componentes ejecutables. En el Diagrama de Componentes

modelas componentes del sistema, a veces agrupados por paquetes, y las
dependencias que existen entre componentes (y paquetes de componentes).

Figura 13: Modelando componentes con el Diagrama de Componentes

3.8. Modelando la Distribucin y la Implementacin
Los Diagramas de Implementacin se usan para modelar la configuracin de los
elementos de procesado en tiempo de ejecucin (run-time processing elements) y de
los componentes, procesos y objetos de software que viven en ellos. En el diagrama
'deployment', empiezas modelando nodos fsicos y las asociaciones de comunicacin
que existen entre ellos. Para cada nodo, puedes indicar qu instancias de
componentes viven o corren (se ejecutan) en el nodo. Tambin puedes modelar los
objetos
que
contiene
el
componente.
Los Diagramas de Implementacin se usan para modelar slo componentes que
existen como entidades en tiempo de ejecucin; no se usan para modelar
componentes solo de tiempo de compilacin o de tiempo de enlazado. Puedes
tambin modelar componentes que migran de nodo a nodo u objetos que migran de
componente a componente usando una relacin de dependencia con el estereotipo
'becomes' (se transforma)

Figura 14: Modelando la Distribucin del Sistema con el Diagrama de

Implementacin
3.9. Diseo de Bases de Datos Relacionales -- Una extensin informal de UML
El Diagrama de Clase presenta un mecanismo de implementacin neutral para
modelar los aspectos de almacenado de datos del sistema. Las clases persistentes,
sus atributos, y sus relaciones pueden ser implementadas directamente en una base
de datos orientada a objetos. Aun as, en el entorno de desarrollo actual, la base de
datos relacional es el mtodo ms usado para el almacenamiento de datos.
Es en el modelado de este rea donde UML se queda corto. El diagrama de clase de
UML se puede usar para modelar algunos aspectos del diseo de bases de datos
relacionales, pero no cubre toda la semntica involucrada en el modelado relacional,
mayoritariamente la nocin de atributos clave que relacionan entre s las tablas unas
con otras. Para capturar esta informacin, un Diagrama de Relacin de Entidad (ER
diagram)
se
recomienda
como
extensin
a
UML.
El Diagrama de Clase se puede usar para modelar el estructura lgica de la base de
datos, independientemente de si es orientada a objetos o relacional, con clases
representando tablas, y atributos de clase representando columnas. Si una base de
datos relacional es el mtodo de implementacin escogido, entonces el diagrama de
clase puede ser referenciados a un diagrama de relacin de entidad lgico. Las clases
persistentes y sus atributos hacen referencia directamente a las entidades lgicas y a
sus atributos; el modelador dispone de varias opciones sobre cmo inferir
asociaciones en relaciones entre entidades. Las relaciones de herencia son

referenciadas directamente a super-sub relaciones entre entidades en un diagrama de

relacin de entidad (ER diagram).

Figura 15: Extensin de UML -- Diseo de Bases de Datos Relacionales con el

Diagrama de Relacin de Entidad (ER Diagram)
Ya en el Diagrama de Relacin de Entidad, el modelador puede empezar el proceso
de determinar cmo el modelo relacional encaja; y qu atributos son claves
primarias, claves secundarias, y claves externas basadas en relaciones con otras
entidades. La idea es constriur un modelo lgico que sea conforme a las reglas de
normalizacin
de
datos.
Al implementar el diseo relacional, es una estrategia encaminada a hacer referencia
al diagrama de relacin de entidad lgico a un diagrama fsico que represente el
objetivo, el RDBMS. El diagrama fsico puede ser denormalizado para lograr un
diseo de base de datos que tiene tiempos eficientes de acceso a los datos. Las
relaciones supersub entre entidades se resuelven por las estructuras de tablas
actuales.
Adems, el diagrama fsico se usa para modelar propiedades especficas de cada
fabricante para el RDBMS. Se crean varios diagramas fsicos si hay varios RDBMSs
siendo 'deployed'; cada diagrama fsco representa uno de los RDBMS que son
nuestro objetivo.

Figura 16: Relaciones clave entre entidades en un Diagrama de Relacin de Entidad

Uso de una herramienta de modelado

El intercambio de informacin de diseo e ideas usando la notacin UML sera
hecho en los medios que siempre han sido populares: pizarras, cuadernos y trozos de
papel por nombrar algunos. Pero UML se sirve mejor por una herramienta de
modelado, la cual puede ser usada para capturar, guardar, rechazar, integrar
automticamente
informacin,
y
diseo
de
documentacin.
Una caracterstica que beneficia a los modeladores, UML tambin hace ms fcil
escoger una herramienta de modelado. Hace tiempo, el modelador primero tena que
seleccionar una notacin de metodologa, y despus estaba limitado a seleccionar
una herramienta que la soportara. Ahora con UML como estndar, la eleccin de
notacin ya se ha hecho para el modelador. Y con todas las herramientas de
modelado soportando UML, el modelador puede seleccionar la herramienta basada
en las reas claves de funcionalidad soportadas que permiten resolver los problemas
y
documentar
las
soluciones.
Como una buena caja de herramientas, una buena herramienta de modelado ofrece

todas las herramientas necesarias para conseguir hacer eficientemente varios

trabajos, sin dejarte nunca sin la herramienta correcta. Dentro de la estructura de
diseo de sistemas descrito en esta gua, esto incluye lo siguiente:

Soporte
para
toda
la
notacin
y
semntica
de
UML
Soporte para una cantidad considerable de tcnicas de modelado y diagramas para
complementar UML - incluyendo tarjetas CRC, modelado de datos, diagramas de
flujo, y diseo de pantallas de usuario. Posibilidad de reutilizar informacin
obtenida por otras tnicas todava usadas, como modelado tradicional de procesos.
Facilitar la captura de informacin en un repositorio subyacente - permitiendo la
reutilizacin
entre
diagramas.
Posibilidad de personalizar las propiedades de definicin de elementos subyacentes
de
modelos
UML.
Permitir a varios equipos de analistas trabajar en los mismos datos a la vez.
Posibilidad de capturar los requisitos, asociarlos con elementos de modelado que
los satisfagan y localizar cmo han sido satisfechos los requisitos en cada uno de los
pasos
del
desarrollo.
Posibilitar la creacin de informes y documentacin personalizados en tus diseos,
y la salida de estos informes en varios formatos, incluyenod HTML para la
distribucin
en
la
Internet
o
Intranet
local.
Posibilidad para generar y 'reverse' cdigo (por ejemplo C++, Java, etc) para
facilitar el anlisis y diseo 'iterative', para volver a usar cdigo o libreras de clase
existentes, y para documentar el cdigo.

Proceso de desarrollo
Aunque UML es bastante independiente del pro-ceso de desarrollo que se siga, los
mismos creadores de UML han propuesto su propia metodologa de desarrollo,
denominada
el
Proceso
Unificado
de
Desarrollo.
El Proceso Unificado est basado en componentes, lo cual quiere decir que el
sistema software en construccin est formado por componentes software
interconectados a travs de interfaces bien definidos. Adems, el Proceso Unificado
utiliza el UML para expresar grficamente todos los esquemas de un sistema
software. Pero, realmente, los aspectos que definen este Proceso Unificado son tres:
es iterativo e incremental, dirigido por casos de uso y centrado en la arquitectura :
Dirigido por casos de uso: Basndose en los casos de uso, los desarrolladores crean
una serie de modelos de diseo e implementacin que los llevan a cabo. Adems,
estos modelos se vali-dan para que sean conformes a los casos de uso. Finalmente,
los casos de uso tambin sir-ven para realizar las pruebas sobre los componentes

desarrollados.
Centrado en la arquitectura: En la arquitectura de la construccin, antes de
construir un edificio ste se contempla desde varios puntos de vista: estructura,
conducciones elctricas, fontanera, etc. Cada uno de estos aspectos est
representado por un grfico con su notacin correspondiente. Siguiendo este
ejemplo, el concepto de arquitectura software incluye los aspectos estticos y
dinmicos
ms
significativos
del
sistema.
Iterativo e incremental: Todo sistema informtico complejo supone un gran
esfuerzo que puede durar desde varios meses hasta aos. Por lo tanto, lo ms
prctico es dividir un proyecto en varias fases. Actualmente se suele hablar de ciclos
de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido
por las fases se denomina iteracin en el proyecto en la que se realizan varios tipos
de trabajo (denominados flujos). Adems, cada iteracin parte de la anterior
incrementado o revisando la funcionalidad implementada. Se suele denominar
proceso. Ver figura 17

Figura 17: Proceso iterativo e incremental

Resumiendo, el Proceso Unificado es un modelo complejo con mucha terminologa

propia, pensado principalmente para el desarrollo de grandes proyectos. Es un
proceso que puede adaptarse y extenderse en funcin de las necesidades de cada
empresa.

Conclusiones
Es fcil predecir que UML ser el lenguaje de modelado de software de uso
universal.
Las
principales
razones
para
ello
son:
En el desarrollo han participado investigadores de reconocido prestigio.
Ha sido apoyado por prcticamente todas las empresas importantes de informtica.

Se
ha
aceptado
como
un
estndar
por
la
OMG.
Prcticamente todas las herramientas CASE y de desarrollo la han adaptado como
lenguaje
de
modelado.
En resumen, UML resuelve de forma bastante satisfactoria un viejo problema del
desarrollo de software como es su modelado grfico. Adems, se ha llega-do a una
solucin unificada basada en lo mejor que haba hasta el momento, lo cual lo hace
todava ms excepcional.