Herramientas y Entornos de Programaci on

Sergio Garc a Mondaray www.yakiboo.net

Escuela Superior de Inform atica de Ciudad Real Universidad de Castilla-La Mancha

 Indice general
1. Introducci on 1.1. Generalidades sobre la Ingenier a del Software. SWEBOK . . . . . . . . . . . . . . . . . 1.1.1. Construcci on del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2. Herramientas y m etodos de la Ingenier a del Software . . . . . . . . . . . . . . . 1.2. Estilos y Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Estilos de construcci on (interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. Principios de organizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1. Patrones de creaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2. Patrones estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3. Patrones de comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Tecnolog as CASE 2.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. Componentes de las herramientas CASE . . . . . . . . . . . . . . . . . . . . . . 2.2. Clasicaci on de las herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Adopci on de herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1. Proceso de evaluaci on y selecci on de herramientas . . . . . . . . . . . . . . . . . 3. Entorno de desarrollo .NET 3.1. Caracter sticas generales de .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Qu e es .NET? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. Objetivos de la tecnolog a .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 un en tiempo de ejecuci on (CLR) . . . . . . . . . . . . . . . . . . . 3.1.5. Especicaciones del lenguaje com un CLS . . . . . . . . . . . . . . . . . . . . . . 3.2. Ensamblados (Assemblies) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Introducci on a los Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. Caracter sticas de los Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3. Estructura de un ensamblado est atico . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4. Maniesto de un Ensamblado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5. Tipos de Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6. Ejecuci on simult anea de varias versiones de un Ensamblado . . . . . . . . . . . . 3.3. Administraci on de datos con ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Integraci on de ADO.NET con XML . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3. Espacio de nombres para ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4. Elementos fundamentales de ADO.NET . . . . . . . . . . . . . . . . . . . . . . . 3.4. .NET frente a otras tecnolog as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Caracter sticas generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Servicios Web 4.1. Introducci on a los Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Conceptos b asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 on de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2. Descripci on del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3. Llamada a los m etodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 on

Cap tulo 1

Introducci on
1.1. Generalidades sobre la Ingenier a del Software. SWEBOK

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

1.1.1.

Construcci on del software

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

Engineering Body of Knowledge

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

1.1.2.

Herramientas y m etodos de la Ingenier a del Software

Existen much simas herramientas de ayuda en la Ingenier a 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. del software. Para crear y vericar dise Para el diseno nos de software. Existe gran variedad, en correspondencia con la gran multitud de notaciones y m etodos. Un ejemplo es Enterprise Architect. Para el proceso de construcci on. Compiladores, depuradores, editores de c odigo, etc. Son ejemplo de herramientas de este tipo Editeur y ConText. Para llevar a cabo pruebas de software. Se clasican seg un las partes del proceso de prueba en que 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 on humana de programas, herramientas de ingenier a inversa, herramientas de re-ingenier a3 , y herramientas de conversi on de c odigo. Son ejemplos Maintenance Assistant y RAMI. Para el control de calidad. Existen herramientas de inspecci on (apoyo a las revisiones), de an alisis est atico (como analizadores sint acticos, de dependencia, etc), y herramientas de comportamiento din amico (an alisis de prestaciones en tiempo de ejcuci on). Ejemplos: KMKey Quality, y Mipsis Software Quality. Para la gesti on de conguraci on del software. Herramientas para la gesti on de versiones, y herramientas para la gesti on de liberaci on y actualizaciones. Por ejemplo: PureCM. Para la gesti on de la Ingenier a del Software. Hay varias modalidades: herramientas para proyectar, planicar y realizar trazas; herramientas para el an alisis y gesti on de riesgos; herramientas para realizar mediciones; y herramientas para trazar deciencias. Miscel anea.

1.2.
1.2.1.

Estilos y Principios
Estilos de construcci on (interfaces)

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

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

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

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

Estilo formal Se basa en la precisi on y rigor del razonamiento l ogico y formal, asemej andose a la forma de razonar del ser humano. Por ello es especialmente apropiado para trasladar a los computadores los prop ositos humanos, as como para vericar la precisi on y complejidad de una construcci on. El problema al que se enfrenta es que el razonamiento formal no est a tan extendido como el lenguaje 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 on de software.

Estilo visual til para la construcSe basa en la utilizaci on de interfaces visuales. Este estilo resulta especialmente u ci on de software porque provee de facilidades, al presentar opciones y ocultar detalles mediante el sistema visual (interfaz). Adem as es apropiado para sistemas que requieren de muchos desarrolladores, ya que permiten establecer c omo y cu ando comunicarse con los dem as.

1.2.2.

Principios de organizaci on

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

Principio de Reducci on de la Complejidad 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 on del software, siendo especialmente cr tico en los procesos de auto-vericaci on. Existen 3 t ecnicas principales para reducir la complejidad: 7

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

Introducci on

1.3.

Patrones

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

1.3.1.

Patrones de creaci on

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

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

Fragmento de c odigo 1.1: Ejemplo de patr on Singleton

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 on

1.3.2.

Patrones estructurales

Tratan de ver c omo las clases y los objetos se unen para formar grandes estructuras. Este tipo de patrones tiles para usan herencia para componer interfaces o implementaciones. Estos patrones son especialmente u hacer desarrollos independientes de librer as 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 aximo. Minimizar la comunicaci on y dependencias entre subsistemas. 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 en est a relacionado con Mediator, y con Singleton (normalmente, s olo es requerido un objeto de tipo Facade). Soluci on: Consiste en ofrecer una clase que haga de interfaz con el sistema (ver c odigo 1.2). Ejemplos: Interfaz de acceso a base de datos, lectura de archivos XML, etc.

Fragmento de c odigo 1.2: Ejemplo de patr on Facade

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 on de responsabilidades entre objetos. Algunos ejemplos son Chain of Responsibility, Interpreter, Observer y Mediator. Observer Contexto: Cuando un objeto cambie de estado, informar a los dem as del cambio. Problema: Denir una o muchas dependencias entre objetos, de modo que cuando uno cambie de estado, todos los dem as est en actualizados autom aticamente. Soluci on: Disponer en los observadores de m etodos de actualizaci on (update(), que sean llamados por los objetos observados cuando algo cambie) y de un m etodo getter en los observados, que facilite la actualizaci on de todos los cambios.

10

Tecnolog as CASE

Cap tulo 2

Tecnolog as CASE
2.1. Introducci on

Las tecnolog as CASE1 proporcionan la automatizaci on del desarrollo del software. Estas tecnolog as son una composici on de ciertas herramientas y metodolog as que se aplican a todo el ciclo de vida del desarrollo del software. Herramientas aut onomas o integradas de productividad que automatizan totalmente, o en parte, tareas del ciclo de vida del desarrollo de software. Metodolog as estructuradas y automatizables que denen una formulaci on t ecnica y disciplinada para todos o algunos de los aspectos del desarrollo de software. Ejemplo: la programaci on estructurada. Las tecnolog as CASE se centran en la productividad, y no s olo en obtener soluciones. Algunos ejemplos son las herramientas de diagramaci on de esquemas estructurados, las herramientas de validaci on sint actica o de inconsistencias, los generadores de c odigo a partir de otras especicaciones (por ejemplo, gr acas), los generadores de documentaci on t ecnica y de usuario, etc.

2.1.1.

Conceptos

CASE: Ingenier a del Software asistida por computaci on. Tecnolog a CASE: Conjunto de instrumentos y t ecnicas software dedicadas a la automatizaci on de una disciplina de la ingenier a, incluyendo metodolog as 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 un y corren en un ambiente computacional com un. Kit de herramientas CASE: Conjunto de herramientas CASE integradas que se han dise nado para trabajar juntas y automatizar el ciclo de desarrollo software, incluyendo el an alisis, dise no, implementaci on y pruebas. Metodolog a CASE: Conjunto estructurado de m etodos que denen una disciplina de la ingenier a como un acercamiento a todos o algunos aspectos del desarrollo y mantenimiento del software. Puesto de trabajo para CASE: Estaci on de trabajo t ecnica o computador personal equipado con herramientas CASE que automatiza varias funciones del ciclo.
1 Computer

Aided Software Engineering. En espa nol: Ingenier a del Software Asistida por Computador.

11

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

2.1.2.

Objetivos

Los nes que persiguen las herramientas CASE son variados: reas de desarrollo y mantenimiento de los sistemas inform Aumentar la productividad de las a aticos (reduciendo tiempos y costes). Mejorar la calidad del software desarrollado. Mejorar la gesti on y dominio sobre el proyecto en cuanto a su planicaci on, ejecuci on y control. 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 on: Automatizar: El desarrollo del software. La documentaci on. La generaci on del c odigo. El chequeo de errores. La gesti on del proyecto. Permitir: La reutilizaci on del software. La portabilidad del software. La estandarizaci on de la documentaci on. Integrar las fases de desarrollo (Ingenier a del Software) Facilitar la utilizaci on de las distintas metodolog as que desarrolla la Ingenier a del Software.

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 on se realiza mediante el apoyo de un SGBD2 o de un sistema de gesti on de cheros. Las caracter sticas m as importantes de un repositorio son: Tipo de informaci on. Que contiene alguna metodolog a concreta, datos, gr acos, procesos, informes, modelos o reglas. Tipo de controles. Si incorpora alg un m odulo de gesti on de cambios, de control de versiones, de acceso por clave, de redundancia de informaci on.
2 Sistema

de Gesti on de Bases de Datos

12

Tecnolog as CASE M odulos de diagramaci on y modelado 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 on. Historia de la vida de las entidades. Diagrama de estructura de datos. Diagrama de estructura de cuadros. T ecnicas matriciales. Las caracter sticas m as importantes de los diagramas y modelos son: N umero m aximo de niveles. Para poder soportar dise nos complejos. N umero m aximo de objetos que se pueden incluir para no encontrarse limitado en el dise no de grandes aplicaciones. N umero de diagramas distintos en pantalla o al mismo tiempo en distintas ventanas. Dibujos en formato libre con la nalidad de a nadir comentarios, informaci on adicional, etc. Actualizaci on del repositorio por cambios en los diagramas. Control sobre el tama no, fuente, emplazamiento de texto, etc. Inclusi on de pseudoc odigo, que servir a de base a los programadores. ltimo cambio, para facilitar la correcci Posibilidad de deshacer el u on de errores. Herramientas de prototipado El objetivo de estas herramientas es poder mostrar al usuario, desde los momentos iniciales del dise no, tiles cuanto el aspecto que tendr a la aplicaci on una vez desarrollada. Por ello estas herramientas ser an m as u m as r apidamente permitan la construcci on del prototipo. Actualmente es imprescindible utilizar productos que incorporen esta funcionalidad, por la cambiante tecnolog a y necesidades de los usuarios. Generadores de c odigo Las caracter sticas m as importantes de los generadores de c odigo son: Lenguaje generado. Si se trata de un lenguaje est andar o propietario. Portabilidad del c odigo generado. nicamente del esqueleto del programa o del programa completo. Si la generaci on es u Posibilidad de modicaci on del c odigo generado. Generaci on del c odigo asociado a las pantallas e informes de la aplicaci on. Para obtener la interfaz de usuario de la aplicaci on. 13

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

2.2.

Clasicaci on de las herramientas CASE

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

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

De An alisis y Dise no: Son de las m as antiguas y m as usadas. Ayudan al ingeniero de software a crear modelos del sistema que hay que construir, eliminando posibilidades de error. En ocasiones se subdividen en herramientas para el dise no funcional (que describen los datos y procesos con diagramas) y en herramientas para el dise no detallado (generadores autom aticos de especicaciones, simuladores de transiciones, etc.). De Prototipado y Simulaci on: Se emplean cuando se utiliza un ciclo de vida mediante prototipos. 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 on. Para la Generaci on de aplicaciones y componentes: Muchas se est an convirtiendo en generadores de prototipos espec cos. Estas herramientas se clasican en generadores de c odigo, generadores de macros, generadores de esquemas de BD, generadores de interfaces de usuario, etc. De Programaci on: Compiladores, editores, depuradores, entornos de programaci on visual (para 3 on (4GL), etc. GUIs), entornos RAD , lenguajes de cuarta generaci De Pruebas (CAST4 ): Sirven para gestionar pruebas de software: denir requisitos y objetivos de las pruebas, dise nar las pruebas, construir entornos de ejecuci on de las pruebas, ejecutarlas y para evaluar de pruebas. Para la Validaci on: Permiten automatizar y vericar el cumplimiento de las especicaciones. De Ingenier a Inversa y Reingenier a: Procesan c odigo fuente para producir otro tipo de ele tiles mento software. Existen muchas para entornos COBOL, FORTRAN SGBD. Son muy u cuando la documentaci on es inexistente o est a desfasada. Existen varios tipos: Recuperadores de dise no a partir del c odigo fuente. Redocumentadores: a partir del c odigo fuente generan diagramas y otros documentos.
3 Entornos

de Desarrollo R apido de Aplicaciones.

15

Herramientas y Entornos de Programaci on Analizadores de c odigo Descompiladores: a partird el c odigo objeto obtienen el c odigo fuente Para el Mantenimiento: Herramientas de Navegaci on (permiten la b usqueda r apida y f acil de las partes del software que interesan. Identican d onde se usan unas variables, qu e m odulos utilizan otros m odulos, visualizan las estructuras de datos...) y herramientas para el perfeccionamiento del c odigo (reformateadores de c odigo y reestructuradores de c odigo).

2.3.

Entornos CASE integrados (I-CASE)

El verdadero poder de las tecnolog as CASE se obtiene a trav es de la integraci on: til Posibilitan la compartici on de informaci on entre varias herramientas del entorno. Esto es muy u para evitar la reintroducci on de datos en cada herramienta (y as evitar errores humanos al reintroducir datos), para facilitar la documentaci on en todas las etapas del desarrollo, y sobre todo para pro nico repositorio de base de datos para todas las herramientas (dise porcionar un u no, representaci on, etc). Permiten la detecci on de cambios en elementos de informaci on relacionados. Permiten el control de versiones Permiten el acceso directo a cualquiera de las herramientas. Permiten mantener la consistencia en el aspecto y la interacci on de la interfaz.

2.3.1.

Componentes de un I-CASE

Podemos visualizarlos de forma gr aca en la gura 2.1. Un I-CASE se compone de: Presentaci oon: Dene c omo el usuario va a ver todas las herramientas del entorno integrado: men us, 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 on. Servicios de integraci on de datos: Permite comunicar las herramientas con el repositorio. 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 on entre las herramientas y el ambiente CASE.

2.3.2.

Benecios

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

Gr aca de Usuario

16

Tecnolog as 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 on de herramientas: facilitan la comunicaci on entre herramientas a trav es de mensajes y eventos, lo que posibilita la ejecuci on concurrente de varias tareas con varias herramientas. Administraci on de entregables: los entornos I-CASE deben administrar el espectro completo de entregables (especicaciones, c odigos fuente, archivos, etc), y as posibilitar la denici on de objetos de tama no arbitrario, de asociar objetos en colecciones, etc. Portabilidad del Sistema Operativo: lo ideal es disponer de independencia con la plataforma de ejecuci on. Administrador de Conguraci on: debe ofrecer facilidades para administrar el compilador y los 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 on de an alisis y dise no. Tambi en debe ofrecer ayuda a mantener la documentaci on acorde con las versiones, y a asegurar la calidad del sistema cuando se cumplan los requerimientos y especicaciones. Administraci on de contexto: hacer vistas de una parte concreta del proyecto (Base de Datos, c odigos...) 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 conguraci on de cada usuario bajo control. Adem as debe proveer de herramientas de depuraci on remota.

2.3.3.

Opciones de Integraci on

Existen diferentes posibilidades en cuanto a la integraci on de las herramientas en un I-CASE: 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. a las herramientas: El usuario puede ver varias herramientas simultaneamente, a Acceso comun trav es de una interfaz de usuario com un. Los procesos de transferencia son sencillos.
6 Sistemas

de Control de Versiones

17

Herramientas y Entornos de Programaci on

Figura 2.2: Integraci on punto a punto

Figura 2.3: Integraci on con acceso com un a las herramientas

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

Figura 2.4: Integraci on con gesti on de datos com un

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

2.4.

Adopci on de herramientas CASE

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

Tecnolog as CASE

Figura 2.5: Integraci on completa

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

2.4.1.

Proceso de evaluaci on y selecci on de herramientas

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

19

Herramientas y Entornos de Programaci on

20

Entorno de desarrollo .NET

Cap tulo 3

Entorno de desarrollo .NET

3.1.
3.1.1.

Caracter sticas generales de .NET

Qu e es .NET?

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

3.1.2.

Objetivos de la tecnolog a .NET

La tecnolog a .NET proporciona un modelo de programaci on simple y consistente, liberando al programador de las cuestiones de infraestructura el framework .NET se encarga de gestionar la memoria, los hilos, etc. Los principales objetivos de la tecnolog a .NET son los siguientes: 1. Proporcionar integraci on entre diferentes lenguajes. 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 on multiplataforma: gracias al lenguaje intermedio de Microsoft (MSIL). 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 on

Figura 3.1: Componentes de la tecnolog a .NET

3.1.4.

en tiempo de ejecuci Lenguaje comun on (CLR)

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

Types System

22

Entorno de desarrollo .NET (CTS) Sistema de tipos comun Est a formado por un amplio conjunto de tipos y operaciones que se encuentran presentes en la mayor a de lenguajes de programaci on. Dene c omo se declaran, utilizan y gestionan los tipos en el CLR. Y es lo que posibilita la interoperabilidad entre diferentes lenguajes de programaci on. En resumen, ofrece las siguientes funciones: Establece un framework que permite la integraci on de lenguajes, seguridad de tipos y ejecuci on de c odigo de alto rendimiento. Proporciona un modelo orientado a objetos que soporta muchos lenguajes de programaci on. 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 un (CTS) Denici on de tipos Una denici on de un tipo constituye un tipo nuevo a partir de los tipos existentes. Dentro de la denici on 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 on del tipo que los contiene. M etodos: operaciones disponibles para un tipo. Propiedades: son la alternativa a las tradicionales formas de acceder a un atributo. Tipos referencia Los tipos referencia son la combinaci on de una localizaci on y una secuencia de bits. Las localizaciones reas de memoria que pueden ser utilizadas, y poseen seguridad de tipos (para s denotan las a olo poder asignarle un tipo compatible). Existen los siguientes tipos de referencias: 23

Herramientas y Entornos de Programaci on 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 on binaria que describe los tipos implementados por un programa. El sistema de metadatos permite almacenar dichos metadatos junto a los tipos a los que se reeran, en tiempo de compilaci on, y obtenerlos en tiempo de ejecuci on. Los benecios de la utilizaci on de metadatos son los siguientes: Proporcionan cheros de c odigo autodescriptivos, eliminando la necesidad del registro. Proporcionan la informaci on necesara para conseguir la interoperabilidad entre distintos lenguajes. Proporcionan la informaci on que necesita el sistema para la gesti on de objetos. Permite a .NET las invocaciones remotas. Mediante los atributos es posible especicar aspectos m as detallados sobre el comportamiento del programa en tiempo de ejecuci on. .NET almacena el c odigo MSIL, junto con los metadatos, en una unidad autodescriptiva denominada ensamblado. Sistema de ejecuci on La traducci on de MSIL a c odigo nativo de la CPU es realizada por un compilador JIT2 o Jitter. El Jitter va conviertiendo din amicamente el c odigo MSIL en c odigo nativo seg un sea necesario. La compilaci on JIT tiene en cuenta el hecho de que algunas porciones de c odigo no ser an llamadas durante la ejecuci on, por nicamente convierte el que es lo que en lugar de infertir tiempo y memoria en convertir todo el c odigo, u necesario durante la ejecuci on, almacen andolo por si volviera a ser necesario en el futuro. El recolector de basura del sistema de ejecuci on debe eliminar los objetos de la memoria cuando no van a ser referenciados nunca m as. El proceso de recolecci on de basura puede ser lanzado autom aticamente por el CLR o invocado expl citamente. 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 on), y obtiene, a su vez, todos los 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.

CLS Especicaciones del lenguaje comun

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

In Time

24

Entorno de desarrollo .NET Pese a esto, no hay ninguna garant a de que un desarrollador de un lenguaje cualquiera dena un tipo que luego pueda ser utilizado por otros desarrolladores. Para asegurar que el c odigo escrito en un lenguaje sea accesible desde otros se ha denido la Especicaci on del Lenguaje Com un o CLS (Common Language Specication) que establece un conjunto m nimo de caracter sticas que deben soportarse para asegurar la interoperabilidad, siendo dicho conjunto de caracter sticas m nimas un subconjunto del CTS. El CLS se ha dise nado para ser lo sucientemente grande como para que incluya las construcciones m as comunes de los lenguajes, y lo sucientemente peque no para que la mayor a de lenguajes lo cumplan.

3.2.
3.2.1.

Ensamblados (Assemblies)
Introducci on a los Ensamblados

Los ensamblados son colecciones de tipos y recursos, que proporcionan la informaci on que el CLR necesita sobre las implementaciones de dichos tipos. Los ensamblados pueden clasicarse, atendiendo a 3 factores, en: Ensamblados est aticos o din amicos: los est aticos son generados en tiempo de compilaci on, y almacenados en disco. Los din amicos se generan en tiempo de ejecuci on y son ejecutados desde memoria, pudiendo almacenarse en disco tras la ejecuci on. Ensamblados multichero o con un unico chero. nicamente en la apliEnsamblados privados o compartidos: los ensamblados privados se utilizan u caci on para la que han sido desplegados, mientras que los compartidos pueden ser utilizados por m as aplicaciones.

