Tabla de contenido

Por qu modernizar? ......................................................................................................................... 3

1.1. Qu es la modernizacin? ................................................................................................. 5
1.2 Enfoques para la modernizacin ............................................................................................... 5
1.3 La necesidad de modernizacin ................................................................................................ 6
1.3.1 La necesidad de modernizar la base de datos ................................................................... 6
1.3.2 La necesidad de modernizacin de interfaz ....................................................................... 6
1.3.3 La necesidad de modernizacin del programa .................................................................. 7
1.4 Los beneficios de la modernizacin .......................................................................................... 7
1.5 A partir de dnde empezar? .................................................................................................... 8
1.6 Colocacin de las reglas del juego............................................................................................. 8
1.7 Qu es una aplicacin moderna? ............................................................................................ 9
1.8 Obstculos ................................................................................................................................. 9
1.9 Comienza el viaje ..................................................................................................................... 10
Camino a la modernizacin ............................................................................................................... 10
2.1 En donde estas empezando? ................................................................................................. 10
2.2 Cules son sus metas de modernizacin? ............................................................................. 11
2.2.1 Reemplazo ........................................................................................................................ 11
2.2.2 Reingeniera ...................................................................................................................... 12
2.2.3 Refacing ............................................................................................................................ 13
2.2.4 Refactoring ....................................................................................................................... 15
2.3 Cmo modernizar .................................................................................................................... 15
2.3.1 Introduccin ..................................................................................................................... 15
2.3.2 Modelo de Modernizacin ............................................................................................... 16
2.3.3 Principios generales ......................................................................................................... 17
2.3.4 Fase 0: Preparar ............................................................................................................... 19
2.3.5 Fase 1: Experimentacin .................................................................................................. 22
2.3.6 Fase 2: Off and Running ................................................................................................... 23
2.3.7 Fase 3: Evaluacin y ampliar el pensamiento futuro ....................................................... 26
2.3.8 Fase 4: Implementacin ................................................................................................... 26
2.3.9 Repita segn sea necesario .............................................................................................. 28
Las tcnicas modernas de arquitectura de aplicaciones ................................................................... 29
3.1 Introduccin ............................................................................................................................ 29
3.1.1 Los sntomas de un mal diseo ........................................................................................ 29
3.2 La modularizacin ................................................................................................................... 30
3.2.1 Por qu la modularizacin es importante ...................................................................... 30
3.2.2 Principios generales ......................................................................................................... 32
3.3 Diseo por niveles ................................................................................................................... 33
3.4 Modelo de objetos de Negocios ............................................................................................. 34
3.4.1 Implementacin ............................................................................................................... 35
3.4.2 Ventajas ............................................................................................................................ 35
3.5 Los datos de programacin centrada ...................................................................................... 36
3.5.1 Mover a centrada en los datos de programacin ............................................................ 39
3.6 Servicio Orientacin ................................................................................................................ 40
3.6.1 Qu es un servicio?......................................................................................................... 42
3.6.2 Las propiedades de los servicios ...................................................................................... 43
3.7 Nube ........................................................................................................................................ 43
4.1 Editar, compilar y depurar IDE ................................................................................................ 45
4.2 SEU y PDM para RDi: Por qu cambiar? ................................................................................ 45
4.2.1 actual (y futuro) soporte de idiomas ................................................................................ 46
4.2.2 entorno de desarrollo basado en Eclipse ......................................................................... 46
















Por qu modernizar?
Para la comunidad de IBM i, la necesidad de modernizar las aplicaciones heredadas es ahora una
urgente requisito. El mundo de las aplicaciones empresariales se ha convertido en un rpido
movimiento, en constante cambio medio ambiente. La web, informtica mvil y la nube han
seguido rpidamente el impacto de interfaces grficas. La comunidad se enfrenta a un entorno en
constante cambio y se debe garantizar que las aplicaciones pueden ser mejoradas y mantenidos
cuando se trata de estos fcilmente nuevos requisitos.
Las opciones para la modernizacin de una aplicacin son o bien para reemplazarlo o para volver a
utilizar tcnicas de ingeniera. En cuanto a cul de estas dos opciones es mejor depende de la
aplicacin y por qu la modernizacin est llevando a cabo el proceso. No importa qu opcin es
la solucin correcta, todava hay un requisito para entender el proceso de modernizacin y el
proceso de re-ingeniera que es aprobada o rechazada.
Las aplicaciones tradicionales a menudo son grandes y difciles de modificar. La modernizacin de
un legado aplicacin no significa que la aplicacin debe ser reemplazado o reescrito en un nuevo
idioma. Modernizacin significa la reingeniera de una aplicacin. Esto puede incluir el cambio de
cualquier combinacin de la interfaz, la lgica de negocio, y la base de datos. El objetivo de la
modernizacin es para que sea ms fcil cambiar y mantener su aplicacin en el futuro y
proporcionar la derecha interfaz para los usuarios.

La realidad es que, a lo largo de los aos, las empresas ya han hecho una fuerte inversin en
aplicaciones que satisfacen las necesidades del negocio. Aunque los requisitos de negocio podran
estar cambiando, las necesidades de negocio actuales se deben cumplir. El reto es ser capaces de
mantener y reutilizar los principales procesos de negocio, mientras que la reingeniera, la
refactorizacin y mejorar el resto de la aplicacin es para satisfacer estas demandas.

Este captulo trata de las fuerzas impulsoras detrs de la modernizacin y algunos de los ms
comunes detrs de los proyectos de modernizacin. Cubre:
Cul es la modernizacin
La necesidad de modernizacin
Los beneficios de la modernizacin






















1.1. Qu es la modernizacin?
Modernizacin significa diferentes cosas para diferentes personas. Modernizacin podra
significar:
Creacin de una nueva interfaz de usuario
Refactorizar una base de datos
Hacer grandes cambios en el cdigo
Hacer pequeos cambios en el cdigo
No hacer cambios en el cdigo
Integracin de nuevas aplicaciones
Cualquier permutacin o combinacin de los elementos anteriores

La modernizacin puede ser cualquier cosa, desde la pantalla raspando una aplicacin para
convertirlo en un escalonado o la arquitectura orientada a servicios (SOA).

La modernizacin puede consistir en cualquier permutacin y combinacin del uso de una
independiente proveedor de soluciones de software (ISV), el rediseo de una base de datos, el
rediseo y la recodificacin de aplicacin programas, codificacin de nuevos programas, utilizando
nuevos lenguajes de programacin, y la escritura de nuevas aplicaciones. La modernizacin es un
trmino muy amplio con muchos aspectos diferentes a considerar. Este Redbooks publicacin est
dirigida a proporcionar una visin holstica de la modernizacin.





1.2 Enfoques para la modernizacin
El trabajo del desarrollador sera mucho ms fcil si hubiera una hoja de ruta simple para
Modernizacin. Por desgracia, este no es el caso. Hay muchos factores que determinan el enfoque
deseado para la modernizacin:
Presupuesto
Apoyo a la gestin
Por qu se est llevando a cabo el proceso de modernizacin? Qu permutacin de interfaz,
cdigo de base de datos, y la aplicacin debe modernizarse?

Recursos . Los retos a los que se enfrentan por una tienda de cien desarrolladores son muy
diferentes a los que enfrent en un taller de diez desarrolladores, que son, a su vez, muy, muy
diferente de los que enfrentan una tienda de dos desarrollador.
Cul es el estado de la aplicacin actual? Qu tan fcil es que va a ser la de cambiar esa
cdigo?
Cualquiera de estos elementos se puede dividir en varios puntos de la bala.
Puesto que hay diferentes requisitos, diferentes puntos de partida, diferentes niveles de apoyo, y
diferentes niveles de recursos, hay muchos enfoques diferentes para la modernizacin.
Aunque hay muchos enfoques, uno de los retos principales es asegurar que el enfoque elegido es
fluido. Hay que caminar por la lnea entre el control y la flexibilidad y desarrollar la capacidad para
abrazar lo nuevo, manteniendo un ncleo de trabajo.
Al principio, la eleccin de un camino a la modernizacin parece ser una tarea desalentadora. Si se
acepta que el camino va a cambiar cuando se inicia el proceso, es mucho ms fcil para empezar
1.3 La necesidad de modernizacin
La necesidad de modernizacin por lo general es impulsado por una necesidad comercial: esto
significa que a menudo que incitan a los usuarios la necesidad de la modernizacin. Aunque
podramos saber que, desde un punto de vista tcnico, una aplicacin debe ser modernizada, es
raro que tengamos los recursos y financiacin necesaria sin las peticiones y el apoyo de los
usuarios y de gestin.
Los usuarios son ms conocedores de la tecnologa. Demanda de los usuarios no es slo para las
soluciones. Los usuarios exigen cmo quieren las soluciones entregadas.
Demandas empresariales conducen a los requisitos de modernizacin en tres reas:
Database
Interface
Cdigo de la aplicacin
Aunque hay muchas variaciones, los siguientes ejemplos deben sonar familiares.
1.3.1 La necesidad de modernizar la base de datos
Estos son algunos de los escenarios ms comunes que pueden conducir a la modernizacin de
bases de datos.
La compaa ha decidido sustituir Query/400 con IBM DB2 Web Query.
La base de datos necesita ser modernizado para hacerlo ms accesible a los usuarios y para
garantizar que el uso de software tales como DB2 Web Query no afecta negativamente al
rendimiento en el sistema.
Usuarios han comenzado a utilizar una nueva herramienta de anlisis de PC que extrae
informacin del base de datos. El proveedor herramienta recomienda que los datos se repliquen
en otra plataforma, ya que no se ve como una base de datos para ellos. La base de datos necesita
ser reprogramado para representar en un formato ms familiar para un administrador de base de
datos (DBA).
Una nueva aplicacin ser escrita sobre una base de datos existente. La nueva aplicacin har
uso de las funciones de base de datos (por ejemplo, las restricciones y los disparadores) que no
han sido implementados en la base de datos existente. La implementacin de estas caractersticas
tambin podra tener afectar a la aplicacin existente.
Una aplicacin existente tiene que ser reescritos. La modernizacin de la base de datos
reducir la complejidad de los programas disponibles en la nueva aplicacin.
1.3.2 La necesidad de modernizacin de interfaz
La necesidad de interfaces nuevas o mejoradas es probablemente la razn ms citada para
modernizacin. Estos son algunos de los escenarios ms comunes que pueden conducir a la
modernizacin de la interfaz.
Una empresa invierte en nuevas aplicaciones que utilizan una interfaz grfica de usuario (GUI).
Los usuarios son la conmutacin entre la GUI y tradicionales 5,250 interfaces para diferentes
aplicaciones. Ellos preferira una interfaz comn y GUI es la preferencia.
Ahora Hay generaciones de usuarios que nunca se han encontrado con una pantalla de 5250 de
estilo antes de unirse a la compaa. Para estos usuarios, una interfaz grfica de usuario es la
interfaz de eleccin y una Pantalla de 5250 de estilo se considera pasado de moda.

Usuarios que han estado utilizando una aplicacin para un nmero de aos que soliciten una
nueva interfaz grfica de usuario para que se coloca en su lugar. Esto es a menudo una reflexin
sobre el diseo de pantallas pobres. Los usuarios de Internet estn felices con la solicitud, pero no
con la forma en que se ve. A menudo, cuando los usuarios estn contentos con Diseo de 5250 de
estilo, que no quieren una nueva interfaz hasta que los nuevos usuarios que no tienen con
experiencia de estilo de 5250, ven.
El CEO quiere informes mensuales como un solo grfico en su telfono inteligente.
Percepcin. 5250 se considera viejo y GUI o mvil se considera nueva. Las nuevas aplicaciones
debe ser mejor, no? A menudo, una nueva interfaz de usuario puede cambiar dramticamente la
vista de la comunidad.
Qu generacin de usuarios tendr instrucciones sobre cmo utilizar un ratn?
1.3.3 La necesidad de modernizacin del programa
Estos son algunos de los escenarios ms comunes que pueden conducir a la modernizacin del
programa.
Una nueva interfaz basada en la web que se replica una aplicacin 5250 de estilo existente est
siendo desarrollado. Por ejemplo, se est creando una aplicacin de entrada de pedidos para que
los clientes pueden colocar sus propias rdenes sin tener que llamarlos pulg La nueva aplicacin
debe utilizar el misma lgica de negocio como la aplicacin existente. Por desgracia, la lgica de
negocio est firmemente incrustada en los programas de pantalla 5250.
Debido a los cambios que se estn haciendo a la base de datos o de la interfaz, los cambios
tienen que ser hecho a los programas de aplicacin.
Una aplicacin tiene cuatro programas horrendos, gigantescas que contienen la lgica de
negocio principal de la aplicacin. Cualquier cambio (aunque sea pequeo) a uno de estos
programas es un gran empresa requiere un conocimiento detallado de los programas y de
extensas pruebas. es hora de simplificar su coste de mantenimiento.
Los programadores con el conocimiento detallado de los programas de aplicacin estn a punto
de la jubilacin. Sera mejor si el cdigo estuviera en un formato ms fcil para un recin
programador entrenado para entender. Es el momento de utilizar los estilos de programacin y
herramientas modernas.
Clientes necesitan acceder a la informacin existente a travs de un servicio web en lugar de
interfaces existentes.
1.4 Los beneficios de la modernizacin
Son muchos los beneficios que se derivan de la modernizacin, que incluye:
Una mejor interfaz
Una mejor base de datos
Ms fcil de mantener aplicaciones
Aplicaciones ms flexibles. Nuevos requerimientos de negocio son ms fciles de implementar.
Aplicaciones integradas. Es ms fcil de integrar con otras aplicaciones, plataformas e
interfaces.
Es ms fcil encontrar desarrolladores que pueden mantener cdigo moderno.
Una aplicacin modernizada puede dar a la empresa una ventaja competitiva. La capacidad de
hacer cambios rpidos en la aplicacin significa que la empresa puede responder rpidamente a
los cambios del negocio.
Siga usando la inversin existente. El hecho de que una aplicacin podra beneficiarse de una
Actualizacin a su interfaz no significa que la aplicacin no est funcionando un cumplimiento de
una necesidad de negocio.
1.5 A partir de dnde empezar?
Al igual que con todos los viajes, la duracin del viaje y el reto del terreno que se atravesar
depender de donde usted est comenzando.
La ventaja y desventaja de IBM i es que las aplicaciones son compatibles con los principios de
versiones. Es posible que un programa que estaba escrito en el System/38 en 1980 para funcionar
(sin recopilacin) en uno de IBM Power Systems de hoy. La ventaja es que, como era de hardware
reemplazado y mejorado, las aplicaciones no necesitan ser actualizados o cambiados.
Desafortunadamente, las mismas aplicaciones se escriben utilizando cdigo y tcnicas que podran
haber sido de codificacin de punta hace veinte aos ms, pero inferiores a las necesidades de hoy
en da.
Es necesario determinar lo siguiente:
La aplicacin tiene una base de datos relacional bien estructurada?
Fue la aplicacin escrita originalmente para System/34, Sistema/36, System/38 o uno de los
Muchas versiones de IBM AS/400, IBM eServer , IBM iSeries o IBM i?
en Qu lenguaje est desarrollada la aplicacin? Es COBOL, COBOL ILE, RPG II, RPG III,
RPG IV, Java, C, algn otro lenguaje, o alguna permutacin o combinacin de dos o ms idiomas?
Es la aplicacin IBM Integrated Language Environment (ILE)?
Los programas de aplicacin estn bien estructurado?
1.6 Colocacin de las reglas del juego
El Inicio de un proyecto de modernizacin puede ser una perspectiva desalentadora y es fcil
sentirse abrumado por las opciones y la cantidad de informacin disponible. Esta es la etapa en la
que la mayora de la gente dice: es ms fcil seguir con lo que sabes en lugar de abrazar lo nuevo.
Hay tambin el reto de tener que mantener la aplicacin existente mientras se est modernizado.
El alcance de un proyecto de modernizacin, la importancia de las diferentes opciones y la
estructura de un proyecto depende de los recursos disponibles y la meta para el resultado. Hay
enormes diferencias entre las opciones disponibles para una tienda de un solo desarrollador y un
centenar de tienda de desarrollador. Por lo general, hay que ser selectivos acerca de lo que va a
ser modernizado y cmo pueden lograrse.
Puede haber ms beneficios de la modernizacin de cdigo en lugar de empezar con la base de
datos o viceversa. Las opciones sobre el uso de nuevos lenguajes dependern de la disponibilidad
de formacin o programadores con las habilidades requeridas. La necesidad de un cambio bien
definido de proceso de gestin es muy variado dependiendo de la cantidad de programadores que
estn trabajando en el proyecto. Hay muchos trminos y condiciones que se aplican.
Sera de gran ayuda si hubiese un solo plan que podra ser aplicado a todos los proyectos de
modernizacin, pero este no es el caso. El proceso ser diferente para cada tienda y cada
aplicacin.
Aunque cada proyecto de modernizacin es diferente, hay una serie de reglas bsicas y
circunstancias que son comunes a todos.
Hay principios bsicos que deben aplicarse a todos los proyectos de modernizacin:
No tengas miedo al fracaso
Habr una necesidad de la educacin y la formacin.
Desarrolladores debe utilizar las herramientas adecuadas y tienen que aprender a usarlos.
Habr una necesidad de gestin del cambio. Esta ser la gestin del cambio en una
Entorno de desarrollo en oposicin a un entorno de mantenimiento.
Pruebe un proyecto no oficial. Pasar por el proceso de modernizacin, con slo un par de
programas. Lleve a cabo una prueba de concepto (POC).
Dar pequeos pasos. Hay mucho que aprender.
Pon un proceso de documentacin en el lugar. Usar Wikis.
Determinar las normas y disciplinas para el proceso de modernizacin. Al comienzo de la
proceso, las normas y disciplinas sern las directrices, que se convertir en firme procesos.
No se adhieren a las mismas prcticas que han estado utilizando durante aos. Utilice gil
principios de desarrollo para entregar proyectos ms pequeos que se acumulan unos sobre otros.
Tienes que hacer las cosas bien la primera vez. De lo contrario, se puede aadir a los gastos.
Considere una solucin "tctica" que puede aprovechar su objetivo estratgico.




1.7 Qu es una aplicacin moderna?
Una aplicacin moderna es aquella en que las modificaciones o mejoras a la aplicacin tienen una
efecto mnimo. Por ejemplo, cambios en la interfaz no deben exigir cambios en el lgica de
negocio.
La naturaleza de una aplicacin moderna es que el diseo de la base de datos y programas es tal
que el requisito de la prueba se reduce al mnimo. Este enfoque permite el desarrollo rpido y
ms fcil, mantenimiento menos complejo.
Estas son algunas de las caractersticas que debe buscar en una aplicacin moderna:
Un diseo escalonado que separa la aplicacin en componentes separados: interfaz,
lgica de negocio, y la base de datos.
Una base de datos bien diseado y sintonizado que implementa la integridad
flexibilidad de cdigo, lo que permite un medio flexible para el desarrollo de nuevas interfaces
y cambiar los procesos de negocio.
La reutilizacin de cdigo, lo que significa que los mismos procedimientos se utilizan en todas
partes. No significa que el cdigo se copia y se pega en mltiples programas.
mantenibilidad de Cdigo, lo que significa que no hay ningn cdigo duplicado y que la
estructura de los programas es ms simple y ms fcil de entender. El mantenimiento de estos
programas debe tener menos efectos secundarios potenciales.
1.8 Obstculos
Aparte de las necesidades obvias de financiamiento y de recursos, hay una serie de
condiciones que pueden inhibir el proceso de modernizacin. Con base en la experiencia del
equipo, estos son algunos de los obstculos comunes que pueden dificultar, si no descarrilar, el
proceso de modernizacin:
Desarrolladores no utilizan las herramientas adecuadas. Los desarrolladores estn a gusto con
lo que saben.
A veces, es ms fcil de mantenerse dentro de la zona de confort de la utilizacin de herramientas
familiares en lugar de frente a la tarea de aprender a usar nuevas herramientas.
desarrolladores no saben lo que no saben. Los desarrolladores que no tienen experiencia con
ciertas tecnologas o tcnicas de tomar decisiones acerca de cmo van a ser utilizados. es
por qu una prueba de concepto es tan importante.
Desaprender viejos hbitos. Muchos desarrolladores han estado observando las mismas
prcticas por muchos aos. Puede ser un reto para cambiar estos hbitos y adoptar otras nuevas.
No conseguir una formacin adecuada. No es suficiente para instalar una herramienta y decir
"empezar a usarlo", o para instruir a los desarrolladores que deben utilizar una nueva tcnica
cuando no lo hacen realmente entender por qu deben usarlo o cmo usarlo correctamente.
Hay tanto que aprender que los desarrolladores se sienten abrumados antes de que
comiencen. todo debe hacerse en pequeos pasos.
Todo el proceso de modernizacin puede ser aterrador. En primer lugar, hay muchos
incgnitas que los desarrolladores quieren retirarse a lo que mejor saben hacer.
El establecimiento de objetivos poco realistas. Los objetivos se establecen a menudo sin
entender lo que se requiere para alcanzarlos.
La falta de apoyo a la gestin. Es por esto que es importante empezar poco a poco. Entre ms
pronto posible demostrar las ganancias, ms fcil conseguir apoyo de la direccin.

1.9 Comienza el viaje
Cualquiera de los muchos caminos de modernizacin que est a punto de salir en el viaje ser
lleno de desafos, logros y diversiones interesantes. Es un viaje que constantemente ofrece nuevos
horizontes.



Camino a la modernizacin

En este captulo se proporciona una va de modernizacin que usted puede seguir,
independientemente del enfoque de modernizacin que usted elija. Tambin proporciona
directrices para ayudar a definir donde debe iniciar su camino a la modernizacin y las definiciones
de algunos de los ms comunes modernizacin se acerca disponible.

2.1 En donde estas empezando?

Antes de iniciar un esfuerzo de modernizacin, es importante hacer una evaluacin honesta de su
los activos de software para definir su estrategia. Incluso si su software est funcionando, puede
ser que necesite ser modernizado. Existen importantes atributos de calidad de software a
considerar ms all de la funcionalidad, como la mantenibilidad, flexibilidad, facilidad de uso y
rendimiento. Para esta evaluacin, considerar los siguientes pasos:
. 1 Construir un inventario de sus aplicaciones principales:
- Objeto social
Definir el propsito de negocio de la aplicacin desde una perspectiva empresarial.
Entender que los procesos de negocio estn soportados por la aplicacin y cmo
cada uno es crtico.
- Interesado principal
Determinar quines son los interesados que se debe tener en cuenta en un eventual proyecto de
modernizacin. Esta lista le recordar la importancia de este proyecto de diferente
personas, no slo los expertos en TI.
- Experto tcnico
Es necesario comprender claramente que los tcnicos son que mantienen las aplicaciones. Estos
expertos saben muchos pequeos detalles acerca de la aplicacin que puede ser fundamental en
el proyecto.
. 2 Evaluar cada aplicacin segn los siguientes criterios:
- Flexibilidad de la interfaz de usuario
- Capacidad de mantenimiento
-Performance
- Facilidad de integracin
- Habilidades disponibles
- El valor del negocio
. 3 Defina sus metas de modernizacin:
- Mejor capacidad de mantenimiento
- Nueva interfaz de usuario
- Mejora de la legibilidad del cdigo
- Mtodos de acceso a base de datos de mejores
4. Priorizar el inventario de acuerdo a las metas.
Despus de haber completado estos pasos, usted est listo para empezar a trabajar. La
modernizacin ,las actividades implicarn diferentes aspectos de la aplicacin, incluyendo:
- Base de Datos
- Interfaz de usuario
- Integracin con otros sistemas
- La lgica de negocio
Usted acaba de empezar, as que no trate de planificar todo el proyecto de modernizacin en este
punto.
Sus planes de modernizacin va a cambiar con el tiempo y se perfeccionar a lo largo del camino.
Encuentra una pequea pieza con que usted puede comenzar. Centrarse en piezas pequeas que
con el tiempo puede llevar a grandes cosas.


2.2 Cules son sus metas de modernizacin?
Dependiendo de sus objetivos de modernizacin, hay varios mtodos disponibles. Lo que
debe tener en cuenta es que no hay un enfoque de "talla nica" para la modernizacin proceso.
Esta seccin presenta algunos de los enfoques ms comunes en la aplicacin modernizacin, que
son fcilmente adaptables a la mayora de los objetivos de modernizacin.
2.2.1 Reemplazo
En este enfoque de la modernizacin, el sistema original se sustituye por un nuevo sistema
completo.
El nuevo sistema puede ser por encargo o un producto fuera de la plataforma comercial. Esta
tcnica puede ser apropiado si los costos de modernizacin son extremadamente altos para
justificar, una modernizacin proyecto bajo un enfoque diferente, o si la aplicacin existente ya no
es capaz de satisfacer la los objetivos de negocio.
No puede haber muchos riesgos en este enfoque que usted debe considerar. Por ejemplo:
No hay garanta de que el nuevo sistema contendr la misma funcionalidad o
rendimiento que el sistema antiguo, que por lo general tiene un largo historial de cambios para
que sea personalizado para las necesidades del negocio. Esta es, probablemente, va a causar una
cierta degradacin de el servicio en algn nivel.
El personal de TI involucrados en el mantenimiento del antiguo sistema necesitarn
capacitacin para llegar a conocer el nuevo sistema. Esta formacin no es definitivamente
opcional.
Las nuevas aplicaciones pueden cambiar sus metodologas de backup y recuperacin, y deben
ser considerado.

2.2.2 Reingeniera
La reingeniera es el enfoque de la modernizacin que transforma la aplicacin original en un
nueva forma de mejorar sus caractersticas originales, como la funcionalidad, el rendimiento, la
flexibilidad, Interfaz de usuario y de mantenimiento con menos riesgo de sustitucin.
La principal diferencia entre la sustitucin y la reingeniera es que, en el ltimo enfoque,
usted debe tomar en cuenta la aplicacin existente como una limitacin de los pasos a seguir en
el proceso de modernizacin. En otras palabras, no se puede ignorar la aplicacin antigua. Por lo
general, la reingeniera de enfoque es un proceso de dos fases:
- La ingeniera inversa
- Ingeniera Forward
Ingeniera Inversa
La ingeniera inversa es la extraccin de los procesos de alto nivel y la estructura del original
codificar en una representacin fcilmente comprensible. La comprensin del cdigo existente
adquirida en esta fase es vital para el proceso de reingeniera. Dada la complejidad de muchos de
las aplicaciones que necesitan ser modernizados y la falta de documentacin funcional existente,
este proceso puede ser difcil. As que tenga en cuenta que hay muchas herramientas que le
pueden ayudar en este proceso.
Los pasos clave que tienen lugar en esta fase son:
1. Generar una representacin estructural del cdigo que le ayuda fcilmente entenderlo.
2. Iniciar el mapeo de la representacin estructural del cdigo para funcionalidades de negocio.
este le ayudar a identificar las reglas de negocio reutilizables que se pueden extraer de la
modularidad.

3. Construir una representacin arquitectnica de la aplicacin para que pueda empezar a
entender la aplicacin como un todo.
Tenga en cuenta que las tareas de ingeniera inversa por lo general se repiten a lo largo de la
modernizacin proceso varias veces. No se preocupe si usted est encontrando difcil de entender
la aplicacin. como el proceso de modernizacin avanza, su comprensin del sistema original se
Aumenta.
ingeniera directa
Ingeniera directa, tambin conocido como el "refinamiento", es la creacin del nuevo sistema a
partir de la representacin de alto nivel del cdigo original.
Esta fase se procesa con los siguientes pasos:
1. Construir una nueva representacin arquitectnica de la aplicacin deseada.
2. Definir la transformacin funcional de la original a la nueva aplicacin.
3. Escriba el nuevo cdigo.
En este proceso, se debe aplicar buenas prcticas en trminos de diseo, cdigo, tecnologas y
herramientas. Ms adelante en este libro, usted encontrar muchas herramientas, tcnicas y
prcticas que usted debe considerar durante la construccin de la nueva aplicacin. Hay muchas
herramientas para ayudar con los actuales la comprensin del programa, junto con herramientas
para ayudarle a escribir cdigo de forma moderna.
2.2.3 Refacing
Refacing es la reingeniera de slo la interfaz de usuario de la aplicacin. El principal objetivo
de este enfoque es mejorar la facilidad de uso y flexibilidad desde el punto de vista del usuario y
sin tener que reestructurar el cdigo subyacente de la aplicacin. Refacing es una tecnologa que
tiene estado disponibles durante mucho tiempo. Algunas soluciones son mejores que otros. El uno
significativa las ventajas de una solucin de la renovacin es el tiempo de comercializacin.
Utilizando una tecnologa de rectificacin, puede potencialmente mover una aplicacin 5250 de
"pantalla verde" a una web o aplicacin mvil en cuestin de varios das. Esto no significa que
usted tiene que parar en refacing. Este enfoque puede ser utilizado como un trampoln o primera
aproximacin paso. Este mtodo le puede dar un tiempo valioso si estn considerando un enfoque
de la reingeniera.
Tipos de rectificacin
Hay ms de una manera de revestir de nuevo la aplicacin. Dependiendo del grado en que va a ser
aplicado, algunas tcnicas de reparacin son slo superficiales y no requieren cambios
en el cdigo fuente. Otras tcnicas involucran cambios mnimos en el cdigo que se encarga de la
IU, pero sin entrar en la lgica de negocio o el acceso de base de datos.
raspado de pantalla
Este tipo de rectificacin se centra en la conversin de las aplicaciones tradicionales de 5250
basadas en terminales las interfaces en la ventana basados en interfaces web o interfaces mviles
basados.
captura de imgenes
por lo general funciona mediante la emulacin de un usuario en el terminal. Mientras estn
conectados, que emulan pulsaciones de teclado, procesen la salida de la pantalla, extraer los
datos, y generar una nueva pantalla. El usuario ve la nueva interfaz de usuario, mientras que la
captura de imgenes hace la intermediacin. estas tecnologas estn dirigidas a la lectura de la
corriente de datos de 5250 y la modificacin de lo que el usuario ve sobre la base de algunos
contenidos fusionada que puede cambiar o controlar el diseo, el color, y mucho
Ms. Este es un gran acercamiento para aplicaciones en las que ya no tienen acceso a la
cdigo fuente.

Para los programas interactivos, tambin puede utilizar la OA para transformar su aplicacin. El
nivel en que acta OA es diferente de un raspador de pantalla. La corriente de datos 5250 se
omite y el buffer de E / S del programa RPG se asigna directamente al controlador de la OA. El
bfer de E / S pueden ser procesados por nombre de campo o a travs de una estructura de datos
para cada formato. Esta oferta ms flexibilidad y posibilidades sobre el control y las extensiones de
su rectificacin enfoque. Puede encontrar ms informacin sobre la OA en la seccin Open Access.
Uso de la solucin de OA le permitir potencialmente controlar la interfaz de usuario de una
manera ms directa de su RPG existente cdigo y aprobar nuevos datos directamente desde su
nueva interfaz de usuario para el cdigo RPG backend.
Beneficios de la rectificacin
Al igual que con todos los enfoques de modernizacin, rectificacin puede traer muchos beneficios
a corto
plazo, incluyendo:
inicio rpido
Con este enfoque, se puede iniciar y terminar la modernizacin muy rpido. Usted no tiene que
entender el cdigo o cambiar la lgica de negocio. Esto puede ser muy til cuando la bsqueda
apoyo ejecutivo para los proyectos de modernizacin ms detallados, como la refactorizacin
completa.
Centrarse slo en la interfaz de usuario
Con refacing que no es necesario para entender el cdigo subyacente de la aplicacin. Si
Use una solucin de captura de imgenes, la aplicacin original puede ser slo un cuadro negro
para usted. si vas con OA, slo tendr que cambiar la especificacin de archivo de pantalla (una
palabra clave en el F-spec). Esto puede reducir el riesgo de romper las partes de la aplicacin que
usted no lo hace entender.
Comience a mover a otros enfoques de modernizacin
Pronto se dar cuenta de que usted necesita para empezar a cambiar otros aspectos de la
aplicacin.
Para hacer ms fcil de mantener. El enfoque de la OA se abre muchas posibilidades para
considerar cuando usted est listo para comenzar un esfuerzo de modernizacin integral. A
menudo, OA puede ser un punto de inicio para un esfuerzo ms amplio de modernizacin.
Mostrar gran mejora rpidamente
Riesgos
Usted ha aprendido los beneficios del enfoque de rectificacin, pero hay muchos riesgos asociados
con este enfoque. Usted puede dar un "lavado de cara" a la aplicacin y hacer que se vea moderna
a los usuarios finales. No obstante, la aplicacin sigue siendo el mismo inflexibles y difciles de
mantener pedazos de software.
Desde un punto de vista del rendimiento, el rendimiento de la aplicacin puede verse afectada,
porque no fue diseado originalmente con la nueva interfaz de usuario en mente. Para percibir
beneficios reales, la Modernizacin de IU se debe acompaar con un rediseo del cdigo
subyacente, donde se puede optimizar en consecuencia.
Refacing una aplicacin no tiene en cuenta el diseo de la interfaz de usuario. El flujo y cmo un
usuario podra querer interactuar con una interfaz desde el punto de vista mvil o web puede ser
diferente a la forma en que la aplicacin interacta con el uso del flujo de la pantalla verde. Por
ejemplo,
utilizando un enfoque de la pantalla verde es posible que tenga que seleccionar un men para ver
los datos adicionales
mientras que en la interfaz de usuario web de un sencillo men desplegable seleccione o podra
ser un enfoque mucho ms agradable.
Entender el flujo de la interfaz de usuario y la interaccin sera necesario que usted contine por la
camino a la modernizacin.
Tambin hay que tener en cuenta que la renovacin es ms probable que sea una solucin
temporal o tctico.
Recuerde que debe aclarar esto con la gestin, ya que desde su punto de vista, se puede pensar
que la aplicacin se moderniza y que adems no requiere.





2.2.4 Refactoring
Refactoring es una variacin de la reingeniera que reestructura una base de cdigo, mejorando su
estructura interna sin efectos adversos a su funcionalidad externa. Refactoring toma un "hacer
dao "enfoque, es decir, entre otras cosas, que las aplicaciones que interactan con el sistema
modernizado no tendr que ser cambiado en absoluto.

La filosofa de "no hacer dao" se garantiza mediante el uso extensivo de las pruebas a lo largo del
proceso de modernizacin completa. Las pruebas deben ser diseadas para automatizar tanto
como posible. Tambin debe asegurarse de que las pruebas cubren todos los aspectos de la
aplicacin.
Sin un conjunto completo de pruebas, los riesgos del aumento de la refactorizacin, porque no se
puede asegurar que el nuevo sistema tendr el comportamiento externo exacto que el sistema
original y que usted no se introducir errores en el sistema.
Al utilizar el mtodo de refactorizacin
La refactorizacin es el enfoque preferido cuando sus metas de modernizacin incluyen:
Reducir los costes de mantenimiento
El aumento de la claridad del cdigo
Revitalizacin de la aplicacin y lo que le permite adaptarse mejor a las necesidades del
negocio
Reducir el riesgo de afectar a los dems mediante la modernizacin de una aplicacin
Mantener la aplicacin en la misma plataforma y el lenguaje como el original
Aprovechando las habilidades existentes de su fuerza actual de programacin
Permitir flexibilidad interfaz de usuario, es ms fcil para actualizar la lgica empresarial de la
aplicacin para ser visitada por cualquiera de diferentes o mltiples tecnologas de interfaz de
usuario
Algunos refactorizacin es a menudo necesario independientemente del enfoque de
modernizacin elegido. este libro describe un modelo de modernizacin que gua el proyecto de
modernizacin. Algunos de los actividades descritas en este modelo estn ms relacionados con el
enfoque de refactorizacin. usted debe evaluar si necesitar de su proyecto o no.
2.3 Cmo modernizar
En esta seccin se presentan los principios generales que deben tenerse en cuenta en cualquier
esfuerzo de modernizacin, independientemente del enfoque elegido. Tambin proporciona un
modelo para guiarle a travs de un
proyecto de modernizacin. Siguiendo un modelo y un conjunto de reglas predefinidas va a ayudar
a lograr un proceso de modernizacin maduro. Hemos de tener en cuenta que usted debe adaptar
este modelo para satisfacer sus necesidades.
2.3.1 Introduccin
La modernizacin es un proceso de descubrimiento y usted tendr que aprender mucho. Pero an
as, es importante seguir un modelo que puede guiar a su manera. Habr ms de una
proyecto de modernizacin por delante, as que preprate para grabar su viaje para que otros
puedan repetir su xito y evitar sus errores.
Esta seccin le ofrece un modelo que puede ayudar a entender lo que debe hacer para
modernizar una aplicacin. Hay algunos principios generales aplicables no slo a este modelo
sino a cualquier proceso personalizado que usted defina.

La modernizacin no est limitada a los lenguajes o plataformas especficas. Hay miles de
aplicaciones de software que necesita ser modernizado y usted no es el nico que tiene
necesaria para tomar bajo un proyecto de modernizacin. Estos principios y este modelo son
aplicables no importa cul sea su situacin.
El modelo que usted est a punto de leer no es "tallada en piedra". Usted debe tomar las partes
que son aplicables a su enfoque de modernizacin y su situacin especfica y adaptarlos.
Hay un montn de espacio para la mejora y la creatividad. Adoptar el modelo y mejorarlo
cualquier forma en que usted necesita. Asegrese de que otros puedan repetir y mejorarlo a s
mismos por lo que el resultado final ser con un proceso maduro que puede reducir los riesgos y la
incertidumbre en el camino.
2.3.2 Modelo de Modernizacin
En esta seccin se presenta el modelo de modernizacin que se propone en este libro. Usted ser
presentacin a los principios que guan el modelo de modernizacin y un conjunto prescriptivo de
fases que se pueden seguir para lograr sus objetivos de modernizacin.
Un modelo o una metodologa?
Antes de aprender sobre el modelo de modernizacin, es necesario tener una clara
comprensin de lo que es un modelo y lo que es una metodologa. A veces estos trminos son
errneamente como sinnimos. Un modelo define un enfoque y un plan para hacer las cosas. El
modelo define lo que hay que hacer, no cmo hacerlo. Por otro lado, una metodologa
define todas las actividades que hay que hacer para lograr cada paso de la modelo. Una
metodologa se puede considerar como la implementacin de un modelo.
Este libro define un modelo de modernizacin en lugar de una metodologa. La modernizacin
puede ser abordado de diferentes maneras y que podra ser difcil mantenerse al da con el ritmo
de cada nuevo tcnica, sino un modelo puede llevar mucho tiempo a la intemperie. Es su
responsabilidad de adaptar este modelo a su situaciones especficas, teniendo en cuenta los
principios, directrices y fases que cada esfuerzo de modernizacin debera tener.

El modelo
La modernizacin de aplicaciones es mucho ms que seguir los pasos y la ejecucin de algunas
actividades. lo implica un conjunto de principios que usted tiene que recordar el camino. La
modernizacin modelo que se propone define este conjunto de principios y tambin un conjunto
de fases para lograr su objetivos de modernizacin.
Grficamente, el modelo de modernizacin se representa en la figura 2-1. Como puede ver, el
modelo define un ciclo de modernizacin iterativo que se repite tantas veces como sea necesario.
cada iteracin contribuye al objetivo principal: crear una aplicacin moderna.








Despus de cada iteracin se debe detener y volver a evaluar la situacin. Usted puede cambiar su
enfoque de la modernizacin o de cualquier tecnologa especfica que haya seleccionado. El punto
clave es que usted puede ver resultados pronto y usted puede parar tan pronto como sus metas
de modernizacin sean alcanzadas.
En la siguiente seccin se ver la definicin de las fases que componen el modelo:
Fase 0. Prepare
Ofertas de esta fase con la planificacin que se necesita para la iteracin. Usted tiene que
seleccionar la parte de la aplicacin que se va a modernizar y definir cmo se va a medir su
progreso. En cada iteracin debe haber actividades de planificacin para que pueda efectivamente
adaptarse a la situacin inmediata.
Fase 1. Experimentacin
Usted tendr que probar cosas nuevas en cada iteracin. Usted tendr que entender las
tecnologas disponibles en el mercado y determinar si se ajustan a su situacin. Esta fase es
acerca de jugar.
Fase 2. Fuera de funcionamiento
Esta fase se trata de hacer el verdadero trabajo y la aplicacin de lo que experimente con el fin de
alcanzar los objetivos de la iteracin.
Fase 3. Evaluar y ampliar el pensamiento futuro
Esta fase consiste en el anlisis de la labor realizada hasta ahora, incluida la consideracin de todas
las anteriores iteraciones. En esta fase, se puede ver la forma de introducir las nuevas tecnologas
para permitir una mayor flexibilidad en la aplicacin modernizada. Esta fase est dedicada a
analizar cmo ampliar la funcionalidad actual de la aplicacin.
Fase 4. Implementacin
Usted necesita para ofrecer el software tan pronto como sea posible. Cada ciclo termina con el
trabajo de software. Usted debe seleccionar cuidadosamente la estrategia de despliegue para
reducir los riesgos





2.3.3 Principios generales
Esta seccin proporciona algunos principios vitales que usted debe seguir durante la
modernizacin proyecto. La aplicacin de estos principios puede ayudar a usted, especialmente
cuando se tiene que enfrentar a situaciones inesperadas especficas y tomar decisiones
importantes.
Proceso iterativo e incremental
El proceso de modernizacin se puede considerar como un proceso iterativo e incremental. es
iterativo ya que todo el proyecto se puede dividir en proyectos ms pequeos que son ms fciles
gestionar y ms rpido para terminar. Es incremental pues con cada iteracin final, se hace
la aplicacin ms moderna, uno de los componentes a la vez. Esto tambin se llama un enfoque
gil.
A veces las personas que participan en un proyecto de modernizacin tratan de seguir un enfoque
"big-bang" y llegar a ser abrumado o frustrado. As que recuerde a cada proyecto de
modernizacin de dividir y conquistar.
Mantenga la investigacin y la lectura. Las cosas cambian. Lo que est la tecnologa de punta de
hoy puede ser obsoleto en cuestin de unos pocos meses. Para mantenerse moderna, hacer un
hbito de leer y la investigacin sobre la modernizacin teora y tecnologas. Lea sobre las ltimas
tendencias y probarlos. Ir a los seminarios y conferencias. Hable con sus colegas y buscar
experiencias exitosas (o fracasos) aplicar enfoques o tecnologas de modernizacin.
Recuerde siempre que la modernizacin no es algo que slo se trata de. lo afecta a una gran
cantidad de empresas, plataformas y lenguajes de programacin. Encontrar tiempo para
experimentar con tecnologas. Crear pruebas de concepto a aprender y probar la tecnologa en su
medio ambiente.
Automatizar lo que pueda
De vez en cuando en un proyecto de modernizacin, que se encuentra haciendo la misma tarea
una y otra vez. Piense en cmo se puede automatizar estos pasos. Siempre hay una mejor
maneras de hacer las cosas. Busque herramientas de modernizacin con fines comerciales o
crearlos usted mismo.
Prueba, prueba, prueba
Las pruebas son la nica manera de asegurarse de que usted no est rompiendo cualquier cosa
que no estuviera ya roto. Hay un montn de diferentes enfoques de prueba que puede utilizar en
su proyecto.
Algunos de los ms comunes son:
pruebas de regresin
Este tipo de prueba se centra en la comparacin de los resultados de una aplicacin en contra de
una lnea de base pre-establecida, en este caso, la solicitud original. Un aspecto clave de estos
tipos de pruebas es que no es necesario para entender el sistema antes de probarlo. Esta lata
ayuda, especialmente cuando usted est comenzando su proyecto de modernizacin y su
comprensin del cdigo no est completo.
pruebas unitarias automticas
Con las pruebas unitarias se puede probar una pequea parte de la aplicacin. A diferencia de las
pruebas de regresin, la unidad de pruebas requieren una mayor comprensin del cdigo que se
est probando. As que empezar a crear unidad automtica pone a prueba lo antes posible. Las
pruebas unitarias deben ser diseados en un auto configurado .
As, lo que significa que usted no debera tener que configurar nada antes de ejecutarlos. adems,
las unidades deben ser capaces de ejecutar muy rpidamente. Puede que tenga que ejecutar
despus de cada compilacin.

Todos estos enfoques pueden complementarse entre s, por lo que hay que encontrar una manera
de utilizarlos en su proyecto de modernizacin y automatizacin de ellos. Recuerde, usted debera
ser capaz de ejecutar las pruebas muy rpido y muy a menudo. Es la nica manera de sentirse ms
seguro al cambiar su cdigo.
Analizar mas
La modernizacin es acerca de la experimentacin. A veces el miedo puede descarrilar sus
esfuerzos, as que no se miedo y no analizar demasiado las cosas. Empezar a trabajar tan pronto
como sea posible.
El antiguo cdigo que se est modernizando causar sorpresas de vez en cuando, no importa
cunto usted lo analiza. Recuerda el carcter iterativo e incremental del proceso y
planificar y analizar de la misma manera.
Sea gil
Los proyectos de modernizacin tienen que ser giles, a fin de centrarse en evitar las actividades y
documentacin que no agregan valor al proceso. Tenga en cuenta los siguientes principios giles:
Entregar software que trabaja con frecuencia
Planee sus iteraciones de una manera que usted puede entregar software de trabajo rpido y con
frecuencia.
Recuerde que sus ejecutivos deben creer en el valor detrs de un proyecto de modernizacin, as
que haga su mejor esfuerzo para entregar valor a los mismos en las primeras etapas del proceso.
Un verdadero proyecto gil se divide en dos semanas iteraciones. Usted es continuo y regular
lograr avances. Sin embargo, no se obsesione con romper cosas en el ms pequeo unidades
posibles. El propsito es ser flexible y entregar pequeas actualizaciones incrementales.
Foco en el software a travs de la documentacin
Evite cualquier documentacin que no agrega valor al proceso de modernizacin. buscar
documentacin dinmico que puede mantenerse y volver a utilizar para diferentes propsitos
fcilmente.
Hay muchos sistemas de gestin de contenidos que pueden ayudarle a crear en colaboracin y
documentacin dinmico. Utilizando una herramienta como un Wiki puede ser til, ya que
permite la comunidad de usuarios para contribuir al esfuerzo de documentacin.
simplicidad es esencial
Recuerde que debe mantener las cosas lo ms simple posible. Resista la tentacin de
aadir caractersticas que podran ser utilizados en el futuro, pero que no son necesarios en estos
momentos. innecesario complejidad es una fuente de errores que pueden daar el proceso.
Dar una atencin continua a la excelencia tcnica
No hay que olvidar que la modernizacin se trata de mejorar. Centrarse en la aplicacin de
mejores prcticas y tecnologas. Convirtase en un defensor de la excelencia. Promover las
mejores prcticas y transmitir su conocimiento. Usted debe ayudar a los dems a comprender la
importancia de hacer cosas correctas.
La gente de negocios y los desarrolladores deben trabajar juntos
Construir buenas lneas de comunicacin entre los desarrolladores y expertos en negocios. la
aplicacin que se est modernizando es lo que soporta el negocio. No subestime
las aportaciones que el personal no puede hacer con el proyecto.
Utilice siempre herramientas modernas
Deje de usar herramientas obsoletas. Las herramientas modernas ayudan a hacer las cosas ms
rpido y mejor que antes. moderno herramientas son recursos valiosos que pueden ayudar a
realizar tareas increbles. No deje que su actual herramientas que se detienen en el camino de
modernizacin.
Naturalmente, es ms productiva con herramientas con las que estn familiarizados. No se debe
confundir esta ventaja de su familiaridad con la superioridad de las herramientas. Cambio de
herramientas requerir un perodo de ajuste antes de que sus ganancias de productividad se
realizan. Con el tiempo (y, a menudo no es mucho tiempo), utillaje moderno le permitir ser an
ms productivo que antes. Tambin debe recordar que es vital para atraer nuevos talentos a la
organizacin, y los nuevos desarrolladores se sientan cmodos con las herramientas que se
asemejan a las herramientas que se han utilizado. "Pantalla verde" herramientas de desarrollo
pueden dar la impresin de que est utilizando tecnologa obsoleta, por lo que evitar
el uso de ellos. Muchos desarrolladores han visto mejoras significativas en la productividad, por lo
general de 20 a 50 por ciento, dependiendo de cada desarrollador, al cambiar de una pantalla
verde basada entorno de desarrollo a un entorno de desarrollo integrado moderno (IDE).
2.3.4 Fase 0: Preparar
Las solicitudes son como los seres vivos. A medida que crecen, los procesos, las personas y otros
sistemas empiezan para construir a su alrededor. Hay ms de cdigo en un proyecto de
modernizacin y usted debe prepararse en consecuencia.
El objetivo principal de esta fase es prepararse para el esfuerzo de modernizacin por delante.
Usted tendr una visin clara y panormica de lo que significa la aplicacin de los diferentes
factores que participan en el proyecto.
Construir el modelo de negocio
Antes del inicio del proyecto, ya debe tener el inventario de aplicaciones priorizada. Ahora debe
crear el modelo de negocio. Un caso de negocio puede determinar si un
proyecto es rentable. El objetivo es convertir sus necesidades en algo que su gerente pueden
comprender en sus trminos y tomar una decisin basada en los negocios.
Un caso de negocios por lo general contiene las siguientes partes:
Planteamiento del problema
Asegrese de que esta parte se describen las insuficiencias, ineficiencias y debilidades de la
aplicacin actual. Armar nmeros y cifras que explican la situacin a la toma de decisiones y
ayudarles a ver la importancia del proyecto de modernizacin.
Solucin
Esta es la descripcin de alto nivel de la solucin para el problema expuesto antes. debieras
incluir:
Las tecnologas actuales del estado de la tcnica
Una visin general de la solucin propuesta
Una propuesta de costos y cronograma preliminar
Tambin puede incluir una breve descripcin del modelo de modernizacin que va a guiar
el proyecto.
Riesgos
Usted debe hacer una evaluacin honesta de los riesgos que podra tener que hacer frente. Esto le
ayudar a prepararse antes de que situaciones inesperadas suceden. Adems, un buen anlisis de
riesgo le ayudar a ganar credibilidad mediante la enumeracin de las cosas que pueden afectar el
alcance del proyecto.
Beneficios
Asegrese de especificar los beneficios del proyecto de modernizacin de una manera
cuantificable, se recomienda incluir varios escenarios:
- Escenario pesimista. En este escenario, debe especificar cul ser el mnimo
beneficios del proyecto de modernizacin. Asegrese de indicar cules son ms probables riesgos
a suceder y cmo usted est planeando para superar estas situaciones.
- Escenario optimista. En este escenario, puede especificar cul ser la mxima beneficios del
proyecto de modernizacin. Asegrese de establecer beneficios cuantificables realistas.
Evite exagerar. Esto puede afectar a su credibilidad si algo sale mal.
Mtricas
Se debe definir cmo se va a medir su progreso. Cada iteracin debe ser
evaluado en contra de estas medidas. Esto no es slo algo que es importante para su
gerente. Tambin le ayudar a hacer ajustes a su plan.
Stakeholders
Identificar todas las partes interesadas del proyecto. Asegrese de incluir a todas las personas
pertinentes, desde los desarrolladores a los usuarios de negocios. Tener aportaciones de todos los
grupos de inters afectados asegurar que recuerde la importancia de la aplicacin para su
negocio.
Ejemplos
Aqu es donde la prueba de concepto entra en juego. Si usted puede demostrar una pequeo y
exitoso ejemplo de lo que usted est tratando de lograr, esto ayudar a impulsar el modelo de
negocio.
El modelo de negocio es esencial para el proyecto de modernizacin. Sin ella, es dudoso que
obtendr la financiacin que se requiere y mantenerlo durante toda la vida del proyecto. Es vital
que el modelo de negocio se ha completado. De lo contrario, su esfuerzo de modernizacin puede
verse obstaculizada incluso antes de cambiar una sola lnea de cdigo.
Construir el equipo
Los proyectos de modernizacin siempre involucran a varias personas. Es de vital importancia que
se defina quin va a ser parte de su equipo en una etapa temprana. Adems de los desarrolladores
que harn el trabajo real, el equipo de modernizacin tambin se compone de personal no TI (por
ejemplo, los usuarios). no subestimar sus contribuciones o compromiso con el proyecto.
Asegrese de que usted define las siguientes funciones como mnimo:
equipo dirigido Modernizacin
Esta persona ser la encargada de dirigir el equipo. Asegrese de que la persona que va
que se asignar a este rol es un defensor de la modernizacin. Debe ser un pragmtico y
persona de mente abierta que no tiene miedo del cambio y un apasionado de la continua
mejora.
ingeniero de Modernizacin
Los ingenieros de modernizacin son los encargados de aplicar el enfoque de la modernizacin de
la aplicacin. Asegrese de elegir a las personas adecuadas para este papel y mantenerlos
enfocados en los objetivos principales. Durante el proceso de modernizacin, es natural querer
arreglar todo de inmediato. Los ingenieros deben tener en cuenta que la modernizacin es un
proceso iterativo
experto lgica de negocios
El experto de lgica de negocios por lo general es una persona no-IT. Pueden ser usuarios finales o
alguien cuyos procesos de negocio se apoya en la aplicacin. Esta funcin es esencial para la
proyecto. Ellos le pueden dar una gua para entender las razones detrs de la especfica
funcionalidades de la aplicacin.
aplicacin personal de mantenimiento
Esta es la persona que tiene experiencia de mantenimiento de la aplicacin y la modificacin se
de acuerdo a los nuevos requerimientos. Este rol puede explicar la mayor parte del diseo y
codificacin decisiones que a veces son difciles de entender.

Recuerde que debe hacer su mejor esfuerzo para mantener la cohesin del equipo y fomentar el
trabajo en equipo.
A veces el personal de mantenimiento de aplicaciones pueden sentirse amenazados por el
proyecto de modernizacin. Asegrese de convencerlos de la importancia y valor del proyecto.
Desarrollar en plan de
No trate de anticipar cada pequeo detalle. Recuerde que las cosas cambien ms probable y
definir un plan de trabajo de alto nivel del proyecto. A continuacin, hacer un plan detallado para
una o dos iteraciones. Utilice la hoja de ruta como a ejecutar su plan para mantener el proyecto en
marcha.
Este plan debe definir sus objetivos inmediatos para la iteracin y las tareas necesarias para
llevarlos a cabo. Asegrese de que su plan incluye un entregable al final de la iteracin.
Elaborar normas y procesos
Al principio se le experimentando mucho con el proceso de modernizacin, pero recuerde
documentar lo que hace y no funciona para usted. En el camino se tendr que definir
normas para garantizar que el equipo de la modernizacin hace las cosas de una manera
predecible. Tan pronto como sea posible, definir un conjunto de reglas y normas que apuntan a la
calidad. Est preparado para modificar sus estndares que usted y su equipo encuentre la mejora
de las tcnicas.
Siempre evitar reinventar la rueda
Si hay un buen nivel en la industria, analizarlo. Si se ajusta a sus necesidades, adoptarlo. Recordar
que usted no es el nico que intenta modernizar las aplicaciones. Hay muchas cosas que necesitas
tener ya se ha investigado y ejecutado por otra persona.

2.3.5 Fase 1: Experimentacin
Esta fase es un buen momento para probar nuevas tecnologas. Dado que esta es una fase de
experimentacin, que se va a hacer un montn de pruebas. La mayor parte de las cosas que usted
va a cdigo son no va a estar en el producto final.
Algunas de las actividades que usted debe considerar en esta fase son:
Haga una prueba de concepto
Usted necesita saber a ciencia cierta qu tecnologas son las mejores para su proyecto. La mejor
manera de determinar esto es mediante la creacin de una prueba de concepto (POC). Usted
podra encontrar obstculos y la necesidad de hacer algunos retrocesos, pero esto ayudar a que
usted y sus compaeros de equipo ganen experiencia.
Si usted est planeando para seleccionar una solucin comercial, lo ms probable es que usted va
a necesitar su la aprobacin del gerente. No confe nicamente en las cifras de comercializacin y
grficos. Mustrales reales software de trabajo. Tome ventaja de los ensayos libres.
Recuerde documentar lo que se aprende en esta fase. Asegrese de involucrar a su grupo de
inters en el POC. Ellos pueden proporcionar informacin valiosa para ayudar a asegurarse de que
usted va en la direccin correcta.
Puedes buscar proyectos ms sencillos
Mientras que usted est aprendiendo y acostumbrando al proceso de modernizacin, evitar la
seleccin de la aplicacin ms compleja. No debe haber aplicaciones que son muy importantes
para el negocio y no aadir riesgos innecesarios al proceso.
Con todo el xito, usted ganar ms habilidades y la confianza que le permitir modernizar
aplicaciones ms crticas y complejas


Experimento
Est cambiando el cdigo, el cambio de la interfaz de usuario, y el cambio de la arquitectura.
Recuerde que este est haciendo una prueba y usted no va a implementarlo en el entorno de
produccin. Las ideas y experiencias que usted gana en esta actividad le ayudarn a trabajar mejor
en la nueva aplicacin y para entender el cdigo subyacente.
Revalorar
Este proceso de experimentacin todo va a ampliar su pensamiento. Muchas de las ideas que
haba van a cambiar. No tenga miedo de volver a evaluar su enfoque de modernizacin s creo que
hay una mejor manera de hacerlo.
Definir los criterios de medicin
En esta fase, usted ganar ms el conocimiento de la aplicacin. Definir los mecanismos que se va
a utilizar para medir su progreso. Recuerde que usted va a informar sobre un regularmente a su
gerente, y que necesitan para ver su progreso. Por lo tanto, definir sus mtricas de acuerdo con el
enfoque de aplicacin y modernizacin seleccionado.
2.3.6 Fase 2: Off and Running
Esta fase se centra en hacer el trabajo real. Ahora que se tiene una vista panormica de la
disposicin tecnologas y tcnicas, puesta en la modernizacin de la aplicacin.
Recuerda el carcter iterativo e incremental del proceso de modernizacin, por lo que empezar a
paso a paso de una manera que tenga sentido para su situacin. Divida la aplicacin en pequeas
unidades que se puede modernizar una a la vez, pero no perder la visin de conjunto de la
aplicacin.
Mientras se encuentra en esta fase, tenga en cuenta las siguientes cosas:
Construya su caja de arena
Muchos proyectos de modernizacin se ejecutan en paralelo con otros proyectos empresariales,
por lo que es importante que construya una caja de arena que es especfica para el proyecto,
donde se puede estar seguro de que usted no afecta a la obra de otra persona y que a nadie ms
est afectando su trabajo.
En el diseo y construccin de su recinto de seguridad, recuerde tener en cuenta los siguientes
elementos:
- Objetos
-Data
-Pruebas
Objetos
Copie todos los objetos de la aplicacin a su caja de arena. Esto debe incluir por lo menos: las
reas de datos, programas, programas de servicio, los de los usuarios, colas de datos y cualquier
otro objeto que su aplicacin va a necesitar para funcionar en un entorno aislado. Para ayudarle a
construir la caja de arena, crear los diagramas de estructura de la aplicacin, que pueden ser
generados con herramientas automatizadas.
Datos
Adems de los objetos ejecutables, asegrese de tener todas las tablas que interactan con su
aplicacin. Se recomienda contar con los datos aislados para permitir que se hagan cambios sin
que afecte a otros proyectos.
Usted debe desarrollar un mtodo de restauracin de los datos de recinto de seguridad a su
estado inicial en forma automatizada. Esto le ayudar a ejecutar los escenarios de pruebas
repetidas y para automatizar las pruebas


Siempre revista sus datos sandbox. Los diarios son indispensables cuando la depuracin de la
cambios.
Pruebas
Usted necesitar un conjunto completo de pruebas para asegurarse de que su trabajo de
modernizacin va en la direccin prevista. Su caja de arena debe contener un conjunto de pruebas
que se pueden ejecutar varias veces y fcilmente. Sin pruebas, cualquier cambio puede ser fatal.
En las primeras iteraciones, debe tener por lo menos un conjunto de pruebas de regresin. A
medida que avanza el proyecto, su comprensin de la aplicacin se incrementar, lo que le
permite escribir pruebas unitarias especficas.
Asegrese de que el equipo de prueba cubre todas las partes de la aplicacin que va a cambiar con
el fin de garantizar el enfoque de "no hacer dao".
Comprender la aplicacin
En cada proyecto de modernizacin, que debe tomar el tiempo para entender la aplicacin que
estn tratando. El nivel de cdigo de comprensin que se necesitan depende directamente de la
enfoque de la modernizacin que se seleccione. Puede considerar las siguientes tcnicas para la
comprensin del cdigo y aplicarlos a su situacin en consecuencia:
Recopilar la documentacin existente
Es probable que no haya documentacin de la solicitud original. Pero hacer lo mejor para recopilar
todas las piezas de la documentacin disponible. Algunos tiles podero documentacin incluir:
Implementacin y configuracin de notas
Historia de Incidentes
Los casos de prueba
Sesiones de lectura de cdigos
La tcnica ms bsica para entender el cdigo es la lectura del cdigo. Usted tendr que leer el
cdigo que se est trabajando con su equipo y buscar el cdigo repetido y lgica. Inicialmente, la
lectura del cdigo no parece ser til, pero despus de que usted se familiarice con l,
Las cosas se vuelven ms claras.
Pregunte a los expertos acerca de la funcionalidad del negocio que se implementa en el cdigo y
mantenga esto en mente al leer el cdigo. A veces ser ms fcil de entender los procesos de
negocio subyacente que el cdigo que implementa.
Sesiones de depuracin
Depuracin de la aplicacin con pruebas especficas puede ayudar a entender la aplicacin y cmo
funciona cada mdulo. Recuerde que el uso de herramientas modernas, como IBM Rational
Developer para i, har las sesiones de depuracin ms productiva.
Anlisis esttico
Este es el anlisis del cdigo fuente o el objeto compilado sin ejecutarla. En general el resultado
del anlisis esttico es:
- Utilizar herramientas de anlisis de cdigo
Hay varios proveedores de herramientas que se han especializado de herramientas para revisar y
ayudar a analizar sus programas monolticos. El Rational Power Pack ARCAD proporciona la
Herramienta Observador que le ayudar a analizar el cdigo.
- Extraccin de reglas de negocio
Las reglas de negocio se refieren a la lgica de negocio que est incrustado en el cdigo. Muchas
de las herramientas ayudarle a extraer este tipo de datos a partir del cdigo, lo que puede ayudar
a entender la funcionalidad que se implementa en el programa.

- El anlisis de dependencia entre los componentes
Esto se refiere a la identificacin de las relaciones entre los mdulos de la aplicacin. El diagrama
que se genera puede ayudarle a entender cmo un componente se integra con toda la aplicacin.
- Esquema de la estructura interna
La mayora de las aplicaciones heredadas son monolticas, programas grandes. Con el fin de
comprender fcilmente el flujo en el interior de estos programas, algunos instrumentos pueden
generar diagramas de llamadas entre subrutinas internas y sub procedimientos. Considere
herramientas como el ARCAD Observador herramienta.
- Complejidad y el mantenimiento mtricas
Mtricas de complejidad y el mantenimiento pueden ayudar a diagnosticar la seccin de cdigo en
el que est trabajando y medir su progreso. Tambin pueden ayudar a estimar el cantidad de
trabajo necesaria para la modernizacin.
Estos tipos de anlisis se realizan ms fcilmente a travs del uso de herramientas automatizadas.
Ms adelante en este libro, usted encontrar ms informacin.

Anlisis dinmico
Este tipo de anlisis se realiza mediante el trazado de la ejecucin de los programas en un medio
ambiente especfico. Hay muchos usos de los resultados del anlisis dinmico incluyendo:
- La cobertura de cdigo
Las aplicaciones tradicionales suelen contener "cdigo muerto". Este es el cdigo que no se
ejecuta pero todava est en el programa. Para identificar el cdigo que ya no es necesario, puede
utilizar una herramienta de eso ayuda a calcular cmo se cubra gran parte del cdigo con un
conjunto de transacciones y cmo mucho cdigo es posiblemente muerto.
- Diagramas de llamadas dinmicas
La mejor manera de entender cmo funciona el programa es el seguimiento de su
comportamiento mientras corre. Herramientas de anlisis dinmicos suelen proporcionar datos
que representa el flujo de ejecucin de un programa, subprogramas y sub procedimientos.
Para ser eficaz, el anlisis dinmico requiere de un buen conjunto de pruebas para producir un
interesante resultado.
Modernizar
Cuando est preparada su caja de arena y tiene una mejor comprensin de la aplicacin, puede
empezar a hacer trabajos de modernizacin. Algunas de las tareas comunes que se pueden hacer
en esta etapa
Incluye:
Limpieza del cdigo
Limpieza de cdigo es la eliminacin de los elementos que hacen que el cdigo sea difcil de
entender. Algunos de las cosas que se deben considerar al limpiar su cdigo incluyen:
- La eliminacin de cdigo duplicado
- La conversin a una forma ms legible. En el contexto de la RPG, esto significa la conversin a
formato libre
- La eliminacin de las variables y los procedimientos utilizados
Reestructuracin del cdigo
Despus de limpiar el cdigo, se puede comenzar a extraer la lgica de negocio relacionada con el
servicio de programas que pueden ser reutilizados en diferentes partes de la aplicacin. Hay varias
buenas herramientas disponibles aqu para ayudar a identificar y reestructurar el cdigo. Algunas
de las tareas que puede hacer en esta etapa incluyen:

- Extraccin de una lgica similar en componentes reutilizables
- La encapsulacin de variables globales
- Conversin de subrutinas para procedimientos
- Cambiar el nombre de las variables y los procedimientos sub a los nombres ms significativos
- Escritura de cdigo auto-documentado
Reempaque
Cada mdulo slo debe contener los procedimientos sub funcionalmente relacionados y todos los
servicios del programa debe contener mdulos slo relacionados funcionalmente. Va a tener que
empezar a separar mdulos monolticos y organizar los procedimientos en los nuevos mdulos.
Asimismo, recuerda que cada mdulo debe tener una responsabilidad.
Modernizar la base de datos
Modernizacin de base de datos es un modelo de modernizacin completa por s misma. Ms
adelante en este libro, usted encontrar una metodologa que le guiar sobre cmo hacer esta
modernizacin.


Prueba
Despus de la modernizacin de la aplicacin, asegrese de que todas las pruebas se realizan sin
xito. Si las pruebas no tienen xito, no debe continuar en el proceso de modernizacin. Debe
asegurarse de que todo est funcionando como antes y que usted no est rompiendo las
funcionalidades existentes.
2.3.7 Fase 3: Evaluacin y ampliar el pensamiento futuro
El objetivo principal de esta fase es el de maximizar algunos de los beneficios de la situacin actual
de las ltimas tecnologas aplicadas a la aplicacin.
Usted ha preparado su medio ambiente y que ha modernizado la aplicacin. Ahora es el momento
para evaluar el progreso de su trabajo. Si esta evaluacin indica que debe dar un paso atrs en el
proceso, no se preocupe. Puede que tenga que hacer esto varias veces.
Si la evaluacin indica que usted ha logrado sus objetivos, es el momento de empezar a ampliar el
valor de la aplicacin y prepararla para el futuro.
Algunas de las actividades que se pueden hacer en esta fase son:
Medida
Es necesario evaluar si se estn logrando los objetivos de modernizacin. Si su objetivo principal es
reducir la complejidad, este paso debe reflejar una reduccin de la complejidad. Si usted necesita
para mejorar la experiencia del usuario, se debe medir de alguna manera. El punto clave es que se
mantenga el control de los objetivos y de los progresos para lograr estos objetivos.
Su medicin debe indicar los ajustes que se deben hacer al proyecto.
Mejorar la arquitectura
Ahora usted puede tener en cuenta la optimizacin de la arquitectura de la aplicacin. Es posible
que desee comenzar separar la aplicacin en capas o niveles y para incluir componentes
adicionales tales como una nueva capa de sustitucin de IU. Este paso se centra en la aplicacin
como un todo.
Integrar
Uno de los objetivos de modernizacin comunes es la de integrar la aplicacin en una empresa
arquitectura. A menudo, es necesario para permitir la aplicacin de SOA o para que sea ms
flexible para otras tecnologas de integracin empresarial.

Traer nuevas tecnologas
Si hay alguna nueva tecnologa que puede ayudar a mejorar la aplicacin, puede incluirla en este
paso. Recuerde que debe analizar con cuidado para evitar que se convierta en un obstculo
futuro.
Siempre apunte para herramientas estndar, tecnologas y soluciones bien probadas. Evaluar el
usuario comunidad en torno a ellos y el apoyo del personal de oficiales de mantenimiento de
aplicaciones.
Tenga en cuenta que estas nuevas tecnologas pueden llegar a ser obsoletos muy rpido, por lo
que los envuelven en una manera que le ayuda a reemplazar fcilmente si es necesario.
2.3.8 Fase 4: Implementacin
Ahora es el momento de entregar los resultados de su trabajo. Sin embargo, los componentes que
entrega no deben ser considerados como un producto final. Con cada iteracin, se puede mejorar
piezas de software, incluso si ya los ha entregado. El punto clave aqu es que usted hace su mejor
para comenzar a desplegar tan pronto como sea posible para mostrar el valor de su esfuerzo de
modernizacin.
Los siguientes pasos le pueden guiar en esta fase:
Documentar la aplicacin
Es probable que la nueva aplicacin sea diferente que la anterior. Usted tendr que crear
documentacin efectiva que explica la nueva aplicacin a las personas que hacen el
mantenimiento y los usuarios y los grupos de inters de sus aplicaciones.
Tome ventaja de cualquier recurso disponible para documentar. Uso de clases, la secuencia y
diagramas de despliegue para ayudar a entender la aplicacin. La mayora de los tipos de
Modelado Unificado Language (UML) estn diseados para lenguajes orientados a objetos, pero se
puede adaptar fcilmente a su situacin. La ventaja de usar un tipo estndar de diagrama es que
muchos de la gente ser capaz de comprender con facilidad y que se parecen ms profesional.
Recuerde que su documentacin se debe aportar un valor aadido. As que evita la
documentacin que ir directamente a la plataforma. El uso de sistemas de gestin de contenidos
(por ejemplo, MediaWiki, WordPress, Joomla, etc) pueden ayudarle a crear documentacin
sencilla y colaborativa.
Tenga en cuenta que la documentacin debe ser de fcil mantenimiento. Hay muchas
herramientas que puede generar documentacin a partir del cdigo o de los objetos compilados.
Utilizarlos (o crear ellos) si es posible.
Capacitar a las personas
Dependiendo del enfoque de modernizacin, puede que tenga que formar a los usuarios, la
aplicacin el personal de mantenimiento, o en ambos.
La documentacin que gener previamente se debe utilizar como la referencia principal para los
aprendices. Asegrese de que esta documentacin se puede acceder fcilmente y que contiene
toda la la informacin necesaria para los usuarios como para los expertos en TI.
Si la nueva aplicacin es ms difcil de entender que el original, esto es una buena indicacin que
el plan de modernizacin de las necesidades se mejora. Evaluar el nuevo sistema desde diferentes
puntos de vista.
Definir la estrategia de implementacin
Al igual que hay muchos enfoques de modernizacin, hay ms de una manera de implementar la
nueva aplicacin. Asegrese de que ambos enfoques estn alineados. Algunos de las ms comunes
tcnicas de implementacin incluyen:

Enfoque Big-Bang
Este enfoque para el despliegue reemplaza toda la aplicacin de una sola vez. Esto por lo general
se utiliza con proyectos de modernizacin que necesitan resolver un problema inmediato que
afecta servicios crticos. Sin embargo, el riesgo asociado es mayor y debe ser manejado con
cuidado.
Cuando se sigue este tipo de enfoque, por lo general es necesario mantener la vieja aplicacin y la
nueva aplicacin en paralelo. La cuestin es que los cambios en el nuevo sistema debera
reflejarse en el viejo y viceversa. Esto puede causar una gran cantidad de trabajo y esfuerzo.
Enfoque incremental
Tambin conocido como "Salida por etapas", en este enfoque, las secciones de la aplicacin son
rediseado y aadi de forma incremental, lo que le permite ofrecer resultados e identificar
errores ms rpidamente.
Cuando se sigue este enfoque, slo se puede cambiar un componente a la vez sin tener en cuenta
la aplicacin en su conjunto. Ante este hecho, el proceso de modernizacin podra tomar ms
tiempo para terminar por completo
Enfoque evolutivo
Al igual que el enfoque incremental, el enfoque evolutivo reemplaza las secciones de la aplicacin
original con partes modernizadas. La diferencia es que, en este enfoque, para reemplazar
secciones se seleccionan basndose en su funcionalidad y no la estructura de la aplicacin. Esto
significa que los desarrolladores de poner adelante esfuerzo adicional para identificar funcional
partes separadas en la solicitud original.
Para ayudarle a entender las diferencias entre estos enfoques, considere la tabla 2-1, que contiene
una breve comparacin de los tres.








2.3.9 Repita segn sea necesario
Despus de terminar el proceso, tendr que volver atrs y repetir el proceso tantas veces segn
sea necesario. En cada iteracin, un nuevo componente se modernizar y usted estar ms cerca
de sus metas.
No todas las fases requieren la misma cantidad de esfuerzo en cada iteracin. Al principio, usted
probablemente tendr que invertir ms esfuerzo en las fases de preparacin y experimentacin.
Sin embargo, a medida que avanza el proyecto, estas fases sern ms cortos. En otras palabras,
usted ver cmo se adaptan las fases durante las iteraciones sucesivas.
Recuerde que debe evaluar su progreso en cada iteracin y ajustar la ruta en consecuencia.
Al ir a travs de todas las fases, tenga en cuenta que debe adherirse a los principios de
modernizacin y ajustar el proceso a su situacin.













Las tcnicas modernas de arquitectura de aplicaciones

Este captulo presenta las tcnicas de la arquitectura de aplicaciones que pueden ayudar a disear
y construir aplicaciones modernas.
3.1 Introduccin
Qu es una aplicacin moderna? Cmo se puede definir un diseo moderno? Dado el ritmo de
cambios en la tecnologa, el trmino moderno puede ser difcil de definir. Cada da las nuevas
tecnologas se construyeron, los patrones se han diseado y se refinan las prcticas
recomendadas o completamente cambiado. Dada la naturaleza dinmica de desarrollo de
software, es ms fcil de entender lo que es un mal diseo.
Un mal diseo exhibe muchas caractersticas que desea evitar en el software que se construir. En
este captulo, aprender algunas de las caractersticas de lo que contribuye a un mal diseo y
algunas tcnicas de diseo que se pueden utilizar para evitarlos.
3.1.1 Los sntomas de un mal diseo
En la primera versin de una aplicacin, los programadores tienen una visin clara de lo que el
software es y cmo se construye. Si tienen que hacer un cambio, es probable que sea fcil para
ellos dada su familiaridad con el cdigo. A medida que el tiempo pasa y varios programadores
empezar a hacer cambios, las nuevas adiciones y actualizaciones, la aplicacin empieza a
deteriorarse. Por qu pasa esto? Por qu software se degrada con el tiempo? Puede haber
muchas razones y algunas veces esto puede ser difcil de evitar, pero usted debe centrarse en la
creacin de un buen diseo que es ms difcil de romper con el tiempo.
Si su aplicacin presenta alguno de los siguientes sntomas, es probable que se enfrente el mal
diseo:
Rigidez
La aplicacin es difcil de cambiar porque un solo cambio puede desencadenar una cascada de
mltiples cambios. Con diseos rgidos, lo que parece ser un simple cambio puede convertir a un
proyecto complejo que es difcil de estimar.
Los ms mdulos afectados por un cambio, el ms rgido el diseo.
Fragilidad
Los cambios hacen que el sistema de romper en muchos lugares cuando se realiza un nico
cambio. Estos partes tienen ninguna relacin conceptual con el rea que se ha cambiado. La
fijacin de un problema puede causar nuevos problemas y as sucesivamente.
Inmovilidad
Un diseo es inmvil cuando contiene piezas que puedan ser reutilizables, pero el esfuerzo de
separarlos del sistema original son demasiado grandes. La aplicacin est demasiado enredada
para reutilizar partes de ella.
Viscosidad
Cuando usted est haciendo un cambio en una aplicacin, usted tiene dos opciones: la
preservacin del diseo o "hack" y romper el diseo. Viscosidad hace ms difcil seguir el diseo
preservar mtodo. Con el tiempo, los desarrolladores tienden a empezar a hacer "hacks" con ms
frecuencia para la aplicacin debido a la falta de comprensin y la presin del tiempo.
La complejidad innecesaria
El diseo de software es esencialmente un proceso creativo. Pero a veces, un diseo contiene
elementos que no son actualmente tiles. Anticipar requisitos puede parecer una buena cosa,
pero si no se planifica cuidadosamente, se convertir en la fuente de complejidades que no lo
hacen aadir beneficio.

