jueves, 28 de junio de 2012

República Bolivariana de Venezuela.
 Ministerio del Poder Popular para la Educación Universitaria.
Universidad Politécnica de Guárico. 

Calabozo -Edo- Guárico.

DISEÑO ORIENTADO A OBJETO




Profesor:                                                     Autores: 
Eliomar Nieves.                                           Bastidas, Yettsy CI.21.277.471.
Ingenieria en informática.                           Milano, María CI. 20.523.388. 
Sección: # 04.                                             Palacios, Yadurmis CI. 21.280.458.
                                                                        Sumoza, Erika CI. 20.524.992.
                                                                       Zambrano, Jhoskary CI. 20.521.654.
 Junio – 2012
Patrones de diseño.

     En la tecnología de objetos, un patrón es una descripción del problema y la solución, a la que se da un nombre, y que se puede aplicar a nuevos contextos; idealmente, proporciona consejos sobre el modo de aplicarlo en varias circunstancias, y considera los puntos fuertes y compromisos. Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.” En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Unos de los patrones fundamentales es el GRASP (Patrones de Principios Generales para Asignar Responsabilidades). En esta entrada se describirán cinco:
•    Experto en información.
•    Creador.
•    Alta cohesión.
•    Bajo acoplamiento.
•    Controlador.
Componentes.
         Componentes del modelo de estructura de diseños OO. El componente básico es la clase de objetos.

•   Objetos entidad:
Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representan la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Ejemplos de objetos entidad pueden ser empleado, alumno, etc.
•  Operaciones: Una operación define un servicio ofrecido por un objeto junto con la información que debe suministrarse cuando es invocado (nombre, argumentos de entrada/salida). También puede contener una especificación de método, el cual especifica una implementación para la operación.
• Objetos Interface: Representan los objetos técnicos requeridos para vincular la aplicación con el entorno. Representan el vínculo a través del cual el sistema recibe o suministra datos e información al entorno. Típicamente incluyen interfaces con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones.
•   Atributos: Son valores de datos asociados a los objetos de una clase al cual describen.  Están fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto. La decisión de cuando un ítem debe considerarse como atributo o como clase varía de sistema en sistema, dependiendo de su semántica en el dominio de problema. Lo que en un sistema se modela como atributo en otro puede modelarse como una clase. Cada atributo identificado debe ser atómico en el sentido de que debe ser tratado como una unidad. En tal caso puede ser un valor simple o grupo de valores tratados siempre como unidad (ej. dirección).  Debe notarse que las clases no se modelan en formas normales. La decisión sobre la estructura de datos subyacente a utilizar se difiere hasta el Diseño Físico. Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definición estándar sobre formato, longitud y dominio de valores para atributos del mismo tipo.
•   Objetos de control:
Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes. 
Clases abstractas y concretas.
        Una clase de la cual pueden generarse instancias particulares (objetos), se denomina clase concreta. Una clase abstracta es aquella que no instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones, y restricciones, reutilizadas a través de la herencia por múltiples clases concretas.  En el diagrama de estructura de objetos una clase abstracta se representa con un rectángulo punteado.
 
Restricciones.
       Las restricciones pueden especificarse sobre los valores que un atributo o relación pueden tomar. La implementación de las restricciones puede realizarse de diferentes formas: reglas de validación durante los procesos de entrada de datos (user inputs). Database-level triggers. Lógica de control contenida en una o más operaciones.
                El diseño de interfaces de sistemas.

      Es una disciplina que estudia y trata de poner en práctica procesos orientados a construir la interfaz más usable posible, dadas ciertas condiciones de entorno. El entorno dentro del cual se inscribe el diseño de una interfaz y la medida de su usabilidad, está dado por tres factores:
•    Una persona.
•    Una tarea.
•    Un contexto.
                             Notación de diseño.
      La notación de diseño, junto con los conceptos de programación estructurada, permite al diseñador representar detalles procedimentales de manera que se facilite la traducción a código. Hay disponibles notaciones gráficas, tabulares y de texto. Gráfica del diseño. Es incuestionable que las herramientas gráficas, tales como los diagramas de flujo o diagramas de caja, proporcionan una excelente forma gráfica que describen muy bien el detalle procedimental. Sin embargo, si se emplean mal las herramientas gráficas, una imagen incorrecta puede conducir a un software erróneo. El diagrama de flujo es un gráfico muy sencillo. Se usa una caja (cuadro/rectángulo) para indicar un paso del proceso. Un rombo representa una condición lógica y las flechas indican el flujo de control.
         Notación tabular del diseño Las tablas de decisión proporcionan una notación de procedimientos a una forma tabular. Es dificil que la tabla se pueda interpretar mal, e incluso puede usarse como entrada interpretable por la máquina para un algoritmo manejado por tabla.
La tabla se divide en cuatro secciones el cuadrante superior izquierdo contiene una lista de todas las condiciones. El cuadrante inferior izquierdo contiene una lista de todas las acciones posibles basándose en combinaciones de las condiciones. Los cuadrantes de la derecha forman una matriz que indican las combinaciones de las condiciones y las correspondientes acciones que se han de producir para cada combinación específica. Por lo tanto, cada columna de la matriz puede interpretarse como una regla de procesamiento.

Medición de los atributos del diseño

             En el software lo que se mide son atributos propios del mismo, se descompone un atributo general en otros más simples de medir, a veces se mide bien o mal ya que la descomposición del atributo genérico de calidad en otros sub-atributos se torna irreal, se mide con datos estadísticos no avalados, es imposible decir que la medición se hace en forma correcta. El concepto de medida va de más a menos, va de lo general a lo concreto y lo concreto es asociado a la métrica, cuya combinación te daría el nivel de calidad o seguridad de tu producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemática.
Tipos de medidas:
•   Número de errores durante un periodo determinado.
•   Fallo en la codificación o diseño de un sistema que causa que el programa no funcione correctamente o falle.
•    Tamaño de un producto informático (líneas de código)
•    Métrica de punto función (IBM): relaciona funcionalidades que ofrecía.
•    Estimación de costes y esfuerzos.
•    COCOMO
La métrica del punto función es un método utilizado en ingeniería del software para medir el tamaño del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la explotación y mantenimiento. Existen diferentes metodologías de medición, la más popular de las cuales es la mantenida por el International Function Point Users Group (IFPUG).
El producto puede ser descrito en función de su tamaño. Se pueden definir un conjunto de atributos para medir el tamaño del software:

•    Longitud: tamaño físico del producto.

•    Funcionalidad: funciones que proporciona el producto al usuario.
•    Complejidad (de tiempo o espacio): recursos necesarios (de tiempo o memoria de ordenador) para implementar una solución particular.
Las propiedades estructurales del software son atributos internos relacionados con la calidad del producto, estos son:
•  Flujo de control: secuencia en que se ejecutan las instrucciones.
•    Flujo de datos: seguimiento de cómo los datos se crean y se manejan por un programa.
•  Estructura de los datos: organización de los datos independiente del programa.
•   Los principales productos que resulta útil medir son la especificación, el diseño y el código.

Métricas del diseño.

 
1.   Cantidad de clases desarrolladas.
•    Aspecto a medir: Tamaño.
•   Objetivo: definir una medida que permita dimensionar el producto.
•   Comentario: se usa como marco de referencia de otras métricas. Por ejemplo valorar la cantidad de jerarquías de herencia con respecto al total de clases.
•   Clases a considerar: Toda clase desarrollada, extendida, usada, que es instanciada en el sistema, clases no instanciadas pero definidas en el sistema.
•  Clases a no considerar: Clases cuyos padres son externos al sistema, usada para definir una nueva clase, por extensión. Tipos primitivos de datos, como ser Integer, Carácter, etc.

2.   Cantidad de clases externas especializadas.

