Herramienta CASELas herramientas CASE (Computer Aided Software Engineering,Ingeniería de Software Asistida por Computadora) son diversasaplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos 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 diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras. Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había 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 más específicas 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 informáticos.

4. Mejorar la planificación de un proyecto

5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la

búsqueda de soluciones para los requisitos.

6. Automatizar el desarrollo del software, la documentación, la generación de código, las

pruebas de errores y la gestión del proyecto.

7. Ayuda a la reutilización del software, portabilidad y estandarización de la

documentación

8. Gestión global en todas las fases de desarrollo de software con una misma

herramienta.

9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Clasificación

Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

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 clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis

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

Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de

la aplicación.

Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código,

crean programas de detección de errores, soportan la depuración de programas y

pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden

incluirse las herramientas de Desarrollo rápido de aplicaciones.

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

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

software, desde análisis hasta implementación.

MetaCASE, herramientas que permiten la definición de nuestra propia técnica 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 definiéramos

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 gestión de proyectos y gestión de la

configuración activa.

Por funcionalidad podríamos diferenciar algunas como:

Herramientas de generación semiautomática de código.

Editores UML.

Herramientas de Refactorización de código.

Herramientas de mantenimiento como los sistemas de control de versiones·

Lista de Herramientas CASEEn esta sección se mostrarán las herramientas CASE expuestas, su link a estos productos y con una breve descripción.

NetBeans   NetBeans  Herramienta muy buena con características buenas como desarrollo intuitivo gratis y open source drag-and-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 herramienta pero no para el desarrollo UML ya que no genera código 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 podría posicionarse como una herramienta optima para poder desarrollar diagrama de clases de una manera muy eficaz  

Eduardo Galicia / Gerardo Valencia 

Microsoft Visio  Visio  Herramienta de diagramación avanzada con gran variedad de plantillas que permiten simplificar las tareas complejas con elementos visuales dinámicos basados en datos, UML Bases de Datos Arquitectura ect con SharePoint con más facilidad sin generar código Pero bastante atractiva para hacer distintos diagramas  

En general es una Herramienta potente con grandes características aunque limitan-tes en cuanto a generar código e Ingeniería inversa por compatibilidad y básicamente seria solo para hacer diagramas simples de DFD principalmente 

Eduardo Galicia Soto / Gerardo Valencia 

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

En lo personal me parece muy potente como ya lo había 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 aplicación pero en lo general muy poderosa  

Eduardo Galicia Soto/ Gerardo Valencia 

OmniGraffle  OmniGraffle  Es una herramienta de Es muy buena, sencilla Gabriela González y

diagramación disponible para OS, muy práctica y fácil de usar, con muchos elementos que facilitan la creación de DFD. Esta herramienta brinda la posibilidad de exportar en varios formatos, es accesible y se puede adquirir directamente en el Appstore 

pero el inconveniente es que es únicamente para Mac OS 

Ernesto Urritia 

Serena Composer  Serena Composer  Esta herramienta ayuda en el diseño de la interfaz gráfica 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 visión no funcional del sistema (prototipo) que no puede ser reutilizado para la etapa de desarrollo 

Serena Composer no nos pareció una buena opción pues el resultado de utilizar este sistema es únicamente un reporte (No código) 

Gabriela González y Ernesto Urrutia 

Erwin  Erwin  Esta herramienta es de las más eficientes y completas, para la tarea de realizar ingeniería inversa esta herramienta es sumamente sencilla, basta con darle la orden, no hubo mucho que explicar pues es realmente sencilla  

Muy eficiente , es un software básico. 

Gabriela González y Ernesto Urrutia 

GUI Design Studio  GUI Design Studio  Es una herramienta enfocada solamente en el diseño de interfaces gráficas para aplicaciones, es muy sencillo de usar y contiene muchos elementos para modelar pantallas de aplicaciones botones, cajas de texto, contraseñas, 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 

Héctor Alfredo Juárez Albarrán / Mauro Abraham Romero Moreno 

Eclipse Indigo *Plug-in "UML 2 Tools" 

UML 2 Tools  Para la generación de diagramas de clases en Ecplise se necesita un plug-in, este tiene una facilidad de uso muy buena y es fácil 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. 

Héctor Alfredo Juárez Albarrán / Mauro Abraham Romero Moreno 

Expression Web 4  Expression Web 4  Esta herramienta de Microsoft permite hacer

Microsoft Expression Web 4 Es una

Héctor Alfredo Juárez Albarrán / Mauro

paginas web muy fácil ya que no es necesario meterse al codigo HTML, si no permite seleccionar los elementos de una paleta y solo arrastrarlos para crear nuestra página. Permite el uso de código PHP para hacer aplicaciones Web poderosas. 

herramienta muy eficiente ya que cuenta con todo lo necesario para hacer un diseño de una pagina Web incluyendo las características de servidor FTP y código del lado del servidor, ademas que es capaz de verificar la compatibilidad con los navegadores 

Abraham Romero Moreno 

Edraw  Edraw  Es un programa muy completo para realizar diferentes tipos de diagramas de varias metodologías, 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 

Héctor Alfredo Juárez Albarrán / Mauro Abraham Romero Moreno 

