Trabajo Investigativo No. 02

Ingeniería de Software

Presentado por:

Hasbleydi Yurani Reyes Saldaña

Camilo Esteban Rodriguez Forero

Presentado a:

Juan Carlos Guevara Bolaños

Universidad Distrital Francisco José de Caldas, Facultad Tecnológica

Bogotá D.C.

2017

Tabla de contenido

1. En que consiste la generación automática de software................................3

2. Características de la generación automática de software............................5

3. Ventajas de la generación automática de software......................................7

4. Problemas de la generación automática de software...................................8

5. Etapas de la generación automática de software.......................................10

6. Taller sobre uso de la herramienta de generación de código.....................16

7. Explicación de la herramienta.....................................................................16

8. Conclusiones..............................................................................................16

9. Bibliografía..................................................................................................16

1. En que consiste la generación automática de software

El concepto de generación automática involucra más que lo que se espera inicialmente. Si bien con un proceso automatizado el factor humano deja de ser un factor limitante (el proceso se realiza más rápidamente), la importancia no es solamente el ahorro en tiempo. La principal consecuencia es que el diseñador deja de codificar manualmente el código y pasa a tomar decisiones más interesantes e importantes de diseño: como el modelo puede ser generado automáticamente en pocos segundos, puede decidir cambiar la arquitectura y rápidamente ver los resultados del desempeño del sistema, y explorar nuevas posibilidades en poco tiempo. Se puede probar múltiples diseños en el mismo tiempo en que el diseñador tardaría en codificar manualmente un solo diseño. Así que el aumento en la productividad es gigantesco.

Uso de librerías y generación: se puede proceder a construir el sistema usando componentes tomados de una librería predefinida, pero este abordaje limita la flexibilidad en que el modelo pueda cambiar, o daría muy pocas opciones de modificación. La única opción para minimizar este efecto sería construir una librería muy extensa, que cubra todas las posibles opciones, y esta misma librería se debería generar automáticamente, por lo cual, simplemente se estaría moviendo la complejidad de una fase del diseño al otro. Considerando que el tiempo de generación es mucho menos que el de simulación, es más factible generarlos al momento de usarlos, así que en este caso, todo el modelo es generado, sin tomar elementos predefinidos.

La generación automática de código a partir de las especificaciones formales determina dos grupos importantes. Uno en la parte académica, donde se definen conjuntos de reglas, y el otro grupo en el cual se vienen desarrollando herramientas CASE como apoyo al proceso.

Gomes, Moreira y Déharbe (2007) y Mammar y Laleau (2006) proponen una metodología para la generación automática de código en lenguaje C a partir de especificaciones formales, utilizando el Método-B. Este método provee un formalismo para el refinamiento de las especificaciones y se estructura en módulos que se clasifican de acuerdo con su nivel de abstracción: máquina, refinamiento e implementación.

Peckham y MacKellar (2001) proponen un lenguaje natural controlado y unas plantillas para la especificación de casos de uso. Estos autores apoyan el desarrollo de software con una herramienta para la generación de procesos algebraicos a partir de los casos de uso.

Ramkarthik y Zhang (2006) definen un conjunto de reglas para generar la estructura básica de una aplicación en Java, tomando como punto de partida las especificaciones escritas en subconjunto de objetos Z (notación para las especificaciones formales).

Gangopadhyay (2001) propone una herramienta CASE para la obtención del diagrama entidad-relación a partir de un lenguaje controlado. Esta herramienta emplea un diagrama de dependencias conceptuales como representación intermedia a partir del lenguaje controlado y un parser basado en una red de transición aumentada (una especie de diagrama de máquina de estados) para el procesamiento de las diferentes palabras.