•    Aspecto a medir: Reutilización.
•  Objetivo: Determinar la cantidad de clases externas al sistema que son reutilizadas por medio del mecanismo de herencia.
•  Comentario: se identifican las clases externas que el propio sistema está especializando, reutilizando. Es significativo mostrar la cantidad de clases reutilizadas por librería de clases.
•   Forma de cálculo: se cuentan las clases externas que tienen una clase hija que pertenece al alcance de medición.
•   Clases a considerar: Toda clase externa al alcance de medición que es extendida en el producto.
•    Clases a no considerar: Tipos primitivos de datos, como ser Integer, Carácter, etc. Clases que pertenecen al alcance de medición y tienen subclases que pertenecen al alcance de medición. Clases que pertenecen al alcance de medición y son padres de clases externas.

3.    Promedio de statements por método de una clase.

•    Aspecto a medir: Granularidad de métodos.
•   Objetivo: Determinar si existe una cantidad excesiva de statements en los métodos que componen una clase.
•    Comentario: Se considera que una cantidad excesiva de statements en un método pueden ser la consecuencia de una inadecuada factorización de los métodos.
•  Forma de cálculo: Sumatoria de la cantidad de statements en todos los métodos de la clase, divido el número total de métodos.
• Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
•   Clases a no considerar: Clases externas al sistema a medir, es decir clases importadas o extendidas.

4.   Cantidad de métodos de interface por clase
.
•    Aspecto a medir: Responsabilidad pública.
•    Objetivo: Medir los contratos asumidos por una clase.
•  Comentario: Esta métrica permite detectar clases que posean un exceso de responsabilidad pública o carencia de la misma. Una visualización rápida por medio de la cantidad de métodos públicos nos permite apreciar la distribución de responsabilidades del sistema y focalizar la atención en la clase que presenta valores llamativos.
•   Forma de cálculo: Se cuentan los métodos de interface que tiene la clase.
•  Métodos a considerar: Se cuentan los métodos de interface propios de la clase y métodos de interface heredados de la clase padre.
•  Métodos a no considerar: Los métodos que no pertenecen a la interface de la clase.
•   Clases a considerar: Toda clase declarada dentro del alcance de medición.
•   Clases a no considerar: Clases externas al sistema a medir, clases importadas o extendidas.

5.    Cantidad de colaboradores por clase.

•    Aspecto a medir: Colaboración - Agregación.
•   Objetivo: Medir el uso de agregación en el diseño del sistema.
•    Comentarios: La agregación de una clase se determina por el número de colaboradores habituales que la clase utiliza. La presencia de dichos colaboradores define una “parsing tool” asociación de agregación o conocimiento entre la clase dueña y las clases referenciadas.
•    Forma de cálculo: se cuentan los objetos colaboradores declarados estáticamente en la definición de la clase y que pertenecen a tipos de datos distintos a la clase considerada.
•  Objetos a considerar: Objetos definidos en la clase a través de una variable de instancia a la cual se le solicita colaboración, por medio del envío de un mensaje en algún método de la clase. Asimismo, se deben contabilizar los objetos declarados en la superclase, si la hubiera, e invocados en la clase corriente. Los objetos cuyas clases están declaradas dentro del alcance de medición (internos) y los objetos externos.
•  Objetos a no considerar: Estos objetos pueden variar dependiendo del lenguaje de programación implementado. Sin embargo, a continuación se detallan algunos objetos que no deberían ser considerados colaboradores, porque están implícitos en la mayoría de las implementaciones. Tipos de datos primitivos, objetos que representan a tipos primitivos de datos y objetos comunes.
• Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
• Clases a no considerar: Clases externas al sistema a medir, es decir clases importadas o extendidas.

