hyep apuntes latex sgm.pdf

Herramientas y Entornosde Programacion

Sergio Garcıa Mondaraywww.yakiboo.net

Escuela Superior de Informatica de Ciudad RealUniversidad de Castilla-La Mancha

Indice general

1. Introduccion 5

1.1. Generalidades sobre la Ingenierıa del Software. SWEBOK . . . . . . . . . . . . . . . . . 5

1.1.1. Construccion del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.2. Herramientas y metodos de la Ingenierıa del Software . . . . . . . . . . . . . . . 6

1.2. Estilos y Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1. Estilos de construccion (interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.2. Principios de organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3.1. Patrones de creacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3.2. Patrones estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.3. Patrones de comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Tecnologıas CASE 11

2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1. Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3. Componentes de las herramientas CASE . . . . . . . . . . . . . . . . . . . . . . 12

2.2. Clasificacion de las herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3. Entornos CASE integrados (I-CASE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1. Componentes de un I-CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2. Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.3. Opciones de Integracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4. Adopcion de herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1. Proceso de evaluacion y seleccion de herramientas . . . . . . . . . . . . . . . . . 19

3. Entorno de desarrollo .NET 21

3.1. Caracterısticas generales de .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1. ¿Que es .NET? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2. Objetivos de la tecnologıa .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.3. Componentes principales de .NET . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3

3.1.4. Lenguaje comun en tiempo de ejecucion (CLR) . . . . . . . . . . . . . . . . . . . 22

3.1.5. Especificaciones del lenguaje comun CLS . . . . . . . . . . . . . . . . . . . . . . 24

3.2. Ensamblados (Assemblies) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1. Introduccion a los Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2. Caracterısticas de los Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.3. Estructura de un ensamblado estatico . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.4. Manifiesto de un Ensamblado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.5. Tipos de Ensamblados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.6. Ejecucion simultanea de varias versiones de un Ensamblado . . . . . . . . . . . . 28

3.3. Administracion de datos con ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1. ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2. Integracion de ADO.NET con XML . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.3. Espacio de nombres para ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.4. Elementos fundamentales de ADO.NET . . . . . . . . . . . . . . . . . . . . . . . 29

3.4. .NET frente a otras tecnologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1. .NET vs COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.2. .NET vs COM+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.3. .NET vs J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.4. .NET vs CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5. El entorno Visual Studio .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.1. Caracterısticas generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. Servicios Web 33

4.1. Introduccion a los Servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1. Conceptos basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. SOAP: Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3. WSDL: Web Services Description Language . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4. WSIL: Web Services Inspection Language . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5. Proceso de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5.1. Localizacion de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5.2. Descripcion del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5.3. Llamada a los metodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5.4. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Introduccion

Capıtulo 1

Introduccion

1.1. Generalidades sobre la Ingenierıa del Software. SWEBOK

El SWEBOK1 es un comite conjunto del IEEE y de ACM, cuyo objetivo es tratar de promover laIngenierıa del Software como profesion reconocida.

Existen diversas areas de conocimiento en SWEBOK, como lo son:

Requerimientos del software.

Diseno del software.

Pruebas del software.

Mantenimiento del software.

Gestion de la configuracion del software.

Calidad del software.

Hablaremos, en primer lugar, de las que mas nos conciernen:

Construccion del software.

Herramientas y metodos de la Ingenierıa del Software.

1.1.1. Construccion del software

Lenguajes de Programacion

Los lenguajes de programacion son medios de comunicacion entre las personas y los computadores.Historicamente fueron creados como respuesta a necesidades de aplicaciones especıficas.

Es una rama muy joven aun, algo inestable. Resulta importante destacar que la construccion de softwareno debe depender del lenguaje o metodologıa de la programacion.

Lenguajes de Construccion

Los lenguajes de construccion contienen todas las formas de comunicacion por medio de las cuales laspersonas pueden construir soluciones ejecutables en un sistema de computo. Los lenguajes de programacionson las formas mas flexibles de los lenguajes de construccion.

1Software Engineering Body of Knowledge

5

Herramientas y Entornos de Programacion

Formas simples de los lenguajes de construccion son los lenguajes de configuracion, con los que losdesarrolladores escogen entre opciones predefinidas para crear un nuevo softwared e instalacion. Otros deestos lenguajes de construccion son los lenguajes de herramientas o toolkits.

Automatizacion de la construccion del software

La construccion automatica supone el uso intensivo de herramientas de construccion automatica(HCA), que tienden a tomar la forma de generadores de programas y de entornos altamente integrados quebrindan el control automatico del proceso de construccion.

Para ser eficaces las HCA deben poseer interfaces sencillas e intuitivas. Ademas, la automatizacion delsoftware se refiere no solo a las herramientas, sino a la abstraccion de programacion (por ejemplo, la POO2).

1.1.2. Herramientas y metodos de la Ingenierıa del Software

Existen muchısimas herramientas de ayuda en la Ingenierıa del Software. Podemos categorizarlas enlos 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 verificar disenos de software. Existe gran variedad, encorrespondencia con la gran multitud de notaciones y metodos. Un ejemplo es Enterprise Architect.

Para el proceso de construccion. Compiladores, depuradores, editores de codigo, etc. Son ejemplode herramientas de este tipo Editeur y ConText.

Para llevar a cabo pruebas de software. Se clasifican segun las partes del proceso de prueba en quese empleen: generadores de pruebas, frameworks, evaluadores de pruebas, y gestores de pruebas. Unejemplo es Junit.

Para el mantenimiento de software. Existen varios tipos: herramientas de ayuda a la compren-sion humana de programas, herramientas de ingenierıa inversa, herramientas de re-ingenierıa3, yherramientas de conversion de codigo. Son ejemplos Maintenance Assistant y RAMI.

Para el control de calidad. Existen herramientas de inspeccion (apoyo a las revisiones), de anali-sis estatico (como analizadores sintacticos, de dependencia, etc), y herramientas de comportamientodinamico (analisis de prestaciones en tiempo de ejcucion). Ejemplos: KMKey Quality, y Mipsis Soft-ware Quality.

Para la gestion de configuracion del software. Herramientas para la gestion de versiones, y her-ramientas para la gestion de liberacion y actualizaciones. Por ejemplo: PureCM.

Para la gestion de la Ingenierıa del Software. Hay varias modalidades: herramientas para proyec-tar, planificar y realizar trazas; herramientas para el analisis y gestion de riesgos; herramientas pararealizar mediciones; y herramientas para trazar deficiencias.

Miscelanea.

1.2. Estilos y Principios

1.2.1. Estilos de construccion (interfaces)

Existen diferentes estilos de interrelacion entre los computadores y las personas que utilizan software(mas concretamente los propios lenguajes de construccion). Los lenguajes de construccion deben presentar

2Programacion orientada a objetos.3Obtencion de productos nuevos a partir de la ingenierıa inversa.

6

Introduccion

y recibir la informacion de modo comprensible a los sentidos y las capacidades humanas, a traves de lo quese denomina interfaz.

Existen 3 estilos de interfaces de construccion de software, que estudiaremos a continuacion: linguısti-co, formal y visual. La mayorıa de lenguajes raramente se apoyan en un solo estilo, los mas extendidosutilizan los estilos linguıstico y formal.

Estilo linguıstico

Se basa en la utilizacion de oraciones que se asemejan a las del lenguaje natural. Normalmente setransfieren visualmente en forma de texto. Su ventaja principal es que son generalmente universales. Porotra parte, su mayor desventaja es la imprecision para expresar necesidades surgidas con el empleo deinterfaces.

Estilo formal

Se basa en la precision y rigor del razonamiento logico y formal, asemejandose a la forma de razonar delser humano. Por ello es especialmente apropiado para trasladar a los computadores los propositos humanos,ası como para verificar la precision y complejidad de una construccion.

El problema al que se enfrenta es que el razonamiento formal no esta tan extendido como el lenguajeconformado por: componente innato + habilidades adquiridas. Otra gran pega es que el razonamientoformal suele centrarse en lo fundamental del problema, desechando los detalles, y ese enfoque “estrecho”no es bueno para la construccion de software.

Estilo visual

Se basa en la utilizacion de interfaces visuales. Este estilo resulta especialmente util para la construc-cion de software porque provee de facilidades, al presentar opciones y ocultar detalles mediante el sistemavisual (interfaz). Ademas es apropiado para sistemas que requieren de muchos desarrolladores, ya que per-miten establecer como y cuando comunicarse con los demas.

1.2.2. Principios de organizacion

Ademas de los 3 estilos de interrelacion humano-computador que hemos estudiado, existen 4 principiosde organizacion que afectan el modo en que tiene lugar la construccion del software. Estos principios, queestudiaremos a continuacion, son los siguientes:

Principio de reduccion de la complejidad.

Principio de anticipacion a la diversidad.

Principio de estructuracion para la validacion.

Principio de utilizacion de estandares externos.

Principio de Reduccion de la Complejidad

Este principio refleja la limitada habilidad de las personas para trabajar con sistemas complejos, demuchas partes o interacciones. Se aplica a todos los aspectos de la construccion del software, siendo espe-cialmente crıtico en los procesos de auto-verificacion. Existen 3 tecnicas principales para reducir la com-plejidad:

7


Eliminacion de la complejidad: consiste en eliminar durante la construccion del software, las posi-bilidades no imprescindibles. Debe manejarse con cuidado y lleva intrınseco el principio de la parsi-monia: no anadir nunca capacidades que no seran requeridas.

Automatizacion de la complejidad: es mas poderosa que la anterior. Se crea un nuevo lenguaje deconstruccion en que las facilidades consumidoras de tiempo, o propensas al error si son realizadaspor humanos, se asignen al computador.Un buen ejemplo son los entornos graficos de programacion.

Localizacion de la complejidad: si la complejidad no puede ser eliminada ni automatizada, la unicaopcion es localizarla en pequenas unidades o modulos. Es muy adecuado para la comprension de unapersona. Pero hay que tener cuidado, pues una division exagerada podrıa no ayudar si las relacionesentre los modulos fuesen muy complicadas.

Principio de Anticipacion a la Diversidad

Tiene que ver mas con como la gente usa el software que con las diferencias entre los computadoresy las personas. Se basa en el hecho de que no existe ninguna construccion de software perpetua, a la queno haya que hacerle cambios con el paso del tiempo. La anticipacion a esos cambios es fundamental en elproceso de construccion del software.

Las implementaciones de formulas matematicas, aunque parezca lo contrario, tambien deben adaptarsecon el paso del tiempo, por ejemplo, a la computacion en nuevas maquinas, etc.

Tecnica de Generalizacion: Los casos generales no son obvios en las primeras fases de analisis. Lageneralizacion tiene como finalidad reconocer como algunos problemas especıficos encajan juntos comoparte de un marco mas general, para poder ası resolverlos mediante una sola construccion software en lugarde varias. Un ejemplo es el uso de pilas, que resulta mas general que el uso de arrays de tamano fijo. Elproblema es que depende mucho de la habilidad del desarrollador para encontrar generalizaciones.

Tecnica de Experimentacion: Consiste en utilizar tempranamente construcciones de software en tantoscontextos de usuario diferentes como sea posible, con el proposito de recopilar datos que permitan gener-alizar la construccion. Es mas una tecnica a nivel de proceso que de codigo. Un ejemplo es la metodologıaque siguio Linus Torvalds para crear Linux: las construcciones de codigo individuales se incorporaban rapi-damente al producto general y se distribuıan, ası se forzaba el uso, la experimentacion y la actualizacion deesas construcciones individuales.

Tecnica de Localizacion: Significa mantener los cambios anticipados tan localizados en una construc-cion software como sea posible. Resulta de la aplicacion del principio de localizacion de la complejidad.Podemos destacar como ejemplos la utilizacion de capas en la definicion de protocolos de comunicacion,ası como la utilizacion de constantes de compilacion para reducir la cantidad de campos.

Principio de Estructuracion para la Validacion

No importa cuanto cuidado se ponga en el diseno e implementacion del software, es inevitable lacomision de errores. El principio de Estructuracion para la Validacion dicta construir el software de modoque tales errores puedan aparecer durante las pruebas. Para ello el software debe ser modular, y las pruebasdeben desarrollarse paralelamente a la construccion.

Principio de Utilizacion de Estandares Externos

Los lenguajes de construccion deben cumplimentar estandares externos. Un ejemplo son las gramaticasde los lenguajes de programacion, otro es la utilizacion de lenguajes como XML, con gran numero deadaptaciones. Pero el ejemplo mas destacable es Internet, que fuerza el desarrollo de software adaptado,por ejemplo, a estandares web.

El conflicto entre reutilizar estandares externos o crear alguno nuevo es muy complejo.

8

Introduccion

1.3. Patrones

Los patrones describen problemas que ocurren una y otra vez en nuestro entorno, y describen el con-tenido de la solucion del mismo, con lo que puedes resolverlos sin tener que rehacerla. Son una abstraccionde una solucion contreta, dada por un problema concreto, en un contexto determinado.

Un patron esta compuesto por varios elementos:

Nombre. Debe ser significativo y corto, para que sea facil de recordar.

Contexto. Define las precondiciones en las cuales se da el problema.

Problema. Describe las metas y objetivos buscados.

Relaciones. Define las relaciones estaticas y dinamicas de un patron con otros.

Solucion. Son reglas dinamicas que describen como solucionar el problema.

Ejemplos. Uno o mas ejemplos que ilustren el contexto, el problema y su solucion.

Existen 3 categorıas principales de patrones, en funcion del nivel de abstraccion, del contexto en el quese aplican o de la etapa en el proceso de desarrollo. Gamma clasifica los patrones en patrones de creacion,patrones estructurales, y patrones de comportamiento.

1.3.1. Patrones de creacion

Se trata de patrones que abstraen el proceso de instanciacion de los objetos. Ayudan a hacer un sistemaindependiente de la creacion, composicion y representacion de sus objetos.

Algunos ejemplos son: Abstract Factory, Builder, Factory Method, Prototype y Singleton.

Singleton

Contexto: Hay clases que necesitan tener solo una instancia.

Problema: Esta unica instancia deberıa ser extensible por diferentes clases sin ser modificada.

Relaciones: Muchos otros patrones, como Abstract Factory, Builder y Prototype, son implementadosusando este patron.

Solucion: El constructor de la clase se hace privado, y dentro de ella se tiene una instancia estatica dela misma. Se crea un metodo getInstance() que devuelva siempre dicha instancia unica. (Verfragmento de codigo 1.1).

Ejemplos: Sistemas spooler para impresoras, donde solo deberıa haber un sistema de manejo spooler,solo una ventana manager.

Fragmento de codigo 1.1: Ejemplo de patron Singleton

1 public class MiClase{2 private static MiClase instanciaUnica = new MiClase();3 private MiClase(){/*Codigo del constructor*/}4 public static getInstance(){return instanciaUnica;}5 ...6 }

9


1.3.2. Patrones estructurales

Tratan de ver como las clases y los objetos se unen para formar grandes estructuras. Este tipo de patronesusan herencia para componer interfaces o implementaciones. Estos patrones son especialmente utiles parahacer 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 maximo. Minimizarla comunicacion y dependencias entre subsistemas.

Problema: Unificar en una interfaz todas las interfaces de un subsistema.

Relaciones: Abstract Factory es una alternativa a Facade para ocultar especificaciones de plataformasen clases. Tambien esta relacionado con Mediator, y con Singleton (normalmente, solo es requeridoun objeto de tipo Facade).

Solucion: Consiste en ofrecer una clase que haga de interfaz con el sistema (ver codigo 1.2).

Ejemplos: Interfaz de acceso a base de datos, lectura de archivos XML, etc.

Fragmento de codigo 1.2: Ejemplo de patron Facade

1 public class MiClase{2 public MiClase(){/*Codigo del constructor*/}3 public void accion1DelSubsistema{...}4 public void accion2DelSubsistema{...}5 ...6 }

1.3.3. Patrones de comportamiento

Este tipo de patrones tratan sobre algoritmos y asignacion de responsabilidades entre objetos. Algunosejemplos son Chain of Responsibility, Interpreter, Observer y Mediator.

Observer

Contexto: Cuando un objeto cambie de estado, informar a los demas del cambio.

Problema: Definir una o muchas dependencias entre objetos, de modo que cuando uno cambie deestado, todos los demas esten actualizados automaticamente.

Solucion: Disponer en los observadores de metodos de actualizacion (update(), que sean llamadospor los objetos observados cuando algo cambie) y de un metodo getter en los observados, quefacilite la actualizacion de todos los cambios.

10

Tecnologıas CASE

Capıtulo 2

Tecnologıas CASE

2.1. Introduccion

Las tecnologıas CASE1 proporcionan la automatizacion del desarrollo del software. Estas tecnologıasson una composicion de ciertas herramientas y metodologıas que se aplican a todo el ciclo de vida deldesarrollo del software.

Herramientas autonomas o integradas de productividad que automatizan totalmente, o en parte, tareasdel ciclo de vida del desarrollo de software.

Metodologıas estructuradas y automatizables que definen una formulacion tecnica y disciplinada paratodos o algunos de los aspectos del desarrollo de software. Ejemplo: la programacion estructurada.

Las tecnologıas CASE se centran en la productividad, y no solo en obtener soluciones. Algunos ejem-plos son las herramientas de diagramacion de esquemas estructurados, las herramientas de validacionsintactica o de inconsistencias, los generadores de codigo a partir de otras especificaciones (por ejemp-lo, graficas), los generadores de documentacion tecnica y de usuario, etc.

2.1.1. Conceptos

CASE: Ingenierıa del Software asistida por computacion.

Tecnologıa CASE: Conjunto de instrumentos y tecnicas software dedicadas a la automatizacion deuna disciplina de la ingenierıa, incluyendo metodologıas estructuradas y herramientas.

Herramienta CASE: Herramienta software que automatiza (totalmente o en parte) una parte delciclo de desarrollo del software.

Sistema CASE: Conjunto de herramientas CASE integradas que comparten una interfaz de usuariocomun y corren en un ambiente computacional comun.

Kit de herramientas CASE: Conjunto de herramientas CASE integradas que se han disenado paratrabajar juntas y automatizar el ciclo de desarrollo software, incluyendo el analisis, diseno, imple-mentacion y pruebas.

Metodologıa CASE: Conjunto estructurado de metodos que definen una disciplina de la ingenierıacomo un acercamiento a todos o algunos aspectos del desarrollo y mantenimiento del software.

Puesto de trabajo para CASE: Estacion de trabajo tecnica o computador personal equipado conherramientas CASE que automatiza varias funciones del ciclo.

1Computer Aided Software Engineering. En espanol: Ingenierıa del Software Asistida por Computador.

11


Plataforma de hardware para CASE: Arquitectura de hardware con uno, dos o tres sistemas puestosen lınea, que provee una plataforma operativa para las herramientas CASE.

2.1.2. Objetivos

Los fines que persiguen las herramientas CASE son variados:

Aumentar la productividad de las areas de desarrollo y mantenimiento de los sistemas informaticos(reduciendo tiempos y costes).

Mejorar la calidad del software desarrollado.

Mejorar la gestion y dominio sobre el proyecto en cuanto a su planificacion, ejecucion 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 clasificacion:

Automatizar:

• El desarrollo del software.

• La documentacion.

• La generacion del codigo.

• El chequeo de errores.

• La gestion del proyecto.

Permitir:

• La reutilizacion del software.

• La portabilidad del software.

• La estandarizacion de la documentacion.

Integrar las fases de desarrollo (Ingenierıa del Software)

Facilitar la utilizacion 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 elementosdefinidos o creados por la herramienta, y cuya gestion se realiza mediante el apoyo de un SGBD2 o de unsistema de gestion de ficheros.

Las caracterısticas mas importantes de un repositorio son:

Tipo de informacion. Que contiene alguna metodologıa concreta, datos, graficos, procesos, informes,modelos o reglas.

Tipo de controles. Si incorpora algun modulo de gestion de cambios, de control de versiones, deacceso por clave, de redundancia de informacion.

2Sistema de Gestion de Bases de Datos

12

Tecnologıas CASE

Modulos de diagramacion y modelado

Algunos de los diagramas y modelos utilizados con mayor frecuencia en las herramientas CASE sonlos siguientes:

Diagrama de flujo de datos.

Modelo entidad-interrelacion.

Historia de la vida de las entidades.

Diagrama de estructura de datos.

Diagrama de estructura de cuadros.

Tecnicas matriciales.

Las caracterısticas mas importantes de los diagramas y modelos son:

Numero maximo de niveles. Para poder soportar disenos complejos.

Numero maximo de objetos que se pueden incluir para no encontrarse limitado en el diseno degrandes aplicaciones.

Numero de diagramas distintos en pantalla o al mismo tiempo en distintas ventanas.

Dibujos en formato libre con la finalidad de anadir comentarios, informacion adicional, etc.

Actualizacion del repositorio por cambios en los diagramas.

Control sobre el tamano, fuente, emplazamiento de texto, etc.

Inclusion de pseudocodigo, que servira de base a los programadores.

Posibilidad de deshacer el ultimo cambio, para facilitar la correccion de errores.

Herramientas de prototipado

El objetivo de estas herramientas es poder mostrar al usuario, desde los momentos iniciales del diseno,el aspecto que tendra la aplicacion una vez desarrollada. Por ello estas herramientas seran mas utiles cuantomas rapidamente permitan la construccion del prototipo.

Actualmente es imprescindible utilizar productos que incorporen esta funcionalidad, por la cambiantetecnologıa y necesidades de los usuarios.

Generadores de codigo

Las caracterısticas mas importantes de los generadores de codigo son:

Lenguaje generado. Si se trata de un lenguaje estandar o propietario.

Portabilidad del codigo generado.

Si la generacion es unicamente del esqueleto del programa o del programa completo.

Posibilidad de modificacion del codigo generado.

Generacion del codigo asociado a las pantallas e informes de la aplicacion. Para obtener la interfazde usuario de la aplicacion.

13


Generadores de documentacion

Este modulo se alimenta del repositorio para transcribir las especificaciones allı contenidas. Algunascaracterısticas importantes son:

Generacion automatica a partir del repositorio, sin esfuerzo adicional.

Combinacion de informacion textual y grafica.

Generacion de referencias cruzadas. Para conocer la localizacion de un determinado elemento yanalizar el impacto de un posible cambio.

Ayuda de tratamiento de textos. Para mejorar la calidad de introduccion de textos complementarios ala documentacion.

Interfaz con otras herramientas: procesadores de texto, editores graficos, etc.

2.2. Clasificacion de las herramientas CASE

A la hora de clasificar las herramientas CASE, debemos tener en cuenta numerosos factores, como loslenguajes de generacion, el tipo de analisis (estructurado u orientado a objetos), si cubren algunas fases deuna etapa, o practicamente todo el ciclo de vida del software, etc.

Es por ello que no existe una unica clasificacion, sino que pueden clasificarese en base a:

Las plataformas que soportan

Segun su amplitud:

• Toolkit: es una coleccion de herramientas integradas que permite automatizar un conjunto detareas de algunas de las fases del ciclo de vida de un sistema informatico: Planificacion es-trategica, Analisis, Diseno, Generacion de programas.

• Workbench: son conjuntos de herramientas que dan soporte a la automatizacion del procesocompleto de desarrollo de un sistema informatico. Permiten cubrir el ciclo de vida completo ysu resultado es un ejecutable y su documentacion.

Las fases del desarrollo de software que automatizan:

• Upper CASE: Planificacion Estrategica y Requerimientos de Desarrollo Funcional.

• Middle CASE: Analisis, Diseno y el Control de Calidad.

• Lower CASE: Construccion, incluyendo la generacion de codigo y las pruebas (test).

La arquitectura de las aplicaciones que producen

Segun su funcionalidad:

• De Ingenierıa de la Informacion: Proporcionan un metamodelo del que se derivan sistemas deinformacion especıficos. Su objetivo es representar objetos de datos de negocio, sus relacionesy la forma en la que influyen entre las distintas areas de negocio de la Empresa.

• De Modelado y Administracion de procesos y empresas: Se emplean para representar los ele-mentos clave del proceso, de modo que sea mas comprensible. Pueden proporcionar vınculoscon otras herramientas que apoyen otras actividades del proceso ya definidas.

• De Estimacion, Planificacion y Administracion de proyectos: Estimacion: Estiman el esfuerzo,la duracion del proyecto y el numero recomendado de personas. Planificacion: capacitan aladministrador para definir todas las tareas del proyecto, crear una red de tareas, representar lasinterdependencias entre tareas, etc. Administracion de Proyectos: extension de las herramientasde planificacion para poder realizar un seguimiento del Proyecto.

14

Tecnologıas CASE

• De Analisis de riesgos: Para identificar los riesgos potenciales y desarrollar un plan que mit-igue, monitorice y administre esos riesgos. Capacitan al administrador para construir una guıadetallada de riesgos que ayude en su identificacion y analisis.

• De Seguimiento de requisitos: Proporcionan un enfoque sistematico para el aislamiento de losrequisitos, comenzando por la solicitud del cliente de una propuesta o especificacion. Las her-ramientas tıpicas de este tipio combinan una evaluacion de textos mediante una interaccionhumano-SGBD que almacena y categoriza los requisistos del sistema.

• Metricas: Proporcionan una mejor vision de la calidad del diseno o del codigo. Muchas her-ramientas metricas avanzadas mantienen una Base de Datos que permite calificar las medidasdel producto particular frente a los valores medios de la industria y frente a rendimientos par-ticulares anteriores.

• De Documentacion: Muchas organizaciones invierten mucho tiempo y esfuerzo en el desarrollode documentos. Estas herramientas posibilitan la edicion, visualizacion e impresion de doc-umentos. Algunos documentadores automaticos incluyen, ademas, opciones de maquetacion,generacion de ındices, etc.

• De Aseguramiento de la calidad: Permiten automatizar las tareas que mejoren la calidad delsoftware: analisis de calidad, control de compatibilidad, control de conexiones, control de se-guridad y validacion de la calidad.

• De Gestion de la configuracion del Software: Permiten gestionar de manera automatizada losdiversos estados por los que pasa el software; es por ello que son el nucleo de muchos sistemasCASE. Llevan a cabo 5 tareas principales:

1. Identificacion de los elementos de configuracion.2. Control de versiones.3. Control de cambios.4. Auditorıa.5. Contabilidad de estados.

• De Analisis y Diseno: Son de las mas antiguas y mas usadas. Ayudan al ingeniero de softwarea crear modelos del sistema que hay que construir, eliminando posibilidades de error. En oca-siones se subdividen en herramientas para el diseno funcional (que describen los datos y pro-cesos con diagramas) y en herramientas para el diseno detallado (generadores automaticos deespecificaciones, simuladores de transiciones, etc.).

• De Prototipado y Simulacion: Se emplean cuando se utiliza un ciclo de vida mediante prototi-pos. Permiten acceder al comportamiento real de un sistema antes de construirlo. Permiten alingeniero crear simulaciones para que el cliente se haga una idea del futuro comportamiento yfuncionamiento antes de la verdadera implementacion.

• Para la Generacion de aplicaciones y componentes: Muchas se estan convirtiendo en generadoresde prototipos especıficos. Estas herramientas se clasifican en generadores de codigo, gener-adores de macros, generadores de esquemas de BD, generadores de interfaces de usuario, etc.

• De Programacion: Compiladores, editores, depuradores, entornos de programacion visual (paraGUIs), entornos RAD3, lenguajes de cuarta generacion (4GL), etc.

• De Pruebas (CAST4): Sirven para gestionar pruebas de software: definir requisitos y objetivosde las pruebas, disenar las pruebas, construir entornos de ejecucion de las pruebas, ejecutarlasy para evaluar de pruebas.

• Para la Validacion: Permiten automatizar y verificar el cumplimiento de las especificaciones.

• De Ingenierıa Inversa y Reingenierıa: Procesan codigo fuente para producir otro tipo de ele-mento software. Existen muchas para entornos COBOL, FORTRAN SGBD. Son muy utilescuando la documentacion es inexistente o esta desfasada. Existen varios tipos:

◦ Recuperadores de diseno a partir del codigo fuente.◦ Redocumentadores: a partir del codigo fuente generan diagramas y otros documentos.

3Entornos de Desarrollo Rapido de Aplicaciones.

15


◦ Analizadores de codigo◦ Descompiladores: a partird el codigo objeto obtienen el codigo fuente

• Para el Mantenimiento: Herramientas de Navegacion (permiten la busqueda rapida y facil de laspartes del software que interesan. Identifican donde se usan unas variables, que modulos utilizanotros modulos, visualizan las estructuras de datos...) y herramientas para el perfeccionamientodel codigo (reformateadores de codigo y reestructuradores de codigo).

2.3. Entornos CASE integrados (I-CASE)

El verdadero poder de las tecnologıas CASE se obtiene a traves de la integracion:

Posibilitan la comparticion de informacion entre varias herramientas del entorno. Esto es muy utilpara evitar la reintroduccion de datos en cada herramienta (y ası evitar errores humanos al reintro-ducir datos), para facilitar la documentacion en todas las etapas del desarrollo, y sobre todo para pro-porcionar un unico repositorio de base de datos para todas las herramientas (diseno, representacion,etc).

Permiten la deteccion de cambios en elementos de informacion relacionados.

Permiten el control de versiones

Permiten el acceso directo a cualquiera de las herramientas.

Permiten mantener la consistencia en el aspecto y la interaccion de la interfaz.

2.3.1. Componentes de un I-CASE

Podemos visualizarlos de forma grafica en la figura 2.1. Un I-CASE se compone de:

Presentacioon: Define como el usuario va a ver todas las herramientas del entorno integrado: menus,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 definir, ejecutar y sincronizar distintas tareas querequieren cooperacion.

Servicios de integracion de datos: Permite comunicar las herramientas con el repositorio.

Repositorio: Provee de los datos comunes y sirve de enlace entre todas las herramientas. Debe so-portar cualquier tipo de objeto y las relaciones entre ellos.

Servidor de mensajes: Provee de un canal de comunicacion entre las herramientas y el ambienteCASE.

2.3.2. Beneficios

Los I-CASE nos ofrecen multitud de beneficios pero los mas importantes son:

Interfaz de usuario comun.5Interfaz Grafica 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 her-ramientas horizontales (procesos de mantenimiento, como CVS6.

Control y comunicacion de herramientas: facilitan la comunicacion entre herramientas a traves demensajes y eventos, lo que posibilita la ejecucion concurrente de varias tareas con varias herramientas.

Administracion de entregables: los entornos I-CASE deben administrar el espectro completo deentregables (especificaciones, codigos fuente, archivos, etc), y ası posibilitar la definicion de objetosde tamano arbitrario, de asociar objetos en colecciones, etc.

Portabilidad del Sistema Operativo: lo ideal es disponer de independencia con la plataforma deejecucion.

Administrador de Configuracion: debe ofrecer facilidades para administrar el compilador y losprocesos 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 medi-ante documentacion de analisis y diseno. Tambien debe ofrecer ayuda a mantener la documentacionacorde con las versiones, y a asegurar la calidad del sistema cuando se cumplan los requerimientos yespecificaciones.

Administracion de contexto: hacer vistas de una parte concreta del proyecto (Base de Datos, codi-gos...) Un programador debe poder ver la parte que le corresponde, es decir, su subconjunto de espaciode 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 deforma transparente al usuario, ası se puede trabajar en un sistema robusto de red. Teniendo la config-uracion de cada usuario bajo control. Ademas debe proveer de herramientas de depuracion remota.

2.3.3. Opciones de Integracion

Existen diferentes posibilidades en cuanto a la integracion de las herramientas en un I-CASE:

Herramientas CASE separadas: en este caso los enlaces entre herramientas se realizan de formamanual, y las salidas suelen ser de texto sobre papel.

Intercambio de datos Punto-a-Punto: Las herramientas exportan datos en un fichero. Los construc-tores de las herramientas CASE realizan puentes entre las herramientas.

Acceso comun a las herramientas: El usuario puede ver varias herramientas simultaneamente, atraves de una interfaz de usuario comun. Los procesos de transferencia son sencillos.

6Sistemas de Control de Versiones

17


Figura 2.2: Integracion punto a punto

Figura 2.3: Integracion con acceso comun a las herramientas

Gestion de datos comun: Los datos de varias herramientas son mantenidos en una sola Base deDatos.

Figura 2.4: Integracion con gestion de datos comun

Integracion completa. Gestion de Metadatos: Las distintas herramientas comparten unos metadatosa traves de un mecanismo de disparo. En esos metadatos se definen objetos, relaciones y dependenciasentre objetos, flujos de trabajo, etc.

2.4. Adopcion de herramientas CASE

Cuando una organizacion quiere adoptar una herramienta CASE, debemos considerar el proceso deseleccion de la herramienta (ya que no hay 2 organizaciones iguales), los pre-requisitos necesarios (debehaber comprension del proposito de las herramientas que se propongan en el ambiente de seleccion), y elconocimiento de la organizacion (para adaptarnos a la personalidad e infraestructura de la misma).

En el proceso de adopcion, siempre nos enfrentamos a diversos problemas:

Deficiencias de las herramientas CASE:

18

Tecnologıas CASE

Figura 2.5: Integracion completa

• Soporte parcial del ciclo de vida.

• Incompatibilidad con otras herramientas.

• Escasa integracion entre herramientas.

• Funcionalidad deficiente en entornos multiusuario.

• Alto coste. No solo por la herramienta sino por la plataforma que exige.

Deficiencias de la propia organizacion:

• Mala actitud de los directivos, que pretenden introducir una tecnologıa CASE como “salvacion”a todos sus males de desarrollo, sin contar con una buena base metodologica.

• Infravaloracion del esfuerzo requerido por parte del personal. Ası como economico.

• Inadecuada formacion.

• El no medir la productividad o rentabilidad resultante de la aplicacion de la tecnologıa.

2.4.1. Proceso de evaluacion y seleccion de herramientas

1. Proceso de iniciacion: Se fijan los objetivos y criterios de la evaluacion y seleccion, y se planifica elproceso general.

2. Proceso de estructuracion: Se elabora un conjunto de requisitos, que serviran para la evaluacion. Seidentifican las herramientas CASE candidatas.

3. Proceso de evaluacion: Se producen los informes tecnicos que serviran para la seleccion.

4. Proceso de seleccion: Se ultiman los criterios y se define el algoritmo de seleccion. En base a losresultados del proceso de evaluacion se determina el mejor candidato.

19


20

Entorno de desarrollo .NET

Capıtulo 3


3.1. Caracterısticas generales de .NET

3.1.1. ¿Que es .NET?

.NET es una plataforma de desarrollo, despliegue y ejecucion de aplicaciones orientadas a serviciossobre entornos altamente distribuidos. Cubre todas las capas de desarrollo de software, y es el resultado dela confluencia de dos proyectos:

El primero tenıa como objetivo la mejora del desarrollo sobre Windows, mejorando especialmente elmodelo COM.

El segundo es NGWS, que tenıa como objetivo la creacion de una plataforma para el desarrollo desoftware como servicio.

3.1.2. Objetivos de la tecnologıa .NET

La tecnologıa .NET proporciona un modelo de programacion simple y consistente, liberando al pro-gramador de las cuestiones de infraestructura –el framework .NET se encarga de gestionar la memoria, loshilos, etc–. Los principales objetivos de la tecnologıa .NET son los siguientes:

1. Proporcionar integracion 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 ejecucion 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 figura 3.1.

21


Figura 3.1: Componentes de la tecnologıa .NET

3.1.4. Lenguaje comun en tiempo de ejecucion (CLR)

El CLR puede considerarse el nucleo de .NET, desempenando el papel de maquina virtual –es el queposibilita la integracion entre varios lenguajes–. El CLR esta formado por 3 componentes (que estudiaremosdespues): Un sistema de tipos comun (CTS), un Sistema de metadatos, y un Sistema de ejecucion.

El CLR es muy util. Un fichero fuente puede contener la definicion de un tipo de objeto X. Al compilardicho fichero, se genera un fichero con codigo intermedio MSIL y metadatos (entre los que se encontraranlos correspondientes al tipo de objeto X). Pues bien, esos metadatos pueden ser utilizados para importardicho tipo en otro fichero de codigo (incluso de otro lenguaje).

Entre los servicios proporcionados por el CLR a las aplicaciones .NET se encuentran los siguientes:

1. Cargar y ejecutar el codigo MSIL.

2. Aislar la memoria de las aplicaciones, de forma que el codigo de un proceso no pueda acceder alcodigo o datos de otro.

3. Garantiza la robustez del codigo mediante la implementacion de un sistema de tipos comun (el CTS1).

4. Convierte el codigo intermedio MSIL a codigo nativo, utilizando tecnicas de compilacion Just InTime (JIT).

5. Gestion automatica de memoria.

6. Asegurar la seguridad en los accesos a los recursos.

7. Manejo de excepciones, incluso escritas en diferentes lenguajes.

8. Interoperabilidad con codigo no gestionado (como DLLs y objetos CCM).

9. Soporte de servicios a los desarrolladores (como la depuracion).

1Common Types System

22


Sistema de tipos comun (CTS)

Esta formado por un amplio conjunto de tipos y operaciones que se encuentran presentes en la mayorıade lenguajes de programacion. Define como se declaran, utilizan y gestionan los tipos en el CLR. Y es loque posibilita la interoperabilidad entre diferentes lenguajes de programacion.

En resumen, ofrece las siguientes funciones:

Establece un framework que permite la integracion de lenguajes, seguridad de tipos y ejecucion decodigo de alto rendimiento.

Proporciona un modelo orientado a objetos que soporta muchos lenguajes de programacion.

Define una serie de reglas que los lenguajes deben seguir para permitir la interoperabilidad.

Podemos ver los componentes del CTS en la figura 3.2.

Figura 3.2: Componentes del sistema de tipos comun (CTS)

Definicion de tipos

Una definicion de un tipo constituye un tipo nuevo a partir de los tipos existentes. Dentro de la definicionde un tipo pueden definirse los siguientes miembros:

Eventos: incidentes a los que se puede responder.

Campos: variables

Tipos anidados: definen un tipo dentro de la definicion del tipo que los contiene.

Metodos: 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 combinacion de una localizacion y una secuencia de bits. Las localizacionesdenotan las areas de memoria que pueden ser utilizadas, y poseen seguridad de tipos (para solo poderasignarle un tipo compatible).

Existen los siguientes tipos de referencias:

23


Clases: como en cualquier lenguaje orientado a objetos.

Delegados: son objetos con una finalidad similar a los punteros de C++.

Arrays

Interfaces: son especificaciones 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 informacion binaria que describe los tipos implementados por un programa. El sis-tema de metadatos permite almacenar dichos metadatos junto a los tipos a los que se refieran, en tiempo decompilacion, y obtenerlos en tiempo de ejecucion.

Los beneficios de la utilizacion de metadatos son los siguientes:

Proporcionan ficheros de codigo autodescriptivos, eliminando la necesidad del registro.

Proporcionan la informacion necesara para conseguir la interoperabilidad entre distintos lenguajes.

Proporcionan la informacion que necesita el sistema para la gestion de objetos.

Permite a .NET las invocaciones remotas.

Mediante los atributos es posible especificar aspectos mas detallados sobre el comportamiento delprograma en tiempo de ejecucion.

.NET almacena el codigo MSIL, junto con los metadatos, en una unidad autodescriptiva denominadaensamblado.

Sistema de ejecucion

La traduccion de MSIL a codigo nativo de la CPU es realizada por un compilador JIT2 o Jitter. El Jitterva conviertiendo dinamicamente el codigo MSIL en codigo nativo segun sea necesario. La compilacion JITtiene en cuenta el hecho de que algunas porciones de codigo no seran llamadas durante la ejecucion, porlo que en lugar de infertir tiempo y memoria en convertir todo el codigo, unicamente convierte el que esnecesario durante la ejecucion, almacenandolo por si volviera a ser necesario en el futuro.

El recolector de basura del sistema de ejecucion debe eliminar los objetos de la memoria cuando no vana ser referenciados nunca mas. El proceso de recoleccion de basura puede ser lanzado automaticamente porel CLR o invocado explıcitamente.

Para llevar a cabo la tarea de saber que objetos pueden ser borrados, el recolector mantiene las refer-encias raices (aquellos objetos referenciados directamente por la aplicacion), y obtiene, a su vez, todos losobjetos referenciados por cada una de esas raices, y ası sucesivamente. Los objetos por los que no hayapasado en este recorrido son los que puede borrar.

3.1.5. Especificaciones del lenguaje comun CLS

El CLR, mediante el sistema de tipos comun, o CTS, y los metadatos, proporciona la infraestructuranecesaria para lograr la interoperabilidad entre lenguajes. Todos los lenguajes siguen las reglas definidas enel CTS para la definicion y uso de los tipos, y los metadatos definen un mecanismo para el almacenamientoy recuperacion de la informacion de dichos tipos.

2Just In Time

24


Pese a esto, no hay ninguna garantıa de que un desarrollador de un lenguaje cualquiera defina un tipoque luego pueda ser utilizado por otros desarrolladores. Para asegurar que el codigo escrito en un lenguajesea accesible desde otros se ha definido la Especificacion del Lenguaje Comun o CLS (Common LanguageSpecification) que establece un conjunto mınimo de caracterısticas que deben soportarse para asegurar lainteroperabilidad, siendo dicho conjunto de caracterısticas mınimas un subconjunto del CTS.

El CLS se ha disenado para ser lo suficientemente grande como para que incluya las construcciones mascomunes de los lenguajes, y lo suficientemente pequeno para que la mayorıa de lenguajes lo cumplan.

3.2. Ensamblados (Assemblies)

3.2.1. Introduccion a los Ensamblados

Los ensamblados son colecciones de tipos y recursos, que proporcionan la informacion que el CLRnecesita sobre las implementaciones de dichos tipos. Los ensamblados pueden clasificarse, atendiendo a 3factores, en:

Ensamblados estaticos o dinamicos: los estaticos son generados en tiempo de compilacion, y alma-cenados en disco. Los dinamicos se generan en tiempo de ejecucion y son ejecutados desde memoria,pudiendo almacenarse en disco tras la ejecucion.

Ensamblados multifichero o con un unico fichero.

Ensamblados privados o compartidos: los ensamblados privados se utilizan unicamente en la apli-cacion para la que han sido desplegados, mientras que los compartidos pueden ser utilizados por masaplicaciones.

3.2.2. Caracterısticas de los Ensamblados

1. Contienen el codigo intermedio (MSIL) que sera ejecutado por el runtime, ası como los metadatosgenerados por el compilador, y el manifiesto del ensamblado.

2. Son unidades autodescriptivas, sin dependencia alguna del registro de Windows.

3. Definen una frontera de encapsulacion para los tipos que contienen. La identidad de un tipo quedaen parte definida por el ensamblado al que pertenece, por lo que dos tipos con el mismo nombre,definidos en ensamblados distintos, se consideran independientes.

4. El manifiesto del ensamblado contiene los metadatos utilizados para la obtencion de los tipos y re-cursos, 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 lostipos y recursos contenidos en el ensamblado.

6. Los ensamblados constituyen la unidad de despliegue, es decir, al arrancar una aplicacion solo losensamblados llamados al inicio tienen que estar presentes, pudiendo obtener el resto bajo demanda.

7. Permiten el aislamiento de aplicaciones. La existencia de ensamblados privados, ademas, favorece elaislamiento de aplicaciones, de forma que los cambios realizados no afecten al comportamiento delresto.

8. Los ensamblados definen un contexto de seguridad. En .NET, las medidas de seguridad son tomadasa nivel de ensamblado, quedando definidas en el manifiesto de los mismos.

9. Soportan ejecucion de multiples versiones simultaneas (slide-by-side execution).

25


3.2.3. Estructura de un ensamblado estatico

En general, la estructura logica de un ensamblado estatico consta de 4 elementos:

1. El manifiesto del ensamblado: contiene los metadatos del ensamblado.

2. Los metadatos de los tipos que contiene el ensamblado.

3. El codigo intermedio (MSIL).

4. Un conjunto de recursos.

Estos 4 elementos pueden estar dispuestos en un unico fichero o en varios. Estos ficheros, cuando contienenmetadatos (y a veces codigo MSIL tambien), son denominados modulos.

Estructura de ensamblados de un solo fichero

Un ensamblado puede estar formado por un unico modulo, estableciendose una correspondencia uno auno entre ensamblado y binario.

Figura 3.3: Estructura de ensamblados de un solo fichero

Estructura de ensamblados multifichero

En los ensamblados compuestos por varios ficheros fısicos, solo un modulo contiene el manifiesto,mientras que el resto de modulos solo contienen metadatos sobre los tipos y opcionalmente codigo inter-medio.

Los modulos que componen un ensamblado multifichero estan relacionados logicamente entre sı pormedio de la informacion del manifiesto, el cual referencia a los ficheros que componen el ensamblado.

3.2.4. Manifiesto de un Ensamblado

El manifiesto de los ensamblados es un conjunto de metadatos que describe como estan relacionadoslos elementos contenidos en el ensamblado (ya sea un ensamblado de uno o varios ficheros). El manifiestopuede ser almacenado en un fichero portable (.exe o .dll), junto a metadatos de tipos y codigo MSIL, o en unfichero portable que unicamente contiene el manifiesto (esto puede darse solo en ensamblados multifichero).

El manifiesto de un ensamblado contiene los siguientes elementos:

1. Identidad: un nombre, un numero de version, e informacion sobre el idioma/cultura del ensamblado.

2. Lista de ficheros del ensamblado: para cada fichero se almacena su nombre y un hash criptograficocon el contenido del fichero.

26


Figura 3.4: Estructura de ensamblados multifichero

3. Informacion sobre los ensamblados referenciados: una lista con la identificacion de los ensambla-dos referenciados de los que depende estaticamente.

4. Informacion sobre los tipos y recursos exportados: informacion relativa al mapeo de los tipos ylos ficheros fısicos que contienen sus metadatos e implementacion, lo que es utilizado en tiempo deejecucion.

5. Permisos solicitados: son tres grupos: los permisos requeridos para ejecutarse, los deseables, y losque 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 entreambos tipos, sino que la diferencia radica en el uso que se le da a los mismos. Realmente las diferenciasresiden en las convenciones de nombrado, polıtica de versiones y aspectos de despliegue.

Ensamblados privados

Nombrado El nombre de cada ensamblado, dentro de una misma aplicacion, debe ser unico.

Polıtica de versiones Ignorada.

Despliegue Los ensamblados privados son desplegados en el directorio local de la aplicacion o enuno de sus subdirectorios.

Ensamblados compartidos

Nombrado Utilizan los denominados nombres fuertes. Los nombres fuertes garantizan la unicidaddel nombre (empleando claves criptograficas, una privada y otra publica). Ademas previenen contrala suplantacion del nombrado (no se puede construir un ensamblado casero y cargarlo en lugar dela version de la aplicacion). Un nombre fuerte esta formado por un nombre amigable, un numero deversion, una clave publica y una firma digital.

Polıtica de versiones El control de versiones es de gran importancia. La polıtica de versiones consisteen informacion de la version, la cual debe ajustarse a unas polıticas.

27


Despliegue Los ensamblados compartidos son desplegados en la cache global de ensamblados (GAC).El mecanismo de almacenamiento de varias versiones de un mismo ensamblado es realizado au-tomaticamente.

3.2.6. Ejecucion simultanea de varias versiones de un Ensamblado

El runtime posee la habilidad de ejecutar multiples versiones de un mismo ensamblado de forma si-multanea. El runtime de .NET, concretamente permite esta ejecucion no solo en la misma maquina, sinotambien dentro del mismo proceso.

3.3. Administracion de datos con ADO.NET

3.3.1. ADO.NET

ADO.NET es una tecnologıa de acceso a datos, basada en los objetos ADO3 anteriores. Es un conjuntode clases que exponen servicios de acceso a datos al programador de .NET. Emplea XML como formato detransmision de datos.

ADO.NET emplea un modelo de acceso pensado para entornos desconectados. Esto quiere decir que laaplicacion 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 co-mo ocurrıa con ADO. Las principales ventajas de ADO.NET frente a ADO son la interoperabilidad, laescalabilidad 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 esta formado por los denominados proveedores gestionados, o Manager Providers, que sonutilizados para abrir conexiones con las bases de datos y ejecutar comandos sobre ellas. Este nivel es similara la infraestructura existente del ADO clasico.

ADO.NET proporciona dos tipos de proveedores: un proveedor de SQL (para servidores SQL de Mi-crosoft), y un proveedor OLEDB (para bases de datos de Oracle, Access, etc.).

Nivel desconectado de ADO.NET

Esta constituido por los denominados DataSets, que son conjuntos de datos que representan un conjun-to de tablas en memoria. Al tratarse de un modelo desconectado, es posible crear una serie de tablas en unDataSet o modificar los datos del mismo sin que la fuente de datos tenga constancia de los cambios. Ex-plıcitamente podemos actualizar el contenido de la base de datos con el contenido del DataSet, en cualquiermomento.

Un DataSet puede ser manipulado de forma programatica, es decir, creando en el una base de datosdesde cero; pero tambien puede ser cargado con los datos provenientes de una conexion a un proveedorgestionado, o a una fuente de datos XML.

3.3.2. Integracion de ADO.NET con XML

La integracion del ADO clasico con XML se basaba unicamente en que este poseıa una interfaz parala entrada y salida de datos en XML. Sin embargo, ADO.NET proporciona un soporte total de XML co-

3Objectos de Datos ActiveX

28


mo representacion de datos, de forma que los datos obtenidos de una fuente de datos son representadosinternamente y transmitidos como XML.

Los DataSets utilizan un esquema XML denominado XSD (XML Shema Definition) para representarla estructura de tablas y relaciones que contiene, de modo que los datos del DataSet son codificados deacuerdo a dicho esquema.

Por ultimo, anadir que la integracion de ADO.NET con XML resulta muy util para la transmision dedatos entre las distintas capas de una aplicacion.

3.3.3. Espacio de nombres para ADO.NET

System.Data: consiste en las clases que constituyen la arquitectura ADO.NET, que es el metodoprimario de acceso a los datos.

System.Data.Common: clases que comparten los proveedores de datos .NET Framework. Dichosproveedores describen una coleccion de clases que se utiliza para obtener acceso a un origen dedatos.

System.Data.OleDb: clases que componen el proveedor de datos de .NET Framework para orıgenesde datos compatibles con OLE DB.

System.Data.SqlClient: clases que conforman el proveedor de datos de .NET Framework para SQLServer, 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 paraOracle. 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 ob-jetos 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 datosSQL Server.

DataSet: para almacenar datos sin formato, datos XML y datos relacionales, ası como para configurarel 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. .NET frente a otras tecnologıas

3.4.1. .NET vs COM

.NET supera a COM, es mucho mas simple y consigue eliminar las deficiencias de este.

Uno de los problemas de COM es la limitacion de su sistema de informacion sobre tipos. Ademas, enCOM no existe una forma estandar de representar la informacion de tipos, sino que puede representarse enformato de texto mediante interfaces IDL o en forma binaria mediante librerıas.

29


El sistema de informacion de tipos de COM tampoco mantiene la informacion de dependencias decomponentes 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 informacion sobre los tipos, manteniendo ademasinformacion sobre las dependencias de un componente.

.NET elimina el denominado infierno de las DLLs4 que va asociado al modelo COM.

Los problemas de COM que generaban inconsistencias en el registro, causados por la separacion delcomponente y su descripcion, han sido solucionados en .NET mediante unidades autodescriptivas, los en-samblados.

3.4.2. .NET vs COM+

COM+ es una mejora del Servidor de Transacciones de Microsoft (MTS). COM+ amplio los serviciosproporcionados por MTS y mejoro 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+ comosistema proveedor de servicios de componentes, al menos de momento, ya que .NET carece de dichosservicios por sı mismo, y requiere de interoperabilidad con COM+ para ello. Este es uno de los aspectospor los que .NET denota cierta inmadurez, pues no ofrece por sı sola una serie de servicios que sı estanpresentes 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, ycuyas 2 diferencias principales son:

J2EE es una plataforma que utiliza unicamente el lenguaje Java, es multiplataforma y con multiplesproveedores de tecnologıa.

.NET es multilenguaje, esta disenada para una unica plataforma, Windows, y con un unico proveedor,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 comun detipos). Ambos modelos tambien poseen sistemas de acceso remotos (RMI en J2EE y el framework remotoen .NET), siendo en este aspecto algo mas potente .NET. Tambien es algo mas potente en el acceso a fuentesde datos, pues introduce la posibilidad de trabajar en modo desconectado con los denominados DataSet yesta altamente integrado con XML.

Ambas plataformas soportan el uso de delegados (skinny clients): J2EE posee los servlets y las paginasJSP, mientras que .NET posee ASP.NET.

Para el desarrollo de clientes pesados (fat clients), J2EE tiene Java Swing, y .NET WinForms. Ambossistemas son similares, y sus pequenas diferencias radican en el uso de eventos, que en Java se realizamediante clases internas y en .NET mediante delegados.

En cuanto al despliegue, ambos modelos son similares. En ambas plataformas los empaquetados con-tienen un manifiesto en el que expresan sus dependencias externas, ası como una serie de metainformacion.

La mayor diferencia entre .NET y J2EE viene dada por el runtime de ambas plataformas. La JVM(Maquina Virtual de Java) ha sido disenada para proporcionar soporte multiplataforma a Java, mientras queel CLR de .NET ha sido disenado, ademas de para ser multiplataforma, para ser independiente del lenguaje.

4Problemas relativos al manejo de versiones, que surgen cuando una DLL o componente COM es compartido por varias aplica-ciones.

30


Comparando los codigos intermedios (el bytecode de Java y el MSIL de .NET), MSIL es de mayornivel e introduce la seguridad de tipos, pudiendo ser verificado el codigo MSIL antes de su ejecucion, paragarantizar su seguridad. La ejecucion del codigo intermedio sigue esquemas distintos: en Java los bytecodesson interpretados, mientras que el CLR compila el codigo MSIL, obteniendo un mayor rendimiento.

Donde J2EE supera ampliamente a .NET es en los servicios de componentes, tales como persistenciaautomatica, transacciones, etc. Ademas, .NET no tiene servicios propios, sino que los toma de COM+, loque supone un factor en contra.

Si establecemos una comparacion entre las herramientas de desarrollo, J2EE tiene una amplia gama deIDEs de distintos proveedores, mientras que VisualStudio .NET es la unica herramienta de desarrollo para.NET. A pesar de esto, la integracion de VisualStudio .NET es mayor que la de las herramientas de J2EE, apesar de que algunas son igual o mas potentes que VS.

3.4.4. .NET vs CORBA

La plataforma .NET es mas amplia que la especificacion CORBA, pues cubre algunos aspectos notratados por esta (como las interfaces de usuario). .NET llega mucho mas lejos que CORBA, ademas, en loque se refiere a la integracion entre distintos lenguajes, pues en .NET una clase puede incluso heredar deotra escrita en otro lenguaje.

CORBA carece de portabilidad en la implementacion (a no ser que emplee Java, claro).

.NET dispone de un framework de objetos remotos, pero en este punto el framework CORBA superaampliamente al de .NET, como es de esperar. Ademas, CORBA es mas potente y extensible que .NET, sobretodo en lo relativo a las polıticas de configuracion de los objetos remotos.

Los servicios web proporcionados por .NET permiten un desarrollo de aplicaciones distribuidas muchomas ligero que el impuesto por CORBA o por los objetos remotos de .NET, pues bastarıa tener una librerıaSOAP o un parser XML para acceder al servicio web (veremos esto en el capıtulo siguiente).

A favor de CORBA esta el hecho de que se trata de una especificacion estandar, consensuada por lasdistintas organizaciones y empresas que forman el OMG5. Si CORBA no ha alcanzado la difusion que semerecıa es por la ausencia de entornos de desarrollo como VisualStudio.

3.5. El entorno Visual Studio .NET

3.5.1. Caracterısticas generales

Visual Studio .NET es un entorno integrado de desarrollo, independiente del lenguaje de programacion–incluso permite combinar varios lenguajes compartiendo una unica interfaz–.

Ofrece un mecanismo potente de depuracion extremo a extremo de las aplicaciones, independientementedel numero de proyectos, procesos y procedimientos.

A traves de un sistema de ventanas de ocultacion automatica (Auto-Hide), Visual Studio .NET nosofrece numerosos servicios, que estudiaremos a continuacion:

Ayuda dinamica (Dynamic Help)

Su objetivo es ofrecernos la informacion correcta en el momento oportuno, a traves de documentacionrelacionada en funcion de las caracterısticas y tecnologıas.

Por ejemplo, si abrimos el IDE, sin cargar ninguna aplicacion, el entorno ofrece enlaces de interes paracrear una aplicacion, elegir plantillas, etc. Conforme se avanza en el desarrollo de la aplicacion, el IDEanaliza parte de la misma y nos ofrece contenidos apropiados.

5Object Management Group

31


Editor visual de paginas web (Visual Web Page Editor)

Se trata de un editor de tipo WYSIWYG6, que permite desarrollar webs dinamicas sin entrar a fondo enel codigo HTML.

Ofrece algunas facilidades, como la complecion de sentencias y etiquetas HTML, la comprobacion desintaxis XML, y el posicionamiento absoluto de elementos.

Lista de tareas

Permite marcar el codigo con comentarios relacionados con las tareas que se necesitan realizar. Estas seanalizan sintacticamente y se muestran en un formato tabular.

Esta caracterıstica hace que resulte sencillo anotar el codigo de forma que, cuando uno mismo, ocualquier miembro del equipo lo vea, sea capaz de conocer el estado del codigo con un mınimo esfuer-zo.

Explorador de objetos

Conecta todos los objetos del sistema y proporciona informacion detallada acerca de cada uno. A travesde un sistema de filtrado podemos buscar la informacion que necesitemos sobre los objetos.

Ventana de comandos

Permite rapidez al proporcionar una unica lınea de acceso para buscar, explorar y ejecutar los numerososelementos, tanto de dentro como de fuera del IDE.

A traves de esta ventana de comandos podemos realizar busquedas, explorar ventanas y elementos dela solucion, ejecutar comandos, explorar el sitio web, y ejecutar programas externos.

6What You See Is What You Get.

32

Capıtulo 4

Servicios Web

4.1. Introduccion a los Servicios Web

4.1.1. Conceptos basicos

Los servicios web son modulos de software que realizan tareas discretas o conjuntos de estas, a los quese accede a traves de una red (sobre todo la World Wide Web). Un ejemplo es el servicio de seguimiento depaquetes 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 de-terminar si se ajustan a sus necesidades. Un desarrollador puede crear una aplicacion cliente que utiliceservicios 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 maneradistribuida. Esto significa que la aplicacion del servicio se estara ejecutando, respecto del cliente que loconsume, 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 mas reciente, y basicamente se diferencia en losprotocolos empleados para hacer la comunicacion. Estos tres mecanismos mencionados se basan en canalesy protocolos de conversacion que no fueron ideados para la WWW. Por ello encuentran problemas condispositivos de encauzamiento y seguridad.

Los servicios web utilizan SOAP (Simple Object Access Protocol) para la carga XML, y el protocoloHTTP para el transporte de los mensajes. Los mensajes SOAP son documentos XML que se envıan entreel servicio web y la aplicacion que efectua la llamada. Esta estandarizacion hace que tanto los serviciosweb como sus programas cliente puedan escribirse en cualquier lenguaje, y ser ejecutados en todas lasplataformas.

4.1.2. Arquitectura

La arquitectura de los servicios web permite desarrollar servicios que encapsulan todos los nivelesde funcionalidad. Es decir, los servicios web pueden ser muy simples (por ejemplo, uno que informe dela temperatura actual) o complejos. Incluso es posible combinar varios servicios web con el fin de crearnuevas funciones.

La arquitectura de los servicios web tiene 3 cometidos:

33


1. Proporcionar datos: como proveedor, crear el servicio web y ponerlo a disposicion de los clientes.

2. Solicitar datos: realizar la peticion de las aplicaciones cliente que consumen el servicio. El serviciosolicitado tambien puede ser un cliente/proveedor de otros servicios web.

3. Hacer de intermediario: permitir la interaccion entre las aplicaciones cliente y el proveedor.

Estos tres cometidos interaccionan por medio de las operaciones de publicacion, busqueda y enlace (verimagen). El proveedor utiliza la interfaz de publicacion del intermediario para comunicarle la existenciadel servicio web. Esa informacion publicada describe el servicio web e indica donde se encuentra. Laaplicacion que hace la solicitud consulta el intermediario para que busque los servicios web publicados.Con la informacion del intermediario, la aplicacion 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) independientedel transoporte –aunque SOAP especifica la forma en que sus mensajes se encaminan por medio de HTTP–. Utiliza mensajes unidireccionales, aunque es posible combinar mensajes en secuencias de solicitud yrespuesta.

Figura 4.2: Mensajes SOAP

Podos los documentos SOAP tienen un elemento raız, que consta de una cabecera (que contiene losdatos de encaminado, y puede estar vacıa) y el cuerpo (que contiene el mensaje propiamente dicho).

La especificacion SOAP tambien proporciona un patron de mensajerıa estandar para el comportamientotipo RPC: se emparejan dos mensajes de SOAP, uno de peticion y uno de respuesta. La llamada a un metodo

34


y sus parametros se serializan en el cuerpo del mensaje de peticion, con cada parametro codificado comoun subelemento XML. El mensaje de respuesta puede contener los resultados de la llamada o una estructurade fallo.

Las ventajas mas importantes de SOAP son:

No esta asociado con ningun lenguaje de programacion.

No se encuentra fuertemente asociado a ningun protocolo de transporte (como es XML, puede em-plearse cualquier protocolo capaz de transportar texto).

No esta atado a ninguna infraestructura de objeto distribuido.

Aprovecha los estandares existentes en la industria.

Permite la interoperabilidad entre multiples entornos.

4.3. WSDL: Web Services Description Language

Los servicios web solo resultan utiles si otras aplicaciones pueden reconocer que hacen y la forma dellamarlos. WSDL es un lenguaje basado en XML que se emplea para definir servicios web y describir laforma de acceder a ellos. Los desarrolladores deben examinar el documento WSDL de los servicios webpara averiguar que metodos hay disponibles y como se realizan las llamadas con los parametros adecuados.

Un documento WSDL se puede dividir en dos grupos de secciones: el grupo superior esta compuesto porlas definiciones abstractas, mientras que el inferior por las descripciones concretas. Las secciones abstractasdefinen los mensajes SOAP de una forma independiente a la plataforma y al lenguaje. Las descripcionesconcretas se emplean para las cuestiones especıficas del sitio, como la serializacion.

Definiciones abstractas

Elemento types:Contiene informacion del esquema de tipos de datos que emplea el documento. El sistema de tipospredeterminado es XML, pero se pueden emplear otros.

Elemento message:Proporciona una abstraccion comun para el paso de mensajes entre cliente y servidor. Es decir, de-fine los datos que se estan comunicando. Normalmente aparecen varios elementos Message en undocumento WSDL, uno para cada tipo de mensaje que se comunica.Los mensajes tienen uno o maselementos Part, que describen las partes del mensaje.

Elemento Operation:Descripcion abstracta de una accion admitida por el servicio.

Elemento portType:Contiene un conjunto de operaciones abstractas, que representan los tipos de correspondencia quepuede haber entre cliente y servidor. WSDL define 4 tipos de operaciones:

1. Request-response (peticion-respuesta): comunicacion tipo RPC, en la que el cliente lanza unapeticion y el servidor envıa la respuesta correspondiente.

2. One-way (un-sentido): comunicacion en la que el cliente envıa un mensaje pero no recibe unarespuesta del servidor.

3. Solicit-response (solicitud-respuesta): es la contraria al tipo peticion-respuesta: el servidor envıauna peticion y el cliente le envıa de vuelta una respuesta.

4. Notification (notificacion): La contraria a la operacion un-sentido: el servidor envıa una comu-nicacion al cliente.

35


Descripciones concretas

Elemento binding:Especifica los detalles de formatos del mensaje y protocolo. Por ejemplo, especifica si se puedeacceder a una instancia de un portType de forma RPC. Las definiciones binding tambien indican elnumero de comunicaciones de red que se requieren para realizar una determinada accion.

Elemento port:Punto final unico, definido como la combinacion del protocolo y del formato de datos para un tipo depuerto.

Elemento service:Un servicio es un grupo de puertos relacionados. Un puerto es un extremo concreto de un ServicioWeb al que se hace referencia por una direccion unica.

4.4. WSIL: Web Services Inspection Language

WSIL proporciona un metodo de descubrimiento de servicios para servicios web. Utiliza un modelodescentralizado y distribuido, en lugar de un modelo centralizado (UDDI1). Los documentos WSIL son,basicamente, punteros de listas de servicios que permiten a los clientes de servicios web examinar losservicios disponibles.

La norma WSIL establece la forma de utilizar documentos con formato XML para inspeccionar sitiosweb en busca de servicios y series de reglas que determinan la forma en que se proporciona la informacion.El proveedor del servicio web aloja el documento WSIL de forma que los consumidores puedan encontrarlos servicios disponibles.

4.5. Proceso de funcionamiento

4.5.1. Localizacion de servicios

Para que un servicio web sea util, y cumpla su funcion, es necesario que los potenciales consumidorespuedan localizarlo, identificar sus metodos y usarlos.

Todo comienza cuando el desarrollador del programa cliente tiene que localizar el servicio, para ellousa una regla general: un servicio de directorio UDDI. Un registro UDDI contiene meta-informacion sobreservicios web, incluyendo la URL donde se encuentran. Por ello, UDDI sirve como infraestructura parauna coleccion de software basado en servicios web. La informacion de UDDI se almacena en nodos deloperador (empresas que se han comprometido a ejecutar un nodo publico).

4.5.2. Descripcion del servicio

Una vez que se dispone de la informacion relativa a la localizacion del servicio, el siguiente paso esobtener una descripcion completa de ese servicio. Aquı entra en escena el lenguaje WSDL. WSDL y UDDIse disenaron para diferenciar los metadatos abstractos y las implementaciones concretas, las consecuenciasde esta division son 2:

1. WSDL distingue claramente los mensajes de los puertos. Los mensajes (sintaxis+semantica) de unservicio web son siempre abstractos, mientras que los puertos (las direcciones en las que se invocaun servicio web) son siempre concretos.

1Universal Discovery, Description and Integration

36


2. No es necesario que un archivo WSDL incluya informacion sobre el puerto, basta con tener infor-macion abstracta de la interfaz, sin facilitar datos de implementacion concretos. De este modo, losarchivos WSDL se separan de las implementaciones.

Pueden existir varias implementaciones de una unica interfaz WSDL.

UDDI establece una distincion similar entre la abstraccion y la implementacion, con el concepto detModels2. UDDI ofrece un mecanismo que permite publicar por separado los tModels de las plantillas deenlace que hacen referencia a ellos.

4.5.3. Llamada a los metodos

Partiendo de la descripcion del servicio, el consumidor llamara a los metodos que exponga el serviciousando mensajes SOAP.

4.5.4. Proceso

Toda la comunicacion entre el servicio y el consumidor se efectuara normalmente usando el protocoloHTTP, el mismo que se emplea para la navegacion web. Esto hace posible la superacion de elementos que,como los cortafuegos, suponen un obstaculo al utilizarse otras vıas de transmision.

2Technology Model. La estructura tModel representa las huellas digitales tecnicas, interfaces y tipos abstractos de metadatos. Elresultado de los tModels son las plantillas de enlace, que hacen referencia a una implementacion particular de un tModel.

37

hyep apuntes latex sgm.pdf

Documents