Herramientas Case

Indice
1. Introduccin
2. Definicin de herramientas case
3. Historia
4. Qu es la tecnologa case?
5. Componentes de una herramienta case
6. Estructura general de una herramienta case
7. Estado actual
8. Integracin de las herramientas case en el futuro
9. Clasificacin de las herramientas case
10. Caractersticas deseables de una herramienta case
11. Implantacin de las herramientas case
12. Conclusin
13. Bibliografa
1. Introduccin
Hoy en da, muchas empresas se han extendido a la adquisicin de herramientas CASE
(Ingeniera Asistida por Computadora), con el fin de automatizar los aspectos clave de todo el
proceso de desarrollo de un sistema, desde el principio hasta el final e incrementar su posicin
en el mercado competitivo, pero obteniendo algunas veces elevados costos en la adquisicin
de la herramienta y costos de entrenamiento de personal as como la falta de adaptacin de la
herramienta a la arquitectura de la informacin y a las metodologas de desarrollo utilizadas por
la organizacin. Por otra parte, algunas herramientas CASE no ofrecen o evalan soluciones
potenciales para los problemas relacionados con sistemas o virtualmente no llevan a cabo
ningn anlisis de los requerimientos de la aplicacin.
Sin embargo, CASE proporciona un conjunto de herramientas semiautomatizadas y
automatizadas que estn desarrollando una cultura de ingeniera nueva para muchas
empresas. Uno de los objetivos ms importante del CASE (a largo plazo) es conseguir la
generacin automtica de programas desde una especificacin a nivel de diseo.
Ahora bien, con la aparicin de las redes de ordenadores en empresas y universidades ha
surgido en el mundo de la informtica la tecnologa cliente / servidor. Son muchas de las
organizaciones que ya cuentan con un nmero considerable de aplicaciones cliente / servidor
en operacin: Servidores de Bases de Datos y Manejadores de Objetos Distribuidos. Cliente /
servidor es una tecnologa de bajo costo que proporciona recursos compartidos, escalabilidad,
integridad, encapsulamiento de servicios, etc. Pero al igual que toda tecnologa, el desarrollo
de aplicaciones cliente / servidor requiere que la persona tenga conocimientos, experiencia y
habilidades en procesamiento de transacciones, diseo de base de datos, redes de
ordenadores y diseo grfica de interfase.
El objeto de estudio est centrado en determinar cules son las influencias de las
herramientas CASE en las empresas desarrolladoras de sistemas de informacin cliente /
servidor? Y cules son las tendencias actuales de las empresas fabricantes de sistemas
cliente
/
servidor?.
A continuacin, en el siguiente artculo ahondaremos ms en el propsito general de las
Herramientas CASE y el impacto que puede ocasionar el uso de las mismas en una empresa.
2. Herramientas Case
De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador es la
aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas propias
de desarrollo, su objetivo es acelerar el proceso para el que han sido diseadas, en el caso de
CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas.

Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de vida de las
aplicaciones de bases de datos, tambin se puede escoger una herramienta CASE (ComputerAided Software Engineering) que permita llevar a cabo el resto de tareas del modo ms
eficiente y efectivo posible. Una herramienta CASE suele incluir:

Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de

bases de datos.
Herramientas de diseo para dar apoyo al anlisis de datos.
Herramientas que permitan desarrollar el modelo de datos corporativo, as como los
esquemas conceptual y lgico.
Herramientas para desarrollar los prototipos de las aplicaciones.
El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una
aplicacin de bases de datos.
3. Historia
En la dcada de los setenta el proyecto ISDOS desarroll un lenguaje llamado "Problem
Statement Language" (PSL) para la descripcin de los problemas de usuarios y las
necesidades de solucin de un sistema de informacin en un diccionario computarizado.
Problem Statement Analyzer (PSA) era un producto asociado que analizaba la relacin de
problemas
y
necesidades.
Pero 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. (Monografas.com)
4. Tecnologa 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 y se plantean
los siguientes objetivos:

Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser

realizadas con una herramienta se consigue 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.

Automatizar:

El desarrollo del software

La documentacin
La generacin del cdigo
El chequeo de errores
La gestin del proyecto
Permitir:

La reutilizacin del software

La portabilidad del software
La estandarizacin de la documentacin

