miércoles, 21 de marzo de 2012

Fundamentos del enfoque orientado a objetos/HerramientasCASE


Fundamentos del enfoque Orientado a Objetos

El paradigma orientado a objetos se basa en el concepto de objeto.
 Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.
La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

En el enfoque Orientado a Objetos, las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.
  • Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
  • Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales.
  • Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
  • Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.
  • Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.
  • Concurrencia. Es la propiedad que distingue un objeto que está activo de uno que no lo está.
  • Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).
Características de la POO.


Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las características siguientes son las más importantes:
  • Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.
    Por ejemplo, volvamos al ejemplo de los automóviles, ¿Qué características podemos abstraer de los automóviles? O lo que es lo mismo ¿Qué características semejantes tienen todos los automóviles? Todos tendrán una marca, un modelo, número de chasis, peso, llantas, puertas, ventanas, etc. Y en cuanto a su comportamiento todos los automóviles podrán acelerar, frenar, retroceder, etc.

    En los lenguajes de programación orientada a objetos, el concepto de Clase es la representación y el mecanismo por el cual se gestionan las abstracciones.
    Por ejemplo, en Java tenemos:
    public class Automovil {
    // variables
    // métodos
    }

  • Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente, el encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el ocultamiento que veremos a continuación.
    La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.

  • Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos que se puedan compilar por separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.
    Principio de ocultación.
    Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
    Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer sólo los detalles que sean necesarios para el resto del sistema.
    El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habrá cierto comportamiento privado de la Clase que no podrá ser accedido por otras Clases. Y controlar porque daremos ciertos mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dónde se validarán que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y métodos.
  • Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación" de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

  • Herencia: Las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.
    La herencia es uno de los conceptos más cruciales en la POO. La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y métodos propios, tiene incorporados los atributos y métodos heredados de la superclase. De esta manera se crea una jerarquía de herencia.
    Por ejemplo, imaginemos que estamos haciendo el análisis de un Sistema para una tienda que vende y repara equipos celulares.

    En el gráfico vemos 2 Clases más que posiblemente necesitemos para crear nuestro Sistema. Esas 2 Clases nuevas se construirán a partir de la Clase Celular existente. De esa forma utilizamos el comportamiento de la SuperClase.
    Recolección de basura
    La recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.
Aplicaciones Orientadas a Objetos.

A lo largo de la historia de la programación, los lenguajes y las metodologías han pasado de una relativa simplicidad a una complejidad creciente. Los lenguajes de programación orientados a objetos pretenden aportar simplicidad a la tarea de programación de grandes aplicaciones.
Cuando se crearon las primeras computadoras todavía no existían los lenguajes de programación, tal como ahora los entendemos. El lenguaje ensamblador puede considerarse como el primer lenguaje de programación propiamente dicho. Permitía al usuario un diálogo más fluido con la máquina a través de instrucciones que tenían relación directa con el conjunto de operaciones que la máquina podía realizar.
A partir de este momento empezó la evolución de los lenguajes de programación. _cada uno tenía su entorno definido y aunque en realidad todos los lenguajes son polivalentes (en teoría, con cualquiera de ellos se puede desarrollar cualquier programa de gestión o científico). Pronto apareció la especialización funcional. Así, COBOL (Common Business Orientated Language) se introdujo como lenguaje mainframe para el diseño de aplicaciones de gestión.; FORTRAN (Formula Translator) para el diseño de aplicaciones científicas; APL (A Programming Language) para el cálculo matemático, etc.
A medida que el software tomaba importancia, aparecieron los primeros problemas relacionados con la programación. Al tiempo que aumenta elvolumen de un programa, disminuye el control del mismo por parte del programador y la capacidad de este de dar mantenimiento.
En un intento de solucionar estos problemas aparecen las metodologías de programación. Una metodología es un conjunto de reglas destinadas a simplificar las tareas de diseño, estimación de costes, desarrollo y mantenimiento de un sistema informático. A menudo se ven acompañadas con unas herramientas (CASE: Computer Aided Software Engeneering) que permiten la elaboración estructurada y documentada de los sistemas informáticos.

DISEÑO DE APLICACIONES Y ELECCIÓN DE ENTORNO

En entorno de programación implica tanto el lenguaje de programación como al empleo de una determinada metodología.
Los lenguajes de programación no se producen por generación espontánea y se ven influidos en gran manera por la forma en la que los profesionales piensan que se debe programar. De esta manera se crea un conjunto de reglas para simplificar la tarea de programación. Generalizadas y codificadas, se convierten en <<principios>> de los que surgen los lenguajes de programación en un afán por darles soporte.
Estos <<principios>> son modelos que proporcionan técnicas que , a su vez, deben aplicarse en el diseño e implementación de los programas. Estas técnicas nos indican la forma de resolver los distintos problemas que surgen a la hora de programar.
Decimos que un lenguaje de programación <<soporta>> un conjunto de <<principios>> si el lenguaje simplifica la aplicación de estas técnicas. A estos <<principios>> se les denomina metodologías de programación.
Las metodologías de programación son modelos sobre como diseñar e implementar los programas. Diferentes modelos tienen como resultado diferentes técnicas. Que cada técnica sea distinta no implica que una sea la verdadera y que las demás falsas. Por el contrario, las metodologías se complementan entre sí. Lo que todas las metodologías tienen en común es la premisa de que hay que partir de abstracciones que corresponden a elementos del problema a resolver, y que la implementación de la solución se debe realizar mediante un conjunto de módulos preferiblemente reutilizables.
Las metodologías orientadas a objetos se centran en las estructuras de datos que sin embargo se relegan a un segundo plano en los modelos procedurales. La base de esta metodología es que una estructura de datos debe contener las operaciones que los modifican. La técnica que se utiliza para obtener esta <<abstracción de datos>> es la encapsulación de los mismos en una estructura conocida como clase.
El accesos a los datos contenidos en la clase se realiza mediante las operaciones que la propia clase define. Por tanto, la metodología orientada a objetos complementa el punto de vista procedural de operaciones realizadas sobre un flujo de datos, al asociar a cada dato el conjunto de operaciones que lo modifican. Como podrá ver, ambos enfoques son complementarios.
Para ilustrar las diferencias entre las aproximaciones orientadas a procedimientos y las orientadas a objetos, considere el diseño de un <<compilador>>
El compilador es un programa que a partir de un conjunto de fichero fuente (programa) construye el código objeto que posteriormente se convierte en programa. Para realizar su trabajo, el compilador lee el fichero fuente y separa de él las variables y las instrucciones. Las variables constituyen la tabla de símbolos del programa, mientras que las instrucciones se organizan en un árbol sintáctico donde se plasman todas la referencias que realizan los mandatos y funciones entre sí.

El modelo mejor establecido es el basado en funciones (procedural) que trata de la construcción de un programa como una colección de funciones. Las metodologías proporcionan una gruía sobre cómo diseñar, organizar e implementar las funciones que componen un programa.
La programación orientada a objetos está basada en un modelo de construcciones de programas como un conjunto de clases. El diseño orientado a objetos identifica los tipos que representan los distintos objetos en el programa. Las operaciones a realizar con cada uno delos objetos son, al igual que en el modelo procedural, los pasos destinados a solucionar el problema. El objeto sirve además de módulo que puede reutilizarse para la solución de un problema de similares características en otro programa.

Ninguna metodología resuelve con acierto todos los tipos de problemas. La programación requiere una especialización como la que se produce en la ingeniería pero todavía no es posible identificarla como una ciencia. Las técnicas a emplear se han de utilizar con exquisito cuidado, sin perder de vista el objetivo de resolver un determinado problema.
Actualmente existe la tendencia de identificar la programación con una disciplina Como la ingeniería. Sin embargo, debe considerarse más como un arte como la arquitectura, donde se unen la inspiración y el dominio de la técnica.
Para la elección de un determinado entorno debemos fijar los criterios necesarios, como los que describimos a continuación.:
Tamaño de la aplicación.
Cuanto mayor sea el volumen de información a procesar, mas necesidad habrá de estructurar dicha información de forma que se fácil su manipulación.

TIPOS DE RELACIONES

Una relación es una conexión semántica entre elementos del
modelo. En el UML se definen relaciones de asociación, generalización
y dependencia. La agregación y composición son casos especiales de
relaciones de asociación. 
Tipos de relaciones. Notación UML
a) Asociación: es un enlace físico o conceptual entre objetos y
denota algún tipo de dependencia semántica entre los objetos.
granito: Familia de roca
oid_familia = 1
sienita: Familia de roca
oid_familia = 2
gab ro : Familia d e ro ca
oid_f amilia = 3Una visión policéntrica del ambiente bajo el enfoque orientado a objetos 99
Esta relación es mostrada mediante enlaces representados por
líneas sólidas que conectan los elementos y que son
enriquecidas con una variedad de adornos que indican sus
propiedades, la figura 6 describe el concepto.
• Asociación binaria: se establece entre dos clases y es
representada por una línea que las relaciona; cada línea de la
relación determina una función, que indica el comportamiento
de una clase en la asociación.
Asociación binaria
Ejemplo de lo anterior se presenta en la figura 6, considerando
las figuras jurídico administrativas denominadas áreas bajo régimen
especial (ABRAE), se interpreta de la siguiente forma: cada categoría
de ABRAE (Parque Nacional-PN, Refugio de Fauna-RF, entre otras)
agrupa muchas ABRAES (PN El Ávila, PN Sierra Nevada, RF Cuare)
y cada ABRAE pertenece a una categoría.
Si la asociación es compleja puede definirse una clase que
contenga las propiedades de la asociación, y es llamada “clase
asociación”, y representa una asociación que tiene propiedades de clase
(atributos, operaciones y asociaciones); denotada mediante un rectángulo
de clase atado a una asociación por medio de una línea punteada.
ABRAE
oid_abrae
nombre
superfice
Decreto_nro
CAT_ABRAE
oid_cat_abrae
nombre
La asociación de las clases se interpreta tomando
como ejemplo un área de producción agrícola, de la siguiente forma: en
una parroquia se cultivan varios rubros agrícolas, y cada rubro es
cultivado en algunas parroquias. La clase asociación Parroquia/Rubro
presenta un atributo llamado número_de_hectáreas, e indica las hectáreas
dedicadas a un determinado rubro en una parroquia dada. También es
necesario mencionar que una asociación entre tres o más clases se
denomina asociación n-aria.
Una función, tal como se menciona en la definición de asociación
binaria, puede tener los siguientes adornos, y son:
• El nombre de la función, vinculado al extremo de la asociación.
• Multiplicidad, la cual especifica el rango de la cardinalidad
permitida (un intervalo con el formato: límite-inferior..límitesuperior; un entero; el símbolo * que denota un número
ilimitado de elementos)
b) Agregación: es una forma de asociación que especifica una
relación todo-parte entre el agregado (el todo) y sus
componentes (las partes).
c) Composición: es una agregación fuerte en donde “el todo” y
“las partes” coinciden en su tiempo de vida.
d) Generalización o herencia: es una relación entre una clase
(superclase) y una o más variaciones de la clase (subclases).
La superclase contiene los atributos y métodos comunes
mientras que la subclase los heredan añadiendo sus propios
atributos y operaciones.
Reusabilidad: Cualidad que nos indica que partes del programa ( en este caso objetos) pueden ser reutilizados en la confección de otros programas. Ello implica que los objetos definidos en un programa pueden ser extraídos del mismo e implantados en otro sin tener que realizar modificaciones importantes en el código del objeto. El objeto final es que el programador construya una librería de objetos que le permita realizar programas basándose en la técnica de cortar y pegar. Esta extrae (corta) código de otras aplicaciones ya realizadas y las implementa (pega) en la aplicación a realizar donde, tras algunos retoques, la nueva aplicación estará lista para funcionar. Como podrá observar el concepto de reusabilidad, permite reducir el tiempo de realización , ganando en claridad, mantenibilidad y productividad.

Actividades del proceso de desarrollo de software representados en el desarrollo en cascada.

Hay algunos modelos más para representar este proceso.
  • Planificación
La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.
  • Implementación, pruebas y documentación
La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores de software lo antes posible.
La documentación del diseño interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un API, tanto interior como exterior.
  • Despliegue y mantenimiento
El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción.
Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.
El mantenimiento y mejora del software de un software con problemas recientemente desplegado puede requerir más tiempo que el desarrollo inicial del software. Es posible que haya que incorporar código que no se ajusta al diseño original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno rediseñar el sistema para poder contener los costes de mantenimiento. 

Modelos de desarrollo de Software

Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado.
Modelo de cascada
Artículo principal: Desarrollo en cascada.
El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:
  1. Especificación de requisitos
  2. Diseño del software
  3. Integración
  4. Pruebas (o validación)
  5. Despliegue (o instalación)
  6. Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.
  
Modelo de Espiral

Artículo principal: Desarrollo en espiral.
La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
  1. crear planes con el propósito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
  2. Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
  3. la implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
  1. El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.
  2. Si la implementación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo.
  3. Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último, se evalúan los resultados y se inicia el diseño de la siguiente fase.
Desarrollo iterativo e incremental
El desarrollo iterativo recomienda la construcción de secciones reducidas de software que irán ganando en tamaño para facilitar así la detección de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes que no saben como definir lo que quieren.1
Desarrollo ágil
Artículo principal: Desarrollo ágil de software.
El desarrollo ágil de software utiliza un desarrollo interactivo como base para abogar por un punto de vista más ligero y más centrado en las personas que en el caso de las soluciones tradicionales. Los procesos ágiles utilizan retroalimentación en lugar de planificación, como principal mecanismo de control. La retroalimentación se canaliza por medio de pruebas periódicas y frecuentes versiones del software.
Hay muchas variantes de los procesos ágiles:
  • En el caso de la programación extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un día o en una semana, en lugar de los meses o años de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Después se programa el código, que será completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabrían como mejorar el conjunto de pruebas necesario. El diseño y la arquitectura emergen a partir de la refactorización del código, y se da después de programar. El diseño lo realizan los propios desarrolladores del código. El sistema, incompleto, pero funcional se despliega para su demostración a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de más importancia.
Codificación y Corrección

El desarrollo de codificación y corrección (en inglés "Code and fix") es, más que una estrategia predeterminada, el resultado de una falta de experiencia o presión que se ejerce sobre los desarrolladores para cumplir con una fecha de entrega.2 Sin dedicar tiempo de forma explícita para el diseño, los programadores comienzan de forma inmediata a producir código. Antes o después comienza la fase de pruebas de software (a menudo de forma tardía) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software.

Modelos de Mejora de Procesos

Capability Maturity Model Integration
El Capability Maturity Model Integration (CMMI), en español «Integración de Modelos de Madurez de Capacidades» es uno de los modelos líderes basados en mejores prácticas. Son evaluaciones independientes las que confirman el grado con el que una organización siguen sus propios procesos, que no evalúa la calidad de los procesos o del software que se produce. CMMI ha reemplazado a CMM y tiene un ámbito global, no sólo en procesos destinados al desarrollo del software.
ISO 9000
ISO 9000 describe estándares para un proceso organizado formalmente para resultar en un producto y los métodos de gestión y monitoreo del progreso. Aunque este estándar se creó inicialmente para el sector de producción, los estándares de ISO 9000 también se han aplicado al desarrollo del software. Al igual que CMMI, que una organización está certificada con el ISO 9000 no garantiza la calidad del resultado final, sólo confirma que se ha seguido los procesos establecidos.
ISO 15504
ISO 15504, también conocido como Software Process Improvement Capability Determination (SPICE), en español «Determinación de la Capacidad de Mejora del Proceso de Software» es un marco para la evaluación de procesos de software. Este estándar tiene como objetivo un modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo que una organización o proyecto hace durante el desarrollo del software. Esta información se analiza para identificar puntos débiles y definir acciones para subsanarlos. También identifica puntos fuertes que pueden adoptarse en el resto de la organización.

Métodos Formales