3.2.2.

Caracter sticas de los Ensamblados

1. Contienen el c odigo intermedio (MSIL) que ser a ejecutado por el runtime, as como los metadatos 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 on para los tipos que contienen. La identidad de un tipo queda 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 on de los tipos y recursos, as como las dependencias con otros ensamblados. 5. Un ensamblado es la unidad m nima versionable. La pol tica 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 on s olo los 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 as, favorece el 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 on de m ultiples versiones simult aneas (slide-by-side execution). 25

Herramientas y Entornos de Programaci on

3.2.3.

Estructura de un ensamblado est atico

En general, la estructura l ogica de un ensamblado est atico consta de 4 elementos: 1. El maniesto del ensamblado: contiene los metadatos del ensamblado. 2. Los metadatos de los tipos que contiene el ensamblado. 3. El c odigo intermedio (MSIL). 4. Un conjunto de recursos. nico chero o en varios. Estos cheros, cuando contienen Estos 4 elementos pueden estar dispuestos en un u metadatos (y a veces c odigo MSIL tambi en), son denominados m odulos. Estructura de ensamblados de un s olo chero n u nico m Un ensamblado puede estar formado por u odulo, estableci endose una correspondencia uno a 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 f sicos, s olo un m odulo contiene el maniesto, mientras que el resto de m odulos s olo contienen metadatos sobre los tipos y opcionalmente c odigo intermedio. Los m odulos que componen un ensamblado multichero est an relacionados l ogicamente entre s por medio de la informaci on del maniesto, el cual referencia a los cheros que componen el ensamblado.