5. 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.
Meta modelo (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.
6. 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, la implantacin 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.
7. Estado Actual
En las ltimas dcadas se ha trabajado en el rea de desarrollo de sistemas para encontrar
tcnicas que permitan incrementar la productividad y el control de calidad en cualquier proceso
de elaboracin de software, y hoy en da la tecnologa CASE (Computer Aided Software
Engineering) reemplaza al papel y al lpiz por el ordenador para transformar la actividad de
desarrollar software en un proceso automatizado.
La tecnologa CASE supone la informatizacin de la informticaes decir la automatizacin
del desarrollo del software--, contribuyendo as a elevar la productividad y la calidad de en el
desarrollo de los sistemas de informacin de forma anloga a lo que suponen las tcnicas
CAD/CAM
en
el
rea
de
fabricacin.
En este nuevo enfoque que persigue mejorar la calidad del software e incrementar la
productividad en el proceso de desarrollo del mismo, se plantean los siguientes objetivos:

Permitir la aplicacin prctica de metodologas, lo que resulta muy difcil sin emplear
herramientas.

Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.

Simplificar el mantenimiento del software.

Mejorar y estandarizar la documentacin.

Aumentar la portabilidad de las aplicaciones.

Facilitar la reutilizacin de componentes de software

Permitir un desarrollo y un refinamiento (visual) de las aplicaciones, mediante la
utilizacin de controles grficos (piezas de cdigo reutilizables).
8. Integracin de las herramientas case en el futuro
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 otras CASE de forma automtica.
9. Clasificacin de las herramientas case
No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil incluirlas en
una
clase
determinada.
Podran
clasificarse
atendiendo
a:
Las
plataformas
que
soportan.
- Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La
arquitectura
de
las
aplicaciones
que
producen.
Su
funcionalidad.
CASE es una combinacin de herramientas software (aplicaciones) y de metodologas de
desarrollo
:
1. Las herramientas permiten automatizar el proceso de desarrollo del software.
2.
Las
metodologas
definen
los
procesos
automatizar.
Una
primera
clasificacin
del
CASE
es
considerando
su
amplitud
:
TOOLKIT: es una coleccin de herramientas integradas que permiten automatizar un conjunto
de tareas de algunas de las fases del ciclo de vida del sistema informtico: Planificacin
estratgica,
Anlisis,
Diseo,
Generacin
de
programas.
WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatizacin
del proceso completo de desarrollo del sistema informtico. Permiten cubrir el ciclo de vida
completo. El producto final aportado por ellas es un sistema en cdigo ejecutable y su
documentacin.
Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que
automatizan:
UPPER CASE: Planificacin estratgica, Requerimientos de Desarrollo Funcional de Planes
Corporativos.
MIDDLE
CASE:
Anlisis
y
Diseo.
LOWER CASE: Generacin de cdigo, test e implantacin
10. Caractersticas Deseables De Una Case
Una herramienta CASE cliente / servidor provee modelo de datos, generacin de cdigo,
registro del ciclo de vida de los proyectos, comunicacin entre distintos ingenieros. Las
principales herramientas son KnowledgeWares Application Development Workbench, TIs,
Information Engineering Facility (IEF), y Andersen Consultings Foundation for Cooperative
Processing.
Deberes
de
una
herramienta
CASE
Cliente
/
servidor:
Proporcionar topologas de aplicacin flexibles. La herramienta debe proporcionar facilidades
de construccin que permita separar la aplicacin (en muchos puntos diferentes) entre el
cliente,
el
servidor
y
ms
importante,
entre
servidores.
Proporcionar aplicaciones porttiles. La herramienta debe generar cdigo para Windows,
OS/ 2, Macintosh, Unix y todas las plataformas de servidores conocidas. Debe ser capaz, a
tiempo de corrida, desplegar la versin correcta del cdigo en la
mquina apropiada.
Control de Versin. La herramienta debe reconocer las versiones de cdigos que se ejecutan
en los clientes y servidores, y asegurarse que sean consistentes. Tambin, la herramienta debe
ser capaz de controlar un gran nmero de tipos de objetos incluyendo texto, grficos, mapas de

bits, documentos complejos y objetos nicos, tales como definiciones de pantallas y de

informes, archivos de objetos y datos de prueba y resultados. Debe mantener versiones de
objetos con niveles arbitrarios de granularidad; por ejemplo, una nica definicin de datos o
una
agrupacin
de
mdulos.
Crear cdigo compilado en el servidor. La herramienta debe ser capaz de compilar
automticamente cdigo 4GL en el servidor para obtener el mximo performance.
Trabajar con una variedad de administradores de recurso. La herramienta debe adaptarse
ella misma a los administradores de recurso que existen en varios servidores de la red; su
interaccin con los administradores de recurso debera ser negociable a tiempo de ejecucin.
Trabajar con una variedad de software intermedios. La herramienta debe adaptar sus
comunicaciones cliente / servidor al software intermedio existente. Como mnimo la herramienta
debera ajustar los temporizadores basndose en, si el trfico se est moviendo en una LAN o
WAN.
Soporte multiusuarios. La herramienta debe permitir que varios diseadores trabajen en una
aplicacin simultneamente. Debe gestionarse los accesos concurrentes a la base de datos por
diferentes usuarios, mediante el arbitrio y bloqueos de accesos a nivel de archivo o de registro.
Seguridad. La herramienta debe proporcionar mecanismos para controlar el acceso y las
modificaciones a los que contiene. La herramienta debe, al menos, mantener contraseas y
permisos de acceso en distintos niveles para cada usuario. Tambin debe facilitar la realizacin
automtica de copias de seguridad y recuperaciones de las mismas, as como el
almacenamiento de grupos de informacin determinados, por ejemplo, por proyecto o
aplicaciones.
Desarrollo en equipo, repositorio de libreras compartidas. Debe permitir que grupos de
programadores trabajen en un proyecto comn; debe proveer facilidades de check-in/ checkout registrar formas, widgets, controles, campos, objetos de
negocio, DLL, etc.; debe
proporcionar un mecanismo para compartir las libreras entre distintos realizadores y mltiples
herramientas; Gestiona y controla el acceso multiusuario a los datos y bloquea los objetos para
evitar que se pierdan modificaciones inadvertidamente cuando se realizan simultneamente.
11. Factores asociados a la implantacin de las herramientas case
La difusin de las innovaciones en esta rea ha comenzado a estudiarse a partir de los aos
1940. Por ello, existen estudios tericos al respecto, realizndose evaluaciones, adopcin e
implementacin tecnolgica.
Existe un amplio cuerpo de investigaciones disponibles sobre la adopcin de innovaciones.
Muchos de los estudios sobre innovacin se han analizado bajo dos perspectivas: adopcin y
difusin (Kimberly, 1981). Mientras unos estudios usan la perspectiva de la adopcin para
evaluar la receptividad y los cambios de la organizacin o sociedad por la innovacin, otros
usan la perspectiva de la difusin para intentar entender por qu y cmo se difunde y qu
caractersticas generales o principales de la innovacin son aceptadas.
12. Conclusin
Sin lugar a dudas las herramientas CASE han venido a revolucionar la forma de automatizar
los aspectos clave en el desarrollo de los sistemas de informacin, debido a la gran plataforma
de seguridad que ofrecen a los sistemas que las usan y es que stas, brindan toda una gama
de componentes que incluyen todas o la mayora de los requisitos necesarios para el desarrollo
de los sistemas, han sido creadas con una gran exactitud en torno a las necesidades de los
desarrolladores de sistemas para la automatizacin de procesos incluyendo el anlisis, diseo
e implantacin.
Las Herramientas CASE se clasifican por su amplitud en: TOOLKIT, WORKBENCH adems
tambin se pueden dividir teniendo en cuenta las fases del ciclo de vida que automatizan:
UPPER CASE, MIDDLE CASE, LOWER CASE.
Debido a la gran demanda que tienen las CASE su exigencia en cuanto a su uso ha ido
aumentando, por lo que toda CASE debe entre otras cosas:

Proporcionar topologas de aplicacin flexibles

Proporcionar aplicaciones porttiles
Brindar un Control de versin
Crear cdigo compilado en el servidor
Dar un Soporte multiusuario
Ofrecer Seguridad
Desde que se crearon stas herramientas (1984) hasta la actualidad, las CASE cuentan con
una credibilidad y exactitud que tienen un reconocimiento universal, siendo usadas por
cualquier desarrollador y / o programador que busca un resultado ptimo y eficiente, pero sobre
todo que busca esa minuciosidad necesaria de los procesos y entre los procesos.
13. Bibliografa
Analisis Y Diseo De Sistemas
3. Edicin

Kendall & Kendall

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Resumen
Introduccin
La Ingeniera de Software
La complejidad del Software
Principios de Modelado
El Lenguaje de Modelado Unificado UML
El proceso Unificado de Modelado (RUP)
Diagramas de UML
Conclusiones
Bibliografa

Resumen.
El presente artculo describe la evolucin de las notaciones que dieron lugar a UML (Lenguaje
de Modelado Unificado), detalla ampliamente sobre el surgimiento de la Ingeniera del
Software, expone los principios de modelado en que se fundamenta la notacin de UML,
asimismo muestra y explica como el UML adopta el RUP(Proceso Unificado de Desarrollo) para
modelar las actividades de un proyecto. Finalmente se propone la organizacin de los
diagramas a utilizar en las diferentes etapas del desarrollo de los sistemas de informacin.
1. Introduccin.
A lo largo de los aos, el desarrollo de los proyectos de software causan bastantes confusiones
y malas interpretaciones en los requerimientos de los clientes y usuarios, en parte debido a la
abundancia de notaciones, metodologas y conceptos que hace que los desarrolladores de
sistemas no se pongan de acuerdo en que es lo que realmente estn elaborando. En un
esfuerzo para estndarizar las notaciones y procesos a utilizar, se conform un consorcio
liderado por la empresa Rational y por las principales empresas del mundo de la industria de la
informtica, entre ellas, Microsoft, Oracle, Sun Microsystems, Intellicorp, IBM, AMD y otras,
quienes desarrollaron una notacin llamada UML y el proceso de desarrollo RUP.
2. La Ingeniera de Software.
La ingeniera del Software nace como una disciplina para aplicar los principios tcnicas y
herramientas de desarrollo de software, surgi porque todos los desarrolladores en la dcada
de los 80s, realizaban el software de forma artstica, es decir utilizando mtodos y tcnicas
adhoc donde la experiencia (el ensayo-error) era el camino a seguir. Este enfoque produjo
grandes y exitosos productos de programacin pero conforme los proyectos se volvieron ms
complejos debido al avance del hardware y software y la penetracin cada vez mayor de la
informtica en todos los mbitos de la sociedad, llev a que se produjera software sin calidad,
se incumplieran los presupuestos y se incrementara dramticamente los costos de
mantenimiento.
La solucin propuesta fue aplicar mtodos y principios que han sido utilizados y probados en la
experiencia de desarrollo de software para producir de forma inequvoca productos que corran
eficientemente y se ejecuten sobre mquinas reales. En la dcada de los 70 surgieron una gran
variedad de metologistas y metodologas entre ellos se destacan Yourdon y Demarco cuyas
investigaciones se basaban en los principios de la programacin estructurada. En los 80s y
90s el paradigma estructurado evolucion hacia el paradigma orientado a objetos, en el
perodo de 1989 y 1994 se cre la llamada guerra de mtodos dentro de la comunidad
orientada a objetos existiendo un incremento de menos de diez a ms de cincuenta
metodologas, es as que los desarrolladores de software quedaron muy confundidos sin saber
cual era la metodologa ms adecuada para elaborar sus proyectos.
Ante lo enunciado, el UML oficialmente se present cuando Rumbaugh, Booch y Jacobson
unifican sus estudios con una semntica y notacin, para lograr compatibilidad en el anlisis y
diseo orientado a objetos, permitiendo que los proyectos se asentaran en un lenguaje de
modelado maduro, permitiendo a los constructores de herramientas enfocarse en producir
caractersticas ms tiles.

3. La complejidad del Software.

Al observar sistemas complejos sociales como una gran empresa, los naturales como el
universo y los sistemas creados por el hombre como el computador, se observa que exhiben
una jerarqua de clases (conceptos) y otra de objetos (instancias). En una empresa donde
conjuntos de personas forman un departamento y un conjunto de departamentos forman
divisiones se describe la forma cannica de un sistema complejo que exhibe dos jerarquas:
Una jerarqua de clases y otra jerarqua de objetos, donde cada objeto es una instancia de la
una clase. Este es el modelo del cual se apropia el anlisis y diseo orientado a objetos para
desarrollar sistemas donde hay gran cantidad de software.
Figura 1.

Forma Cannica de un Sistema Complejo

4. Principios de Modelado
En cualquier proyecto de ingeniera como la construccin de un gran edificio, un avin, una
represa hidroelctrica, la construccin de un procesador de textos o un software de
comunicaciones para Internet, requieren de etapas de modelamiento que permitan
experimentar y visualizar el sistema que se construir. De la experiencia en ingeniera se
extractan los siguientes principios de modelado:
a) La forma como vemos el problema tiene una profunda influencia en forma como
acometemos el problema y le damos solucin al mismo.
Si pensamos que el mundo esta compuesto de clases (Abstracciones de la realidad y de la
solucin del problema) y objetos (instancias de stas abstracciones) que interactan entre si
para realizar una funcionalidad, as veremos el mundo. Este es precisamente al paradigma a
que le apuesta UML: el modelo orientado a objetos. Si vemos la realidad como compuesta de
procesos donde cada uno a su vez se puede descomponer en subprocesos entonces estamos
concibiendo la realidad segn el modelo estructurado y la arquitectura del sistema en desarrollo
estar conformada de programas y subprogramas.
b) Para modelar un sistema complejo no es suficiente un nico modelo se requieren
mltiples modelos donde cada uno representa una vista (aspecto) del sistema; estos
modelos se complementan entre si.