6.   Cantidad de colaboradores externos por clase
.
•    Aspecto a medir: Reutilización – Agregación.
•   Objetivo: determinar el uso de colaboradores externos en el sistema. Esta métrica completa el planteo de la medición de reutilización.
•  Comentarios: la agregación realizada con clases externas al sistema es otra forma posible de reutilizar clases.
•    Forma de cálculo: se cuentan los objetos colaboradores externos declarados estáticamente en la definición de la clase y que pertenecen a tipos de datos distintos a la clase considerada. “Design Patterns” pag.22-23, Erich Gamma. Una colaborador definido en forma estática en una clase, significa que existe una variable de instancia del tipo del colaborador.
•   Objetos a considerar: Los objetos cuyas clases no están declaradas dentro del alcance de medición (externos). Objetos definidos en la clase a través de una variable de instancia a la cual se le solicita colaboración, por medio del envío de un mensaje en algún método de la clase. Asimismo, se deben contabilizar los objetos declarados en la superclase, si la hubiera, e invocados en la clase corriente.
•  Objetos a no considerar: Objetos internos. Estos objetos pueden variar dependiendo del lenguaje de programación implementado. Sin embargo, a  continuación se detallan algunos objetos que no deberían ser considerados colaboradores, porque están implícitos en la mayoría de las implementaciones. Tipos de datos primitivos, objetos que representan a tipos primitivos de datos y objetos comunes. Ej. Integer, String, Byte, Char, int, char, short, flota, etc.
• Clases a considerar: Toda clase desarrollada, perteneciente al sistema a evaluar.
•  Clases a no considerar: Clases externas al sistema a medir, es decir clases importadas o extendidas.

7.   Cantidad de Mensajes Polimórficos.

•    Aspecto a medir: Polimorfismo.
•    Objetivo: medir el uso de polimorfismo en la invocación de los métodos.
•  Comentarios: Se considera mensajes enviados a tipos internos y externos al alcance de medición.
•   Forma de Cálculo: Se cuentan los mensajes polimórficos enviados a tipos internos y externos al alcance de medición.

8.    Cantidad de jerarquías de clases desarrolladas.

•    Aspecto a medir: Herencia.
•    Objetivo: medir el uso de herencia.
•  Comentarios: se define esta métrica como valor de referencia, útil para la valoración de los resultados obtenidos en otras métricas. Por ejemplo, valores obtenidos en la medición de cantidad de mensajes polimórficos.
•    Forma de Cálculo: se cuentan las jerarquías de clases propias implementadas en el sistema.
•  Jerarquías a considerar: jerarquías donde la raíz pertenece al alcance de medición.
•    Jerarquías a no considerar: jerarquías donde la raíz no pertenece al alcance de medición
•    Clases a considerar: Toda clase, que pertenezca a una jerarquía de clases declarada dentro del alcance de medición.
•   Clases a no considerar: Clases internas al alcance de medición, que heredan de una “superclase”, que esté fuera del alcance de medición.

9.  Cantidad de jerarquías extendidas de clases externas.

•    Aspecto a medir: Herencia.
•    Objetivo: Medir el uso de herencia.
• Comentarios: Puede suceder que algunas de las jerarquías que sean principales a la aplicación tengan una raíz externa.
•    Forma de Cálculo: se cuentan las jerarquías de clases, que tengan una clase padre externa, y que al menos tenga una clase hija que pertenezca al alcance de medición, que a su vez sea padre de una clase que pertenezca al alcance de medición.
•  Jerarquías a considerar: jerarquías donde la raíz no pertenece al alcance de medición.
•  Jerarquías a no considerar: jerarquías donde la raíz pertenece al alcance de medición. Jerarquía donde la raíz no pertenece al alcance de medición y tiene un padre externo, que tiene una hija perteneciente al alcance de medición que no es padre de una clase que pertenece al alcance de medición.