ERwin  ERwin  Esta herramienta es muy eficaz cuando se busca hacer el diseño de una Base de Datos ya que permite crear paralelamente el modelo físico y lógico de la BD. Así mismo permite crear Triggers, Indices Stored Procedures, en bastantes Manejadores de Base de Datos tanto para hacer una ingeniería inversa o pasar el diseño a un manejador. 

ERwin es una herramienta muy poderosa que permite hacer de todo en cuanto a diseño de BD se refiere, ademas que soporta la colaboración de usuarios y servicio en la nube 

Héctor Alfredo Juárez Albarrán / Mauro Abraham Romero Moreno 

MOCKFLOW  MOCKFLOW  Herramienta CASE enfocada a la etapa de diseño ya sea web, móvil o desktop. Tiene servicio en la nube. 

Ofrece muchas ventajas de exportación, manejo fácil y accesible. Solo sirve para documentación. 

Mishelle Eduardo Bermudez Domínguez, Miguel Ángel Flores Saldívar, Iván García Messner 

yUML  yUML  Herramienta CASE enfocada a diagramación 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 Domínguez, Miguel Ángel Flores Saldívar, Iván García Messner 

Oracle SQL Developer  Oracle SQL Developer  Herramienta CASE especializada en Base de Datos, tiene varios módulos de modelado de datos entre otras y tiene compatibilidad con distintos manejadores de Base de Datos. 

Es muy práctica y sabiéndola 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 Domínguez, Miguel Ángel Flores Saldívar, Iván García 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 básica, hecha solamente con fines educativos. 

Mishelle Eduardo Bermudez Domínguez, Miguel Ángel Flores Saldívar, Iván García Messner 

CASE Studio 2  Case studio2  es una herramienta case que es principalmente orientada al diseño y modelado de diagramas de entidad relación. 

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 González Rivas/Manuel Alejandro Avalos Aviles 

SQL server  sql server  herramienta para realizar ingenieria inversa 

Esta herramienta nos muestra como se reducen o aumentan el 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 

Pedro Antonio González Rivas/Manuel Alejandro Avalos Aviles 

EASY CASE  easy case  herramienta para realizar de analisis y diseño 

es buena la herramienta por que te permite obtener los resultados esperados y 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 diseño 

Pedro Antonio González Rivas/Manuel Alejandro Avalos Aviles 

Poseidon  Poseidon  herramienta para realizar diagramas UML  

la herramienta no es muy buena ya que es complicada realizar los diagrams ya que la manipulación es dificil y no te cuenta con todo lo necesario los uml muy poderosos. 

Pedro Antonio González Rivas/Manuel Alejandro Avalos Aviles 

Sharepoint workflow  sharepoint  plataforma de microsoft de colaboración empresarial, funciones de colaboración, basado en el explorador web, módulos de administración de proceso, módulos de búsqueda y una plataforma de administración de documento. 

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 González Rivas/Manuel Alejandro Avalos Aviles 

Mostrando 20 elementos

Herramientas CASE (Computer Aided Software Engineering, Ingeniería de SoftwareAsistida por Computadoras). Son diversas Aplicaciones informáticas destinadas a aumentar la productividad en el

Desarrollo de software reduciendo el coste de las mismas en términos 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 diseño de proyectos, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, Compilación automática, documentación o detección 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 método. 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 .

HistoriaYa en los años 70, un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Aunque esos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había 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 más específicas para cada fase del ciclo de vida del software.

Tecnología de las herramientas CASELa tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información a la hora de construir software se plantean los siguientes objetivos: • Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta conseguimos agilizar el trabajo. • Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones. • Simplificar el mantenimiento de los programas. • Mejorar y estandarizar la documentación. • Aumentar la portabilidad de las aplicaciones. • Facilitar la reutilización de componentes software. • Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.

Componentes de una herramienta CASEDe una forma esquemática 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 gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros. • Metamodelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías 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 comunicación con otras herramientas. • Comprobación de errores, facilidades que permiten llevar a cabo un análisis 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 diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.

Estructura general de una herramienta CASE 

La estructura CASE se basa en la siguiente terminología :

• 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 planificación de sistemas, el análisis de sistemas y el diseño de sistemas. • CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, laimplantación 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 gestión de proyectos y la estimación.

ClasificaciónAunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

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 clasificación basada en las fases del ciclo de desarrollo cubre:

Upper CASE  (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.

Middle CASE  (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.

Lower CASE  (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.

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

Integrated CASE  (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.

MetaCASE , herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelogenerado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos 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 gestión de proyectos y gestión de la configuración.

Por funcionalidad podríamos diferenciar algunas como:

Herramientas de generación semiautomática de código.

Editores UML.

Herramientas de Refactorización de código.

Herramientas de mantenimiento como los sistemas de control de versiones.

Ejemplos de Herramientas Case más utilizadas.ERwin

PLATINUM ERwin es una herramienta de diseño de base de datos. Brinda productividad en diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos. Genera automáticamente las tablas y miles de líneas 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 Ingeniería de Base de Datos, es un producto para la generación de esquemas de base de datos e ingeniería reversa,

trabaja para proveer una solución comprensible para el diseño, consistencia y documentación del sistema en conjunto.

Oracle Designer

Oracle Designer es un juego de herramientas para guardar las definiciones que necesita el usuario y automatizar la construcción rápida de aplicaciones cliente/servidor flexibles y gráficas. Integrado con Oracle Developer, Oracle Designer provee una solución para desarrollar sistemas empresariales cliente/servidor de segunda generación.

PowerDesigner

PowerDesigner es una suite de aplicaciones de Powersoft para la construcción, diseño y modelado de datos a través de diversas aplicaciones. Es la herramienta para el análisis, diseño inteligente y construcción sólida de una base de datos y un desarrollo orientado a modelos de datos a nivel físico y conceptual, que dan a los desarrolladores de aplicaciones Cliente/Servidor la más firme base para aplicaciones de alto rendimiento.

System Architect

System Architect posee un repositorio único que integra todas las herramientas, y metodologías usadas. En la elaboración de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos asociados, comentarios,reglas de validaciones, normalización, etc. Posee control automático de diagramas y datos, normalizaciones y balanceo entre diagramas "Padre e Hijo", además 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

estándares S.A.A de IBM., totalmente documentados y ajustados a los requerimientos específicos de la organización, en una fracción del tiempo y coste del que se invertiría, si se utilizaran herramientas tradicionales.

Futuro de las Herramientas CASELas herramientas CASE evolucionan hacia tres tipos de integración: 1. La integración de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios locales para el intercambio de datos. 2. La integración de presentación confiere a todas las herramientas CASE el mismo aspecto. 3. La integración de herramientas permite disponer de herramientas CASE capaces de invocar a otra herramienta CASE.

Glosario de Definiciones Básicas de CASE CASE: Ayuda por Computadora a la Ingeniería de Software.

TECNOLOGIA CASE: Una tecnología del software que mantiene una disciplina de la ingeniería automatizada para el desarrollo de software, mantenimiento y dirección de proyecto, incluye metodologías estructuradas, automatizadas y herramientas automatizadas.

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 común y corren en un ambiente computacional común.

KIT de HERRAMIENTAS CASE: Un conjunto de herramientas CASE integradas que se han diseñado para trabajar juntas y automatizar (o proveer ayuda automatizada al ciclo de desarrollo de software, incluyendo el análisis, diseño, codificación y prueba).

METODOLOGIA CASE:metodología estructurada que define una disciplina e ingeniería como un acercamiento a todos o algunos aspectos del desarrollo y mantenimiento de software.

PUESTO DE TRABAJO para CASE: Una estación de trabajo técnica 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 línea, que proveen unaplataforma operativa para las Herramientas Case.

EL LENGUAJE UNIFICADO DE MODELADO (UML)

En todas las disciplinas de la Ingeniería 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, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.

El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 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, aeronáutica, finanzas, etc.

Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o más). Modelar sistemas (y no sólo de software) utilizando conceptos orientados a

objetos. Establecer conceptos y artefactos ejecutables. Encaminar el desarrollo del escalamiento en sistemas complejos de misión

crítica. Crear un lenguaje de modelado utilizado tanto por humanos como por

máquinas. Mejor soporte a la planeación y al control de proyectos. Alta reutilización y minimización de costos.

UML, ¿Método o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo los símbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 1).

figura 1

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos 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 Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

Vista de Componentes: Muestra la organización de los componentes de código.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.

Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.

 

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos 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 asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

FASES DEL DESARROLLO DE UN SISTEMA

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.

Análisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés 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 jerarquías. 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 análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.

Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están 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 también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía 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.

Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: 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 análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.

Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración 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 aceptación 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. Introducción2. El lenguaje UML3. Una perspectiva general de UML4. Un estudio a fondo de UML5. Uso de una herramienta de modelado6. Proceso de desarrollo7. Conclusiones8. Bibliografía

Introducción

En el presente módulo se permite entregar un material de apoyo que le permita al alumno poder definir diagramas propios como también 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 cómo estos diagramas se usan para modelar sistemas, toda vez que el Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico 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, además 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 ingeniería o arquitectura ha encontrado útil desde hace mucho tiempo la representación de los diseños de forma gráfica. Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños de una forma más bien personal o con algún modelo gráfico. La falta de estandarización en la manera de representar gráficamente un modelo impedía que los diseños gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores. Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creó el Lenguaje Unificado de Modelado (UML: Unified Modeling Lan-guage).

UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño. 

El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con los diagramas de despliegue.

1.1. MODELADO VISUAL

Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificación de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación gráfica. Esto se conoce como modelado visual. El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. 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 diseño 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 implementación, de tal forma que los diseños realizados usando UML se pueda implementar en cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados a objetos). UML es además un método formal de modelado. Esto aporta las siguientes ventajas: • Mayor rigor en la especificación. • Permite realizar una verificación y validación del modelo realizado. • Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y a la inversa (a partir del código fuente generar los modelos). Esto

permite que el modelo y el código estén actualizados, con lo que siempre se puede mantener la visión en el diseño, de más 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 compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software). El objetivo de ambos era unificar dos métodos que habían desarrollado: el método 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". Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML. Esta primera versión se ofreció a un grupo de tra-bajo para convertirlo en 1997 en un estándar del OMG (Object Management Grouphttp://www.omg.org). Este grupo, que gestiona estándares relacionados con la tecnología orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.), propuso una serie de modificaciones y una nueva versión de UML (la 1.1), que fue adoptada por el OMG como estándar en noviembre de 1997. Desde aquella versión han habido varias revisiones que gestiona la OMG Revision Task Force. La última versión aprobada es la 1.4. En estos momentos se está desarrollando una nueva versión en la que se incluirán cambios importantes (principalmente añadir nuevos diagramas) que conducirán a la versión 2.0 planificada para fines del 2002.

