Herramientas y Entornos de Programaci n o

Sergio Garca Mondaray www.yakiboo.net

Escuela Superior de Inform tica de Ciudad Real a Universidad de Castilla-La Mancha

 Indice general
1. Introducci n o 1.1. Generalidades sobre la Ingeniera del Software. SWEBOK . . . . . . . . . . . . . . . . . 1.1.1. Construcci n del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 1.1.2. Herramientas y m todos de la Ingeniera del Software . . . . . . . . . . . . . . . e 1.2. Estilos y Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Estilos de construcci n (interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . o 1.2.2. Principios de organizaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 1.3. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1. Patrones de creaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 1.3.2. Patrones estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3. Patrones de comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Tecnologas CASE 2.1. Introducci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.1.1. Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. Componentes de las herramientas CASE . . . . . . . . . . . . . . . . . . . . . . 2.2. Clasicaci n de las herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.3. Entornos CASE integrados (I-CASE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Componentes de un I-CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Benecios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. Opciones de Integraci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.4. Adopci n de herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.4.1. Proceso de evaluaci n y selecci n de herramientas . . . . . . . . . . . . . . . . . o o 3. Entorno de desarrollo .NET 3.1. Caractersticas generales de .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Qu es .NET? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 3.1.2. Objetivos de la tecnologa .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3. Componentes principales de .NET . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 5 5 6 6 6 7 9 9 10 10 11 11 11 12 12 14 16 16 16 17 18 19 21 21 21 21 21

3.1.4. Lenguaje com n en tiempo de ejecuci n (CLR) . . . . . . . . . . . . . . . . . . . u o 3.1.5. Especicaciones del lenguaje com n CLS . . . . . . . . . . . . . . . . . . . . . . u 3.2. Ensamblados (Assemblies) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Introducci n a los Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.2.2. Caractersticas de los Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3. Estructura de un ensamblado est tico . . . . . . . . . . . . . . . . . . . . . . . . a 3.2.4. Maniesto de un Ensamblado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5. Tipos de Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6. Ejecuci n simult nea de varias versiones de un Ensamblado . . . . . . . . . . . . o a 3.3. Administraci n de datos con ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.3.1. ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Integraci n de ADO.NET con XML . . . . . . . . . . . . . . . . . . . . . . . . . o 3.3.3. Espacio de nombres para ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4. Elementos fundamentales de ADO.NET . . . . . . . . . . . . . . . . . . . . . . . 3.4. .NET frente a otras tecnologas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. .NET vs COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. .NET vs COM+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3. .NET vs J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4. .NET vs CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. El entorno Visual Studio .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1. Caractersticas generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Servicios Web 4.1. Introducci n a los Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.1.1. Conceptos b sicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 4.1.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. SOAP: Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. WSDL: Web Services Description Language . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. WSIL: Web Services Inspection Language . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Proceso de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Localizaci n de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.5.2. Descripci n del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4.5.3. Llamada a los m todos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 4.5.4. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 24 25 25 25 26 26 27 28 28 28 28 29 29 29 29 30 30 31 31 31 33 33 33 33 34 35 36 36 36 36 37 37

Introducci n o

Captulo 1

Introducci n o
1.1. Generalidades sobre la Ingeniera del Software. SWEBOK

El SWEBOK1 es un comit conjunto del IEEE y de ACM, cuyo objetivo es tratar de promover la e Ingeniera del Software como profesi n reconocida. o Existen diversas areas de conocimiento en SWEBOK, como lo son: Requerimientos del software. Dise o del software. n Pruebas del software. Mantenimiento del software. Gesti n de la conguraci n del software. o o Calidad del software. Hablaremos, en primer lugar, de las que m s nos conciernen: a Construcci n del software. o Herramientas y m todos de la Ingeniera del Software. e

1.1.1.

Construcci n del software o

Lenguajes de Programaci n o Los lenguajes de programaci n son medios de comunicaci n entre las personas y los computadores. o o Hist ricamente fueron creados como respuesta a necesidades de aplicaciones especcas. o Es una rama muy joven a n, algo inestable. Resulta importante destacar que la construcci n de software u o no debe depender del lenguaje o metodologa de la programaci n. o Lenguajes de Construcci n o Los lenguajes de construcci n contienen todas las formas de comunicaci n por medio de las cuales las o o personas pueden construir soluciones ejecutables en un sistema de c mputo. Los lenguajes de programaci n o o son las formas m s exibles de los lenguajes de construcci n. a o
1 Software

Engineering Body of Knowledge

Herramientas y Entornos de Programaci n o Formas simples de los lenguajes de construcci n son los lenguajes de conguraci n, con los que los o o desarrolladores escogen entre opciones predenidas para crear un nuevo softwared e instalaci n. Otros de o estos lenguajes de construcci n son los lenguajes de herramientas o toolkits. o Automatizaci n de la construcci n del software o o La construcci n autom tica supone el uso intensivo de herramientas de construcci n autom tica o a o a (HCA), que tienden a tomar la forma de generadores de programas y de entornos altamente integrados que brindan el control autom tico del proceso de construcci n. a o Para ser ecaces las HCA deben poseer interfaces sencillas e intuitivas. Adem s, la automatizaci n del a o software se reere no s lo a las herramientas, sino a la abstracci n de programaci n (por ejemplo, la POO2 ). o o o

1.1.2.

Herramientas y m todos de la Ingeniera del Software e

Existen muchsimas herramientas de ayuda en la Ingeniera del Software. Podemos categorizarlas en los siguientes grupos: Para los requerimientos del software. Para registrar, analizar y validar los requisitos del software. Algunos ejemplos son Rational RequisitePro y DOORS. Para el diseno del software. Para crear y vericar dise os de software. Existe gran variedad, en n correspondencia con la gran multitud de notaciones y m todos. Un ejemplo es Enterprise Architect. e Para el proceso de construcci n. Compiladores, depuradores, editores de c digo, etc. Son ejemplo o o de herramientas de este tipo Editeur y ConText. Para llevar a cabo pruebas de software. Se clasican seg n las partes del proceso de prueba en que u se empleen: generadores de pruebas, frameworks, evaluadores de pruebas, y gestores de pruebas. Un ejemplo es Junit. Para el mantenimiento de software. Existen varios tipos: herramientas de ayuda a la comprensi n humana de programas, herramientas de ingeniera inversa, herramientas de re-ingeniera3 , y o herramientas de conversi n de c digo. Son ejemplos Maintenance Assistant y RAMI. o o Para el control de calidad. Existen herramientas de inspecci n (apoyo a las revisiones), de an lio a sis est tico (como analizadores sint cticos, de dependencia, etc), y herramientas de comportamiento a a din mico (an lisis de prestaciones en tiempo de ejcuci n). Ejemplos: KMKey Quality, y Mipsis Softa a o ware Quality. Para la gesti n de conguraci n del software. Herramientas para la gesti n de versiones, y hero o o ramientas para la gesti n de liberaci n y actualizaciones. Por ejemplo: PureCM. o o Para la gesti n de la Ingeniera del Software. Hay varias modalidades: herramientas para proyeco tar, planicar y realizar trazas; herramientas para el an lisis y gesti n de riesgos; herramientas para a o realizar mediciones; y herramientas para trazar deciencias. Miscel nea. a

1.2.
1.2.1.

Estilos y Principios
Estilos de construcci n (interfaces) o

Existen diferentes estilos de interrelaci n entre los computadores y las personas que utilizan software o (m s concretamente los propios lenguajes de construcci n). Los lenguajes de construcci n deben presentar a o o
2 Programaci n o 3 Obtenci n o

orientada a objetos. de productos nuevos a partir de la ingeniera inversa.

Introducci n o y recibir la informaci n de modo comprensible a los sentidos y las capacidades humanas, a trav s de lo que o e se denomina interfaz. Existen 3 estilos de interfaces de construcci n de software, que estudiaremos a continuaci n: ling stio o u co, formal y visual. La mayora de lenguajes raramente se apoyan en un solo estilo, los m s extendidos a utilizan los estilos ling stico y formal. u

Estilo lingustico Se basa en la utilizaci n de oraciones que se asemejan a las del lenguaje natural. Normalmente se o transeren visualmente en forma de texto. Su ventaja principal es que son generalmente universales. Por otra parte, su mayor desventaja es la imprecisi n para expresar necesidades surgidas con el empleo de o interfaces.

Estilo formal Se basa en la precisi n y rigor del razonamiento l gico y formal, asemej ndose a la forma de razonar del o o a ser humano. Por ello es especialmente apropiado para trasladar a los computadores los prop sitos humanos, o as como para vericar la precisi n y complejidad de una construcci n. o o El problema al que se enfrenta es que el razonamiento formal no est tan extendido como el lenguaje a conformado por: componente innato + habilidades adquiridas. Otra gran pega es que el razonamiento formal suele centrarse en lo fundamental del problema, desechando los detalles, y ese enfoque estrecho no es bueno para la construcci n de software. o

Estilo visual Se basa en la utilizaci n de interfaces visuales. Este estilo resulta especialmente util para la construco ci n de software porque provee de facilidades, al presentar opciones y ocultar detalles mediante el sistema o visual (interfaz). Adem s es apropiado para sistemas que requieren de muchos desarrolladores, ya que pera miten establecer c mo y cu ndo comunicarse con los dem s. o a a

1.2.2.

Principios de organizaci n o

Adem s de los 3 estilos de interrelaci n humano-computador que hemos estudiado, existen 4 principios a o de organizaci n que afectan el modo en que tiene lugar la construcci n del software. Estos principios, que o o estudiaremos a continuaci n, son los siguientes: o Principio de reducci n de la complejidad. o Principio de anticipaci n a la diversidad. o Principio de estructuraci n para la validaci n. o o Principio de utilizaci n de est ndares externos. o a

Principio de Reducci n de la Complejidad o Este principio reeja la limitada habilidad de las personas para trabajar con sistemas complejos, de muchas partes o interacciones. Se aplica a todos los aspectos de la construcci n del software, siendo espeo cialmente crtico en los procesos de auto-vericaci n. Existen 3 t cnicas principales para reducir la com o e plejidad: 7

Herramientas y Entornos de Programaci n o Eliminaci n de la complejidad: consiste en eliminar durante la construcci n del software, las posio o bilidades no imprescindibles. Debe manejarse con cuidado y lleva intrnseco el principio de la parsi monia: no a adir nunca capacidades que no ser n requeridas. n a Automatizaci n de la complejidad: es m s poderosa que la anterior. Se crea un nuevo lenguaje de o a construcci n en que las facilidades consumidoras de tiempo, o propensas al error si son realizadas o por humanos, se asignen al computador. Un buen ejemplo son los entornos gr cos de programaci n. a o Localizaci n de la complejidad: si la complejidad no puede ser eliminada ni automatizada, la unica o opci n es localizarla en peque as unidades o m dulos. Es muy adecuado para la comprensi n de una o n o o persona. Pero hay que tener cuidado, pues una divisi n exagerada podra no ayudar si las relaciones o entre los m dulos fuesen muy complicadas. o Principio de Anticipaci n a la Diversidad o Tiene que ver m s con c mo la gente usa el software que con las diferencias entre los computadores a o y las personas. Se basa en el hecho de que no existe ninguna construcci n de software perpetua, a la que o no haya que hacerle cambios con el paso del tiempo. La anticipaci n a esos cambios es fundamental en el o proceso de construcci n del software. o Las implementaciones de f rmulas matem ticas, aunque parezca lo contrario, tambi n deben adaptarse o a e con el paso del tiempo, por ejemplo, a la computaci n en nuevas m quinas, etc. o a a T cnica de Generalizaci n: Los casos generales no son obvios en las primeras fases de an lisis. La e o generalizaci n tiene como nalidad reconocer como algunos problemas especcos encajan juntos como o parte de un marco m s general, para poder as resolverlos mediante una sola construcci n software en lugar a o de varias. Un ejemplo es el uso de pilas, que resulta m s general que el uso de arrays de tama o jo. El a n problema es que depende mucho de la habilidad del desarrollador para encontrar generalizaciones. T cnica de Experimentaci n: Consiste en utilizar tempranamente construcciones de software en tantos e o contextos de usuario diferentes como sea posible, con el prop sito de recopilar datos que permitan genero alizar la construcci n. Es m s una t cnica a nivel de proceso que de c digo. Un ejemplo es la metodologa o a e o que sigui Linus Torvalds para crear Linux: las construcciones de c digo individuales se incorporaban r pio o a damente al producto general y se distribuan, as se forzaba el uso, la experimentaci n y la actualizaci n de o o esas construcciones individuales. T cnica de Localizaci n: Signica mantener los cambios anticipados tan localizados en una construce o ci n software como sea posible. Resulta de la aplicaci n del principio de localizaci n de la complejidad. o o o Podemos destacar como ejemplos la utilizaci n de capas en la denici n de protocolos de comunicaci n, o o o as como la utilizaci n de constantes de compilaci n para reducir la cantidad de campos. o o Principio de Estructuraci n para la Validaci n o o No importa cuanto cuidado se ponga en el dise o e implementaci n del software, es inevitable la n o comisi n de errores. El principio de Estructuraci n para la Validaci n dicta construir el software de modo o o o que tales errores puedan aparecer durante las pruebas. Para ello el software debe ser modular, y las pruebas deben desarrollarse paralelamente a la construcci n. o Principio de Utilizaci n de Est ndares Externos o a Los lenguajes de construcci n deben cumplimentar est ndares externos. Un ejemplo son las gram ticas o a a de los lenguajes de programaci n, otro es la utilizaci n de lenguajes como XML, con gran n mero de o o u adaptaciones. Pero el ejemplo m s destacable es Internet, que fuerza el desarrollo de software adaptado, a por ejemplo, a est ndares web. a El conicto entre reutilizar est ndares externos o crear alguno nuevo es muy complejo. a 8

Introducci n o

1.3.

Patrones

Los patrones describen problemas que ocurren una y otra vez en nuestro entorno, y describen el contenido de la soluci n del mismo, con lo que puedes resolverlos sin tener que rehacerla. Son una abstracci n o o de una soluci n contreta, dada por un problema concreto, en un contexto determinado. o Un patr n est compuesto por varios elementos: o a Nombre. Debe ser signicativo y corto, para que sea f cil de recordar. a Contexto. Dene las precondiciones en las cuales se da el problema. Problema. Describe las metas y objetivos buscados. Relaciones. Dene las relaciones est ticas y din micas de un patr n con otros. a a o Soluci n. Son reglas din micas que describen c mo solucionar el problema. o a o Ejemplos. Uno o m s ejemplos que ilustren el contexto, el problema y su soluci n. a o Existen 3 categoras principales de patrones, en funci n del nivel de abstracci n, del contexto en el que o o se aplican o de la etapa en el proceso de desarrollo. Gamma clasica los patrones en patrones de creaci n, o patrones estructurales, y patrones de comportamiento.

1.3.1.

Patrones de creaci n o

Se trata de patrones que abstraen el proceso de instanciaci n de los objetos. Ayudan a hacer un sistema o independiente de la creaci n, composici n y representaci n de sus objetos. o o o Algunos ejemplos son: Abstract Factory, Builder, Factory Method, Prototype y Singleton.

Singleton Contexto: Hay clases que necesitan tener s lo una instancia. o Problema: Esta unica instancia debera ser extensible por diferentes clases sin ser modicada. Relaciones: Muchos otros patrones, como Abstract Factory, Builder y Prototype, son implementados usando este patr n. o Soluci n: El constructor de la clase se hace privado, y dentro de ella se tiene una instancia est tica de o a la misma. Se crea un m todo getInstance() que devuelva siempre dicha instancia unica. (Ver e fragmento de c digo 1.1). o Ejemplos: Sistemas spooler para impresoras, donde s lo debera haber un sistema de manejo spooler, o s lo una ventana manager. o

Fragmento de c digo 1.1: Ejemplo de patr n Singleton o o

1 2 3 4 5 6

public class MiClase{ private static MiClase instanciaUnica = new MiClase(); private MiClase(){/*Codigo del constructor*/} public static getInstance(){return instanciaUnica;} ... }

Herramientas y Entornos de Programaci n o

1.3.2.

Patrones estructurales

Tratan de ver c mo las clases y los objetos se unen para formar grandes estructuras. Este tipo de patrones o usan herencia para componer interfaces o implementaciones. Estos patrones son especialmente utiles para hacer desarrollos independientes de libreras de clases que trabajan juntas. Algunos ejemplos son: Adapter, Bridge, Composite, Decorator, Facade, Flyweight y Proxy. Facade Contexto: Estructurar un sistema y sus subsistemas para reducir la complejidad al m ximo. Minimizar a la comunicaci n y dependencias entre subsistemas. o Problema: Unicar en una interfaz todas las interfaces de un subsistema. Relaciones: Abstract Factory es una alternativa a Facade para ocultar especicaciones de plataformas en clases. Tambi n est relacionado con Mediator, y con Singleton (normalmente, s lo es requerido e a o un objeto de tipo Facade). Soluci n: Consiste en ofrecer una clase que haga de interfaz con el sistema (ver c digo 1.2). o o Ejemplos: Interfaz de acceso a base de datos, lectura de archivos XML, etc.

Fragmento de c digo 1.2: Ejemplo de patr n Facade o o

1 2 3 4 5 6

public class MiClase{ public MiClase(){/*Codigo del constructor*/} public void accion1DelSubsistema{...} public void accion2DelSubsistema{...} ... }

1.3.3.

Patrones de comportamiento

Este tipo de patrones tratan sobre algoritmos y asignaci n de responsabilidades entre objetos. Algunos o ejemplos son Chain of Responsibility, Interpreter, Observer y Mediator. Observer Contexto: Cuando un objeto cambie de estado, informar a los dem s del cambio. a Problema: Denir una o muchas dependencias entre objetos, de modo que cuando uno cambie de estado, todos los dem s est n actualizados autom ticamente. a e a Soluci n: Disponer en los observadores de m todos de actualizaci n (update(), que sean llamados o e o por los objetos observados cuando algo cambie) y de un m todo getter en los observados, que e facilite la actualizaci n de todos los cambios. o

10

Tecnologas CASE

Captulo 2

Tecnologas CASE
2.1. Introducci n o

Las tecnologas CASE1 proporcionan la automatizaci n del desarrollo del software. Estas tecnologas o son una composici n de ciertas herramientas y metodologas que se aplican a todo el ciclo de vida del o desarrollo del software. Herramientas aut nomas o integradas de productividad que automatizan totalmente, o en parte, tareas o del ciclo de vida del desarrollo de software. Metodologas estructuradas y automatizables que denen una formulaci n t cnica y disciplinada para o e todos o algunos de los aspectos del desarrollo de software. Ejemplo: la programaci n estructurada. o Las tecnologas CASE se centran en la productividad, y no s lo en obtener soluciones. Algunos ejem o plos son las herramientas de diagramaci n de esquemas estructurados, las herramientas de validaci n o o sint ctica o de inconsistencias, los generadores de c digo a partir de otras especicaciones (por ejempa o lo, gr cas), los generadores de documentaci n t cnica y de usuario, etc. a o e

2.1.1.

Conceptos

CASE: Ingeniera del Software asistida por computaci n. o Tecnologa CASE: Conjunto de instrumentos y t cnicas software dedicadas a la automatizaci n de e o una disciplina de la ingeniera, incluyendo metodologas estructuradas y herramientas. Herramienta CASE: Herramienta software que automatiza (totalmente o en parte) una parte del ciclo de desarrollo del software. Sistema CASE: Conjunto de herramientas CASE integradas que comparten una interfaz de usuario com n y corren en un ambiente computacional com n. u u Kit de herramientas CASE: Conjunto de herramientas CASE integradas que se han dise ado para n trabajar juntas y automatizar el ciclo de desarrollo software, incluyendo el an lisis, dise o, implea n mentaci n y pruebas. o Metodologa CASE: Conjunto estructurado de m todos que denen una disciplina de la ingeniera e como un acercamiento a todos o algunos aspectos del desarrollo y mantenimiento del software. Puesto de trabajo para CASE: Estaci n de trabajo t cnica o computador personal equipado con o e herramientas CASE que automatiza varias funciones del ciclo.
1 Computer

Aided Software Engineering. En espa ol: Ingeniera del Software Asistida por Computador. n

11

Herramientas y Entornos de Programaci n o Plataforma de hardware para CASE: Arquitectura de hardware con uno, dos o tres sistemas puestos en lnea, que provee una plataforma operativa para las herramientas CASE.

2.1.2.

Objetivos

Los nes que persiguen las herramientas CASE son variados: Aumentar la productividad de las areas de desarrollo y mantenimiento de los sistemas inform ticos a (reduciendo tiempos y costes). Mejorar la calidad del software desarrollado. Mejorar la gesti n y dominio sobre el proyecto en cuanto a su planicaci n, ejecuci n y control. o o o Mejorar el archivo de datos o enciclopedia de conocimientos (know-how) y sus facilidades de uso, reduciendo la dependencia de analistas y programadores. Podemos hacer la siguiente clasicaci n: o Automatizar: El desarrollo del software. La documentaci n. o La generaci n del c digo. o o El chequeo de errores. La gesti n del proyecto. o Permitir: La reutilizaci n del software. o La portabilidad del software. La estandarizaci n de la documentaci n. o o Integrar las fases de desarrollo (Ingeniera del Software) Facilitar la utilizaci n de las distintas metodologas que desarrolla la Ingeniera del Software. o

2.1.3.

Componentes de las herramientas CASE

Repositorio (diccionario) Lo que conocemos como repositorios, son una especie de almacenes donde se guardan los elementos denidos o creados por la herramienta, y cuya gesti n se realiza mediante el apoyo de un SGBD2 o de un o sistema de gesti n de cheros. o Las caractersticas m s importantes de un repositorio son: a Tipo de informaci n. Que contiene alguna metodologa concreta, datos, gr cos, procesos, informes, o a modelos o reglas. Tipo de controles. Si incorpora alg n m dulo de gesti n de cambios, de control de versiones, de u o o acceso por clave, de redundancia de informaci n. o
2 Sistema

de Gesti n de Bases de Datos o

12

Tecnologas CASE M dulos de diagramaci n y modelado o o Algunos de los diagramas y modelos utilizados con mayor frecuencia en las herramientas CASE son los siguientes: Diagrama de ujo de datos. Modelo entidad-interrelaci n. o Historia de la vida de las entidades. Diagrama de estructura de datos. Diagrama de estructura de cuadros. T cnicas matriciales. e Las caractersticas m s importantes de los diagramas y modelos son: a N mero m ximo de niveles. Para poder soportar dise os complejos. u a n N mero m ximo de objetos que se pueden incluir para no encontrarse limitado en el dise o de u a n grandes aplicaciones. N mero de diagramas distintos en pantalla o al mismo tiempo en distintas ventanas. u Dibujos en formato libre con la nalidad de a adir comentarios, informaci n adicional, etc. n o Actualizaci n del repositorio por cambios en los diagramas. o Control sobre el tama o, fuente, emplazamiento de texto, etc. n Inclusi n de pseudoc digo, que servir de base a los programadores. o o a Posibilidad de deshacer el ultimo cambio, para facilitar la correcci n de errores. o Herramientas de prototipado El objetivo de estas herramientas es poder mostrar al usuario, desde los momentos iniciales del dise o, n el aspecto que tendr la aplicaci n una vez desarrollada. Por ello estas herramientas ser n m s utiles cuanto a o a a m s r pidamente permitan la construcci n del prototipo. a a o Actualmente es imprescindible utilizar productos que incorporen esta funcionalidad, por la cambiante tecnologa y necesidades de los usuarios. Generadores de c digo o Las caractersticas m s importantes de los generadores de c digo son: a o Lenguaje generado. Si se trata de un lenguaje est ndar o propietario. a Portabilidad del c digo generado. o Si la generaci n es unicamente del esqueleto del programa o del programa completo. o Posibilidad de modicaci n del c digo generado. o o Generaci n del c digo asociado a las pantallas e informes de la aplicaci n. Para obtener la interfaz o o o de usuario de la aplicaci n. o 13

Herramientas y Entornos de Programaci n o Generadores de documentaci n o Este m dulo se alimenta del repositorio para transcribir las especicaciones all contenidas. Algunas o caractersticas importantes son: Generaci n autom tica a partir del repositorio, sin esfuerzo adicional. o a Combinaci n de informaci n textual y gr ca. o o a Generaci n de referencias cruzadas. Para conocer la localizaci n de un determinado elemento y o o analizar el impacto de un posible cambio. Ayuda de tratamiento de textos. Para mejorar la calidad de introducci n de textos complementarios a o la documentaci n. o Interfaz con otras herramientas: procesadores de texto, editores gr cos, etc. a

2.2.

Clasicaci n de las herramientas CASE o

A la hora de clasicar las herramientas CASE, debemos tener en cuenta numerosos factores, como los lenguajes de generaci n, el tipo de an lisis (estructurado u orientado a objetos), si cubren algunas fases de o a una etapa, o pr cticamente todo el ciclo de vida del software, etc. a Es por ello que no existe una unica clasicaci n, sino que pueden clasicarese en base a: o Las plataformas que soportan Segun su amplitud: Toolkit: es una colecci n de herramientas integradas que permite automatizar un conjunto de o tareas de algunas de las fases del ciclo de vida de un sistema inform tico: Planicaci n esa o trat gica, An lisis, Dise o, Generaci n de programas. e a n o Workbench: son conjuntos de herramientas que dan soporte a la automatizaci n del proceso o completo de desarrollo de un sistema inform tico. Permiten cubrir el ciclo de vida completo y a su resultado es un ejecutable y su documentaci n. o Las fases del desarrollo de software que automatizan: Upper CASE: Planicaci n Estrat gica y Requerimientos de Desarrollo Funcional. o e Middle CASE: An lisis, Dise o y el Control de Calidad. a n Lower CASE: Construcci n, incluyendo la generaci n de c digo y las pruebas (test). o o o La arquitectura de las aplicaciones que producen Segun su funcionalidad: De Ingeniera de la Informaci n: Proporcionan un metamodelo del que se derivan sistemas de o informaci n especcos. Su objetivo es representar objetos de datos de negocio, sus relaciones o y la forma en la que inuyen entre las distintas areas de negocio de la Empresa. De Modelado y Administraci n de procesos y empresas: Se emplean para representar los eleo mentos clave del proceso, de modo que sea m s comprensible. Pueden proporcionar vnculos a con otras herramientas que apoyen otras actividades del proceso ya denidas. De Estimaci n, Planicaci n y Administraci n de proyectos: Estimaci n: Estiman el esfuerzo, o o o o la duraci n del proyecto y el n mero recomendado de personas. Planicaci n: capacitan al o u o administrador para denir todas las tareas del proyecto, crear una red de tareas, representar las interdependencias entre tareas, etc. Administraci n de Proyectos: extensi n de las herramientas o o de planicaci n para poder realizar un seguimiento del Proyecto. o 14

Tecnologas CASE De An lisis de riesgos: Para identicar los riesgos potenciales y desarrollar un plan que mita igue, monitorice y administre esos riesgos. Capacitan al administrador para construir una gua detallada de riesgos que ayude en su identicaci n y an lisis. o a De Seguimiento de requisitos: Proporcionan un enfoque sistem tico para el aislamiento de los a requisitos, comenzando por la solicitud del cliente de una propuesta o especicaci n. Las hero ramientas tpicas de este tipio combinan una evaluaci n de textos mediante una interacci n o o humano-SGBD que almacena y categoriza los requisistos del sistema. o n o M tricas: Proporcionan una mejor visi n de la calidad del dise o o del c digo. Muchas here ramientas m tricas avanzadas mantienen una Base de Datos que permite calicar las medidas e del producto particular frente a los valores medios de la industria y frente a rendimientos particulares anteriores. De Documentaci n: Muchas organizaciones invierten mucho tiempo y esfuerzo en el desarrollo o de documentos. Estas herramientas posibilitan la edici n, visualizaci n e impresi n de doco o o umentos. Algunos documentadores autom ticos incluyen, adem s, opciones de maquetaci n, a a o generaci n de ndices, etc. o De Aseguramiento de la calidad: Permiten automatizar las tareas que mejoren la calidad del software: an lisis de calidad, control de compatibilidad, control de conexiones, control de sea guridad y validaci n de la calidad. o De Gesti n de la conguraci n del Software: Permiten gestionar de manera automatizada los o o diversos estados por los que pasa el software; es por ello que son el n cleo de muchos sistemas u CASE. Llevan a cabo 5 tareas principales: 1. 2. 3. 4. 5. Identicaci n de los elementos de conguraci n. o o Control de versiones. Control de cambios. Auditora. Contabilidad de estados.

De An lisis y Dise o: Son de las m s antiguas y m s usadas. Ayudan al ingeniero de software a n a a a crear modelos del sistema que hay que construir, eliminando posibilidades de error. En ocasiones se subdividen en herramientas para el dise o funcional (que describen los datos y pron cesos con diagramas) y en herramientas para el dise o detallado (generadores autom ticos de n a especicaciones, simuladores de transiciones, etc.). De Prototipado y Simulaci n: Se emplean cuando se utiliza un ciclo de vida mediante prototio pos. Permiten acceder al comportamiento real de un sistema antes de construirlo. Permiten al ingeniero crear simulaciones para que el cliente se haga una idea del futuro comportamiento y funcionamiento antes de la verdadera implementaci n. o Para la Generaci n de aplicaciones y componentes: Muchas se est n convirtiendo en generadores o a de prototipos especcos. Estas herramientas se clasican en generadores de c digo, gener o adores de macros, generadores de esquemas de BD, generadores de interfaces de usuario, etc. De Programaci n: Compiladores, editores, depuradores, entornos de programaci n visual (para o o 3 o GUIs), entornos RAD , lenguajes de cuarta generaci n (4GL), etc. De Pruebas (CAST4 ): Sirven para gestionar pruebas de software: denir requisitos y objetivos de las pruebas, dise ar las pruebas, construir entornos de ejecuci n de las pruebas, ejecutarlas n o y para evaluar de pruebas. Para la Validaci n: Permiten automatizar y vericar el cumplimiento de las especicaciones. o De Ingeniera Inversa y Reingeniera: Procesan c digo fuente para producir otro tipo de ele o mento software. Existen muchas para entornos COBOL, FORTRAN SGBD. Son muy utiles cuando la documentaci n es inexistente o est desfasada. Existen varios tipos: o a Recuperadores de dise o a partir del c digo fuente. n o Redocumentadores: a partir del c digo fuente generan diagramas y otros documentos. o
3 Entornos

de Desarrollo R pido de Aplicaciones. a

15

Herramientas y Entornos de Programaci n o Analizadores de c digo o Descompiladores: a partird el c digo objeto obtienen el c digo fuente o o Para el Mantenimiento: Herramientas de Navegaci n (permiten la b squeda r pida y f cil de las o u a a partes del software que interesan. Identican d nde se usan unas variables, qu m dulos utilizan o e o otros m dulos, visualizan las estructuras de datos...) y herramientas para el perfeccionamiento o del c digo (reformateadores de c digo y reestructuradores de c digo). o o o

2.3.

Entornos CASE integrados (I-CASE)

El verdadero poder de las tecnologas CASE se obtiene a trav s de la integraci n: e o Posibilitan la compartici n de informaci n entre varias herramientas del entorno. Esto es muy util o o para evitar la reintroducci n de datos en cada herramienta (y as evitar errores humanos al reintroo ducir datos), para facilitar la documentaci n en todas las etapas del desarrollo, y sobre todo para proo porcionar un unico repositorio de base de datos para todas las herramientas (dise o, representaci n, n o etc). Permiten la detecci n de cambios en elementos de informaci n relacionados. o o Permiten el control de versiones Permiten el acceso directo a cualquiera de las herramientas. Permiten mantener la consistencia en el aspecto y la interacci n de la interfaz. o

2.3.1.

Componentes de un I-CASE

Podemos visualizarlos de forma gr ca en la gura 2.1. Un I-CASE se compone de: a Presentaci on: Dene c mo el usuario va a ver todas las herramientas del entorno integrado: men s, o o u mensajes de ayuda y de error... Interfaz de usuario: Establece una GUI5 particular para todo el conjunto: administrador de ventanas, aspecto de botones, etc. Administrador de tareas: Permite al desarrollador denir, ejecutar y sincronizar distintas tareas que requieren cooperaci n. o Servicios de integraci n de datos: Permite comunicar las herramientas con el repositorio. o Repositorio: Provee de los datos comunes y sirve de enlace entre todas las herramientas. Debe soportar cualquier tipo de objeto y las relaciones entre ellos. Servidor de mensajes: Provee de un canal de comunicaci n entre las herramientas y el ambiente o CASE.

2.3.2.

Benecios

Los I-CASE nos ofrecen multitud de benecios pero los m s importantes son: a Interfaz de usuario comun.
5 Interfaz

Gr ca de Usuario a

16

Tecnologas CASE

Figura 2.1: Componentes de los I-CASE

Interfaz de herramienta: herramientas verticales (partes del ciclo de vida del proyecto) y herramientas horizontales (procesos de mantenimiento, como CVS6 . Control y comunicaci n de herramientas: facilitan la comunicaci n entre herramientas a trav s de o o e mensajes y eventos, lo que posibilita la ejecuci n concurrente de varias tareas con varias herramientas. o Administraci n de entregables: los entornos I-CASE deben administrar el espectro completo de o entregables (especicaciones, c digos fuente, archivos, etc), y as posibilitar la denici n de objetos o o de tama o arbitrario, de asociar objetos en colecciones, etc. n Portabilidad del Sistema Operativo: lo ideal es disponer de independencia con la plataforma de ejecuci n. o Administrador de Conguraci n: debe ofrecer facilidades para administrar el compilador y los o procesos ligados, as como administrar las versiones de los componentes. Trazabilidad: un buen I-CASE debe dar soporte a la habilidad de trazar el sistema completo mediante documentaci n de an lisis y dise o. Tambi n debe ofrecer ayuda a mantener la documentaci n o a n e o acorde con las versiones, y a asegurar la calidad del sistema cuando se cumplan los requerimientos y especicaciones. Administraci n de contexto: hacer vistas de una parte concreta del proyecto (Base de Datos, c dio o gos...) Un programador debe poder ver la parte que le corresponde, es decir, su subconjunto de espacio de trabajo, sin tener que impactar en el resto del proyecto. Transparencia en la red: debe facilitar el trabajo en forma distribuida, accediendo a los datos de forma transparente al usuario, as se puede trabajar en un sistema robusto de red. Teniendo la cong uraci n de cada usuario bajo control. Adem s debe proveer de herramientas de depuraci n remota. o a o

2.3.3.

Opciones de Integraci n o

Existen diferentes posibilidades en cuanto a la integraci n de las herramientas en un I-CASE: o Herramientas CASE separadas: en este caso los enlaces entre herramientas se realizan de forma manual, y las salidas suelen ser de texto sobre papel. Intercambio de datos Punto-a-Punto: Las herramientas exportan datos en un chero. Los constructores de las herramientas CASE realizan puentes entre las herramientas. Acceso comun a las herramientas: El usuario puede ver varias herramientas simultaneamente, a trav s de una interfaz de usuario com n. Los procesos de transferencia son sencillos. e u
6 Sistemas

de Control de Versiones

17

Herramientas y Entornos de Programaci n o

Figura 2.2: Integraci n punto a punto o

Figura 2.3: Integraci n con acceso com n a las herramientas o u

Gesti n de datos comun: Los datos de varias herramientas son mantenidos en una sola Base de o Datos.

Figura 2.4: Integraci n con gesti n de datos com n o o u

Integraci n completa. Gesti n de Metadatos: Las distintas herramientas comparten unos metadatos o o a trav s de un mecanismo de disparo. En esos metadatos se denen objetos, relaciones y dependencias e entre objetos, ujos de trabajo, etc.

2.4.

Adopci n de herramientas CASE o

Cuando una organizaci n quiere adoptar una herramienta CASE, debemos considerar el proceso de o selecci n de la herramienta (ya que no hay 2 organizaciones iguales), los pre-requisitos necesarios (debe o haber comprensi n del prop sito de las herramientas que se propongan en el ambiente de selecci n), y el o o o conocimiento de la organizaci n (para adaptarnos a la personalidad e infraestructura de la misma). o En el proceso de adopci n, siempre nos enfrentamos a diversos problemas: o Deciencias de las herramientas CASE: 18

Tecnologas CASE

Figura 2.5: Integraci n completa o

Soporte parcial del ciclo de vida. Incompatibilidad con otras herramientas. Escasa integraci n entre herramientas. o Funcionalidad deciente en entornos multiusuario. Alto coste. No s lo por la herramienta sino por la plataforma que exige. o Deciencias de la propia organizaci n: o Mala actitud de los directivos, que pretenden introducir una tecnologa CASE como salvaci n o a todos sus males de desarrollo, sin contar con una buena base metodol gica. o Infravaloraci n del esfuerzo requerido por parte del personal. As como econ mico. o o Inadecuada formaci n. o El no medir la productividad o rentabilidad resultante de la aplicaci n de la tecnologa. o

2.4.1.

Proceso de evaluaci n y selecci n de herramientas o o

1. Proceso de iniciaci n: Se jan los objetivos y criterios de la evaluaci n y selecci n, y se planica el o o o proceso general. 2. Proceso de estructuraci n: Se elabora un conjunto de requisitos, que servir n para la evaluaci n. Se o a o identican las herramientas CASE candidatas. e a o 3. Proceso de evaluaci n: Se producen los informes t cnicos que servir n para la selecci n. o 4. Proceso de selecci n: Se ultiman los criterios y se dene el algoritmo de selecci n. En base a los o o resultados del proceso de evaluaci n se determina el mejor candidato. o

19

Herramientas y Entornos de Programaci n o

20

Entorno de desarrollo .NET

Captulo 3

Entorno de desarrollo .NET

3.1.
3.1.1.

Caractersticas generales de .NET

Qu es .NET? e

.NET es una plataforma de desarrollo, despliegue y ejecuci n de aplicaciones orientadas a servicios o sobre entornos altamente distribuidos. Cubre todas las capas de desarrollo de software, y es el resultado de la conuencia de dos proyectos: El primero tena como objetivo la mejora del desarrollo sobre Windows, mejorando especialmente el modelo COM. El segundo es NGWS, que tena como objetivo la creaci n de una plataforma para el desarrollo de o software como servicio.

3.1.2.

Objetivos de la tecnologa .NET

La tecnologa .NET proporciona un modelo de programaci n simple y consistente, liberando al pro o gramador de las cuestiones de infraestructura el framework .NET se encarga de gestionar la memoria, los hilos, etc. Los principales objetivos de la tecnologa .NET son los siguientes: 1. Proporcionar integraci n entre diferentes lenguajes. o 2. Proporcionar un mecanismo de errores consistente. 3. Proporcionar un mecanismo de seguridad avanzado. 4. Disponer de un sistema de despliegue simple: con GUIS, sin registro, etc. 5. Proporcionar una ejecuci n multiplataforma: gracias al lenguaje intermedio de Microsoft (MSIL). o 6. Proporcionar soporte para arquitecturas fuertemente acopladas y debilmente acopladas.

3.1.3.

Componentes principales de .NET

Ver la gura 3.1. 21

Herramientas y Entornos de Programaci n o

Figura 3.1: Componentes de la tecnologa .NET

3.1.4.

Lenguaje comun en tiempo de ejecuci n (CLR) o

El CLR puede considerarse el n cleo de .NET, desempe ando el papel de m quina virtual es el que u n a posibilita la integraci n entre varios lenguajes. El CLR est formado por 3 componentes (que estudiaremos o a despu s): Un sistema de tipos com n (CTS), un Sistema de metadatos, y un Sistema de ejecuci n. e u o El CLR es muy util. Un chero fuente puede contener la denici n de un tipo de objeto X. Al compilar o dicho chero, se genera un chero con c digo intermedio MSIL y metadatos (entre los que se encontrar n o a los correspondientes al tipo de objeto X). Pues bien, esos metadatos pueden ser utilizados para importar dicho tipo en otro chero de c digo (incluso de otro lenguaje). o Entre los servicios proporcionados por el CLR a las aplicaciones .NET se encuentran los siguientes: 1. Cargar y ejecutar el c digo MSIL. o 2. Aislar la memoria de las aplicaciones, de forma que el c digo de un proceso no pueda acceder al o c digo o datos de otro. o 3. Garantiza la robustez del c digo mediante la implementaci n de un sistema de tipos com n (el CTS1 ). o o u 4. Convierte el c digo intermedio MSIL a c digo nativo, utilizando t cnicas de compilaci n Just In o o e o Time (JIT). 5. Gesti n autom tica de memoria. o a 6. Asegurar la seguridad en los accesos a los recursos. 7. Manejo de excepciones, incluso escritas en diferentes lenguajes. 8. Interoperabilidad con c digo no gestionado (como DLLs y objetos CCM). o 9. Soporte de servicios a los desarrolladores (como la depuraci n). o
1 Common

Types System

22

Entorno de desarrollo .NET Sistema de tipos comun (CTS) Est formado por un amplio conjunto de tipos y operaciones que se encuentran presentes en la mayora a de lenguajes de programaci n. Dene c mo se declaran, utilizan y gestionan los tipos en el CLR. Y es lo o o que posibilita la interoperabilidad entre diferentes lenguajes de programaci n. o En resumen, ofrece las siguientes funciones: Establece un framework que permite la integraci n de lenguajes, seguridad de tipos y ejecuci n de o o c digo de alto rendimiento. o Proporciona un modelo orientado a objetos que soporta muchos lenguajes de programaci n. o Dene una serie de reglas que los lenguajes deben seguir para permitir la interoperabilidad. Podemos ver los componentes del CTS en la gura 3.2.

Figura 3.2: Componentes del sistema de tipos com n (CTS) u Denici n de tipos o Una denici n de un tipo constituye un tipo nuevo a partir de los tipos existentes. Dentro de la denici n o o de un tipo pueden denirse los siguientes miembros: Eventos: incidentes a los que se puede responder. Campos: variables Tipos anidados: denen un tipo dentro de la denici n del tipo que los contiene. o M todos: operaciones disponibles para un tipo. e Propiedades: son la alternativa a las tradicionales formas de acceder a un atributo. Tipos referencia Los tipos referencia son la combinaci n de una localizaci n y una secuencia de bits. Las localizaciones o o denotan las areas de memoria que pueden ser utilizadas, y poseen seguridad de tipos (para s lo poder o asignarle un tipo compatible). Existen los siguientes tipos de referencias: 23

Herramientas y Entornos de Programaci n o Clases: como en cualquier lenguaje orientado a objetos. Delegados: son objetos con una nalidad similar a los punteros de C++. Arrays Interfaces: son especicaciones parciales de un tipo. Punteros: el CTS soporta algunos tipos de punteros: punteros gestionados, punteros no gestionados, y punteros no gestionados a funciones. Sistema de metadatos Los metadatos son informaci n binaria que describe los tipos implementados por un programa. El siso tema de metadatos permite almacenar dichos metadatos junto a los tipos a los que se reeran, en tiempo de compilaci n, y obtenerlos en tiempo de ejecuci n. o o Los benecios de la utilizaci n de metadatos son los siguientes: o Proporcionan cheros de c digo autodescriptivos, eliminando la necesidad del registro. o Proporcionan la informaci n necesara para conseguir la interoperabilidad entre distintos lenguajes. o Proporcionan la informaci n que necesita el sistema para la gesti n de objetos. o o Permite a .NET las invocaciones remotas. Mediante los atributos es posible especicar aspectos m s detallados sobre el comportamiento del a programa en tiempo de ejecuci n. o .NET almacena el c digo MSIL, junto con los metadatos, en una unidad autodescriptiva denominada o ensamblado. Sistema de ejecuci n o La traducci n de MSIL a c digo nativo de la CPU es realizada por un compilador JIT2 o Jitter. El Jitter o o va conviertiendo din micamente el c digo MSIL en c digo nativo seg n sea necesario. La compilaci n JIT a o o u o tiene en cuenta el hecho de que algunas porciones de c digo no ser n llamadas durante la ejecuci n, por o a o lo que en lugar de infertir tiempo y memoria en convertir todo el c digo, unicamente convierte el que es o necesario durante la ejecuci n, almacen ndolo por si volviera a ser necesario en el futuro. o a El recolector de basura del sistema de ejecuci n debe eliminar los objetos de la memoria cuando no van o a ser referenciados nunca m s. El proceso de recolecci n de basura puede ser lanzado autom ticamente por a o a el CLR o invocado explcitamente. Para llevar a cabo la tarea de saber que objetos pueden ser borrados, el recolector mantiene las referencias raices (aquellos objetos referenciados directamente por la aplicaci n), y obtiene, a su vez, todos los o objetos referenciados por cada una de esas raices, y as sucesivamente. Los objetos por los que no haya pasado en este recorrido son los que puede borrar.

3.1.5.

Especicaciones del lenguaje comun CLS

El CLR, mediante el sistema de tipos com n, o CTS, y los metadatos, proporciona la infraestructura u necesaria para lograr la interoperabilidad entre lenguajes. Todos los lenguajes siguen las reglas denidas en el CTS para la denici n y uso de los tipos, y los metadatos denen un mecanismo para el almacenamiento o y recuperaci n de la informaci n de dichos tipos. o o
2 Just

In Time

24

Entorno de desarrollo .NET Pese a esto, no hay ninguna garanta de que un desarrollador de un lenguaje cualquiera dena un tipo que luego pueda ser utilizado por otros desarrolladores. Para asegurar que el c digo escrito en un lenguaje o sea accesible desde otros se ha denido la Especicaci n del Lenguaje Com n o CLS (Common Language o u Specication) que establece un conjunto mnimo de caractersticas que deben soportarse para asegurar la interoperabilidad, siendo dicho conjunto de caractersticas mnimas un subconjunto del CTS. El CLS se ha dise ado para ser lo sucientemente grande como para que incluya las construcciones m s n a comunes de los lenguajes, y lo sucientemente peque o para que la mayora de lenguajes lo cumplan. n

3.2.
3.2.1.

Ensamblados (Assemblies)
Introducci n a los Ensamblados o

Los ensamblados son colecciones de tipos y recursos, que proporcionan la informaci n que el CLR o necesita sobre las implementaciones de dichos tipos. Los ensamblados pueden clasicarse, atendiendo a 3 factores, en: Ensamblados est ticos o din micos: los est ticos son generados en tiempo de compilaci n, y almaa a a o cenados en disco. Los din micos se generan en tiempo de ejecuci n y son ejecutados desde memoria, a o pudiendo almacenarse en disco tras la ejecuci n. o Ensamblados multichero o con un unico chero. Ensamblados privados o compartidos: los ensamblados privados se utilizan unicamente en la aplicaci n para la que han sido desplegados, mientras que los compartidos pueden ser utilizados por m s o a aplicaciones.

3.2.2.

Caractersticas de los Ensamblados

1. Contienen el c digo intermedio (MSIL) que ser ejecutado por el runtime, as como los metadatos o a generados por el compilador, y el maniesto del ensamblado. 2. Son unidades autodescriptivas, sin dependencia alguna del registro de Windows. 3. Denen una frontera de encapsulaci n para los tipos que contienen. La identidad de un tipo queda o en parte denida por el ensamblado al que pertenece, por lo que dos tipos con el mismo nombre, denidos en ensamblados distintos, se consideran independientes. 4. El maniesto del ensamblado contiene los metadatos utilizados para la obtenci n de los tipos y reo cursos, as como las dependencias con otros ensamblados. 5. Un ensamblado es la unidad mnima versionable. La poltica de versiones se aplica sobre todos los tipos y recursos contenidos en el ensamblado. 6. Los ensamblados constituyen la unidad de despliegue, es decir, al arrancar una aplicaci n s lo los o o ensamblados llamados al inicio tienen que estar presentes, pudiendo obtener el resto bajo demanda. 7. Permiten el aislamiento de aplicaciones. La existencia de ensamblados privados, adem s, favorece el a aislamiento de aplicaciones, de forma que los cambios realizados no afecten al comportamiento del resto. 8. Los ensamblados denen un contexto de seguridad. En .NET, las medidas de seguridad son tomadas a nivel de ensamblado, quedando denidas en el maniesto de los mismos. 9. Soportan ejecuci n de m ltiples versiones simult neas (slide-by-side execution). o u a 25

Herramientas y Entornos de Programaci n o

3.2.3.

Estructura de un ensamblado est tico a

En general, la estructura l gica de un ensamblado est tico consta de 4 elementos: o a 1. El maniesto del ensamblado: contiene los metadatos del ensamblado. 2. Los metadatos de los tipos que contiene el ensamblado. 3. El c digo intermedio (MSIL). o 4. Un conjunto de recursos. Estos 4 elementos pueden estar dispuestos en un unico chero o en varios. Estos cheros, cuando contienen metadatos (y a veces c digo MSIL tambi n), son denominados m dulos. o e o Estructura de ensamblados de un s lo chero o Un ensamblado puede estar formado por un unico m dulo, estableci ndose una correspondencia uno a o e uno entre ensamblado y binario.

Figura 3.3: Estructura de ensamblados de un solo chero

Estructura de ensamblados multichero En los ensamblados compuestos por varios cheros fsicos, s lo un m dulo contiene el maniesto, o o mientras que el resto de m dulos s lo contienen metadatos sobre los tipos y opcionalmente c digo intero o o medio. Los m dulos que componen un ensamblado multichero est n relacionados l gicamente entre s por o a o medio de la informaci n del maniesto, el cual referencia a los cheros que componen el ensamblado. o

3.2.4.

Maniesto de un Ensamblado

El maniesto de los ensamblados es un conjunto de metadatos que describe c mo est n relacionados o a los elementos contenidos en el ensamblado (ya sea un ensamblado de uno o varios cheros). El maniesto puede ser almacenado en un chero portable (.exe o .dll), junto a metadatos de tipos y c digo MSIL, o en un o chero portable que unicamente contiene el maniesto (esto puede darse s lo en ensamblados multichero). o El maniesto de un ensamblado contiene los siguientes elementos: 1. Identidad: un nombre, un n mero de versi n, e informaci n sobre el idioma/cultura del ensamblado. u o o 2. Lista de cheros del ensamblado: para cada chero se almacena su nombre y un hash criptogr co a con el contenido del chero. 26

Entorno de desarrollo .NET

Figura 3.4: Estructura de ensamblados multichero

3. Informaci n sobre los ensamblados referenciados: una lista con la identicaci n de los ensamblao o dos referenciados de los que depende est ticamente. a 4. Informaci n sobre los tipos y recursos exportados: informaci n relativa al mapeo de los tipos y o o los cheros fsicos que contienen sus metadatos e implementaci n, lo que es utilizado en tiempo de o ejecuci n. o 5. Permisos solicitados: son tres grupos: los permisos requeridos para ejecutarse, los deseables, y los que el autor nunca quiere que le sean concedidos.

3.2.5.

Tipos de Ensamblados

Existen dos tipos de ensamblados: los privados y los compartidos. No existe diferencia estructural entre ambos tipos, sino que la diferencia radica en el uso que se le da a los mismos. Realmente las diferencias residen en las convenciones de nombrado, poltica de versiones y aspectos de despliegue. Ensamblados privados Nombrado El nombre de cada ensamblado, dentro de una misma aplicaci n, debe ser unico. o Poltica de versiones Ignorada. Despliegue Los ensamblados privados son desplegados en el directorio local de la aplicaci n o en o uno de sus subdirectorios. Ensamblados compartidos Nombrado Utilizan los denominados nombres fuertes. Los nombres fuertes garantizan la unicidad del nombre (empleando claves criptogr cas, una privada y otra p blica). Adem s previenen contra a u a la suplantaci n del nombrado (no se puede construir un ensamblado casero y cargarlo en lugar de o la versi n de la aplicaci n). Un nombre fuerte est formado por un nombre amigable, un n mero de o o a u versi n, una clave p blica y una rma digital. o u Poltica de versiones El control de versiones es de gran importancia. La poltica de versiones consiste en informaci n de la versi n, la cual debe ajustarse a unas polticas. o o 27

Herramientas y Entornos de Programaci n o Despliegue Los ensamblados compartidos son desplegados en la cach global de ensamblados (GAC). e El mecanismo de almacenamiento de varias versiones de un mismo ensamblado es realizado autom ticamente. a

3.2.6.

Ejecuci n simult nea de varias versiones de un Ensamblado o a

El runtime posee la habilidad de ejecutar m ltiples versiones de un mismo ensamblado de forma siu mult nea. El runtime de .NET, concretamente permite esta ejecuci n no s lo en la misma m quina, sino a o o a tambi n dentro del mismo proceso. e

3.3.
3.3.1.

Administraci n de datos con ADO.NET o

ADO.NET

ADO.NET es una tecnologa de acceso a datos, basada en los objetos ADO3 anteriores. Es un conjunto de clases que exponen servicios de acceso a datos al programador de .NET. Emplea XML como formato de transmisi n de datos. o ADO.NET emplea un modelo de acceso pensado para entornos desconectados. Esto quiere decir que la aplicaci n se conecta al origen de datos, hace lo que tiene que hacer, la carga en memoria y se desconecta. o Con ADO.NET se elimina la necesidad de que el receptor de los datos sea un objeto COM, tal y como ocurra con ADO. Las principales ventajas de ADO.NET frente a ADO son la interoperabilidad, la escalabilidad mejorada, y el soporte para tipado fuerte. Podemos dividir el modelo de objetos de ADO.NET en 2 niveles: conectado y desconectado. Nivel conectado de ADO.NET Este nivel est formado por los denominados proveedores gestionados, o Manager Providers, que son a utilizados para abrir conexiones con las bases de datos y ejecutar comandos sobre ellas. Este nivel es similar a la infraestructura existente del ADO cl sico. a ADO.NET proporciona dos tipos de proveedores: un proveedor de SQL (para servidores SQL de Microsoft), y un proveedor OLEDB (para bases de datos de Oracle, Access, etc.). Nivel desconectado de ADO.NET Est constituido por los denominados DataSets, que son conjuntos de datos que representan un conjuna to de tablas en memoria. Al tratarse de un modelo desconectado, es posible crear una serie de tablas en un DataSet o modicar los datos del mismo sin que la fuente de datos tenga constancia de los cambios. Explcitamente podemos actualizar el contenido de la base de datos con el contenido del DataSet, en cualquier momento. Un DataSet puede ser manipulado de forma program tica, es decir, creando en el una base de datos a desde cero; pero tambi n puede ser cargado con los datos provenientes de una conexi n a un proveedor e o gestionado, o a una fuente de datos XML.

3.3.2.

Integraci n de ADO.NET con XML o

La integraci n del ADO cl sico con XML se basaba unicamente en que este posea una interfaz para o a la entrada y salida de datos en XML. Sin embargo, ADO.NET proporciona un soporte total de XML co3 Objectos

de Datos ActiveX

28

Entorno de desarrollo .NET mo representaci n de datos, de forma que los datos obtenidos de una fuente de datos son representados o internamente y transmitidos como XML. Los DataSets utilizan un esquema XML denominado XSD (XML Shema Denition) para representar la estructura de tablas y relaciones que contiene, de modo que los datos del DataSet son codicados de acuerdo a dicho esquema. Por ultimo, a adir que la integraci n de ADO.NET con XML resulta muy util para la transmisi n de n o o datos entre las distintas capas de una aplicaci n. o

3.3.3.

Espacio de nombres para ADO.NET

System.Data: consiste en las clases que constituyen la arquitectura ADO.NET, que es el m todo e primario de acceso a los datos. System.Data.Common: clases que comparten los proveedores de datos .NET Framework. Dichos proveedores describen una colecci n de clases que se utiliza para obtener acceso a un origen de o datos. System.Data.OleDb: clases que componen el proveedor de datos de .NET Framework para orgenes de datos compatibles con OLE DB. System.Data.SqlClient: clases que conforman el proveedor de datos de .NET Framework para SQL Server, que permiten conectarse a orgenes de datos SQL Server 7.0. System.Data.SqlTypes: clases de tipos de datos nativos de SQL Server. System.Data.OracleClient: clases que componen el proveedor de datos de .NET Framework para Oracle. Estas clases permiten el acceso a orgenes de datos Oracle en el espacio administrado.

3.3.4.

Elementos fundamentales de ADO.NET

ADO.NET utiliza algunas clases de objetos ADO, como las clases Connection y Command, y agrega objetos nuevos. Algunos de los nuevos objetos clave de ADO.NET son DataSet, DataReader y DataAdapter. Connection: para conectar a una base de datos. Command: para ejecutar comandos SQL en una base de datos. DataReader: para leer una secuencia de registros de datos hacia delante desde un origen de datos SQL Server. DataSet: para almacenar datos sin formato, datos XML y datos relacionales, as como para congurar el acceso remoto y programar sobre datos de este tipo. DataAdapter. Para insertar datos en un objeto DataSet y reconciliar datos de la base de datos.

3.4.
3.4.1.

.NET frente a otras tecnologas

.NET vs COM

.NET supera a COM, es mucho m s simple y consigue eliminar las deciencias de este. a Uno de los problemas de COM es la limitaci n de su sistema de informaci n sobre tipos. Adem s, en o o a COM no existe una forma est ndar de representar la informaci n de tipos, sino que puede representarse en a o formato de texto mediante interfaces IDL o en forma binaria mediante libreras. 29

Herramientas y Entornos de Programaci n o El sistema de informaci n de tipos de COM tampoco mantiene la informaci n de dependencias de o o componentes externos. El sistema de metadatos sobre los tipos de .NET mejora notablemente al sistema del modelo COM. Mediante los metadatos se consigue un unico sistema de informaci n sobre los tipos, manteniendo adem s o a informaci n sobre las dependencias de un componente. o .NET elimina el denominado inerno de las DLLs4 que va asociado al modelo COM. Los problemas de COM que generaban inconsistencias en el registro, causados por la separaci n del o componente y su descripci n, han sido solucionados en .NET mediante unidades autodescriptivas, los eno samblados.

3.4.2.

.NET vs COM+

COM+ es una mejora del Servidor de Transacciones de Microsoft (MTS). COM+ ampli los servicios o proporcionados por MTS y mejor la interoperabilidad con el modelo COM. o Al contrario de lo que sucede con COM, no se puede decir que .NET vaya a sustituir a COM+ como sistema proveedor de servicios de componentes, al menos de momento, ya que .NET carece de dichos servicios por s mismo, y requiere de interoperabilidad con COM+ para ello. Este es uno de los aspectos por los que .NET denota cierta inmadurez, pues no ofrece por s sola una serie de servicios que s estan presentes en los modelos de componentes J2EE y CORBA, teniendo que recurrir a un modelo anterior.

3.4.3.

.NET vs J2EE

Las plataformas .NET y J2EE son muy similares entre s, manteniendo bastantes puntos comunes, y cuyas 2 diferencias principales son: J2EE es una plataforma que utiliza unicamente el lenguaje Java, es multiplataforma y con m ltiples u proveedores de tecnologa. .NET es multilenguaje, est dise ada para una unica plataforma, Windows, y con un unico proveedor, a n Microsoft. En cuanto al modelo de componentes, con propiedades y eventos, ambas plataformas son semejantes (en J2EE los componentes vienen dados por JavaBeans, y en .NET vienen incluidos en el sistema com n de u tipos). Ambos modelos tambi n poseen sistemas de acceso remotos (RMI en J2EE y el framework remoto e en .NET), siendo en este aspecto algo m s potente .NET. Tambi n es algo m s potente en el acceso a fuentes a e a de datos, pues introduce la posibilidad de trabajar en modo desconectado con los denominados DataSet y est altamente integrado con XML. a Ambas plataformas soportan el uso de delegados (skinny clients): J2EE posee los servlets y las p ginas a JSP, mientras que .NET posee ASP.NET. Para el desarrollo de clientes pesados (fat clients), J2EE tiene Java Swing, y .NET WinForms. Ambos sistemas son similares, y sus peque as diferencias radican en el uso de eventos, que en Java se realiza n mediante clases internas y en .NET mediante delegados. En cuanto al despliegue, ambos modelos son similares. En ambas plataformas los empaquetados contienen un maniesto en el que expresan sus dependencias externas, as como una serie de metainformaci n. o La mayor diferencia entre .NET y J2EE viene dada por el runtime de ambas plataformas. La JVM (M quina Virtual de Java) ha sido dise ada para proporcionar soporte multiplataforma a Java, mientras que a n el CLR de .NET ha sido dise ado, adem s de para ser multiplataforma, para ser independiente del lenguaje. n a
4 Problemas relativos al manejo de versiones, que surgen cuando una DLL o componente COM es compartido por varias aplicaciones.

30

Entorno de desarrollo .NET Comparando los c digos intermedios (el bytecode de Java y el MSIL de .NET), MSIL es de mayor o nivel e introduce la seguridad de tipos, pudiendo ser vericado el c digo MSIL antes de su ejecuci n, para o o garantizar su seguridad. La ejecuci n del c digo intermedio sigue esquemas distintos: en Java los bytecodes o o son interpretados, mientras que el CLR compila el c digo MSIL, obteniendo un mayor rendimiento. o Donde J2EE supera ampliamente a .NET es en los servicios de componentes, tales como persistencia autom tica, transacciones, etc. Adem s, .NET no tiene servicios propios, sino que los toma de COM+, lo a a que supone un factor en contra. Si establecemos una comparaci n entre las herramientas de desarrollo, J2EE tiene una amplia gama de o IDEs de distintos proveedores, mientras que VisualStudio .NET es la unica herramienta de desarrollo para .NET. A pesar de esto, la integraci n de VisualStudio .NET es mayor que la de las herramientas de J2EE, a o pesar de que algunas son igual o m s potentes que VS. a

3.4.4.

.NET vs CORBA

La plataforma .NET es m s amplia que la especicaci n CORBA, pues cubre algunos aspectos no a o tratados por esta (como las interfaces de usuario). .NET llega mucho m s lejos que CORBA, adem s, en lo a a que se reere a la integraci n entre distintos lenguajes, pues en .NET una clase puede incluso heredar de o otra escrita en otro lenguaje. CORBA carece de portabilidad en la implementaci n (a no ser que emplee Java, claro). o .NET dispone de un framework de objetos remotos, pero en este punto el framework CORBA supera ampliamente al de .NET, como es de esperar. Adem s, CORBA es m s potente y extensible que .NET, sobre a a todo en lo relativo a las polticas de conguraci n de los objetos remotos. o Los servicios web proporcionados por .NET permiten un desarrollo de aplicaciones distribuidas mucho m s ligero que el impuesto por CORBA o por los objetos remotos de .NET, pues bastara tener una librera a SOAP o un parser XML para acceder al servicio web (veremos esto en el captulo siguiente). A favor de CORBA est el hecho de que se trata de una especicaci n est ndar, consensuada por las a o a distintas organizaciones y empresas que forman el OMG5 . Si CORBA no ha alcanzado la difusi n que se o mereca es por la ausencia de entornos de desarrollo como VisualStudio.

3.5.
3.5.1.

El entorno Visual Studio .NET

Caractersticas generales

Visual Studio .NET es un entorno integrado de desarrollo, independiente del lenguaje de programaci n o incluso permite combinar varios lenguajes compartiendo una unica interfaz. Ofrece un mecanismo potente de depuraci n extremo a extremo de las aplicaciones, independientemente o del n mero de proyectos, procesos y procedimientos. u A trav s de un sistema de ventanas de ocultaci n autom tica (Auto-Hide), Visual Studio .NET nos e o a ofrece numerosos servicios, que estudiaremos a continuaci n: o Ayuda din mica (Dynamic Help) a Su objetivo es ofrecernos la informaci n correcta en el momento oportuno, a trav s de documentaci n o e o relacionada en funci n de las caractersticas y tecnologas. o Por ejemplo, si abrimos el IDE, sin cargar ninguna aplicaci n, el entorno ofrece enlaces de inter s para o e crear una aplicaci n, elegir plantillas, etc. Conforme se avanza en el desarrollo de la aplicaci n, el IDE o o analiza parte de la misma y nos ofrece contenidos apropiados.
5 Object

Management Group

31

Herramientas y Entornos de Programaci n o Editor visual de p ginas web (Visual Web Page Editor) a Se trata de un editor de tipo WYSIWYG6 , que permite desarrollar webs din micas sin entrar a fondo en a el c digo HTML. o Ofrece algunas facilidades, como la compleci n de sentencias y etiquetas HTML, la comprobaci n de o o sintaxis XML, y el posicionamiento absoluto de elementos. Lista de tareas Permite marcar el c digo con comentarios relacionados con las tareas que se necesitan realizar. Estas se o analizan sint cticamente y se muestran en un formato tabular. a Esta caracterstica hace que resulte sencillo anotar el c digo de forma que, cuando uno mismo, o o cualquier miembro del equipo lo vea, sea capaz de conocer el estado del c digo con un mnimo esfuero zo. Explorador de objetos Conecta todos los objetos del sistema y proporciona informaci n detallada acerca de cada uno. A trav s o e de un sistema de ltrado podemos buscar la informaci n que necesitemos sobre los objetos. o Ventana de comandos Permite rapidez al proporcionar una unica lnea de acceso para buscar, explorar y ejecutar los numerosos elementos, tanto de dentro como de fuera del IDE. A trav s de esta ventana de comandos podemos realizar b squedas, explorar ventanas y elementos de e u la soluci n, ejecutar comandos, explorar el sitio web, y ejecutar programas externos. o

6 What

You See Is What You Get.

32

Captulo 4

Servicios Web
4.1.
4.1.1.

Introducci n a los Servicios Web o

Conceptos b sicos a

Los servicios web son m dulos de software que realizan tareas discretas o conjuntos de estas, a los que o se accede a trav s de una red (sobre todo la World Wide Web). Un ejemplo es el servicio de seguimiento de e paquetes de Federal Express, mediante el cual los clientes pueden examinar el estado de sus envos. Los servicios web publicados se describen de forma que los desarrolladores puedan localizarlos y determinar si se ajustan a sus necesidades. Un desarrollador puede crear una aplicaci n cliente que utilice o servicios web mediante llamadas a procedimientos remotos (RPC) o un servicio de mensajes. Desde hace tiempo existen mecanismos que hacen posible el acceso a funciones discretas de manera distribuida. Esto signica que la aplicaci n del servicio se estar ejecutando, respecto del cliente que lo o a consume, en cualquier punto de una red. Algunos ejemplos son: CORBA (Common Object Request Broker Architecture) Java RMI (Remote Method Invocation) Microsoft DCOM (Distributed Component Object Model) Sin embargo, el concepto de servicio web es bastante m s reciente, y b sicamente se diferencia en los a a protocolos empleados para hacer la comunicaci n. Estos tres mecanismos mencionados se basan en canales o y protocolos de conversaci n que no fueron ideados para la WWW. Por ello encuentran problemas con o dispositivos de encauzamiento y seguridad. Los servicios web utilizan SOAP (Simple Object Access Protocol) para la carga XML, y el protocolo HTTP para el transporte de los mensajes. Los mensajes SOAP son documentos XML que se envan entre el servicio web y la aplicaci n que efect a la llamada. Esta estandarizaci n hace que tanto los servicios o u o web como sus programas cliente puedan escribirse en cualquier lenguaje, y ser ejecutados en todas las plataformas.

4.1.2.

Arquitectura

La arquitectura de los servicios web permite desarrollar servicios que encapsulan todos los niveles de funcionalidad. Es decir, los servicios web pueden ser muy simples (por ejemplo, uno que informe de la temperatura actual) o complejos. Incluso es posible combinar varios servicios web con el n de crear nuevas funciones. La arquitectura de los servicios web tiene 3 cometidos: 33

Herramientas y Entornos de Programaci n o 1. Proporcionar datos: como proveedor, crear el servicio web y ponerlo a disposici n de los clientes. o 2. Solicitar datos: realizar la petici n de las aplicaciones cliente que consumen el servicio. El servicio o solicitado tambi n puede ser un cliente/proveedor de otros servicios web. e 3. Hacer de intermediario: permitir la interacci n entre las aplicaciones cliente y el proveedor. o Estos tres cometidos interaccionan por medio de las operaciones de publicaci n, b squeda y enlace (ver o u imagen). El proveedor utiliza la interfaz de publicaci n del intermediario para comunicarle la existencia o del servicio web. Esa informaci n publicada describe el servicio web e indica d nde se encuentra. La o o aplicaci n que hace la solicitud consulta el intermediario para que busque los servicios web publicados. o Con la informaci n del intermediario, la aplicaci n cliente puede llamar al servicio web. o o

Figura 4.1: Cometidos de la arquitectura de servicios web

4.2.

SOAP: Simple Object Access Protocol

SOAP es un protocolo de mensajes (como ya vimos, los mensajes son documentos XML) independiente del transoporte aunque SOAP especica la forma en que sus mensajes se encaminan por medio de HTTP . Utiliza mensajes unidireccionales, aunque es posible combinar mensajes en secuencias de solicitud y respuesta.

Figura 4.2: Mensajes SOAP Podos los documentos SOAP tienen un elemento raz, que consta de una cabecera (que contiene los datos de encaminado, y puede estar vaca) y el cuerpo (que contiene el mensaje propiamente dicho). La especicaci n SOAP tambi n proporciona un patr n de mensajera est ndar para el comportamiento o e o a tipo RPC: se emparejan dos mensajes de SOAP, uno de petici n y uno de respuesta. La llamada a un m todo o e 34

Entorno de desarrollo .NET y sus par metros se serializan en el cuerpo del mensaje de petici n, con cada par metro codicado como a o a un subelemento XML. El mensaje de respuesta puede contener los resultados de la llamada o una estructura de fallo. Las ventajas m s importantes de SOAP son: a No est asociado con ning n lenguaje de programaci n. a u o No se encuentra fuertemente asociado a ning n protocolo de transporte (como es XML, puede emu plearse cualquier protocolo capaz de transportar texto). No est atado a ninguna infraestructura de objeto distribuido. a Aprovecha los est ndares existentes en la industria. a Permite la interoperabilidad entre m ltiples entornos. u

4.3.

WSDL: Web Services Description Language

Los servicios web s lo resultan utiles si otras aplicaciones pueden reconocer qu hacen y la forma de o e llamarlos. WSDL es un lenguaje basado en XML que se emplea para denir servicios web y describir la forma de acceder a ellos. Los desarrolladores deben examinar el documento WSDL de los servicios web para averiguar qu m todos hay disponibles y c mo se realizan las llamadas con los par metros adecuados. e e o a Un documento WSDL se puede dividir en dos grupos de secciones: el grupo superior est compuesto por a las deniciones abstractas, mientras que el inferior por las descripciones concretas. Las secciones abstractas denen los mensajes SOAP de una forma independiente a la plataforma y al lenguaje. Las descripciones concretas se emplean para las cuestiones especcas del sitio, como la serializaci n. o Deniciones abstractas Elemento types: Contiene informaci n del esquema de tipos de datos que emplea el documento. El sistema de tipos o predeterminado es XML, pero se pueden emplear otros. Elemento message: Proporciona una abstracci n com n para el paso de mensajes entre cliente y servidor. Es decir, deo u ne los datos que se est n comunicando. Normalmente aparecen varios elementos Message en un a documento WSDL, uno para cada tipo de mensaje que se comunica.Los mensajes tienen uno o m s a elementos Part, que describen las partes del mensaje. Elemento Operation: Descripci n abstracta de una acci n admitida por el servicio. o o Elemento portType: Contiene un conjunto de operaciones abstractas, que representan los tipos de correspondencia que puede haber entre cliente y servidor. WSDL dene 4 tipos de operaciones: 1. Request-response (petici n-respuesta): comunicaci n tipo RPC, en la que el cliente lanza una o o petici n y el servidor enva la respuesta correspondiente. o 2. One-way (un-sentido): comunicaci n en la que el cliente enva un mensaje pero no recibe una o respuesta del servidor. 3. Solicit-response (solicitud-respuesta): es la contraria al tipo petici n-respuesta: el servidor enva o una petici n y el cliente le enva de vuelta una respuesta. o 4. Notication (noticaci n): La contraria a la operaci n un-sentido: el servidor enva una comuo o nicaci n al cliente. o 35

Herramientas y Entornos de Programaci n o Descripciones concretas Elemento binding: Especica los detalles de formatos del mensaje y protocolo. Por ejemplo, especica si se puede acceder a una instancia de un portType de forma RPC. Las deniciones binding tambi n indican el e n mero de comunicaciones de red que se requieren para realizar una determinada acci n. u o Elemento port: Punto nal unico, denido como la combinaci n del protocolo y del formato de datos para un tipo de o puerto. Elemento service: Un servicio es un grupo de puertos relacionados. Un puerto es un extremo concreto de un Servicio Web al que se hace referencia por una direcci n unica. o

4.4.

WSIL: Web Services Inspection Language

WSIL proporciona un m todo de descubrimiento de servicios para servicios web. Utiliza un modelo e descentralizado y distribuido, en lugar de un modelo centralizado (UDDI1 ). Los documentos WSIL son, b sicamente, punteros de listas de servicios que permiten a los clientes de servicios web examinar los a servicios disponibles. La norma WSIL establece la forma de utilizar documentos con formato XML para inspeccionar sitios web en busca de servicios y series de reglas que determinan la forma en que se proporciona la informaci n. o El proveedor del servicio web aloja el documento WSIL de forma que los consumidores puedan encontrar los servicios disponibles.

4.5.
4.5.1.

Proceso de funcionamiento
Localizaci n de servicios o

Para que un servicio web sea util, y cumpla su funci n, es necesario que los potenciales consumidores o puedan localizarlo, identicar sus m todos y usarlos. e Todo comienza cuando el desarrollador del programa cliente tiene que localizar el servicio, para ello usa una regla general: un servicio de directorio UDDI. Un registro UDDI contiene meta-informaci n sobre o servicios web, incluyendo la URL donde se encuentran. Por ello, UDDI sirve como infraestructura para una colecci n de software basado en servicios web. La informaci n de UDDI se almacena en nodos del o o operador (empresas que se han comprometido a ejecutar un nodo p blico). u

4.5.2.

Descripci n del servicio o

Una vez que se dispone de la informaci n relativa a la localizaci n del servicio, el siguiente paso es o o obtener una descripci n completa de ese servicio. Aqu entra en escena el lenguaje WSDL. WSDL y UDDI o se dise aron para diferenciar los metadatos abstractos y las implementaciones concretas, las consecuencias n de esta divisi n son 2: o 1. WSDL distingue claramente los mensajes de los puertos. Los mensajes (sintaxis+sem ntica) de un a servicio web son siempre abstractos, mientras que los puertos (las direcciones en las que se invoca un servicio web) son siempre concretos.
1 Universal

Discovery, Description and Integration

36

Entorno de desarrollo .NET 2. No es necesario que un archivo WSDL incluya informaci n sobre el puerto, basta con tener inforo maci n abstracta de la interfaz, sin facilitar datos de implementaci n concretos. De este modo, los o o archivos WSDL se separan de las implementaciones. Pueden existir varias implementaciones de una unica interfaz WSDL. UDDI establece una distinci n similar entre la abstracci n y la implementaci n, con el concepto de o o o tModels2 . UDDI ofrece un mecanismo que permite publicar por separado los tModels de las plantillas de enlace que hacen referencia a ellos.

4.5.3.

Llamada a los m todos e

Partiendo de la descripci n del servicio, el consumidor llamar a los m todos que exponga el servicio o a e usando mensajes SOAP.

4.5.4.

Proceso

Toda la comunicaci n entre el servicio y el consumidor se efectuar normalmente usando el protocolo o a HTTP, el mismo que se emplea para la navegaci n web. Esto hace posible la superaci n de elementos que, o o como los cortafuegos, suponen un obst culo al utilizarse otras vas de transmisi n. a o

2 Technology Model. La estructura tModel representa las huellas digitales t cnicas, interfaces y tipos abstractos de metadatos. El e resultado de los tModels son las plantillas de enlace, que hacen referencia a una implementaci n particular de un tModel. o

37