Repeticin innecesaria
El diseo contiene estructuras repetidas que pudieran ser unificados bajo un solo reutilizable
componente. A veces, los programadores utilizan un enfoque de goma de la copia para la
codificacin, esto puede llevar redundantes cdigo que hace que sea difcil de hacer cambios y
errores cuando corrige.
Opacidad
El diseo y el cdigo es difcil de leer y entender. No expresa su propsito adecuadamente. En las
siguientes secciones, aprender tcnicas que pueden ayudar a crear diseos modernos que tratan
de evitar estos problemas. Cuando lea estas secciones, tenga en cuenta el mal diseo sntomas
descritos aqu y descubre cmo estas prcticas recomendadas pueden ayudarle a evitarlos.
3.2 La modularizacin
Alguna vez ha tenido que lidiar con un programa monoltico grande? Muchas aplicaciones
antiguas tradicionales son programas monolticos que se componen de un solo mdulo. En este
nico mdulo grande, a menudo se puede encontrar el cdigo para manejar la pantalla, las
interacciones del usuario, la lgica de negocio, y el acceso a la base de datos. No hay sentido de la
separacin.
El mantenimiento de los programas monolticos no es tarea fcil. Dado su tamao y complejidad,
programadores se enfrentan a muchos obstculos. A menudo se necesita la ayuda del autor
original del programa para entenderlo (suponiendo que el autor original es todava alrededor).
Como resultado, proyectos de mantenimiento y nuevas incorporaciones tienden a crecer con el
tiempo, el costo, la complejidad y el riesgo.
Qu hacer con estas aplicaciones? Hasta ahora, en este libro, usted ha estado aprendiendo sobre
la modernizacin de sus aplicaciones. Programas monolticos deben modernizarse pero en
paralelo a un proyecto global de modernizacin. Debe asegurarse de que las nuevas aplicaciones
no estn diseadas con este enfoque. La modularizacin es la clave para el diseo de fcil-a-
mantener aplicaciones.
La modularidad se puede definir como una cantidad de componentes dentro de una aplicacin
que est separada y recombinado. La modularizacin es una tcnica de software que se centra en
la separacin de la funcionalidad de un programa en mdulos reutilizables ms pequeas que
contiene slo una funcin que es a continuacin, se utiliza a lo largo de toda la aplicacin.
Con el fin de lograr un buen diseo modular, lo que tienes que empezar a pensar en la separacin
funcionalidades y la aplicacin de una sola funcin por mdulo. Si un mdulo de hace muchos
funciones no relacionadas, se deben reconsiderar su diseo.
3.2.1 Por qu la modularizacin es importante
La modularizacin trae muchos beneficios a la aplicacin y sus programadores. En esta seccin,
aprenders algunos de los principales beneficios que ofrece la modularizacin.
Ms fcil de cambio
Usted probablemente ya sabe que las aplicaciones cambian. El negocio es una entidad dinmica y
as son las aplicaciones que lo soportan. La modularizacin mejora la dificultad, el costo y el
tiempo para hacer cambios. Con las aplicaciones monolticas, incluso un simple cambio puede
convertirse en una ardua tarea que requiere ms esfuerzo y el riesgo de lo esperado.
Cmo la modularizacin hace cambios ms fciles de hacer? Imagine una aplicacin monoltica
enorme donde todas las funcionalidades estn en el mismo mdulo. La empresa necesita un
pequeo cambio en la lgica incrustado en el cdigo. Usted no est familiarizado con toda la
aplicacin y el tiempo esta en contra de usted. Este escenario no estamuy lejos de la realidad.
Cuando los programadores se enfrentan a esta situacin, no tienen el tiempo para entender todo
el cdigo mixto y hacer el cambio usando malas tcnicas como el "copy-paste". El riesgo aumenta
y el cdigo se convierte en un lo ms grande que antes.
Consideremos ahora el otro escenario. Usted tiene que hacer el mismo cambio pequeo, pero en
un bien diseado aplicacin modular. Si genera un esquema de la aplicacin, ver cmo se
estructura la aplicacin. Ahora usted puede entender cules son los mdulos que tiene que
cambiar. Usted no tiene que pasar por miles de lneas de cdigo que no estaban relacionados con
su cambio. La modularizacin hace que sea ms fcil de entender toda la aplicacin y se centran
slo en las partes que le interesan.
Consideremos ahora un ejemplo en el que usted necesita para hacer un cambio en el modo de
acceso a una base de datos.
Con una aplicacin monoltica, es posible que tenga que repetir el mismo cambio muchas veces. Y
si se olvida de uno de los lugares de acceso a datos? Usted acaba de inyectarse un error. Con un
enfoque modular, actualizar el mdulo que se ocupa del acceso a la base de datos y ya est.
Ms fcil de entender
Cuando usted est tratando de entender un programa monoltico, hay que ver todo a la vez.
El componente ms pequeo es toda la aplicacin. No es muy fcil centrarse en la lgica de la
interfaz de usuario o el acceso a la base de datos por separado. Dada la ausencia de capas y la
separacin, que se ven obligados
comprender todos los aspectos de la aplicacin incluso si usted est interesado slo en una parte
especfica.
En una aplicacin modular, usted puede comenzar a aprender las diferentes partes del cdigo y
haciendo caso omiso de la descansar. Por ejemplo, usted puede centrarse en la comprensin de
cmo una parte especfica de la lgica de negocio funciona, sin tener que entrar en la interfaz de
usuario o los datos de acceso.
Esta facilidad en la comprensin le beneficiar principalmente en las siguientes reas:
Nueva formacin del talento
Menos tiempo y costos para capacitar a gente nueva en la aplicacin. Es ms fcil de explicar
pequea piezas una a la vez que una aplicacin monoltica conjunto.
Los proyectos de modernizacin
Estos proyectos requieren de personal que entienda la solicitud original antes de que sea
modernizado. Comprensin de cdigo es una tarea ardua que se pueden aliviar con un sistema
modular diseo.
ubicacin Error y la fijacin de
Bsqueda de errores en aplicaciones monolticas puede ser difcil. Un diseo modular puede
ayudarle a aislar los errores ms fcil y ms rpido.
Ms fcil de probar
Desde una perspectiva de pruebas, es ms fcil para probar aplicaciones modulares. Similar a la
proceso de comprensin, puede centrarse en un mdulo en particular y escribir pruebas unitarias
para ello. unidad de pruebas son recursos valiosos para validar su cdigo. Ellos le permiten
escribir las pruebas para concretas secciones de cdigo que puede ser difcil de alcanzar. Las
pruebas unitarias deben ser complementados con la integracin y las pruebas de funcionamiento,
pero en aplicaciones monolticas, que no tienen esta opcin.
En trminos de diseo de prueba, aplicaciones monolticas tienden a tener una mayor
complejidad, lo que hace ms difciles de probar. Esta dificultad en las pruebas pueden conducir a
importantes sectores no estn siendo probadas correctamente y de riesgo adicional para los
errores en el futuro.
Reutilizacin
Las grandes piezas de software son ms difciles de reutilizar. La modularizacin tiene como
objetivo crear la aplicacin como una composicin de piezas pequeas. Con un buen diseo, es
ms fcil de reutilizar estas piezas en diferentes partes de la aplicacin.
3.2.2 Principios generales
Ustedes han aprendido lo que la modularizacin es y por qu es importante, pero ahora vas a
aprender los principios ms importantes que usted necesita para tener en cuenta a la hora de
definir cmo modularizar.
La divisin de la aplicacin en partes ms pequeas es esencial en el camino hacia la
modernizacin, pero a veces, la parte difcil es saber qu incluir en cada pieza. En esta seccin se
abordar este punto. Tenga en cuenta las siguientes pautas en el diseo de una aplicacin
modular:
Responsabilidad individual
Este principio establece que todos los mdulos de una aplicacin debe tener una responsabilidad.
La responsabilidad puede ser entendida como una razn para cambiar. Por ejemplo, considere un
mdulo que recupera los datos de una tabla y tambin genera un informe basado en los datos. Si
un cambio que es relacionado con la recuperacin de datos se debe hacer, todo el mdulo tiene
que cambiar. Pero si un cambio que se debe hacer con el informe, el mismo mdulo tiene que
cambiar. Ergo, el mdulo tiene dos razones no relacionadas con el cambio. La forma correcta es la
creacin de dos mdulos, uno centrado en la recuperacin de datos y otro centrado en la
generacin del informe.
Cuando un mdulo tiene ms de una responsabilidad, es ms fcil para causar daos colaterales:
usted se acaba de cambiar el informe, pero, sin usted saberlo, la funcionalidad de recuperacin de
datos tambin fue afectados.
Alta cohesin
La cohesin es el grado en el que los elementos de un mdulo van de la mano. Es el funcional la
relacin de los elementos dentro de un mdulo. Puede detectar baja cohesin cuando un mdulo
tiene ms de una responsabilidad. Tambin, bajo la cohesin se puede ver cuando comn las
competencias estn repartidas en diferentes mdulos, no relacionados.
Debe disear componentes con la cohesin. Esto har que sean ms robustos y ms fciles de
reutilizar. Todo lo que tienes que hacer es poner la funcionalidad relacionada en el mismo mdulo
y asegrese de que cambios futuros toman esto en consideracin.
Acoplamiento dbil
El acoplamiento puede ser definido como el grado en que cada mdulo se basa en otros mdulos.
Es una medida de la fuerza de la asociacin establecida por una conexin de un mdulo a otro.
Acoplamiento apretado hace que un programa sea ms difcil de entender, cambio, o correcta por
s mismo. El cambio en un mdulo genera una gran cantidad de cambios en los mdulos
relacionados. Es como domin piezas cayendo en secuencia.
El logro de un diseo sin acoplamiento es muy duro y no es prctico, pero usted debe tratar de
centrarse en el diseo con bajo acoplamiento en mente. Acoplamiento dbil se puede lograr
mediante la alta creacin de mdulos de cohesin que se comunican con otros a travs de una
interfaz bien definida, ocultando su implementacin interna. En otras palabras, los mdulos deben
ocultar sus variables globales, formato de datos y cualquier otro tipo de detalles de la
implementacin de otros mdulos. Los mdulos son llamados y funcionan dentro del mdulo
efecta slo cuando los datos pasan a la interfaz definida.
Empacar juntos solo mdulos relacionados
Al preparar sus mdulos (programas de servicio en el contexto ILE), recuerde slo para empacar
mdulos relacionados entre s. Esto puede ser pensado como el principio de alta cohesin, pero al
nivel de paquete. Por qu es importante disear paquetes con este enfoque? Si empaca mdulos
sin relacin juntos, se genera una gran cantidad de dependencias para el paquete de diferentes
aplicaciones. Un cambio de un mdulo requerir la modificacin de todo el paquete, lo que
aumenta los riesgos de daar otras aplicaciones.
Convencin de nomenclatura adecuada
Convenciones de nombres se deben definir de una manera que ayuda a los programadores a
entender el enfoque modular. Debe definir una convencin de nomenclatura auto-documentado
que ayuda identificar rpidamente la nica funcionalidad de un mdulo. Esto ayudar a los dems
a mantener el orden y el estilo de toda la aplicacin. Buenas convenciones de nombres tambin
hacen herramientas como UML diagramas ms til.
3.3 Diseo por niveles
Dos de los principales objetivos de la arquitectura moderna de aplicacin son para maximizar
reutilizacin cdigo y reducir al mnimo el impacto del cambio y los gastos generales de
mantenimiento.
A travs de los aos, ha habido un nmero de diferentes arquitecturas de servidor de cliente, de
tres niveles, de n niveles, de varios niveles, el modelo-vista-controlador (MVC), y rica de cliente
para el servicio orientado (SOA).
Independientemente de cul de estas arquitecturas se selecciona, todos comparten una
caracterstica comn.
Ellos tratan de separar la aplicacin en niveles distintos.
Por ejemplo, un diseo de tres niveles separa la presentacin, la lgica y las capas de datos.
Las interfaces de nivel de presentacin con el usuario. Esto podra ser una interfaz 5250 de
estilo, una red interfaz o una interfaz mvil.
El nivel de lgica coordina el movimiento y transformacin de datos entre la presentacin y
capas de datos. Procesos consisten en todas las decisiones y clculos que deben estar hechos. Aqu
es donde toda la lgica de negocio tiene que existir.
El nivel de datos es donde se almacenan los datos y se recupera de una base de datos. Las
asegura capa de datos la integridad de los datos sin ninguna dependencia en el nivel de lgica.
Cada nivel es una entidad en s misma y no tiene conocimiento de los contenidos y las
metodologas de los otros niveles. Hay interfaces publicadas que permiten la comunicacin entre
niveles. En teora, cualquier nivel puede ser cambiado o reemplazado sin afectar a ninguno de los
otros niveles de la aplicacin.
Suponiendo que la capa de presentacin actual es una interfaz tradicional 5250-estilo, el concepto
de un diseo escalonado significa que una nueva capa de presentacin (por ejemplo, una interfaz
web o un Interfaz mvil) podra introducirse sin tener que realizar ningn cambio en la lgica o los
datos capas.
Aunque en este ejemplo est en un nivel de aplicacin, el principio se puede llevar hacia abajo en
cada uno de los niveles que pueden estar a su vez por niveles. Este principio llevara hasta el nivel
de programacin, donde se utiliza la encapsulacin para implementar un diseo escalonado en el
cdigo.
La aplicacin de un diseo escalonado asegura que el cambio o la adicin de un nivel (en la
aplicacin o nivel de programa) no tienen efecto en los dems niveles. Por lo tanto, los principales
objetivos de maximizando la reutilizacin del cdigo y minimizando el impacto del cambio y los
gastos generales de mantenimiento se cumplan.

La arquitectura exacta para ser utilizado a veces puede ser influenciada por otros factores, tales
como la Herramientas ISV, lenguajes de programacin, y los marcos que se estn utilizando.
Cualquiera se est utilizando la arquitectura, todos ellos tienen como objetivo lograr los mismos
principios niveles.
Una serie de artculos en iProdeveloper demostr la implementacin de un diseo escalonado
utilizando un enfoque MVC.
En el artculo "Pattern Recognition: Facilidad Moderna RPG Programacin", Scott Klement
demostrado una metodologa MVC utilizado con un tradicional mantenimiento del cliente 5250 de
estilo programas. Estos programas separa todo el manejo de la base de datos en un mdulo en un
programa de servicio: el programa de servicio es un nivel de datos. Usted puede leer el artculo en
la siguiente link:
http://iprodeveloper.com/rpg-programming/pattern-recognition-ease-modern-rpg-programming

En el siguiente artculo, "Reconocimiento de Patrones: La adopcin de El Patrn", Paul Tuohy
demostr cmo se utiliz el mismo nivel de datos con una interfaz web escrito en CGIDEV2.
Usted puede leer el artculo en el siguiente enlace:
http://iprodeveloper.com/rpg-programming/pattern-recognition-adopting-pattern

Por ltimo, en el artculo "Reconocimiento de Patrones: La prestacin de mantenimiento", Paul
Tuohy mostr cmo el nivel de datos podra ser re-escrito sin afectar a cualquiera de las dos capas
de presentacin (5250 o web). Usted puede leer el artculo en el siguiente enlace:
http://iprodeveloper.com/application-development/pattern-recognition-maintenance-benefit

El enfoque por niveles, en todos los niveles dentro de una aplicacin, proporciona la mayor
flexibilidad en trminos del mantenimiento y el potencial para un cambio rpido.



3.4 Modelo de objetos de Negocios
En el desarrollo de la arquitectura de software, a menudo es til pensar en el problema como un
conjunto de objetos de negocio y sus interacciones. Un objeto de negocio se define a menudo
como un "actor" o "participante" en la lgica de negocio para su organizacin. Puede ser cualquier
tipo de entidad que puede ser visto en los procesos que impulsan el negocio. Objetos de negocio
comunes incluyen cosas como empleados, clientes, rdenes de trabajo, recibos, registros de
cuentas, etc.
Estos objetos de negocio pueden modelarse como un conjunto de reglas, flujos de trabajo y los
flujos de datos.
Considere la posibilidad de un escenario de ejemplo donde un cliente llama para informar de un
problema. El cliente representante de servicio puede crear una orden de trabajo para un
especialista para investigar ms a fondo. Una llamada registro puede ser creado y almacenado en
una base de datos local. El cliente es un objeto de negocio, as como el representante de servicio al
cliente, la orden de trabajo, y el registro de llamadas. Reglas podran tambin regir estas
transacciones. Por ejemplo, los atributos de los clientes pueden dictar la prioridad para trabajar.
Tambin tendrn que ser trada, creado y modificado (tambin parte del modelo) de datos.
Como se puede imaginar, un modelo de objetos de negocio se realiza generalmente en trminos
no-programadores puede entender. Es la perspectiva empresarial del problema o de la solucin.
Como tal, la creacin y revisin del modelo pueden afectar a cualquier grupo de personas tcnicas
o no tcnicas de su organizacin.
3.4.1 Implementacin
Una vez que se crea un modelo de negocio, se puede utilizar para ayudar a su arquitecto de
soluciones de software.
Como se puede imaginar, este tipo de modelo fomenta diseo orientado a objetos. Pero, cmo lo
hace traducir en su solucin de software? Vamos a discutir un enfoque muy estricto.
Cada tipo de objeto de negocio (BO) puede ser representada por una instancia de una clase. Esta
clase puede (y debe) encapsular todos los atributos de ese BO particular. Puesto que cada uno
tiene atributos que se pueden recuperar o cambiar segn sea necesario, estas clases suelen
implementarse como "beans de datos" con un simple conjunto de puntos de entrada para crear o
modificar los atributos. La lgica de negocio se escribe como las interacciones entre estos objetos
de negocio. Para interactuar con los datos (como una instancia DBMS) el modelo incluye objetos
de acceso a datos (dao), que proporciona la interfaz para el backend de datos. El DAO proporciona
una capa de abstraccin para que los objetos de negocio no sea necesario que entienda la
complejidad del backend. Ese avanzado conocimiento (por ejemplo, el formato especfico de
tablas relacionales de una base de datos) puede ser encapsulado en la DAO. Los datos que fluyen
entre las partes de un proceso pueden ser an ms encapsulados en un objeto de transferencia de
datos (DTO), que contiene los datos de inters (clientes electrnicos) y nada ms.
Ahora volvamos a nuestro ejemplo anterior. Cuando un cliente llama para reportar un problema,
el cliente representante de servicio puede necesitar buscar la direccin del cliente. El
representante (ser un "actor" en el proceso y, por tanto, un objeto de negocio) pedir a la DAO
para este informacin. El DAO entiende la complejidad del backend, obtiene los datos y devuelve
un DTO que contiene la direccin del cliente.
Por supuesto, la aplicacin de la vida real de cdigo basado en el modelo de objetos de negocios
rara vez es tan perfecta como la descripcin precedente afirma. Por ejemplo, puede que no sea
factible totalmente encapsular un objeto de negocio en una sola clase. Consideraciones sobre el
rendimiento o de terceros software puede imponer restricciones a su diseo.
Independientemente, el modelo todava se puede utilizar para ayudar a particionar el diseo en
objetos de negocio relevantes y mantener una lgica y significativa de separacin de trabajo.
3.4.2 Ventajas
Como puede ver, el uso de un modelo de objetos de negocio ayudar a la solucin que sigue
muchos de las prcticas preferidas que se describen en este captulo. Por ejemplo, el modelo
tiende a hacer cumplir una fuerte nocin de modularizacin, ya que cada BO, DTO, y DAO contiene
la informacin que necesita para completar sus propias tareas necesarias. Adems, cada objeto no
necesita contener detallado el conocimiento acerca de las tareas realizadas por otros objetos (solo
responsabilidad). En un buen diseo, partes del modelo pueden ser reemplazados o modificados
sin afectar el resto de la solucin (acoplamiento dbil). Esto da como resultado cdigo que es ms
fcil de mantener, reutilizable y flexible.
Adems, el modelado con objetos de negocio le permite identificar rpidamente las dependencias
al hacer un cambio. En nuestro ejemplo, si el DTO recupera la direccin de un cliente, otros
objetos podran ser afectados? Del mismo modo, puede ayudar a identificar el rendimiento
sensible de los mdulos dentro de la solucin.
Como se mencion anteriormente, el modelo de objetos de negocio en s no es hablar
programador. No es la clase, diagramas, prototipos de funciones, o XML. De hecho, a menudo se
hace con el palillo-hombres y crculos. Como tal, casi cualquier persona puede contribuir a la
modelo al identificar interacciones, asociaciones, y las reglas para el modelo.
Tal vez lo ms importante, este enfoque obliga al arquitecto de software para mantener una
perspectiva a nivel de negocio en el problema. Despus de todo, cuando el diseo de un
componente de software, es esencial comprender cmo encaja en el cuadro grande. Este
entendimiento es seguro que resultar en una solucin de software mejor.
3.5 Los datos de programacin centrada
Antes de introducir el concepto de la programacin centrada en los datos, es necesario
comprender el enfoque tradicional para el desarrollo de aplicaciones en el IBM i: la programacin
centrada en el programa.
Con este enfoque, el programa tiene las siguientes responsabilidades:
De acceso a datos
Determine los archivos necesarios y el mtodo de acceso de datos, por lo general el nivel de
acceso al registro (RLA) para recuperar datos de una fila a la vez. Adems, el programa en s mismo
determina la relacin entre los archivos, haciendo que el sistema de gestin de base de datos
(DBMS) de poco ayuda.
Lgica de negocios
El programa cuenta con todas las reglas de negocio embebidas en el cdigo (ya sea directamente o
a travs de un miembro de la copia). La lgica empresarial hace cumplir la integridad referencial
entre archivos.
Interfaz de usuario
Mostrar los resultados del procesamiento de los datos y reglas de negocio para el usuario.
Aplicaciones monolticas pueden considerarse como centrada en el programa, pero tambin se
puede pensar en aplicaciones modulares que se construyen como centrada en el programa. La
Figura 3-1 muestra un ejemplo de la estructura de una aplicacin que est diseado usando un
enfoque centrado en el programa.