3.2.4.

Maniesto de un Ensamblado

El maniesto de los ensamblados es un conjunto de metadatos que describe c omo est an relacionados 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 odigo MSIL, o en un nicamente contiene el maniesto (esto puede darse s chero portable que u olo en ensamblados multichero). El maniesto de un ensamblado contiene los siguientes elementos: 1. Identidad: un nombre, un n umero de versi on, e informaci on sobre el idioma/cultura del ensamblado. 2. Lista de cheros del ensamblado: para cada chero se almacena su nombre y un hash criptogr aco con el contenido del chero. 26

Entorno de desarrollo .NET

Figura 3.4: Estructura de ensamblados multichero

3. Informaci on sobre los ensamblados referenciados: una lista con la identicaci on de los ensamblados referenciados de los que depende est aticamente. 4. Informaci on sobre los tipos y recursos exportados: informaci on relativa al mapeo de los tipos y los cheros f sicos que contienen sus metadatos e implementaci on, lo que es utilizado en tiempo de ejecuci on. 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, pol tica de versiones y aspectos de despliegue. Ensamblados privados nico. Nombrado El nombre de cada ensamblado, dentro de una misma aplicaci on, debe ser u Pol tica de versiones Ignorada. Despliegue Los ensamblados privados son desplegados en el directorio local de la aplicaci on o en uno de sus subdirectorios. Ensamblados compartidos Nombrado Utilizan los denominados nombres fuertes. Los nombres fuertes garantizan la unicidad del nombre (empleando claves criptogr acas, una privada y otra p ublica). Adem as previenen contra la suplantaci on del nombrado (no se puede construir un ensamblado casero y cargarlo en lugar de la versi on de la aplicaci on). Un nombre fuerte est a formado por un nombre amigable, un n umero de versi on, una clave p ublica y una rma digital. Pol tica de versiones El control de versiones es de gran importancia. La pol tica de versiones consiste en informaci on de la versi on, la cual debe ajustarse a unas pol ticas. 27

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