10.   Cantidad de niveles de especialización por jerarquía de clases
.
•    Aspecto a medir: Herencia.
•   Objetivo: Determinar la especialización alcanzada por la clase “raíz” en cada jerarquía de clases.
•   Comentario: En el capítulo anterior se citan trabajos que reportan dificultades en los niveles bajos de especialización. Se plantea esta métrica para focalizar la atención en jerarquías complejas.
•  Forma de cálculo: Primero se determina la rama de subclases con mayor profundidad. La cantidad de niveles de la jerarquía es igual a la cantidad de clases de la rama de mayor profundidad menos una clase.
•  Jerarquías a considerar: toda jerarquía donde la clase raíz pertenezca al alcance de medición.
•   Jerarquías a no considerar: familias de clases externas al sistema, ramas de familias de clases externas, clases que pertenecen a la librería del lenguaje utilizado.
.
11.  Cantidad de niveles agregados a jerarquías donde la raíz es externa.
•    Aspecto a medir: Herencia.
•   Objetivo: Determinar la especialización alcanzada de una clase externa en el alcance de medición.
•    Comentario: En el capítulo anterior se citan trabajos que reportan dificultades en los niveles bajos de especialización. Se plantea esta métrica para apuntar la atención a jerarquías complejas. Es la que tiene mayor cantidad de niveles.
•    Forma de cálculo: A partir de la clase externa al alcance de medición, que es padre de al menos una clase que pertenece al alcance de medición, determinar la rama de subclases que pertenece al alcance de medición con mayor profundidad (la cantidad de niveles se cuentan a partir del padre externo). Para esta rama, la cantidad de niveles agregados es igual a la cantidad de clases de la rama de mayor profundidad menos una clase.
•  Jerarquías a considerar: toda jerarquía donde la clase raíz es externa, donde existe un padre externo, y en el alcance de medición la clase hija es padre de una clase que pertenece al alcance de medición.
• Jerarquías a no considerar: jerarquías donde existe un padre externo, y en el alcance de medición la clase hija no tiene hijos.

12.  Cantidad de Clases Raíz no Abstractas.

•    Aspecto a medir: Herencia.
•   Objetivo: identificar las jerarquías que no tienen una clase raíz abstracta.
•    Comentario: Declarar la clase raíz como clase abstracta, implica que cada subclase debe proveer una implementación completa de los métodos definidos en la clase raíz. De esta forma se asegura el uso de polimorfismo. Gamma et al. [1995] dice que facilita “programar para una interfase, y no para una implementación”. Liskov asegura el uso de polimorfismo, si se programa para el tipo abstracto.
•   Forma de cálculo: se cuentan las clases raíz que no son abstractas.
•  Clases a considerar: Clases que pertenecen al alcance de medición, y son raíz de una jerarquía, que pertenece al alcance de medición.
• Clases que no deben considerarse: Clases que pertenezcan a la librería del lenguaje de programación. Cualquier clase externa que tenga subclases que pertenecen al alcance de medición.

13.  Porcentaje de Métodos Reemplazados en una Jerarquía.

•    Aspecto a medir: Herencia.
•  Objetivo: Determinar si la cantidad de métodos sobrescritos es excesiva.
•   Comentarios: El porcentaje de métodos heredados que son remplazados en cada subclase de una jerarquía de clases propia, da una idea del uso o abuso de la sobre-escritura. El problema principal de la redefinición de métodos (overriden) se centra en aquellos casos donde la firma se mantienen, pero la implementación es remplazada completamente. Como consecuencia, se rehace el comportamiento del método y se descarta completamente el comportamiento heredado de la clase padre. La jerarquía que tiene un porcentaje alto de métodos redefinidos detiene el mecanismo de herencia, que la clase padre aporta en la subclase.
•    Forma de cálculo: PMRJ = (CMR / CMH) * 100.
•    CMR = Cantidad de métodos remplazados.
•    CMH = Cantidad de métodos heredados.
•  Clases a considerar: subclases de una jerarquía de herencia definida en el alcance de medición.
•    Clases a no considerar: Clases externas a la jerarquía de herencia. Subclases, que pertenecen a la jerarquía de herencia y que hereden de una clase definida abstracta.

14. Porcentaje de Métodos Reemplazados en Jerarquías donde la raíz es externa.

•    Aspecto a medir: Herencia.
•  Objetivo: determinar si se esta usando bien el mecanismo de herencia cuando se esta rehusando clases.
•  Comentarios: no tiene sentido reutilizar una clase a la cual se le sobrescriben un alto porcentaje de métodos.
•    Forma de cálculo: PMRJ = (CMR / CMH) * 100.
•    CMR = Cantidad de métodos remplazados.
•    CMH = Cantidad de métodos heredados.
• Clases a considerar: subclases de una jerarquía de herencia donde la raíz es externo y tiene una clase hija en el alcance de medición que a su vez tiene una hija.
•  Clases a no considerar: subclases de una jerarquía de herencia donde la raíz es externo y tiene una clase hija en el alcance de medición que no tiene hijos. Subclases, que pertenecen a la jerarquía de herencia de raíz externo y que hereden de una clase definida abstracta.