Los métodos formales son soluciones matemáticas para resolver problemas de software y hardware a nivel de requisitos, especificación y diseño. Ejemplos de métodos formales incluyen el Método B, la red de Petri, la demostración automática de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje Z. Más generalmente, se puede utilizar la teoría de autómatas para aumentar y validar el comportamiento de la aplicación diseñando un sistema de autómata finito.
Las metodologías basadas en los autómatas finitos permiten especificación de software ejecutable y evitar la creación convencional de código.
Los métodos formales se suelen aplicar en software de aviación, especialmente si es software de seguridad crítico. Los estándares de aseguramiento del software de seguridad, tales como DO178B demandan métodos formales en el nivel más alto de categorización (Nivel A).
La formalización del desarrollo de software está ganando en fuerza poco a poco, en otros ámbitos, con la aplicación del lenguaje de especificación OCL2.0 (y especializaciones tales como Java Modeling Language) y particularmente con Model-driven Architecture, que permite la ejecución de diseños, incluso especificaciones.
Otra tendencia que está surgiendo en el desarrollo de software es la redacción de especificaciones en algún tipo de lógica (normalmente una variación de FOL), para acto seguido ejecutar esa lógica como si se tratase de un programa. El lenguaje OWL, basado en lógica descriptiva, es un buen ejemplo. También se está trabajando en enlazar un idioma natural de forma automática con lógica, lógica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lógica de negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una características de los sistemas que apoyan el vínculo bidireccional inglés-lógica y ejecución directa de la lógica es que pueden explicar sus resultados en inglés en un nivel de negocios o científico.

Proceso Unificado de Desarrollo (UP del inglés UnifiedProcess) Fases de desarrollo. Disciplinas

El Proceso Unificado es dirigido por casos de uso.
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos.
El término usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el término usuario representa algo o alguien que interactúa con el sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificación funcional del sistema. 

Una especificación funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por cada usuario? Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo.
Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.
El Proceso Unificado está centrado en la arquitectura
El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempeña en la construcción de edificios. El edificio se mira desde diferentes puntos de vista: estructura, servicios, plomería, electricidad, etc. Esto le permite al constructor ver una radiografía completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que está siendo construido.
El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en los casos de uso. Sin embargo, también está influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutará, la disponiblidad de componentes reutilizables, consideraciones de instalación, sistemas legados, requerimientos no funcionales (ej. desempeño, confiabilidad). La arquitectura es la vista del diseño completo con las características más importantes hechas más visibles y dejando los detalles de lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reuso.
¿Cómo se relacionan los casos de uso con la arquitectura? Cada producto tiene función y forma. Uno sólo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso función corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del “huevo y la gallina”. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realización de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.
El Proceso Unificado es Iterativo e Incremental
Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o años. Es práctico dividir el trabajo en pequeños pedazos o mini-proyectos. Cada mini-proyecto es una iteración que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser más efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada.
Los desarrolladores basan su selección de qué van a implementar en una iteración en dos factores. Primero, la iteración trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteración trata con los riesgos más importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteración anterior.
En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteración cumple sus metas – y usualmente lo hace – el desarrollo continúa con la siguiente iteración. Cuando la iteración no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.