Un segundo grupo se enfoca en el desarrollo de herramientas CASE, las cuales permiten mejorar el proceso de generación de código. Entre ellas, se encuentran NL-OOPS (Natural Language Object- Oriented Production System), LIDA (Linguistic Assistant for Domain Analysis), CM-Builder (Class Model Builder), RADD (Rapid Application and Database Development) y NIBA. NL-OOPS es una herramienta CASE basada en un sistema de procesamiento del lenguaje natural denominado LOLITA (Largescale Object-based Linguistic Interactor, Translator and Analyser), el cual contiene una serie de funciones para el análisis del lenguaje natural (Mich, 1999). NL-OOPS entrega como resultado una versión preliminar del diagrama de clases de OMT. LIDA es una herramienta CASE que analiza el texto en lenguaje natural y hace una clasificación en tres categorías gramaticales: sustantivos, verbos y adjetivos (Overmyer, Lavoie y Rambow, 2001); con esta información, el analista debe asignar a cada categoría, manualmente, un elemento del diagrama de clases y, de esta manera, LIDA permite trazar este diagrama. CM-Builder es una herramienta CASE que permite la elaboración del diagrama de clases a partir de textos en inglés, utilizando como modelo intermedio una red semántica (Harmain y Gaizauskas, 2000). RADD es una herramienta CASE que se enfoca en la obtención del diagrama entidad-relación a partir de un lenguaje controlado. Además, emplea una "herramienta de diálogo moderado" que posibilita la comunicación con el diseñador de la base de datos en lenguaje natural (Buchholz y Düsterhöft, 1994). NIBA busca la elaboración de diferentes diagramas UML (especialmente clases y actividades, aunque se podrían obtener otros como secuencias y comunicación), empleando un conjunto de esquemas intermedios que denominaron KCPM -Klagenfurt Conceptual Predesign Model- (Fliedl y Weber, 2002). KCPM posee formas diferentes de representación del conocimiento para diferentes diagramas de UML. NIBA, además de generar los diferentes diagramas UML, genera el código fuente en C++.

Objetivos

Mejorar la productividad en el desarrollo y mantenimiento del software. Aumentar la calidad del software. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas

informáticos. Mejorar la planificación de un proyecto Aumentar la biblioteca de conocimiento informático de una empresa

ayudando a la búsqueda de soluciones para los requisitos. Automatizar el desarrollo del software, la documentación, la generación

de código, las pruebas de errores y la gestión del proyecto. Ayuda a la reutilización del software, portabilidad y estandarización de la

documentación Gestión global en todas las fases de desarrollo de software con una

misma herramienta. Facilitar el uso de las distintas metodologías propias de la ingeniería del

software.

2. Características de la generación automática de software

Una herramienta CASE cliente / servidor provee modelo de datos, generación de código, registro del ciclo de vida de los proyectos, comunicación entre distintos ingenieros. Las principales herramientas son KnowledgeWare’s Application Development Workbench, TI’s, Information Engineering Facility (IEF), y Andersen Consulting’s Foundation for Cooperative Processing.Deberes de una herramienta CASE Cliente / servidor:

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.

3. Ventajas de la generación automática de software

El código se genera de una manera transparente al usuario, así que puedes obtener un programa en C# sin saber ese lenguaje, por ejemplo:

Agiliza mucho el desarrollo de pequeños prototipos para hacer las demostraciones.

Los generadores interactivos suelen poseer como característica, que un usuarios sin saber programar en ningún lenguaje, pueda crear un programa más o menos complejo.

Facilidad para la revisión de aplicaciones

La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por mucho tiempo. Las herramientas CASE proporcionan un beneficio substancial para las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen a modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente.

Soporte para el desarrollo de prototipos de sistemas

Se suelen desarrollar diseños para pantallas y reportes con la finalidad de mostrar la organización y composición de los datos, encabezados y mensajes. Los ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y las características de la interface. Sin embargo, no se prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del prototipo. Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las características de entrada y salida son desarrolladas junto con el código orientado hacia los procedimientos y archivos de datos.

Generación de códigoComo ya se mencionó, algunas herramientas CASE tienen la capacidad de producir el código fuente. La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar un programa. Sin embargo, la generación del código también asegura una estructura estándar y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de la generación del código permiten volver a utilizar el software y las estructuras estándares para generar dicho código, así como el cambio de una especificación modular, lo que significa volver a generar el código y los enlaces con otros módulos. Ninguna de las herramientas que existen en el presente es capaz de generar un código completo en los dominios.

Soporte interactivo para el proceso de desarrolloLa experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.

Mejora en la habilidad para satisfacer los requerimientos del usuario

Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la calidad de las prácticas de desarrollo. Las herramientas CASE disminuyen el tiempo de desarrollo, una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y cantidad de interacción entre los encargados del desarrollo y el usuario. Las descripciones gráficas y los diagramas, así como los prototipos de reportes y la composición de las pantallas, contribuyen a un intercambio de ideas más efectivo.

4. Problemas de la generación automática de software

A continuación se discuten los problemas recurrentes en la generación automática de código, cuyos trabajos se presentaron en la sección previa.

o Intervención del analista

La mayoría de los trabajos requieren una alta participación del analista, con el fin de tomar decisiones de diseño pertinentes a la generación de código,

las cuales se deberían automatizar. La generación automática de código procura aliviar la carga del analista. Así, se busca optimizar el tiempo de desarrollo y minimizar los posibles errores, también buscando que el analista se centre más en el análisis subjetivo del dominio.