Esta es la razn de la existencia de varios diagramas en UML que modelan diferentes aspectos
del sistema, desde las vistas lgicas y fsicas del sistema hasta los aspectos dinmicos,
estticos y funcionales del mismo.
c) Cualquier modelo puede ser representado con diferentes grados de precisin.
La precisin se puede ver desde dos pticas: La primera es el grado de detalle con que se
representa un modelo; por ejemplo, si lo que se desea es razonar acerca de los requerimientos
del sistema con un cliente o usuario final, se puede elaborar un diagrama de clases que
muestra las clases, sus atributos y operaciones as como varios adornos(multiplicidad) en las
relaciones; por otro lado, si lo que se desea es transmitir el diagrama de clases para que sea
implementado en un DBMS (Data Base Management System, Sistema Administrador de Bases
de Datos) por un programador, el diagrama con toda seguridad contendr la visibilidad de las
caractersticas (atributos y operaciones) de las clases, los tipos de datos de los atributos y las
signaturas de las mtodos de las clases.
La segunda forma de ver la precisin de un modelo se refiere al nivel de abstraccin, ese decir,
a los detalles y la vista (porcin del sistema o realidad) que presenta un modelo al lector; por
ejemplo, en un sistema Bancario que maneja los retiros que hacen los clientes ya sea en un
cajero automtico o humano, el diagrama de clases contiene decenas de stas; sin embargo
las personas encargadas de desarrollar la interfaz de un cajero electrnico estaran interesadas
en las clases necesarias para realizar el comportamiento del cajero y omiten el resto de clases
del sistema.
d) Los mejores Modelos estn ligados a la realidad.
El smbolo de un actor en un diagrama de casos de uso representa, de hecho, un actor en el
sistema real; as como un componente en un diagrama de componentes representa un
componente fsico del software. Cada elemento de UML como una clase, objeto, estado,
componente o nodo tiene su correspondencia con algn elemento conceptual o fsico del
mundo real.
5. El Lenguaje de Modelado Unificado UML.
"El Lenguaje de Modelado Unificado UML es un lenguaje estndar para escribir planos de
software. UML puede utilizarse para visualizar, especificar, construir y documentar los
artefactos de un sistema que involucra gran cantidad de software"
El UML es el Lenguaje de Modelado Unificado Orientado a Objetos, UML no es un mtodo
porque no tiene nocin de proceso el cual es una parte importante de un mtodo. Ahora
bien si UML no es mtodo; entonces Cules son las etapas a seguir en el desarrollo de
sistemas con UML?, varios especialistas en desarrollo de sistemas de informacin arguyen de
que existe la necesidad de adoptar un Proceso de Desarrollo de sistemas para enmarcar las
fases importantes que sigue el UML, por ello los desarrolladores de proyectos de sistemas de
informacin emplean el Procesos Unificado para dar soluciones adecuadas a las necesidades
de los clientes.
El desarrollo de sistemas con UML siguiendo el proceso unificado incluye actividades
especficas, cada una de ellas a su vez contienen otras subactividades las cuales sirven como
una gua de cmo deben ser las actividades desarrolladas y secuenciadas con el fin de obtener
sistemas exitosos; consecuentemente el desarrollo de los sistemas puede variar de
desarrollador en desarrollador, de proyecto en proyecto, de empresa en empresa adoptando
siempre un Proceso de Desarrollo.
6. El proceso Unificado de Modelado (RUP).
A travs de la historia se han desarrollado varios modelos de proceso de software (paradigmas
de desarrollo) cada uno con sus ventajas, desventajas y utilidad en algunos tipos de proyectos