3.2.6.

Ejecuci on simult anea de varias versiones de un Ensamblado

El runtime posee la habilidad de ejecutar m ultiples versiones de un mismo ensamblado de forma simult anea. El runtime de .NET, concretamente permite esta ejecuci on no s olo en la misma m aquina, sino tambi en dentro del mismo proceso.

3.3.
3.3.1.

Administraci on de datos con ADO.NET

ADO.NET

ADO.NET es una tecnolog a 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 on de datos. ADO.NET emplea un modelo de acceso pensado para entornos desconectados. Esto quiere decir que la aplicaci on se conecta al origen de datos, hace lo que tiene que hacer, la carga en memoria y se desconecta. Con ADO.NET se elimina la necesidad de que el receptor de los datos sea un objeto COM, tal y como ocurr a 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 a formado por los denominados proveedores gestionados, o Manager Providers, que son 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 asico. 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 a constituido por los denominados DataSets, que son conjuntos de datos que representan un conjunto 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. Expl citamente podemos actualizar el contenido de la base de datos con el contenido del DataSet, en cualquier momento. l una base de datos Un DataSet puede ser manipulado de forma program atica, es decir, creando en e desde cero; pero tambi en puede ser cargado con los datos provenientes de una conexi on a un proveedor gestionado, o a una fuente de datos XML.

