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.