Análisis formal del diseño.

 
          La transición entre las fases de análisis y diseño en la orientación al objeto es mucho más suave que en las metodologías estructuradas, no habiendo tanta diferencia entre las etapas. Es difícil determinar donde acaba el AOO y donde comienza el DOO, siendo la frontera entre el AOO y DOO totalmente inconsistente, de forma que lo que algunos autores incluyen en el AOO otros lo hacen en el DOO.
     El objetivo del AOO es modelar la semántica del problema en términos de objetos distintos pero relacionados. Por su parte, el DOO conlleva reexaminar las clases del dominio del problema, refinándolas, extendiéndolas y reorganizándolas, para mejorar su reutilización y tomar ventaja de la herencia. El análisis casa con el dominio del problema y el diseño con el dominio de la solución; por lo tanto el AOO enfoca el problema en los objetos del dominio del problema y el DOO en los objetos del dominio de la solución.
        Según Monarchi, los objetos del dominio del problema representan cosas o conceptos utilizados para describir el problema, denominándose objetos semánticos porque ellos tienen el significado del dominio del problema. El análisis se centra en la representación del problema, la identificación de las abstracciones que tienen el significado de las especificaciones y de los requisitos del sistema. El énfasis del diseño está en definir la solución. Las clases semánticas pueden ser extendidas durante el análisis o el diseño. Los objetos del dominio de la solución incluyen: objetos de interfaz, objetos de aplicación y objetos base o de utilidad. Estos no forman parte directamente de los objetos del dominio problema, pero representan la vista del usuario de los objetos semánticos.
       Se puede definir AOO como  el proceso que modela el dominio del problema identificando y especificando un conjunto de objetos semánticos que interaccionan y se comportan de acuerdo a los requisitos del sistema. Se puede definir DOO como el proceso que modela el dominio de la solución, lo que incluye a las clases semánticas con posibles añadidos, y las clases de interfaz, aplicación y utilidad identificadas durante el diseño.
      El AOO y el DOO no deben separarse en fases muy separadas, siendo recomendable llevarlas a cabo concurrentemente, así el modelo de análisis no puede completarse en ausencia de un modelo de diseño, ni viceversa. Uno de los aspectos más importantes de  ADOO es la sinergia entre los dos conceptos.

Reingeniería e Ingeniería de reverso.

 
          Reingeniería del software se puede definir como: “modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o evaluación.” La Ingeniería de Reverso es lo opuesto a la generación de código: el código fuente del sistema es examinado, analizado y convertido en entidades en el repositorio.
Entre las técnicas de Reingeniería tenemos:

•    Reestructuración de Datos: Esto es reversar el modelo físico al modelo lógico para obtener el modelo de E-R de la base de datos, recuperando el diccionario de datos, atributos, entidades, dominios, cardinalidad entre otros, la mayoría de las herramientas CASE del mercado cumplen con esta función.

•    Reestructuración de Código: Llevar a cabo esta actividad requiere analizar el código fuente empleando una herramienta de reestructuración, de no tener el código fuente disponible puede aplicarse ingeniería inversa sobre el compilado para obtener el código fuente original siempre y cuando la licencia del software lo permita, inmediatamente se indican las violaciones de las estructuras de programación estructurada u orientada a objetos, y entonces se reestructura el código (esto se puede hacer automáticamente). El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalías. Se actualiza la documentación interna del código.

Herramientas Case. 

      Las herramientas CASE:  (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).
     Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue  Excelerator  que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.
     De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas.
Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir:
•   Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos.
•  Herramientas de diseño para dar apoyo al análisis de datos.
•  Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico.
• Herramientas para desarrollar los prototipos de las aplicaciones.
     El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos.