Está en la página 1de 19

Trabajo Investigativo No.

02
Ingeniera de Software

Presentado por:
Hasbleydi Yurani Reyes Saldaa
Camilo Esteban Rodriguez Forero

Presentado a:
Juan Carlos Guevara Bolaos

Universidad Distrital Francisco Jos de Caldas, Facultad Tecnolgica


Bogot D.C.
2017
Tabla de contenido

1. En que consiste la generacin automtica de software................................3


2. Caractersticas de la generacin automtica de software.............................5
3. Ventajas de la generacin automtica de software.......................................7
4. Problemas de la generacin automtica de software....................................8
5. Etapas de la generacin automtica de software........................................10
6. Taller sobre uso de la herramienta de generacin de cdigo......................16
7. Explicacin de la herramienta......................................................................16
8. Conclusiones................................................................................................16
9. Bibliografa...................................................................................................16
1. En que consiste la generacin automtica de software
El concepto de generacin automtica involucra ms 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 ms rpidamente), la
importancia no es solamente el ahorro en tiempo. La principal consecuencia
es que el diseador deja de codificar manualmente el cdigo y pasa a tomar
decisiones ms interesantes e importantes de diseo: como el modelo
puede ser generado automticamente en pocos segundos, puede decidir
cambiar la arquitectura y rpidamente ver los resultados del desempeo del
sistema, y explorar nuevas posibilidades en poco tiempo. Se puede probar
mltiples diseos en el mismo tiempo en que el diseador tardara en
codificar manualmente un solo diseo. As que el aumento en la
productividad es gigantesco.

Uso de libreras y generacin: se puede proceder a construir el sistema


usando componentes tomados de una librera predefinida, pero este
abordaje limita la flexibilidad en que el modelo pueda cambiar, o dara muy
pocas opciones de modificacin. La nica opcin para minimizar este efecto
sera construir una librera muy extensa, que cubra todas las posibles
opciones, y esta misma librera se debera generar automticamente, por lo
cual, simplemente se estara moviendo la complejidad de una fase del
diseo al otro. Considerando que el tiempo de generacin es mucho menos
que el de simulacin, es ms factible generarlos al momento de usarlos, as
que en este caso, todo el modelo es generado, sin tomar elementos
predefinidos.

La generacin automtica de cdigo a partir de las especificaciones


formales determina dos grupos importantes. Uno en la parte acadmica,
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 Dharbe (2007) y Mammar y Laleau (2006) proponen una


metodologa para la generacin automtica de cdigo en lenguaje C a partir
de especificaciones formales, utilizando el Mtodo-B. Este mtodo provee
un formalismo para el refinamiento de las especificaciones y se estructura
en mdulos que se clasifican de acuerdo con su nivel de abstraccin:
mquina, refinamiento e implementacin.

Peckham y MacKellar (2001) proponen un lenguaje natural controlado y


unas plantillas para la especificacin de casos de uso. Estos autores
apoyan el desarrollo de software con una herramienta para la generacin de
procesos algebraicos a partir de los casos de uso.
Ramkarthik y Zhang (2006) definen un conjunto de reglas para generar la
estructura bsica de una aplicacin en Java, tomando como punto de
partida las especificaciones escritas en subconjunto de objetos Z (notacin
para las especificaciones formales).

Gangopadhyay (2001) propone una herramienta CASE para la obtencin


del diagrama entidad-relacin a partir de un lenguaje controlado. Esta
herramienta emplea un diagrama de dependencias conceptuales como
representacin intermedia a partir del lenguaje controlado y un parser
basado en una red de transicin aumentada (una especie de diagrama de
mquina 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 generacin de cdigo. 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 anlisis del lenguaje natural (Mich, 1999).
NL-OOPS entrega como resultado una versin preliminar del diagrama de
clases de OMT. LIDA es una herramienta CASE que analiza el texto en
lenguaje natural y hace una clasificacin en tres categoras gramaticales:
sustantivos, verbos y adjetivos (Overmyer, Lavoie y Rambow, 2001); con
esta informacin, el analista debe asignar a cada categora, 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
elaboracin del diagrama de clases a partir de textos en ingls, utilizando
como modelo intermedio una red semntica (Harmain y Gaizauskas, 2000).
RADD es una herramienta CASE que se enfoca en la obtencin del
diagrama entidad-relacin a partir de un lenguaje controlado. Adems,
emplea una "herramienta de dilogo moderado" que posibilita la
comunicacin con el diseador de la base de datos en lenguaje natural
(Buchholz y Dsterhft, 1994). NIBA busca la elaboracin de diferentes
diagramas UML (especialmente clases y actividades, aunque se podran
obtener otros como secuencias y comunicacin), empleando un conjunto de
esquemas intermedios que denominaron KCPM -Klagenfurt Conceptual
Predesign Model- (Fliedl y Weber, 2002). KCPM posee formas diferentes de
representacin del conocimiento para diferentes diagramas de UML. NIBA,
adems de generar los diferentes diagramas UML, genera el cdigo 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
informticos.
Mejorar la planificacin de un proyecto
Aumentar la biblioteca de conocimiento informtico de una empresa
ayudando a la bsqueda de soluciones para los requisitos.
Automatizar el desarrollo del software, la documentacin, la generacin
de cdigo, las pruebas de errores y la gestin del proyecto.
Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la
documentacin
Gestin global en todas las fases de desarrollo de software con una
misma herramienta.
Facilitar el uso de las distintas metodologas propias de la ingeniera del
software.

2. Caractersticas de la generacin automtica de software

Una herramienta CASE cliente / servidor provee modelo de datos, generacin


de cdigo, registro del ciclo de vida de los proyectos, comunicacin entre
distintos ingenieros. Las principales herramientas son KnowledgeWares
Application Development Workbench, TIs, Information Engineering Facility
(IEF), y Andersen Consultings Foundation for Cooperative Processing.
Deberes de una herramienta CASE Cliente / servidor:
Proporcionar topologas de aplicacin flexibles. La herramienta debe
proporcionar facilidades de construccin que permita separar la
aplicacin (en muchos puntos diferentes) entre el cliente, el servidor y
ms importante, entre servidores.

Proporcionar aplicaciones porttiles. La herramienta debe generar


cdigo para Windows, OS/ 2, Macintosh, Unix y todas las plataformas de
servidores conocidas. Debe ser capaz, a tiempo de corrida, desplegar la
versin correcta del cdigo en la mquina apropiada.

Control de Versin. La herramienta debe reconocer las versiones de


cdigos que se ejecutan en los clientes y servidores, y asegurarse que
sean consistentes. Tambin, la herramienta debe ser capaz de controlar
un gran nmero de tipos de objetos incluyendo texto, grficos, 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 definicin de datos o una
agrupacin de mdulos.

Crear cdigo compilado en el servidor. La herramienta debe ser capaz


de compilar automticamente cdigo 4GL en el servidor para obtener el
mximo 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 interaccin con los
administradores de recurso debera ser negociable a tiempo de
ejecucin.
Trabajar con una variedad de software intermedios. La herramienta debe
adaptar sus comunicaciones cliente / servidor al software intermedio
existente. Como mnimo la herramienta debera ajustar los
temporizadores basndose en, si el trfico se est moviendo en una
LAN o WAN.

Soporte multiusuarios. La herramienta debe permitir que varios


diseadores trabajen en una aplicacin simultneamente. 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 contraseas y permisos de
acceso en distintos niveles para cada usuario. Tambin debe facilitar la
realizacin automtica de copias de seguridad y recuperaciones de las
mismas, as como el almacenamiento de grupos de informacin
determinados, por ejemplo, por proyecto o aplicaciones.

Desarrollo en equipo, repositorio de libreras compartidas. Debe permitir


que grupos de programadores trabajen en un proyecto comn; 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 libreras entre distintos realizadores y
mltiples herramientas; Gestiona y controla el acceso multiusuario a los
datos y bloquea los objetos para evitar que se pierdan modificaciones
inadvertidamente cuando se realizan simultneamente.
3. Ventajas de la generacin automtica de software

El cdigo 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 pequeos prototipos para hacer las


demostraciones.

Los generadores interactivos suelen poseer como caracterstica, que un


usuarios sin saber programar en ningn lenguaje, pueda crear un programa
ms o menos complejo.

Facilidad para la revisin 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 revisin de las aplicaciones. Contar con un depsito central agiliza el
proceso de revisin ya que ste proporciona bases para las definiciones
y estndares para los datos. Las capacidades de generacin interna, si
se encuentran presentes, contribuyen a modificar el sistema por medio
de las especificaciones ms que por los ajustes al cdigo fuente.

Soporte para el desarrollo de prototipos de sistemas

Se suelen desarrollar diseos para pantallas y reportes con la finalidad


de mostrar la organizacin y composicin de los datos, encabezados y
mensajes. Los ajustes necesarios al diseo se hacen con rapidez para
alterar la presentacin y las caractersticas de la interface. Sin embargo,
no se prepara el cdigo fuente, de naturaleza orientada hacia
procedimientos, como una parte del prototipo. Como disyuntiva, el
desarrollo de prototipos puede producir un sistema que funcione. Las
caractersticas de entrada y salida son desarrolladas junto con el cdigo
orientado hacia los procedimientos y archivos de datos.

Generacin de cdigo
Como ya se mencion, algunas herramientas CASE tienen la capacidad de
producir el cdigo fuente. La ventaja ms visible de esta caracterstica es la
disminucin del tiempo necesario para preparar un programa. Sin embargo, la
generacin del cdigo tambin asegura una estructura estndar 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 caractersticas de la generacin del cdigo permiten volver a utilizar el
software y las estructuras estndares para generar dicho cdigo, as como el
cambio de una especificacin modular, lo que significa volver a generar el
cdigo y los enlaces con otros mdulos. Ninguna de las herramientas que
existen en el presente es capaz de generar un cdigo completo en los
dominios.

Soporte interactivo para el proceso de desarrollo


La 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 catlogos y clasificar. Como
resultado de esto, se anticipa que los analistas repasarn y revisarn los
detalles del sistema con mayor frecuencia y en forma ms 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 relacin con el xito del sistema. De manera similar, tener los
requerimientos correctos mejora la calidad de las prcticas de desarrollo. Las
herramientas CASE disminuyen el tiempo de desarrollo, una caracterstica que
es importante para los usuarios. Las herramientas afectan la naturaleza y
cantidad de interaccin entre los encargados del desarrollo y el usuario. Las
descripciones grficas y los diagramas, as como los prototipos de reportes y la
composicin de las pantallas, contribuyen a un intercambio de ideas ms
efectivo.

4. Problemas de la generacin automtica de software


A continuacin se discuten los problemas recurrentes en la generacin
automtica de cdigo, cuyos trabajos se presentaron en la seccin previa.

o Intervencin del analista

La mayora de los trabajos requieren una alta participacin del analista, con
el fin de tomar decisiones de diseo pertinentes a la generacin de cdigo,
las cuales se deberan automatizar. La generacin automtica de cdigo
procura aliviar la carga del analista. As, se busca optimizar el tiempo de
desarrollo y minimizar los posibles errores, tambin buscando que el
analista se centre ms en el anlisis subjetivo del dominio.

o Punto de partida

En la mayora de los trabajos relacionados con la generacin automtica de


cdigo, se suelen utilizar, como punto de partida, algunos de los diagramas
UML (clases, actividades, secuencias). Si bien este punto de partida permite
la generacin automtica de cdigo, slo se puede hacer despus de un
anlisis subjetivo del problema, lo cual requiere tiempo y puede tener
implcitos errores de anlisis. Si se procura la generacin automtica de
cdigo a partir de las etapas tempranas de desarrollo, se debera hacer
desde la descripcin del problema y no desde la solucin como tal.

o Validacin en tiempo real

La mayora de los trabajos utilizan los esquemas conceptuales como punto


de partida para la generacin de cdigo. Muchos de estos esquemas no los
interpreta fcilmente el cliente, lo cual impide una validacin suya en las
etapas iniciales al desarrollo. Es necesario tener dicha validacin, 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 estndar para el soporte de la metodologa

An no aparece un conjunto estndar de herramientas CASE. Por tanto, debe


tener precaucin al seleccionar una herramienta de este tipo.
Existen dos significados para las palabras soporte de la metodologa. Una
herramienta puede: 1) dar soporte a los diagramas que emplea una
metodologa o 2) soportarlos e imponer la metodologa, sus reglas y procesos.
Las herramientas CASE que existen en el presente, tienen una de las
siguientes caractersticas:

* Son independientes de la metodologa.

* Permiten que los usuarios definan sus propias metodologas.

* Soportan una metodologa.

* Soportan las metodologas ms diseminadas.

o Otras
La calidad del cdigo, llegados a este punto muchos programadores
avanzados pueden cuestionar, cmo de bueno es el cdigo que generan
estas herramientas. Desde Somos Binarios afirmamos que un programador
avanzado y entendido en ese lenguaje, va a poder hacer cdigo mucho
mejor optimizado del que genera la mquina, porque puede adaptar mucho
mejor el proyecto al lenguaje, mientras que el generador esta pensado para
que funcione en muchos proyectos muy distintos. Pero tambin es verdad,
que un generador de cdigo respecto a un usuario de nivel medio-bajo,
posiblemente puede generar mejor cdigo o por lo menos cometiendo un
nmero 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 ms rentable aprender la nueva tecnologa que
aprender UML.

5. Etapas de la generacin automtica 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:

Preanlisis
Anlisis
Diseo
Desarrollo
Pruebas
Implantacin
Mantenimiento

El modelo en cascada

Tambin llamado ciclo de vida clsico o tradicional, es el modelo ms 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
caractersticas principales de este modelo son:
Se recomienda para el desarrollo de productos de gran tamao 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 finalizacin de la etapa anterior
La documentacin 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 adaptacin o una mejora de un producto existente, los
requisitos deben entenderse de manera razonable.
Un error encontrado en la etapa de pruebas, conduce al rediseo del
producto
Los primeros resultados se obtienen despus de un tiempo considerable

El modelo en V

Se considera como una versin mejorada del modelo en cascada y por tanto,
conserva las caractersticas de secuencialidad y organizacin. El modelo en V
fundamenta su enfoque en la minimizacin de riesgos, la mejora de calidad, la
reduccin total de gastos y el perfeccionamiento de la comunicacin entre los
participantes del proyecto de desarrollo de software. Adems, incorpora
procesos de verificacin y validacin. Las caractersticas de este modelo son:

Se recomienda para el desarrollo de productos pequeos 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 finalizacin de la etapa anterior
La documentacin del proceso realizado, se produce en cada etapa
Contiene etapas de retroalimentacin para facilitar correcciones
El modelo no contempla la posibilidad de retornar a etapas
inmediatamente anteriores, situacin que en la realidad puede ocurrir.
Las pruebas comienzan a efectuarse despus de la implantacin, esto
puede conducir a un retroceso de todo un proceso que cost tiempo y dinero.

Prototipos

Este modelo tambin se ha llamado evolutivo, se fundamenta en el desarrollo


de un producto inicial que se presenta al usuario para obtener su aprobacin y
se perfecciona, a travs 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 pequeos o de tamao
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
tecnologas
La posibilidad de establecer el nmero de iteraciones necesarias para
obtener el producto definitivo, es mnima.
La documentacin del proceso se realiza sobre la versin final del
producto
A medida que avanza el proceso, incorporar cambios en los prototipos
se convierte en una tarea difcil y costosa.
La tcnica 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 ms 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
caractersticas principales del modelo en espiral son:
Es un enfoque acertado para el desarrollo de software a gran escala
Cada iteracin incluye definicin de objetivos, evaluacin y reduccin de
riesgos, desarrollo y validacin y planificacin.
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, surgirn dificultades en el proceso
El producto evoluciona conforme avanza el proceso de desarrollo

Desarrollo Rpido de Aplicaciones (DRA)

El modelo DRA es una versin que integra las caractersticas de los modelos
cascada y prototipos, aadiendo velocidad de desarrollo. Propone la divisin
del proyecto en mdulos 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 mdulos, cuyo
tiempo de desarrollo no exceda los tres meses, pueden abordarse con este
modelo.
Resalta el uso de componentes de software existente
Apoya la construccin del producto con la generacin automtica de
cdigo

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 planeacin 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 evaluacin 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 generacin de cdigo

Enunciado

Un Departamento de una Universidad quiere mostrar en su pgina web los


planes de estudio de todas las titulaciones en las que imparte docencia.

La estructura de navegacin que se quiere conseguir es la siguiente:

Un nodo de navegacin representa el curso actual (la informacin de


este nodo debe generarse dinmicamente)
Este nodo contiene la lista de todas las titulaciones en las que el
Departamento impartir docencia en dicho curso acadmico.
Cada una de las titulaciones incluye un enlace a otro nodo de
navegacin donde, dinmicamente, se muestra la informacin de dicha
titulacin, a saber: Nombre, Plan de estudios , Descripcin , Centro
donde se imparte ,Asignaturas troncales, obligatorias y optativas
(organizadas por curso, y dentro de cada curso ordenadas
alfabticamente) titulacin llevan asociado un enlace a otro nodo de
navegacin que presenta la informacin de la asignatura, esto es:
Cdigo de asignatura, Nombre de la asignatura, Nmero de crditos de
teora y de prctica, Carcter 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 ms de uno,


quin es el profesor responsable. De los profesores se necesita saber
nombre, e-mail, telfono del despacho, direccin 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 generacin de codigo automtico

7. Explicacin de la herramienta
o Qu es?
Enterprise Architect de Sparx Systems es una herramienta CASE (Computer
Aided Software Engineering) para el diseo y construccin de sistemas de
software, para el modelado de procesos de negocios, y para objetivos de
modelado ms generalizados. EA est basada en la especificacin 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 mnimos 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 Generacin de cdigo

Vista de cdigo fuente: View -> Source code


Para generar el cdigo fuente de un grupo de clases
Clic derecho sobre el diagrama para el que se desea generar el cdigo
Code Engineering -> Generate Source Code
Seleccionar las clases y presionar generate
Para cada clase seleccionar el directorio destino o chequear la opcin
Auto Generate Files.
El cdigo generado se puede ver en la vista de cdigo fuente o en el
archivo fsico.
Se puede generar el cdigo fuente de una clase haciendo clic derecho
sobre ella y Generate Code.

o Caractersticas

Plataforma integrada de modelado

modelado del ciclo de vida completo para:


Los sistemas de negocios y de TI
Software e Ingeniera de Sistemas
En tiempo real y desarrollo embebido

Con las capacidades de gestin de requisitos integrados, Enterprise Architect


ayuda a rastrear las especificaciones de alto nivel a los modelos de anlisis,
diseo, implementacin, prueba y mantenimiento usando UML, SysML, BPMN
y otros estndares abiertos.

Rastrear los cambios propuestos

Capturar y seguimiento de los requisitos formales para el diseo, construccin,


implementacin y ms all. Utilice el anlisis del impacto de rastrear los
cambios propuestos a los requisitos originales. Construir la derecha del
sistema.

caractersticas de administracin de requisitos incorporadas de Enterprise


Architect se pueden utilizar para:

Definir un modelo jerrquico requisitos organizada


Trazar la implementacin de los requisitos del sistema para modelar
elementos
Buscar e informar sobre los requisitos
Realizar anlisis de impacto de los cambios propuestos a los requisitos
Modelar y gestionar informacin compleja

Enterprise Architect ayuda a las personas, grupos y organizaciones de gran


tamao modelo y maneje informacin compleja. Mediante la integracin y la
conexin de una amplia gama de informacin 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 estratgicos y de


negocios de nivel
perfiles especficos de dominio y los patrones de modelo
reutilizables
La lnea de base y la versin de gestin para el seguimiento y la
integracin 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 caractersticas, los objetivos y los requerimientos estn planteados
anticipadamente en la planificacin. Sin embargo, en muchos casos no es del
todo recomendable seguir el cdigo sin la previa revisin 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 planificacin ya
realizada.

9. Bibliografa

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/