Como se puede notar, el enfoque centrado en el programa tiene muchas desventajas, incluyendo:
La aplicacin no se est aprovechando de los DBMS y sus futuras actualizaciones y funciones
inflexibilidad para adaptarse a las nuevas necesidades del negocio
Las reglas de negocio se duplican a travs de diversos programas. A medida que cambian las
reglas de negocio, los programas deben ser cambiadas o vuelve a compilar.
Los problemas de rendimiento asociados a RLA
La aplicacin tiene que ser recompilado si un archivo cambia
normalizacin de bases de datos puede ser inexistente.
integridad referencial est implcita
Por otro lado, la programacin centrada en datos se puede entender como la estrategia para
resolver problemas de negocio mediante el aprovechamiento de las caractersticas de los DBMS.
Este enfoque propone implementar ms lgica de negocio en la base de datos y la separacin de
la lgica de negocio de programas de aplicaciones de alto nivel. La figura 3-2, se muestra la
estructura bsica de una centrada en los datos programa.








Programacin centrada en los datos tiene como objetivo aprovechar los DBMS, especficamente
con los siguientes artculos:
Optimizar el acceso a los datos
La aplicacin solicita datos a travs de sentencias SQL. A su vez, el DBMS selecciona la mejor forma
de acceder a los datos y aconseja a los ndices necesarios para que sea ms eficiente.
El uso de restricciones
Con el uso de restricciones, puede mover las reglas de negocio de las aplicaciones a la DBMS
Normalizacin
Con el uso de los DBMS, es ms fcil mantener la normalizacin al menos a la tercera forma
normal.
El DBMS entiende las relaciones de las tablas mediante el uso de clave principal (PK) y clave
externa (FK) restricciones. PK / FK relaciones son datos ajenos a la empresa, por lo general
mediante el uso de las columnas de identidad en cada mesa. Una columna de identidad se
incrementa automticamente cuando las nuevas filas se agregan a la tabla, y se mantiene por el
DBMS, no por el programador.
En resumen, los objetivos principales de la aproximacin centrada en los datos son los siguientes:
Conduzca tanto trabajo hacia abajo en el sistema de gestin de base de datos como sea posible
Definir reglas de negocio como parte de la base de datos
Reglas se aplican a todas las interfaces de aplicaciones
Aproveche SQL slo capacidades
DDL modificaciones sin afectar los programas (es decir, Index Advisor, y as sucesivamente)
Evolucionar la base de datos para cumplir con los nuevos requisitos
Aprovechar las nuevas tecnologas y mejoras en DBMS, tales como el nuevo optimizador (SQE)
Cuanto ms cerca de su diseo se ajusta a los objetivos centrados en datos anteriores, cuanto ms
se puede aprovechar tecnologa de avanzada. En la Figura 3-3, se puede ver una comparacin
entre cntrica programa y los enfoques centrados en datos.

3.5.1 Mover a centrada en los datos de programacin
Si usted est planeando mudarse a un enfoque centrado en los datos, hay algunas cosas que usted
debe consideran que pueden ayudarle en el camino:
integridad referencial
Comprobar restricciones
seguridad a nivel de la columna
cifrado Columna
generacin automtica de claves
Triggers
procedimientos tienda


Integridad referencial desde el principio
Es muy importante para empezar a definir las relaciones de las tablas para poder garantizar
integridad de la base. Por ejemplo, cuando queremos aadir un nuevo empleado a una base de
datos y que valide su departamento, podemos definir una regla de integridad referencial que no
hace permitir que el complemento del registro de empleado si el ID de departamento no es
correcta o no existe en la mesa del departamento. Con esta regla nos aseguramos que no hay
empleados en mala identificacin del departamento; esta norma se destaca y se aplica para todas
las interfaces.
Los factores desencadenantes son un complemento excepcional
Hay una lgica de negocio que se puede implementar con disparadores. Definicin de un
disparador es una tcnica para garantizar validaciones de negocio importantes.
Puede que sea necesario incluir algunas validaciones que no son posibles para garantizar
referencial integridad. Esto es cuando se va a utilizar disparadores. El mayor complemento para
ejecutar las validaciones de la base de datos.
Imagnese si usted desea validar el estado de crdito de un cliente antes de aceptar un pedido.
Esta validacin no es posible a partir de la integridad referencial, pero se puede crear un
disparador para insertar el momento de determinar si se acepta o no la orden del cliente.
La figura 3-4 muestra un ejemplo. Cuando se inserta un nuevo orden, un disparador inicia y el
gatillo obtiene informacin sobre el orden y el cliente. Inmediatamente, un correo electrnico es
enviado automticamente.

SQL es la base
SQL es la base de la programacin centrada en los datos. En este tipo de programacin, SQL
funciona de manera eficiente en el procesamiento de grandes conjuntos de datos.
Todos los objetos de la base de datos son ms eficaces cuando se crean con SQL.
Usted debe considerar la creacin de todos los objetos con SQL porque esto puede mejorar el
acceso a los datos y el rendimiento de las aplicaciones.
3.6 Servicio Orientacin
La figura 3-5 muestra la evolucin de las aplicaciones. Al principio, las solicitudes tenan todo el
cdigo para todas las funciones en el mismo lugar. El mantenimiento de estas aplicaciones es muy
difcil, debido a la cantidad de cdigo y las funcionalidades en los programas.


Despus de eso, se consideraron las aplicaciones distribuidas. Estas aplicaciones tienen una parte
de cdigo en el lado del servidor y otra en el lado cliente. Este perodo de tiempo fue llamado el
momento de las aplicaciones cliente / servidor. Las aplicaciones cliente / servidor fueron muy
tiles para un buen interfaces de usuario, sino que requiere un muy buen diseo y una buena
capacidad o la aplicacin podra salir fcilmente de los problemas de sincronizacin y la causa.
Despus de las aplicaciones cliente / servidor, los programadores desarrollaron aplicaciones
mediante el uso de diferentes tecnologas. Algunas de estas tecnologas son RMI / IIOP, CORBA,
DCOM, y otros. Este perodo de tiempo se denomina tiempo de las tecnologas distribuidas.
Durante este tiempo aplicaciones corran sobre plataformas heterogneas.
Desarrollo de aplicaciones con tecnologas como RMI / IIOP, CORBA, DCOM y otros similares
tecnologas, es una tarea difcil. Usted debe tener altas habilidades para el uso de estas
tecnologas. Para esta razn, las aplicaciones comenzaron a aplicarse con el uso de los servicios
web. Cuando crear aplicaciones basadas en SOA (Service Oriented Architecture), que est
utilizando un estndar lenguaje llamado XML. XML se utiliza para definir la entrada y la salida de la
llamada de servicios. Esta lata contribuye a disociar y promover un enfoque escalonado porque el
llamador del servicio Web no necesita saber nada acerca de la plataforma.


Cuando hablamos de la orientacin al servicio, nos referimos a la arquitectura orientada a
servicios
(SOA). SOA es un enfoque de arquitectura de integracin basada en el concepto de un servicio. Las
funciones comerciales y de infraestructura que se requieren para construir sistemas distribuidos
son disposicin en los servicios que, en conjunto o individualmente, ofrecen funcionalidad de la
aplicacin a fin aplicaciones de usuario u otros servicios.
SOA especifica que dentro de cualquier arquitectura dada, debe haber un mecanismo consistente
de servicios para comunicarse. Ese mecanismo debe ser acoplado y apoyar el uso de las interfaces
explcitas.
SOA ofrece los beneficios de acoplamiento dbil y la encapsulacin a la integracin en una
empresa nivel. Se aplica conceptos de xito demostrado por el desarrollo orientado a objetos,
componentes
Diseo basado, y la tecnologa de Integracin de Aplicaciones Empresariales de un enfoque
arquitectnico para la integracin de sistemas de TI.
Los servicios son los componentes bsicos de SOA, proporcionando interfaces para las funciones
de las cuales los sistemas distribuidos pueden ser construidos. Los servicios pueden ser invocados
de forma independiente, ya sea externo o consumidores de servicios internos para procesar
funciones simples, o se pueden encadenar juntos para formar funcionalidad ms compleja y por lo
tanto concebir rpidamente nuevas funcionalidades.
3.6.1 Qu es un servicio?
Un servicio puede ser definido como cualquier funcin discreta que se puede ofrecer a un externo
o interno consumidor. Esto puede ser una funcin de negocios individuales o una coleccin de
funciones que forman juntos un proceso. Se puede comparar a un mdulo que se empaqueta en
un servicio programa. La diferencia es que un servicio se puede llamar desde cualquier lugar.
Los servicios son funciones u operaciones que estn disponibles en una red. Algunos ejemplos son
de login Servicio, Calcular TRM, Servicio de impresin, y as sucesivamente.
Los servicios son accesibles de forma independiente de la aplicacin o el transporte y se integran a
travs de la red de la empresa.

3.6.2 Las propiedades de los servicios
Un servicio debe cumplir con las siguientes caractersticas.
Ligeramente agrupado
Los servicios se definen por interfaces independiente de la implementacin explcitas. Los
consumidores de los servicios slo dependen de este tipo de interfaz de invocacin de servicio;
que no tienen que ver con la implementacin del servicio o incluso cuando se ejecuta.
Acoplamiento dbil promueve la flexibilidad en el cambio de la implementacin del servicio sin
afectar a los consumidores de servicios.
Reutilizable
Es muy importante para disear servicios con la reutilizacin en mente y anticipar los diferentes
escenarios de reutilizacin. Es decir, cada servicio ha sido diseado para su reutilizacin, sin
duplicaciones.
Usted puede seguir estos pasos en el diseo para la reutilizacin:
Descomponer el negocio que necesite en su funcin y los servicios (separacin de las
preocupaciones necesarias)
Reutilizar y crear la funcin de aplicaciones de negocio especficas y los servicios (creacin y
reutilizacin servicios)
Utilizar los servicios comunes que ofrece el entorno operativo (utilizar la infraestructura)
El resultado es una aplicacin compuesta en tiempo de ejecucin que representa un proceso de
negocio.
Encapsulado
Los servicios no deben exponerse fsicamente ningn detalle de implementacin o detalles de
implementacin dentro de su diseo de la interfaz.
El concepto de encapsulacin por el uso de interfaces debe estar familiarizado de las disciplinas de
Anlisis y Diseo Orientada a Objetos (OOAD). Las interfaces se utilizan para separar pblicamente
comportamiento disponible de la aplicacin de dicho comportamiento. Los consumidores de ese
comportamiento slo depende de la interfaz que describe el comportamiento; los consumidores a
continuacin, no son afectados si la puesta en prctica de ese comportamiento cambia de ninguna
manera. Servicio basado arquitecturas proporcionan un conjunto de interfaces de grano grueso
que encapsulan el acceso al ms fino grano componentes y son accesibles a travs de la red.
Aptrida
Las implementaciones de servicios no deberan acercarse estado conversacional en las distintas
solicitudes.
Los servicios deben comunicar la informacin completa en cada peticin y cada operacin debe
ser funcionalmente independiente (separada e independiente).
Alta cohesin
Las interfaces de servicios deben ser concisos, relacionados, y juegos completos de operaciones.
Conciso y completa implica cada operacin que se necesita y no ms.
3.7 Nube
El hecho de que el sistema operativo IBM i (OS) es uno de los mejores de mltiples cargas de
trabajo, multiusuario plataformas de negocios es innegable. El valor de i de IBM y su arquitectura
es que se basa en seguridad de los objetos, las descripciones de puestos, y robusto de
planificacin de tareas y gestin del trabajo. Estas caractersticas lo convierten en una plataforma
ideal para ejecutar cargas de trabajo multiproceso. Usuarios de IBM i se ejecutan por lotes
procesamiento, web, y las cargas de trabajo de aplicaciones interactivas a la vez, sin dejar de
tomar ventaja de una alta disponibilidad. Otras plataformas no estn estructuradas de tal forma
de ejecutar estos tipos de cargas de trabajo de manera ms eficiente y con el aislamiento de
trabajo (separacin).
Desde una perspectiva tcnica, la seguridad y el aislamiento de los inquilinos de los negocios de
cada uno procesos y datos es una preocupacin primordial para la nube. Nueva aprovisionamiento
inquilino es la capacidad para crear la infraestructura, la plataforma y entorno de software en
forma oportuna y repetible manera para sus nuevos clientes.
Desde una perspectiva comercial, la medicin y la medicin para la facturacin es la principal
preocupacin.
Los principales puntos que debe considerar para la nube son:
Virtualizacin
Multitenancy
Performance
Seguridad
Medicin para su modelo de licencia
El IBM i tiene una larga historia de la virtualizacin. Por ejemplo, particin lgica (LPAR)
capacidades han estado disponibles desde 2001.
Para multiusuario, cuando los usuarios 1 de usuario o 1000 utilizan el mismo programa, la parte
ejecutable del programa se carga slo una vez en la memoria. Si implementa una nueva versin
del programa mientras que los usuarios siguen conectados, no hay nada roto y los usuarios seguir
trabajando con su versin actual. Sin embargo, si se limitan a firmar apagado y firman de nuevo,
van a tener la nueva versin del programa. Para un entorno de 5250, este despliegue dinmico no
es posible porque los objetos de visualizacin del archivo se asignan mientras estn abiertos. En
un entorno de multinivel, esta es totalmente posible.
La i de IBM es muy escalable para el rendimiento y la seguridad es su fuerza.
IBM i ha tenido esta capacidad durante muchos aos. Sus aplicaciones ya pueden aprovechar la
nube.

















Herramientas de desarrollo moderno
Hay muchas categoras de herramientas de desarrollo. En este captulo, cubrimos algunas de las
herramientas que son comnmente utilizados por los desarrolladores de RPG y COBOL. Tiene
sentido que una aplicacin proyecto de modernizacin tambin podra incluir la modernizacin de
su conjunto de herramientas de desarrollo.
La categora de herramientas que se aplica a la mayora de las tiendas se refiere a la edicin,
compilacin y depuracin aplicaciones host, que son a veces parte de un conjunto de
herramientas que se llama un Sistema Integrado
Entorno de desarrollo (IDE). Adems, existen herramientas que estn relacionados con el cdigo
fuente cambiar las herramientas de gestin o de control de cdigo fuente. Veremos esas dos
categoras de herramientas en este captulo, y algunas otras herramientas que pueden ser tiles
para entornos especficos.
Los cambios en su aplicacin puede ser muy sencilla tcnicamente, pero tambin hay otros
aspectos de un proyecto de modernizacin para tener en cuenta:
Pluralidad de la cultura: Los desarrolladores que utilizan diferentes tecnologas necesitan
compartir proyectos, informacin y procesos.
Pluralidad de tecnologas: Interfaces y conexiones introducen funcionalidad multiplataforma
dependencias.
Complejidades: Las nuevas tecnologas y metodologas pueden introducir complejidades que su
herramientas existentes no llegan a ser capaz de manejar de una manera significativa y confiable.
En este captulo se describe la situacin y recomienda cambios en las herramientas de desarrollo
que podran ser necesarias para su proyecto de modernizacin. Tambin describe cmo cambiar
su metodologa de desarrollo cuando se trabaja con estas herramientas.