1.3. ¿Qué es UML?

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.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 comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema. Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo. Las objetivos de UML son muchos, pero se pueden sintetizar sus funciones: • Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender. • Especificar: UML permite especificar cuáles son las características de un sistema

antes de su construcción. Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseñados. • Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura re-visión. 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 informáticos, como flujos de trabajo (workflow ) en una empresa, diseño de la estructura de una organización y por supuesto, en el diseño de hardware.Un modelo UML está compuesto por tres clases de bloques de construcción: • 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 representación gráfica 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 Colaboración para modelar interacciones entre objetos.• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.• Diagramas de Componentes para modelar componentes.• Diagramas de Implementación para modelar la distribución del sistema.Los diagramas más interesantes (y los más 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 gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción 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 cómo. 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 más común a la hora de describir el diseño de los sistemas orientados a objetos. En la figura 4 se muestran las clases globales, sus atributos y las relaciones de una posible solución al problema de la venta de entradas.En el diagrama de secuencia se muestra la interacción de los objetos que componen un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 5 muestra la interacción de crear una nueva sala para un espectáculo. El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el comportamiento dinámico del sistema están los deinteracción, colaboración, estados y actividades. Los diagramas de componentes y despliegue están enfocados a la implementación del sistema.

Figura 3: Diagrama de casos de uso

Figura 4: Diagrama de clases

Figura 5: Diagrama de secuencia.

1.5. UML ofrece notación y semántica estándar

UML preescribe una notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos. Previamente, un diseño orientado a objetos podría haber sido modelado con cualquiera de la docena de metodologías populares, causando a los revisores tener que aprender las semánticas y notaciones de la metodología empleada antes que intentar entender el diseño en sí. Ahora con UML, diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de los otros.

1.6. UML no es un Método

Aun así, UML no preescribe un proceso o método estándar para desarrollar un sistema. Hay varias metodologías existentes; entre las más populares se incluyen las siguientes:• Catalysis: Un método orientado a objetos que fusiona mucho del trabajo reciente en métodos orientados a objetos, y además ofrece técnicas específicas para modelar componentes distribuidos.• Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por Ivar Jacobson.• Shlaer/Mellor: El método para diseñar 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 continúan actualizando su método continuamente (la actualización más reciente es el OOA96 report), y recientemente publicaron una guía sobre cómo usar la notación UML con Shlaer/Mellor.• Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer intento de un método de diseño orientado a objetos estándar. Combina OMT y Booch con tarjetas CRC y métodos formales. (www.hpl.hp.com/fusion/file/teameps.pdf)• OMT: La Técnica de Modelado de Objetos fue desarrollada por James Rumbaugh y otros, y publicada en el libro de gran influencia "Diseño y Modelado Orientado a Objetos" (Prentice Hall, 1991). Un método que propone análisis y diseño 'iterative', más centrado en el lado del análisis.• Booch: Parecido al OMT, y también muy popular, la primera y segunda edición de "Diseño Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design, With Applications), detallan un método ofreciendo también diseño y análisis 'iterative', centrándose en el lado del diseño.Además, muchas organizaciones han desarrollado sus propias metodologías internas, usando diferentes diagramas y técnicas con orígenes varios. Ejemplos son el método Catalyst por Computer Sciences Corporation (CSC) o el Worlwide Solution Design

and Delivery Method (WSDDM) por IBM. Estas metodologías difieren, pero generalmente combinan análisis 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 técnicas adicionales de modelado de objetos como Casos de Uso y tarjetas CRC. La mayoría de estas organizaciones están adoptando e incorporando el UML como la notación orientada a objetos de sus metodologías.Algunos modeladores usarán 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 usarán una suite más completa, incluyendo los diagramas de estado y actividad para modelar sistemas de tiempo real, y el diagrama de implementación para modelar sistemas distribuidos. Aun así, otros no estarán satisfechos con los diagramas ofrecidos por UML, y necesitarán 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 jerárquica de un documento válido.Dado que XML Schema no tiene su propia notación gráfica se ha decidido utilizar UML. Sin embargo, este lenguaje no permite representar directamente estos esquemas, con lo que será necesario realizar una extensión al mismo.UML ha sido diseñado para que pueda extenderse de una forma controlada, mediante sus propios mecanismos de extensión. Dichos mecanismos permiten crear nuevos bloques de construcción por medio de estereotipos, valores etiquetados y restricciones. Una extensión de UML debería contener : una breve descripción, la lista y descripción 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 extensión de UML para la representación de XML Schemas.

Tabla 1. Extensión de UML para representación gráfica de XML Schemas

Icono: FRPSOH[7\SH Icono: VLPSOH7\SH

Restricciones: Debe estar relacionado por medio de una asociación <<Compose>> con los elementos que forman el tipo complejo.Valores Etiquetados: Ninguno

Restricciones: Debe estar relacionado por medio de una asociación <<Compose>> con el elemento o atributo que lo usa.Valores Etiquetados: Tipo base, Restricciones propias del tipo base.

Asociación ComposeClase del Metamodelo: AsociaciónDescripción: Una asociación <<Compose>> es un tipo especial de asociación unidireccional que enlaza una clase <<ELEMENT>> con la clase referenciada por un atributo IDREF/IDREFS o un tipo simple o complejo que lo sea utilizado por el<<ELEMENT>>. Si el atributo es de tipo IDREFS, la flecha estará rellena.Si se trata de un atributo IDREF, la flecha estará sin rellenar. La dirección de la asociación se representará con la flecha al final de la clase, que se referencia por el tipo ELEMENT.Icono: NingunoRestricciones: Sólo se puede 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

Asociación BelongToClase del Metamodelo: AsociaciónDescripción: Una asociación <<BelongTo>> es un tipo especial de asociación unidireccional que enlaza una clase <<ELEMENT>> con la clase querepresenta a su elemento padre. La parte de la asociación con el rombo representa el elemento padre. En el extremo opuesto pueden aparece el mínimo número y/o máximo de ocurrencias Un número máximo de ocurrencias ilimitado se representará mediante una N.Icono: NingunoRestricciones: Sólo se puede usar para unir dos <<ELEMENTS>>, siendo uno el padre del otro.Valores Etiquetados: Ninguno

Reglas que ha de cumplir un diseño bien formadoCada tipo <<ELEMENT>> tiene que estar enlazado con una asociación de <<Compose>> o<<BelongTo>> con otro <<ELEMENT>>, <<complexType>> o <<simpleType>>.Un atributo de tipo <<IDREF>> o <<IDREFS>> en un <<ELEMENT>> implica una asociación de<<Compose>> con otro <<ELEMENT>>. Un <<ELEMENT>> puede contener una colección de atributos.

Se ha presentado una extensión a UML para representar un esquema en XML Schema. Esta propuesta se enmarca dentro de MIDAS/DB, una metodología para la creación de bases de datos Web que propone utilizar UML como notación única para la definición de todo el sistema. Existen diferentes extensiones a UML para distintas técnicas de modelado Web, sin embargo, no son suficientes para representar todas las técnicas que se proponen en MIDAS/DB.Para validar la extensión propuesta se han desarrollado distintos casos de prueba.Además también se está realizando la implementación de una extensión a Rational Rose, que permitirá la representación en notación gráfica en UML de todo el sistema en todas las etapas de desarrollo de MIDAS/DB, así como la transformación semiautomática entre las distintas etapas. Actualmente, se está trabajando en la definición de otras extensiones a UML necesarias para poder respresentar todo el sistema con una única notación, y de guías de transformación para pasar de una etapa a la siguiente de forma sistemática.

Una perspectiva general de UML

2.1. Una vuelta por un caso de uso

Una vez más, UML es una notación, no un método. No preescribe un proceso para modelar un sistema.No obstante, como UML incluye los diagramas de casos de uso, se le considera estar dotado de una aproximación al diseño centrada en el problema con los casos de uso. El Diagrama de Caso de Uso nos da el punto de entrada para analizar los requisitos del sistema, y el problema que necesitamos solucionar.La Figura 1 muestra un flujo general de cómo los diagramas de UML, con extensiones, interactuan en una aproximación al diseño con los casos de uso.

2.2. Casos de Uso y Diagramas de Interacción

Un caso de uso se modela para todos los procesos que el sistema debe llevar a cabo. Los procesos se describen dentro de el caso de uso por una descripción textual o una secuencia de pasos ejecutados. Los Diagramas de Actividad se pueden usar también para modelar escenarios gráficamente. 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 Colaboración y de Secuencia se usan para mostrar las relaciones entre los objetos.

2.3. Clases y Diagramas de Implementación

Conforme se van encontrando los objetos, pueden ser agrupados por tipo y clasificados en un Diagrama de Clase. Es el diagrama de clase el que se convierte en el diagrama central del análisis del diseño orientado a objetos, y el que muestra la

estructura estática del sistema. El diagrama de clase puede ser dividido en capas: aplicación, y datos, las cuales muestran las clases que intervienen con la interfaz de usuario, la lógica del software de la aplicación, y el almacenamiento de datos respectivamente. Los Diagramas de Componentes se usan para agrupar clases en componentes o módulos. La distribución general del hardware del sistema se modela usando el Diagrama de Implementación.

2.4. Tarjetas CRC (CRC cards) - Una extensión informal de UML

Como una extensión informal a UML, la técnica de las tarjetas CRC se puede usar para guiar el sistema a través de análisis 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 dinámico y significativo, se modela usando un Diagrama de Estado. El diagrama de actividad puede ser usado también aquí, esta vez como una extensión 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 también para representar gráficamente las acciones de métodos de clases.

Figura 1: Aproximación 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 diseño

La implementación del sistema trata de traducir información desde múltiples modelos UML en código y

estructura de bases de datos. Cuando se modela un sistema grande, es útil fragmentar el sistema en su capa 'business' (incluyendo los objetos de la interfaz de usuario), su capa de aplicación (incluyendo los objetos de implementación), y su capa de datos (incluyendo la estructura de la base de datos y el acceso a objetos).

2.7. Implementando la aplicación

El Diagrama de Clase se usa para generar una estructura base del código en el lenguaje escogido.Información de los diagramas de interacción, estado, y actividad, puede ofrecer detalles de la parte procedimental del código de implementación.

2.8. Implementando el diseño de Bases de Datos

La capa de datos del diagrama de clase se puede usar para implementar directamente un diseño orientado a objetos de una base de datos, o, como extensión de UML, puede ser referenciado en un diagrama de relación de entidad para más análisis de relaciones de entidad. Está en el diagrama de relación de entidad (ER diagram, entity relationship) el cual relaciona entre entidades que pueden ser modeladas basadas en atributos clave. El diagrama de relación de entidad lógico ofrece una base desde la cual construir un diagrama físico 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 también para probar el sistema y ver si satisface los requisitos iniciales. Los pasos de los casos de uso van llevando a cabo para determinar si el sistema está satisfaciendo los requisitos del usuario.

Un estudio a fondo de UML

Las siguientes secciones presentan una vista más detallada al modelado con UML. Un sistema de reserva de aerolíneas simple se va a usar para mostrar los diagramas y técnicas de modelado con UML. Se cubren los siguientes puntos:• Organizando tu sistema con paquetes• Modelando con Casos de Uso, y usándolos para averiguar los requisitos del sistema• Modelando con Diagramas de Secuencia y Colaboración• Analizando y diseñando con el Diagrama de Clase, y extendiendo UML con la técnica de las tarjetasCRC• Modelando comportamiento con Diagramas de Actividad y de Estado• Modelando componentes de software, distribución e implementación

• Extendiendo UML con el diseño de Bases de Datos relacionalesUna 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, categorías o subsistemas, la idea es la misma: dividir el sistema en áreas que tengan competencias parecidas.UML introduce la noción 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 más alto, donde son usados para subdividir el sistema en dominios, hasta el nivel más 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 técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmente una aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis 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 "muñecos" 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 estímulo desde un actor. Se dibujan como elipses.

Figura 3: Modelado de Casos de Uso.

Cada caso de uso se documenta por una descripción del escenario. La descripción puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso puede ser también definido por otras propiedades, como las condiciones pre- y post- del escenario --- condiciones que existen antes de que el escenario comience, y

condiciones que existen después de que el escenario se completa. Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. éstos son descritos en una sección posterior de este documento.

 

3.1.1. Estudiar y descubrir los requisitos

El objetivo final en cualquier diseño 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 diseño, y que el diseño 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 través de los Casos de Uso, permite el descubrimiento de estos requisitos.

3.1.2. Organización de Diagramas de Casos de Uso

Durante el análisis 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 través de la relación "Extiende" (extends)

Típicamente, 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 están relacionados con el caso de uso original mediante una relación "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 relación de extensión es un elemento especial de modelado, por lo tanto la relación aparece explícitamente en las siguientes definiciones.

Definición 4: Extensión de Casos de UsoUn Caso de Uso UC es la extensión de UC1 por UC2 a través de una relación "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 condición:Para cada punto de extensión de ext debe existir una acción 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 uotb- 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-Corrección: cada secuencia de acciones en UC es una extensión de alguna secuencia de acciones en UC1.« oOEUC.operation .$o1OE UC1.operation . (o.name=o1.name Ÿ (« sOEo.actionSequence.$s1OEo1.actionSequence. sOEextensions(s1,ext,UC2) ) )Definición 5:isExtensible: ActionSequence x ExtendEl predicado es verdadero si la secuencia de acciones contiene algún punto de extensión de la relación extend y está definido de la siguiente forma:« s:ActionSequence « ext:Extend .isExtensible(s,ext) ´ $ iOEext.extensionPoint . i.locationOEsDefinición 6:extensions: ActionSequence x Extend x UseCase -> Set(ActionSequence)La función extensions(s,ext,uc) retorna el conjunto de todas las posibles extensiones de la secuencias dadas por la relación ext y el Caso de Uso uc. La función 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 }Definición 7: UC extiende a UC1 si existe un Caso de Uso UC2 tal que UC es la extensión de UC1 por UC2 a través de una relación ext:UC extendsext UC1 ´ $ UC2:UseCase . ( UC = UC1 ³ext UC2 )

3.1.5. Eliminar el modelado redundante a través de la relación "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 relación "Incluir" (Include). La relación Incluir (Include) se puede pensar como un caso de uso equivalente 'of aggregation'.La relación Include Una relación include entre dos Casos de Uso indica que el comportamiento definido en el Caso de Uso a adicionar, es incluído 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 incluído, ejecuta todo el comportamiento descripto por el Caso de Uso incluído y luego continúa de acuerdo a su Caso de Uso original. El Caso de Uso incluído no depende del Caso de Uso base. En este sentido, el Caso de Uso incluído representa comportamiento encapsulado que puede ser reusado en varios Casos de Uso.Definición 1: Inclusión de Casos de UsoUn 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.nameOEutb- 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- Corrección: 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) ) )Definición 2:isIncluible: ActionSequence x UseCaseEl predicado isIncluible(s,uc) es verdadero si la secuencia de acciones s contiene alguna invocación al Caso de Uso uc y está definido de la siguiente forma:« s:ActionSequence « uc:UseCase . isIncluible(s,uc) ´ uc.name OEsDefinición 3:inclusions: ActionSequence x UseCase -> Set(ActionSequence)La función 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: Relación caso de uso Extiende (extends) frente a relación de caso Usa (uses=Include).

3.1.6. Ayuda en casos de uso probando el sistema frente a los requisitos

Los Casos de Uso también se utilizan para construir scripts de prueba que se usan a su vez para comprobar que la aplicación satisface los requisitos de negocio y de sistema.Cuando has llegado al caso de uso del nivel más bajo, podrías crear un Diagrama de Secuencia para el Caso de Uso. Con los Diagramas de Secuencia y de Colaboración puedes modelar la implementación del escenario.

3.2. Diagramas de Secuencia

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción 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 implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos.Típicamente uno examina la descripción de un caso de uso para determinar qué

objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción 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 líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.

3.3. Diagramas de Colaboración

El Diagrama de Colaboración 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 cronológica del escenario que estamos modelando, el diagrama de colaboración 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 asociación entre las clases implicadas.

El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto

con respecto a los otros.

Figura 6:Diagrama de Colaboración para un grupo de Objetos

3.4. Análisis y Diseño con el Diagrama de Clase

El Diagrama de Clase es el el diagrama principal de diseño y análisis para un sistema. En él, la estructura de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, 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 análisis

3.4.1.1. Aproximación a un Caso de Uso guiado

En una aproximación a un Caso de Uso guiado hacia el análisis orientado a objetos, el diagrama de clases se desarrolla a través de información obtenida en los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboración. Los objetos encontrados durante el análisis son modelados en términos 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 análisis

3.4.1.2. Extensión guiada por la responsabilidad

La técnica de la tarjeta CRC se usa a veces como una extensión a UML para análisis guiados por la responsabilidad. Las definiciones de clase son refinadas basándose 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 diseñadores 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 información se pasa directamente a un diagrama de clase; las responsabilidades coinciden con los métodos de clase, las colaboraciones se traducen en asociaciones entre clases.

Figura 8: Extensión informal de UML -- Tarjetas CRC para análisis guiados por la responsabilidad.

3.4.2. Diseño del sistema con Diagramas de Clase

Durante el diseño, el Diagrama de Clase se elabora para tener en cuenta los detalles concretos de la implementación del sistema.

3.4.2.1. Arquitecturas Multicapas

Una vez concienciados del diseño, estableceremos la arquitectura del sistema. Esto incluye establecer si será un sistema simple diseñado para correr en una sola máquina, 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 aproximación a dirigir el diagrama de clase para un sistema complejo es separar el diagrama en secciones que muestren la lógica de la aplicación, el diseño de la interfaz de usuario, y las clases implicadas con el almacenamiento de los datos. Esto

se puede hacer físicamente segmentando el diagrama de clase, usando diagramas separados para cada sección, o simplemente añadiendo una propiedad a cada clase que 'tracks' cada 'tier' al cual pertenece.

3.4.2.2. Diseño de Componentes

Un componente es un grupo de objetos o componentes más pequeños 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 diseño e implementación internas del componente. El desarrollo basado en componentes es el proceso deensamblar la combinación correcta de componentes en la configuración 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 operación). 'The alternate, shortcut notation' es mostrar la interfaz como un circulo pequeño junto con la clase con una línea sólida, con el nombre de la interfaz en el círculo.El ejemplo de la Figura 9 muestra que la clase 'Pasajero' ofrece la operación move(x coord, y coord) para su apariencia en un GUI, a través de su interfaz 'Displayable'. Ambas notaciones UML de interfaz, se muestran en la figura. Además, la clase Pasajero también ofrece una opción save(store at) a través de su interfaz Persistente. Una clase de o componente para conectar con una base de datos podría usar esta interfaz.

Figura 9: Diseño de Componentes: Especificando la Interfaz de la Clase

3.4.2.3. Análisis y diseño 'Iterative'

El diagrama de clase se puede desarrollar en una 'iterative fashion', a través de un ciclo repetido de análisis, diseño e implementación, y después vuelta al análisis, 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 permitiéndote implementar el diseño en un lenguaje como C++ o Java, y después traer de vuelta al código a al diagrama de clase, automáticamente actualizando la información contenida en el diagrama y en el 'underlying repository'.

Figura 10: Análisis, diseño y documentación 'Iterative' con el Diagrama de Clase

3.5. Modelando el comportamiento de las Clases con Diagramas de Estado

Mientras los diagramas de interacción y colaboración modelan secuencias dinámicas de acción entre grupos de objetos en un sistema, el diagrama de estado se usa para modelar el comportamiento dinámico 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 dinámico. En él, modelas la secuencia de estado que un objeto de la clase atraviesa durante su vida en respuesta a los estímulos recibidos, junto con sus propias respuestas y acciones.Por ejemplo, un comportamiento de un objeto se modela en términos de en qué estado está inicialmente, y a qué estado cambia cuando recibe un evento en particular. También 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 líneas de transición describen el movimiento desde un estado hasta otro. Cada línea de transición se nombre con el evento que causa esta transición. Las acciones ocurren cuando un objeto llega a un estado.

Figura 11: Modelando Comportamiento Dinámico 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-propósito 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 método 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 gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más 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 asincrónicos. El diagrama de actividad se usa conado todos o la mayoría de los elementos representan el desarrollo de los pasos dados por las acciones generadas internamente. Deberías 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 código 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 Distribución y la Implementación

Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama 'deployment', empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente.Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo 'becomes' (se transforma)

Figura 14: Modelando la Distribución del Sistema con el Diagrama de Implementación

3.9. Diseño de Bases de Datos Relacionales -- Una extensión informal de UML

El Diagrama de Clase presenta un mecanismo de implementación 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 método más 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 diseño de bases de datos relacionales, pero no cubre toda la semántica involucrada en el modelado relacional, mayoritariamente la noción de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar esta información, un Diagrama de Relación de Entidad (ER diagram) se recomienda como extensión a UML.El Diagrama de Clase se puede usar para modelar el estructura lógica 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 método de implementación escogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relación de entidad lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entre entidades en un diagrama de relación de entidad (ER diagram).

Figura 15: Extensión de UML -- Diseño de Bases de Datos Relacionales con el Diagrama de Relación de Entidad (ER Diagram)

Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de determinar cómo 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 lógico que sea conforme a las reglas de normalización de datos.Al implementar el diseño relacional, es una estrategia encaminada a hacer referencia al diagrama de relación de entidad lógico a un diagrama físico que represente el objetivo, el RDBMS. El diagrama físico puede ser denormalizado para lograr un diseño 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.Además, el diagrama físico se usa para modelar propiedades específicas de cada fabricante para el RDBMS. Se crean varios diagramas físicos si hay varios RDBMSs siendo 'deployed'; cada diagrama físco representa uno de los RDBMS que son nuestro objetivo.

Figura 16: Relaciones clave entre entidades en un Diagrama de Relación de Entidad

Uso de una herramienta de modelado

El intercambio de información de diseño e ideas usando la notación UML sería 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 automáticamente información, y diseño de documentación.Una característica que beneficia a los modeladores, UML también hace más fácil escoger una herramienta de modelado. Hace tiempo, el modelador primero tenía que seleccionar una notación de metodología, y después estaba limitado a seleccionar una herramienta que la soportara. Ahora con UML como estándar, la elección de notación 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

diseño de sistemas descrito en esta guía, esto incluye lo siguiente:• Soporte para toda la notación y semántica de UML• Soporte para una cantidad considerable de técnicas de modelado y diagramas para complementar UML - incluyendo tarjetas CRC, modelado de datos, diagramas de flujo, y diseño de pantallas de usuario. Posibilidad de reutilizar información obtenida por otras ténicas todavía usadas, como modelado tradicional de procesos.• Facilitar la captura de información en un repositorio subyacente - permitiendo la reutilización entre diagramas.• Posibilidad de personalizar las propiedades de definición 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 cómo han sido satisfechos los requisitos en cada uno de los pasos del desarrollo.• Posibilitar la creación de informes y documentación personalizados en tus diseños, y la salida de estos informes en varios formatos, incluyenod HTML para la distribución en la Internet o Intranet local.• Posibilidad para generar y 'reverse' código (por ejemplo C++, Java, etc) para facilitar el análisis y diseño 'iterative', para volver a usar código o librerías de clase existentes, y para documentar el código.

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 metodología de desarrollo, denominada el Proceso Unificado de Desarrollo.El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidos. Además, el Proceso Unificado utiliza el UML para expresar gráficamente 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: Basándose en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que los llevan a cabo. Además, estos modelos se vali-dan para que sean conformes a los casos de uso. Finalmente, los casos de uso también sir-ven para realizar las pruebas sobre los componentes desarrollados. • Centrado en la arquitectura: En la arquitectura de la construcción, antes de construir un edificio éste se contempla desde varios puntos de vista: estructura, conducciones eléctricas, fontanería, etc. Cada uno de estos aspectos está representado por un gráfico con su notación correspondiente. Siguiendo este ejemplo, el concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. 

• Iterativo e incremental: Todo sistema informático complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico 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 iteración en el proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Además, cada iteración 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 terminología propia, pensado principalmente para el desarrollo de grandes proyectos. Es un

proceso que puede adaptarse y extenderse en función de las necesidades de cada empresa.

Conclusiones

Es fácil 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 prácticamente todas las empresas importantes de informática. • Se ha aceptado como un estándar por la OMG. • Prácticamente 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 gráfico. Además, se ha llega-do a una solución unificada basada en lo mejor que había hasta el momento, lo cual lo hace todavía más excepcional.