3.3.2.

Integraci on de ADO.NET con XML

nicamente en que e ste pose La integraci on del ADO cl asico con XML se basaba u a una interfaz para 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 on de datos, de forma que los datos obtenidos de una fuente de datos son representados 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. ltimo, a til para la transmisi Por u nadir que la integraci on de ADO.NET con XML resulta muy u on de datos entre las distintas capas de una aplicaci on.

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 etodo primario de acceso a los datos. System.Data.Common: clases que comparten los proveedores de datos .NET Framework. Dichos proveedores describen una colecci on de clases que se utiliza para obtener acceso a un origen de datos. System.Data.OleDb: clases que componen el proveedor de datos de .NET Framework para or genes 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 or genes 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 or genes 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 tecnolog as

.NET vs COM

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

Herramientas y Entornos de Programaci on El sistema de informaci on de tipos de COM tampoco mantiene la informaci on de dependencias de componentes externos. El sistema de metadatos sobre los tipos de .NET mejora notablemente al sistema del modelo COM. nico sistema de informaci Mediante los metadatos se consigue un u on sobre los tipos, manteniendo adem as informaci on sobre las dependencias de un componente. .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 on del componente y su descripci on, han sido solucionados en .NET mediante unidades autodescriptivas, los ensamblados.

3.4.2.

.NET vs COM+