4.1 Editar, compilar y depurar IDE
La herramienta principal de IBM disponible en la edicin, compilacin y depuracin de categora es
un IDE llamada Rational Developer for i, RPG y COBOL Herramientas, ms comnmente conocido
como RDi. Anterior versiones de este IDE basado en Eclipse de IBM eran conocidos como Rational
Developer for Power Sistemas (RDP) y Cliente de IBM WebSphere Development Studio (WDSC).
Las principales capacidades bsicas de estas herramientas se han mantenido igual a lo largo de las
distintas versiones.
Sin embargo, las nuevas caractersticas y funciones se han aadido a travs de los aos, incluido el
apoyo de las caractersticas del lenguaje actual en el editor y una pantalla grfica de DDS y
diseador de informes.
4.2 SEU y PDM para RDi: Por qu cambiar?
Muchos desarrolladores de IBM i han estado utilizando la misma herramienta para la edicin,
compilacin y depuracin su cdigo durante dcadas. Esta herramienta es la "pantalla verde"
herramienta de desarrollo de aplicaciones basadas
Set (ADTS), que incluye el Administrador de Programacin del Desarrollo (PDM), Utilidad para
Entrada del Fuente
(SEU), Screen Design Aid (SDA) y otras herramientas.
ADTS ya no es la mejor herramienta para los modernos i desarrolladores de IBM. Las herramientas
de la pantalla verde tienen alcanzado el lmite de sus capacidades y su funcionalidad no se ha
mejorado en muchos ao. La ltima actualizacin de estas herramientas fue en abril de 2008
cuando IBM i 6.1 fue lanzado. Desde ese momento, el conjunto de herramientas ADTS se ha
estabilizado. No hay planes para incluir cualquier informacin adicional funcionar a estas
herramientas, incluyendo cambios a los verificadores de sintaxis para los lenguajes soportados.
Las modernas herramientas de desarrollo de sustitucin de IBM se basan actualmente en el
Rational Developer para i (IDI), un entorno de desarrollo integrado basado en Eclipse (IDE).
Los desarrolladores que se sienten cmodos usando el conjunto de herramientas PDM / SEU
podra preguntarse por qu deben cambiar.
Las siguientes secciones describen algunas de las razones para el cambio.
4.2.1 actual (y futuro) soporte de idiomas
IBM ya no es la actualizacin de las herramientas ADTS estilo antiguo para las nuevas
caractersticas del lenguaje. Ha sido muchos aos ya que no haba ningn tipo de mejora funcional
de las herramientas ADTS. Hasta IBM i 6.1, IBM incluye soporte para nuevas caractersticas del
lenguaje. Por ejemplo, los inspectores de sintaxis en la SEU editor se han actualizado para
comprender nuevas palabras clave de rol, los cdigos de operacin o funciones incorporadas en
cada versin.
Las actualizaciones para las nuevas caractersticas del lenguaje ya no se proporcionan. Por lo
tanto, al utilizar SEU editar RPG o fuente COBOL, nuevas caractersticas del lenguaje para IBM i 7.1
y posterior no son reconocido. Esto significa que muchas de las nuevas funciones de forma libre
para RPG habr prcticamente imposible de implementar para los desarrolladores que utilizan las
herramientas ADTS. SEU usuarios ya estn falta de apoyo editor para funciones como la ScanRpl%
(escanear y reemplazar) incorporado, RPG Manejadores de acceso abierto, y gastos de conjuntos
de resultados de procedimientos almacenados. Slo Rational Developer para i utillaje ofrece lo
ltimo en soporte de idiomas, tanto ahora como en el futuro liberaciones.
4.2.2 entorno de desarrollo basado en Eclipse
Las herramientas de Rational Developer estn basadas en Eclipse, un desarrollo de cdigo abierto
medio ambiente en diferentes idiomas en muchas plataformas diferentes. La base de Eclipse
proporciona muchas ventajas para IBM i desarrolladores.

El mismo conjunto de habilidades que se utiliza cuando el desarrollo de RPG o COBOL de
IBM i puede ser utilizados en muchos otros entornos debido a una amplia variedad de
herramientas tales son Eclipse basado. Cuando est desarrollando pginas web, escribir o
utilizar el cdigo escrito en PHP o Java, o cuando se accede a muchas herramientas
orientadas a la base de datos, puede utilizar muchas de las mismas tcnicas y habilidades.
Puesto que hay muchas herramientas basadas en el mismo ncleo, se obtiene
previsibilidad cuando se necesita para utilizar estas herramientas.
Muchos plug-ins estn disponibles para Eclipse porque es tan ampliamente utilizado. Esto
significa que usted no tienen que depender solamente de IBM para suministrar toda la
nueva funcionalidad es posible que desee o necesite.
Otra persona podra ya haber escrito l y lo puso a disposicin del pblico. Algunos de
estos plug-ins pueden ser especficos para la plataforma IBM i. Ejemplos de estos incluyen
RPG / Gratis conversiones de origen, 5250 emuladores, editores de archivos de mensajes,
y otras herramientas tiles. hay son los plug-ins adicionales que no estn escritas
especficamente para un IBM i medio ambiente, pero todava puede ser muy til,
incluyendo muchas herramientas orientadas a bases de datos. A menudo, estas
herramientas estn disponibles ya sea de forma gratuita o con un costo muy bajo.


4.2.3 Las caractersticas de productividad de RDi
Tal vez la razn ms importante para cambiar de PDM / SEU a RDi es la dramtica
aumento de la productividad que ofrecen las herramientas ms avanzadas. Se requerira un libro
entero para producir una lista completa de caractersticas de productividad que RDi ofrece sobre
las herramientas PDM y SEU.
A continuacin se destacan algunas de las caractersticas de productividad ms evidentes de la RDi
editor de cdigo fuente especfica, junto con algunas herramientas estrechamente integradas con
el editor que estn diseados para apoyar el proceso de edicin.
RDi depurador grfico El depurador RDi tiene la capacidad de controlar los valores de las variables
seleccionadas al pisar a travs del cdigo y / o detenerse en los puntos de ruptura. El depurador
tambin tiene la capacidad de contener puntos de ruptura, tanto activos (habilitados) e inactivos
(discapacitados). Esto viene muy bien porque la depurador tambin puede recordar los puntos de
corte a travs de mltiples sesiones de depuracin en caso de que un bug problemtica requiere
de un trabajo de varios das.
Un ejemplo del depurador RDi en la accin se muestra en la Figura 4-1. La captura de pantalla
ilustra varias caractersticas del depurador RDi. Los monitores de ver (ventana superior derecha)
muestra valores de las variables que se eligieron a ver a lo largo de la sesin de depuracin. Los
valores que han cambiado desde el ltimo paso o punto de ruptura aparecen en rojo. Otros
valores de las variables pueden ser se muestra el cursor sobre una variable para mostrar su valor
actual, como se ilustra. Los puntos de interrupcin se muestra con una marca a la izquierda del
nmero de documento.


Figure 4-1 RDi Graphical Debugger

DDS diseador
Adems del depurador, el diseador DDS puede hacer mantenimiento o creacin de informes o
pantallas ms fciles. El diseador grfico de DDS es la misma herramienta, tanto para informes y
pantallas - a diferencia de la SDA y herramientas RLU en el ADTS mayor conjunto de herramientas.
El diseador hace que sea mucho ms fcil mover los campos y el texto alrededor y centrar o
alinear elementos. Los campos de los archivos de bases de datos o tablas se pueden elegir de una
lista y se deja caer sobre la pantalla para crear campos de referencia de base de datos. Lo es muy
simple para cambiar entre el modo de diseo grfico y la edicin directa de la DDS para aquellas
ocasiones en que el enfoque directo de edicin es ms productivo.
Mira la Figura 4-2 para tener una idea de lo que funciona la herramienta de diseo de DDS en RDi.
En este ejemplo se muestra un archivo de pantalla pero la interfaz para archivos de impresora es
muy similar. La ventana de diseo en el centro permite al desarrollador para mover o cambiar la
longitud de los elementos de la pantalla utilizando arrastre o estiramiento. La ventana de
propiedades por debajo de la ventana de diseo permite que todas las propiedades del elemento
seleccionado (ProdCode en este ejemplo) para ser visto y editado, incluyendo palabras clave y el
indicador acondicionado (utilizando otras pestaas en la ventana de propiedades.) La Paleta a la
derecha de la ventana de diseo permite a los nuevos elementos que se colocan en la pantalla de
arrastrar y soltar. El Esquema (ventana inferior izquierda) muestra detalles de elementos en la
pantalla, incluyendo a muchas palabras clave, y tambin se puede utilizar para seleccionar
elementos en la pantalla de diseo. En la parte inferior de la ventana de la pantalla del diseo son
tres pestaas, una de las cuales (Fuente) permite que la fuente DDS para ser editado
directamente.



iProjects

Hay otras herramientas en RDi, ms notablemente iProjects, que el apoyo que trabaja en un
desconectado medio ambiente. iProjects tambin se pueden utilizar para ayudar a organizar el
trabajo de desarrollo en locales proyectos almacenan en el disco estacin de trabajo o en IBM i u
otro servidor. iProjects tambin es se utiliza con algunas herramientas de gestin del cambio de
fuente.
RDI destacados productividad editor como la mayora de los desarrolladores gastan ms de su
tiempo de visin, navegacin y edicin de cdigo fuente, los beneficios de productividad del editor
RDi merecen un anlisis ms detallado. El editor contiene mltiples funciones para mejorar la
productividad de programacin. Adems del editor de s mismo, hay herramientas, tales como el
Esquema y Error vistas Feedback, que estn diseados para trabajar en estrecha colaboracin con
el editor para mejorar an ms la productividad. En esta seccin se har hincapi en algunos de las
ms valiosas funciones de productividad del editor.
Ms cdigo visible a la vez Cuando la edicin de cdigo fuente, un desarrollador puede ver
tpicamente de 2 a 3 veces el nmero de lneas de cdigo en comparacin con el editor de
SEU mayor. Cuando se utiliza SEU, el nmero de lneas visibles es fijo,
independientemente del tamao de monitor utilizado. Con el editor de RDi, el nmero de
fuente lneas visibles vara en funcin del tamao del monitor y la forma y el tamao de la
fuente seleccionada. Vista ms cdigo hace que sea ms fcil y ms rpido para seguir el
flujo de la lgica. Figura 4-3 ilustra la capacidad de ver ms lneas de cdigo a la vez.

Miembros fuente abierto y mltiple a la vez Miembros fuente mltiples pueden ser
abiertos para su edicin (y hojear) al mismo tiempo. Este se vuelve ms importante como
las aplicaciones modernas se hacen ms modular. Es fcil de haga clic entre los miembros
abiertos como fluye la lgica entre los mdulos. Dos o ms miembros se pueden ver
simultneamente a travs de uno o ms de pantalla dividida horizontal y vertical lneas.
Incluso en el modo de pantalla dividida, todos los miembros pueden ser abiertos para su
edicin. Consulte la Figura 4-3, que muestra un ejemplo de edicin de la pantalla dividida
en IDI. En esa misma figura las pestaas mostrando por encima del cdigo fuente indican
los diferentes miembros de origen que se encuentran actualmente abrir en la sesin de
edicin.

See Figure 4-3,which shows an example of split screen editing in RDi. In that same figure the tabs
showing above the source code indicate the different source members that are currently
open in the edit session.


Filtrado de cdigo fuente
Lneas de cdigo fuente se pueden filtrar en el editor RDi en un nmero de maneras. Si hay
muchos lneas comentadas Salida de cdigo en un miembro fuente, eligen para filtrar para ver slo
cdigo. Este elimina todas las lneas de comentarios desde su punto de vista, dando an ms
lneas de cdigo visible a l desarrollador. Las lneas tambin pueden ser filtradas por la ltima
fecha de modificacin de la lnea, que puede ser til en la bsqueda de los cambios recientes en el
cdigo que pueden haber causado errores recientes en la aplicacin. Otras opciones de filtro
incluyen mostrando instrucciones SQL nicas, mostrando slo subrutinas o secundarios y las que
muestran sentencias lgicas flujo nico de control. Adicionalmente, un poco de texto, por
ejemplo, un nombre de campo, se puede seleccionar y luego se filtr el cdigo en ese seleccin.
Esto calza nicamente las lneas de cdigo que hace referencia a ese campo en el editor.
El filtrado puede ayudar al desarrollador a encontrar partes de un programa que requiere atencin
rpida.
Vista del esquema para las definiciones, referencias cruzadas y de navegacin fuente
A la vista Esquema programa est disponible para ayudar con la navegacin a travs del cdigo
fuente. El esbozo de un programa RPG IV incluye los detalles de cada archivo declarados, incluidos
todos los registros formatos y todos los campos y sus definiciones. Los detalles de todas las
variables del programa definido y
Tambin se incluyen las estructuras de datos. Tanto el programa describe como externamente
describe variables que aparecen en una lista que puede ser ordenada alfabticamente por el
nombre del campo para que sea rpido para encontrar la definicin de campo es necesario.
Incluso sin utilizar la vista Esquema, espectculos el editor RDi la definicin de una variable cuando
se pasa el ratn sobre su nombre. As que no hay ms
Necesitamos hacer un DSPFFD (Mostrar archivo de definiciones de campo) o algn otro mtodo en
el host para encontrar la definicin de un campo.
Adems de las definiciones de datos, el Esquema RPG IV contiene todas las subrutinas,
subprocedimientos y los prototipos que se definen en el miembro fuente.

El Esquema est integrado con el editor. Esto significa que un desarrollador puede navegar
directamente al lugar en el programa en el que un elemento variable o subrutina u otra se define
o codificada. Adems hay una referencia cruzada en el Esquema muestra que cada elemento hace
referencia en el miembro fuente; esas lneas de referencia transversales tambin estn
conectados al editor. As, por ejemplo, un desarrollador puede navegar fcilmente no slo a una
subrutina especfica utilizando el esquema, pero tambin pueden navegar directamente a cada
lnea de cdigo en el elemento que llama a la subrutina. La informacin de referencia cruzada para
los campos indica si no se modifica el campo en que la declaracin por medio de (M) despus de
que el nmero de sentencia. La Vista Esquema se actualiza automticamente a medida que edita
el cdigo en la vista de edicin. Estos dos puntos de vista estn estrechamente ligados.
La figura 4-4 muestra el esquema para la derecha del cdigo en el editor. Los detalles de cada lnea
de cdigo que hace referencia a la variable FullDate, junto con la definicin de FullDate, se
muestra.
Tenga en cuenta que dos de las instrucciones que hacen referencia FullDate modificar el valor,
mientras que uno de ellos slo hace referencia a ella. Una de las referencias se selecciona en el
Esquema, que automticamente colocado el editor para esa lnea de cdigo.





Deshacer y rehacer
Durante una sesin de edicin, un desarrollador tiene niveles ilimitados de deshacer y rehacer,
tanto de cambios individuales, incluso despus de la parada y compilar, mientras que el miembro
fuente sigue abierta en el editor. Esto significa que usted puede abrir un archivo, realizar cambios,
guardar y luego compilar y hacer esta secuencia varias veces y todava "deshacer" cambios
individuales de todo el camino de regreso al abrir ese archivo. En el editor de SEU, la nica opcin
para deshacer los cambios es deshacer todo los cambios en toda la sesin de edicin de cerrar el
editor sin guardar el miembro.
Teclas Tab trabajan en lenguas columnas sensibles
Para algunos idiomas sensibles de columna, las teclas Tab funcionan sin necesidad de preguntar.
Las posiciones de las pestaas se pueden personalizar segn las preferencias del desarrollador.
Una lnea de formato que aparece en la parte superior de la ventana del editor indica la posicin
actual del cursor en la line. A diferencia de la lnea de formato en el SEU, que siempre refleja el
formato de la primera declaracin en la pantalla, el editor RDi cambia la lnea de formato para que
coincida con la declaracin en la que se encuentra el cursor. Esto hace que sea mucho ms rpido
para introducir el cdigo que se encuentra todava en formato fijo RPG, as como el cdigo DDS.
Retroalimentacin Error integrado con el editor
Errores que se producen durante una compilacin aparecen en una lista de errores al lado del
editor de cdigo fuente.
Haciendo doble clic en un error en la lista que posiciona a la lnea de cdigo en el editor de donde
se encontr el error y coloca el mensaje (s) error en la fuente. Desarrolladores nunca tienen que
mirar a unos separados listados archivo de cola de compilacin para encontrar y corregir los
errores de tiempo de compilacin en su cdigo. Miembros fuente editados en RDi son tpicamente
compiladas sin cerrar el miembro fuente para permitir una reaccin ms rpida a los errores en
tiempo de compilacin. En la Figura 4-5, un intento de compilacin result en varios errores. En el
momento de esta captura de pantalla, el desarrollador ejecuta doble clic sobre uno de los errores
y el editor se coloca automticamente en la lnea de cdigo para ese error.
La integracin de la retroalimentacin de error con el editor es considerablemente ms rpida que
cualquier mecanismo que implica la exploracin de un archivo en spool de compilacin listado
para localizar lneas de cdigo en el error.