UNIVERSIDAD AUTÓNOMA DE TLAXCALA DEPARTAMENTO DE INGENIERÍA Y TECNOLOGÍA UNIDAD DE ESTUDIOS DE POSGRADO TESIS
|
|
- Dolores San Segundo de la Fuente
- hace 8 años
- Vistas:
Transcripción
1 UNIVERSIDAD AUTÓNOMA DE TLAXCALA DEPARTAMENTO DE INGENIERÍA Y TECNOLOGÍA UNIDAD DE ESTUDIOS DE POSGRADO PRUEBA DE COMPONENTES DE SOFTWARE BASADAS EN EL MODELO DE JAVABEANS TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INGENIERÍA EN COMPUTACIÓN PRESENTA: PERLA INÉS VELASCO ELIZONDO. DIRIGIDA POR: M.I. JUAN MANUEL FERNÁNDEZ PEÑA. M.C. MA. ELENA HERNÁNDEZ HERNÁNDEZ. APIZACO, TLAX. ABRIL DE 2001.
2 Dedico cariñosamente este trabajo a: Mis padres, porque con su invaluable apoyo pude iniciar y terminar esta nueva etapa. Mi hermana Lilia. Sodel, que comparte conmigo la emoción de este nuevo momento. Mi maestro y asesor Juan Manuel Fernández Peña.
3 Índice Resumen... 1 Abstract... 2 Introducción Sofware Basado en Componentes El concepto de componente El concepto de software basado en componentes Objetos y componentes Modelos para el desarrollo COM y DCOM Corba JavaBeans El bean development kit Revisión Técnica sobre Prueba de Software La prueba de software Objetivos de la prueba del software Métodos de prueba del software Pruebas de caja blanca Pruebas de caja negra Niveles de prueba del software Prueba de software para objetos Generalidades del modelo de desarrollo orientado a objetos Aspectos a considerar en la prueba del software orientado a objetos... 27
4 2.5.3 Métodos de prueba de software orientado a objetos Pruebas de unidad Pruebas de integración Pruebas de sistema Prueba de software basado en componentes Métodos de prueba de software basado en componentes Pruebas de unidad Pruebas de integración Descripción del Diseño Antecedentes La prueba de beans Aspectos de diseño Selección de los componentes La generación de casos de prueba La ejecución de casos de prueba La presentación de resultados Descripción de la Arquitectura e Implementación Arquitectura y colaboración entre clases La invocación de los servicios La extracción de archivos jar La generación de casos de prueba La ejecución de casos de prueba generados automáticamente La ejecución de casos de prueba generados manualmente La presentación de resultados... 73
5 5. Pruebas de Funcionamiento Los componentes utilizados El componente Puzzle Los resultados observados El componente TextEditor Los resultados observados El componente ProgressBar Los resultados observados Conclusiones Anexo A Anexo B Anexo C Referencias bibliográficas
6 Resumen. El desarrollo de software basado en componentes hace necesario contar con herramientas adecuadas; entre ellas se encuentran las herramientas de prueba. Los JavaBeans representan una forma de construir aplicaciones a partir de componentes preexistentes. Por el momento solo hay ayuda para probar aspectos gráficos de sus interfaces de usuario, pero no del funcionamiento interno de los beans. Este trabajo presenta una herramienta de prueba de componentes de software construidas bajo el modelo de JavaBeans. El objetivo de la herramienta es proveer al usuario de directrices que le permitan realizar las tareas de selección y evaluación de las componentes mediante la generación y ejecución automática de casos de prueba. 1
7 Abstract. Component-based software development makes necessary to have adequate tools; some of them are testing tools. JavaBeans are a way to build applications based in preexistent components. At present testing of interfaces graphical aspects is available, but testing beans internal behavior is not. This work presents a testing tool for software components using the JavaBeans model. Testing tool s objective is to offer guides to users on components selection and evaluation through automatic execution and generation of test cases. 2
8 Introducción. Actualmente el reuso de elementos preexistentes es una práctica común en la actividad de desarrollo de software. Situaciones como la competencia en el mercado para generar nuevos productos o actualizar versiones, han propiciado que muchos desarrolladores busquen nuevas opciones para generar software en tiempos muy cortos. Incluso, en ambientes de desarrollo no comercial, la actividad del reuso también se lleva a cabo; un simple ejemplo es la inclusión de bibliotecas o clases en los programas de un estudiante, con el fin de reutilizar funciones o métodos ya implementados. La creación de nuevas metodologías de desarrollo, cuyas características han permitido alcanzar en diversos grados la rápida construcción de programas, han considerado al reuso como una actividad básica, contribuyendo así a que esta se convierta en una alternativa atractiva en la construcción de software. El desarrollo orientado a objetos y el desarrollo basado en componentes, son ejemplos significativos de lo planteado anteriormente. A pesar de la aceptación alcanzada por estos enfoques, una de las más importantes limitaciones que surgen, es la falta de garantías que se tienen de que el o los elementos de software que se están reusando funcionen correctamente en todas las ocasiones, situación que influye considerablemente en la calidad de los productos que se desarrollan. Java Beans, actualmente es uno de los modelos de desarrollo basados en componentes con gran aceptación, factores como la independencia del sistema operativo, con lo que se pretende eliminar los problemas de plataforma y software, interoperabilidad y capacidad de trabajar en ambientes distribuidos, contribuyen a que el número de personas que utilizan este modelo este creciendo notablemente. A pesar de esto, el área de pruebas es poco robusta. Definitivamente, la prueba de software es una actividad que de una u otra manera es llevada a cabo en algún momento al menos por su desarrollador original. Para ello este puede planear y realizar un proceso de prueba enfocado a un ambiente en el que espera operará su producto. Aunque esto es aceptable, puede no ser suficiente. Muchas veces el ambiente de operación pensado por el desarrollador puede diferir del ambiente que se presenta para la 3
9 persona que utiliza finalmente dicho elemento de software, por lo que en la prueba desarrollada se pueden haber ignorado algunas situaciones. Así mismo, cuando una persona distinta al desarrollador desea probar un elemento que está reusando, el hecho de ser un elemento reutilizable, de los que generalmente no se tiene mucha información, dificulta esta actividad. En el caso de los componentes, que normalmente se ofrecen como productos terminados, no se dispone del código fuente, por lo que es difícil inspeccionar completamente su estructura interna. Este, además de otros factores propios del modelo de desarrollo impiden que un proceso de prueba pueda llevarse a cabo fácil y eficientemente. Actualmente son pocas las herramientas que permiten evaluar elementos preexistentes. Cuando alguien requiere integrar un elemento de software para construir una aplicación o simplemente para utilizarla de forma aislada, la evaluación que se realiza radica en la mayoría de los casos en una prueba manual, que en el peor de los casos no es nada sistematizada ni fundamentada. Si el usuario requiriera realizar una prueba más exhaustiva, esta prueba seria más amplia y formal, pero en raras ocasiones automatizada, por lo que para llevarla acabo se requiere una cantidad de tiempo considerable. Tomado como temas centrales el desarrollo basado en componentes y la prueba de software, el propósito de este trabajo es presentar una alternativa para la prueba de componentes. Esto se llevará a cabo mediante la implementación de una herramienta que permita realizar pruebas a componentes desarrollados bajo el modelo propuesto por Sun Microsystems, Java Beans. Haciendo uso de las funcionalidades que ofrecerá esta herramienta, se podrán realizar de forma automática la generación y ejecución de casos de prueba, de modo que con los resultados obtenidos en esta última actividad, el usuario de los componentes pueda tener algunas directrices que le permitan realizar con mayor facilidad las tareas de selección y evaluación de las mismas. 4
10 El tipo de prueba que realizará la herramienta es a nivel de unidad, utilizándose para ello técnicas de prueba funcional. Así mismo, los servicios que ofrecerá la herramienta estarán orientados a los usuarios de los componentes, más que a los desarrolladores originales. Con el propósito de describir el trabajo que se realizará para la creación de la herramienta, este trabajo se organiza fundamentalmente en dos partes, en la primera que comprende los capítulos 1 y 2, se presenta de acuerdo a una revisión bibliográfica los temas Software Basado en Componentes y Métodos de Prueba de software respectivamente, en los cuales se pretende proporcionar al lector un marco teórico de referencia con respecto al diseño de aplicación a desarrollar. La segunda parte que comprende de los capítulos 3 al 5, se concentra en la descripción de la herramienta implementada. Para ello en el capítulo 3 Descripción del Diseño, como su nombre lo indica, se presentarán las consideraciones con respecto al diseño de la herramienta de prueba. En el capitulo 4 Descripción de la Arquitectura e Implementación, se describen detalles referente a la implementación. En el quinto y último capitulo Pruebas de Funcionamiento, se presentan algunas de las pruebas realizadas con el propósito de verificar el adecuado funcionamiento de la aplicación. Al final de este documento, se encuentran secciones que contienen las conclusiones, obtenidas como producto de este trabajo, una sección en donde se citan las referencias bibliográficas, y anexos. El Anexo A que contiene información referente a los valores establecidos para la generación de casos de prueba. El anexo B contiene el manual del usuario de la herramienta. El anexo C presenta detalles de la notación utilizada para la descripción del diseño. 5
11 Capítulo 1 Software Basado en Componentes. Como respuesta a la necesidad de buscar alternativas que permitan hacer más fáciles las tareas de desarrollo e integración de software, uno de los más recientes modelos de desarrollo es el de componentes. Aspectos como el reuso y la interoperabilidad, muy importantes en la actualidad, son característicos de este enfoque. Puede visualizarse como un modelo de desarrollo bastante prometedor. Con el propósito de ofrecer información que permita al lector conocer sobre el desarrollo a partir de componentes, en este capítulo se presenta una descripción del modelo con base en sus principales características. Así mismo, al término de esta descripción, se presentarán tres modelos muy populares que actualmente se ofrecen en el mercado para construir software bajo esta modalidad: COM+/DCOM, CORBA, y Java Beans. 1.1 El concepto de componente. La palabra componente nos hace pensar en una unidad o elemento con propósito bien definido que, trabajando en conjunto con otras, puede ofrecer alguna funcionalidad compleja. Transportando este concepto al contexto de ingeniería de software, específicamente de desarrollo basado en componentes, un componente es la pieza elemental de este enfoque de desarrollo, de esta forma, a partir de componentes existentes pueden llegarse a construir aplicaciones completas. En términos formales, y de acuerdo con [MAR96], un componente es una pieza de software que cumple con dos características: no depende de la aplicación que la utiliza y, se puede emplear en diversas aplicaciones. Según se cita [SZY97], los asistentes a la ECOOP96 definen a un componente como una unidad de composición con interfaces definidas contractualmente y dependencias 6
12 contextuales explícitas solamente. Un componente de software puede desplegarse independientemente y estar sujeta a composición por terceros. El análisis de las ideas presentadas en estas definiciones y, de acuerdo con lo que plantea [FER99], se pueden identificar características en común: - Orientación al reuso, lo que nos hace pensar en algo que se puede tomar y utilizar más de una vez. - Interoperabilidad, el componente no puede solo usarse de forma aislada, sino que puede integrarse a otras y trabajar conjuntamente. - Función significativa, el componente tiene una función bien definida, identificable y diferenciable. - Encapsulamiento, generalmente los componentes ocultan detalles acerca de su implementación. Una definición más orientada a un enfoque de desarrollo, es la presentada en [DSO99] en la que un componente se define como un paquete coherente de una implementación de software que puede ser independientemente desarrollado y entregado, tiene interfaces explícitas y bien especificadas para informar los servicios que provee y espera de otros, puede estar constituido por otros componentes, quizás mediante la especialización de algunas de sus propiedades, sin que esto signifique modificar los componentes mismos. Tomando esta última definición se pueden enriquecer algunas de las características presentadas antes considerando también: - Una lista de interfaces proveídas y requeridas, las cuales representan mecanismos indispensables para la interoperabilidad de los componentes. 7
13 - Una especificación externa, medio que permite principalmente identificar la función del componente. - El código de validación, necesario para verificar, cuando se utilizan mas de un componente, si se conectaron correctamente. - El código ejecutable del componente. 1.2 El concepto de software basado en componentes. El concepto de software basado en componentes considera a todas aquellas aplicaciones que se construyen haciendo uso de componentes de software. En la definición presentada para este concepto por [DSO99], se habla de un enfoque de desarrollo de software en el cual todos los artefactos -desde código ejecutable para la especificación de la interfaz, arquitecturas, modelos de negocios, escalar aplicaciones completas y descomposición de sistemas en partes- pueden ser construidos por ensamble, adaptación y conexión de componentes existentes dentro de una variedad de configuraciones. Es claro que las características descritas para este enfoque de desarrollo suenan bastante atractivas; de hecho muchos autores resaltan algunas otras como el reuso de implementaciones e interfaces, la facilidad de mantenimiento y actualización de aplicaciones o la posibilidad de desarrollo en paralelo de diferentes partes de un sistema. Ante este panorama, es importante hacer mención de que al ser esta un área de investigación relativamente joven, existen muchos aspectos que aún no son lo suficientemente robustos. Carencias como el soporte disponible, la selección de componentes, el manejo de excepciones o bien la prueba de integración de componentes son situaciones que se destacan en [FER99]. 8
14 1.3 Objetos y componentes. Existen algunos aspectos comunes entre los objetos y los componentes que pueden hacer que estos se entiendan como conceptos equivalentes. Aunque hay similitudes, existen marcadas diferencias que permiten entenderlos como entidades diferentes, aunque no por ello excluyentes una de otra. Según [DSO99] los componentes son artefactos de software que representan el trabajo realizado por los desarrolladores. Por otra parte, un objeto se concibe como una instancia identificable creada en el sistema en ejecución, el cual es parte de un componente. Esta idea permite comprender que un componente puede contener uno o más objetos. En términos reales, un componente se manifiesta frecuentemente como una colección de objetos. Finalmente, con el propósito de diferenciar a los componentes de los objetos, a continuación se presentan algunas características que se destacan en [FER99] y [DSO99]: - Los componentes tienen persistencia, los objetos solo utilizan memoria. - Los componentes utilizan otras formas de comunicación como eventos, en lugar de limitarse al uso de mensajes como los objetos. - La granularidad de los componentes es mayor que la de los objetos, un componente puede presentarse como varios objetos de diferentes clases. - El paquete que contiene a el componente, incluye la especificación de las interfaces proveídas y requeridas, mientras que la en los objetos estas especificaciones se concentran en las operaciones proveídas. 9
15 1.4 Modelos para el desarrollo. La metodología de desarrollo basada en componentes, ha adquirido el respaldo de compañías importantes como Microsoft y Sun que han propuesto sus propios modelos de desarrollo. En las siguientes secciones se describen tres de los más populares actualmente, COM+/DCOM, CORBA y Java Beans COM y DCOM. El Component Object Model (COM), es la propuesta de Microsoft en materia de componentes, [MIC00]. Aunque inicialmente fue creado para resolver problemas en la construcción de documentos con OLE para Windows 3.1, este modelo ha sido enriquecido con el propósito de permitir la construcción de aplicaciones a partir de componentes. COM es esencialmente un esquema de integración, de modo que los componentes que se construyen para trabajar bajo este modelo, deben describir su comportamiento bajo las consideraciones de este esquema, el cual es popularmente conocido como estándar binario. Este estándar permite que las interfaces de los componentes se presenten a los clientes como un conjunto de apuntadores a tablas en memoria, llamadas tablas virtuales de funciones o vtables. El llamado de funciones entre componentes se realiza utilizando estos apuntadores, ocultándose así detalles de implementación, lo cual permite que componentes que estén escritos en diferentes lenguajes de programación de los que se pueden incluir a C++, Small Talk, Ada, VisualBasic, Delphi o Power Builder, puedan comunicarse. Dadas las características de las vtables, las interfaces no pueden definirse utilizando herencia múltiple, porque se deben considerar la posibilidad de tener varias vtables y más de un apuntador por interface. Las interfaces COM se definen utilizando un lenguaje especial denominado IDL. La compilación de estas interfaces, produce una especie de librerías que contienen información sobre los metadescriptores del objeto, de sus interfaces, de las estructuras definidas por el 10
16 usuario y de los elementos referidos por el componente, así como un mapa de memoria para las operaciones públicas. Distributed COM, mejor conocido como DCOM, es una extensión de COM que se implementa como una respuesta a la necesidad de aplicaciones distribuidas, proporcionando capacidades para el trabajo con componentes que residen en diferentes computadoras. DCOM utiliza como mecanismo de comunicación los llamados a procedimientos remotos (RPC), los cuales son transparentes para el cliente. Tanto COM como DCOM son modelos que inicialmente fueron implementados para trabajar bajo ambientes Windows y Windows NT, sin embargo actualmente existen versiones para operar con MacOS y UNIX. Como se mencionó inicialmente el funcionamiento de COM y DCOM, se basa estrictamente en el estándar binario, por lo que los componentes construidos para estos modelos no son del todo independientes de la plataforma, en caso de migrar a otros entornos, para poder utilizare los componentes necesitan ser recompilados para la plataforma en que se van a utilizar o bien, disponer el interprete del formato binario correspondiente CORBA. CORBA, Common Object Request Broker Architecture, es una infraestructura abierta para el manejo de objetos distribuidos que esta siendo estandarizada por el Object Management Group (OMG), [ORG00]. En CORBA, un objeto se considera como una instancia de una clase que encapsula operaciones, atributos y excepciones. CORBA permite que los objetos puedan comunicarse con otros sin necesidad de preocuparse por donde están localizados o por quien han sido diseñados. Para esto, se han considerado algunos elementos importantes como: un lenguaje de definición de interface (IDL) y una API que provee al programador la interacción cliente-servidor entre componentes con la implementación especifica de un Object Request Broker (ORB), el cual es una especie de infraestructura en CORBA que permite que los objetos puedan comunicarse. 11
17 Un componente expone un conjunto de interfaces, implementadas utilizando un lenguaje de definición llamado OMG Interface Definition Language (OMG IDL), mismas que definen las operaciones de los objetos. Actualmente existen estándares para el mapeo de un IDL a lenguajes de programación como C, C++, Java, Smalltalk, o Ada. Una vez que la interfaz se ha definido, se procede a generar dos archivos especiales, un archivo denominado stub para el cliente y, un archivo skeleton para el servidor, estos archivos son una especie de pegamento entre el cliente y el servidor con el ORB que le permiten acceder a sus interfaces. El Object Request Broker (ORB), provee un mecanismo para la comunicación transparente entre clientes y objetos, actuando como un intermediario para realizar la comunicación ya sea local o remota entre componentes. El ORB simplifica la programación distribuida desligando del cliente detalles sobre la invocación de los métodos. Para ello, intercepta la solicitud, encuentra el objeto que corresponde a dicha solicitud, invoca al método correspondiente y regresa el resultado. Al delegarse al ORB todas estas responsabilidades, el cliente no tiene que preocuparse por detalles sobre la localización del objeto, sobre el lenguaje de programación en el cual el objeto ha sido implementado, del sistema operativo, u otros aspectos propios del sistema JavaBeans. Actualmente uno de los modelos de desarrollo de software basado en componentes con mayor aceptación, es el propuesto por Sun Microsystems [SUN97], conocido como Java Beans. Java Beans es una API implementada para la construcción y uso de componentes escritos en Java, los cuales son comúnmente llamados Beans. Esta API es proporcionada por SUN como una herramienta visual que permite la carga, utilización, modificación, así como también interconexión de Beans, con el propósito de construir nuevos Beans, applets o bien aplicaciones completas. 12
18 Retomando la idea de [VAN98], una forma útil para describir a un Bean es comparándolo con una especie de caja negra; una unidad de la cual se conoce su funcionalidad pero no su implementación o estructura interna. Siendo un Bean un elemento de software sobre el cual solo se conoce su función, es preciso contar con algún mecanismo que permita la comunicación con él. En este modelo, ese mecanismo de comunicación consiste en una interfaz, a partir de la cual, se puede acceder a los elementos principales de un Bean: sus métodos, propiedades y eventos. En Java Beans, los métodos implementados en un Bean, especialmente los definidos con el prefijo set o get, son un medio para interactuar con el. Los métodos pueden entenderse como servicios con efectos específicos que el usuario puede invocar en algún momento. Las propiedades son conceptualmente equivalentes a lo que en el software tradicional se conocen como atributos, estos consisten en conjunto de características que un usuario puede leer o modificar haciendo uso de los métodos de acceso. Los eventos son utilizados por el Bean como un medio de comunicación con otros Beans. Un evento se presenta como un cambio de estado que el componente puede notificar a su ambiente. El evento lleva información de quién lo genera, así mismo puede llevar datos y aún objetos que migran de una clase a otra. Puesto que existen otros modelos de desarrollo basados en componentes, en Java Beans se han establecido algunas capacidades con el propósito de distinguirlo de otros. La característica más importante, es por supuesto, que el componente este escrito en Java, además de soportar las siguientes capacidades: a) Introspección, mecanismo mediante el cual se pueden descubrir las propiedades, métodos y eventos que un Bean contiene. 13
19 b) Soporte a propiedades, la posibilidad de conocer las características de los atributos y la capacidad de poder ser modificados a tiempo de diseño. c) Soporte a eventos, actividades como generación, escucha o respuesta a eventos con el propósito de comunicarse con otros Beans. d) Persistencia, capacidad para salvar y recuperar las especializaciones realizadas a un Bean. El modelo propuesto por Sun Microsystems, permite interrelacionar los componentes construidos bajo sus propias consideraciones con componentes de otros lenguajes y modelos, destacando principalmente la compatibilidad con el estándar de CORBA. Aunque los Beans han sido pensados para ser simples procesos locales, recientemente se ha propuesto una alternativa para trabajar con componentes remotos diseñadas para correr en un servidor y ser invocados por clientes, esta propuesta es conocida como Server Beans o Enterprise Java Beans (EJB) [SUN00]. Los EJB cuentan con mecanismos que les permiten ofrecer nuevos y mejores servicios entre los que destacan los de seguridad, manejo de transacciones, concurrencia y persistencia El Bean Development Kit. El Bean Development Kit (BDK), es un ambiente visual que permite construir y utilizar Beans. Con el propósito de realizar estas tareas, el BDK implementa tres elementos principales: el BeanBox, el ToolBox, y el PropertySheet. La apariencia de estos elementos, después de haberse seleccionado un Bean, se presenta en la Figura 1.1. El BeanBox, que es el lugar donde se visualiza y modelan algunos de los aspectos involucrados con el comportamiento de un Bean, en este espacio el usuario puede conectar Beans y definir como quiere que se realicen las interacciones entre ellos. Para esto, el 14
20 BeanBox ofrece al usuario un conjunto de menúes, que incluyen acciones como salvar el contenido actual del BeanBox -incluyendo aspectos como tamaño, posición, estado-, generación de applets a partir del contenido del BeanBox, cargar archivos JAR, realizar un reporte de introspección al Bean, listar los métodos que lanzan eventos, etc. Figura 1.1 Apariencia del BDK. En el BeanBox se presenta al usuario una vista, en tiempo de diseño, de lo que ocurriría cuando la aplicación se ejecute fuera de este ambiente de trabajo. Ya se ha mencionado que un componente puede estar conformado por varias clases, las cuales en este modelo deben estar contenidas en un archivo JAR. Un archivo JAR es muy similar a un archivo ZIP, es un archivo que comprime y almacena varios archivos. De hecho, la principal diferencia entre un archivo ZIP y un JAR, es que este último requiere de un archivo especial denominado MANIFEST.MF, que contiene la descripción de lo que contiene el JAR, dicho de otro modo, el archivo MANIFEST.MF almacena los meta datos del archivo JAR. 15
21 El ToolBox es un contenedor de Beans, el cual utiliza los archivos JAR localizados en un directorio predefinido dentro del ambiente de referencia, beans/jars. Los mecanismos implementados en el ToolBox examinan el contenido de estos archivos, de forma que puedan mostrarse los Beans contenidos en él y así, permitir al usuario seleccionar y posteriormente colocar los Beans dentro del BeanBox para su manipulación. Al iniciarse BeanBox, este carga de forma automática todos los Beans contenidos en los archivos JAR, sin embargo se pueden cargar JAR de forma manual mediante el menú File LoadJar del BeanBox. Ya se ha mencionado que la apariencia de un Bean puede cambiarse mediante la manipulación de sus propiedades, métodos y eventos; el PropertySheet muestra y permite modificar los valores de las propiedades de un Bean. Si se selecciona un Bean en el BeanBox, en el PropertySheet se despliegan los nombres de cada una de las propiedades y de sus valores actuales. Estos valores pueden ser editados por el usuario modificándose así la apariencia y comportamiento del Bean, aspectos que en muchos casos pueden ser apreciables desde el BeanBox. 16
22 Capítulo 2 Revisión Técnica sobre Prueba de Software. Cuando se desarrolla software, una de las actividades asociadas a este proceso es la prueba; de hecho, se ha establecido formalmente que la prueba es una actividad fundamental dentro de cada una de las etapas del proceso de desarrollo de software. La prueba es indispensable, puesto que a partir de ella se puede determinar la calidad de los productos implementados; a pesar de esto, no es difícil percibir como su importancia se ha subestimado y en ocasiones hasta ignorado. Desde hace ya mucho tiempo, la prueba ha sido un tema muy importante en la ingeniería de software, a partir de cual se han generado un gran número de trabajos. En este capítulo se presenta una revisión técnica sobre la prueba de software, abordándose fundamentalmente los enfoques de prueba propuestos para probar software construido bajo un enfoque funcional, orientado a objetos y basado en componentes. 2.1 La prueba de software. Para muchas de las actividades que lleva a cabo el ser humano, la prueba es una actividad necesaria que permite determinar la calidad de estas. Hoy por ejemplo, se realizan pruebas para determinar resistencia de determinados materiales, para determinar la vida útil de diversas maquinarias y equipos, o bien para verificar que ciertas tareas se realicen de forma correcta. Definitivamente la prueba es una actividad fundamental en muchos procesos de desarrollo, incluyendo el del software. De manera general, se puede decir que la prueba de software permite al desarrollador determinar si el producto generado satisface las especificaciones establecidas. Así mismo, una prueba de software permite detectar la presencia de errores que pudieran generar salidas o comportamientos inapropiados durante su ejecución. 17
23 De acuerdo a la IEEE [IEEE90] el concepto de prueba (testing) se define como: Una actividad en la cual un sistema o componente es ejecutado bajo condiciones especificas, se observan o almacenan los resultados y se realiza una evaluación de algún aspecto del sistema o componente. Cuando se habla de condiciones especificas en la definición anterior, se puede suponer la presencia de una especie de ambiente de operación de la prueba, para el cual deben existir determinados valores para las entradas y las salidas, así como también ciertas condiciones que delimitan a dicho ambiente de operación. Formalmente esto es conocido como caso de prueba. La IEEE [IEEE90] define un caso de prueba como: Un conjunto de entradas, condiciones de ejecución y resultados esperados diseñados para un objetivo particular. A partir de las definiciones anteriores y retomando las ideas presentadas en [WOH98] y [FER99], en un proceso de prueba de software, se pueden identificar las siguientes acciones: a) preparar una serie de casos de prueba, b) llevar a cabo dichos casos de prueba, c) decidir cuando suspender la prueba. d) evaluar los resultados generados por la prueba, e) emitir un criterio de evaluación. De lo anteriormente presentado surgen cuestionamientos como: cómo seleccionar casos de prueba representativos?, cuántas pruebas realizar? o bien cómo decidir si es o no de calidad el producto evaluado?, los cuales permiten entender que cada una de estas acciones 18
24 requiere especial atención. Por fortuna, actualmente existe una base teórica que permite guiar la puesta en marcha de estas actividades. Términos como falla, equivocación y error, pueden considerarse como sinónimos, sin embargo, dentro del contexto de prueba de software no es prudente realizar esta suposición. Con el propósito evitar confusiones y presentar al lector conceptos básicos en materia de pruebas, se presentan estas definiciones tomadas de [IEEE90] : a) Equivocación (mistake): Acción del ser humano que produce un resultado incorrecto. b) Defecto o falta (fault): Un paso, proceso o definición de dato incorrecto en un programa de computadora. El resultado de una equivocación. c) Falla (failure): Resultado incorrecto. El resultado de una falla. d) Error (error): Magnitud por la que el resultado es incorrecto. 2.2 Objetivos de la prueba de software. Un buen preámbulo, antes de establecer los objetivos de la prueba de software es recordar la afirmación realizada por Dijkstra en los años 70 y citada en [PRE98], en donde se plantea que el hecho de realizar una prueba no garantiza la ausencia de defectos, sino solamente se demuestra la existencia de éstos. 19
25 Como ya se mencionó en la sección anterior, la prueba de software se realiza con el propósito de encontrar algo que difiera a las especificaciones planteadas para el producto o bien, para detectar la presencia de situaciones que pudieran generar resultados inapropiados. Aunque a grandes rasgos estas razones pueden orientar el sentido de una prueba, en [MYE79] se presentan algunas normas que pueden servir como objetivos: a) La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. b) Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. c) Una prueba tiene éxito si se descubre un error. 2.3 Métodos de prueba de software. Desde hace ya algunos años, han surgido y evolucionado una variedad de métodos para realizar pruebas de software. Las alternativas más significativas en este contexto son las pruebas de caja blanca y las pruebas de caja negra; las primeras, pruebas orientadas a la estructura y las segundas al comportamiento del software. A continuación se hace una descripción de algunas de las propuestas que plantean cada una de estas alternativas, tomando material de las referencias [JOR95], [PRE98] y [KIT96] Pruebas de caja blanca. La pruebas de caja blanca enfocan su atención a los detalles procedimentales del software, por ello la implementación de estas pruebas depende fuertemente de la disponibilidad de código fuente. Este tipo de pruebas, permiten generar casos para ejercitar y 20
26 validar los caminos de cada módulo, las condiciones lógicas, los bucles y sus límites, así como también para las estructuras de datos. Las pruebas de caja blanca también son conocidas como pruebas de caja de cristal o pruebas estructurales. Algunas de las pruebas más significativas dentro de este enfoque son: - Prueba de caminos. En este tipo de prueba se realiza un análisis sobre una representación gráfica de un programa denominada grafo de control. En este grafo, los nodos representan bloques de instrucciones de un programa y los flujos de ejecución para dichas instrucciones se representan por medio de aristas. A partir de este grafo, se puede identificar un conjunto básico de caminos de ejecución, sobre el cual se pueden realizar pruebas con el propósito de ejercitar el flujo de ejecución de los caminos en una unidad. - Prueba de condiciones. Basándose de igual forma en un grafo de control, pueden generarse casos de prueba para elementos individuales de expresiones lógicas. De esta forma se pretende probar cada condición con todas sus posibles alternativas. - Prueba de ciclos. A partir del grafo de control, pueden generarse casos de prueba para las iteraciones definidas en los programas con el propósito de verificar si se realizan de forma correcta. - Prueba de definición de datos. Estas pruebas son realizadas con el objetivo de encontrar posibles contradicciones o redundancias en la definición de los datos utilizados en el software. Para ello se realiza un análisis del comportamiento de cada uno de los datos o cada una de los flujos de ejecución. 21
27 2.3.2 Pruebas de caja negra. Este tipo de pruebas, conocidas también como pruebas funcionales o pruebas de comportamiento, concentran la atención en generar casos de prueba que permitan ejercitar los requisitos funcionales de un programa. A diferencia de las pruebas de caja blanca, que se basan en la lógica interna del software, este tipo de pruebas se concentran en su funcionalidad, por lo que mucho del trabajo se realiza interactuando con la interfaz del software. Los casos de prueba generados en este enfoque, se diseñan a partir de valores entrada y salida. De esta forma, se puede determinar la validez de una salida para un conjunto de entradas proporcionadas. La aplicación de pruebas de caja negra permiten detectar errores como funciones incorrectas o ausentes, errores en estructuras de datos, errores de rendimiento, así como errores de inicialización y terminación. Estas son algunas de las pruebas más conocidas en este contexto: - Partición equivalente. La idea de esta técnica, es en dividir los valores válidos y no válidos para entradas y salidas en un número reducido de particiones de forma que, el comportamiento del software sea el mismo para cualquier valor contenido en una partición particular. El propósito principal de una partición es reducir la cantidad de casos de prueba generados en el proceso. - Análisis de los valores límite. La generación de casos de prueba en esta técnica, se enfoca en los valores limites, esto bajo la consideración de que existe una tendencia a fallar precisamente cuando el software trabaja con valores extremos de la variable de entrada. Generalmente los valores establecidos para generar los casos de prueba son el mínimo, valores un poco arriba del mínimo, valor máximo y valores un poco arriba del máximo. 22
28 - Pruebas según la experiencia (error guessing). Este tipo de prueba la generación de casos se realiza a partir de la intuición y la experiencia. La idea básica es redactar una lista de las posibles fallas o de las posibles situaciones en las cuales suele ocurrir algún problema y así desarrollar casos de prueba basados en la información contenida en estas listas. - Tablas de decisión. Este tipo de prueba permite describir el comportamiento de un programa a partir de un conjunto de acciones que este realiza cuando se opera bajo determinadas condiciones. En este enfoque, las condiciones pueden ser interpretadas como entradas de un programa y las acciones como las salidas producidas. Para ello se pueden utilizar conectores lógicos y (and), o (or) y no (not). Al involucrar aspectos de lógica, se dice que este tipo de prueba se hace más rigurosa, que permite además transformar una especificación en lenguaje natural en una especificación más formal. 2.4 Niveles de prueba del software. Un nivel de prueba permite especificar el alcance de la prueba de software que se realiza, se pueden identificar principalmente dos niveles: a) Bajo nivel. En este nivel están consideradas todas aquellas pruebas que se realizan a componentes individuales de un programa. Las pruebas que se pueden realizar en este nivel son: Pruebas de unidad. Como su nombre lo indica, este tipo de prueba se aplica a elementos de software individualmente, excluyendo todos aquellos casos en los que se considere la interacción con otras unidades. El propósito fundamental de una prueba de unidad es 23
29 descubrir diferencias entre la especificación del modulo de la interfaz y el comportamiento efectivo. Pruebas de integración Las pruebas de integración se realizan con el propósito de ejercitar la arquitectura de un sistema. Una vez que ya se han probado que las unidades funcionan de forma correcta de forma aislada, se procede a probar cómo funcionan al integrarlas con otras de forma que se llegue a probar el comportamiento de un sistema final. La forma en que se pude organizar la integración de las unidades para la prueba puede realizarse siguiendo enfoques como el ascendente, descendente, big bang, o sandwich. b) Alto nivel. En éste nivel las pruebas se orientan a un producto completo; para ello se proponen las siguientes alternativas: Pruebas de sistema Este tipo de pruebas permiten probar el sistema como un todo así como también aspectos relacionados con la integración del producto a otros sistemas. Pruebas de usabilidad. El diseño de pruebas de usabilidad, requiere considerar a los usuarios que trabajan con el producto, con el propósito de observar sus respuestas hacia éste. De ésta forma se pueden observar discrepancias existentes entre las interfaces implementadas y los requerimientos de los estilos de trabajo de los usuarios finales. Pruebas de función. Este tipo de pruebas tiene como objetivo detectar inconsistencias entre la especificación funcional de un programa y su comportamiento actual. 24
30 Pruebas de aceptación. Realizando estas pruebas se puede comparar el producto final con las necesidades finales de los los usuarios. Pruebas de regresión. Las pruebas de regresión son recomendables cuando partes del software se modifican, ya que permiten verificar que los cambios realizados no generan comportamientos no deseados. 2.5 Prueba de software para objetos. Como consecuencia de las facilidades y beneficios que ofrece, actualmente una de las nuevas alternativas para desarrollo de software con mayor aceptación es la metodología orientada a objetos. Si bien es cierto que este nuevo enfoque ha sido adoptado por muchos, es también cierto que estas personas han tenido que enfrentarse y adaptarse a cambios bastante significativos. Conceptos como objeto, herencia y encapsulación marcan una nueva perspectiva que contrasta con los modelos de desarrollo anteriormente utilizados. Esta nueva percepción ha impedido que áreas de vital importancia, como la prueba de software, no hayan alcanzado el desarrollo y la robustez que requieren. Es importante destacar que mucho del software que se está fabricando hoy es orientado a objetos, por lo resulta evidente la necesidad de contar con herramientas o al menos guías de acción para realizar esta actividad. Esta falta de trabajos quizá sea debida a la suposición y afirmación inicial de algunos autores de que el software orientado a objetos, al tener como una característica esencial el reuso, está propenso a presentar menos errores que el software construido usando las metodologías tradicionales. Lamentablemente las experiencias obtenidas han demostrado que no es así. 25
31 2.5.1 Generalidades del modelo de desarrollo orientado a objetos. En cierto grado algunos de los conceptos de la orientación a objetos han estado presentes en los lenguajes de programación que se han utilizado; sin embargo la programación orientada a objetos aparece formalmente durante la década de los 80, como una alternativa de desarrollo de software que ofrece características muy atractivas: mejor modularidad en los programas, mayor flexibilidad y una de las más significativas el reuso, característica nada despreciable en ambientes de trabajo donde se requiere construir software en tiempos muy cortos. De acuerdo con [PER90], la programación orientada a objetos puede definirse como la descripción de tareas en términos de los objetos que la misma tarea envuelve, así como de las propiedades de dichos objetos. A pesar de lo simple de la definición, se puede apreciar que un elemento muy representativo en este modelo es el objeto. Profundizando sobre este tema, es posible decir que la programación orientada a objetos gira en torno a dos conceptos: el objeto y la clase. En los lenguajes de programación imperativos, los elementos más significativos son las estructuras de datos y los procedimientos, los cuales aparecen en forma desligada. En el modelo orientado a objetos, existe una unidad que conjunta estos elementos, esta unidad es el objeto. La definición formal de un objeto esta contenida en una clase a la que pertenece. Esta definición contiene las características del objeto, las cuales se modelan en términos los atributos, datos que el objeto utiliza, y los métodos que son las funciones que manipulan a estos datos. A continuación se presentan descripciones mas amplias de clase y objeto, que permitirán tener una mejor comprensión de lo mencionado anteriormente: 26
32 Según [KIR94], un objeto tiene un estado y un comportamiento. El estado del objeto lo determina un conjunto de atributos. El comportamiento de un objeto está definido por el conjunto de métodos del objeto. Una clase describe el comportamiento común de un grupo único de objetos. Describe todos los métodos y los atributos de esos objetos. Los objetos son creados mediante la instanciación de clases. Para [PER90], un objeto es un entidad instanciada la cual tiene: 1. un conjunto de operaciones a las cuales responde, 2. un estado el cual es afectado por un subconjunto de operaciones, 3. la habilidad de enviar mensajes a otros objetos para invocar operaciones. Una clase especifica las propiedades de un objetos y contiene: 1. una interfaz la cual detalla como se accede a las propiedades públicas de la clase, 2. un cuerpo de código que implementa las operaciones definidas en la interfaz, y 3. variables de instancia, las cuales implementan el estado del objeto. Además de clase y objeto, existen otros conceptos relacionados con esta forma de programación; encapsulación, polimorfismo y herencia, son algunos de los más destacables. En la siguiente sección se abordan cada uno de ellos, dentro del contexto de prueba de software Aspectos a considerar en la prueba de software orientado a objetos. Al igual que el software construido utilizando otros enfoques de desarrollo, todo producto construido a partir del modelo orientado a objetos requiere ser sometido a pruebas con el propósito de garantizar su calidad. En términos generales, se puede decir que los dos enfoques mas representativos en materia de pruebas, de caja blanca y de caja negra, son aplicables al software orientado a objetos en cierta medida. Sin embargo como se menciona en 27
33 [FER99], existen algunas características del software orientado a objetos que generan problemas adicionales no cubiertos por las técnicas tradicionales de prueba. Existe una referencia común en [BIN95-A], [PER90] o [FER99], acerca de que la unidad básica para la prueba de software orientado a objetos es la clase. A pesar de ello, cuando se prueba al software orientado a objetos, no es posible realizar una prueba para una clase por sí misma, sino que hay que realizarla para una instancia de ésta, es decir para un objeto. Una característica importante del enfoque orientado a objetos es la encapsulación. Un objeto encapsula su estado y sus funciones asociadas. La abstracción, concepto que define la capacidad de solo destacar las características esenciales de un objeto de tal forma que se puede separar su comportamiento esencial de su implementación, va estrechamente ligada con la encapsulación. Indudablemente la posibilidad de poder encerrar dentro de un contenedor físico o lógico elementos como arreglos, registros o incluso objetos parece ser muy atractiva para ciertas actividades, sin embargo en el contexto de prueba esto no es realmente una ventaja. Como se cita en [BAS99], el ocultar todos los detalles del objeto que no contribuyen a sus características esenciales, por ejemplo su estructura y la implementación de sus métodos, hace que parte de un objeto sea inaccesible para el mundo. Naturalmente, esto obstaculiza la eficiencia de las pruebas, ya que para realizarlas, en algún momento se requiere monitorear el estado de un objeto. Esto es difícil de realizar con características como la encapsulación y la abstracción, pues la dificultad de visualizar el estado interno del objeto impide consultar información que podría requerirse para el desarrollo de la prueba. [BIN95-A]. Por otra parte, la herencia es otra de las características que han venido a facilitar en gran medida el desarrollo de sistemas, la posibilidad de que una clase pueda ser escrita en términos de variaciones de otras clases es una ventaja significativa. Puede pensarse que esto apoya la prevención de fallas al construir software. Desgraciadamente, se ha comprobado que. mediante esta práctica, se tienen muchas posibilidades de cometer errores, porque 28
34 generalmente los elementos heredados son sometidos a algún tipo de refinamiento o redefinición y en algunos casos eliminación de componentes [FER99]. Cuando un objeto es creado a partir de características heredadas, se genera un nuevo contexto que puede ser diferente al que pudiera crearse por la clase antecesesora si esta trabajara de manera aislada y, por tanto, presentarse problemas ante situaciones no previstas en el nuevo contexto. Todas estas situaciones hacen que autores como [BIN95-A], afirmen que realizar una prueba a los métodos heredados debe ser una regla más que una excepción. La herencia en cierta medida trae como consecuencia reuso, lo que genera una interrogante común con respecto a la formulación de las pruebas: las subclases de una clase que ya ha sido probada deben de ser probadas nuevamente?. Si la respuesta es sí, en referencias como [PER90], se habla de diferentes niveles de herencia lo que incrementa el número de pruebas a realizar. Así mismo, en [BIN95-B] se afirma que el reuso no garantiza que el software esté exento de errores, ya que no es posible determinar si un número suficiente de rutas y estados hayan sido ejercitados. Otro aspecto que determina la dificultad de las pruebas que se realizan al software orientado a objetos es el polimorfismo. En [BIN95-A] se explica que cada vez que se realiza una instancia diferente de un objeto como producto del polimorfismo en los métodos, se requiere una prueba separada. Realizar una prueba separada para cada una de la formas de un método es una tarea difícil, la complejidad y el tiempo requerido crece considerablemente cuando se tienen que definir todos los posibles errores y obstáculos que pueden presentarse. En los sistemas orientados a objetos, el flujo de control se lleva a cabo mediante el paso de mensajes entre objetos. Cuando un mensaje es enviado de un objeto u otro, la consecuencia es, generalmente, que el objeto receptor ejecute alguna operación para examinar o alterar su estado. En [PER90] hace hincapié que el paso de mensajes es un punto fundamental al realizar la prueba. Si bien estos son algunos de los aspectos más significativos y de referencia común en revisiones bibliográficas, de igual forma pueden mencionarse la dependencia de estado, el 29
PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE
PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,
Más detallesElementos requeridos para crearlos (ejemplo: el compilador)
Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción
Más detallesPRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE
VI PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE 6.1 PRUEBAS DEL SOFTWARE Una vez generado el código el software debe ser probado para descubrir el máximo de errores posibles antes de su entrega al cliente.
Más detallesCapítulo 5. Cliente-Servidor.
Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor
Más detallesFundamentos del diseño 3ª edición (2002)
Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software
Más detallesPlan de estudios ISTQB: Nivel Fundamentos
Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE
Más detallesIngeniería de Software. Pruebas
Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en
Más detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer
Más detallesUNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos
2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven
Más detallesProceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:
PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo
Más detallesSERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO
SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3
Más detallesCAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar
CAPITULO 4 Requerimientos, Análisis y Diseño El presente capítulo explica los pasos que se realizaron antes de implementar el sistema. Para esto, primero se explicarán los requerimientos que fueron solicitados
Más detalles1. Descripción y objetivos
Pruebas 1 1. Descripción y objetivos Las pruebas son prácticas a realizar en diversos momentos de la vida del sistema de información para verificar: El correcto funcionamiento de los componentes del sistema.
Más detallesEntidad Formadora: Plan Local De Formación Convocatoria 2010
Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú
Más detallesI INTRODUCCIÓN. 1.1 Objetivos
I INTRODUCCIÓN 1.1 Objetivos En el mundo de la informática, la auditoría no siempre es aplicada en todos las empresas, en algunos de los casos son aplicadas por ser impuestas por alguna entidad reguladora,
Más detalles3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)
3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.
Más detallesARQUITECTURA DE DISTRIBUCIÓN DE DATOS
4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia
Más detallesIntroducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual
Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los
Más detallesUnidad III. Software para la administración de proyectos.
Unidad III Software para la administración de proyectos. 3.1 Herramientas de software para administrar proyectos. El software de administración de proyectos es un concepto que describe varios tipos de
Más detallesMejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos
ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados
Más detallesSISTEMAS DE INFORMACIÓN II TEORÍA
CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR
Más detallesCapítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN
CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN CONCEPTOS DE PRUEBAS DE APLICACIÓN El departamento de Testing se encarga de diseñar, planear y aplicar el rol de pruebas a los sistemas que el PROVEEDOR
Más detallesCapitulo III. Diseño del Sistema.
Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje
Más detallesSÍNTESIS Y PERSPECTIVAS
SÍNTESIS Y PERSPECTIVAS Los invitamos a observar, a identificar problemas, pero al mismo tiempo a buscar oportunidades de mejoras en sus empresas. REVISIÓN DE CONCEPTOS. Esta es la última clase del curso.
Más detallesDiseño orientado al flujo de datos
Diseño orientado al flujo de datos Recordemos que el diseño es una actividad que consta de una serie de pasos, en los que partiendo de la especificación del sistema (de los propios requerimientos), obtenemos
Más detallesVentajas del software del SIGOB para las instituciones
Ventajas del software del SIGOB para las instituciones Podemos afirmar que además de la metodología y los enfoques de trabajo que provee el proyecto, el software, eenn ssi i mi issmoo, resulta un gran
Más detalles6.4 ESTRATEGIAS DE PRUEBA
Prueba del sistema Prueba de validación Prueba de integración Prueba de Unidad Código Diseño Requisitos Ingeniería del Sistema Las pruebas del software aplican similar estrategia moviéndonos de adentro
Más detallesResumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software
Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril
Más detallesColección de Tesis Digitales Universidad de las Américas Puebla. Morales Salcedo, Raúl
1 Colección de Tesis Digitales Universidad de las Américas Puebla Morales Salcedo, Raúl En este último capitulo se hace un recuento de los logros alcanzados durante la elaboración de este proyecto de tesis,
Más detallesOMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento
OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje
Más detallesIntroducción a la Firma Electrónica en MIDAS
Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento
Más detallesLa utilización de las diferentes aplicaciones o servicios de Internet se lleva a cabo respondiendo al llamado modelo cliente-servidor.
Procesamiento del lado del servidor La Programación del lado del servidor es una tecnología que consiste en el procesamiento de una petición de un usuario mediante la interpretación de un script en el
Más detallesSistema de Mensajería Empresarial para generación Masiva de DTE
Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE
Más detallesCAPÍTULO 3 VISUAL BASIC
CAPÍTULO 3 VISUAL BASIC 3.1 Visual Basic Microsoft Visual Basic es la actual y mejor representación del viejo lenguaje BASIC, le proporciona un sistema completo para el desarrollo de aplicaciones para
Más detallesPROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...
Tabla de Contenido PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... 2 1. LA PRESENCIA DE INFORMACIÓN Y AYUDA ÚTIL PARA COMPLETAR LOS TRÁMITES EN LÍNEA.... 2 2. LA DISPONIBILIDAD DE DIVERSOS
Más detalles1.1.- Objetivos de los sistemas de bases de datos 1.2.- Administración de los datos y administración de bases de datos 1.3.- Niveles de Arquitectura
1. Conceptos Generales 2. Modelo Entidad / Relación 3. Modelo Relacional 4. Integridad de datos relacional 5. Diseño de bases de datos relacionales 6. Lenguaje de consulta estructurado (SQL) 1.1.- Objetivos
Más detallesCORPORACIÓN MEXICANA DE INVESTIGACIÓN EN MATERIALES, S.A. DE CV
Página 1 de 6 1. OBJETIVO El presente documento tiene la finalidad de citar los beneficios de la migración de la herramienta de análisis de riesgo, mantenimiento e inspección que en lo sucesivo se denominará
Más detalleshttp://www.cem.itesm.mx/extension/ms
Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos
Más detallesEl presente documento describe la importancia que está tomando el cómputo distribuido en
INTRODUCCIÓN El presente documento describe la importancia que está tomando el cómputo distribuido en los sistemas de administración integral o empresarial. Con un prototipo particular, mostraremos como
Más detallesWorkflows? Sí, cuántos quiere?
Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención
Más detallesK2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2
K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2 Historia de revisiones Fecha VersiónDescripción Autor 08/10/2009 1.0 Creación del documento.
Más detallesFigure 7-1: Phase A: Architecture Vision
Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como
Más detallesJAVA EE 5. Arquitectura, conceptos y ejemplos.
JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones
Más detallesPropuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA
Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)
Más detallesHaga clic en los recuadros donde indica la mano y regrese al inicio del capítulo al hacer clic en el título de la sección donde se encuentra
Cómo gestiono el Plan Anual de Adquisiciones de mi Entidad en el SECOP II? Crear equipo Crear Plan Anual de Adquisiciones Publicar Plan Anual de Adquisiciones Modificar Plan Anual de Adquisiciones Buscar
Más detallesCAPÍTULO 2 Sistemas De Base De Datos Multiusuarios
CAPÍTULO 2 Sistemas De De Multiusuarios Un sistema multiusuario es un sistema informático que da servicio, manera concurrente, a diferentes usuarios mediante la utilización compartida sus recursos. Con
Más detallesCAPÍTULO I. Sistemas de Control Distribuido (SCD).
1.1 Sistemas de Control. Un sistema es un ente cuya función es la de recibir acciones externas llamadas variables de entrada que a su vez provocan una o varias reacciones como respuesta llamadas variables
Más detallese-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red.
Comercio electrónico. (e-commerce) Las empresas que ya están utilizando la red para hacer comercio ven como están cambiando las relaciones de la empresa con sus clientes, sus empleados, sus colaboradores
Más detallesModificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.
UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:
Más detallesUsos de los Mapas Conceptuales en Educación
Usos de los Mapas Conceptuales en Educación Carmen M. Collado & Alberto J. Cañas Introducción Los mapas conceptuales son una poderosa herramienta de enseñanza-aprendizaje. Su utilización en (y fuera de)
Más detallesEmpresa Financiera Herramientas de SW Servicios
Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través
Más detallesSoporte Técnico de Software HP
Soporte Técnico de Software HP Servicios Tecnológicos HP Servicios contractuales Datos técnicos El Soporte Técnico de Software HP ofrece servicios integrales de soporte remoto de para los productos de
Más detallesRECOMENDACIONES DE INVESTIGACIÓN FUTURA.
Capítulo 6 CONCLUSIONES Y RECOMENDACIONES DE INVESTIGACIÓN FUTURA. 212 METODOLOGÍA PARA LA DETECCIÓN DE REQUERIMIENTOS SUBJETIVOS EN EL DISEÑO DE PRODUCTO. CAPÍTULO 6. CONCLUSIONES, APORTACIONES Y RECOMENDACIONES.
Más detallesGuía Metodológica para el diseño de procesos de negocio
Guía Metodológica para el diseño de procesos de negocio La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el desarrollo BPM, principalmente en aquellas que soportan
Más detallesActividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.
Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas
Más detallesArquitectura de sistema de alta disponibilidad
Mysql Introducción MySQL Cluster esta diseñado para tener una arquitectura distribuida de nodos sin punto único de fallo. MySQL Cluster consiste en 3 tipos de nodos: 1. Nodos de almacenamiento, son los
Más detallesIntroducción. Componentes de un SI. Sistema de Información:
Introducción. Sistema de Información: Conjunto de elementos relacionados entre sí de acuerdo a ciertas reglas, que aporta a la organización la información necesaria para el cumplimiento de sus fines, para
Más detallesTécnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE
Técnicas de prueba El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de
Más detallesE-learning: E-learning:
E-learning: E-learning: capacitar capacitar a a su su equipo equipo con con menos menos tiempo tiempo y y 1 E-learning: capacitar a su equipo con menos tiempo y Si bien, no todas las empresas cuentan con
Más detallesSistema de marketing de proximidad
Dizan Vasquez Propuesta de proyecto Sistema de marketing de proximidad ACME México Dizan Vasquez Índice general 1. Descripción 3 2. Resúmen ejecutivo 4 2.1. Objetivo.................................................
Más detalles1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).
1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada
Más detallesDiseño orientado a los objetos
Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia
Más detallesDiseño de Base de Datos
Diseño de Base de Datos DISEÑO DE BASE DE DATOS 1 Lectura No. 2 Nombre: Arquitectura Cliente-Servidor Contextualización Qué es la arquitectura Cliente-Servidor? En la nueva de las comunicaciones a través
Más detallesIntroducción a las redes de computadores
Introducción a las redes de computadores Contenido Descripción general 1 Beneficios de las redes 2 Papel de los equipos en una red 3 Tipos de redes 5 Sistemas operativos de red 7 Introducción a las redes
Más detallesUnidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación.
Unidad II Metodología de Solución de Problemas 2.1 Descripción del problema (enunciado). Este aspecto nos indica describir de manera objetiva la realidad del problema que se esta investigando. En la descripción
Más detallesLos mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:
SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas
Más detalles6 Anexos: 6.1 Definición de Rup:
6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.
Más detallesGUIA PROGRAMACIÓN ORIENTADA A OBJETOS
GUIA PROGRAMACIÓN ORIENTADA A OBJETOS 1. Por qué la P.O.O? R= A medida que se van desarrollando los lenguajes, se va desarrollando también la posibilidad de resolver problemas más complejos. En la evolución
Más detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para
Más detallesM.T.I. Arturo López Saldiña
M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil
Más detallesVisión General de GXportal. Última actualización: 2009
Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de
Más detallesNovedades en Q-flow 3.02
Novedades en Q-flow 3.02 Introducción Uno de los objetivos principales de Q-flow 3.02 es adecuarse a las necesidades de grandes organizaciones. Por eso Q-flow 3.02 tiene una versión Enterprise que incluye
Más detalles2.1 Clasificación de los sistemas de Producción.
ADMINISTRACION DE OPERACIONES Sesión 2: La Administración de operaciones II Objetivo específico 1: El alumno conocerá la clasificación de los sistemas de producción, los sistemas avanzados de manufactura
Más detallesGUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000
1 INTRODUCCIÓN Dos de los objetivos más importantes en la revisión de la serie de normas ISO 9000 han sido: desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas
Más detallesCAPÍTULO 1 Instrumentación Virtual
CAPÍTULO 1 Instrumentación Virtual 1.1 Qué es Instrumentación Virtual? En las últimas décadas se han incrementado de manera considerable las aplicaciones que corren a través de redes debido al surgimiento
Más detallesSISTEMA DE PAPELES DE TRABAJO PARA AUDITORÍA SPT AUDIT
SISTEMA DE PAPELES DE TRABAJO PARA AUDITORÍA SPT AUDIT INTRODUCCIÓN La documentación de auditoría ó papeles de trabajo son el respaldo que tiene el auditor para registrar los procedimientos aplicados,
Más detalles4. Programación Paralela
4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios
Más detallesINTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS
INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS AUTORÍA JOSEFA PÉREZ DOMÍNGUEZ TEMÁTICA NUEVAS TECNOLOGIAS ETAPA CICLOS FORMATIVOS DE GRADO SUPERIOR DE INFORMÁTICA Resumen En esta publicación se
Más detallesCurso de Java POO: Programación orientada a objetos
Curso de Java POO: Programación orientada a objetos Luis Guerra Velasco Curso INEM 02830. Programación en Java Marzo 2010 Índice 1 Introducción a la POO 2 Herencia y polimorfismo 3 Empaquetado de proyectos
Más detallesTópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN
Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.
Más detallesCatoira Fernando Fullana Pablo Rodriguez Federico [MINERIA DE LA WEB] Proyecto Final - Informe Final
Catoira Fernando Fullana Pablo Rodriguez Federico [MINERIA DE LA WEB] Proyecto Final - Informe Final INTRODUCCION En principio surgió la idea de un buscador que brinde los resultados en agrupaciones de
Más detalles4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review)
1_Visión general de SCRUM 2_Teoría de Scrum 3_El Equipo Scrum (Scrum Team) 3.1_El Dueño de Producto (Product Owner) 3.2_El Equipo de Desarrollo (Development Team) 3.3_El Scrum Master 4_Eventos de Scrum
Más detalles19. Packages o paquetes
Programación orientada a objetos con Java 201 19. Packages o paquetes Objetivos: a) Definir el concepto de paquete b) Interpretar el código fuente de una aplicación Java donde se utilicen paquetes c) Construir
Más detallesModelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com
Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico
Más detallesResumen General del Manual de Organización y Funciones
Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de
Más detallesEstándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008
Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION
Más detallesORGANISMO COORDINADOR DEL SISTEMA ELÉCTRICO NACIONAL INTERCONECTADO DE LA REPÚBLICA DOMINICANA
ORGANISMO COORDINADOR DEL SISTEMA ELÉCTRICO NACIONAL INTERCONECTADO DE LA REPÚBLICA DOMINICANA TÉRMINOS DE REFERENCIA PARA LA CONTRATACIÓN DE SERVICIOS DE DESARROLLO SOFTWARE OC-GA-14-TDRCSDS1601-160128-V1
Más detallesBPM: Articulando Estrategia, Procesos y Tecnología
BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores
Más detallesAcronis License Server. Guía del usuario
Acronis License Server Guía del usuario TABLA DE CONTENIDO 1. INTRODUCCIÓN... 3 1.1 Generalidades... 3 1.2 Política de licencias... 3 2. SISTEMAS OPERATIVOS COMPATIBLES... 4 3. INSTALACIÓN DE ACRONIS LICENSE
Más detallesCapítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente
Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.
Más detallesEl modelo de ciclo de vida cascada, captura algunos principios básicos:
Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",
Más detallesCiclo de vida y Metodologías para el desarrollo de SW Definición de la metodología
Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto
Más detalles<Generador de exámenes> Visión preliminar
1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,
Más detallesVICERRECTORÍA DE ADMINISTRACIÓN Y ASUNTOS ECONÓMICOS DIRECCIÓN DE DESARROLLO DE PERSONAS. Estructura de Cargos y Competencias Institucionales
VICERRECTORÍA DE ADMINISTRACIÓN Y ASUNTOS ECONÓMICOS DIRECCIÓN DE DESARROLLO DE PERSONAS Estructura de Cargos y Competencias Institucionales Campus San Juan Pablo II Presentación La Universidad Católica
Más detallesEducación y capacitación virtual, algo más que una moda
Éxito Empresarial Publicación No.12 marzo 2004 Educación y capacitación virtual, algo más que una moda I Introducción Últimamente se ha escuchado la posibilidad de realizar nuestra educación formal y capacitación
Más detallesBechtle Solutions Servicios Profesionales
Soluciones Tecnología Bechtle Solutions Servicios Profesionales Fin del servicio de soporte técnico de Windows Server 2003 No hacer nada puede ser un riesgo BECHTLE Su especialista en informática Ahora
Más detallesCAPITULO V. Conclusiones y recomendaciones. Este capítulo tiene como objetivo mostrar las conclusiones más significativas que se
CAPÍTULO V 74 CAPITULO V Conclusiones y recomendaciones Este capítulo tiene como objetivo mostrar las conclusiones más significativas que se identificaron a lo largo de la investigación. Asimismo, se presentan
Más detallesCapítulo VI. Conclusiones. En este capítulo abordaremos la comparación de las características principales y
Capítulo VI Conclusiones En este capítulo abordaremos la comparación de las características principales y de las ventajas cada tecnología Web nos ofrece para el desarrollo de ciertas aplicaciones. También
Más detallesLa interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la
Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes
Más detallesDISEÑO DE FUNCIONES (TRATAMIENTOS)
DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se
Más detalles