Lenguaje Unificado de Modelado 

 (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
DIAGRAMAS
Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concre-to, un diagrama ofrece una vista del sistema a mode-lar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas:
Diagrama de casos de uso.
Diagrama de clases.
Diagrama de objetos.
Diagrama de secuencia. 

Herramientas CASE
Herramienta CASE según ...
  • Henry David Crockett (Portland State University), "Las herramientas CASE se ven simplemente como herramientas que cualquiera puede escoger y utilizar (como un martillo) para desarrollar un sistema de información, su selección e implementación casi siempre llevará a una reducida productividad y calidad. La selección e implementación de herramientas CASE son un proceso de múltiples etapas que permite errores fatales en cada etapa. Uno de los errores más comunes es escoger una herramienta CASE que apoye un método desconocido para los diseñadores".
  • Alan Chimura (CASE Associates), "Las herramientas CASE incluyen manejadores, métodos, técnicas, disciplina, e instrucciones, todos trabajando juntos. Definir CASE menos ampliamente y presentarlo sin un suficiente entorno de apoyo es un acto de negligencia".
  • Las herramientas CASE abarcan cada etapa del proceso de ingeniería y cada actividad que se desarrolla a lo largo del mismo. CASE está formado por un conjunto de bloques que comienzan en el nivel del hardware y del sistema operativo y acaban en cada una de las herramientas.
  • CASE se refiere a herramientas para el desarrollo de sistemas que constan de cinco componentes: herramientas de diagramación, depósito de información, generadores de interfaces, generadores de código y herramientas de administración. Las herramientas CASE hacen hincapié en las actividades de alto nivel, aunque el objetivo a largo plazo es abarcar las actividades de análisis, diseño y desarrollo.
En resumen, las herramientas CASE son un complemento de la caja de herramientas del ingeniero del software. CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas. Las herramientas CASE ayudan a asegurar la calidad de un producto desde su diseño antes de construirlo.
Bloques básicos de CASE
La ingeniería del software asistida por computadora puede ser tan sencilla como una única herramienta que preste su apoyo para una única actividad de ingeniería del software, o bien puede ser tan compleja como todo un entorno que abarque herramientas, una base de datos, personas, hardware, una red, sistemas operativos, estándares, y otros muchos componentes más.
Los bloques de construcción de CASE
Cada bloque de construcción forma un fundamento para el siguiente, estando las herramientas situadas en la parte superior de la estructura de los niveles de Hardware y Software. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos tiene relativamente poco que ver con las herramientas de ingeniería del software en sí. Más bien, los entornos que tienen éxito para la ingeniería del software se construyen basándose en una arquitectura de entorno que abarca un hardware y un sistema software adecuado. Además, la arquitectura del entorno debe considerar patrones de trabajo humano que se aplican durante el proceso de ingeniería de software. La arquitectura del entorno debe de considerar los patrones de trabajo humano que se aplicaran durante el proceso de ingeniería del software. Las arquitecturas del entorno constan de una plataforma hardware y de un apoyo de sistema operativo (incluyendo el software de red y de gestión de la base de datos), constituyen los fundamentos de CASE. Aunque su entorno en si requiere de otros bloques de construcción, existe un conjunto de servicios de portabilidad que proporciona un puente entre las herramientas CASE y su marco de referencia de integración y la arquitectura del entorno.
El marco de referencia de integración es una colección de programas más especializados que capacitan a las herramientas CASE individuales para comunicarse entre sí, para crear una base de datos del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero del software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de referencia de integración, migren entre distintas plataformas del hardware y sistemas operativos sin un mantenimiento adaptativo que resulte significativo.
Los bloques de construcción representan un fundamento exhaustivo para la integración de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE utilizados actualmente no han sido construidas empleando todos los bloques de construcción que antes descritos. De hecho, algunas herramientas CASE siguen siendo soluciones puntuales. Esto es, se utiliza una herramienta para que preste apoyo en una actividad de ingeniería del software concreta (p. ej.: análisis y modelado), pero esta herramienta no se comunica directamente con otras. Es decir, no esta unida a una base de datos del proyecto y no forma parte de un entorno integrado CASE (I-CASE), aún cuando no es lo ideal, se puede utilizar una herramienta CASE lo suficientemente eficiente, aunque se trate de una solución puntual.
Ciclo de vida del desarrollo de un sistema con las herramientas CASE y los métodos tradicionales
Utilizar herramientas CASE para el desarrollo de un sistema tiene una ligera ventaja sobre los sistemas tradicionales (ver Figuras a y b), y entre los beneficios ofrecidos por la tecnología CASE se encuentran los siguientes:
  • Facilidad para llevar a cabo la tarea de revisión de especificaciones del sistema así como de representaciones gráficas (lo que aumenta la posibilidad de realizar la tarea).
  • Facilidad para desarrollar prototipos de sistemas por medio de la capacidad para cambiar especificaciones y, por otro lado, para determinar el efecto que sobre el desempeño del sistema tendrían otras alternativas.
  • Generación de código.
  • Soporte para mantenimiento como resultado de haber guardado las especificaciones del sistema en un depósito central de información.
  • Aumentar las posibilidades de satisfacer los requerimientos del usuario.


Taxonomía de Herramientas Case

Existe un cierto numero de riesgos que son inherentes siempre que se intenta efectuar una categorización de las herramientas CASE. Aunado a esto, una implicación consistente en que para crear un entorno CASE efectivo, se deben de implementar todas las categorías de herramientas, lo cual simplemente es incierto. Se puede crear una confusión (o un antagonismo) al ubicar una herramienta especifica dentro de una categoría cuando algunas personas creen lo contrario. De este modo, podría pensarse que se ha omitido la categoría completa, eliminando un conjunto completo de herramientas para su inclusión en el entorno CASE global. Además, una categorización sencilla tiende a ser plana, es decir, no se muestra la interacción jerárquica de herramientas o las relaciones que existen entre ellas. Pese a estos riesgos, es necesario crear una taxonomía de herramientas CASE para comprender mejor tanto la amplitud de CASE como los puntos en los que se pueden aplicar estas herramientas dentro del proceso del software.

Clasificación de Herramientas CASE

Las herramientas CASE pueden clasificarse por su función, su papel como instrumentos para administradores o personal técnico, por su utilización en los distintos pasos del proceso de ingeniería del software, la arquitectura de entorno (hardware y software) que les presta su apoyo, o incluso por su origen o su coste. En muchos casos, las únicas herramientas disponibles para el ingeniero del software eran compiladores y editores de texto. Estas herramientas abarcan solo la codificación, actividad que no debería de ocupar mas del 20% del proceso global del software. La taxonomía que se presenta enseguida, utiliza como criterio principal la función.

Herramientas de la ingeniería de la información: Al modelar los requisitos de información estratégica de una organización, las herramientas de la ingeniería de la información proporcionan un metamodelo del cual se derivan sistemas de información específicos. En lugar de centrarse en los requisitos de una aplicación especifica, estas herramientas CASE modelan la información de negocios cuando esta se transfiere entre distintas entidades organizativas en el seno de una compañía. El objetivo primordial de las herramientas de esta categoría consiste en representar objetos de datos de negocios, sus relaciones, y la forma en que fluyen estos objetos de datos entre distintas zonas de negocio en el seno de la compañía.

Modelado de procesos y herramientas de administración: Si una organización intenta mejorar un proceso de negocios (o de software) lo primero que debe de hacer es entenderlos. Las herramientas de modelado de procesos (también denominadas herramientas de tecnología de procesos) se utilizan para representar los elementos clave del proceso para entenderlo lo mejor posible. Estas herramientas también pueden proporcionar vínculos con descripciones de procesos que ayuden a quienes estén implicados en el proceso de comprender las tareas que se requieren para llevar a cabo ese proceso. Además, también pueden proporcionar vínculos con otras herramientas que proporcionen un apoyo para actividades de proceso ya definidas.

Herramientas de planificación de proyectos: Las herramientas de esta categoría se concentran en dos áreas primordiales: estimación de esfuerzos de proyecto y de costes de software, y planificación de proyectos. Las primeras calculan su esfuerzo estimado, la duración del proyecto y su número de personas empleando una o más de las técnicas presentadas. Por su parte, las herramientas de planificación de proyectos capacitan al administrador para definir todas las tareas del proyecto (la estructura de desglose de tareas), para crear una red de tareas (normalmente empleando una entrada gráfica), para representar la interdependencia entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto.

Herramientas de análisis de riesgos: La identificación de riesgos potenciales y el desarrollo de un plan para mitigar, monitorizar y administrar esos riesgos tiene una importancia fundamental en los grandes proyectos. Estas herramientas en si, capacitan al administrador del proyecto para construir una tabla de riesgos proporcionando una guía detallada en la identificación y análisis de riesgos.

Herramientas de administración de proyectos: La planificación del proyecto y el plan del proyecto deben de seguirse y de monitorizarse de forma continua. Además, el gestor deberá de utilizar las herramientas que recojan métricas que en ultima instancia proporcionen una indicación de la calidad del producto del software. Las herramientas de esta categoría suelen ser extensiones de herramientas de planificación de proyectos.

Herramientas de seguimiento de requisitos: Cuando se desarrollan grandes sistemas, el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. El objetivo estas herramientas es proporcionar un enfoque sistemático para el aislamiento de requisitos, comenzando por la solicitud del cliente de una propuesta (RFP) 0 especificación. Las herramientas de trazado de requisitos típicas combinan una evaluación de textos por interacción humana. Con un sistema de gestión de bases de datos que almacena y categoriza todos y cada uno de los requisitos del sistema que se analizan partir de la RFP o especificación original.

Herramientas de métricas y gestión: Las métricas de software mejoran la capacidad del administrador para controlar y coordinar el proceso del software y la capacidad del ingeniero para mejorar la calidad del software que se produce. Las métricas y herramientas de medida actuales se centran en procesos, proyectos y características del producto. Las herramientas orientadas a la administración capturan métricas especificas del proyecto (p. ej.: LDC/persona-mes, defectos por punto de función) que proporcionan una indicación global de productividad o de calidad. Las herramientas orientadas técnicamente determinan métricas técnicas que proporcionan una mejor visión de La calidad del diseño o del código.
Muchas de las herramientas métricas avanzadas mantienen una base de datos de medidas de medias de la industria. Basándose en características de proyectos y de productos proporcionados por el usuario, estas herramientas «califican» los numero locales frente a los valores medios de la industria (y frente al rendimiento local anterior) y sugieren estrategias para llegar a mejoras.

Herramientas de documentación: Las herramientas de producción de documentos y de autoedición prestan su apoyo a casi todos los aspectos de la ingeniería del software, y representan una importante oportunidad de «aprovechamiento» para todos los desarrollares de software. La mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad de tiempo considerable en el desarrollo de documentos, y en muchos casos el proceso de documentación en 51' resulta bastante deficiente. No es infrecuente que una organización de desarrollo de software invierta hasta Un 20 0 un 30 por ciento de su esfuerzo global de desarrollo de software en la documentación. Por esta razón, las herramientas de documentación suponen una oportunidad importante para mejorar la productividad.

Herramientas de software de sistema: CASE es una tecnología de estaciones de trabajo. Por tanto, el entorno CASE debe adaptarse a un software de sistema en red de alta calidad, al correo electrónico, a los boletines electrónicos y a otras capacidades de comunicaciones.

Herramientas de control de calidad: La mayor parte de las herramientas CASE que afirman que tienen como principal interés el control de calidad son en realidad herramientas métricas que hace una auditoría del código fuente para determinar Si se ajusta o no a ciertos estándares del lenguaje. Otras herramientas extraen métricas en un esfuerzo por extrapolar la calidad del software que sé esta construyendo.
Herramientas de gestión de bases de datos: El software de gestión de bases de datos sirve como fundamento para establecer una base de datos CASE (depósito), que también se denominara- base de datos del proyecto. Dado el énfasis acerca de los objetos de configuración, las herramientas de gestión de bases de datos para CASE pueden evolucionar a partir de los sistemas de gestión de bases de datos relacionales (SGBDR) para transformarse en sistemas de gestión de bases de datos orientadas a objetos (SGBDOO).

Herramientas de gestión de configuración de software: La gestión de configuración de software (GCS) se encuentra en el núcleo de todos los entornos CASE. Las herramientas pueden ofrecer su asistencia en las cinco tareas principales de CICS: identificación, control de versiones, control de cambios, auditoría y contabilidad de estados. La base de datos CASE proporciona Un mecanismo para identificar todos los elementos de configuración y relacionarlo con otros elementos; el proceso de control que se describa se puede implementar con ayuda de herramientas especializadas; un acceso sencillo a los elementos de configuración individuales facilita el proceso de auditoría; y las herramientas de comunicación CASE pueden mejorar enormemente la contabilidad de estados (ofreciendo información acerca de los cambios a todos aquellos que necesiten conocerlos).

Herramientas de análisis y diseño: Estas herramientas capacitan al ingeniero del software para crear modelos del sistema que haya que construir. Los modelos contienen una representación de los datos, de la función y del comportamiento (en el nivel de análisis), así como caracterizaciones del diseño de datos, arquitectura, procedimientos e interfaz. Al efectuar una comprobación de la consistencia y validez del modelo, las herramientas de análisis y diseño proporciona una al ingeniero del software Un cierto grado de visión en lo tocante a la representación del análisis, y ayudan a eliminar errores antes de que se propaguen al diseño, o lo que es peor, a la propia implementación.

Herramientas PRO/SIM: Las herramientas PRO/SIM (de prototipos y simulación) [NIC9O] proporcionan al ingeniero del software la capacidad de predecir el comportamiento de Un sistema en tiempo real antes de llegar a construirlo. Además, capacitan al ingeniero del software para desarrollar simulaciones del sistema de tiempo real que permitirán al cliente obtener ideas acerca de su funcionamiento, comportamiento, y respuesta antes de la verdadera implementaron.

Herramientas de desarrollo y diseño de interfaz: Estas herramientas son en realidad un conjunto de primitivas de componente de programas tales como menús, botones, estructuras de ventanas, iconos, mecanismos de desplazamiento, controladores de dispositivos etc. Sin embargo, estos conjuntos de herramientas se están viendo sustituidos por herramientas de generación de prototipos de interfaz que permiten una rápida creación en pantalla de sofisticadas interfaces de usuario, que se ajustan al estándar de interfaz que se haya adoptado para el software.

Herramientas de generación de prototipos: Se puede utilizar toda una gama de este tipo de herramientas, los generadores de pantallas permiten al ingeniero del software definir rápidamente la disposición de la pantalla para aplicaciones interactivas. Otras herramientas de prototipos CASE más sofisticadas permiten la creación de Un diseño de datos, acoplado con las disposiciones de la pantalla y de los informes simultáneamente. Muchas herramientas de análisis y diseño proporcionan extensiones que ofrecen alguna opción de generación de prototipos. Las herramientas PRO/SIM generan Un esqueleto de código fuente en Ada y C para las aplicaciones de ingeniería (en tiempo real). Por ultimo, una gama de herramientas de cuarta generación poseen también características de generación de prototipos.

Herramientas de programación: La categoría de estas herramientas abarca los compiladores, editores, y depuradores que están disponibles para prestar su apoyo en la mayoría de los lenguajes de programación convencionales. Además, los entornos de programación orientados a objetos (00), los lenguajes de cuarta generación, los entornos de programación gráfica, los generadores de aplicaciones, y los lenguajes de consulta de bases de datos residen también en esta categoría.

Herramientas de integración y comprobación: En su directorio de herramientas de comprobación de software, Software Quality Engineering define las siguientes categorías de herramientas de comprobación:
  • Adquisición de datos: herramientas que adquieren datos que son utilizaran durante la comprobación.
  • Medida estática: herramientas que analizan el código fuente sin ejecutar casos de prueba.
  • Medida dinámica: herramientas que analizan el código fuente durante la ejecución.
  • Simulación: herramientas que simulan las funciones del hardware o de otros elementos externos.
  • Administración de comprobaciones: herramientas que prestan su asistencia en la planificación, desarrollo y control de las comprobaciones.
  • Herramientas de funcionalidad cruzada: se trata de herramientas que cruzan los limites de las categorías anteriores.
Debería tenerse en cuenta que muchas de las herramientas de comprobación poseen características que abarcan dos o más de las categorías anteriores.
Herramientas de análisis estático. Estas herramientas prestan su asistencia al ingeniero del software a efectos de derivar casos prácticos. Se utilizan tres tipos distintos de herramientas estáticas de comprobación en la industria: Herramientas de comprobación basadas en código, lenguajes de comprobación especializados, y herramientas de comprobación basadas en requisitos. Las herramientas de comprobación basadas en código admiten Un código fuente (o PDL) como entrada, y efectúan Un cierto numero de análisis que dan lugar a la generación de casos de prueba. Los lenguajes de comprobación especializados (p. ej.: ATLAS) capacitan al ingeniero del software para escribir detalladas especificaciones de comprobación que describirán todos los casos de prueba y la logística de su ejecución. Las herramientas de comprobación basadas en requisitos aislan los requisitos especificos del usuario y sugieren casos de prueba (0 clases de comprobaciones) que ejerciten estos requisitos.

Herramientas de análisis dinámico: Son herramientas que interactuan con un programa que se esté ejecutando comprobando la cobertura de rutas, las afirmaciones acerca del valor de variables especificas y en general instrumentan el flujo de ejecución del programa. Las herramientas dinámicas pueden ser intrusivas o no intrusivas. Las herramientas intrusivas modifican el software que hay que comprobar mediante sondas que se insertan (instrucciones adicionales) y que efectúan las actividades mencionadas anteriormente. Las herramientas no intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el procesador que contenga el programa que se está comprobando.

Herramientas de gestión de comprobación: Son herramientas que se utilizan para comprobar y coordinar la comprobación de software para cada uno de los pasos principales de comprobación. Las herramientas de esta categoría administran y coordinan la comprobación de regresiones, efectúan comparaciones que determinan las diferencias entre la salida real y la esperada, y efectúan comprobaciones por lotes de programas con interfaces interactivas entre hombre y maquina. Además de las funciones indicadas anteriormente, muchas herramientas de gestión de comprobaciones sirven también como controladores de comprobación genéricos. Un controlador de comprobación lee uno o más casos de prueba de algún archivo de pruebas, da formato a los datos de prueba para que se ajusten a las necesidades del software que se está probando, e invoca entonces al software que sea preciso comprobar.

Herramientas de comprobación cliente/servidor: El entorno C/S exige unas herramientas de comprobación especializadas que ejerciten la interfaz gráfica de usuario y los requisitos de comunicaciones en red para él cliente y él servidor.

Herramientas de ingeniería: La categoría de herramientas de reingeniería se puede subdividir en las funciones siguientes:

Herramientas de ingeniería inversa para producir especificaciones: se toma el código fuente como entrada y se generan modelos gráficos de análisis y diseño estructurados, listas de utilización y otras informaciones de diseño.
Herramientas de estructuración y validación de código: se analiza la sintaxis del programa, se genera una gráfica de control de flujo y se genera automáticamente un programa estructurado; y
Herramientas de reingeniería para sistemas en línea: se utilizan para modificar sistemas de bases de datos en linea (p. ej.: para convertir archivos IDMS 0 DB2 traduciéndolos a un formato de entidades y relaciones).
Muchas de las herramientas anteriores están limitadas a lenguajes de programación específicos (aun cuando se abarcan la mayoría de los lenguajes principales) y requieren un cierto grado de interacción con el ingeniero del software.
Las herramientas de ingeniería inversa y progresiva de la próxima generación hará un uso mucho mayor de técnicas de inteligencia artificial, aplicando una base de conocimientos que sea especifica del dominio de la aplicación (esto es, un conjunto de reglas de descomposición que se aplicarían a todos los programas de una cierta zona de aplicación tal como sí control de fabricación o la aviónica). El componente de inteligencia artificial asistirá en la descomposición y reconstrucción del sistema, pero seguirá requiriendo una interacción con un ingeniero de software a lo largo del ciclo de la reingeniería.

Heramientas CASE Cliente/Servidor (C/S)
A la relación entre las herramientas CASE y la arquitectura C/S podemos determinarla al plantearnos las siguientes cuestiones, ¿ cuáles son las influencias de las herramientas CASE en las empresas desarrolladoras de sistemas de información cliente/servidor ? y, ¿ cuáles son las tendencias actuales de las empresas fabricantes de sistemas cliente/servidor ?. Como soporte, se planteará un marco teórico que explicará la filosofía cliente/servidor, y posteriormente se procederá a responder a las preguntas mencionadas anteriormente.
Arquitectura Cliente/Servidor (C/S)
Con la aparición de las redes de ordenadores en empresas y universidades ha surgido en el mundo de la informática la tecnología cliente/servidor. Hay una gran cantidad de organizaciones que ya cuentan con un número considerable de aplicaciones cliente/servidor en operación: Servidores de Bases de Datos y Manejadores de Objetos Distribuidos. Cliente/servidor es una tecnología de bajo costo que proporciona recursos compartidos, escalabilidad, integridad, encapsulamiento de servicios, etc. Pero al igual que toda tecnología, el desarrollo de aplicaciones cliente/servidor requiere que la persona tenga conocimientos, experiencia y habilidades en procesamiento de transacciones, diseño de base de datos, redes de ordenadores y diseño gráfica de interfase.
Clientes y servidores son entidades lógicas separadas que trabajan junto en una red, para cumplir una tarea. Todo sistema cliente / servidor tiene las siguientes características:
  • Servicio: Cliente/Servidor es principalmente una relación entre ejecución de procesos de máquinas separadas. El servidor de procesos es un proveedor de servicios. El cliente es un consumidor de servicios. En esencia, cliente/servidor provee una separación limpia de funciones basadas en la idea de servicios.
  • Recursos Compartidos: Un servidor puede ofrecer servicios a muchos clientes al mismo tiempo y regular su acceso a recursos compartidos.
  • Protocolos Asimétricos: Hay una relación de muchos a uno entre clientes y servidores. Los clientes siempre inician el diálogo para solicitar un servicio. Los servidores están esperando pasivamente por solicitudes de clientes.
  • Localidad Transparente: El servidor es un proceso que puede permanecer en la misma máquina como el cliente o en una máquina diferente de la red.
  • Intercambio de Mensajes: Los clientes y servidores se acoplan a sistemas que actúan recíprocamente por un mecanismo de pase de mensaje (message passing).
  • Encapsulación de Servicios: El servidor es un especialista. Un mensaje le dice a un servidor qué servicio es solicitado; éste entonces le indica al servidor como realizar el trabajo. Los servidores pueden ser actualizados sin afectar la interfase de pase de mensajes con los clientes.
  • Escalabilidad: Los sistemas cliente/servidor pueden ser escalados horizontalmente o verticalmente. La escalabilidad horizontal significa agregar o quitar estaciones de trabajo cliente con sólo un impacto en la ejecución. Una escalabilidad vertical significa emigrar a una máquina servidora más grande y más rápida o múltiples servidores.
  • Integridad: El código y el dato del servidor es centralmente mantenido, el cual resulta un mantenimiento más barato y guardando la integridad de los datos compartidos.
Evolución de la tecnología C/S

La primera ola de cliente/ servidor fue causada por los NOSs (Network Operating System). Los NOSs facilitan a las aplicaciones compartir archivos, impresoras y otros dispositivos conectados a la red; desempeñan su magia extendiendo el alcance del sistema operativo. Podríamos llamar a la primera ola de cliente/servidor la "ola Netware". Estamos en la segunda ola del cliente/servidor: La ola de las aplicaciones centradas en bases de datos. La tecnología predominante es el "servidor de bases de datos SQL". Sin embargo, también experimentamos otras dos grandes oleadas tecnológicas causadas por el GroupWare y los TP monitors. La tercera oleada de cliente/servidor son los objetos distribuidos. Los objetos rodean la tecnología de la primera y segunda ola y añaden un nuevo valor considerable. Tienen el único potencial de distribuir inteligencia entre clientes y servidores donde más se requiere. A continuación se muestra el gráfico de la evolución de la tecnología Cliente/Servidor a lo largo de los años.
Ahora podemos describir el panorama general del uso de herramientas CASE en aplicaciones Cliente/Servidor enfocado desde dos puntos de vista distintos:
  • Estructura de costos de las empresas desarrolladoras.
  • Rango de aplicabilidad de las herramientas CASE.
CASE al nivel de Estructura de Costos.
Las empresas desarrolladoras, al decidir adoptar una herramienta CASE, asimilan una serie de costos tangibles e intangibles que afectan el proceso de desarrollo de las futuras aplicaciones Cliente/Servidor. Dichos costos podemos diferenciarlos en 3 tipos, a saber:
  • Precio de Venta. Las herramientas CASE, por su complejidad de desarrollo y su alto nivel de especialización, son muy costosas. En la tabla que aparece en la bibliografía anexa1, vemos que los precios oscilan entre los 1000$ y los 25,000$, y existen herramientas aún más costosas (de más de un millón de dólares). Sin embargo, las herramientas más caras resultan más baratas para la empresa desarrolladora si ésta posee una gran cantidad de recursos humanos destinados a proyectos. La razón es que la licencia de las herramientas costosas es única, en cambio, la de las otras herramientas es por máquina instalada. Esta variación en el precio incide, lógicamente, en la toma de decisión de la Alta Gerencia en relación a cuál herramienta debe elegir para un proyecto determinado.
  • Costo de Entrenamiento de Personal. La gran complejidad que poseen las herramientas CASE también se traduce en un aumento de los costos de desarrollo de sistemas, debido a los costos generados por la curva de aprendizaje del personal y los costos por entrenamiento. Este incremento se aminora con el tiempo, a medida que los desarrolladores adquieran más destreza en el uso de la herramienta y sean, por tanto, más productivos. Esto se evidencia en la siguiente gráfica:
Como puede apreciarse, el costo es considerablemente elevado y en muchas ocasiones esto ha provocado que algunas empresas dejen de usar las herramientas CASE por considerarlas improductivas.
Un factor que influye en la inclinación de la curva de aprendizaje es un bajo nivel de restricción de la herramienta CASE. Una herramienta que posea pocas restricciones, "puede sobrecargar a un analista al ofrecer más opciones de las que es capaz de manejar. El resultado final puede ser que la herramienta CASE no sea usada apropiadamente"
  • Costo de Adopción de la Metodología Asociada a la Herramienta CASE. Sabiendo que toda herramienta CASE posee una metodología de trabajo asociada, y muy específica; es posible que se genere un costo de desarrollo adicional por adoptar una herramienta cuya metodología sea diferente a la imperante en la empresa. Ello puede generar, a su vez, brotes de hostilidad del personal hacia la herramienta. La implementación de las herramientas CASE integradas en una organización puede ser muy bien recibida por el personal deseoso para su utilización, bien educado en un fondo teórico, y ser apaciblemente introducido en la mecánica de la herramienta a través de un excelente entrenamiento y soporte durante el mismo. La misma herramienta en otro lugar puede ser recibida con hostilidad, con el personal sintiendo que ha sido obligado por la Gerencia. Uno de los errores más comunes es el de elegir una herramienta CASE que soporte un método que no sea familiar a los desarrolladores.
  • CASE al nivel de l Rango de Aplicación (CASE Cliente/Servidor).
Características deseables de una herramienta CASE C/S

Una herramienta CASE cliente/servidor provee modelo de datos, generación de código, registro del ciclo de vida de los proyectos , múltiples repositorios de usuarios, comunicación entre distintos ingenieros. Las principales herramientas son KnowledgeWare's Application Development Workbench, TI's Information Engineering Facility (IEF), and Andersen Consulting's Foundation for Cooperative Processing.
Por otra parte, una herramienta CASE Cliente/Servidor debe ofrecer:
    • Proporcionar topologías de aplicación flexibles. La herramienta debe proporcionar facilidades de construcción que permita separar la aplicación (en muchos puntos diferentes) entre el cliente, el servidor y más importante, entre servidores.
    • Proporcionar aplicaciones portátiles. La herramienta debe generar código para Windows, OS/ 2, Macintosh, Unix y todas las plataformas de servidores conocidas. Debe ser capaz, a tiempo de corrida, desplegar la versión correcta del código en la máquina apropiada.
    • Control de Versión. La herramienta debe reconocer las versiones de códigos que se ejecutan en los clientes y servidores, y asegurarse que sean consistentes. También, la herramienta debe ser capaz de controlar un gran número de tipos de objetos incluyendo texto, gráficos, mapas de bits, documentos complejos y objetos únicos, tales como definiciones de pantallas y de informes, archivos de objetos y datos de prueba y resultados. Debe mantener versiones de objetos con niveles arbitrarios de granularidad ; por ejemplo, una única definición de datos o una agrupación de módulos.
    • Crear código compilado en el servidor. La herramienta debe ser capaz de compilar automáticamente código 4GL en el servidor para obtener el máximo performance.
    • Trabajar con una variedad de administradores de recurso. La herramienta debe adaptarse ella misma a los administradores de recurso que existen en varios servidores de la red; su interacción con los administradores de recurso debería ser negociable a tiempo de ejecución.
    • Trabajar con una variedad de software intermedios. La herramienta debe adaptar sus comunicaciones cliente/servidor al software intermedio existente. Como mínimo la herramienta debería ajustar los temporizadores basándose en, si el tráfico se está moviendo en una LAN o WAN.
    • Soporte multiusuarios. La herramienta debe permitir que varios diseñadores trabajen en una aplicación simultáneamente. Debe gestionarse los accesos concurrentes a la base de datos por diferentes usuarios, mediante el arbitrio y bloqueos de accesos a nivel de archivo o de registro.
    • Seguridad. La herramienta debe proporcionar mecanismos para controlar el acceso y las modificaciones a los que contiene. La herramienta debe, al menos, mantener contraseñas y permisos de acceso en distintos niveles para cada usuario. También debe facilitar la realización automática de copias de seguridad y recuperaciones de las mismas, así como el almacenamiento de grupos de información determinados, por ejemplo, por proyecto o aplicaciones.
    • Desarrollo en equipo, repositorio de librerías compartidas. Debe permitir que grupos de programadores trabajen en un proyecto común; debe proveer facilidades de check-in/ check-out registrar formas, widgets, controles, campos, objetos de negocio, DLL, etc; debe proporcionar un mecanismo para compartir las librerías entre distintos realizadores y múltiples herramientas; gestiona y controla el acceso multiusuario a los datos y bloquea los objetos para evitar que se pierdan modificaciones inadvertidamente cuando se realizan simultáneamente.
  • Clasificación de las herramientas CASE Cliente/Servidor.
Las herramientas CASE Cliente/Servidor se pueden clasificar en dos grupos: las más modestas y baratas (como Visual Basic, Power Builder, Delphi, Erwin, etc.), y las llamadas herramientas integradas (IEF, Oracle CASE, etc.). Su costo está en proporción directa con su rango de aplicabilidad para desarrollar sistemas de información. Se ha demostrado que las herramientas del primer grupo no sirven para desarrollar sistemas de complejidad muy grande (sistemas distribuidos, multiplataformas, o cualquier otro que consuma gran cantidad de recursos durante su desarrollo). Esto influye claramente en las políticas de desarrollo de una empresa que posea alguna herramienta, de forma tal que se han desarrollado metodologías para elegir la herramienta CASE más acorde a las características del proyecto a llevar a cabo. Si bien la diversidad de herramientas CASE es bastante marcada, las empresas fabricantes están mostrando varias tendencias fundamentales de integración, a saber:
    • Las futuras versiones de las herramientas CASE integradas serán más abiertas, es decir, admitirán en su metodología el uso de herramientas más pequeñas. Además, cada vez se vislumbran acuerdos para utilizar estándares conocidos (como OLE). Cada vez se hacen públicos más y más acuerdos de integración de tecnologías de diferentes fabricantes.
    • Las herramientas CASE cada vez más facilitan la centralización de los archivos fuente y de documentación de los proyectos en entes llamados repositorios, donde puedan almacenarse eficientemente durante una o más fases del ciclo de desarrollo de un sistema.

      Herramientas CASE en el mercado actual 

      A continuación se presenta en forma breve, una reseña de cada una de las herramientas que hasta ahora han salido al mercado del SW. Debido a que se tienen herramientas de desarrollo abiertas con conectividad a diversas plataformas, basadas en tecnología orientada a objetos y a tecnología cliente/servidor que permiten la reutilización del software; nos permitimos dividir secciones entre estas, como a continuación se describe.
  • PowerBuilder de PowerSoft
Con 30 manejadores de base de datos, ofrece dos opciones de conectividad: ODBC de Microsoft y conectividad nativa. Una de las características principales (muy apreciada por los usuarios, quienes dicen es mejor con Oracle e Informix que sus propias herramientas) de este producto es que comparte el mismo idioma de cada manejador. Incluye entre otros módulos el Optima++, herramienta RAD basada en componentes que combina desarrollos cliente/servidor e Internet con el rendimiento de C++. Asimismo, ofrece un módulo opcional CASE Power Design que genera modelos lógicos y físicos de los distintos manejadores que soporta para acelerar los desarrollos. También cuenta con la herramienta Info Maker que ellos definen "como la estrellita" que permite de manera muy sencilla que los usuarios finales puedan hacer data minning o minería de datos.
Power Builder cuenta con conectividad para aplicaciones Java a través del driver JDBC, desarrollado por Sybase y puede construir aplicaciones sobre cualquier plataforma. Precisamente, Java es uno de los lenguajes de programación que más está dando que hablar hoy día por considerarse un nuevo paradigma en el mundo de la computación, con él Sun Microsystems avanzó unos cuantos pasos delante de su principal competidor Microsoft en el área de redes de computadoras. "Es orientado a objetos y tiene la ventaja de que rompe la aplicación en bytecodes diseñados para trabajar y viajar a lo largo de una red desde el servidor hasta el cliente y puede correr encima de un browser o de un sistema operativo a través del Java Virtual Machine que permite correr la aplicación sobre cualquier tipo de cliente".
Se considera que una de las fortalezas de Java son sus Interfaces de Programación de Aplicaciones (APIs), que las hay específicas y por áreas de industria y disponibles en la red. "Hoy día existen unas 23 APIs, cada una con una funcionalidad particular que facilita enormemente el desarrollo". Otra de las ventajas de Java para el desarrollador, es el concepto de "escribir una vez y correr en cualquier parte" eso quiere decir que el programador escribe una sola vez el código, lo compila una sola vez y ese programa puede correr en cualquier plataforma. Si bien esta es la bandera de Sun aún está en entredicho que la misma siga ondeando dado que Java está a media asta en Microsoft. Las características novedosas de Java, especialmente su total orientación a objetos ha llevado a muchas empresas a establecer acuerdos con Sun: NetScape, IBM, Oracle, e incluso Microsoft, empresa que para bien o para mal se torna cada vez más agresiva hacia el mercado tuvo que ceder ante sus encantos y ya tiene su Visual J++.
  • Visual Basic
Actualmente Microsoft continúa impulsando este lenguaje, el cual es una evolución de su antecesor Basic y como su nombre lo indica, es un ambiente de desarrollo más visual. A partir de la versión 5.0 cuenta con un compilador original de códigos y está más orientado a ambientes cliente/servidor e incluye soporte e integración a aplicaciones Internet/intranet a través de la tecnología ActiveX. La popularidad de Visual Basic se debe a su simplicidad ya que en cuanto a conectividad hay otros que lo superan, pero podemos mencionar que soporta FoxPro, Oracle, e Informix vía ODBC y aún cuando no está orientada a objetos porque no soporta polimorfismos, cumple algunas de las reglas de esta tecnología al permitir reutilizar componentes para el desarrollo de aplicaciones personalizadas.
  • Visual FoxPro y Visual C++
Las herramientas de desarrollo orientadas a objetos con que Microsoft cuenta son Visual FoxPro y Visual C++, siendo ahora lo más reciente InterDev. De tales herramientas, esta última es la primera que ayuda a los desarrolladores de aplicaciones basadas en Web en la construcción de sitios sofisticados totalmente interactivos. InterDev disminuye el ciclo de desarrollo al soportar los lenguajes de Internet Java y Visual Basic Scrip interconectándose con otros lenguajes como C++ o Visual Basic a través de componentes ActiveX, además, puede interactuar totalmente con FrontPage 97 (herramienta orientada a usuarios finales y diseñadores). De esta manera ambos pueden trabajar en equipo para la construcción de sitios Web.
  • Oracle
Siguiendo la orientación al Web, Oracle en la actualidad está enfocada directamente a su Arquitectura de Computación de Redes (NCA), considerada como un servidor universal de datos, aprovechando lo mejor de los tres mundos: Web, cliente/servidor y orientación a objetos. Sus herramientas de desarrollo son básicamente tres:
Developer/2000, herramienta tipo RAD, presenta ventajas como sencillez, orientada a cliente/servidor y desarrollar ambientes Web. Genera software basado en Visual Basic y Java para que pueda correr en cualquier browser. Developer/2000 funciona sólo en Oracle, pero soporta básicamente las bases de datos SQL Server de Microsoft e Informix.
Oracle J-Dveloper, un generador de software de objetos en Java que pueden correr en cualquier browser y permite reutilizarlos.
Designer/2000, herramienta de modelaje de alto nivel para procesos, entidad-relación, work flow y modelajes funcionales. La principal diferencia de esta herramienta es que manteniendo un modelaje de alto nivel puede generar la aplicación final y luego realiza reingeniería de reverso para actualizar el repositorio central.
  • Erwin
Erwin es otra de las herramientas de la tecnología CASE, cuyo mayor diferenciador es su simplicidad (por generar código para la mayoría de los manejadores de base de datos ya que es completamente abierta) y la rapidez para el desarrollo de bases de datos complejas (acelerar los tiempos de desarrollo). Esta herramienta ofrece una metodología para realizar diagramas entidad-relación y cuenta con una interfaz gráfica altamente intuitiva. La versión 3.0 que incluye un servidor de ingeniería de reverso, función que lleva a cabo desde los datos existentes a modelos lógicos de datos. Asimismo trae un editor de disparadores (triggers) y de stored procedures.
  • Cool Stuf, de Sterling Software
Esta herramienta cuenta con un módulo para generar ingeniería de software tradicional, así mismo, una línea de productos para desarrollo de aplicaciones cliente/servidor de múltiples capas y para ambientes distribuidos. Además puede generar aplicaciones para Internet/intranets, soporta métodos orientados a objeto UML y cuenta con interfaces MQSeries de IBM o DCE. Cool Stuf cubre todo el ciclo de vida del producto desde la reingeniería de los procesos del negocio, análisis, diseño, distribución de procesos de datos y generación automática de código que puede ser en C++, Java o Cobol. Para ello se apoya en la metodología de James Martin, así como también en metodologías basadas en Orientación a Objetos. Una desventaja de esta es que utilizar una herramienta CASE del tipo Cool Stuf toma más tiempo el desarrollo de software en las primeras fases de análisis y diseño, se asegura la calidad de la aplicación, el entendimiento y la documentación, así como también minimiza el mantenimiento.
  • Informix
Otra de las empresas que también cuenta con su herramienta de desarrollo NewEra orientada a la plataforma cliente/servidor y es totalmente orientada a objetos. Además posee dos formas de generar aplicaciones: en forma compilada y en interpretada. Ésta última disminuye considerablemente los tiempos de desarrollo. NewEra cuenta con una característica de particionamiento que permite al desarrollador decidir qué parte de la aplicación se va a ejecutar en la PC y qué parte en el servidor y esto se hace desde el mismo lenguaje y no a través de stored procedures. Su conectividad con otras plataformas se realiza por medio de drivers ODBC, específicamente para Informix, Oracle, Sybase.
  • Herramientas CASE tradicionales
  • Opal, de Computer Associates
Herramienta de desarrollo que sirve para preservar toda la inversión existente en las aplicaciones que tiene una empresa en funcionamiento y le agrega nuevo valor al integrar diferentes fuentes de información no sólo de ambiente mainframe sino cliente/servidor, AS/400 y todo de manera interactiva y más amigable. Presenta un ambiente de desarrollo gráfico que tiene capacidad de comunicación con cualquier terminal 3270, VT100 y 5250 e integra cualquier base de datos relacional que tenga un driver ODBC.
Sin embargo, y aunque pareciese no es un maquillador de pantalla, ya que además de contar con una interfaz tipo Windows permite al usuario crear sus propios temas y multimedios. Uno de las ventajas principales de Opal es CODE, el cual permite desarrollar una aplicación una sola vez independientemente del ambiente bajo el cual vaya a ser ejecutada y esa aplicación va a servir para un ambiente cliente/servidor, así como también para verlo a través de Internet e intranet. Cabe destacar que múltiples y diferentes fuentes de datos en la misma aplicación Opal pueden ser conectadas con una sesión 3270, VT100 y por otro lado estar accesando a una base de datos Oracle cliente/servidor y toda esta información converge en un sólo punto que va a ser la aplicación Opal y luego se despliega de acuerdo a lo que se requiere.
Opal está compuesto por tres elementos: Integrator, ambiente de desarrollo orientado a objetos; Opal Player runtime, que permite ejecutar la aplicación para diversas plataformas y para Internet (browser Netscape y Explorer). El tercer y último componente es el Opal Server, para optimizar las comunicaciones entre la aplicación Opal que está corriendo en el cliente y los requerimientos de información hacia las fuentes de datos.
  • Trabajando en equipo
Dentro de los llamados ambientes heterogéneos se continúa imponiendo el trabajo en grupos, de los cuales se tienen actualmente los siguientes:
Lotus con Notes
Herramienta que impulsa esta tendencia desde hace ya siete años. Funciona como cliente y uno de sus factores diferenciadores es que trae una serie de funcionalidades para grupos tales como manejo de documentos, work flow, foros, electrónicos, tratamiento de imágenes y calendario, de modo que el desarrollador no tiene que comenzar de cero como sucede con otras herramientas (Visual Basic que se inicia en un editor). Incluye un almacén de objetos dentro de la documentación que no son sólo anexos, sino un soporte completo a OLE 2.0. Otro punto importante, es el Lotus Components, los cuales son miniprogramas rápidos y eficientes desarrollados con tecnología OLE y ActiveX de Microsoft que se insertan dentro de documentos Notes, como hoja de cálculo, diagramas de flujo, graficación, diagramas organizacionales y no se requiere comprar todo un paquete de herramientas de productividad, que como se sabe el 80% de los usuarios sólo utilizan un 20% de lo que el producto trae.
Otra característica de Notes es que ofrece la facilidad de trabajo en grupo con aplicaciones interactivas y permite integrar ambientes tradicionales de las empresas al permitir la conexión con bases de datos internas y con aplicaciones de terminales mainframes o AS/400, las cuales pueden ser vistas desde Notes o desde un browser e incluso permite grabar datos dentro de ellas. Desarrollar en Notes es bastante rápido, por ejemplo un producto de flujo de trabajo se puede hacer en dos meses, mientras en Visual Basic tarda unos 9 meses. Pero aquí habría que añadir cuánto cuesta un desarrollador de Notes versus uno de Visual Basic. Una característica última es que trabaja en múltiples plataformas, corre Windows 3.11, NT, Macintosh y en diversos sabores de Unix y el producto de los desarrollos en cada una de esas plataformas puede correr en otras sin modificaciones (importante para soportar la tendencia de los ambientes heterogéneos).
Notes Global Designer
Esta es de las herramientas que está cobrando mucha fuerza al permitir que el desarrollador, utilizando un glosario de términos pueda crear una aplicación y la misma puede verse en varios idiomas de acuerdo a los requerimientos del usuario.
  • Evaluación de Herramientas CASE´s
Sabemos que las herramientas CASE son de gran utilidad en el proceso de planeación y que además, la información estará disponible para ser manipulada durante las etapas de desarrollo y mantenimiento del ciclo de vida del sistema. Se considera pues, como la mejor manera de diseñar diagramas y como una forma de almacenar el trabajo de desarrollo de un sistema en un repositorio, el cual actúa como un puente para ligar varias herramientas, mientras la información en este puede ser usada para analizar la totalidad de un diseño, es decir, como algo que permite desarrollar sistemas en nuevas formas usando elementos existentes.
Considerando que con el uso de CASE se tiende a tener pocos errores de análisis y diseño, además de que las pruebas al sistema toman mucho menos tiempo, es recomendable hacer uso de esta seleccionando una metodología de desarrollo. Se tiene la ventaja de que aún cuando debido a la evolución constante de estos productos sea difícil escoger la herramienta óptima, no lo es la metodología. Tal selección debe darse con la plena seguridad de que es lo que realmente se requiere.
Ahora bien, de las herramientas CASE antes mencionadas seleccionamos tan solo a cuatro: Erwin 3.0, Erstudio 2.5, System Architech 4.0 y Power Designer 6.1, que a nuestra consideración, son las más óptimas para modelado de funciones de proyectos, flujos de información, entidades de datos y otra información. Por lo que, a continuación se da una breve descripción de cada una de estas herramientas de acuerdo a las características que presentan en los distintos componentes que ofrece una herramienta CASE (diagramación, generación de código, esquema de Base de Datos, entre otros).
  • Características Generales
ERWIN 3.0
Erwin es una herramienta para modelar, que ayuda a diseñar bases de datos de alto desempeño para cliente/servidor y web/intranet, así como aplicaciones de data warehousing. La herramienta Erwin no solo ayuda a diseñar modelos de datos lógicos, también construye automáticamente estructuras de datos físicos con la información del diagrama. Cuando el modelo de datos esta listo para usarse, simplemente se selecciona el servidor donde se quiere construir la base de datos y se eligen las opciones de generación de esquema que se quieran incorporar. En minutos, Erwin automáticamente construye la base de datos física, incluyendo todas las tablas, índices, procedimientos almacenados, triggers de integridad referencial y otros componentes necesarios para manejar exitosamente los datos usados en la organización.
ER/STUDIO 2.5
Es una herramienta de modelado de datos fácil de usar y multinivel, para el diseño y construcción de bases de datos a nivel físico y lógico. Direcciona las necesidades diarias de los administradores de bases de datos, desarrolladores y arquitectos de datos que construyen y mantienen aplicaciones de bases de datos grandes y complejas. ER/Studio está equipado para crear y manejar diseños de bases de datos funcionales y confiables.