COM+ es una mejora del Servidor de Transacciones de Microsoft (MTS). COM+ ampli o los servicios proporcionados por MTS y mejor o la interoperabilidad con el modelo COM. 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: nicamente el lenguaje Java, es multiplataforma y con m J2EE es una plataforma que utiliza u ultiples proveedores de tecnolog a. nica plataforma, Windows, y con un u nico proveedor, .NET es multilenguaje, est a dise nada para una u 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 un de tipos). Ambos modelos tambi en poseen sistemas de acceso remotos (RMI en J2EE y el framework remoto en .NET), siendo en este aspecto algo m as potente .NET. Tambi en es algo m as potente en el acceso a fuentes de datos, pues introduce la posibilidad de trabajar en modo desconectado con los denominados DataSet y est a altamente integrado con XML. Ambas plataformas soportan el uso de delegados (skinny clients): J2EE posee los servlets y las p aginas 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 nas diferencias radican en el uso de eventos, que en Java se realiza 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 on. La mayor diferencia entre .NET y J2EE viene dada por el runtime de ambas plataformas. La JVM (M aquina Virtual de Java) ha sido dise nada para proporcionar soporte multiplataforma a Java, mientras que el CLR de .NET ha sido dise nado, adem as de para ser multiplataforma, para ser independiente del lenguaje.
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 odigos intermedios (el bytecode de Java y el MSIL de .NET), MSIL es de mayor nivel e introduce la seguridad de tipos, pudiendo ser vericado el c odigo MSIL antes de su ejecuci on, para garantizar su seguridad. La ejecuci on del c odigo intermedio sigue esquemas distintos: en Java los bytecodes son interpretados, mientras que el CLR compila el c odigo MSIL, obteniendo un mayor rendimiento. Donde J2EE supera ampliamente a .NET es en los servicios de componentes, tales como persistencia autom atica, transacciones, etc. Adem as, .NET no tiene servicios propios, sino que los toma de COM+, lo que supone un factor en contra. Si establecemos una comparaci on entre las herramientas de desarrollo, J2EE tiene una amplia gama de nica herramienta de desarrollo para IDEs de distintos proveedores, mientras que VisualStudio .NET es la u .NET. A pesar de esto, la integraci on de VisualStudio .NET es mayor que la de las herramientas de J2EE, a pesar de que algunas son igual o m as potentes que VS.

3.4.4.

.NET vs CORBA

La plataforma .NET es m as amplia que la especicaci on CORBA, pues cubre algunos aspectos no sta (como las interfaces de usuario). .NET llega mucho m tratados por e as lejos que CORBA, adem as, en lo que se reere a la integraci on entre distintos lenguajes, pues en .NET una clase puede incluso heredar de otra escrita en otro lenguaje. CORBA carece de portabilidad en la implementaci on (a no ser que emplee Java, claro). .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 as, CORBA es m as potente y extensible que .NET, sobre todo en lo relativo a las pol ticas de conguraci on de los objetos remotos. Los servicios web proporcionados por .NET permiten un desarrollo de aplicaciones distribuidas mucho m as ligero que el impuesto por CORBA o por los objetos remotos de .NET, pues bastar a tener una librer a SOAP o un parser XML para acceder al servicio web (veremos esto en el cap tulo siguiente). A favor de CORBA est a el hecho de que se trata de una especicaci on est andar, consensuada por las distintas organizaciones y empresas que forman el OMG5 . Si CORBA no ha alcanzado la difusi on que se merec a es por la ausencia de entornos de desarrollo como VisualStudio.

3.5.
3.5.1.

El entorno Visual Studio .NET

Caracter sticas generales

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

Management Group

31

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

6 What

You See Is What You Get.

32

Cap tulo 4

Servicios Web
4.1.
4.1.1.

Introducci on a los Servicios Web

Conceptos b asicos

stas, a los que Los servicios web son m odulos de software que realizan tareas discretas o conjuntos de e se accede a trav es de una red (sobre todo la World Wide Web). Un ejemplo es el servicio de seguimiento de paquetes de Federal Express, mediante el cual los clientes pueden examinar el estado de sus env os. 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 on cliente que utilice 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 on del servicio se estar a ejecutando, respecto del cliente que lo 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 as reciente, y b asicamente se diferencia en los protocolos empleados para hacer la comunicaci on. Estos tres mecanismos mencionados se basan en canales y protocolos de conversaci on que no fueron ideados para la WWW. Por ello encuentran problemas con 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 env an entre el servicio web y la aplicaci on que efect ua la llamada. Esta estandarizaci on hace que tanto los servicios 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 on 1. Proporcionar datos: como proveedor, crear el servicio web y ponerlo a disposici on de los clientes. 2. Solicitar datos: realizar la petici on de las aplicaciones cliente que consumen el servicio. El servicio solicitado tambi en puede ser un cliente/proveedor de otros servicios web. 3. Hacer de intermediario: permitir la interacci on entre las aplicaciones cliente y el proveedor. Estos tres cometidos interaccionan por medio de las operaciones de publicaci on, b usqueda y enlace (ver imagen). El proveedor utiliza la interfaz de publicaci on del intermediario para comunicarle la existencia del servicio web. Esa informaci on publicada describe el servicio web e indica d onde se encuentra. La aplicaci on que hace la solicitud consulta el intermediario para que busque los servicios web publicados. Con la informaci on del intermediario, la aplicaci on cliente puede llamar al servicio web.

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 ra z, que consta de una cabecera (que contiene los datos de encaminado, y puede estar vac a) y el cuerpo (que contiene el mensaje propiamente dicho). La especicaci on SOAP tambi en proporciona un patr on de mensajer a est andar para el comportamiento tipo RPC: se emparejan dos mensajes de SOAP, uno de petici on y uno de respuesta. La llamada a un m etodo 34

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