o Punto de partida

En la mayoría de los trabajos relacionados con la generación automática de código, se suelen utilizar, como punto de partida, algunos de los diagramas UML (clases, actividades, secuencias). Si bien este punto de partida permite la generación automática de código, sólo se puede hacer después de un análisis subjetivo del problema, lo cual requiere tiempo y puede tener implícitos errores de análisis. Si se procura la generación automática de código a partir de las etapas tempranas de desarrollo, se debería hacer desde la descripción del problema y no desde la solución como tal.

o Validación en tiempo real

La mayoría de los trabajos utilizan los esquemas conceptuales como punto de partida para la generación de código. Muchos de estos esquemas no los interpreta fácilmente el cliente, lo cual impide una validación suya en las etapas iniciales al desarrollo. Es necesario tener dicha validación, con el fin de que el proceso sea transparente. Para esto se tiene una alternativa en el lenguaje natural como punto de partida.

Falta de niveles estándar para el soporte de la metodología

Aún no aparece un conjunto “estándar” de herramientas CASE. Por tanto, debe tener precaución al seleccionar una herramienta de este tipo.Existen dos significados para las palabras “soporte de la metodología”. Una herramienta puede: 1) dar soporte a los diagramas que emplea una metodología o 2) soportarlos e imponer la metodología, sus reglas y procesos.Las herramientas CASE que existen en el presente, tienen una de las siguientes características:

* Son independientes de la metodología.

* Permiten que los usuarios definan sus propias metodologías.

* Soportan una metodología.

* Soportan las metodologías más diseminadas.

o Otras

La calidad del código, llegados a este punto muchos programadores avanzados pueden cuestionar, cómo de bueno es el código que generan estas herramientas. Desde Somos Binarios afirmamos que un programador avanzado y entendido en ese lenguaje, va a poder hacer código mucho mejor optimizado del que genera la máquina, porque puede adaptar mucho mejor el proyecto al lenguaje, mientras que el generador esta  pensado para que funcione en muchos proyectos muy distintos. Pero también es verdad, que un generador de código respecto a un usuario de nivel medio-bajo, posiblemente puede generar mejor código o por lo menos cometiendo un número sensiblemente inferior de errores.

Los generadores basados en lenguajes formales como UML, necesitan conocer UML y esto no es una cosa que se aprenda en un par de semanas, sino que necesita un duro y continuo trabajo para poder dominarlo. Así que algunos casos, puede ser más rentable aprender la nueva tecnología que aprender UML.

5. Etapas de la generación automática de software

Describe el desarrollo de software desde la fase inicial hasta la fase final, proponiendo etapas que sirven como referencia para realizar este proceso. Las fases que conforman el ciclo de vida son:

Preanálisis Análisis Diseño Desarrollo Pruebas Implantación Mantenimiento

El modelo en cascada

También llamado ciclo de vida clásico o tradicional, es el modelo más antiguo cuya propuesta de trabajo se fundamenta en un proceso ordenado y secuencial donde el producto de cada etapa, es el insumo para la etapa posterior. Las características principales de este modelo son:  

Se recomienda para el desarrollo de productos de gran tamaño cuyo tiempo de entrega sea largo. No se requiere demasiada experiencia por parte del equipo de trabajo El inicio de una etapa debe esperar la finalización de la etapa anterior La documentación del proceso realizado, se produce en cada etapa Se pueden presentar iteraciones entre las etapas del desarrollo, pero resultan costosas e implican repetir el trabajo. Cuando se trata de nuevos desarrollos, los requisitos del producto deben estar bien definidos y ser estables. Si se trata de una adaptación o una mejora de un producto existente, los requisitos deben entenderse de manera razonable. Un error encontrado en la etapa de pruebas, conduce al rediseño del producto Los primeros resultados se obtienen después de un tiempo considerable

El modelo en V

Se considera como una versión mejorada del modelo en cascada y por tanto, conserva las características de secuencialidad y organización. El modelo en V fundamenta su enfoque en la minimización de riesgos, la mejora de calidad, la reducción total de gastos y el perfeccionamiento de la comunicación entre los

participantes del proyecto de desarrollo de software. Además, incorpora procesos de verificación y validación. Las características de este modelo son:

 Se recomienda para el desarrollo de productos pequeños con equipos de trabajo de hasta cinco integrantes. Ideal para los analistas que no han programado siguiendo un modelo El inicio de una etapa debe esperar la finalización de la etapa anterior La documentación del proceso realizado, se produce en cada etapa Contiene etapas de retroalimentación para facilitar correcciones El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, situación que en la realidad puede ocurrir. Las pruebas comienzan a efectuarse después de la implantación, esto puede conducir a un retroceso de todo un proceso que costó tiempo y dinero.