y problemas. Al igual que cualquier notacin, el proceso unificado acta como un modelo que
puede adaptarse a cualquier tipo de proyecto y empresa (grandes y pequeas). Las
caractersticas del proceso unificado de modelado son:

Centrado en los Modelos: Los diagramas son un vehculo de comunicacin ms

expresivo que las descripciones en lenguaje natural. Se trata de minimizar el uso de
descripciones y especificaciones textuales del sistema.
Guiado por lo casos de uso: Los casos de uso son el instrumento para validar la
arquitectura del software y extraer los casos de prueba.
Centrado en la arquitectura: Los modelos son proyecciones del anlisis y el diseo
constituye la arquitectura del producto a desarrollar.
Iterativo e incremental: Durante todo el proceso de desarrollo se producen versiones
incrementales (que se acercan al producto terminado) del producto en desarrollo.
Figura 2.

El Proceso de Modelado Unificado

El grfico que representa el RUP incluye las cuatro etapas importantes que son: la iniciacin,
elaboracin, construccin y transicin, las cuales muestran que para producir una versin del
producto en desarrollo se aplican todas las actividades de ingeniera pero con diferente nfasis;
en las versiones preliminares, como adems indica la intuicin, hay ms nfasis en actividades
de modelado del negocio, requisitos, anlisis y diseo; conforme se producen versiones el
nfasis pasa a las actividades de implementacin, pruebas y despliegue.
8. Diagramas de UML.
Los elementos de UML se muestran mediante diagramas que presentan mltiples vistas del
sistema, ese conjunto de vistas son conocidos como modelos.
UML presenta varios diagramas donde cada uno representa un aspecto del sistema. De ah
que varios investigadores segn sus criterios y puntos de vista mencionan qu diagramas
emplear en el desarrollo de los sistemas de informacin; sin mencionar cules son los
diagramas ms adecuados en las distintas etapas de desarrollo del Proceso Unificado, viendo
esta necesidad, la autora del presente artculo propone un conjunto de diagramas necesarios
para cada etapa segn la complejidad del sistema de informacin a solucionar.

Dado un sistema a desarrollar no es necesario emplear todos los diagramas; para sistemas
sencillos un diagrama de clases junto con un par de diagramas de actividades e interaccin
sera suficiente, asimismo si los sistemas son complejos requieren de la utilizacin de ms
diagramas, debido a que requieren de etapas incrementales e iterativas(ciclos de desarrollo) en
el anlisis, diseo e implementacin, por ello es que el conjunto actividades deber especificar
la etapa de desarrollo y los diagramas recomendados como muestra la siguiente figura:
9. Conclusiones.
El lenguaje Unificado de modelado UML es una notacin que es el resultado de la evolucin de
las notaciones previas en ingeniera de software, toma los aspectos fuertes de tres
metodologas anteriores: OMT, Booch y OOSE.
La notacin UML se fundamenta en principios de modelado, lo cual es importante para toda
implementacin de un sistema de informacin.
El UML debe adoptar el Proceso Unificado de Desarrollo para modelar las actividades de un
proyecto.
Los diagramas a utilizar en las diferentes etapas del desarrollo de los sistemas de informacin,
pueden variar dependiendo del tamao y tipo de sistema, por lo que es necesario organizarlos
segn las fases del Proceso Unificado.