4.3.

WSDL: Web Services Description Language

tiles si otras aplicaciones pueden reconocer qu Los servicios web s olo resultan u e hacen y la forma de 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 e m etodos hay disponibles y c omo se realizan las llamadas con los par ametros adecuados. Un documento WSDL se puede dividir en dos grupos de secciones: el grupo superior est a compuesto por 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 espec cas del sitio, como la serializaci on. Deniciones abstractas Elemento types: Contiene informaci on del esquema de tipos de datos que emplea el documento. El sistema de tipos predeterminado es XML, pero se pueden emplear otros. Elemento message: Proporciona una abstracci on com un para el paso de mensajes entre cliente y servidor. Es decir, dene los datos que se est an comunicando. Normalmente aparecen varios elementos Message en un documento WSDL, uno para cada tipo de mensaje que se comunica.Los mensajes tienen uno o m as elementos Part, que describen las partes del mensaje. Elemento Operation: Descripci on abstracta de una acci on admitida por el servicio. 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 on-respuesta): comunicaci on tipo RPC, en la que el cliente lanza una petici on y el servidor env a la respuesta correspondiente. 2. One-way (un-sentido): comunicaci on en la que el cliente env a un mensaje pero no recibe una respuesta del servidor. 3. Solicit-response (solicitud-respuesta): es la contraria al tipo petici on-respuesta: el servidor env a una petici on y el cliente le env a de vuelta una respuesta. 4. Notication (noticaci on): La contraria a la operaci on un-sentido: el servidor env a una comunicaci on al cliente. 35

Herramientas y Entornos de Programaci on 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 en indican el n umero de comunicaciones de red que se requieren para realizar una determinada acci on. Elemento port: nico, denido como la combinaci Punto nal u on del protocolo y del formato de datos para un tipo de puerto. Elemento service: Un servicio es un grupo de puertos relacionados. Un puerto es un extremo concreto de un Servicio nica. Web al que se hace referencia por una direcci on u

4.4.

WSIL: Web Services Inspection Language

WSIL proporciona un m etodo de descubrimiento de servicios para servicios web. Utiliza un modelo descentralizado y distribuido, en lugar de un modelo centralizado (UDDI1 ). Los documentos WSIL son, b asicamente, punteros de listas de servicios que permiten a los clientes de servicios web examinar los 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 on. 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 on de servicios

til, y cumpla su funci Para que un servicio web sea u on, es necesario que los potenciales consumidores puedan localizarlo, identicar sus m etodos y usarlos. 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 on sobre servicios web, incluyendo la URL donde se encuentran. Por ello, UDDI sirve como infraestructura para una colecci on de software basado en servicios web. La informaci on de UDDI se almacena en nodos del operador (empresas que se han comprometido a ejecutar un nodo p ublico).

4.5.2.

Descripci on del servicio

Una vez que se dispone de la informaci on relativa a la localizaci on del servicio, el siguiente paso es obtener una descripci on completa de ese servicio. Aqu entra en escena el lenguaje WSDL. WSDL y UDDI se dise naron para diferenciar los metadatos abstractos y las implementaciones concretas, las consecuencias de esta divisi on son 2: 1. WSDL distingue claramente los mensajes de los puertos. Los mensajes (sintaxis+sem antica) de un 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 on sobre el puerto, basta con tener informaci on abstracta de la interfaz, sin facilitar datos de implementaci on concretos. De este modo, los archivos WSDL se separan de las implementaciones. nica interfaz WSDL. Pueden existir varias implementaciones de una u UDDI establece una distinci on similar entre la abstracci on y la implementaci on, con el concepto de 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 etodos

Partiendo de la descripci on del servicio, el consumidor llamar a a los m etodos que exponga el servicio usando mensajes SOAP.

4.5.4.

Proceso

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

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

37