Prototipos

Este modelo también se ha llamado evolutivo, se fundamenta en el desarrollo de un producto inicial que se presenta al usuario para obtener su aprobación y se perfecciona, a través de diferentes versiones, hasta obtener el producto adecuado. El modelo por prototipo se caracteriza por:

 Es un modelo menos formal de desarrollo Se recomienda para el desarrollo de productos pequeños o de tamaño medio Útil cuando se desconocen los requerimientos del producto o son poco estables Proporciona rapidez en el proceso de desarrollo Conveniente en desarrollos que requieren probar arquitecturas y tecnologías La posibilidad de establecer el número de iteraciones necesarias para obtener el producto definitivo, es mínima. La documentación del proceso se realiza sobre la versión final del producto A medida que avanza el proceso, incorporar cambios en los prototipos se convierte en una tarea difícil y costosa. La técnica de los prototipos se puede implementar dentro de cualquier modelo de proceso.

Espiral

Se trata de una propuesta que combina las propiedades de los modelos cascada y prototipos. Se fundamenta en un proceso de desarrollo en el cual se hacen entregas del producto -cada una más evolucionada o completa que la anterior- teniendo en cuenta los riesgos que pueden afectar el proceso. Cada ciclo del espiral representa una etapa del ciclo de vida del software. Las características principales del modelo en espiral son:

Es un enfoque acertado para el desarrollo de software a gran escala Cada iteración incluye definición de objetivos, evaluación y reducción de riesgos, desarrollo y validación y planificación. Exige cuidado con el tratamiento de los riesgos que se presentan en el proceso Requiere habilidad para evaluar el riesgo y resolverlo efectivamente Si se pasa por alto un riesgo, surgirán dificultades en el proceso El producto evoluciona conforme avanza el proceso de desarrollo

Desarrollo Rápido de Aplicaciones (DRA)

El modelo DRA es una versión que integra las características de los modelos cascada y prototipos, añadiendo velocidad de desarrollo. Propone la división del proyecto en módulos que son desarrollados por cada equipo de trabajo y luego se integran para configurar el producto definitivo.

Ofrece flexibilidad al proceso de desarrollo Requiere el compromiso de los desarrolladores y los clientes Los requisitos del producto deben ser comprendidos desde el inicio Aquellos productos de software que se puedan dividir en módulos, cuyo tiempo de desarrollo no exceda los tres meses, pueden abordarse con este modelo. Resalta el uso de componentes de software existente Apoya la construcción del producto con la generación automática de código

Modelo incremental

Combina elementos del modelo tradicional aplicado en forma iterativa. Este modelo emplea secuencias lineales escalonadas que proporcionan incrementos del producto.

Requiere de la planeación del desarrollo del producto de acuerdo con las prioridades de funcionalidad establecidas por el cliente. Requiere poco personal para el desarrollo de los incrementos iniciales, pero se puede vincular nuevo personal si los incrementos así lo exigen. El primer incremento es un producto que incorpora las funcionalidades prioritarias completamente funcionales. La evaluación del incremento, por parte del cliente, origina un plan para el desarrollo del incremento siguiente. Cada incremento integra nuevas funcionalidades al producto

6. Taller sobre uso de la herramienta de generación de código

Enunciado

Un Departamento de una Universidad quiere mostrar en su página web los planes de estudio de todas las titulaciones en las que imparte docencia.

La estructura de navegación que se quiere conseguir es la siguiente:

Un nodo de navegación representa el curso actual (la información de este nodo debe generarse dinámicamente)

Este nodo contiene la lista de todas las titulaciones en las que el Departamento impartirá docencia en dicho curso académico.

Cada una de las titulaciones incluye un enlace a otro nodo de navegación donde, dinámicamente, se muestra la información de dicha titulación, a saber: Nombre, Plan de estudios , Descripción , Centro donde se imparte ,Asignaturas troncales, obligatorias y optativas (organizadas por curso, y dentro de cada curso ordenadas alfabéticamente) titulación llevan asociado un enlace a otro nodo de navegación que presenta la información de la asignatura, esto es:

Código de asignatura, Nombre de la asignatura, Número de créditos de teoría y de práctica, Carácter de la asignatura (semestral o anual).

En caso de ser semestral debe indicarse en qué semestral se imparte

Profesores que imparten la asignatura, y en caso de haber más de uno, quién es el profesor responsable. De los profesores se necesita saber nombre, e-mail, teléfono del despacho, dirección del despacho, cargo que ocupa y si es doctor.

De esta manera, teniendo en cuenta lo anterior, desarrolle en EA:

Crear un diagrama que modele el negocio. Crear un modelo de requerimientos que contenga al menos casos

de uso y requerimientos no funcionales. Crear el diagrama de clases del sistema. Crear dos diagramas de secuencia que representen dos

escenarios del sistema. Generar un reporte en el que se muestren las relaciones

existentes entre los casos de uso y las clases. Realizar la generación de codigo automático

7. Explicación de la herramientao ¿Qué es?

Enterprise Architect de Sparx Systems es una herramienta CASE (Computer Aided Software Engineering) para el diseño y construcción de sistemas de software, para el modelado de procesos de negocios, y para objetivos de modelado más generalizados. EA está basada en la especificación the UML 2.1, que define un lenguaje visual que usa para modelar un dominio o sistema en particular (existente o propuesto). 

o Funciones elementales

Los pasos mínimos que debe ejecutar el responsable del proyecto se pueden resumir como:

• Solicitar el repositorio del proyecto en BD

• Crear el proyecto

• Activar seguridad

• Establecer usuarios administradores

• Crear grupos de usuarios y asignarles privilegios

• Crear usuarios y asignarlos a grupos

o Generación de código

Vista de código fuente: View -> Source code Para generar el código fuente de un grupo de clases Clic derecho sobre el diagrama para el que se desea generar el código

Code Engineering -> Generate Source Code Seleccionar las clases y presionar generate Para cada clase seleccionar el directorio destino o chequear la opción

Auto Generate Files. El código generado se puede ver en la vista de código fuente o en el

archivo físico. Se puede generar el código fuente de una clase haciendo clic derecho

sobre ella y Generate Code.

o Características

Plataforma integrada de modelado

modelado del ciclo de vida completo para: Los sistemas de negocios y de TI Software e Ingeniería de Sistemas En tiempo real y desarrollo embebido

Con las capacidades de gestión de requisitos integrados, Enterprise Architect ayuda a rastrear las especificaciones de alto nivel a los modelos de análisis, diseño, implementación, prueba y mantenimiento usando UML, SysML, BPMN y otros estándares abiertos.

Rastrear los cambios propuestosCapturar y seguimiento de los requisitos formales para el diseño, construcción, implementación y más allá. Utilice el análisis del impacto de rastrear los cambios propuestos a los requisitos originales. Construir la derecha del sistema.

características de administración de requisitos incorporadas de Enterprise Architect se pueden utilizar para:

Definir un modelo jerárquico requisitos organizada Trazar la implementación de los requisitos del sistema para modelar

elementos Buscar e informar sobre los requisitos Realizar análisis de impacto de los cambios propuestos a los requisitos

Modelar y gestionar información complejaEnterprise Architect ayuda a las personas, grupos y organizaciones de gran tamaño modelo y maneje información compleja. Mediante la integración y la conexión de una amplia gama de información estructural y de comportamiento

en forma visual, se puede construir un modelo coherente y verificable de lo que-es o qué-will-be .

Herramientas integradas en EA que ayudan a administrar la complejidad incluyen:

Diagramas para el modelado de conceptos estratégicos y de negocios de nivel

perfiles específicos de dominio y los patrones de modelo reutilizables

La línea de base y la versión de gestión para el seguimiento y la integración de los cambios

Seguridad basada en roles para ayudar a las personas adecuadas contribuyen en el camino correcto

8. Conclusiones

Las herramientas CASE permiten el desarrollo ágil de un proyecto a medida que las características, los objetivos y los requerimientos están planteados anticipadamente en la planificación. Sin embargo, en muchos casos no es del todo recomendable seguir el código sin la previa revisión de un analista e ingeniero; puesto que existe un factor de varianza que no es identificado en el momento de realizar cambios luego de un cronograma o una planificación ya realizada.

9. Bibliografía

http://revistas.ucr.ac.cr/index.php/ingenieria/article/view/8250/15647 http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S1794-

12372010000100011 https://www.somosbinarios.es/generadores-de-codigo/ http://www.monografias.com/trabajos14/herramicase/herramicase.shtml http://ingsoftware01.blogspot.com.co/2012/04/herramientas-case.html https://www.somosbinarios.es/generadores-de-codigo/ http://defreq.blogspot.com.co/2012/08/ciclo-de-vida-del-software.html http://www.sparxsystems.com.ar/