|
|
|
Número 143 |
| Portada
del número 0 79
Autor: Equipo Crónica |
Sumario del número 0 80 |
| Publicidad |
 |
 |
 |
Resumen: el uso de vistas parciales como mecanismo inevitable para la descripción de cualquier sistema no trivial es algo asumido por la aplicación de las Tecnologías de Objetos (TO) desde sus comienzos. Por tanto, y a consecuencia del tiempo que llevo trabajando con ellas, no es de extrañar que a la hora de hacer historia y balance de las Jornadas de TO, el resultado haya sido una vista muy personal. Espero que los lectores acepten que, en beneficio de la inteligibilidad, haya podido sacrificar un punto la objetividad.
Resumen: en este artículo exploro la relación entre las necesidades y soluciones en los niveles más generales [de la empresa] y los posibles sistemas de información y sus soluciones en los niveles inferiores. Lo que encuentro es una jerarquía de fines y medios, en la que la especificación de los sistemas informáticos puede considerarse como una decisión de diseño de bastante bajo nivel. Propongo la siguiente jerarquía:
- Reconocimiento de la necesidad de introducir algún cambio o
mejora en la empresa.
- Elección del contexto/fronteras de la solución.
- Diseño de los procesos de negocio (asignación de responsabilidades,
quién hace qué y cuando).
- Descripción de las tareas del personal.
- Selección de tecnología y arquitectura del sistema.
- Diseño detallado de las herramientas. Determinación
de los casos de uso.
- Especificación de los servicios de información inexistentes.
- Diseño e implementación de los servicios de información
informatizados (p.ej. como Enterprise JavaBeans).
- Diseño e implementación de las interfaces de usuario
(herramientas) que soporten las operaciones de los usuarios.
Me gusta este enfoque. Permite el uso de formalismos si y cuando los queremos, mientras que otras partes pueden mantenerse informales e incluso indocumentadas. Además nos deja enlazar información entre los diferentes niveles siempre que escojamos hacerlo así.
Resumen: ¿comercio electrónico? ¡Claro que no! Porque el término «comercio» intuitivamente parece reflejar la cara menos amable --más chabacana-- del impoluto «ataque web». Comercio parece equivaler, en breve, a ínfulas sin fundamento; a vender mediante la web; a mera transacción comercial desprovista de viva inteligencia. Y, claro, lo que se pretende insuflar a los ávidos oyentes/navegantes es la ilusión del «negocio-business global», más allá del nudo comercio y más acá de la dulce tontería. Negocio, pues, revestido de «e» es lo que supone especulación terráquea o pasmo amazónico, envidia ciscante o codicia expediativa . Todo ello negocio, al fin, aderezado de la «e» sulfatant-e, la doble «e» de p-e-dant-e, la «e» de e-lectrólisis y de nuevo la «e» de e-business: de todas ellas tratará y hará gala el presente artículo.
Resumen: en este artículo se ofrece una visión general de la ingeniería de requisitos y se plantean algunas cuestiones sobre ella y sobre la aplicación de la tecnología de objetos durante las actividades propias de esta fase de desarrollo del software.
Resumen: los Sistemas de Gestión de Bases de Objetos (SGBO), basados en el estándar ODMG, aumentan la capacidad semántica respecto a los tradicionales SGBD relacionales, soportando tipos de datos definidos por el usuario, herencia, etc. Sin embargo, las relaciones binarias apenas empiezan a ser soportadas como tales, es decir, manteniendo la consistencia y soportando opciones de borrado y actualización. En cuanto a las relaciones n-arias, ningún SGBO, ni el estándar ODMG en el que se basan, soporta aún relaciones de grado mayor de dos. En este artículo se resume la situación actual de la tecnología en cuanto al soporte de asociaciones (incluyendo generalizaciones, agregaciones y relaciones) y se presenta una propuesta de extensión del estándar ODMG para el soporte de relaciones ternarias.
Resumen: la tecnología orientada a objetos ha surgido como un nuevo paradigma para el diseño y desarrollo de software, y su adopción ha ido creciendo en la industria. Para que realmente el desarrollo de software orientado a objetos sea un éxito es necesario poder evaluar su calidad desde las etapas tempranas del ciclo de vida. La idea de este trabajo es proponer métricas para evaluar la complejidad introducida por las jerarquías de generalización en los diagramas de clases obtenidos en las etapas de análisis y diseño, expresados utilizando, el Lenguaje de Modelado Unificado (UML).
La principal ventaja de las métricas propuestas es que pueden aplicarse en las etapas tempranas del ciclo de vida del sistema que se está desarrollando, pudiendo de esta forma analizar el mismo a medida que se va desarrollando, permitiendo así realizar mejoras antes de llegar a la implementación.
Resumen: se analiza la tendencia a convertir soluciones particulares en «verdades absolutas», que al ser aplicadas en cualquier situación no producen los resultados esperados. El presente trabajo se dedica a discutir los peligros de una idea sobre el desarrollo de software que se ha extendido como «verdad absoluta» desde el enfoque estructurado hasta el enfoque de objetos: la representación de la realidad como método de desarrollo de software.
Resumen: el modelo de interacción entre objetos más común es el conocido con el nombre de cliente/servidor. Está basado generalmente en paso de mensajes o en llamadas a procedimientos remotos y nos permite describir nuestra solución a los problemas como una serie de intercambios ordenados de información. Por desgracia, este modelo conduce a soluciones demasiado complejas cuando es preciso que más de dos objetos interactúen y colaboren de forma simultánea para resolver un cierto problema. El propósito de este artículo es presentar un nuevo modelo de interacción entre objetos que está adquiriendo una popularidad creciente en el ámbito académico ya que permite describir algunos problemas de una forma mucho más simple e intuitiva que el modelo cliente/servidor. También mostraremos algunas de sus aplicaciones más prácticas en el campo de las transacciones electrónicas.
Resumen: En este artículo se describirán dos ámbitos en los cuales las nuevas tecnologías de Internet, y la base de Orientación a Objetos es especialmente relevante, y que de hecho proponen nuevas formas de trabajo soportadas en la red. El primero es el desarrollo de un marco que permite ampliar las ventajas del entorno Internet/Web al ámbito de las aplicaciones interactivas e industriales. El segundo es una metodología/herramienta para soportar las actividades de Ingeniería de Requisitos, que, por un lado, está firmemente enraizada en las técnicas de construcción de modelos de objetos, y por otro utiliza tecnologías Internet para facilitar el trabajo de equipos distribuidos de analistas,que ha sido desarolladas por TCP Sistemas e Ingeniería, empresa dedicada al desarrollo e integración de aplicaciones y a la provisión de servicios de ingeniería y consultoría en el ámbito de las Comunicaciones y los Sistemas de Información. Fue creada en el año 93 por un grupo de profesionales de las TIC. Entre el bagaje de estos profesionales figuraban las Técnicas de Orientación a Objetos, que con el paso de los años han ido convirtiéndose en parte integrante de la forma de trabajo y de las herramientas habituales en la empresa.
Resumen: en los últimos tiempos venimos observando cómo el uso del término benchmarking se está extendiendo en contextos afines al área, aún relativamente joven, de la mejora de procesos de software. La falta de una definición rigurosa e ine-quívoca del concepto de benchmarking, junto con el riesgo de que el mercado perciba esta técnica como una moda más, sugieren la conveniencia de recordar el modo en que el benchmarking se concibe y utiliza con éxito en otros ámbitos de la gestión y mejora empresarial.
En el presente artículo presentamos el benchmarking estructurado como una técnica de cambio y de mejora en las organizaciones, incluyendo las dedicadas a la gestión, desarrollo y mantenimiento de software. Esta herramienta, utilizada en primer lugar de modo sistemático por empresas de los Estados Unidos hace aproximadamente dos décadas, comparte los mismos principios de Calidad Total que han inspirado la creación de métodos de mejora basados en modelos de referencia como el Capability Maturity Model (CMM) o ISO/IEC 15504 (SPICE).
Resumen: la obtención del coste de un algoritmo en el caso medio es una tarea, difícil en muchos casos, que requiere un conocimiento profundo de ciertas técnicas matemáticas. Este tipo de técnicas y su aplicación en algoritmia requieren una cierta madurez que normalmente no tienen los estudiantes de los primeros cursos de ingeniería en informática. No obstante, el concepto de coste promedio es fundamental para entender cuál es el papel del análisis de algoritmos dentro de la metodología de programación. En este trabajo se muestra cómo a partir de un ejemplo sencillo (búsqueda binaria) se pueden plantear modificaciones que son interesantes desde el punto de vista del análisis, así como para la realización de prácticas para la comprobación de los resultados teóricos. El objetivo consiste en que el estudiante se motive y llegue a entender desde una perspectiva práctica cual es la importancia del coste promedio de los algorimos.
Resumen: a mediados de Enero, momento de escribir estas líneas, es opinión generalizada de los «gurús» de la materia que el Efecto 2000 aún no ha terminado y que no conocemos todos los problemas acaecidos. En cualquier caso, desde mi punto de vista, existe suficiente información como para aventurar una clasificación y aventurar una visión de conjunto de los hechos. Por tanto, en este artículo se ofrecerá una relación de estos problemas, que no pretende ser exhaustiva sino representativa de cada uno de los casos, y una clasificación de los mismos. Por último daremos una breve idea sobre costes y sobre lo que debemos hacer para el futuro.
Resumen: presentamos un modelo genérico en Cálculo de Situaciones (C.S.) para formalizar protocolos criptográficos. Se distingue de otras lógicas para la modelización criptográ-fica que usan los conceptos de creencia o secreto porque nuestra propuesta está basada en el concepto de cono-cimiento y no es necesaria ninguna construcción adicional fuera del C.S. Como muestra, presentamos la especificación formal del protocolo de autentificación del ISO/IEC 9798-2 y se ilustra cómo demostrar diferentes propiedades de corrección sobre él. A la vista de una posible automatización de las demostraciones, el resultado más prometedor hasta ahora es que la especificación de los protocolos se mantiene de una manera extremadamente clara y explícita, facilitando la tarea de diseño y verificación, y permitiendo una implementación directa.
| Última actualización: 29 de Febrero de 2000 | |
 novatica@ati.es
  |
Monografía: