74
Tabla de contenido ¿Por qué modernizar?............................................. 3 1.1. ¿Qué es la modernización?..................................5 1.2 Enfoques para la modernización..............................5 1.3 La necesidad de modernización...............................6 1.3.1 La necesidad de modernizar la base de datos.............6 1.3.2 La necesidad de modernización de interfaz...............6 1.3.3 La necesidad de modernización del programa..............7 1.4 Los beneficios de la modernización..........................7 1.5 ¿A partir de dónde empezar?.................................8 1.6 Colocación de las reglas del juego..........................8 1.7 ¿Qué es una aplicación moderna?.............................9 1.8 Obstáculos..................................................9 1.9 Comienza el viaje..........................................10 Camino a la modernización.......................................10 2.1 ¿En donde estas empezando?.................................10 2.2 ¿Cuáles son sus metas de modernización?....................11 2.2.1 Reemplazo..............................................11 2.2.2 Reingeniería...........................................12 2.2.3 Refacing...............................................13 2.2.4 Refactoring............................................15 2.3 Cómo modernizar............................................15 2.3.1 Introducción...........................................15 2.3.2 Modelo de Modernización................................16 2.3.3 Principios generales...................................17 2.3.4 Fase 0: Preparar.......................................19 2.3.5 Fase 1: Experimentación................................22 2.3.6 Fase 2: Off and Running................................23

manual español reingenieria.docx

Embed Size (px)

Citation preview

Page 1: manual español  reingenieria.docx

Tabla de contenido

¿Por qué modernizar?........................................................................................................................3

1.1. ¿Qué es la modernización?................................................................................................5

1.2 Enfoques para la modernización..............................................................................................5

1.3 La necesidad de modernización...............................................................................................6

1.3.1 La necesidad de modernizar la base de datos...................................................................6

1.3.2 La necesidad de modernización de interfaz......................................................................6

1.3.3 La necesidad de modernización del programa..................................................................7

1.4 Los beneficios de la modernización..........................................................................................7

1.5 ¿A partir de dónde empezar?...................................................................................................8

1.6 Colocación de las reglas del juego............................................................................................8

1.7 ¿Qué es una aplicación moderna?...........................................................................................9

1.8 Obstáculos................................................................................................................................9

1.9 Comienza el viaje....................................................................................................................10

Camino a la modernización..............................................................................................................10

2.1 ¿En donde estas empezando?................................................................................................10

2.2 ¿Cuáles son sus metas de modernización?.............................................................................11

2.2.1 Reemplazo.......................................................................................................................11

2.2.2 Reingeniería.....................................................................................................................12

2.2.3 Refacing...........................................................................................................................13

2.2.4 Refactoring......................................................................................................................15

2.3 Cómo modernizar...................................................................................................................15

2.3.1 Introducción....................................................................................................................15

2.3.2 Modelo de Modernización..............................................................................................16

2.3.3 Principios generales.........................................................................................................17

2.3.4 Fase 0: Preparar...............................................................................................................19

2.3.5 Fase 1: Experimentación..................................................................................................22

2.3.6 Fase 2: Off and Running...................................................................................................23

2.3.7 Fase 3: Evaluación y ampliar el pensamiento futuro.......................................................26

2.3.8 Fase 4: Implementación..................................................................................................26

2.3.9 Repita según sea necesario.............................................................................................28

Page 2: manual español  reingenieria.docx

Las técnicas modernas de arquitectura de aplicaciones..................................................................29

3.1 Introducción...........................................................................................................................29

3.1.1 Los síntomas de un mal diseño........................................................................................29

3.2 La modularización..................................................................................................................30

3.2.1 ¿Por qué la modularización es importante......................................................................30

3.2.2 Principios generales.........................................................................................................32

3.3 Diseño por niveles..................................................................................................................33

3.4 Modelo de objetos de Negocios.............................................................................................34

3.4.1 Implementación..............................................................................................................35

3.4.2 Ventajas...........................................................................................................................35

3.5 Los datos de programación centrada.....................................................................................36

3.5.1 Mover a centrada en los datos de programación............................................................39

3.6 Servicio Orientación...............................................................................................................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

Page 3: manual español  reingenieria.docx

¿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 rápido movimiento, en constante cambio medio ambiente. La web, informática móvil y la nube han seguido rápidamente el impacto de interfaces gráficas. 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 fácilmente nuevos requisitos.

Page 4: manual español  reingenieria.docx

Las opciones para la modernización de una aplicación son o bien para reemplazarlo o para volver a utilizar técnicas de ingeniería. En cuanto a cuál de estas dos opciones es mejor depende de la aplicación y por qué la modernización está llevando a cabo el proceso. No importa qué opción es la solución correcta, todavía hay un requisito para entender el proceso de modernización y el proceso de re-ingeniería que es aprobada o rechazada. Las aplicaciones tradicionales a menudo son grandes y difíciles de modificar. La modernización de un legado aplicación no significa que la aplicación debe ser reemplazado o reescrito en un nuevo idioma. Modernización significa la reingeniería de una aplicación. Esto puede incluir el cambio de cualquier combinación de la interfaz, la lógica de negocio, y la base de datos. El objetivo de la modernización es para que sea más fácil cambiar y mantener su aplicación en el futuro y proporcionar la derecha interfaz para los usuarios.

La realidad es que, a lo largo de los años, las empresas ya han hecho una fuerte inversión en aplicaciones que satisfacen las necesidades del negocio. Aunque los requisitos de negocio podrían 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 reingeniería, la refactorización y mejorar el resto de la aplicación es para satisfacer estas demandas.

Este capítulo trata de las fuerzas impulsoras detrás de la modernización y algunos de los más comunes detrás de los proyectos de modernización. Cubre:

¿Cuál es la modernización La necesidad de modernización Los beneficios de la modernización

Page 5: manual español  reingenieria.docx

1.1.¿Qué es la modernización? Modernización significa diferentes cosas para diferentes personas. Modernización podría significar:

Creación de una nueva interfaz de usuario Refactorizar una base de datos Hacer grandes cambios en el código Hacer pequeños cambios en el código No hacer cambios en el código Integración de nuevas aplicaciones Cualquier permutación o combinación de los elementos anteriores

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

La modernización puede consistir en cualquier permutación y combinación del uso de una independiente proveedor de soluciones de software (ISV), el rediseño de una base de datos, el rediseño y la recodificación de aplicación programas, codificación de nuevos programas, utilizando nuevos lenguajes de programación, y la escritura de nuevas aplicaciones. La modernización es un término muy amplio con muchos aspectos diferentes a considerar. Este Redbooks publicación está dirigida a proporcionar una visión holística de la modernización.

1.2 Enfoques para la modernización El trabajo del desarrollador sería mucho más fácil si hubiera una hoja de ruta simple para Modernización. Por desgracia, este no es el caso. Hay muchos factores que determinan el enfoque deseado para la modernización:

Presupuesto Apoyo a la gestión ¿Por qué se está llevando a cabo el proceso de modernización? ¿Qué permutación de interfaz,

código de base de datos, y la aplicación 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.

¿Cuál es el estado de la aplicación actual? ¿Qué tan fácil es que va a ser la de cambiar esa código? 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 modernización. Aunque hay muchos enfoques, uno de los retos principales es asegurar que el enfoque elegido es fluido. Hay que caminar por la línea entre el control y la flexibilidad y desarrollar la capacidad para abrazar lo nuevo, manteniendo un núcleo de trabajo. Al principio, la elección de un camino a la modernización parece ser una tarea desalentadora. Si se acepta que el camino va a cambiar cuando se inicia el proceso, es mucho más fácil para empezar

Page 6: manual español  reingenieria.docx

1.3 La necesidad de modernización La necesidad de modernización por lo general es impulsado por una necesidad comercial: esto significa que a menudo que incitan a los usuarios la necesidad de la modernización. Aunque podríamos saber que, desde un punto de vista técnico, una aplicación debe ser modernizada, es raro que tengamos los recursos y financiación necesaria sin las peticiones y el apoyo de los usuarios y de gestión. Los usuarios son más conocedores de la tecnología. Demanda de los usuarios no es sólo para las soluciones. Los usuarios exigen cómo quieren las soluciones entregadas. Demandas empresariales conducen a los requisitos de modernización en tres áreas:

Database Interface Código de la aplicación

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 más comunes que pueden conducir a la modernización de bases de datos.

La compañía ha decidido sustituir Query/400 con IBM DB2 Web Query. La base de datos necesita ser modernizado para hacerlo más 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 análisis de PC que extrae información 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 más familiar para un administrador de base de datos (DBA).

Una nueva aplicación será escrita sobre una base de datos existente. La nueva aplicación 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 implementación de estas características también podría tener afectar a la aplicación existente.

Una aplicación existente tiene que ser reescritos. La modernización de la base de datos reducirá la complejidad de los programas disponibles en la nueva aplicación.

1.3.2 La necesidad de modernización de interfaz La necesidad de interfaces nuevas o mejoradas es probablemente la razón más citada para modernización. Estos son algunos de los escenarios más comunes que pueden conducir a la modernización de la interfaz.

Una empresa invierte en nuevas aplicaciones que utilizan una interfaz gráfica de usuario (GUI). Los usuarios son la conmutación entre la GUI y tradicionales 5,250 interfaces para diferentes aplicaciones. Ellos preferiría una interfaz común 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 compañía. Para estos usuarios, una interfaz gráfica de usuario es la interfaz de elección y una Pantalla de 5250 de estilo se considera pasado de moda.

Usuarios que han estado utilizando una aplicación para un número de años que soliciten una nueva interfaz gráfica de usuario para que se coloca en su lugar. Esto es a menudo una reflexión sobre el diseño de pantallas pobres. Los usuarios de Internet están felices con la solicitud, pero no con la forma en que se ve. A menudo, cuando los usuarios están contentos con Diseño de 5250 de

Page 7: manual español  reingenieria.docx

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 gráfico en su teléfono inteligente. Percepción. 5250 se considera viejo y GUI o móvil se considera nueva. Las nuevas aplicaciones

debe ser mejor, ¿no? A menudo, una nueva interfaz de usuario puede cambiar dramáticamente la vista de la comunidad.

Qué generación de usuarios tendrá instrucciones sobre cómo utilizar un ratón?

1.3.3 La necesidad de modernización del programa Estos son algunos de los escenarios más comunes que pueden conducir a la modernización del programa.

Una nueva interfaz basada en la web que se replica una aplicación 5250 de estilo existente está siendo desarrollado. Por ejemplo, se está creando una aplicación de entrada de pedidos para que los clientes pueden colocar sus propias órdenes sin tener que llamarlos pulg La nueva aplicación debe utilizar el misma lógica de negocio como la aplicación existente. Por desgracia, la lógica de negocio está firmemente incrustada en los programas de pantalla 5250.

Debido a los cambios que se están haciendo a la base de datos o de la interfaz, los cambios tienen que ser hecho a los programas de aplicación.

Una aplicación tiene cuatro programas horrendos, gigantescas que contienen la lógica de negocio principal de la aplicación. Cualquier cambio (aunque sea pequeño) 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 aplicación están a punto de la jubilación. Sería mejor si el código estuviera en un formato más fácil para un recién programador entrenado para entender. Es el momento de utilizar los estilos de programación y herramientas modernas. Clientes necesitan acceder a la información existente a través de un servicio web en lugar de interfaces existentes.

1.4 Los beneficios de la modernización Son muchos los beneficios que se derivan de la modernización, que incluye:

Una mejor interfaz Una mejor base de datos Más fácil de mantener aplicaciones Aplicaciones más flexibles. Nuevos requerimientos de negocio son más fáciles de implementar. Aplicaciones integradas. Es más fácil de integrar con otras aplicaciones, plataformas e

interfaces. Es más fácil encontrar desarrolladores que pueden mantener código moderno. Una aplicación modernizada puede dar a la empresa una ventaja competitiva. La capacidad de

hacer cambios rápidos en la aplicación significa que la empresa puede responder rápidamente a los cambios del negocio.

Siga usando la inversión existente. El hecho de que una aplicación podría beneficiarse de una Actualización a su interfaz no significa que la aplicación no está funcionando un cumplimiento de una necesidad de negocio.

1.5 ¿A partir de dónde empezar? Al igual que con todos los viajes, la duración del viaje y el reto del terreno que se atravesará dependerá de donde usted está comenzando.

Page 8: manual español  reingenieria.docx

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 recopilación) 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 código y técnicas que podrían haber sido de codificación de punta hace veinte años más, pero inferiores a las necesidades de hoy en día. Es necesario determinar lo siguiente:

¿La aplicación tiene una base de datos relacional bien estructurada? Fue la aplicación 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 aplicación? ¿Es COBOL, COBOL ILE, RPG II, RPG III,

RPG IV, Java, C, algún otro lenguaje, o alguna permutación o combinación de dos o más idiomas? Es la aplicación IBM Integrated Language Environment ® (ILE)? ¿Los programas de aplicación están bien estructurado?

1.6 Colocación de las reglas del juego El Inicio de un proyecto de modernización puede ser una perspectiva desalentadora y es fácil sentirse abrumado por las opciones y la cantidad de información disponible. Esta es la etapa en la que la mayoría de la gente dice: es más fácil seguir con lo que sabes en lugar de abrazar lo nuevo. Hay también el reto de tener que mantener la aplicación existente mientras se está modernizado. El alcance de un proyecto de modernización, 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 cómo pueden lograrse. Puede haber más beneficios de la modernización de código en lugar de empezar con la base de datos o viceversa. Las opciones sobre el uso de nuevos lenguajes dependerán de la disponibilidad de formación o programadores con las habilidades requeridas. La necesidad de un cambio bien definido de proceso de gestión es muy variado dependiendo de la cantidad de programadores que están trabajando en el proyecto. Hay muchos términos y condiciones que se aplican. Sería de gran ayuda si hubiese un solo plan que podría ser aplicado a todos los proyectos de modernización, pero este no es el caso. El proceso será diferente para cada tienda y cada aplicación. Aunque cada proyecto de modernización es diferente, hay una serie de reglas básicas y circunstancias que son comunes a todos. Hay principios básicos que deben aplicarse a todos los proyectos de modernización:

No tengas miedo al fracaso Habrá una necesidad de la educación y la formación. Desarrolladores debe utilizar las herramientas adecuadas y tienen que aprender a usarlos. Habrá una necesidad de gestión del cambio. Esta será la gestión del cambio en una

Entorno de desarrollo en oposición a un entorno de mantenimiento. Pruebe un proyecto no oficial. Pasar por el proceso de modernización, con sólo un par de

programas. Lleve a cabo una prueba de concepto (POC). Dar pequeños pasos. Hay mucho que aprender. Pon un proceso de documentación en el lugar. Usar Wikis. Determinar las normas y disciplinas para el proceso de modernización. Al comienzo de la

proceso, las normas y disciplinas serán las directrices, que se convertirá en firme procesos.

Page 9: manual español  reingenieria.docx

No se adhieren a las mismas prácticas que han estado utilizando durante años. Utilice ágil principios de desarrollo para entregar proyectos más pequeños que se acumulan unos sobre otros.

Tienes que hacer las cosas bien la primera vez. De lo contrario, se puede añadir a los gastos. Considere una solución "táctica" que puede aprovechar su objetivo estratégico.

1.7 ¿Qué es una aplicación moderna? Una aplicación moderna es aquella en que las modificaciones o mejoras a la aplicación tienen una efecto mínimo. Por ejemplo, cambios en la interfaz no deben exigir cambios en el lógica de negocio. La naturaleza de una aplicación moderna es que el diseño de la base de datos y programas es tal que el requisito de la prueba se reduce al mínimo. Este enfoque permite el desarrollo rápido y más fácil, mantenimiento menos complejo. Estas son algunas de las características que debe buscar en una aplicación moderna:

Un diseño escalonado que separa la aplicación en componentes separados: interfaz, lógica de negocio, y la base de datos.

Una base de datos bien diseñado y sintonizado que implementa la integridad flexibilidad de código, lo que permite un medio flexible para el desarrollo de nuevas interfaces

y cambiar los procesos de negocio. La reutilización de código, lo que significa que los mismos procedimientos se utilizan en todas

partes. No significa que el código se copia y se pega en múltiples programas. mantenibilidad de Código, lo que significa que no hay ningún código duplicado y que la

estructura de los programas es más simple y más fácil de entender. El mantenimiento de estos programas debe tener menos efectos secundarios potenciales.

1.8 Obstáculos Aparte de las necesidades obvias de financiamiento y de recursos, hay una serie de condiciones que pueden inhibir el proceso de modernización. Con base en la experiencia del equipo, estos son algunos de los obstáculos comunes que pueden dificultar, si no descarrilar, el proceso de modernización:

Desarrolladores no utilizan las herramientas adecuadas. Los desarrolladores están a gusto con lo que saben. A veces, es más fácil de mantenerse dentro de la zona de confort de la utilización 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 tecnologías o técnicas de tomar decisiones acerca de cómo van a ser utilizados. es por qué una prueba de concepto es tan importante.

Desaprender viejos hábitos. Muchos desarrolladores han estado observando las mismas prácticas por muchos años. Puede ser un reto para cambiar estos hábitos y adoptar otras nuevas.

No conseguir una formación adecuada. No es suficiente para instalar una herramienta y decir "empezar a usarlo", o para instruir a los desarrolladores que deben utilizar una nueva técnica cuando no lo hacen realmente entender por qué deben usarlo o cómo usarlo correctamente.

Hay tanto que aprender que los desarrolladores se sienten abrumados antes de que comiencen. todo debe hacerse en pequeños pasos.

Todo el proceso de modernización puede ser aterrador. En primer lugar, hay muchos

Page 10: manual español  reingenieria.docx

incógnitas 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 gestión. Es por esto que es importante empezar poco a poco. Entre más

pronto posible demostrar las ganancias, más fácil conseguir apoyo de la dirección.

1.9 Comienza el viaje Cualquiera de los muchos caminos de modernización que está a punto de salir en el viaje será lleno de desafíos, logros y diversiones interesantes. Es un viaje que constantemente ofrece nuevos horizontes.

Camino a la modernización

En este capítulo se proporciona una vía de modernización que usted puede seguir, independientemente del enfoque de modernización que usted elija. También proporciona directrices para ayudar a definir donde debe iniciar su camino a la modernización y las definiciones de algunos de los más comunes modernización se acerca disponible.

2.1 ¿En donde estas empezando?

Antes de iniciar un esfuerzo de modernización, es importante hacer una evaluación 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 más allá de la funcionalidad, como la mantenibilidad, flexibilidad, facilidad de uso y rendimiento. Para esta evaluación, considerar los siguientes pasos: . 1 Construir un inventario de sus aplicaciones principales: - Objeto social Definir el propósito de negocio de la aplicación desde una perspectiva empresarial. Entender que los procesos de negocio están soportados por la aplicación y cómo cada uno es crítico. - Interesado principal Determinar quiénes son los interesados que se debe tener en cuenta en un eventual proyecto de modernización. Esta lista le recordará la importancia de este proyecto de diferente personas, no sólo los expertos en TI. - Experto técnico Es necesario comprender claramente que los técnicos son que mantienen las aplicaciones. Estos expertos saben muchos pequeños detalles acerca de la aplicación que puede ser fundamental en el proyecto. . 2 Evaluar cada aplicación según los siguientes criterios: - Flexibilidad de la interfaz de usuario

Page 11: manual español  reingenieria.docx

- Capacidad de mantenimiento -Performance - Facilidad de integración - Habilidades disponibles - El valor del negocio . 3 Defina sus metas de modernización: - Mejor capacidad de mantenimiento - Nueva interfaz de usuario - Mejora de la legibilidad del código - Métodos de acceso a base de datos de mejores 4. Priorizar el inventario de acuerdo a las metas. Después de haber completado estos pasos, usted está listo para empezar a trabajar. La modernización ,las actividades implicarán diferentes aspectos de la aplicación, incluyendo: - Base de Datos - Interfaz de usuario - Integración con otros sistemas - La lógica de negocio Usted acaba de empezar, así que no trate de planificar todo el proyecto de modernización en este punto. Sus planes de modernización va a cambiar con el tiempo y se perfeccionará a lo largo del camino. Encuentra una pequeña pieza con que usted puede comenzar. Centrarse en piezas pequeñas que con el tiempo puede llevar a grandes cosas.

2.2 ¿Cuáles son sus metas de modernización? Dependiendo de sus objetivos de modernización, hay varios métodos disponibles. Lo que debe tener en cuenta es que no hay un enfoque de "talla única" para la modernización proceso. Esta sección presenta algunos de los enfoques más comunes en la aplicación modernización, que son fácilmente adaptables a la mayoría de los objetivos de modernización.

2.2.1 Reemplazo En este enfoque de la modernización, 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 técnica puede ser apropiado si los costos de modernización son extremadamente altos para justificar, una modernización proyecto bajo un enfoque diferente, o si la aplicación 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 garantía 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 degradación de el servicio en algún nivel.

El personal de TI involucrados en el mantenimiento del antiguo sistema necesitarán capacitación para llegar a conocer el nuevo sistema. Esta formación no es definitivamente opcional.

Las nuevas aplicaciones pueden cambiar sus metodologías de backup y recuperación, y deben ser considerado.

Page 12: manual español  reingenieria.docx

2.2.2 Reingeniería La reingeniería es el enfoque de la modernización que transforma la aplicación original en un nueva forma de mejorar sus características originales, como la funcionalidad, el rendimiento, la flexibilidad, Interfaz de usuario y de mantenimiento con menos riesgo de sustitución. La principal diferencia entre la sustitución y la reingeniería es que, en el último enfoque, usted debe tomar en cuenta la aplicación existente como una limitación de los pasos a seguir en el proceso de modernización. En otras palabras, no se puede ignorar la aplicación antigua. Por lo general, la reingeniería de enfoque es un proceso de dos fases: - La ingeniería inversa - Ingeniería Forward Ingeniería Inversa La ingeniería inversa es la extracción de los procesos de alto nivel y la estructura del original codificar en una representación fácilmente comprensible. La comprensión del código existente adquirida en esta fase es vital para el proceso de reingeniería. Dada la complejidad de muchos de las aplicaciones que necesitan ser modernizados y la falta de documentación funcional existente, este proceso puede ser difícil. 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 representación estructural del código que le ayuda fácilmente entenderlo. 2. Iniciar el mapeo de la representación estructural del código para funcionalidades de negocio. este le ayudará a identificar las reglas de negocio reutilizables que se pueden extraer de la modularidad.

3. Construir una representación arquitectónica de la aplicación para que pueda empezar a entender la aplicación como un todo. Tenga en cuenta que las tareas de ingeniería inversa por lo general se repiten a lo largo de la modernización proceso varias veces. No se preocupe si usted está encontrando difícil de entender la aplicación. como el proceso de modernización avanza, su comprensión del sistema original se Aumenta.ingeniería directa Ingeniería directa, también conocido como el "refinamiento", es la creación del nuevo sistema a partir de la representación de alto nivel del código original. Esta fase se procesa con los siguientes pasos: 1. Construir una nueva representación arquitectónica de la aplicación deseada. 2. Definir la transformación funcional de la original a la nueva aplicación. 3. Escriba el nuevo código. En este proceso, se debe aplicar buenas prácticas en términos de diseño, código, tecnologías y herramientas. Más adelante en este libro, usted encontrará muchas herramientas, técnicas y prácticas que usted debe considerar durante la construcción de la nueva aplicación. Hay muchas herramientas para ayudar con los actuales la comprensión del programa, junto con herramientas para ayudarle a escribir código de forma moderna.

2.2.3 Refacing Refacing es la reingeniería de sólo la interfaz de usuario de la aplicación. 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 código subyacente de la aplicación. Refacing es una tecnología que

Page 13: manual español  reingenieria.docx

tiene estado disponibles durante mucho tiempo. Algunas soluciones son mejores que otros. El uno significativa las ventajas de una solución de la renovación es el tiempo de comercialización. Utilizando una tecnología de rectificación, puede potencialmente mover una aplicación 5250 de "pantalla verde" a una web o aplicación móvil en cuestión de varios días. Esto no significa que usted tiene que parar en refacing. Este enfoque puede ser utilizado como un trampolín o primera aproximación paso. Este método le puede dar un tiempo valioso si están considerando un enfoque de la reingeniería. Tipos de rectificación Hay más de una manera de revestir de nuevo la aplicación. Dependiendo del grado en que va a ser aplicado, algunas técnicas de reparación son sólo superficiales y no requieren cambios en el código fuente. Otras técnicas involucran cambios mínimos en el código que se encarga de la IU, pero sin entrar en la lógica de negocio o el acceso de base de datos.

raspado de pantalla Este tipo de rectificación se centra en la conversión de las aplicaciones tradicionales de 5250 basadas en terminales las interfaces en la ventana basados en interfaces web o interfaces móviles basados. captura de imágenes por lo general funciona mediante la emulación de un usuario en el terminal. Mientras están 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 imágenes hace la intermediación. estas tecnologías están dirigidas a la lectura de la corriente de datos de 5250 y la modificación de lo que el usuario ve sobre la base de algunos contenidos fusionada que puede cambiar o controlar el diseño, el color, y mucho Más. Este es un gran acercamiento para aplicaciones en las que ya no tienen acceso a la código fuente.

Para los programas interactivos, también puede utilizar la OA para transformar su aplicación. El nivel en que actúa 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 búfer de E / S pueden ser procesados por nombre de campo o a través de una estructura de datos para cada formato. Esta oferta más flexibilidad y posibilidades sobre el control y las extensiones de su rectificación enfoque. Puede encontrar más información sobre la OA en la sección Open Access. Uso de la solución de OA le permitirá potencialmente controlar la interfaz de usuario de una manera más directa de su RPG existente código y aprobar nuevos datos directamente desde su nueva interfaz de usuario para el código RPG backend. Beneficios de la rectificación Al igual que con todos los enfoques de modernización, rectificación puede traer muchos beneficios a corto plazo, incluyendo:

inicio rápido Con este enfoque, se puede iniciar y terminar la modernización muy rápido. Usted no tiene que entender el código o cambiar la lógica de negocio. Esto puede ser muy útil cuando la búsqueda apoyo ejecutivo para los proyectos de modernización más detallados, como la refactorización completa.

Centrarse sólo en la interfaz de usuario Con refacing que no es necesario para entender el código subyacente de la aplicación. Si Use una solución de captura de imágenes, la aplicación original puede ser sólo un cuadro negro para usted. si vas con OA, sólo tendrá que cambiar la especificación de archivo de pantalla (una

Page 14: manual español  reingenieria.docx

palabra clave en el F-spec). Esto puede reducir el riesgo de romper las partes de la aplicación que usted no lo hace entender.

Comience a mover a otros enfoques de modernización Pronto se dará cuenta de que usted necesita para empezar a cambiar otros aspectos de la aplicación.Para hacer más fácil de mantener. El enfoque de la OA se abre muchas posibilidades para considerar cuando usted está listo para comenzar un esfuerzo de modernización integral. A menudo, OA puede ser un punto de inicio para un esfuerzo más amplio de modernización. Mostrar gran mejora rápidamente Riesgos Usted ha aprendido los beneficios del enfoque de rectificación, pero hay muchos riesgos asociados con este enfoque. Usted puede dar un "lavado de cara" a la aplicación y hacer que se vea moderna a los usuarios finales. No obstante, la aplicación sigue siendo el mismo inflexibles y difíciles de mantener pedazos de software. Desde un punto de vista del rendimiento, el rendimiento de la aplicación puede verse afectada, porque no fue diseñado originalmente con la nueva interfaz de usuario en mente. Para percibir beneficios reales, la Modernización de IU se debe acompañar con un rediseño del código subyacente, donde se puede optimizar en consecuencia. Refacing una aplicación no tiene en cuenta el diseño de la interfaz de usuario. El flujo y cómo un usuario podría querer interactuar con una interfaz desde el punto de vista móvil o web puede ser diferente a la forma en que la aplicación interactúa 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 podría ser un enfoque mucho más agradable. Entender el flujo de la interfaz de usuario y la interacción sería necesario que usted continúe por la camino a la modernización. También hay que tener en cuenta que la renovación es más probable que sea una solución temporal o táctico. Recuerde que debe aclarar esto con la gestión, ya que desde su punto de vista, se puede pensar que la aplicación se moderniza y que además no requiere.

2.2.4 Refactoring Refactoring es una variación de la reingeniería que reestructura una base de código, mejorando su estructura interna sin efectos adversos a su funcionalidad externa. Refactoring toma un "hacer daño "enfoque, es decir, entre otras cosas, que las aplicaciones que interactúan con el sistema modernizado no tendrá que ser cambiado en absoluto.

La filosofía de "no hacer daño" se garantiza mediante el uso extensivo de las pruebas a lo largo del proceso de modernización completa. Las pruebas deben ser diseñadas para automatizar tanto como posible. También debe asegurarse de que las pruebas cubren todos los aspectos de la aplicación.

Page 15: manual español  reingenieria.docx

Sin un conjunto completo de pruebas, los riesgos del aumento de la refactorización, 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 método de refactorización La refactorización es el enfoque preferido cuando sus metas de modernización incluyen:

Reducir los costes de mantenimiento El aumento de la claridad del código Revitalización de la aplicación y lo que le permite adaptarse mejor a las necesidades del

negocio Reducir el riesgo de afectar a los demás mediante la modernización de una aplicación Mantener la aplicación en la misma plataforma y el lenguaje como el original Aprovechando las habilidades existentes de su fuerza actual de programación Permitir flexibilidad interfaz de usuario, es más fácil para actualizar la lógica empresarial de la

aplicación para ser visitada por cualquiera de diferentes o múltiples tecnologías de interfaz de usuario Algunos refactorización es a menudo necesario independientemente del enfoque de modernización elegido. este libro describe un modelo de modernización que guía el proyecto de modernización. Algunos de los actividades descritas en este modelo están más relacionados con el enfoque de refactorización. usted debe evaluar si necesitará de su proyecto o no.

2.3 Cómo modernizar En esta sección se presentan los principios generales que deben tenerse en cuenta en cualquier esfuerzo de modernización, independientemente del enfoque elegido. También proporciona un modelo para guiarle a través de un proyecto de modernización. Siguiendo un modelo y un conjunto de reglas predefinidas va a ayudar a lograr un proceso de modernización maduro. Hemos de tener en cuenta que usted debe adaptar este modelo para satisfacer sus necesidades.

2.3.1 Introducción La modernización es un proceso de descubrimiento y usted tendrá que aprender mucho. Pero aún así, es importante seguir un modelo que puede guiar a su manera. Habrá más de una proyecto de modernización por delante, así que prepárate para grabar su viaje para que otros puedan repetir su éxito y evitar sus errores. Esta sección le ofrece un modelo que puede ayudar a entender lo que debe hacer para modernizar una aplicación. Hay algunos principios generales aplicables no sólo a este modelo sino a cualquier proceso personalizado que usted defina.

La modernización no está limitada a los lenguajes o plataformas específicas. 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 modernización. Estos principios y este modelo son aplicables no importa cuál sea su situación. 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 modernización y su situación específica y adaptarlos. Hay un montón de espacio para la mejora y la creatividad. Adoptar el modelo y mejorarlo cualquier forma en que usted necesita. Asegúrese 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.

Page 16: manual español  reingenieria.docx

2.3.2 Modelo de Modernización En esta sección se presenta el modelo de modernización que se propone en este libro. Usted será presentación a los principios que guían el modelo de modernización y un conjunto prescriptivo de fases que se pueden seguir para lograr sus objetivos de modernización. ¿Un modelo o una metodología? Antes de aprender sobre el modelo de modernización, es necesario tener una clara comprensión de lo que es un modelo y lo que es una metodología. A veces estos términos son erróneamente como sinónimos. Un modelo define un enfoque y un plan para hacer las cosas. El modelo define lo que hay que hacer, no cómo hacerlo. Por otro lado, una metodología define todas las actividades que hay que hacer para lograr cada paso de la modelo. Una metodología se puede considerar como la implementación de un modelo. Este libro define un modelo de modernización en lugar de una metodología. La modernización puede ser abordado de diferentes maneras y que podría ser difícil mantenerse al día con el ritmo de cada nuevo técnica, sino un modelo puede llevar mucho tiempo a la intemperie. Es su responsabilidad de adaptar este modelo a su situaciones específicas, teniendo en cuenta los principios, directrices y fases que cada esfuerzo de modernización debería tener.

El modelo La modernización de aplicaciones es mucho más que seguir los pasos y la ejecución de algunas actividades. lo implica un conjunto de principios que usted tiene que recordar el camino. La modernización modelo que se propone define este conjunto de principios y también un conjunto de fases para lograr su objetivos de modernización. Gráficamente, el modelo de modernización se representa en la figura 2-1. Como puede ver, el modelo define un ciclo de modernización iterativo que se repite tantas veces como sea necesario. cada iteración contribuye al objetivo principal: crear una aplicación moderna.

Después de cada iteración se debe detener y volver a evaluar la situación. Usted puede cambiar su enfoque de la modernización o de cualquier tecnología específica que haya seleccionado. El punto clave es que usted puede ver resultados pronto y usted puede parar tan pronto como sus metas de modernización sean alcanzadas. En la siguiente sección se verá la definición de las fases que componen el modelo:

Fase 0. Prepare Ofertas de esta fase con la planificación que se necesita para la iteración. Usted tiene que seleccionar la parte de la aplicación que se va a modernizar y definir cómo se va a medir su progreso. En cada iteración debe haber actividades de planificación para que pueda efectivamente

Page 17: manual español  reingenieria.docx

adaptarse a la situación inmediata. Fase 1. Experimentación

Usted tendrá que probar cosas nuevas en cada iteración. Usted tendrá que entender las tecnologías disponibles en el mercado y determinar si se ajustan a su situación. Esta fase es acerca de jugar.

Fase 2. Fuera de funcionamiento Esta fase se trata de hacer el verdadero trabajo y la aplicación de lo que experimente con el fin de alcanzar los objetivos de la iteración.

Fase 3. Evaluar y ampliar el pensamiento futuro Esta fase consiste en el análisis de la labor realizada hasta ahora, incluida la consideración de todas las anteriores iteraciones. En esta fase, se puede ver la forma de introducir las nuevas tecnologías para permitir una mayor flexibilidad en la aplicación modernizada. Esta fase está dedicada a analizar cómo ampliar la funcionalidad actual de la aplicación.

Fase 4. Implementación 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 sección proporciona algunos principios vitales que usted debe seguir durante la modernización proyecto. La aplicación de estos principios puede ayudar a usted, especialmente cuando se tiene que enfrentar a situaciones inesperadas específicas y tomar decisiones importantes. Proceso iterativo e incremental El proceso de modernización se puede considerar como un proceso iterativo e incremental. es iterativo ya que todo el proyecto se puede dividir en proyectos más pequeños que son más fáciles gestionar y más rápido para terminar. Es incremental pues con cada iteración final, se hace la aplicación más moderna, uno de los componentes a la vez. Esto también se llama un enfoque ágil. A veces las personas que participan en un proyecto de modernización tratan de seguir un enfoque "big-bang" y llegar a ser abrumado o frustrado. Así que recuerde a cada proyecto de modernización de dividir y conquistar. Mantenga la investigación y la lectura. Las cosas cambian. Lo que está la tecnología de punta de hoy puede ser obsoleto en cuestión de unos pocos meses. Para mantenerse moderna, hacer un hábito de leer y la investigación sobre la modernización teoría y tecnologías. 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 tecnologías de modernización. Recuerde siempre que la modernización no es algo que sólo se trata de. lo afecta a una gran cantidad de empresas, plataformas y lenguajes de programación. Encontrar tiempo para experimentar con tecnologías. Crear pruebas de concepto a aprender y probar la tecnología en su medio ambiente. Automatizar lo que pueda

Page 18: manual español  reingenieria.docx

De vez en cuando en un proyecto de modernización, que se encuentra haciendo la misma tarea una y otra vez. Piense en cómo se puede automatizar estos pasos. Siempre hay una mejor maneras de hacer las cosas. Busque herramientas de modernización 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 montón de diferentes enfoques de prueba que puede utilizar en su proyecto. Algunos de los más comunes son:

pruebas de regresión Este tipo de prueba se centra en la comparación de los resultados de una aplicación en contra de una línea 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 modernización y su comprensión del código no está completo.

pruebas unitarias automáticas Con las pruebas unitarias se puede probar una pequeña parte de la aplicación. A diferencia de las pruebas de regresión, la unidad de pruebas requieren una mayor comprensión del código que se está probando. Así que empezar a crear unidad automática pone a prueba lo antes posible. Las pruebas unitarias deben ser diseñados en un auto configurado .Así, lo que significa que usted no debería tener que configurar nada antes de ejecutarlos. además, las unidades deben ser capaces de ejecutar muy rápidamente. Puede que tenga que ejecutar después de cada compilación.

Todos estos enfoques pueden complementarse entre sí, por lo que hay que encontrar una manera de utilizarlos en su proyecto de modernización y automatización de ellos. Recuerde, usted debería ser capaz de ejecutar las pruebas muy rápido y muy a menudo. Es la única manera de sentirse más seguro al cambiar su código. Analizar masLa modernización es acerca de la experimentación. 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 código que se está modernizando causará sorpresas de vez en cuando, no importa cuánto usted lo analiza. Recuerda el carácter iterativo e incremental del proceso y planificar y analizar de la misma manera. Sea ágil Los proyectos de modernización tienen que ser ágiles, a fin de centrarse en evitar las actividades y documentación 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 rápido y con frecuencia. Recuerde que sus ejecutivos deben creer en el valor detrás de un proyecto de modernización, 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 más pequeño unidades posibles. El propósito es ser flexible y entregar pequeñas actualizaciones incrementales.

Foco en el software a través de la documentación Evite cualquier documentación que no agrega valor al proceso de modernización. buscar

Page 19: manual español  reingenieria.docx

documentación dinámico que puede mantenerse y volver a utilizar para diferentes propósitos fácilmente. Hay muchos sistemas de gestión de contenidos que pueden ayudarle a crear en colaboración y documentación dinámico. Utilizando una herramienta como un Wiki puede ser útil, ya que permite la comunidad de usuarios para contribuir al esfuerzo de documentación.

simplicidad es esencial Recuerde que debe mantener las cosas lo más simple posible. Resista la tentación de añadir características que podrían ser utilizados en el futuro, pero que no son necesarios en estos momentos. innecesario complejidad es una fuente de errores que pueden dañar el proceso.

Dar una atención continua a la excelencia técnica No hay que olvidar que la modernización se trata de mejorar. Centrarse en la aplicación de mejores prácticas y tecnologías. Conviértase en un defensor de la excelencia. Promover las mejores prácticas y transmitir su conocimiento. Usted debe ayudar a los demás a comprender la importancia de hacer cosas correctas.

La gente de negocios y los desarrolladores deben trabajar juntos Construir buenas líneas de comunicación entre los desarrolladores y expertos en negocios. la aplicación 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 más rápido y mejor que antes. moderno herramientas son recursos valiosos que pueden ayudar a realizar tareas increíbles. No deje que su actual herramientas que se detienen en el camino de modernización. Naturalmente, es más productiva con herramientas con las que están familiarizados. No se debe confundir esta ventaja de su familiaridad con la superioridad de las herramientas. Cambio de herramientas requerirá un período 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 aún más productivo que antes. También debe recordar que es vital para atraer nuevos talentos a la organización, y los nuevos desarrolladores se sientan cómodos con las herramientas que se asemejan a las herramientas que se han utilizado. "Pantalla verde" herramientas de desarrollo pueden dar la impresión de que está utilizando tecnología 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 más de código en un proyecto de modernización y usted debe prepararse en consecuencia. El objetivo principal de esta fase es prepararse para el esfuerzo de modernización por delante. Usted tendrá una visión clara y panorámica de lo que significa la aplicación 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 términos y tomar una decisión basada en los negocios. Un caso de negocios por lo general contiene las siguientes partes:

Page 20: manual español  reingenieria.docx

Planteamiento del problema Asegúrese de que esta parte se describen las insuficiencias, ineficiencias y debilidades de la aplicación actual. Armar números y cifras que explican la situación a la toma de decisiones y ayudarles a ver la importancia del proyecto de modernización.

Solución Esta es la descripción de alto nivel de la solución para el problema expuesto antes. debieras incluir: • Las tecnologías actuales del estado de la técnica • Una visión general de la solución propuesta • Una propuesta de costos y cronograma preliminar También puede incluir una breve descripción del modelo de modernización que va a guiar el proyecto.

Riesgos Usted debe hacer una evaluación honesta de los riesgos que podría tener que hacer frente. Esto le ayudará a prepararse antes de que situaciones inesperadas suceden. Además, un buen análisis de riesgo le ayudará a ganar credibilidad mediante la enumeración de las cosas que pueden afectar el alcance del proyecto.

Beneficios Asegúrese de especificar los beneficios del proyecto de modernización de una manera cuantificable, se recomienda incluir varios escenarios: - Escenario pesimista. En este escenario, debe especificar cuál será el mínimo beneficios del proyecto de modernización. Asegúrese de indicar cuáles son más probables riesgos a suceder y cómo usted está planeando para superar estas situaciones.- Escenario optimista. En este escenario, puede especificar cuál será la máxima beneficios del proyecto de modernización. Asegúrese de establecer beneficios cuantificables realistas. Evite exagerar. Esto puede afectar a su credibilidad si algo sale mal.

Métricas Se debe definir cómo se va a medir su progreso. Cada iteración debe ser evaluado en contra de estas medidas. Esto no es sólo algo que es importante para su gerente. También le ayudará a hacer ajustes a su plan.

Stakeholders Identificar todas las partes interesadas del proyecto. Asegúrese de incluir a todas las personas pertinentes, desde los desarrolladores a los usuarios de negocios. Tener aportaciones de todos los grupos de interés afectados asegurará que recuerde la importancia de la aplicación para su negocio.

Ejemplos Aquí es donde la prueba de concepto entra en juego. Si usted puede demostrar una pequeño 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 modernización. Sin ella, es dudoso que obtendrá la financiación 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 modernización puede verse obstaculizada incluso antes de cambiar una sola línea de código. Construir el equipo Los proyectos de modernización siempre involucran a varias personas. Es de vital importancia que se defina quién va a ser parte de su equipo en una etapa temprana. Además de los desarrolladores que harán el trabajo real, el equipo de modernización también se compone de personal no TI (por ejemplo, los usuarios). no subestimar sus contribuciones o compromiso con el proyecto.

Page 21: manual español  reingenieria.docx

Asegúrese de que usted define las siguientes funciones como mínimo: equipo dirigido Modernización

Esta persona será la encargada de dirigir el equipo. Asegúrese de que la persona que va que se asignará a este rol es un defensor de la modernización. Debe ser un pragmático ypersona de mente abierta que no tiene miedo del cambio y un apasionado de la continuamejora.

ingeniero de Modernización Los ingenieros de modernización son los encargados de aplicar el enfoque de la modernización de la aplicación. Asegúrese de elegir a las personas adecuadas para este papel y mantenerlos enfocados en los objetivos principales. Durante el proceso de modernización, es natural querer arreglar todo de inmediato. Los ingenieros deben tener en cuenta que la modernización es un proceso iterativo

experto lógica de negocios El experto de lógica de negocios por lo general es una persona no-IT. Pueden ser usuarios finales o alguien cuyos procesos de negocio se apoya en la aplicación. Esta función es esencial para la proyecto. Ellos le pueden dar una guía para entender las razones detrás de la específica funcionalidades de la aplicación.

aplicación personal de mantenimiento Esta es la persona que tiene experiencia de mantenimiento de la aplicación y la modificación se de acuerdo a los nuevos requerimientos. Este rol puede explicar la mayor parte del diseño y codificación decisiones que a veces son difíciles de entender.

Recuerde que debe hacer su mejor esfuerzo para mantener la cohesión del equipo y fomentar el trabajo en equipo. A veces el personal de mantenimiento de aplicaciones pueden sentirse amenazados por el proyecto de modernización. Asegúrese de convencerlos de la importancia y valor del proyecto. Desarrollar en plan de No trate de anticipar cada pequeño detalle. Recuerde que las cosas cambien más probable y definir un plan de trabajo de alto nivel del proyecto. A continuación, 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 iteración y las tareas necesarias para llevarlos a cabo. Asegúrese de que su plan incluye un entregable al final de la iteración. Elaborar normas y procesos Al principio se le experimentando mucho con el proceso de modernización, 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 modernización 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 estándares que usted y su equipo encuentre la mejora de las técnicas. 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.

Page 22: manual español  reingenieria.docx

2.3.5 Fase 1: Experimentación Esta fase es un buen momento para probar nuevas tecnologías. Dado que esta es una fase de experimentación, que se va a hacer un montón de pruebas. La mayor parte de las cosas que usted va a código 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é tecnologías son las mejores para su proyecto. La mejor manera de determinar esto es mediante la creación de una prueba de concepto (POC). Usted podría encontrar obstáculos y la necesidad de hacer algunos retrocesos, pero esto ayudará a que usted y sus compañeros de equipo ganen experiencia. Si usted está planeando para seleccionar una solución comercial, lo más probable es que usted va a necesitar su la aprobación del gerente. No confíe únicamente en las cifras de comercialización y gráficos. Muéstrales reales software de trabajo. Tome ventaja de los ensayos libres. Recuerde documentar lo que se aprende en esta fase. Asegúrese de involucrar a su grupo de interés en el POC. Ellos pueden proporcionar información valiosa para ayudar a asegurarse de que usted va en la dirección correcta. Puedes buscar proyectos más sencillos Mientras que usted está aprendiendo y acostumbrando al proceso de modernización, evitar la selección de la aplicación más compleja. No debe haber aplicaciones que son muy importantes para el negocio y no añadir riesgos innecesarios al proceso. Con todo el éxito, usted ganará más habilidades y la confianza que le permitirá modernizar aplicaciones más críticas y complejas

Experimento Está cambiando el código, 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 producción. Las ideas y experiencias que usted gana en esta actividad le ayudarán a trabajar mejor en la nueva aplicación y para entender el código subyacente. Revalorar Este proceso de experimentación todo va a ampliar su pensamiento. Muchas de las ideas que había van a cambiar. No tenga miedo de volver a evaluar su enfoque de modernización sí creo que hay una mejor manera de hacerlo. Definir los criterios de medición En esta fase, usted ganará más el conocimiento de la aplicación. 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 métricas de acuerdo con el enfoque de aplicación y modernización seleccionado.

2.3.6 Fase 2: Off and Running Esta fase se centra en hacer el trabajo real. Ahora que se tiene una vista panorámica de la disposición tecnologías y técnicas, puesta en la modernización de la aplicación. Recuerda el carácter iterativo e incremental del proceso de modernización, por lo que empezar a paso a paso de una manera que tenga sentido para su situación. Divida la aplicación en pequeñas unidades que se puede modernizar una a la vez, pero no perder la visión de conjunto de la aplicación. Mientras se encuentra en esta fase, tenga en cuenta las siguientes cosas: Construya su caja de arena

Page 23: manual español  reingenieria.docx

Muchos proyectos de modernización se ejecutan en paralelo con otros proyectos empresariales, por lo que es importante que construya una caja de arena que es específica para el proyecto, donde se puede estar seguro de que usted no afecta a la obra de otra persona y que a nadie más está afectando su trabajo. En el diseño y construcción de su recinto de seguridad, recuerde tener en cuenta los siguientes elementos: - Objetos -Data -Pruebas Objetos Copie todos los objetos de la aplicación 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 aplicación va a necesitar para funcionar en un entorno aislado. Para ayudarle a construir la caja de arena, crear los diagramas de estructura de la aplicación, que pueden ser generados con herramientas automatizadas. Datos Además de los objetos ejecutables, asegúrese de tener todas las tablas que interactúan con su aplicación. Se recomienda contar con los datos aislados para permitir que se hagan cambios sin que afecte a otros proyectos. Usted debe desarrollar un método de restauración 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 depuración de la cambios. Pruebas Usted necesitará un conjunto completo de pruebas para asegurarse de que su trabajo de modernización va en la dirección prevista. Su caja de arena debe contener un conjunto de pruebas que se pueden ejecutar varias veces y fácilmente. Sin pruebas, cualquier cambio puede ser fatal. En las primeras iteraciones, debe tener por lo menos un conjunto de pruebas de regresión. A medida que avanza el proyecto, su comprensión de la aplicación se incrementará, lo que le permite escribir pruebas unitarias específicas. Asegúrese de que el equipo de prueba cubre todas las partes de la aplicación que va a cambiar con el fin de garantizar el enfoque de "no hacer daño". Comprender la aplicación En cada proyecto de modernización, que debe tomar el tiempo para entender la aplicación que están tratando. El nivel de código de comprensión que se necesitan depende directamente de la enfoque de la modernización que se seleccione. Puede considerar las siguientes técnicas para la comprensión del código y aplicarlos a su situación en consecuencia:

Recopilar la documentación existente Es probable que no haya documentación de la solicitud original. Pero hacer lo mejor para recopilar todas las piezas de la documentación disponible. Algunos útiles poderío documentación incluir: • Implementación y configuración de notas • Historia de Incidentes • Los casos de prueba

Sesiones de lectura de códigos

Page 24: manual español  reingenieria.docx

La técnica más básica para entender el código es la lectura del código. Usted tendrá que leer el código que se está trabajando con su equipo y buscar el código repetido y lógica. Inicialmente, la lectura del código no parece ser útil, pero después de que usted se familiarice con él, Las cosas se vuelven más claras. Pregunte a los expertos acerca de la funcionalidad del negocio que se implementa en el código y mantenga esto en mente al leer el código. A veces será más fácil de entender los procesos de negocio subyacente que el código que implementa.

Sesiones de depuración Depuración de la aplicación con pruebas específicas puede ayudar a entender la aplicación y cómo funciona cada módulo. Recuerde que el uso de herramientas modernas, como IBM Rational Developer para i, hará las sesiones de depuración más productiva.

Análisis estático Este es el análisis del código fuente o el objeto compilado sin ejecutarla. En general el resultado del análisis estático es: - Utilizar herramientas de análisis de código Hay varios proveedores de herramientas que se han especializado de herramientas para revisar y ayudar a analizar sus programas monolíticos. El Rational Power Pack ARCAD proporciona la Herramienta Observador que le ayudará a analizar el código. - Extracción de reglas de negocio Las reglas de negocio se refieren a la lógica de negocio que está incrustado en el código. Muchas de las herramientas ayudarle a extraer este tipo de datos a partir del código, lo que puede ayudar a entender la funcionalidad que se implementa en el programa.

- El análisis de dependencia entre los componentes Esto se refiere a la identificación de las relaciones entre los módulos de la aplicación. El diagrama que se genera puede ayudarle a entender cómo un componente se integra con toda la aplicación. - Esquema de la estructura interna La mayoría de las aplicaciones heredadas son monolíticas, programas grandes. Con el fin de comprender fácilmente 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 métricas Métricas de complejidad y el mantenimiento pueden ayudar a diagnosticar la sección de código en el que está trabajando y medir su progreso. También pueden ayudar a estimar el cantidad de trabajo necesaria para la modernización. Estos tipos de análisis se realizan más fácilmente a través del uso de herramientas automatizadas. Más adelante en este libro, usted encontrará más información.

Análisis dinámico Este tipo de análisis se realiza mediante el trazado de la ejecución de los programas en un medio ambiente específico. Hay muchos usos de los resultados del análisis dinámico incluyendo: - La cobertura de código Las aplicaciones tradicionales suelen contener "código muerto". Este es el código que no se ejecuta pero todavía está en el programa. Para identificar el código que ya no es necesario, puede utilizar una herramienta de eso ayuda a calcular cómo se cubría gran parte del código con un conjunto de transacciones y cómo mucho código es posiblemente muerto. - Diagramas de llamadas dinámicas

Page 25: manual español  reingenieria.docx

La mejor manera de entender cómo funciona el programa es el seguimiento de su comportamiento mientras corre. Herramientas de análisis dinámicos suelen proporcionar datos que representa el flujo de ejecución de un programa, subprogramas y sub procedimientos. Para ser eficaz, el análisis dinámico requiere de un buen conjunto de pruebas para producir un interesante resultado. Modernizar Cuando está preparada su caja de arena y tiene una mejor comprensión de la aplicación, puede empezar a hacer trabajos de modernización. Algunas de las tareas comunes que se pueden hacer en esta etapa Incluye:

Limpieza del código Limpieza de código es la eliminación de los elementos que hacen que el código sea difícil de entender. Algunos de las cosas que se deben considerar al limpiar su código incluyen: - La eliminación de código duplicado - La conversión a una forma más legible. En el contexto de la RPG, esto significa la conversión a formato libre - La eliminación de las variables y los procedimientos utilizados

Reestructuración del código Después de limpiar el código, se puede comenzar a extraer la lógica de negocio relacionada con el servicio de programas que pueden ser reutilizados en diferentes partes de la aplicación. Hay varias buenas herramientas disponibles aquí para ayudar a identificar y reestructurar el código. Algunas de las tareas que puede hacer en esta etapa incluyen:

- Extracción de una lógica similar en componentes reutilizables - La encapsulación de variables globales - Conversión de subrutinas para procedimientos - Cambiar el nombre de las variables y los procedimientos sub a los nombres más significativos - Escritura de código auto-documentado

Reempaque Cada módulo sólo debe contener los procedimientos sub funcionalmente relacionados y todos los servicios del programa debe contener módulos sólo relacionados funcionalmente. Va a tener que empezar a separar módulos monolíticos y organizar los procedimientos en los nuevos módulos. Asimismo, recuerda que cada módulo debe tener una responsabilidad.

Modernizar la base de datos Modernización de base de datos es un modelo de modernización completa por sí misma. Más adelante en este libro, usted encontrará una metodología que le guiará sobre cómo hacer esta modernización.

Prueba Después de la modernización de la aplicación, asegúrese de que todas las pruebas se realizan sin éxito. Si las pruebas no tienen éxito, no debe continuar en el proceso de modernización. Debe asegurarse de que todo está funcionando como antes y que usted no está rompiendo las funcionalidades existentes.

2.3.7 Fase 3: Evaluación y ampliar el pensamiento futuro El objetivo principal de esta fase es el de maximizar algunos de los beneficios de la situación actual de las últimas tecnologías aplicadas a la aplicación.

Page 26: manual español  reingenieria.docx

Usted ha preparado su medio ambiente y que ha modernizado la aplicación. Ahora es el momento para evaluar el progreso de su trabajo. Si esta evaluación indica que debe dar un paso atrás en el proceso, no se preocupe. Puede que tenga que hacer esto varias veces. Si la evaluación indica que usted ha logrado sus objetivos, es el momento de empezar a ampliar el valor de la aplicación y prepararla para el futuro. Algunas de las actividades que se pueden hacer en esta fase son: Medida Es necesario evaluar si se están logrando los objetivos de modernización. Si su objetivo principal es reducir la complejidad, este paso debe reflejar una reducción 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 medición debe indicar los ajustes que se deben hacer al proyecto. Mejorar la arquitectura Ahora usted puede tener en cuenta la optimización de la arquitectura de la aplicación. Es posible que desee comenzar separar la aplicación en capas o niveles y para incluir componentes adicionales tales como una nueva capa de sustitución de IU. Este paso se centra en la aplicación como un todo. Integrar Uno de los objetivos de modernización comunes es la de integrar la aplicación en una empresa arquitectura. A menudo, es necesario para permitir la aplicación de SOA o para que sea más flexible para otras tecnologías de integración empresarial.

Traer nuevas tecnologías Si hay alguna nueva tecnología que puede ayudar a mejorar la aplicación, puede incluirla en este paso. Recuerde que debe analizar con cuidado para evitar que se convierta en un obstáculo futuro. Siempre apunte para herramientas estándar, tecnologías 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 tecnologías pueden llegar a ser obsoletos muy rápido, por lo que los envuelven en una manera que le ayuda a reemplazar fácilmente si es necesario.

2.3.8 Fase 4: Implementación 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 iteración, 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 modernización. Los siguientes pasos le pueden guiar en esta fase: Documentar la aplicación Es probable que la nueva aplicación sea diferente que la anterior. Usted tendrá que crear documentación efectiva que explica la nueva aplicación a las personas que hacen el mantenimiento y los usuarios y los grupos de interés 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 aplicación. La mayoría de los tipos de Modelado Unificado Language (UML) están diseñados para lenguajes orientados a objetos, pero se puede adaptar fácilmente a su situación. La ventaja de usar un tipo estándar de diagrama es que muchos de la gente será capaz de comprender con facilidad y que se parecen más profesional.

Page 27: manual español  reingenieria.docx

Recuerde que su documentación se debe aportar un valor añadido. Así que evita la documentación que irá directamente a la plataforma. El uso de sistemas de gestión de contenidos (por ejemplo, MediaWiki, WordPress, Joomla, etc) pueden ayudarle a crear documentación sencilla y colaborativa. Tenga en cuenta que la documentación debe ser de fácil mantenimiento. Hay muchas herramientas que puede generar documentación a partir del código o de los objetos compilados. Utilizarlos (o crear ellos) si es posible. Capacitar a las personas Dependiendo del enfoque de modernización, puede que tenga que formar a los usuarios, la aplicación el personal de mantenimiento, o en ambos. La documentación que generó previamente se debe utilizar como la referencia principal para los aprendices. Asegúrese de que esta documentación se puede acceder fácilmente y que contiene toda la la información necesaria para los usuarios como para los expertos en TI. Si la nueva aplicación es más difícil de entender que el original, esto es una buena indicación que el plan de modernización de las necesidades se mejora. Evaluar el nuevo sistema desde diferentes puntos de vista. Definir la estrategia de implementación Al igual que hay muchos enfoques de modernización, hay más de una manera de implementar la nueva aplicación. Asegúrese de que ambos enfoques están alineados. Algunos de las más comunes técnicas de implementación incluyen:

Enfoque Big-Bang Este enfoque para el despliegue reemplaza toda la aplicación de una sola vez. Esto por lo general se utiliza con proyectos de modernización que necesitan resolver un problema inmediato que afecta servicios críticos. 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 aplicación y la nueva aplicación en paralelo. La cuestión es que los cambios en el nuevo sistema debería reflejarse en el viejo y viceversa. Esto puede causar una gran cantidad de trabajo y esfuerzo.

Enfoque incremental También conocido como "Salida por etapas", en este enfoque, las secciones de la aplicación son rediseñado y añadió de forma incremental, lo que le permite ofrecer resultados e identificar errores más rápidamente. Cuando se sigue este enfoque, sólo se puede cambiar un componente a la vez sin tener en cuenta la aplicación en su conjunto. Ante este hecho, el proceso de modernización podría tomar más tiempo para terminar por completo

Enfoque evolutivo Al igual que el enfoque incremental, el enfoque evolutivo reemplaza las secciones de la aplicación original con partes modernizadas. La diferencia es que, en este enfoque, para reemplazar secciones se seleccionan basándose en su funcionalidad y no la estructura de la aplicación. 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 comparación de los tres.

Page 28: manual español  reingenieria.docx

2.3.9 Repita según sea necesario Después de terminar el proceso, tendrá que volver atrás y repetir el proceso tantas veces según sea necesario. En cada iteración, un nuevo componente se modernizará y usted estará más cerca de sus metas. No todas las fases requieren la misma cantidad de esfuerzo en cada iteración. Al principio, usted probablemente tendrá que invertir más esfuerzo en las fases de preparación y experimentación. Sin embargo, a medida que avanza el proyecto, estas fases serán más cortos. En otras palabras, usted verá cómo se adaptan las fases durante las iteraciones sucesivas. Recuerde que debe evaluar su progreso en cada iteración y ajustar la ruta en consecuencia. Al ir a través de todas las fases, tenga en cuenta que debe adherirse a los principios de modernización y ajustar el proceso a su situación.

Las técnicas modernas de arquitectura de aplicaciones

Este capítulo presenta las técnicas de la arquitectura de aplicaciones que pueden ayudar a diseñar y construir aplicaciones modernas.

3.1 Introducción ¿Qué es una aplicación moderna? ¿Cómo se puede definir un diseño moderno? Dado el ritmo de cambios en la tecnología, el término moderno puede ser difícil de definir. Cada día las nuevas tecnologías se construyeron, los patrones se han diseñado y se refinan las prácticas

Page 29: manual español  reingenieria.docx

recomendadas o completamente cambiado. Dada la naturaleza dinámica de desarrollo de software, es más fácil de entender lo que es un mal diseño. Un mal diseño exhibe muchas características que desea evitar en el software que se construir. En este capítulo, aprenderá algunas de las características de lo que contribuye a un mal diseño y algunas técnicas de diseño que se pueden utilizar para evitarlos.

3.1.1 Los síntomas de un mal diseño En la primera versión de una aplicación, los programadores tienen una visión clara de lo que el software es y cómo se construye. Si tienen que hacer un cambio, es probable que sea fácil para ellos dada su familiaridad con el código. A medida que el tiempo pasa y varios programadores empezar a hacer cambios, las nuevas adiciones y actualizaciones, la aplicación 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 difícil de evitar, pero usted debe centrarse en la creación de un buen diseño que es más difícil de romper con el tiempo. Si su aplicación presenta alguno de los siguientes síntomas, es probable que se enfrente el mal diseño: Rigidez La aplicación es difícil de cambiar porque un solo cambio puede desencadenar una cascada de múltiples cambios. Con diseños rígidos, lo que parece ser un simple cambio puede convertir a un proyecto complejo que es difícil de estimar. Los más módulos afectados por un cambio, el más rígido el diseño. Fragilidad Los cambios hacen que el sistema de romper en muchos lugares cuando se realiza un único cambio. Estos partes tienen ninguna relación conceptual con el área que se ha cambiado. La fijación de un problema puede causar nuevos problemas y así sucesivamente. Inmovilidad Un diseño es inmóvil cuando contiene piezas que puedan ser reutilizables, pero el esfuerzo de separarlos del sistema original son demasiado grandes. La aplicación está demasiado enredada para reutilizar partes de ella.

Viscosidad Cuando usted está haciendo un cambio en una aplicación, usted tiene dos opciones: la preservación del diseño o "hack" y romper el diseño. Viscosidad hace más difícil seguir el diseño preservar método. Con el tiempo, los desarrolladores tienden a empezar a hacer "hacks" con más frecuencia para la aplicación debido a la falta de comprensión y la presión del tiempo.

La complejidad innecesaria El diseño de software es esencialmente un proceso creativo. Pero a veces, un diseño 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 añadir beneficio.

Repetición innecesariaEl diseño 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 codificación, esto puede llevar redundantes código que hace que sea difícil de hacer cambios y errores cuando corrige. Opacidad El diseño y el código es difícil de leer y entender. No expresa su propósito adecuadamente. En las siguientes secciones, aprenderá técnicas que pueden ayudar a crear diseños modernos que tratan

Page 30: manual español  reingenieria.docx

de evitar estos problemas. Cuando lea estas secciones, tenga en cuenta el mal diseño síntomas descritos aquí y descubre cómo estas prácticas recomendadas pueden ayudarle a evitarlos.

3.2 La modularización ¿Alguna vez ha tenido que lidiar con un programa monolítico grande? Muchas aplicaciones antiguas tradicionales son programas monolíticos que se componen de un solo módulo. En este único módulo grande, a menudo se puede encontrar el código para manejar la pantalla, las interacciones del usuario, la lógica de negocio, y el acceso a la base de datos. No hay sentido de la separación. El mantenimiento de los programas monolíticos no es tarea fácil. Dado su tamaño y complejidad, programadores se enfrentan a muchos obstáculos. A menudo se necesita la ayuda del autor original del programa para entenderlo (suponiendo que el autor original es todavía 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 modernización de sus aplicaciones. Programas monolíticos deben modernizarse pero en paralelo a un proyecto global de modernización. Debe asegurarse de que las nuevas aplicaciones no están diseñadas con este enfoque. La modularización es la clave para el diseño de fácil-a-mantener aplicaciones. La modularidad se puede definir como una cantidad de componentes dentro de una aplicación que está separada y recombinado. La modularización es una técnica de software que se centra en la separación de la funcionalidad de un programa en módulos reutilizables más pequeñas que contiene sólo una función que es a continuación, se utiliza a lo largo de toda la aplicación. Con el fin de lograr un buen diseño modular, lo que tienes que empezar a pensar en la separación funcionalidades y la aplicación de una sola función por módulo. Si un módulo de hace muchos funciones no relacionadas, se deben reconsiderar su diseño.

3.2.1 ¿Por qué la modularización es importanteLa modularización trae muchos beneficios a la aplicación y sus programadores. En esta sección, aprenderás algunos de los principales beneficios que ofrece la modularización. Más fácil de cambio Usted probablemente ya sabe que las aplicaciones cambian. El negocio es una entidad dinámica y así son las aplicaciones que lo soportan. La modularización mejora la dificultad, el costo y el tiempo para hacer cambios. Con las aplicaciones monolíticas, incluso un simple cambio puede convertirse en una ardua tarea que requiere más esfuerzo y el riesgo de lo esperado. ¿Cómo la modularización hace cambios más fáciles de hacer? Imagine una aplicación monolítica enorme donde todas las funcionalidades están en el mismo módulo. La empresa necesita un pequeño cambio en la lógica incrustado en el código. Usted no está familiarizado con toda la aplicación y el tiempo esta en contra de usted. Este escenario no estamuy lejos de la realidad. Cuando los programadores se enfrentan a esta situación, no tienen el tiempo para entender todo el código mixto y hacer el cambio usando malas técnicas como el "copy-paste". El riesgo aumenta y el código se convierte en un lío más grande que antes. Consideremos ahora el otro escenario. Usted tiene que hacer el mismo cambio pequeño, pero en un bien diseñado aplicación modular. Si genera un esquema de la aplicación, verá cómo se estructura la aplicación. Ahora usted puede entender cuáles son los módulos que tiene que cambiar. Usted no tiene que pasar por miles de líneas de código que no estaban relacionados con su cambio. La modularización hace que sea más fácil de entender toda la aplicación y se centran sólo en las partes que le interesan.

Page 31: manual español  reingenieria.docx

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 aplicación monolítica, 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 módulo que se ocupa del acceso a la base de datos y ya está. Más fácil de entender Cuando usted está tratando de entender un programa monolítico, hay que ver todo a la vez. El componente más pequeño es toda la aplicación. No es muy fácil centrarse en la lógica de la interfaz de usuario o el acceso a la base de datos por separado. Dada la ausencia de capas y la separación, que se ven obligados comprender todos los aspectos de la aplicación incluso si usted está interesado sólo en una parte específica. En una aplicación modular, usted puede comenzar a aprender las diferentes partes del código y haciendo caso omiso de la descansar. Por ejemplo, usted puede centrarse en la comprensión de cómo una parte específica de la lógica de negocio funciona, sin tener que entrar en la interfaz de usuario o los datos de acceso. Esta facilidad en la comprensión le beneficiará principalmente en las siguientes áreas:

Nueva formación del talento Menos tiempo y costos para capacitar a gente nueva en la aplicación. Es más fácil de explicar pequeña piezas una a la vez que una aplicación monolítica conjunto.

Los proyectos de modernización Estos proyectos requieren de personal que entienda la solicitud original antes de que seamodernizado. Comprensión de código es una tarea ardua que se pueden aliviar con un sistema modular diseño.

ubicación Error y la fijación de Búsqueda de errores en aplicaciones monolíticas puede ser difícil. Un diseño modular puede ayudarle a aislar los errores más fácil y más rápido. Más fácil de probar Desde una perspectiva de pruebas, es más fácil para probar aplicaciones modulares. Similar a la proceso de comprensión, puede centrarse en un módulo en particular y escribir pruebas unitarias para ello. unidad de pruebas son recursos valiosos para validar su código. Ellos le permiten escribir las pruebas para concretas secciones de código que puede ser difícil de alcanzar. Las pruebas unitarias deben ser complementados con la integración y las pruebas de funcionamiento, pero en aplicaciones monolíticas, que no tienen esta opción. En términos de diseño de prueba, aplicaciones monolíticas tienden a tener una mayor complejidad, lo que hace más difíciles de probar. Esta dificultad en las pruebas pueden conducir a importantes sectores no están siendo probadas correctamente y de riesgo adicional para los errores en el futuro.Reutilización Las grandes piezas de software son más difíciles de reutilizar. La modularización tiene como objetivo crear la aplicación como una composición de piezas pequeñas. Con un buen diseño, es más fácil de reutilizar estas piezas en diferentes partes de la aplicación.

3.2.2 Principios generales Ustedes han aprendido lo que la modularización es y por qué es importante, pero ahora vas a aprender los principios más importantes que usted necesita para tener en cuenta a la hora de definir cómo modularizar.

Page 32: manual español  reingenieria.docx

La división de la aplicación en partes más pequeñas es esencial en el camino hacia la modernización, pero a veces, la parte difícil es saber qué incluir en cada pieza. En esta sección se abordará este punto. Tenga en cuenta las siguientes pautas en el diseño de una aplicación modular: Responsabilidad individual Este principio establece que todos los módulos de una aplicación debe tener una responsabilidad. La responsabilidad puede ser entendida como una razón para cambiar. Por ejemplo, considere un módulo que recupera los datos de una tabla y también genera un informe basado en los datos. Si un cambio que es relacionado con la recuperación de datos se debe hacer, todo el módulo tiene que cambiar. Pero si un cambio que se debe hacer con el informe, el mismo módulo tiene que cambiar. Ergo, el módulo tiene dos razones no relacionadas con el cambio. La forma correcta es la creación de dos módulos, uno centrado en la recuperación de datos y otro centrado en la generación del informe. Cuando un módulo tiene más de una responsabilidad, es más fácil para causar daños colaterales: usted se acaba de cambiar el informe, pero, sin usted saberlo, la funcionalidad de recuperación de datos también fue afectados. Alta cohesión La cohesión es el grado en el que los elementos de un módulo van de la mano. Es el funcional la relación de los elementos dentro de un módulo. Puede detectar baja cohesión cuando un módulo tiene más de una responsabilidad. También, bajo la cohesión se puede ver cuando común las competencias están repartidas en diferentes módulos, no relacionados. Debe diseñar componentes con la cohesión. Esto hará que sean más robustos y más fáciles de reutilizar. Todo lo que tienes que hacer es poner la funcionalidad relacionada en el mismo módulo y asegúrese de que cambios futuros toman esto en consideración. Acoplamiento débil El acoplamiento puede ser definido como el grado en que cada módulo se basa en otros módulos. Es una medida de la fuerza de la asociación establecida por una conexión de un módulo a otro. Acoplamiento apretado hace que un programa sea más difícil de entender, cambio, o correcta por sí mismo. El cambio en un módulo genera una gran cantidad de cambios en los módulos relacionados. Es como dominó piezas cayendo en secuencia. El logro de un diseño sin acoplamiento es muy duro y no es práctico, pero usted debe tratar de centrarse en el diseño con bajo acoplamiento en mente. Acoplamiento débil se puede lograr mediante la alta creación de módulos de cohesión que se comunican con otros a través de una interfaz bien definida, ocultando su implementación interna. En otras palabras, los módulos deben ocultar sus variables globales, formato de datos y cualquier otro tipo de detalles de la implementación de otros módulos. Los módulos son llamados y funcionan dentro del módulo efectúa sólo cuando los datos pasan a la interfaz definida. Empacar juntos solo módulos relacionados Al preparar sus módulos (programas de servicio en el contexto ILE), recuerde sólo para empacar módulos relacionados entre sí. Esto puede ser pensado como el principio de alta cohesión, pero al nivel de paquete. ¿Por qué es importante diseñar paquetes con este enfoque? Si empaca módulos sin relación juntos, se genera una gran cantidad de dependencias para el paquete de diferentes aplicaciones. Un cambio de un módulo requerirá la modificación de todo el paquete, lo que aumenta los riesgos de dañar otras aplicaciones. Convención 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 convención de nomenclatura auto-documentado que ayuda identificar rápidamente la única funcionalidad de un módulo. Esto ayudará a los demás

Page 33: manual español  reingenieria.docx

a mantener el orden y el estilo de toda la aplicación. Buenas convenciones de nombres también hacen herramientas como UML diagramas más útil.

3.3 Diseño por niveles Dos de los principales objetivos de la arquitectura moderna de aplicación son para maximizar reutilización código y reducir al mínimo el impacto del cambio y los gastos generales de mantenimiento. A través de los años, ha habido un número 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 cuál de estas arquitecturas se selecciona, todos comparten una característica común. Ellos tratan de separar la aplicación en niveles distintos. Por ejemplo, un diseño de tres niveles separa la presentación, la lógica y las capas de datos.

Las interfaces de nivel de presentación con el usuario. Esto podría ser una interfaz 5250 de estilo, una red interfaz o una interfaz móvil.

El nivel de lógica coordina el movimiento y transformación de datos entre la presentación y capas de datos. Procesos consisten en todas las decisiones y cálculos que deben estar hechos. Aquí es donde toda la lógica 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 lógica. Cada nivel es una entidad en sí misma y no tiene conocimiento de los contenidos y las metodologías de los otros niveles. Hay interfaces publicadas que permiten la comunicación entre niveles. En teoría, cualquier nivel puede ser cambiado o reemplazado sin afectar a ninguno de los otros niveles de la aplicación. Suponiendo que la capa de presentación actual es una interfaz tradicional 5250-estilo, el concepto de un diseño escalonado significa que una nueva capa de presentación (por ejemplo, una interfaz web o un Interfaz móvil) podría introducirse sin tener que realizar ningún cambio en la lógica o los datos capas. Aunque en este ejemplo está en un nivel de aplicación, el principio se puede llevar hacia abajo en cada uno de los niveles que pueden estar a su vez por niveles. Este principio llevaría hasta el nivel de programación, donde se utiliza la encapsulación para implementar un diseño escalonado en el código. La aplicación de un diseño escalonado asegura que el cambio o la adición de un nivel (en la aplicación o nivel de programa) no tienen efecto en los demás niveles. Por lo tanto, los principales objetivos de maximizando la reutilización del código 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 programación, y los marcos que se están utilizando. Cualquiera se está utilizando la arquitectura, todos ellos tienen como objetivo lograr los mismos principios niveles. Una serie de artículos en iProdeveloper demostró la implementación de un diseño escalonado utilizando un enfoque MVC.

En el artículo "Pattern Recognition: Facilidad Moderna RPG Programación", Scott Klement demostrado una metodología 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 módulo en un

Page 34: manual español  reingenieria.docx

programa de servicio: el programa de servicio es un nivel de datos. Usted puede leer el artículo en la siguiente link: http://iprodeveloper.com/rpg-programming/pattern-recognition-ease-modern-rpg-programming

En el siguiente artículo, "Reconocimiento de Patrones: La adopción de El Patrón", Paul Tuohy demostró cómo se utilizó el mismo nivel de datos con una interfaz web escrito en CGIDEV2. Usted puede leer el artículo en el siguiente enlace: http://iprodeveloper.com/rpg-programming/pattern-recognition-adopting-pattern

Por último, en el artículo "Reconocimiento de Patrones: La prestación de mantenimiento", Paul Tuohy mostró cómo el nivel de datos podría ser re-escrito sin afectar a cualquiera de las dos capas de presentación (5250 o web). Usted puede leer el artículo en el siguiente enlace: http://iprodeveloper.com/application-development/pattern-recognition-maintenance-benefit El enfoque por niveles, en todos los niveles dentro de una aplicación, proporciona la mayor flexibilidad en términos del mantenimiento y el potencial para un cambio rápido.

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 lógica de negocio para su organización. 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 más 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 podrían también regir estas transacciones. Por ejemplo, los atributos de los clientes pueden dictar la prioridad para trabajar. También tendrán que ser traída, creado y modificado (también parte del modelo) de datos. Como se puede imaginar, un modelo de objetos de negocio se realiza generalmente en términos no-programadores puede entender. Es la perspectiva empresarial del problema o de la solución. Como tal, la creación y revisión del modelo pueden afectar a cualquier grupo de personas técnicas o no técnicas de su organización.

3.4.1 Implementación 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 diseño orientado a objetos. Pero, ¿cómo lo hace traducir en su solución 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

Page 35: manual español  reingenieria.docx

tiene atributos que se pueden recuperar o cambiar según 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 lógica 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 abstracción para que los objetos de negocio no sea necesario que entienda la complejidad del backend. Ese avanzado conocimiento (por ejemplo, el formato específico 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 aún más encapsulados en un objeto de transferencia de datos (DTO), que contiene los datos de interés (clientes electrónicos) y nada más. Ahora volvamos a nuestro ejemplo anterior. Cuando un cliente llama para reportar un problema, el cliente representante de servicio puede necesitar buscar la dirección del cliente. El representante (ser un "actor" en el proceso y, por tanto, un objeto de negocio) pedirá a la DAO para este información. El DAO entiende la complejidad del backend, obtiene los datos y devuelve un DTO que contiene la dirección del cliente. Por supuesto, la aplicación de la vida real de código basado en el modelo de objetos de negocios rara vez es tan perfecta como la descripción 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 diseño. Independientemente, el modelo todavía se puede utilizar para ayudar a particionar el diseño en objetos de negocio relevantes y mantener una lógica y significativa de separación de trabajo.

3.4.2 Ventajas Como puede ver, el uso de un modelo de objetos de negocio ayudará a la solución que sigue muchos de las prácticas preferidas que se describen en este capítulo. Por ejemplo, el modelo tiende a hacer cumplir una fuerte noción de modularización, ya que cada BO, DTO, y DAO contiene la información que necesita para completar sus propias tareas necesarias. Además, cada objeto no necesita contener detallado el conocimiento acerca de las tareas realizadas por otros objetos (solo responsabilidad). En un buen diseño, partes del modelo pueden ser reemplazados o modificados sin afectar el resto de la solución (acoplamiento débil). Esto da como resultado código que es más fácil de mantener, reutilizable y flexible. Además, el modelado con objetos de negocio le permite identificar rápidamente las dependencias al hacer un cambio. En nuestro ejemplo, si el DTO recupera la dirección de un cliente, otros objetos podrían ser afectados? Del mismo modo, puede ayudar a identificar el rendimiento sensible de los módulos dentro de la solución. 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 círculos. Como tal, casi cualquier persona puede contribuir a la modelo al identificar interacciones, asociaciones, y las reglas para el modelo. Tal vez lo más importante, este enfoque obliga al arquitecto de software para mantener una perspectiva a nivel de negocio en el problema. Después de todo, cuando el diseño de un componente de software, es esencial comprender cómo encaja en el cuadro grande. Este entendimiento es seguro que resultará en una solución de software mejor.

3.5 Los datos de programación centrada Antes de introducir el concepto de la programación centrada en los datos, es necesario comprender el enfoque tradicional para el desarrollo de aplicaciones en el IBM i: la programación centrada en el programa.

Page 36: manual español  reingenieria.docx

Con este enfoque, el programa tiene las siguientes responsabilidades: De acceso a datos

Determine los archivos necesarios y el método de acceso de datos, por lo general el nivel de acceso al registro (RLA) para recuperar datos de una fila a la vez. Además, el programa en sí mismo determina la relación entre los archivos, haciendo que el sistema de gestión de base de datos (DBMS) de poco ayuda.

Lógica de negocios El programa cuenta con todas las reglas de negocio embebidas en el código (ya sea directamente o a través de un miembro de la copia). La lógica 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 monolíticas pueden considerarse como centrada en el programa, pero también 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 aplicación que está diseñado usando un enfoque centrado en el programa.

Como se puede notar, el enfoque centrado en el programa tiene muchas desventajas, incluyendo:

Page 37: manual español  reingenieria.docx

La aplicación 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 través 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 aplicación tiene que ser recompilado si un archivo cambia normalización de bases de datos puede ser inexistente. integridad referencial está implícita

Por otro lado, la programación centrada en datos se puede entender como la estrategia para resolver problemas de negocio mediante el aprovechamiento de las características de los DBMS. Este enfoque propone implementar más lógica de negocio en la base de datos y la separación de la lógica de negocio de programas de aplicaciones de alto nivel. La figura 3-2, se muestra la estructura básica de una centrada en los datos programa.

Page 38: manual español  reingenieria.docx

Programación centrada en los datos tiene como objetivo aprovechar los DBMS, específicamente con los siguientes artículos:

Optimizar el acceso a los datos La aplicación solicita datos a través 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 más eficiente.

El uso de restricciones Con el uso de restricciones, puede mover las reglas de negocio de las aplicaciones a la DBMS Normalización Con el uso de los DBMS, es más fácil mantener la normalización 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 automáticamente 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 aproximación centrada en los datos son los siguientes:

Conduzca tanto trabajo hacia abajo en el sistema de gestión 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 sólo 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 tecnologías y mejoras en DBMS, tales como el nuevo optimizador (SQE)

Cuanto más cerca de su diseño se ajusta a los objetivos centrados en datos anteriores, cuanto más se puede aprovechar tecnología de avanzada. En la Figura 3-3, se puede ver una comparación entre céntrica programa y los enfoques centrados en datos.

Page 39: manual español  reingenieria.docx

3.5.1 Mover a centrada en los datos de programación 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 generación automática 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 añadir 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 identificación del departamento; esta norma se destaca y se aplica para todas las interfaces. Los factores desencadenantes son un complemento excepcional

Page 40: manual español  reingenieria.docx

Hay una lógica de negocio que se puede implementar con disparadores. Definición de un disparador es una técnica 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. Imagínese si usted desea validar el estado de crédito de un cliente antes de aceptar un pedido. Esta validación 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 información sobre el orden y el cliente. Inmediatamente, un correo electrónico es enviado automáticamente.

SQL es la base SQL es la base de la programación centrada en los datos. En este tipo de programación, SQL funciona de manera eficiente en el procesamiento de grandes conjuntos de datos. Todos los objetos de la base de datos son más eficaces cuando se crean con SQL. Usted debe considerar la creación de todos los objetos con SQL porque esto puede mejorar el acceso a los datos y el rendimiento de las aplicaciones.

3.6 Servicio Orientación La figura 3-5 muestra la evolución de las aplicaciones. Al principio, las solicitudes tenían todo el código para todas las funciones en el mismo lugar. El mantenimiento de estas aplicaciones es muy difícil, debido a la cantidad de código y las funcionalidades en los programas.

Después de eso, se consideraron las aplicaciones distribuidas. Estas aplicaciones tienen una parte de código en el lado del servidor y otra en el lado cliente. Este período 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 diseño y una buena capacidad o la aplicación podría salir fácilmente de los problemas de sincronización y la causa. Después de las aplicaciones cliente / servidor, los programadores desarrollaron aplicaciones mediante el uso de diferentes tecnologías. Algunas de estas tecnologías son RMI / IIOP, CORBA, DCOM, y otros. Este período de tiempo se denomina tiempo de las tecnologías distribuidas. Durante este tiempo aplicaciones corrían sobre plataformas heterogéneas.

Page 41: manual español  reingenieria.docx

Desarrollo de aplicaciones con tecnologías como RMI / IIOP, CORBA, DCOM y otros similares tecnologías, es una tarea difícil. Usted debe tener altas habilidades para el uso de estas tecnologías. Para esta razón, 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 estándar 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 orientación al servicio, nos referimos a la arquitectura orientada a servicios (SOA). SOA es un enfoque de arquitectura de integración basada en el concepto de un servicio. Las funciones comerciales y de infraestructura que se requieren para construir sistemas distribuidos son disposición en los servicios que, en conjunto o individualmente, ofrecen funcionalidad de la aplicación 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 explícitas.

Page 42: manual español  reingenieria.docx

SOA ofrece los beneficios de acoplamiento débil y la encapsulación a la integración en una empresa nivel. Se aplica conceptos de éxito demostrado por el desarrollo orientado a objetos, componentes Diseño basado, y la tecnología de Integración de Aplicaciones Empresariales de un enfoque arquitectónico para la integración de sistemas de TI. Los servicios son los componentes básicos 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 más compleja y por lo tanto concebir rápidamente nuevas funcionalidades.

3.6.1 ¿Qué es un servicio? Un servicio puede ser definido como cualquier función discreta que se puede ofrecer a un externo o interno consumidor. Esto puede ser una función de negocios individuales o una colección de funciones que forman juntos un proceso. Se puede comparar a un módulo 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 están disponibles en una red. Algunos ejemplos son de login Servicio, Calcular TRM, Servicio de impresión, y así sucesivamente. Los servicios son accesibles de forma independiente de la aplicación o el transporte y se integran a través de la red de la empresa.

3.6.2 Las propiedades de los servicios Un servicio debe cumplir con las siguientes características.Ligeramente agrupado Los servicios se definen por interfaces independiente de la implementación explícitas. Los consumidores de los servicios sólo dependen de este tipo de interfaz de invocación de servicio; que no tienen que ver con la implementación del servicio o incluso cuando se ejecuta.

Page 43: manual español  reingenieria.docx

Acoplamiento débil promueve la flexibilidad en el cambio de la implementación del servicio sin afectar a los consumidores de servicios. Reutilizable Es muy importante para diseñar servicios con la reutilización en mente y anticipar los diferentes escenarios de reutilización. Es decir, cada servicio ha sido diseñado para su reutilización, sin duplicaciones. Usted puede seguir estos pasos en el diseño para la reutilización:

Descomponer el negocio que necesite en su función y los servicios (separación de las preocupaciones necesarias)

Reutilizar y crear la función de aplicaciones de negocio específicas y los servicios (creación y reutilización servicios)

Utilizar los servicios comunes que ofrece el entorno operativo (utilizar la infraestructura)El resultado es una aplicación compuesta en tiempo de ejecución que representa un proceso de negocio. Encapsulado Los servicios no deben exponerse físicamente ningún detalle de implementación o detalles de implementación dentro de su diseño de la interfaz. El concepto de encapsulación por el uso de interfaces debe estar familiarizado de las disciplinas de Análisis y Diseño Orientada a Objetos (OOAD). Las interfaces se utilizan para separar públicamente comportamiento disponible de la aplicación de dicho comportamiento. Los consumidores de ese comportamiento sólo depende de la interfaz que describe el comportamiento; los consumidores a continuación, no son afectados si la puesta en práctica de ese comportamiento cambia de ninguna manera. Servicio basado arquitecturas proporcionan un conjunto de interfaces de grano grueso que encapsulan el acceso al más fino grano componentes y son accesibles a través de la red. Apátrida Las implementaciones de servicios no deberían acercarse estado conversacional en las distintas solicitudes. Los servicios deben comunicar la información completa en cada petición y cada operación debe ser funcionalmente independiente (separada e independiente). Alta cohesión Las interfaces de servicios deben ser concisos, relacionados, y juegos completos de operaciones. Conciso y completa implica cada operación que se necesita y no más.

3.7 Nube El hecho de que el sistema operativo IBM i (OS) es uno de los mejores de múltiples 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 planificación de tareas y gestión del trabajo. Estas características 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 están estructuradas de tal forma de ejecutar estos tipos de cargas de trabajo de manera más eficiente y con el aislamiento de trabajo (separación).Desde una perspectiva técnica, la seguridad y el aislamiento de los inquilinos de los negocios de cada uno procesos y datos es una preocupación 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.

Page 44: manual español  reingenieria.docx

Desde una perspectiva comercial, la medición y la medición para la facturación es la principal preocupación. Los principales puntos que debe considerar para la nube son:

Virtualización Multitenancy Performance Seguridad Medición para su modelo de licencia

El IBM i tiene una larga historia de la virtualización. Por ejemplo, partición lógica (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 sólo una vez en la memoria. Si implementa una nueva versión del programa mientras que los usuarios siguen conectados, no hay nada roto y los usuarios seguir trabajando con su versión actual. Sin embargo, si se limitan a firmar apagado y firman de nuevo, van a tener la nueva versión del programa. Para un entorno de 5250, este despliegue dinámico no es posible porque los objetos de visualización del archivo se asignan mientras están 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 años. Sus aplicaciones ya pueden aprovechar la nube.

Herramientas de desarrollo modernoHay muchas categorías de herramientas de desarrollo. En este capítulo, cubrimos algunas de las herramientas que son comúnmente utilizados por los desarrolladores de RPG y COBOL. Tiene sentido que una aplicación proyecto de modernización también podría incluir la modernización de su conjunto de herramientas de desarrollo. La categoría de herramientas que se aplica a la mayoría de las tiendas se refiere a la edición, compilación y depuración aplicaciones host, que son a veces parte de un conjunto de herramientas que se llama un Sistema Integrado

Page 45: manual español  reingenieria.docx

Entorno de desarrollo (IDE). Además, existen herramientas que están relacionados con el código fuente cambiar las herramientas de gestión o de control de código fuente. Veremos esas dos categorías de herramientas en este capítulo, y algunas otras herramientas que pueden ser útiles para entornos específicos. Los cambios en su aplicación puede ser muy sencilla técnicamente, pero también hay otros aspectos de un proyecto de modernización para tener en cuenta:

Pluralidad de la cultura: Los desarrolladores que utilizan diferentes tecnologías necesitan compartir proyectos, información y procesos.

Pluralidad de tecnologías: Interfaces y conexiones introducen funcionalidad multiplataforma dependencias.

Complejidades: Las nuevas tecnologías y metodologías pueden introducir complejidades que su herramientas existentes no llegan a ser capaz de manejar de una manera significativa y confiable. En este capítulo se describe la situación y recomienda cambios en las herramientas de desarrollo que podrían ser necesarias para su proyecto de modernización. También describe cómo cambiar su metodología de desarrollo cuando se trabaja con estas herramientas.

4.1 Editar, compilar y depurar IDE La herramienta principal de IBM disponible en la edición, compilación y depuración de categoría es un IDE llamada Rational Developer for i, RPG y COBOL Herramientas, más comúnmente 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 básicas de estas herramientas se han mantenido igual a lo largo de las distintas versiones. Sin embargo, las nuevas características y funciones se han añadido a través de los años, incluido el apoyo de las características del lenguaje actual en el editor y una pantalla gráfica de DDS y diseñador 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 edición, compilación y depuración su código durante décadas. Esta herramienta es la "pantalla verde" herramienta de desarrollo de aplicaciones basadas Set (ADTS), que incluye el Administrador de Programación 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 límite de sus capacidades y su funcionalidad no se ha mejorado en muchos año. La última actualización 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 información adicional funcionar a estas herramientas, incluyendo cambios a los verificadores de sintaxis para los lenguajes soportados. Las modernas herramientas de desarrollo de sustitución 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 cómodos usando el conjunto de herramientas PDM / SEU podría preguntarse por qué deben cambiar. Las siguientes secciones describen algunas de las razones para el cambio.

Page 46: manual español  reingenieria.docx

4.2.1 actual (y futuro) soporte de idiomas IBM ya no es la actualización de las herramientas ADTS estilo antiguo para las nuevas características del lenguaje. Ha sido muchos años ya que no había ningún tipo de mejora funcional de las herramientas ADTS. Hasta IBM i 6.1, IBM incluye soporte para nuevas características del lenguaje. Por ejemplo, los inspectores de sintaxis en la SEU editor se han actualizado para comprender nuevas palabras clave de rol, los códigos de operación o funciones incorporadas en cada versión. Las actualizaciones para las nuevas características del lenguaje ya no se proporcionan. Por lo tanto, al utilizar SEU editar RPG o fuente COBOL, nuevas características 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á prácticamente imposible de implementar para los desarrolladores que utilizan las herramientas ADTS. SEU usuarios ya están 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. Sólo 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 están basadas en Eclipse, un desarrollo de código 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 páginas web, escribir o utilizar el código escrito en PHP o Java, o cuando se accede a muchas herramientas orientadas a la base de datos, puede utilizar muchas de las mismas técnicas y habilidades. Puesto que hay muchas herramientas basadas en el mismo núcleo, se obtiene previsibilidad cuando se necesita para utilizar estas herramientas.

Muchos plug-ins están 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 podría ya haber escrito él y lo puso a disposición del público. Algunos de estos plug-ins pueden ser específicos 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 están escritas específicamente para un IBM i medio ambiente, pero todavía puede ser muy útil, incluyendo muchas herramientas orientadas a bases de datos. A menudo, estas herramientas están disponibles ya sea de forma gratuita o con un costo muy bajo.

4.2.3 Las características de productividad de RDi Tal vez la razón más importante para cambiar de PDM / SEU a RDi es la dramática aumento de la productividad que ofrecen las herramientas más avanzadas. Se requeriría un libro entero para producir una lista completa de características de productividad que RDi ofrece sobre las herramientas PDM y SEU. A continuación se destacan algunas de las características de productividad más evidentes de la RDi editor de código fuente específica, junto con algunas herramientas estrechamente integradas con el editor que están diseñados para apoyar el proceso de edición.

Page 47: manual español  reingenieria.docx

RDi depurador gráfico El depurador RDi tiene la capacidad de controlar los valores de las variables seleccionadas al pisar a través del código y / o detenerse en los puntos de ruptura. El depurador también tiene la capacidad de contener puntos de ruptura, tanto activos (habilitados) e inactivos (discapacitados). Esto viene muy bien porque la depurador también puede recordar los puntos de corte a través de múltiples sesiones de depuración en caso de que un bug problemática requiere de un trabajo de varios días. Un ejemplo del depurador RDi en la acción se muestra en la Figura 4-1. La captura de pantalla ilustra varias características 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 sesión de depuración. 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 interrupción se muestra con una marca a la izquierda del número de documento.

Figure 4-1 RDi Graphical Debugger

DDS diseñador Además del depurador, el diseñador DDS puede hacer mantenimiento o creación de informes o pantallas más fáciles. El diseñador gráfico 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 diseñador hace que sea mucho más fácil 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

Page 48: manual español  reingenieria.docx

simple para cambiar entre el modo de diseño gráfico y la edición directa de la DDS para aquellas ocasiones en que el enfoque directo de edición es más productivo. Mira la Figura 4-2 para tener una idea de lo que funciona la herramienta de diseño 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 diseño 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 diseño 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 pestañas en la ventana de propiedades.) La Paleta a la derecha de la ventana de diseño 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 también se puede utilizar para seleccionar elementos en la pantalla de diseño. En la parte inferior de la ventana de la pantalla del diseño son tres pestañas, una de las cuales (Fuente) permite que la fuente DDS para ser editado directamente.

iProjects

Hay otras herramientas en RDi, más notablemente iProjects, que el apoyo que trabaja en un desconectado medio ambiente. iProjects también se pueden utilizar para ayudar a organizar el trabajo de desarrollo en locales proyectos almacenan en el disco estación de trabajo o en IBM i u otro servidor. iProjects también es se utiliza con algunas herramientas de gestión del cambio de fuente.

Page 49: manual español  reingenieria.docx

RDI destacados productividad editor como la mayoría de los desarrolladores gastan más de su tiempo de visión, navegación y edición de código fuente, los beneficios de productividad del editor RDi merecen un análisis más detallado. El editor contiene múltiples funciones para mejorar la productividad de programación. Además del editor de sí mismo, hay herramientas, tales como el Esquema y Error vistas Feedback, que están diseñados para trabajar en estrecha colaboración con el editor para mejorar aún más la productividad. En esta sección se hará hincapié en algunos de las más valiosas funciones de productividad del editor.

Más código visible a la vez Cuando la edición de código fuente, un desarrollador puede ver típicamente de 2 a 3 veces el número de líneas de código en comparación con el editor de SEU mayor. Cuando se utiliza SEU, el número de líneas visibles es fijo, independientemente del tamaño de monitor utilizado. Con el editor de RDi, el número de fuente líneas visibles varía en función del tamaño del monitor y la forma y el tamaño de la fuente seleccionada. Vista más código hace que sea más fácil y más rápido para seguir el flujo de la lógica. Figura 4-3 ilustra la capacidad de ver más líneas de código a la vez.

Miembros fuente abierto y múltiple a la vez Miembros fuente múltiples pueden ser abiertos para su edición (y hojear) al mismo tiempo. Este se vuelve más importante como las aplicaciones modernas se hacen más modular. Es fácil de haga clic entre los miembros abiertos como fluye la lógica entre los módulos. Dos o más miembros se pueden ver simultáneamente a través de uno o más de pantalla dividida horizontal y vertical líneas. Incluso en el modo de pantalla dividida, todos los miembros pueden ser abiertos para su edición. Consulte la Figura 4-3, que muestra un ejemplo de edición de la pantalla dividida en IDI. En esa misma figura las pestañas mostrando por encima del código fuente indican los diferentes miembros de origen que se encuentran actualmente abrirá en la sesión de edición.

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

Page 50: manual español  reingenieria.docx

Filtrado de código fuente Líneas de código fuente se pueden filtrar en el editor RDi en un número de maneras. Si hay muchos líneas comentadas Salida de código en un miembro fuente, eligen para filtrar para ver sólo código. Este elimina todas las líneas de comentarios desde su punto de vista, dando aún más líneas de código visible a él desarrollador. Las líneas también pueden ser filtradas por la última fecha de modificación de la línea, que puede ser útil en la búsqueda de los cambios recientes en el código que pueden haber causado errores recientes en la aplicación. Otras opciones de filtro incluyen mostrando instrucciones SQL únicas, mostrando sólo subrutinas o secundarios y las que muestran sentencias lógicas flujo único de control. Adicionalmente, un poco de texto, por ejemplo, un nombre de campo, se puede seleccionar y luego se filtró el código en ese selección. Esto calza únicamente las líneas de código que hace referencia a ese campo en el editor. El filtrado puede ayudar al desarrollador a encontrar partes de un programa que requiere atención rápida.

Vista del esquema para las definiciones, referencias cruzadas y de navegación fuente A la vista Esquema programa está disponible para ayudar con la navegación a través del código 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 También se incluyen las estructuras de datos. Tanto el programa describe como externamente describe variables que aparecen en una lista que puede ser ordenada alfabéticamente por el nombre del campo para que sea rápido para encontrar la definición de campo es necesario. Incluso sin utilizar la vista Esquema, espectáculos el editor RDi la definición de una variable cuando se pasa el ratón sobre su nombre. Así que no hay más

Page 51: manual español  reingenieria.docx

Necesitamos hacer un DSPFFD (Mostrar archivo de definiciones de campo) o algún otro método en el host para encontrar la definición de un campo. Además 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. Además hay una referencia cruzada en el Esquema muestra que cada elemento hace referencia en el miembro fuente; esas líneas de referencia transversales también están conectados al editor. Así, por ejemplo, un desarrollador puede navegar fácilmente no sólo a una subrutina específica utilizando el esquema, pero también pueden navegar directamente a cada línea de código en el elemento que llama a la subrutina. La información de referencia cruzada para los campos indica si no se modifica el campo en que la declaración por medio de (M) después de que el número de sentencia. La Vista Esquema se actualiza automáticamente a medida que edita el código en la vista de edición. Estos dos puntos de vista están estrechamente ligados. La figura 4-4 muestra el esquema para la derecha del código en el editor. Los detalles de cada línea de código que hace referencia a la variable FullDate, junto con la definición de FullDate, se muestra. Tenga en cuenta que dos de las instrucciones que hacen referencia FullDate modificar el valor, mientras que uno de ellos sólo hace referencia a ella. Una de las referencias se selecciona en el Esquema, que automáticamente colocado el editor para esa línea de código.

Page 52: manual español  reingenieria.docx

Deshacer y rehacer Durante una sesión de edición, un desarrollador tiene niveles ilimitados de deshacer y rehacer, tanto de cambios individuales, incluso después 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 todavía "deshacer" cambios individuales de todo el camino de regreso al abrir ese archivo. En el editor de SEU, la única opción para deshacer los cambios es deshacer todo los cambios en toda la sesión de edición 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 pestañas se pueden personalizar según las preferencias del desarrollador. Una línea de formato que aparece en la parte superior de la ventana del editor indica la posición actual del cursor en la line. A diferencia de la línea de formato en el SEU, que siempre refleja el formato de la primera declaración en la pantalla, el editor RDi cambia la línea de formato para que coincida con la declaración en la que se encuentra el cursor. Esto hace que sea mucho más rápido para introducir el código que se encuentra todavía en formato fijo RPG, así como el código DDS.

Retroalimentación Error integrado con el editor Errores que se producen durante una compilación aparecen en una lista de errores al lado del editor de código fuente. Haciendo doble clic en un error en la lista que posiciona a la línea de código 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 compilación para encontrar y corregir los errores de tiempo de compilación en su código. Miembros fuente editados en RDi son típicamente compiladas sin cerrar el miembro fuente para permitir una reacción más rápida a los errores en tiempo de compilación. En la Figura 4-5, un intento de compilación 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 automáticamente en la línea de código para ese error. La integración de la retroalimentación de error con el editor es considerablemente más rápida que cualquier mecanismo que implica la exploración de un archivo en spool de compilación listado para localizar líneas de código en el error.