IMPLANTACIÓN DE LINEAS DE PRODUCTOS DE SOFTWAREMEDIANTE HERRAMIENTAS COMERCIALES

T E S I S

MAESTRÍA EN CIENCIASESPECIALIDAD EN TECNOLOGÍA INFORMÁTICA

INSTITUTO TECNOLÓGICO Y DE ESTUDIOSSUPERIORES DE MONTERREY

CAMPUS MONTERREY

DIVISIÓN DE GRADUADOS EN ELECTRÓNICA,COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES

PORCÉSAR FREDY LUCAS GONZÁLEZ

JULIO DE 2000

Dedico esta tesis a mis papás, con quienes siempreestaré en deuda por su amor y motivación.

A mis hermanos y a toda la familia.

Gracias.

Reconocimientos.

A mi asesor principal, Lic. Guillermo Jiménez Pérez, por sus enseñanzas, paciencia yayuda que aportó para la realización de esta investigación.

A mis sinodales, Ing. Gustavo Cervantes Ornelas e Ing. Yolanda Martínez Treviño, por sudisposición y recomendaciones para la realización de este trabajo.

A los señores, C.P. Benigno Escalante y Sr. José Alberto Echeverría, de las Uniones deCrédito de Monterrey: UCREDI y UCREM, por su colaboración e informaciónproporcionada.

iv

Resumen.

Una arquitectura de software para líneas de productos es un modelo de diseño, utilizado paraproducir una línea de productos de software (aplicaciones que tienen aspectos comunes yvariaciones pronosticadas). Esta arquitectura es desarrollada de tal manera que explote elconjunto de características comunes y las variaciones presentes en los productos de la línea, pormedio de componentes de software reutilizables, con un enfoque que rompe el tradicionalconcepto de desarrollo de proyectos para un solo producto. A esta propuesta de desarrollo desoftware se le ha denominado línea de productos.

En una línea de productos, el desarrollo de los sistemas llega a convertirse más en materia degeneración que de elaboración; la actividad predominante es la integración en lugar de laprogramación. Así como la evolución de un sólo producto (modificaciones, actualizaciones)debe ser considerada dentro de un contexto más amplio; la evolución de la línea de productoscomo un todo.

Desarrollar líneas de productos involucra seguir un método de análisis y diseño para obtener laarquitectura, y una vez obtenida seguir una técnica de implementación. Esta investigaciónpropone un método de análisis y diseño para la línea de sistemas de contabilidad para Uniones decrédito, una técnica de implementación de arquitecturas por medio de una herramienta comercial,y un generador de aplicaciones.

En la actualidad existen varios métodos para el análisis y diseño de líneas de productos, peropocos están orientados a facilitar la implementación. Principalmente se centran en ladeterminación de las variaciones y semejanzas. El método propuesto tiene como resultado laobtención de arquitecturas de software por niveles, en donde cada nivel corresponde a uncomponente reutilizable.

La principal técnica de implementación de arquitecturas de software es por medio de herenciaparametrizada, característica presente en lenguajes como CLOS, C++ y otros. Pero, la mayoríade los ambientes comerciales de desarrollo no la presentan. La técnica de implementaciónpropuesta, sustituye la herencia parametrizada por delegación, y hace uso de referenciascirculares para hacer llamadas directas a código (ejecutar desde el interior de un componente,código localizado en un componente externo) sin restricciones de ubicación de los componentes.

La tesis finaliza con el desarrollo de un generador de aplicaciones, el cual además de simplificarel proceso de producción, genera automáticamente diferentes sistemas de contabilidad. Ungenerador de aplicaciones para una línea de productos, tiene características propias que lo hacendiferente a los generadores tradicionales, como analizadores semánticos para reglas de diseño ygeneración de diversos tipos de componentes.

V

Índice general

Reconocimientos v

Resumen vi

Índice de figuras x

Índice de tablas xi

Capítulo 1 Introducción1.1 El desarrollo de software 11.2 Objetivo de la tesis 31.3 Estructura del documento de la tesis 3

Capítulo 2 Marco de referencia2.1 La motivación para el reuso 42.2 Beneficios 52.3 Componentes 62.4 Obstáculos para el desarrollo de componentes 62.5 Clasificación de los métodos de reuso 72.6 Arquitecturas de software 92.7 Arquitecturas de software líneas de productos 102.8 Ingeniería de dominios 12

Capítulo 3 Método de análisis y diseño para la línea de sistemas3.1 Los métodos actuales 143.2 Método ADLIS 16

3.2.1 Fase de Análisis 163.2.1.1 Definición del dominio de aplicaciones 163.2.1.2 Análisis de contexto 173.2.1.3 Descripción de las aplicaciones y definición de requerimientos 173.2.1.4 Análisis de requerimientos entre productos 173.2.1.5 Análisis de características 173.2.1.6 Definición del patrón de diseño 18

3.2.2 Fase de Diseño 183.2.2.1 Diagramas de flujo de datos 183.2.2.2 Modelo operacional 193.2.2.3 Registro de colaboraciones 203.2.2.4 Componentes complementarios 21

vi

Capítulo 4 Aplicación del método ADLIS4.1 Fase de Análisis 22

4.1.1 Definición del dominio de aplicaciones 224.1.2 Análisis de contexto 244.1.3 Descripción de la aplicación y definición de requerimientos 254.1.4 Análisis de requerimientos entre productos 274.1.5 Análisis de características 284.1.6 Definición del patrón de diseño 28

4.2 Fase de Diseño 304.2.1 Diagramas de flujo de datos 314.2.2 Colaboración 314.2.3 Registro de operaciones 344.2.4 Componentes complementarios 38

Capítulo 5 Implementación5.1 Arquitectura por niveles y gramática GenVoca 405.2 Estrategia de implementación de componentes 43

5.2.1 Características de Delphi 445.3 Implementación de componentes en Delphi 45

5.3.1 Componente tipo Inicial 505.3.2 Componente tipo Final 505.3.3 Componente tipo Globales 515.3.4 Componente tipo Procedimiento 525.3.5 Componente tipo Decorador 535.3.6 Componente tipo Función 545.3.7 Componente tipo Procedimiento-función 56

Capítulo 6 Generador6.1 Introducción 596.2 Análisis semántico 606.3 Clase generadora 616.4 Ensamble con la pantalla al usuario 656.5 Construcción de aplicaciones 656.6 Resultados 67

Capítulo 7 Conclusiones7.1 Conclusiones 707.2 Alcance de la tesis 717.3 Trabajos futuros 72

Apéndice A Código del generador de aplicaciones y componentesA.l Descripción 73A.2 Unidades del generador de aplicaciones 74A.3 Ejemplos de componentes 83

vii

Apéndice B Planes de Misión XXIB.l Sumario 87B,.2 Plan técnico 91B.3 Plan de negocios 98

Referencias 108

VITA 111

viii

Índice de figuras.

1.1 Producción en una línea de productos 22.1 Ejes de clasificación de los métodos de reuso 82.2 Diapositiva de la materia: Arquitecturas para sistemas de software 92.3 Procesamiento de datos clásico 103.1 Ciclo de vida de ADLIS 154.1 Modelo de contexto del sistema de contabilidad 244.2 Diagrama de características 294.3 Patrón para el diseño 304.4 Diagrama de flujo de datos del reporte Saldos 324.5 Colaboración del reporte Saldos 334.6 Definición de tipos a las operaciones del reporte Saldos 344.7 Colaboración del reporte Saldos con su estructura final 395.1 Esquema de las unidades 455.2 Estructura general 465.3 Componente_X[Componente_Y[Componente_Z[...]]] 485.4 Estructura general con parámetros formales 495.5 Componente tipo inicial 505.6 Componente tipo final 505.7 Componente tipo globales 515.8 Componente tipo procedimiento 525.9 Componente tipo decorador 535.10 Componente tipo función 545.11 Componente tipo procedimiento - función 566.1 Arreglos: Componente, Requiere, y Max veces 606.2 Clase generadora 626.3 Representación de la Unidad generadora como un bus de comunicaciones 646.4 Generador de aplicaciones para la Línea de Sistemas de Contabilidad de Uniones 666.5 Directorios utilizados para organizar el código 666.6 Ejemplo de un sistema de contabilidad para una Unión de crédito industrial 686.7 Ejemplo de un sistema de contabilidad para una Unión de crédito agropecuaria 686.8 Ejemplo para producir un sistema de contabilidad personalizado 69

ix

Capítulo 1. Introducción.

1.1 El desarrollo de software.

Como toda ingeniería que pretende la mejora de su conjunto de estudios, la comunidadinvolucrada en la ingeniería en sistemas computacionales ha tratado de dar soluciones a unproblema en particular de los sistemas computacionales, el desarrollo de software. No por elhecho mismo, que el desarrollo de software sea un problema, sino por las necesidades odemandas actuales del mercado del software.

El fin último o propósito del desarrollo de software es obtener una aplicación, un programacomputacional que nos dé un resultado útil a nuestros propósitos; esta aplicación puedeconsiderarse como "el producto", y el medio de producción son los métodos y herramientas parael desarrollo de software. Existen productos de muy diversos tipos, pero en particular noscentraremos en aquellos que involucran mucho tiempo en su desarrollo, bastantes recursos o sonutilizados para situaciones críticas, estos productos pueden clasificarse como sistemas complejosy son a los que se hará referencia.

Para obtener un producto de software se sigue un método basado en un ciclo de desarrollo quegeneralmente tiene las etapas de: análisis, diseño, codificación, prueba y mantenimiento; existenotros ciclos que varían en cuanto a la definición de otras etapas o en la forma de repetir lasetapas, pero todos con un objetivo en común, la obtención de un producto de software de altacalidad. Estos métodos han dado muy buenos resultados pero sólo se enfocan a la producción deun solo sistema. Su perspectiva es la de producir un solo producto. Como ejemplos de estosmétodos están el ciclo de vida en cascada, la construcción de prototipos, y el modelo en espiral.

Pero muchas de las demandas actuales de software, no pueden ser satisfechas por estos métodostradicionales de software. Como sucede con el software para mercados verticales, en donde setienen que producir aplicaciones que tienen aspectos comunes y variaciones pronosticadas (a estetipo de aplicaciones en conjunto se les denomina familia de sistemas). Actualmente existe unaausencia de métodos que nos lleven a la obtención de varias aplicaciones de una familia desistemas, en un mismo ciclo de desarrollo [Czarnecki 99].

Por las formas de producción tradicionales de software, existen otras comunidades que hancalificado al proceso de desarrollo de software más como una actividad artesanal, en lugar de seruna técnica, propia de una ingeniería, dado que otras ingenierías han logrado un nivel deindustrialización o automatización para la producción de diversos productos, con un menor gradode participación humana.

Si bien las formas actuales de producción de software han dado buenos resultados, no tenemospor qué estar sujetos a estas formas tradicionales, que por su naturaleza no pueden ser aplicadasen todas las situaciones que se nos presenten, y por consiguiente no deben ser consideradas comolas mejores soluciones para el desarrollo de aplicaciones con aspectos comunes y variacionespronosticadas.

Una de las nuevas propuestas de desarrollo de software que han surgido, se le ha denominadolíneas de productos de software [Bronsword 96], la cual se basa en el desarrollo de unaarquitectura de software (estructura o forma de organización del código) [Garlan 96] que facilitela construcción de aplicaciones de una familia de sistemas, de manera análoga a una línea deproducción industrial (línea automatizada). La propuesta de arquitectura de software para líneasde productos no define la estrategia a seguir, tampoco si debe utilizarse el paradigma de objetos oel estructurado para su codificación, pero con su teoría establece los conceptos y propósito.

Las arquitecturas1 principalmente se han implementado en lenguajes especializados o utilizandomecanismos avanzados (tales como, templates de C++), dejando sin explorar las posibilidadesque presentan otros ambientes de uso comercial (Delphi, Visual Basic, etc.), los cuales tienen lascaracterísticas básicas que permiten la implementación de arquitecturas por medio del paradigmade objetos. Tales ambientes a diferencia de otros lenguajes, son herramientas de desarrollo másrápidas y enfocadas al desarrollo de sistemas.

La implementación de una arquitectura no es sólo un asunto de programar clases y tratar dereusar por medio de la herencia, polimorfismo y encapsulación en sus formas tradicionales. Senecesita una estrategia para la implementación de aplicaciones por medio de una línea deproductos. Varias estrategias se han propuesto para su implementación en los lenguajesespecializados; pero actualmente se desconoce una estrategia para su implementación enambientes comerciales.

La elaboración de las aplicaciones en la propuesta de líneas de productos de software es realizadapor medio de un generador de código, el cual automatiza la producción de una línea de productos[Sodhi 99]. El generador tiene como tarea tomar del grupo de componentes (definidos en laarquitectura de software para línea de productos), los requeridos para producir el código de unode los varios productos. La Figura 1.1 representa la secuencia de producción de las aplicaciones.

- AHA

Arquitectura de softwarepara una linea de productos

Componentesimple me ruados

ProductosFigura 1.1 Producción en una Línea de productos.

' Los términos "arquitectura de software para líneas de productos" y "arquitectura" serán usados indistintamente, latesis no hace referencia a otro tipo de arquitectura de software.

1.2 Objetivo de la tesis.

Explorar la viabilidad del desarrollo de Arquitecturas de software para líneas de productos y suimplementación por medio de una herramienta comercial, como una solución alternativa aldesarrollo de aplicaciones para mercados verticales. Describiendo un método para suconstrucción, incluyendo las etapas de su ciclo de vida y los aspectos técnicos para suimplementación.

1.3 Estructura del documento de la tesis.

El documento consta de siete capítulos, los cuales están divididos en: 1) Introducción y basesteóricas que sustentan la tesis, 2) Método de desarrollo hasta el nivel de diseño, 3)Implementación y 4) Conclusiones.

La primera parte consta de los capítulos:

• Introducción. Descripción de situaciones que se presentan en el desarrollo de softwarepara mercados verticales, y descripción de las características de la tesis.

• Marco de referencia. Ubicación de la propuesta de solución (tesis) dentro del ámbito desoluciones del reuso de software, así como explicación del reuso y sus beneficios.Definición de los conceptos de arquitecturas de software y los elementos involucradospara su desarrollo.

Segunda parte:

• Método ADLIS. Descripción de deficiencias de los métodos actuales de análisis y diseñoorientados a objetos. Propuesta de un método para el análisis y diseño de arquitecturas desoftware para sistemas de contabilidad de Uniones de crédito. El método posee etapas aseguir para el análisis y diseño, del apego a estas etapas dependerá la facilidad deimplementación de los requerimientos del usuario.

• Aplicación de ADLIS. Muestra un ejemplo de aplicación del método ADLIS.

Tercera parte:

• Implementación. Características de Delphi. Descripción de la técnica utilizada para laimplementación de arquitecturas por niveles en Delphi, y formas de implementación delos componentes resultantes de la arquitectura

• Generador. Descripción de los módulos que conforman al generador de aplicaciones, asícomo su funcionamiento. Indica la forma de integrar el código generado a la aplicación.

Cuarta parte:

• Conclusiones. Expone las conclusiones de la tesis, así como propone trabajos futuros.

Capítulo 2. Marco de referencia.

Una estrategia de solución que está emergiendo, y propone un nuevo tipo de desarrollo desistemas es el enfoque de líneas de productos de software. Este enfoque está ubicado en el áreadel reuso de software. El reuso de software es considerado como una de las más importantessoluciones a los problemas del desarrollo de software, debido a varios beneficios que ofrece. Eneste capítulo se describe la teoría que fundamenta el desarrollo de software basado en líneas deproductos. Inicia con la descripción de la necesidad del reuso, sus beneficios y la definición decomponentes reusables. Posteriormente es definido el enfoque de líneas de productos dentro delcontexto de reuso de software, y finaliza con la explicación de los conceptos de arquitecturas desoftware para líneas de productos.

2.1 La motivación para el reuso.

Actualmente es imposible concebir nuestro mundo sin software, cada día se convierte más en unelemento indispensable del mundo moderno. El ciberespacio depende del software, así comobancos, centros comerciales, industrias, laboratorios de investigación, escuelas y otrasorganizaciones de nuestra sociedad. El software, además de ser una herramienta de apoyo en lasactividades de los individuos, se ha convertido en un elemento más de competitividad entre lasempresas. Si bien algunas empresas desean software rápido y confiable para tener una mejorposición competitiva, otras en cambio no podrían operar sin éste.

Desafortunadamente, existen problemas que afligen al desarrollo del software. Estos se puedendividir bajo muchas perspectivas, pero los responsables de los desarrollos de software se centransobre los aspectos de "fondo": (1) la planificación y estimación de costos son frecuentementeimprecisas, (2) la productividad de la industria del software no corresponde con la demanda y (3)la calidad del software no es buena [Pressman 92].

Ante los problemas descritos, se han buscado soluciones que reduzcan el tiempo de entrega,incrementen la productividad, mejoren la calidad, faciliten el mantenimiento y disminuyan loscostos. Dos alternativas de solución se han propuesto para lograr esas metas. Una se haenfocado a la mejora en la eficiencia de los procesos de desarrollo, y la otra propone el reuso desoftware en mayores proporciones [Jacobson 97].

La primera alternativa tiene como objetivo incrementar la eficiencia de la organización queproduce el software. La mejora se centra en la "productividad del proceso", el cual es unconcepto de medición para la efectividad de todo el proceso de software (administración,recursos, herramientas y personal); es decir, proponen el establecimiento de métricas para elproceso, y la mejora consiste en superarlas constantemente.

La segunda alternativa es el reuso. La definición de reuso sistemático de código es [Mcllroy69]: desarrollar sistemas de componentes de un tamaño razonable y reusables. Posteriormente se

extendió lo idea de "sistemas de componentes" más allá de únicamente el código, arequerimientos, modelos de análisis, diseño, y pruebas. Todas las etapas del proceso dedesarrollo de software están sujetas a reuso. Por medio del reuso es posible [Jacobson 97]:

• Ahorrar esfuerzo para resolver problemas a lo largo de todo el desarrollo.• Reducir el costo del producto, por el menor número de actividades a realizar.• Mejorar la posibilidad de predicción del proceso dado que se conocen todos los posibles

escenarios, y de esta forma saber un patrón de conducta.• Mejorar la confiabilidad del trabajo, porque cada componente que sea vuelto a utilizar en

un sistema, ya ha sido revisado e inspeccionado en el transcurso de su desarrollo original.• Asegurar la eficiencia, debido a que los componentes han pasado pruebas de unidad, de

sistema, y pruebas de uso en el campo.• Reducir el tiempo de desarrollo de años a meses, o de meses a semanas.• Incrementar la calidad del producto y por consiguiente su funcionalidad, facilidad de uso,

eficiencia, facilidad en su mantenimiento y portabilidad.

2.2 Beneficios.

Los beneficios del reuso pueden ejemplificarse en empresas como AT&T, Ericsson, GTE,Hewlett-Packard, IBM, Motorola, NEC, y Toshiba, las cuales han obtenido ahorros significativosen costos y tiempo.

Iniciando con experimentos en 1984, Hewlett-Packard en el transcurso de diez años logró nivelesde reuso del 25 al 50% enfirmware para instrumentos e impresoras. Una línea de instrumentosalcanzó un 83%. Algunas organizaciones han obtenido niveles de reuso de alrededor del 90% endeterminados proyectos o áreas [Jacobson 97]:

• AT&T: 40-92% en software para soporte de operaciones en telecomunicaciones.• Brooklyn Union Gas: 90-95% en un nivel de proceso, y 67% en una interface a usuarios y

objetos del negocio.• Ericsson AXE: 90% en cientos de configuraciones para el cliente.• Motorola: 85% de reuso y un rango de ahorros de 10:1 en un compilador y varios

paquetes de pruebas.

Con base a la experiencia y conocimiento de los desarrolladores que hacen uso de las prácticas dereuso de software, la administración de una empresa desarrolladora de software puede esperarganancias sustanciales [Jacobson 97, HP 93]:

• Tiempo de entrega: reducciones de 2 a 5 veces.• Densidad de defectos: reducciones de 5 a 10 veces.• Costo de mantenimiento: reducciones de 5 a 10 veces.

Costo de desarrollo de todo el software: reducciones de alrededor del 15% y hasta 75%para proyectos de largo término (incluye el costo de desarrollar los elementos reusables yel soporte para su uso).Calidad: mejora la calidad de 5 a 10 veces.

2.3 Componentes.

El elemento base del reuso de software son los componentes. Un componente es un objeto únicoque no está limitado a un programa en particular, lenguaje computacional, o implementación.Éste no constituye una aplicación completa por sí mismo, pero puede ser usado para construiraplicaciones personalizadas y baratas [Umar 97]. Los componentes reducen el costo y lacomplejidad del desarrollo de software. Diferentes componentes interactúan usando lenguaje-neutral, las interacciones se realizan por medio de llamadas o notificación de eventos.

Los componentes son módulos de software "plug and play" de alto nivel, que ejecutan unconjunto de tareas limitadas dentro de una aplicación. Por ejemplo, Microsoft Draw es uncomponente dentro de las aplicaciones Microsoft. Este componente en particular es de alto nivelya que realiza funciones tipo usuario-final (dibuja cajas, flechas, círculos, etc.). Sin embargo, noes una aplicación aislada, ésta solamente trabaja con otros componentes de aplicaciones [Umar97]. Los componentes son usados como elementos "plug and play" para construir aplicacionescompletas.

Una de las características importantes de un componente de software de alta calidad es lareusabilidad. El componente debe diseñarse e implementarse para que pueda volver a usarse enmuchos programas diferentes. En los setenta se construyeron bibliotecas de subrutinascientíficas y de ingeniería. Esas bibliotecas de subrutinas reutilizaban de forma efectivaalgoritmos bien definidos [Pressman 92]. Hoy en día, se ha extendido la visión de componentespara abarcar no sólo algoritmos, sino también estructuras de datos. Un componente encapsulatanto datos como procesos en un único paquete.

2.4 Obstáculos en el desarrollo por componentes.

La información que se encuentra sobre los beneficios de construir por componentes es bastante,es común encontrar las analogías sobre como la industria electrónica construye a partir de chipsreutilizables, y de cómo esto puede multiplicar el poder de invención en toda esta industria (sólobasta ver las novedades electrónicas que aparecen constantemente). A pesar de los beneficiosprometedores que puede traer el desarrollar software a partir de componentes, esto no es tan fácilde lograr.

Dada la gran cantidad de información que existe sobre tecnologías de software, muchas empresashan comenzado a desarrollar utilizando enfoques orientados a componentes, considerando que loscomponentes son objetos. Un estudio del grupo de información Cutter Information Groupencontró que 80 de 120 empresas citaron el reuso de software como una razón para la adopción

de los objetos. Pero el hecho de utilizar programación orientada a objetos, no garantiza el reusodel software, se involucran varios aspectos para lograrlo, basta decir que existen varios tipos decomponentes reusables con diferentes beneficios [Radding 98]:

• Objetos GUI reusables, reducen el tiempo de desarrollo y mejoran la calidad yconsistencia pero proveen solamente un modesto beneficio en términos de todo el costode desarrollo de la aplicación.

• Componentes server-side, constituyen lógica de negocios reutilizable que pueden proveerun beneficio significativo pero requieren mucho análisis y diseño de antemano. Tambiénrequieren una base arquitectónica (modelo de diseño).

• Componentes de infraestructura y frameworks de servicios son servicios genéricos paratransacciones, mensajes, seguridad y conectividad de bases de datos. Eliminan lanecesidad de construir repetidamente infraestructura que todas las aplicaciones usan, perorequieren mucho análisis, diseño y programación compleja. Están basados en estándaresy pueden ser comprados.

• Patrones de alto nivel permiten a las organizaciones lograr reuso del diseño e identificarcomponentes con alto potencial de reuso, pero los desarrolladores deben construir oadquirir esos componentes.

• Aplicaciones empacadas permiten a las compañías adquirir funcionalidad con unacomplejidad menor al de construirlas por ellas mismas. Sin embargo, estas aplicacionesno ofrecen la misma funcionalidad que la organización necesita, la subsecuente"personalización" que sea requerida aumentará el costo.

Dentro de los aspectos para garantizar el reuso, se necesita como base una buena arquitectura, esimprobable que sin una arquitectura los componentes trabajen para la siguiente aplicación. Almenos las organizaciones necesitarán de una arquitectura de sistemas, una arquitectura dedominio de negocios y una infraestructura para su implementación [Radding 98].

Sin una arquitectura, las organizaciones no serán capaces de construir o comprar componentesreusables que sean consistentes.

Tecnologías de software basadas en componentes como ActiveX, OLE, Appleís de Java, IDL deCORBA, sugieren el desarrollo de componentes, pero no presentan una estrategia para eldesarrollo de aplicaciones por medio del reuso de componentes, no proponen un desarrollo anivel sistema; esas tecnologías definen y controlan interfaces de componentes de maneraindependiente a la implementación del componente.

2.5 Clasificación de los métodos de reuso.

La clasificación de los métodos de reuso depende de tres criterios [Karlsson 95]: el alcance delreuso, el destino del reuso y lo granular de los componentes. El alcance del reuso tiene tresdiferentes valores, como se muestran en la Figura 2.1:

Destino

Granularidad

Figura 2.1 Ejes de clasificación de los métodos de reuso.

• Reuso general significa reuso independiente del dominio de aplicaciones, por ejemplo loscomponentes de propósito general como funciones matemáticas y paquetes para interfacesa usuarios. También denominado como reuso horizontal. El comportamiento de loscomponentes es común en varios dominios.

• Reuso de dominios constituye el reuso dentro de un dominio de aplicaciones. Porejemplo, en el dominio de las telecomunicaciones, un subsistema de administración dedesempeño. En este caso, el subsistema es estandarizado dentro del dominio, y comocomponente es potencialmente reusable en cualquier aplicación de telecomunicaciones.La semántica de los componentes es dependiente del dominio.

• Reuso por líneas de productos significa reuso dentro de una familia de aplicaciones, deforma análoga a una línea de producción industrial. La semántica de los componentesestá limitada al tipo de aplicaciones. Una línea de productos requiere de una arquitecturagenérica y los roles de los componentes.

El destino del reuso tiene dos valores:

• El método interno o método de casa, significa que la empresa está desarrollando parareusar y provee sus servicios de forma interna (a la propia empresa).

• El método externo indica que la empresa está desarrollando para reusar y provee susservicios al mercado externo (para otra empresa).

Lo granular de los componentes está clasificado en :

• Fino significa que los componentes son genéricos e independientes del dominio, tal comolas funciones para acceso a bases de datos, funciones para manipulación de estructuras dedatos y las clases de objetos individuales. También denominados de escala pequeña.

• Extenso indica que los componentes pueden ser subsistemas de las aplicaciones, como lossubsistemas de procesamiento de órdenes, servidores de bases de datos y otros.

Algunas analogías al problema de construir productos por medio de componentes, se hacen enbase a juegos de construcción como se describe en la Figura 2.2.

Building Systems from Parts

• The hype:".„ and then we'll be abie to construct software systems bypicking out parts and plugging them togcther, just likeTinkertoys „.."

• The hard cold truth:H's more like having a bathtub fuü of Tinkertoy, Lego, Erectorsetf Lincoln logs, Bloek Cily, and six other iricontpatíl»ie kit* —picking o«t parts that fit specific fujudions and expectíng theoito ñk together

Figura 2.2 Diapositiva de la materia Arquitecturas para sistemas de software [Garlan 98].

2.6 Arquitecturas de software.

La arquitectura de software comprende la descripción de elementos a partir de los cuales lossistemas son construidos, las interacciones entre estos elementos, patrones que guían sucomposición y restricciones de esos patrones [Garlan 96]. La arquitectura de un sistema desoftware:

• Define al sistema en términos de elementos o componentes computacionales y lasinteracciones entre estos.

• Muestra la correspondencia entre los requerimientos y los elementos del sistemaconstruido.

• Define las propiedades (escala, capacidad, flujo, consistencia, compatibilidad) a nivelsistema. Las propiedades ayudan para la construcción y el análisis.

Por ejemplo, en una aplicación para base de datos, los componentes pueden ser módulos comoclientes, servidores, tablas, procedimientos, y las interacciones entre estos componentes se realizapor medio de llamadas a procedimientos y acceso a variables. Las propiedades dependerán delas características esperadas de los componentes en su conjunto (a nivel sistema), como las

posibilidades de compatibilidad, capacidad, el tipo de información que proporciona y tamaño.Cuando se trata del procesamiento de datos clásico, el tipo de arquitectura más utilizado es elbatch - secuencial [Garlan 98], como se muestra en la Figura 2.3.

Transformación de datos

/ \

\

Inf. i 1 Inf. i 1 Inf. i , Inf. ,>\ Validar | * Ordenar | ~ — f l Actualizar \~^~*\ R«Portar

reporte

Inf.

Flujo de datos Inf. = Información

Figura 2.3 Procesamiento de datos clásico.

Con el ejemplo anterior, podría interpretarse que una arquitectura de software es sólo unprograma, dada la secuencia de procesos mostrada. El desarrollar por medio de los componentesde una arquitectura de software, brinda otras posibilidades diferentes a las de un programa, estasdiferencias se muestran en la Tabla 2.1 [Garlan 98].

ArquitecturaInteracciones entre partesPropiedades estructuralesDeclarativoEn su mayor parte es estáticaDesempeño a nivel sistemaFuera del límite modular

ProgramaImplementación de partesPropiedades computacionalesOperacionalEn su mayor parte es dinámicaDesempeño algorítmicoDentro del límite modular

Tabla 2.1 Diferencias entre arquitectura y programa.

2.7 Arquitecturas de software para líneas de productos.

Una arquitectura de software para línea de productos es una arquitectura de softwareespecializada, que de forma similar a una línea de producción de una industria, produce una líneade productos de software (aplicaciones). Esta arquitectura es elaborada de tal manera queexplote un conjunto de características en común, por medio de componentes de softwarereutilizables.

El enfoque de arquitecturas de software para líneas de productos consiste en el uso de unaarquitectura de software con el propósito de construir múltiples aplicaciones en un dominio

10

[Batory 98]. Las arquitecturas de software han estado implícitamente en los sistemas desoftware, generalmente dividendo los programas en módulos, definiendo las interacciones entrelos módulos, y construyendo sistemas a partir del arreglo de los módulos.

Un grupo de sistemas construidos a partir de un conjunto de características comunes yvariaciones pronosticadas es una familia de productos. Una familia de productos no necesitaconstituir una línea de productos necesariamente, dado que se puede construir los miembros deuna familia de sistemas de forma individual. Pero, construir una familia de sistemas como unalínea de productos aprovecha y amortiza inversiones anteriores al máximo grado posible. Lasuma del costo de construcción de una línea de productos, llega a ser mucho menor que la sumadel costo de construcción de sistemas individuales. Producir un nuevo sistema llega a ser menoren materia de elaboración, que uno desarrollado o modificado (de un sistema anterior, o de unaversión genérica de un miembro "prototipo" de una familia). Las incertidumbres asociadas conla construcción de un sistema sin precedentes son nulificadas, o al menos aisladas, por el métodode líneas de productos, pues los problemas generalmente ya han sido encontrados y resueltos poranteriores miembros de la familia [Bronsword 96].

Una línea de productos es una familia de sistemas diseñada (arquitectura de software) para tomarventaja de los aspectos comunes y variaciones pronosticadas de los miembros de la familia[Weiss 99].

En línea de productos, el desarrollo de nuevos sistemas llega a convertirse más en materia deconstrucción que de elaboración; la actividad predominante es la integración en lugar de laprogramación. Así como la evolución de un sólo producto (modificaciones, actualizaciones)debe ser considerada dentro de un contexto más amplio; la evolución de la línea de productoscomo un todo [Solderitsch 96].

Una línea de productos enfatiza el reuso, a veces en formas que no son muy evidentes. Losaspectos que pueden ser reusados por todos los miembros de una línea de productos son[Bronsword 96]:

• Componentes: los componentes son utilizados en todos los productos individuales. Loscomponentes son diseñados para reusarlos, el concepto de reuso del código es aplicado alo largo y ancho del desarrollo, este esfuerzo (frecuentemente difícil) es considerado unainversión. Los diseños de componentes exitosos son capturados y reusados. Esteproceso también incluye el diseño de las interfaces de los componentes, sudocumentación, sus planes de prueba y procedimientos, y algunos modelos (tal comomodelos de desempeño) usados para predecir su comportamiento.

• Personal: debido a la generalidad de las aplicaciones, el personal puede ser transferidoentre proyectos dependiendo de como se requiera. Esta experiencia es aplicable en todala línea de productos.

• Eliminación de defectos: ya que los errores son eliminados en un componente de unproducto, incrementando la calidad de los componentes corregidos y de todos los otrosproductos, esto genera confianza y la calidad se incrementa.

• Experiencia en la planeación de proyectos: porque la experiencia obtenida es unindicador de alta fiabilidad en el desempeño, presupuesto y calendarización; haciendo aestos tres aspectos más predecibles.

11

• Análisis de desempeño: Modelos de desempeño, análisis de planeación, características desistemas distribuidos (tal como, ausencia de deadlocks), asignación de procesos aprocesadores, esquemas de tolerancia de fallas y políticas de redes, pueden sertransferidas de producto a producto.

• Procesos, métodos y herramientas: procedimientos de control de configuración, planes dedocumentación y procesos aprobados, herramientas y otras actividades de soporte para eldesarrollo que se realicen, pueden ser transferidas de producto a producto.

• Sistemas de muestra: Productos desarrollados sirven como prototipos de demostración dealta calidad. La satisfacción del cliente se incrementa (y el riesgo disminuye). Losproductos desarrollados también sirven como prototipos de modelos de desempeño.

Entre otros beneficios de las arquitecturas de software para líneas de productos se encuentran:mejora la evolución de la arquitectura en el tiempo, capacidad de soportar una mayor cantidad demiembros en la línea de productos, tienen un diseño para el cambio, nos dan una ventajacompetitiva en el mercado con respecto al tipo de aplicaciones, la inversión económica en laproducción es amortizada por todo el conjunto de miembros que son producidos.

2.8 Ingeniería de dominios.

Los casos exitosos de arquitecturas de software para líneas de productos que se encuentran en laliteratura, muestran que no existe una práctica estándar para la obtención de una arquitectura desoftware para líneas de productos, pues en cada proyecto utilizaron diferentes métodos. Aunqueno existe una práctica estándar, los aspectos técnicos para realizar el reuso de software están bienestablecidos, definiendo que en el proceso de obtención de la arquitectura deben considerarse lossiguientes elementos [Bronsword 96]:

• Análisis de dominio: producir un modelo de dominio de una línea de productos queidentifique cuales son las generalidades de todos los miembros, e identificar las formas enlas cuales pueden variar de uno a otro.

• Metodología de diseño a partir de un diseño basado en componentes: aplicando losprincipios de separación de concerns (intereses), el ocultamiento de la información paraidentificar los componentes que la arquitectura comprende, y asignar roles yresponsabilidades a cada uno; cada componente diseñado tendrá una interface que provealos servicios al sistema, de una forma independiente a la implementación.

• Arquitectura de referencia: adoptar una infraestructura estándar (esqueleto) que seaplique a todos (actuales y potenciales) los miembros de la línea de productos.

Estas etapas se presentan en varios métodos para la obtención de arquitecturas; y en ningúnmomento está presente la implementación. El proceso que incorpora las etapas antes descritas,así como la implementación, actualmente se le denomina ingeniería de dominios.

El concepto de ingeniería de dominios se originó por parte de la comunidad de reuso de software,al tener que establecer la diferencia entre desarrollar para reusar y desarrollar por medio dereuso. Desarrollar por medio de reuso considera para la construcción de una aplicación, la

12

existencia de los componentes, los cuales pudieron haber sido comprados o desarrollados conanterioridad; a partir de los componentes es que se realiza un análisis y diseño para obtener laaplicación. Desarrollar para reusar tiene el propósito de diseñar los componentes reusables yposteriormente realizar su implementación, también puede considerarse el desarrollo de ungenerador de aplicaciones para simplificar la construcción de las aplicaciones.

La comunidad ha establecido que desarrollar para reusar sea denominado Ingeniería deDominios, y desarrollar por medio de reuso, Ingeniería de Aplicaciones.

Los objetivos de la ingeniería de dominios son identificar, derivar, organizar, abstraer yrepresentar las similitudes y diferencias entre las características de un dominio de aplicaciones enparticular. Esto facilitará la reusabilidad en los productos.

Ingeniería de dominios se define como [Sodhi 99]: un proceso para construir un elemento quepueda ser administrado y reusado. Las etapas que la comprenden son:

• Análisis del dominio: es el proceso de descubrir aspectos comunes y diferentes en variossistemas que estén relacionados, limitar con cuidado el dominio, organizar y entender lasrelaciones entre los elementos del dominio, y representar ese entendimiento de una formaútil [Krut 96]. Sus objetivos son definir el alcance del dominio y la modelación decaracterísticas. El alcance del dominio determina qué sistemas y característicascorresponden al dominio y cuáles no. La modelación de características identifica lascaracterísticas variables y comunes de los conceptos del dominio y las dependencias entrelas características variables [Czarnecki 99].

• Diseño del dominio: Su propósito es desarrollar una arquitectura común para la familiade sistemas.

• Implementación del dominio: Se refiere a la implementación de componentes,generadores, y la infraestructura para la utilización de los componentes (interfaces alusuario, menús, etc.).

La secuencia de etapas de la Ingeniería de dominios, constituyen un marco importante, pero serequiere de un método de análisis, diseño, e implementación para el desarrollo de una línea deproductos de un dominio en particular. De acuerdo con la clasificación de [Karlsson 95], elmétodo propuesto en la tesis, está ubicado en el de línea de productos, desarrollado para unmétodo interno, y con componentes extensos. Para la clasificación de componentes de [Radding96], los componentes son del tipo server-side. El método propuesto aplica el enfoque deingeniería de dominios para construir arquitecturas de líneas de productos.

En el Capítulo 3 presentamos un método para el análisis y diseño de una línea de productos, elcual comprende a las etapas de análisis y diseño de la Ingeniería de dominios; los productosresultantes del método son: modelo de dominio, arquitectura de software para la línea deproductos y componentes reusables.

La etapa de implementación de la línea de productos, es mostrada en los Capítulos 5 y 6. ElCapítulo 5 describe una técnica de implementación de componentes, y el Capítulo 6 lascaracterísticas de un generador de aplicaciones.

13

Capítulo 3. Método de análisis y diseño para la línea de sistemas.

La propuesta de arquitectura de software para líneas de productos no define el método a seguirpara su obtención, tampoco si debe utilizarse el paradigma de objetos o el estructurado para sucodificación, pero con su teoría establece los conceptos y propósito. El desarrollo de unaarquitectura de software para una línea de productos comprende etapas parecidas a las del ciclode vida clásico pero con alcances diferentes. Con base a la teoría y definiciones de ingeniería dedominios y de arquitecturas de software, en este capítulo se propone un método para el análisis ydiseño de familia de sistemas. El capítulo inicia describiendo las deficiencias de los métodos deanálisis y diseño orientado a objetos, razón por la cuál no se utilizó un método de este tipo para eldesarrollo de la línea de productos.

3.1 Los métodos actuales.

Un método universal para obtener arquitecturas de software para líneas de productos aún no se hadefinido [Czarnecki 99]. En cambio, existe actualmente una gran variedad de métodos deanálisis y diseño de dominios; la mayoría de estos orientadas a objetos (00), dado los beneficiosque brinda este tipo de programación [Rumbaugh 91] [Shlaer 88] [Booch 94] [Coad 90] [Martin93].

Pero, la mayoría de los métodos de análisis y diseño 0 0 también se enfocan en el desarrollo deun solo sistema, en lugar de producir una línea de sistemas. Además, no soportan de formaadecuada el reuso de software. Específicamente, tienen las siguientes deficiencias [Czarnecki99][Weiss 99]:

• Ninguna diferencia entre desarrollar para reusar y desarrollar por medio de reuso:requiere dividir el proceso de desarrollo de software 0 0 en desarrollo para el reuso y eldesarrollo por medio de reuso. El propósito del desarrollo para reuso no es sólo unsistema, sino una línea de sistemas. Esto permite la producción de componentesreusables. El proceso del desarrollo por medio de reuso ha sido diseñado para utilizar loselementos reusables producidos durante el desarrollo para reusar. Los actuales procesosde análisis y diseño 0 0 carecen de esas propiedades.

• Ninguna etapa de delimitación del dominio: debido a que los métodos de análisis ydiseño 0 0 se enfocan al proceso de un solo sistema, estos carecen de una fase de alcancedel dominio, en donde la clase (tipo) de sistemas sea seleccionada. También, el análisis ydiseño 0 0 se enfoca en satisfacer "al cliente" de un solo sistema, en lugar de analizar ysatisfacer los requerimientos de una clase de sistemas.

• Ningún mecanismo de diferenciación para modelar variabilidad entre una aplicación yentre varias aplicaciones: las actuales notaciones OO no hacen diferenciación entre lavariabilidad que exista dentro de la aplicación, por ejemplo, la variabilidad de los objetosen el tiempo y el uso de diferentes variantes de un objeto en diferentes situaciones en una

14

aplicación; y en caso de la variabilidad entre aplicaciones, no existe diferenciación devariabilidad entre diferentes aplicaciones para diferentes usuarios y contextos de uso.Además, los mecanismos de implementación para codificar la variabilidad entreaplicaciones, como el polimorfismo dinámico, da como resultado frameworks ocomponentes grandes y por consiguiente aplicaciones grandes.Ninguna notación para modelar la variabilidad que sea independiente de laimplementación: además de que las actuales notaciones 0 0 no permiten modelar lavariabilidad de una forma independiente a la implementación, por ejemplo, cuando sedibuja un diagrama de clases en UML [Booch 98], se tiene que decidir si usar herencia,agregación, parametrización de clases, o algún otro mecanismo de implementación pararepresentar un punto de variación dado.

En la literatura, el marco teórico de los métodos que corresponden a la Ingeniería de dominioscomo Kaptur [Bailin 92], Idefo [U.S.DOD 94], Joda [Holibaugh 92] y Foda [Kang 90] es escaso,mostrando únicamente descripciones textuales resumidas de los conceptos y etapas a seguir parala obtención de los elementos comunes entre aplicaciones relacionadas. Estos métodos sonproductos comerciales de alto costo.

Para el desarrollo de la arquitectura de software para la línea de productos proponemos ladefinición de un propio método. El método propuesto (ADLIS, descrito en la sección 3.2) sefundamenta en varias técnicas (Foda, casos de uso, arquitecturas por niveles) tomando lo másadecuado de ellas, con el propósito de obtener modelos arquitectónicos aptos para la producciónde familias de sistemas.

Análisis del dominio Diseño del dominio Implementación del dominio

Análisisdel dominio

modelo deldominio

Desarrollo de laArquitectura de

software

arquitecturade softwarepara líneas

de productos

Desarrollo delos componentes

reusables yGenerador

Proceso Producto

Figura 3.1 Ciclo de vida de ADLIS.

componentesreusables ygenerador

Desarrollo de laaplicación por

medio delGenerador

15

El desarrollo de una línea de productos por medio de ADLIS comprende etapas parecidas a lasdel ciclo de vida clásico, pero con alcances diferentes (Véase Figura 3.1):

• Análisis de dominio es un proceso que consiste en identificar el dominio, definir elalcance, analizar el espacio del problema y definir el espacio de la solución (modelo deldominio).

• Diseño del dominio o modelación arquitectónica, es un proceso cuyo objetivo es dar unarepresentación de la estructura modular que conformará la arquitectura de software. Laarquitectura de software para líneas de productos define módulos que serán componentesreusables. Por medio de este proceso se estructura y captura la información relevantepara realizar los componentes y guías (modelos de diseño) que conducen los procesos.

• Implementación del dominio es el proceso de codificación de los componentes derivadosdel diseño, así como el desarrollo de un generador de aplicaciones que produzca losdiferentes productos. De acuerdo a los requerimientos del cliente, al generador se leindican las características del producto deseado, para de esta forma obtener unaaplicación.

3.2 Método ADLIS.

El método propuesto, denominado Análisis y Diseño para la Línea de Sistemas (ADLIS), estábasado en el concepto de abstracción. La abstracción es usada para obtener componentesgenéricos y específicos de un dominio de aplicaciones. Estos componentes genéricos abstraen lafuncionalidad y el diseño de las aplicaciones. La naturaleza genérica de los componentes escreada abstrayendo "factores" que hacen una aplicación semejante de otras aplicaciones en undominio particular. ADLIS es aplicado para el desarrollo de una familia de sistemas decontabilidad para Uniones de crédito (Capítulo 4).

3.2.1 Fase de análisis.

La fase de análisis se enfoca en la definición del dominio de aplicaciones, y la exploración de lossistemas del dominio para descubrir y explotar las características semejantes. El análisis revelael conjunto de características que son comunes en una familia de sistemas y es representado deuna forma que ayude al desarrollo e implementación de los productos. Como parte del análisisse propone un patrón para el diseño de los requerimientos, que será utilizado en la fase de diseño.

3.2.1.1 Definición del dominio de aplicaciones.

Como primer paso se tiene que definir la viabilidad de la línea de productos elegida por medio deun análisis, para determinar las justificaciones del desarrollo de una línea de productos. De esteanálisis depende el éxito o fracaso, ya que una línea de productos no debe aplicarse en todos loscasos de desarrollo de software; el análisis previene de realizar inversiones cuantiosas. Entre losaspectos que debe contener el análisis están: definición de la familia de sistemas, definición delmercado y justificaciones.

16

3.2.1.2 Análisis de contexto.

El propósito del análisis de contexto es definir el alcance de un dominio. Las relaciones entre eldominio y elementos externos (medios operativos, requerimientos de datos, etc.) son analizadas,así como las variaciones son evaluadas. Los resultados son documentados en un diagrama decontexto, el cual muestra las entidades externas y los flujos de datos entre el dominio y lasentidades externas.

3.2.1.3 Descripción detallada de las aplicaciones y definición derequerimientos.

Durante esta etapa, es realizado un análisis de las aplicaciones y sus requerimientos. Losaspectos que debe contener son: definición de las aplicaciones (miembros de la familia desistemas), determinar los requerimientos de las aplicaciones, determinar que requerimientoshacen diferentes a las aplicaciones, e identificar los requerimientos que no serán analizados por elmétodo, porque no son buenos candidatos para su desarrollo por medio de componentes.

La determinación de los requerimientos que no son analizados por el método, es realizado pormedio de una clasificación de los tipos de operaciones que realizan: 1) los requerimientos querealizan operaciones de mantenimiento de información, y 2) los requerimientos que realizanoperaciones de reglas de negocio. Los requerimientos que involucran operaciones demantenimiento de información (altas, bajas y modificaciones de datos) no son analizados, suimplementación es directa (no son utilizados componentes).

3.2.1.4 Análisis de requerimientos entre productos.

Los requerimientos de todos los miembros de la familia de sistemas, deben analizarse paraidentificar la variabilidad y semejanzas; el resultado del análisis es la definición de lascaracterísticas a nivel sistema de cada producto en su contexto general.

3.2.1.5 Análisis de características.

Durante este análisis, los requerimientos de toda la familia de sistemas son capturados en undiagrama, y estos son clasificados por sus características. Las características describen elcontexto del dominio de las aplicaciones, las operaciones necesarias y la representación devariaciones. Sus resultados son importantes porque el modelo de características generaliza yparametriza los modelos producidos. Las características se definen como alternativas, opcionalesy principales. Las características principales representan las características base y susrelaciones. Las características alternativas u opcionales representan la especialización decaracterísticas más generales, representan qué cambios muy probablemente ocurren en diferentescircunstancias.

17

3.2.1.6 Definición del patrón para el diseño.

En esta etapa se propone el establecimiento de un patrón de etapas de procesos, que servirá deguía para el diseño de cada requerimiento. Su definición se debe al patrón de comportamientoque generalmente siguen las aplicaciones.

La identificación del patrón también debe apoyarse en un análisis previo con un pequeño grupode diagramas de flujo de datos; primero se proponen etapas de procesamiento, posteriormente secomprueba que sean aplicables para todos los casos, y por último se establece un orden osecuencia.

Una vez definido el patrón de etapas de procesos, este es utilizado como un medio deestandarización en todos los diseños (diagramas de flujo de datos). Es decir, todos los procesoscontenidos en un diseño estarán ordenados de acuerdo al patrón. Por otra parte, en el momentode realizar los diseños, los procesos pueden seguir esta secuencia de acciones, como unaestrategia que también facilite la elaboración del mismo diseño.

3.2.2 Fase de Diseño.

La fase de diseño es realizada por medio de diagramas de flujo de datos y de un análisisoperacional a estos. En el análisis operacional se identifican las características delcomportamiento de los procesos de los diagramas de flujo de datos. Esta actividad producefunciones para posteriormente estructurarlas, dando una secuencia a dichas funciones en unmodelo operacional denominado colaboración. El control y flujo de datos de una aplicaciónindividual se derivan de las colaboraciones que le corresponden.

3.2.2.1 Diagramas de flujo de datos.

Los diagramas de flujo de datos (DFD) representan la secuencia de operación de los datos, estopermite identificar los procesos y los resultados. En la construcción de los DFD's se debeprocurar:

• Mantener el orden de ejecución de las reglas de negocio.• Almacenar los resultados de los procesos en tablas temporales. Las tablas temporales van

incorporando nueva información conforme se ejecutan los procesos.• Dividir los diagramas en tres áreas (franjas), en el lado izquierdo colocar las solicitudes de

información a las tablas de la base de datos, en el centro los procesos, y en el lado derecholas tablas temporales usadas.

• Obtener el DFD de último nivel o con la mayoría de los elementos representativos.• Los datos proporcionados por el usuario al inicio de los procesos, son considerados

globales.

Posterior a la elaboración del DFD, se realiza un análisis operacional a partir de las siguientesreglas de modelación:

18

• Identificar los procesos que involucren cálculos.• Identificar procesos para dar formatos de presentación de la información.• Identificar los procesos que solamente realizan operaciones de almacenamiento a una

tabla temporal, el código de este tipo de proceso se incorporará en el proceso anterior.• Identificar la información que es solicitada a la base de datos.• Identificar las tablas temporales utilizadas.• Identificar los datos proporcionados por el usuario, al inicio de los procesos, estos datos

serán considerados en la implementación como variables globales.

El resultado del análisis operacional es una tabla de clasificación de procesos y la identificaciónde tablas utilizadas de la base de datos.

3.2.2.2 Colaboración.

El siguiente paso consiste en la elaboración de la colaboración; es un diseño de alto nivel. Seenfoca en la identificación de operaciones concurrentes y módulos comunes orientados aldominio. Define el orden y características de las operaciones. Hace uso de un registro deoperaciones para identificar que operación ya fue definida.

La construcción de la colaboración consiste en tomar de la tabla de clasificación su información,y ordenar en forma descendente de acuerdo al patrón de diseño (Sección 3.2.1.6):

Io. Los tipos de información solicitada.2o. Los procedimientos del reporte.3o. Los procedimientos de presentación.

Los elementos de construcción de la colaboración son las operaciones. Las operaciones son losprocesos resultantes de la tabla de clasificación (estos procesos a su vez son resultado del análisisoperacional del DFD). Las etapas del patrón son utilizadas en la colaboración para ordenar lasoperaciones, estas etapas son consideradas en la colaboración como categorías.

Las categorías forman grupos de operaciones, los cuales tienen el propósito de facilitar laasignación de los nombres a las operaciones. El nombre de una operación depende de lacategoría donde se encuentra y su función en general. Los grupos de las operaciones tambiénfacilitan la identificación de las mismas. En caso de no existir la operación en la categoría(grupo), se nombra una nueva operación. El medio que lleva el control de las operaciones es unregistro de las operaciones (Sección 3.2.2.3), a través del cual se identifica qué operaciones yafueron definidas.

El orden que determina el patrón de diseño, no restringe la posibilidad de colocar una operaciónde la categoría Selección de información dentro de alguna de las otras; salvo esta excepción, laintención principal es seguir el orden del patrón de diseño.

19

El último paso en la etapa de la elaboración de la colaboración, es la aplicación de tres reglas paraidentificar los tipos de comportamiento de las operaciones:

• En los diagramas de flujo de datos, se localizan los procesos de cálculos que involucrenoperaciones para un determinado rango de información. Los enunciados que describenestos procesos son revisados para identificarles las preposiciones, y de esta forma asignarel tipo de comportamiento para la operación.

• En los diagramas de flujo de datos, se localizan los procesos que dan formatos depresentación de la información, por cada resultado diferente que den, le es asignado untipo de comportamiento a su operación.

• A cada tipo de comportamiento identificado se le asigna un número consecutivo, alprimer tipo le corresponde el cero, al segundo tipo el uno, el tercer tipo el dos, y asísucesivamente. Al finalizar la identificación de operaciones de todo el sistema, a lasoperaciones que sólo tengan un tipo (cero), se les considera que no tengan tipo.

Como se menciono anteriormente, cada nueva operación identificada es agregada a una listadenominada registro de operaciones. De igual forma, cada tipo de comportamiento identificadode alguna operación, es agregado al registro de operaciones como si se tratará de una operaciónmás. (Véase Tabla 4.4)

3.2.2.3 Registro de operaciones.

El registro de operaciones es una lista donde se registran todas las operaciones diferentes que seidentifican en el proceso del diseño y análisis operacional. Permite identificar si una nuevaoperación que se proponga, ya había sido definida. Su propósito principal es el de servir dereferencia, para utilizar las operaciones ya definidas en las nuevas colaboraciones. Junto con lasoperaciones se registran sus diferentes tipos de comportamiento, únicamente por el número detipo de comportamiento asignado.

Una tarea a realizar una vez obtenida la tabla de registro de operaciones, es identificar lasoperaciones que hacen las veces de funciones. La identificación también es con ayuda de losDFD's. Para estas operaciones se hace una clasificación:

a) Las operaciones que no tienen una participación directa en la secuencia principal deejecución de operaciones de la colaboración, su propósito es de apoyo a otra operación,no contienen mas de una función, regresan un solo dato, y su uso es frecuente.

b) Las operaciones que tienen una participación directa en la secuencia principal deejecución de operaciones, su propósito principal es ser una etapa en la secuencia de lacolaboración, pero para otras colaboraciones se utiliza como una función que apoya a otraoperación que sí forma parte de la secuencia principal de una colaboración.

La última actividad de la etapa de registro de operaciones es la elaboración de una Tabla Final, enla que se muestra la nueva categoría, las operaciones que corresponden a cada categoría, y laasignación a cada operación de un tipo que determina su función en la colaboración.

20

A partir de este punto las operaciones son denominadas como componentes, dado que es eltérmino técnico que se utiliza para su implementación. Para simplificar la utilización de losnombres de las operaciones en la implementación, éstas son renombradas por un nombre máscorto.

3.2.2.4 Componentes complementarios.

Tres componentes se agregan al conjunto de los componentes ya identificados: Inicial, Final yGlobales. Los componentes Inicial y Final tienen como propósito delimitar el inicio y final de lacolaboración. No contienen algún código a ejecutar. El componente inicial es colocado alinicio de los componentes que correspondan a una colaboración, con el componente final ocurrelo mismo pero en la posición final.

Las variables globales identificadas en los análisis operacionales (Tabla 4.3) estarán contenidasen un componente denominado Globales.

Estos componentes junto con la categoría de Funciones, dan como resultado la estructura final dela colaboración. El propósito de tener un tipo de categoría como Funciones, es separar loscomponentes tipo Función, de los componentes que contienen los procedimientos principales,para facilitar la identificación de las funciones que están disponibles en la colaboración.

El componente Globales, no es colocado dentro de la secuencia de componentes de lacolaboración, pero por medio de una técnica en la codificación, cualquier componente puedeacceder a sus variables contenidas.

Con esta última etapa termina la definición del método ADLIS, en el siguiente capítulo esmostrada la aplicación del método para una línea de sistemas de contabilidad.

21

Capítulo 4. Aplicación del método ADLIS.

Con base en la teoría y definiciones de ingeniería de dominios y de arquitecturas de software, seha definido un método para el análisis y diseño de líneas de sistemas. La aplicación de ADLISpara el desarrollo de una arquitectura de software para una línea de productos comprende etapasparecidas a las del ciclo de vida clásico pero con alcances diferentes. El capítulo muestra laaplicación de ADLIS en la producción de una línea de sistemas de contabilidad para Uniones decrédito, ejemplificando los productos que deben obtenerse en cada etapa.

4.1 Fase de análisis.

La fase de análisis se enfoca en la definición del dominio de aplicaciones, es decir la exploraciónde los sistemas del dominio para descubrir y explotar las características y la definición de unpatrón para el diseño. Con base al seguimiento del método ADLIS, las siguientes seccionesdescriben los productos resultantes del análisis.

4.1.1 Definición del dominio de aplicaciones.

El primer paso del método es definir el dominio de las aplicaciones en el que se desarrolla laarquitectura. El dominio de aplicaciones elegido, es el de Sistemas de Contabilidad paraUniones de Crédito, el cual consideraremos nuestra línea de productos. Los productos resultantesson sistemas de información (sistemas de contabilidad). Cada sistema de información deberásatisfacer las necesidades básicas de control de información del departamento de contabilidad deUniones de Crédito de diversos sectores industriales y de servicios del país.

Una Unión de Crédito es una institución financiera cooperativa, controlada por sus miembros(socios) y propiedad de sus miembros, formada para permitir a las personas ahorrar, tomarpréstamos, obtener servicios financieros relacionados y participar en su administración. Estasinstituciones son parte del sector bancario y financiero de México, regidas por la ComisiónNacional Bancaria y de Valores (Gobierno de México). Su función es la de complementar elapoyo crediticio a la micro, pequeña, y mediana empresa, en condiciones más favorables que lasinstituciones bancarias de mayor tamaño (Bancomer, Banamex, etc.).

Generalmente las Uniones son formadas por personas del mismo giro o actividad, existenUniones de ganaderos, industriales, agricultores, empleados del sector salud, muebleros,constructores, etc.

Entre los sistemas de información utilizados por las Uniones, se encuentran los sistemas decontabilidad, las características que presentan son las propias de los sistemas para una línea deproductos:

22

• Productos de un mercado vertical.• Tienen un conjunto de operaciones y actividades similares (procesos para ingresar la

información y tipos de reportes requeridos por la CNBV).• Cada producto debe satisfacer requerimientos propios de la Unión (reportes con varias

formas de presentar la información, reportes propios), que los hace diferentes.• Los resultados son obtenidos por medio de algunos procesos muy bien identificados, que

aparecen repetitivamente en varios requerimientos.• Los procedimientos que se realizan en la contabilidad han sido definidos desde hace

mucho tiempo, por lo que programar sus procesos, consiste en seguir las reglas yaestablecidas.

Tradicionalmente, las empresas desarrolladoras de software para las Uniones de crédito, optanpor alguna de las siguientes opciones para desarrollar:

• Construcción de un sistema tipo estándar (sistema único).• Construcción de sistemas individuales para cada cliente.

En la primera opción los clientes tienen que adaptarse a las posibilidades que ofrezca el sistemaestándar, limitando el potencial de beneficios que pueden brindar los sistemas de información.Los clientes saben que los sistemas de información pueden "manejar" la información de muchasmaneras, pero con los sistemas tipo estándar no es posible:

• Agregar otras opciones (módulos para reportes específicos, formas de presentación deinformación, módulos para reportes propios de la Unión).

• Modificar las opciones presentes, con el propósito de adecuarlos a sus necesidades.

Las Uniones de crédito que adquieren este tipo de sistemas, necesitan de software adicional(Excel, Lotus, etc.) para poder realizar sus actividades, debido a lo restringido en cuanto a lasposibilidades que brindan los sistemas estándares (COI-Aspel, Conta-Plus, etc.).

En la segunda opción para desarrollar sistemas, se construyen sistemas a la medida para cadaUnión de crédito. Esta opción es la que debería elegirse, ya que todas las Uniones aunque tienenun marco en común, también tienen necesidades específicas, debidas principalmente al sectoreconómico en que se encuentren; estas diferencias son generalmente reportes de informaciónespecífica.

Los sistemas para Uniones de crédito son un nicho de mercado que no ha sido explotado deforma adecuada, todas las Uniones trabajan con sistemas de información sin embargo, sóloaquellas que han invertido en la construcción de sus propios sistemas son las que operan de mejorforma, desafortunadamente también estos sistemas dejan mucho que desear ya que generalmenteson productos de mala calidad. Existe la oportunidad de ofrecerles productos de calidad y a bajocosto, por medio del desarrollo de líneas de productos, debido en gran medida al cambio en laforma de desarrollar el software, producir sistemas "a la medida" en gran escala.

23

4.1.2 Análisis de contexto.

La ubicación en el contexto de operación del sistema de contabilidad para Uniones de crédito esmostrado en la Figura 4.1.

Departamento de contabilidad

Auxiliares encontabilidad

Reportesauxiliares

Contadorgeneral

Direcciónadministrativa

Reportesauxiliares y

oficiales

Sistema de informaciónfinanciera (SIF) de la

CNBV

Base de datos

Figura 4.1 Modelo de contexto del sistema de contabilidad.

Los elementos involucrados con el sistema de contabilidad para Uniones de crédito son:

• Los auxiliares en contabilidad son quienes alimentan de información al sistema, susactividades con el sistema son: mantener el catálogo de cuentas, actualizar las reglas deagrupación, pero la actividad principal es la captura de pólizas de contabilidad. Paracomprobar la información que almacenan, obtienen los reportes auxiliares y verifican lascantidades de las cuentas.

• El contador general es la persona autorizada para ejecutar en el sistema los cierresmensuales y del ejercicio, sus actividades con el sistema son: comprobar la informacióncapturada por medio de los reportes auxiliares, y obtener los reportes oficiales para suanálisis y posterior entrega a los directivos de la Unión.

• La dirección administrativa obtiene los reportes oficiales una vez que el contador realizael cierre del período.

• El sistema interactúa con un administrador de base de datos relaciónales (RDBMS,relational datábase management system), las interacciones son por medio solicitudes yenvíos de información. El RDBMS atiende las solicitudes (comandos SQL) y envía losdatos seleccionados.

24

• El sistema de información financiera (SIF) es un sistema entregado a cada Unión paragenerar dos archivos tipo texto y posteriormente enviarlos a la CNBV, los archivoscontienen información de la Unión y su situación financiera en un período. Antes degenerar los archivos el personal de la Unión debe capturar los saldos de todas las cuentasexcepto las de detalle. Esta captura puede realizarla el sistema de contabilidad por mediodel traspaso de los saldos del sistema a la base de datos del SIF.

Por lo expuesto en el modelo de contexto (Figura 4.1), se identifica que el sistema decontabilidad opera de forma independiente, porque no necesita de datos de otros sistemas para sufuncionamiento. Los requerimientos técnicos para el sistema de contabilidad son lostradicionales para una aplicación que opera sobre Windows.

4.1.3 Descripción detallada de la aplicación y deñnición de requerimientos.

Los sistemas de contabilidad para Uniones de crédito son sistemas de información desarrolladospara almacenar datos y ejecutar los procesos de Contabilidad para organizaciones auxiliares delcrédito, las reglas de este tipo de Contabilidad son establecidos por la CNBV. La contabilidadpara Uniones se basa en la contabilidad por partida doble, la mayoría de los procesos de este tipode contabilidad así como otros, fueron definidos desde hace muchos años. Sus procesosinvolucran generalmente sumas, restas, multiplicaciones y operaciones con una "mecánica" fija,así como la lógica de sus procesos no presenta razonamientos complejos. Esto ha facilitado laautomatización (por medio de sistemas de información) de la contabilidad, en sus diversos tipos.

Los sistemas de contabilidad a producir serán para Uniones de los tipos: comercial, industrial, yagropecuaria, es decir, son producidas tres tipos de aplicaciones. Los requerimientos básicos deun sistema de Contabilidad para Uniones de crédito son:

• Catálogo de cuentas: Ejecutar opciones de altas, bajas, modificación y consulta decuentas que formarán el catálogo.

• Reglas de contabilidad: Ejecutar opciones de altas, bajas, modificación y consultas dereglas de agrupación, que estipula la CNBV para la construcción de reportes como elBalance general y el Estado de resultados.

• Pólizas: Realizar altas, bajas, modificación y consulta de pólizas, permitiendo manejarvarios tipos de pólizas, generación automática del número consecutivo de la póliza,comprobación de saldos, e ingreso de conceptos particulares.

• Reportes auxiliares: Reporte de Saldos (muestra los saldos de las cuentas, cargos, abonos,y saldos anteriores), Diario (muestra por día las pólizas que fueron operadas, sus saldos,cargos y abonos), Mayor (muestra los saldos de las cuentas de nivel mayor), Auxiliares(muestra por cuenta los movimientos que tuvieron), y Balanza de comprobación (muestralos movimientos ordenados por fecha, de las cuentas de nivel mayor).

• Reportes oficiales: Realizar los reportes de Balance General y Estado de resultados.• Reportes opcionales: Relación de responsabilidades, SIF, etc.• Cierres: Ejecutar el cierre mensual (cancela los saldos del período y abre el siguiente

período), y el cierre del ejercicio (es una operación especial que se realiza al final del año,cancela los saldos de las cuentas del último mes, hace una póliza de cierre del ejercicio, yabre el nuevo período y ejercicio).

25

Los requerimientos que hacen diferente a cada sistema, se encuentran en los reportes auxiliares yopcionales; estos reportes son solicitados con características propias dependiendo de la unión.

De los requerimientos se hace una clasificación dependiendo de los tipos de operaciones querealizan:

Operaciones de mantenimiento de la informaciónCatálogo de cuentasReglas de contabilidadPólizas

Operaciones de contabilidadReportes oficialesReportes auxiliaresReportes opcionalesCierres

Tabla 4.1 Tipos de operaciones de los sistemas de contabilidad para Uniones.

Las operaciones de mantenimiento de la información (Tabla 4.1), representan los requerimientosque ejecutan las operaciones para ingresar la información utilizada en los procesos de reportes;realizan altas, bajas, modificaciones y consultas de las cuentas, reglas de agrupación, y pólizas decontabilidad. Por la otra parte, los requerimientos de operaciones de contabilidad, involucranobtener información de la base de datos, procesarla y mostrar un resultado al usuario.

Esta clasificación se realizó porque los requerimientos sobre operaciones de mantenimiento de lainformación, serán implementados directamente, no son considerados en el método de análisis ydiseño, porque son requerimientos siempre presentes, internamente no ejecutan procesamiento dedatos, y no tienen variaciones significativas.

Los requerimientos que involucran procesamiento de la información, son los considerados por elmétodo de análisis y diseño, por sus características adecuadas para el desarrollo de laarquitectura, cada uno de estos requerimientos son interpretados en el ámbito de las arquitecturasde software, como las aplicaciones o productos de la línea de productos, es decir, cadarequerimiento (reporte o cierre) que involucra operaciones de contabilidad es un producto,independientemente del tipo de sistema que se esté desarrollando para una Unión de crédito.

Cuando se produce un sistema para una Unión de crédito, primero se define el tipo de Unión alcual estará dirigido, a partir de esta definición se determina los requerimientos que correspondenal tipo de sistema, de esta forma se cumple el producir un producto de la línea de productos, apartir de un conjunto de característica en común. Pero, por las características que presentan lossistemas de contabilidad, también es posible considerar a cada requerimiento que involucraoperaciones de contabilidad como un producto de una línea de productos, porque también entrelos requerimientos se presentan características en común, sólo que en este caso son reglas decontabilidad (reglas de negocio), repetitivas en muchas situaciones, por lo que se decidió que laarquitectura de software de la línea de productos a desarrollar, se enfocará en el desarrollo decomponentes que ejecutan procesos de contabilidad. De otra forma, pudo haberse desarrolladouna arquitectura en la que cada componente representara un requerimiento completo, e integrarseúnicamente por medio del tipo de sistema a producir.

26

La obtención de un producto de la línea, se logra por medio de la integración de losrequerimientos que definirán el tipo de producto. Cada requerimiento se implementa mediantevarias reglas. Una regla de contabilidad es la etapa de un proceso. Una misma regla puede serutilizada para la obtención de varios requerimientos (en este caso reportes o cierres). Cada reglaes implementada como un componente.

4.1.4 Análisis de requerimientos entre productos.

En esta fase se analizan los requerimientos para identificar la variabilidad entre los productos ydefinir la arquitectura de cada producto en su contexto general. (Véase Tabla 4.2)

Las características que definen el tipo de sistema se encuentran en los reportes auxiliares,identificando de esta forma la variabilidad entre los productos a nivel requerimientos. Losrequerimientos sobre reportes opcionales, no se consideran para identificar variabilidad, dado quepueden estar o no presentes, independientemente de la Unión. Todos los otros requerimientosdeben estar presentes en los productos.

Como se mencionó anteriormente, los requerimientos que involucran ingreso de información noserán implementados de forma directa, es decir, su implementación no será por medio decomponentes. Esto es debido a que son requerimientos siempre presentes, su implementación essencilla, y no sugiere la necesidad de utilizar componentes.

Otros requerimientos también deben estar presentes en todos los productos, como los reportesoficiales y los cierres. No obstante, a diferencia de los requerimientos para ingreso deinformación, su implementación es recomendable por medio de componentes. Esto se puedesaber porque los resultados que dan, son obtenidos por medio de reglas de contabilidad (reglas denegocio), que en su momento también son utilizadas en los reportes auxiliares.

Requerimientos comunesy variables

CaracterísticasSistema 1

Unión de créditoComercial

Sistema 2Unión de crédito

Industrial

Sistema 3Unión de crédito

AgropecuariaIngreso de información:- Catálogo de cuentas- Grupos del Estado de resultados- Reglas de agrupación del Estado de resultados- Grupos del Balance general- Reglas de agrupación del Balance general- Pólizas

*****

******

*

****

Reportes auxiliares:- Saldos- Analítico de cuentas- Analítico por día- Mayor- Diario- Auxiliares normales- Auxiliares con cuentas sin movimiento- Auxiliares de varios períodos

**

****

**

***

*

****

*

Tabla 4.2 Línea de sistemas de contabilidad para Uniones de crédito.

27

- Balanza de comprobación previa- Balanza de comprobación por día

* **

Reportes oficiales:- Estado de resultados- Balance general * *

**

Reportes opcionales:- Relación de responsabilidades-SIFCierres:- Cierre mensual- Cierre del ejercicio

**

**

**

Tabla 4.2 Línea de sistemas de contabilidad para Uniones de crédito (Continuación).

4.1.5 Análisis de características.

El resultado del análisis de características es un diagrama, en el que las características(requerimientos) son definidas como alternativas, opcionales y principales. Las característicasprincipales representan las características base y sus relaciones. Las características alternativas yopcionales representan la especialización de características más generales. Representa lassemejanzas y los cambios o variaciones que ocurren en los diferentes sistemas de contabilidadpara Uniones de crédito (comercial, industrial, y agropecuaria). (Véase Figura 4.2)

4.1.6 Definición del patrón para el diseño.

La definición del patrón propuesto, es debido a la identificación del patrón de procesamientos quesiguen generalmente las aplicaciones para bases de datos (BD). Si bien no todas las aplicacionespara BD necesariamente presentan este patrón, si contienen la mayoría de las etapas definidas;aunque quizá no en el orden propuesto. El desarrollo de aplicaciones de bases de datos sigue porlo general esta secuencia:

• Abrir las tablas a utilizar.• Inicializar las tablas temporales que almacenan los resultados de las operaciones.• Seleccionar la información a utilizar.• Ejecutar los procedimientos principales.• Ejecutar los procedimientos para presentación de información en las tablas que muestran

los resultados.

Las etapas que corresponden al patrón son: activación de tablas, inicialización de tablas,selección de información, procedimientos del reporte y procedimientos de presentación. Estasetapas tienen una secuencia que inicia con activación de tablas. (Véase Figura 4.3)

28

Sistema de Contabilidad

Caracteristicas Principales

Catálogo

Grupos

Edo. de resultadosI

' Características Alternativas. |

Balance general

Reglas

Edo. de resultados

Características Alternativas. I

Balance general

Pólizas

Saldos

Mayor

Auxiliares

Características AlternativasI

Cuentas sinmovimientos Normales Varios

períodos

Cierres

MensualI

Características Alternativas

Ejercicio

Estado de resultados

Balance General

Caracteristicas Principales

Balanza de comprobación

Previa

Características Alternativas

Por día

Analítico de cuentas

Normal

Características Alternativas '

Por día

Diario

Características Opcionales

Relación deresponsabilidades

S1F

Figura 4.2 Diagrama de características.

29

Activación de tablas

Inicialización de tablas

Selección de información

Procedimientos del reporte

Procedimientos depresentación

Figura 4.3 Patrón para el diseño.

Descripción de las etapas del patrón para los diseños:

• Activación de tablas, en esta etapa se ubican los procesos para abrir las tablas temporalesutilizadas en el reporte o cierre.

• Inicialización de tablas, ubicación de los procesos para inicializar las tablas temporales.• Selección de información, contiene los procesos para obtener de la base de datos la

información necesaria para realizar el reporte o cierre.• Procedimientos del reporte, en esta etapa se ubican los procesos que ejecutan las reglas de

contabilidad, son los procedimientos utilizados para la obtención del reporte o cierre.• Procedimientos de presentación, ubicación de los procesos que dan algún formato de

presentación a la información mostrada al usuario.

Los procesos de las etapas de activación e inicialización de tablas no son incluidos en losdiagramas de diseño, porque su implementación está insertada en el código de las interfaces deusuario, y no en forma de componentes. El diseño comprende las etapas de selección deinformación, procedimientos del reporte y procedimientos de presentación.

4.2 Fase de Diseño.

La fase de diseño es realizada por medio de diagramas de flujo de datos y de un análisisoperacional a los diagramas, para obtener como resultado colaboraciones que constituyen laarquitectura de software para líneas de productos. Para las etapas de diseño se tomará comoejemplo el reporte de Saldos.

30

4.2.1 Diagramas de flujo de datos.

Los diagramas de flujo de datos (DFD) deben elaborarse de acuerdo a las reglas de elaboraciónde los diseños, el apego a estas reglas facilita el análisis operacional del diagrama. El propósitode esta etapa es obtener una tabla que clasifica los tipos de procesos e identifica las tablas de lasbases de datos involucradas en el reporte Saldos.

El diagrama de flujo de datos del reporte Saldos es mostrado en la Figura 4.4, y la tabla deresultante del análisis operacional es la Tabla 4.3.

Cálculos256

Presentación7

Incorporados3 ^ 2

Inf. SolicitadaCuentasPólizas

Saldos Anteriores

TemporalesRep soRepana

GlobalesPeríodo

Tabla 4.3 Tabla de clasificación del reporte Saldos.

Como muestra la Tabla 4.3, del diagrama se identificó que los procesos involucrados en loscálculos de procesamiento de información (para obtener una parte del resultado final del reporte),son los procesos: 2, 5 y 6. El único proceso para dar un formato de presentación a lainformación, es el proceso 7. El proceso que será incorporado dentro de otro, es el número 3, elcual es incorporado al proceso 2, por ser el proceso cercano; esto significa que las tareas quehabían sido definidas para el proceso 3, serán ahora realizadas por el proceso 2.

Las entidades colocadas en el lado izquierdo de los diagramas, son los almacenes de datos con lainformación que es solicitada por el reporte. La práctica más común es que cada entidad setraducirá a una tabla en una base de datos relacional. En el ejemplo de la Figura 4.4, las tablassolicitadas al software administrador de base de datos son: Cuentas, Pólizas y Saldos anteriores.Las tablas temporales utilizadas para almacenar los resultados parciales de los procesos, y elresultado final con un formato de presentación son: Repso (información de saldos) y Repana(información de saldos con nombres de cuentas). El dato proporcionado por la interface es elPeríodo, el cual es considerado como variable global.

4.2.2 Colaboración.

El siguiente paso consiste en la elaboración de la colaboración. Define el orden y tipos deoperaciones. A cada requerimiento del sistema de contabilidad, le corresponde una colaboración.

Con base a la tabla de clasificación del reporte Saldos (Tabla 4.3) y al orden de los procesos quedeben seguir las colaboraciones, los primeros procesos colocados son los que hacen solicitudesde información, enseguida los procesos para los cálculos y finalmente los procesos para darformato de presentación de la información. Los procesos en esta etapa del diseño son ahoraconsiderados como operaciones, por ser el término que se utiliza para este tipo derepresentaciones. Las etapas del patrón del diseño en las colaboraciones son consideradas comocategorías.

31

Panel de control

Período

1. Obtenerpólizas del

período

2. Sumarmovimientospor cuenta

Cuenta, Debe, Haber, Saldo

3. Almacenaren temporal

Cuenta, DebeHaber, Saldo

Período, cuenta—/ 4 ObtenersaldosSaldos Anteriores

Saldo anterior—-A anteriores porcuenta

5. Agregarsaldos

anteriores alas cuentas

Saldo anteriof ••

Cuenta, saldo anterior,debe, haber, saldo

Cuent

Nombres de Cta:

7.Agregarnombres

Figura 4.4 Diagrama de flujo de datos del reporte Saldos.

32

La definición de las operaciones es una tarea que se lleva en conjunto con la elaboración de unalista o registro de operaciones. Cada vez que una operación es definida, primero se tiene quelocalizar en el registro de operaciones, para ver si ya fue registrada (definida). Esto permitevolver a utilizar operaciones que ya fueron identificadas (la funcionalidad de la operación debeser la misma). En caso de no existir la operación, se nombra una nueva operación.

Al nombre de una operación definida, se le agrega alguno de los siguientes prefijos: Se l , Pro yPre para identificar a que categoría pertenece la operación. Las operaciones de la categoríaSelección de información les corresponden el prefijo Se l , a las operaciones de Procedimientosdel reporte el prefijo Pro, y a Procedimientos de presentación el prefijo Pre .

La Figura 4.5 muestra la colaboración para el reporte Saldos, y dentro de la categoría Selecciónde información se agrega la operación SelvalidaCtaPol, para verificar la existencia deinformación, esto es con el propósito de agregar mayor funcionalidad a la colaboración.

Operaciones. Categorías.

Sel cuentas

Sel_polizas

Sel saldos anteriores

Sel validaCtaPol

Pro Suma movimientos

Pro_Agregar_saldos_anteriores I

Pro Construcción del árbol

Pre_Agregar_nombres

Selección de información

Procedimientos del reporte

Procedimientos de presentación

Figura 4.5 Colaboración del reporte Saldos.

Otra tarea a realizar en la colaboración es la definición de los tipos de comportamiento de lasoperaciones. Los tipos de comportamiento se determinan a partir de varias reglas (sección3.2.2.2), la primera regla se aplica a las operaciones de las categorías: Selección de información yProcedimientos del reporte, en estas operaciones se procura encontrar para que tipo deinformación será realizada la operación, y una segunda regla se aplica a las operaciones de la

33

categoría Procedimientos del reporte, en estas operaciones se averigua a que tipo de tablatemporal será almacenado el resultado de una operación.

Para el caso de Selcuentas su tipo es: del período, y como esta operación es el primer tipo decomportamiento que se le identifica, es decir, no ha sido incluido en el registro de operacionesalgún comportamiento para esta operación, el número de tipo de comportamiento que lecorresponde es cero. El tipo de comportamiento de la operación debe ser agregado al registro deoperaciones; lo mismo sucede para las operaciones Sel_polizas y Selsaldosanteriores.

En las operaciones ProSumamovimientos y ProAgregarsaldosanteriores su tipo decomportamiento identificado es: por cuenta, lo cual significa que la suma de movimientos y lossaldos anteriores agregados al reporte son realizados por cuenta, el número de tipo decomportamiento para ambos es cero. Para la operación PreAgregarnombres su tipo esRep_so, esto significa que se agregaran nombres de cuentas a la tabla temporal Repso; elnúmero de tipo es cero. (Véase Figura 4.6)

Operaciones

Sel cuentas

Sel_polizas

Sel saldos anteriores

Tipo de No. de Tipo decomportamiento comportamiento

: por cuenta 0

: del período

: del período

Sel validaCtaPol

Pro_Suma_mov¡mientos ; por cuenta

Pro_Agregar_saldos_anteriores : pOr cuenta

Pro Construcción del árbol

Pre_Agregar_nombres : para Rep_so

Figura 4.6 Definición de tipos de comportamiento a las operaciones del reporte Saldos.

4.2.3 Registro de operaciones.

El registro de operaciones es una lista donde se registran todas las operaciones diferentes,identificadas en el proceso del diseño y análisis operacional.

34

Junto con las operaciones se registran sus diferentes tipos de comportamiento, únicamente por elnúmero de tipo; por ejemplo, en el caso de la operación Selsaldosanteriores se identificarondos tipos de comportamiento en las colaboraciones donde se utilizó la operación, en lacolaboración para el reporte de Saldos se identifica el primer comportamiento (saldos anteriorespara un período) que se registra como tipo cero (SelsaldosanterioresTO), y en la colaboraciónpara el reporte de Auxiliares de varios períodos se identifica un segundo comportamiento (saldosanteriores para un período y un rango de cuentas) que se registra como tipo uno(Selsaldosanteriores TI). (Véase Tabla 4.4).

OperaciónSel cuentasSel gruposSel grupos TOSel grupos TISel_polizasSel_polizas_TOSel_polizas_Tl

Sel_polizas T2Sel_polizas T3

Sel_polizas_T4

Sel_polizas_T5Sel reglasSelreglasTOSelreglasTlSel saldos anterioresSel saldos anteriores TOSel saldos anteriores TISelNombreCtaSelNombreGpoSel validaCtaPolProAgregarCSMProAgregarsaldosanterioresProAgregar saldos anteriores TOPro_Agregar saldos anteriores TIPro Agregar_saldos_anteriores_T2Pro Auxiliares con CSMPro_Auxiliares_por cursoresProBalancegeneralPro BalanzaaldiaPro Cierre mensual

Pro_Construccion_del_arbol

ProEstadoderesultadosProMayor

DescripciónObtiene el catálogo de cuentas del período.Obtiene los grupos para el Edo. de resultados o el Balance general.- Para el Edo. de resultados.- Para el Balance general.Obtiene pólizas cumpliendo un cierto rango.- Para un período y obtención de datos parciales de la póliza.- Para un período, un rango de cuentas, un rango de fechas, y obtención dedatos parciales de la póliza.- Para un período y obtención de todos los datos de la póliza.- Para un rango de cuentas, un rango de fechas y obtención de datos parcialesde la póliza.- Para un rango de cuentas, un rango de fechas y obtención de todos los datosde la póliza.- Para un período, un rango de fechas y obtención de datos parciales.Obtiene las reglas de agrupación para el Edo. de resultados o Balance Gral.- Para el Edo. de resultados.- Para el Balance generalObtiene los saldos anteriores de las cuentas.- Para un período.- Para un período y un rango de cuentas.Contiene una función que regresa el nombre de una cuenta.Contiene una función que regresa el nombre de un grupo.Verifica la existencia de información de cuentas y pólizas.Agrega a los Auxiliares las cuentas que no tuvieron movimientos del período.Agregar al saldo de las cuentas o grupos su saldo anterior.- Para cuentas.- Para un rango de cuentas.- Para grupos.Procedimiento para obtener Auxiliares con cuentas sin movimientos.Obtiene Auxiliares sin cuentas que no tuvieron movimientos.Obtiene el Balance general del período.Obtiene una Balanza de comprobación de un día.Realiza el Cierre mensual (actualiza los saldos anteriores del nuevo período,forma el nuevo período con catálogo, grupos y reglas de agrupación).Construye un árbol de cuentas por niveles, obtiene las sumas de losmovimientos y saldos de las cuentas de mayor nivel.Obtiene el Estado de resultados del período.Realiza el reporte Mayor (saldos y movimientos de las cuentas a nivelmayor).

Tabla 4.4 Registro de operaciones.

35

Pro Póliza de cierrePro Saldos a un diaPro Suma movimientosPro Suma movimientos TOPro Suma movimientos TIPreAgregarnombresPreAgregarnombresTOPreAgregarnombresT 1Pre Agregar nombres T2

Construye la póliza de cierre del ejercicio.Obtiene los saldos anteriores, a un día definido por el usuario.Obtiene la suma de los cargos, abonos, y saldos de cada grupo o cuenta.- Para cuentas.- Para grupos.A las tablas temporales se les agregan los nombres de las cuentas.- Para Repso.- Para Repana y un determinado rango de cuentas.- Para Rep ana.

Tabla 4.4 Registro de operaciones (continuación).

El resultado de los análisis operacionales realizados a todos los diseños (DFD's yColaboraciones) de los reportes y cierres del dominio, son mostrados en la Tabla 4.4. La Tablamuestra todas las operaciones identificadas así como sus tipos de comportamiento.

Una tarea a realizar una vez obtenida la tabla de registro de operaciones, es identificar lasoperaciones que hacen las veces de funciones. Para estas operaciones se hace una clasificación:

a) Las operaciones que no tienen una participación directa en la secuencia principal deejecución de operaciones dentro de una colaboración.

b) Las operaciones que tienen una participación directa en la secuencia principal deejecución de operaciones dentro de una colaboración.

Las operaciones que están dentro de la clasificación 'a' son: SelNomCta y SelNomGpo. Estasoperaciones son apartadas de su categoría para formar una nueva categoría denominadaFunciones. Las clasificadas dentro de 'b' son: ProAgregarsaldosanteriores, Pro_Auxiliares_conCSM, ProSumamovimientos y Sel_polizas.

La última actividad de la etapa de registro de operaciones es la elaboración de una Tabla Final, enla que se muestra la nueva categoría, las operaciones que corresponden a cada categoría, y laasignación en algunas operaciones de tipos de comportamiento.

A partir de este punto las operaciones son denominadas como componentes, dado que es eltérmino técnico que se utiliza para su implementación. Para simplificar la utilización de losnombres de las operaciones en la implementación, éstas son renombradas por un nombre máscorto. (Véase Tabla 4.5)

La columna final de la Tabla 4.5 determina el tipo del componente a nivel funcional. Ladefinición de los tipos se hace para conocer el propósito del componente en una colaboración.Los tipos son los siguientes:

• Procedimiento: Componente que forma parte de una secuencia de ejecución en unacolaboración; sí tiene definidos tipos de comportamiento (Decoradores), se comporta deacuerdo al tipo requerido. Puede hacer uso de componentes tipo: Función yProcedimiento_F. Obtenido de las operaciones en las colaboraciones.

36

Procedimiento_F (Procedimiento - Función): Componente tipo Procedimiento que hacelas veces de función, es decir, además de formar parte de una secuencia de ejecución enuna colaboración, puede ser ejecutado de forma directa a través de una "llamada"contenida en otro componente tipo Procedimiento. Obtenido de la identificación deoperaciones que hacen las veces de funciones.Decorador: Define el tipo de comportamiento para su componente principal(Procedimiento o ProcedimientoF). Obtenido del tipo de comportamiento de operación.Función: Componente que no forma parte de la secuencia de ejecución de algunacolaboración, tiene el propósito de apoyar en alguna tarea a un componente de tipoProcedimiento o ProcedimientoF. Obtenido de la identificación de funciones que serepiten en varios diseños y tienen una tarea pequeña.

Categoría

Selección de información

Procedimientos del reporte

Operación

Sel cuentasSelgruposSelgruposTOSel gruposTlSeljiolizasSel_polizas_TOSel_polizas TISel_polizas_T2Sel_polízas_T3Sel_polizas_T4Sel_polizas T5SelreglasSel_reglas_TOSelreglasTlSel saldos anterioresSel saldos anteriores TOSel saldos anteriores TISel validaCtaPolPro Agregar CSMProAgregar saldos anterioresPro Agregar saldos anteriores TOPro Agregar saldos anteriores TIPro_Agregar saldos anteriores T2Pro Auxiliares con CSMPro Auxiliares_por cursoresPro Balance generalPro Balanza al diaPro Cierre mensualPro Construcción del árbolPro Estado de resultadosPro MayorPro Póliza de cierrePro Saldos a un dia

Componente

Se CtasScGposSc_Gpos_T0Se GposTlSe PolSe Pol TOSe Pol TISe Pol T2Se Pol T3Se Pol T4Se Pol T5ScRegsScRegsTOScRegs TISc_SAScSATOSe SA TISe ValidaCtaPolPr AgrCSMPr AgrSAPr AgrSA TOPr_AgrSA_TlPr_AgrSA_T2Pr AuxCSMPr AuxCursoresPr BalancePr BalDiaPr CMPr ÁrbolPr EstadoPrMayorPr PolCierrePr SalDia

Tipo decomponente

ProcedimientoProcedimientoDecoradorDecoradorProcedimiento FDecoradorDecoradorDecoradorDecoradorDecoradorDecoradorProcedimientoDecoradorDecoradorProcedimientoDecoradorDecoradorProcedimientoProcedimientoProcedimiento FDecoradorDecoradorDecoradorProcedimiento FProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimiento

Tabla 4.5 Tabla final de operaciones - componentes.

37

Procedimientos de presentación

Funciones

Pro Suma movimientosPro Suma movimientos TOPro Suma movimientos TIPreAgregarnombresPre Agregar nombres_T0Pre Agregar nombres_TlPreAgregar nombres_T2Sel NombreCtaSel NombreGpo

Pr SumaMovsPr SumaMovs TOPr SumaMovs TIPt AgrNomPtAgrNomTOPt AgrNom TI

LPt_AgrNom_T2ScNomCtaSe NomGpo

ProcedimientoFDecoradorDecoradorProcedimientoDecoradorDecoradorDecoradorFunciónFunción

Tabla 4.5 Tabla final de operaciones - componentes.

Para tener una mejor lectura e identificación de los componentes en las colaboraciones, serecomienda colocar los componentes tipo función después de los componentes para presentación.

4.2.4 Componentes complementarios.

Tres componentes se agregan al conjunto de los componentes ya identificados: Inicial, Final yGlobales. El componente inicial es colocado al inicio de los componentes que correspondan auna colaboración, con el componente final ocurre lo mismo pero en la posición final.

Las variables globales identificadas en los análisis operacionales son mostradas en la Tabla 4.6.

VariablesYear Act, Mes Act, Year Ant, Mes Ant, Year Pos,MesPosGhayctas , G_hay_s_ant, G_hay_polizas,Ghaygrupos, Ghay reglasG_fechal, G_fechaF, GfechalTemp,G fechaF TempGctal, GctaFG nivelGran EdoRes

UsoDefinen Periodos.

Variables tipo Boolean usadas en la verificación deexistencia de información.Rangos de fechas.

Rangos de cuentas.Define un nivel de cuentas.Almacena el resultado del Edo. de resultados

Tabla 4.6 Variables globales.

Estos componentes junto con la categoría de Funciones, dan como resultado la estructura final dela colaboración. En la Figura 4.7 se muestra la estructura final que siguen las colaboraciones;como ejemplo se utiliza el reporte Saldos, descrito en términos de los componentes que utiliza ysu organización. Este reporte no utiliza componentes tipo función, pero se indica su posición.

Cada requerimiento de los sistemas de contabilidad es representado por medio de colaboraciones,como el descrito en el ejemplo del reporte de Saldos. La intención al tener una representación deesa forma, es facilitar la implementación de los requerimientos. En el siguiente capítulo esdescrita la técnica a utilizar para implementar los componentes.

38

Componentes Categorías Distribución general

Globales

Figura

Inicial

Se Ctas

Se Pol TO

Se Pol

Se SA TO

Se SA

Se ValidaCtaPol

Pe SumaMovs TO

Pe SumaMovs

Pc_AgrSA_TO

Pc_AgrSA

Pe Árbol

Pr_AgrNom_TO

Pr_AgrNom

Final

Selección deinformación

Procedimientosdel reporte

Procedimientosde presentación

Funciones

Procedimientosprincipales

Funciones

4.7 Colaboración del reporte Saldos con su Estructura Final.

39

Capítulo 5. Implementación.

Una vez obtenida la arquitectura de software (colaboraciones) continúa la etapa deimplementación. La implementación implica definir ecuaciones de tipo para representar lasecuencia de ejecución de las operaciones de una colaboración, y los diferentes tipos decomponentes involucrados. Este capítulo explica los aspectos necesarios y las técnicasempleadas para implementar una línea de productos en Delphi.

5.1 Arquitecturas por niveles y gramática GenVoca.

La intención al tener las operaciones (componentes) ordenadas por categorías es obtener unaarquitectura por niveles. El orden es dado en principio por el Patrón de diseño, y posteriormentepor medio del análisis operacional que da como resultado la colaboración. El tipo de arquitecturaque sigue la colaboración es una arquitectura por niveles.

En una arquitectura por niveles las categorías pueden ser ordenadas en una jerarquía de niveles,en donde cada nivel representa una categoría, y cada categoría depende de otra [Czarnecki 99].

En las arquitecturas por niveles, cada aplicación es representada como un sistema dividido. Unnivel puede ser considerado como un slot (ranura, hueco) en el cual pueden colocarsecomponentes. El conjunto de componentes colocados en los slots dará como resultado unaaplicación con un determinado comportamiento [Jacobson 97].

El propósito de una arquitectura por niveles, es que cada componente tome al componenteinferior como un parámetro [Czarnecki 99], por ejemplo, en la colaboración del reporte Saldos(Figura 4.5) el primer componente es Sel_cuentas y su componente inferior esSe l_po l i za s , la manera de representar al componente parámetro es: Sel_cuentas [Se l_po l i zas [...]]. A esta representación la llamamos una ecuación de tipo [Batory 92]. Enel ejemplo, Se l_cuentas [ tiene como parámetro a Sel p ó l i z a s , el cual puede tener otroparámetro que no es mostrado.

En ese orden, la colaboración del reporte Saldos se representa: S e l c u e n t a s [Sel_pol izas[Sel_saldos_anter iores[Sel_Val idaCtaPol[Pro_Suma_movimien tos [Pro_Agregar_sa ldos_an te r io res [Pro_Cons t rucc ion_de l_a rbo l [Pre_Agregar_nombres [...] ] ] ] ] ] ] ] .

La ecuación de tipo para el mismo reporte, pero en términos de componentes y con su estructurafinal (Figura 4.7) es: Inicial[Sc_Ctas[Sc_Pol_T0[Sc_Pol[Sc_SA_T0[Sc_SA[ScJValidaCtaPol[Pc_SumaMovs_TO[Pc_SumaMovs[Pc_AgrSAJTO[Pc_AgrSA[Pc_Arbol[Pt_AgrNom_TO[Pt_AgrNom[Final]]]]]]]]]]]]]]•

40

La representación de una ecuación de tipo en términos de categorías es: I n i c i a l [Se lecc ión de_información[Procedimientos_del_repor te[Selecc ión_de_in fo rmac ión [Proced imien tos_de_presen tac ión [F ina l ] ] ] ] ] .

Las ecuaciones de tipo resultantes de las colaboraciones son mostradas en la Tabla 5.1.

RequerimientoSaldos

Analítico de cuentas

Analítico por día

Mayor

Auxiliares normales

Auxiliares con cuentas sinmovimientosAuxiliares de variosperíodos

Balanza de comprobaciónprevia

Balanza de comprobaciónpor día

Estado de resultados

Balance general

Cierre mensual

Cierre del ejercicio

Ecuación de tipoInicial[Sc_Ctas[Sc_Pol TO[Sc_Pol[Sc_SA_TO[Sc_SA[Sc_ValidaCtaPol[Pe SumaMovs T0[Pc SumaMovs[Pc AgrSA T0[Pc AgrSA[Pc ArbolfPt AgrNom T0[Pt AgrNom[Final]]]]]]]]]]]]]]Inicial[Sc_Ctas[Sc_Pol_TOtSc_Pol[Sc_SA_TO[Sc_SA[Sc_ValidaCtaPol[Pe SumaMovs T0[Pc SumaMovsfPc AgrSA T0[Pc AgrSAfPc ArbolfPt AgrNom Tl[Pt AgrNom[Final]]]]]]]]]]]]]]Inicial[Sc_Ctas[Sc_Pol_Tl[Sc_Pol[Sc_SA_TO[Sc_SA[Sc_ValidaCtaPol[Pe SumaMovs TOfPc SumaMovs[Pc AgrSA TI [Pe AgrSAfPc ArbolfPt AgrNom T2[Pt AgrNomfFinal]]]]]]]]]]]]]]InicialfSc CtasfSc Pol TOfSc PolfSc SA TOfSc SAfSc ValidaCtaPolfPc_Mayor[Sc_NomCtafFinal]]]]]]]]Inicial[Sc_Ctas[Sc_Pol_TO[Sc_Pol[Sc_SA_TO[Sc_SA[Sc_ValidaCtaPoI[Pe AuxCursoresfSc NomCtafFinal]]]]]]]]]InicialfSc CtasfSc Pol T2[Sc PolfSc SA TOfSc SAfSc ValidaCtaPolfPc_AuxCSM[Pc_AgrCSM[Sc_NomCta[Final]]]]]]]]]]InicialfScCtasfScPolJTOfScPolfScSATlfScSAfScValidaCtaPolfSe Pol T4[Sc PolfPc SalDiafSc Pol T3[Sc PolfPc SumaMovs TOfPc SumaMovsfPc_AgrSA_TO[Pc_AgrSA[Pc_AuxCSM[Sc_NomCta[Final]]]]]]]]]]]]]]]]]]Inicial[Sc_Ctas[Sc_Pol_TO[Sc_Pol[Sc_SA_TOfSc_SA[Sc_ValidaCtaPol[Pe SumaMovs TI [Pe SumaMovsfPc AgrSA T2[Pc AgrSAfPt AgrNom TOfPt AgrNomfFinal]]]]]]]]]]]]]Inicial[Sc_Ctas[Sc Pol_TO[Sc_Pol[Sc SA_T0[Sc SAfScValidaCtaPolfPe BalDiafPc SumaMovs TI [Pe SumaMovsfPc AgrSA T2[Pc AgrSAfPtAgrNomTOfPtAgrNomfFinal]]]]]]]]]]]]]]Inicial[Sc_Ctas[Sc_Pol_TO[Sc_Pol[Sc_SA_TO[Sc_SA[Sc_ValidaCtaPol[Pc_SumaMovs_TO[Pc_SurnaMovs[Pc_AgrSA_TO[Pc_AgrSA[Pc_Arbol[Se Gpos TOfSc GposfSc Regs TOfSc RegsfPc Estado[Sc NomGpofFinal]]]]]]]]]]]]]]]]]]Inicial[Sc_Ctas[Sc_Pol_TO[Sc_Pol[Sc_SA_TO[Sc_SA[Sc_ValidaCtaPol[Pc_SumaMovs_TO[Pc_SumaMovs[Pc_AgrSA_TO[Pc_AgrSA[Pc_ArboI[Se Gpos TI [Se GposfSc Regs TI [Se Regs[Pc BalancefSc NomGpofFinal]]]]]]]]]]]]]]]]]]Inicial[Sc_Ctas[Sc_Pol_TO[Sc_Pol[Sc_SA_TO[Sc_SA[Sc_ValidaCtaPol[Pc_SumaMovs_TO[Pc_SumaMovs[Pc_AgrSA_TO[Pc_AgrSA[Pc_Arbol[Se Gpos TOfSc GposfSc Gpos TI [Se GposfSc Regs TOfSc RegsfSc_Regs_Tl[Sc_Regs[Pc_CM[Final]]]]]]]]]]]]]]]]]]]]]InicialfSc_Ctas[Sc_Pol_TO[Sc_Pol[Sc_SA TOfSc SAfSc ValidaCtaPolfPcSumaMovsTOfPcSumaMovsfPcAgrSA TOfPc AgrSAfPc ArbolfPcPolCierrefScPolTOfSc PolfPc SumaMovs TOfPc SumaMovsfPe AgrSA TOfPc AgrSAfPc ArbolfSc Gpos TOfSc GposfSe Gpos TI [Se GposfSc Regs TOfSc RegsfSc Regs TI [Se RegsfPc_CM[Final]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

Tabla 5.1 Ecuaciones de tipo.

41

La Tabla 5.2 muestra los componentes usados en cada requerimiento.

Componente

Se CtasScGposSc_Gpos_T0Se Gpos TISe PolSe Pol TOSe Pol TISe Pol T2Sc_Pol_T3Se Pol T4ScRegsScRegsTOSe Regs TISe SASe SA TOSe SA TIScValidaCtaPolPrAgrCSMPrAgrSAPrAgrSATOPrAgrSATlPr_AgrSA_T2PrAuxCSMPr_AuxCursoresPrJBalancePrBalDiaPrCMPr_ArbolPr EstadoPr MayorPrPolCierrePrSalDiaPr SumaMovsPr SumaMovs TOPr SumaMovs TIPtAgrNomPtAgrNomTOPtAgrNomTlPt_AgrNom_T2ScNomCtaSe NomGpo

Requerimiento

o

*

*

*

*

**

VJ

tsuoo-oO

1<

**

*

*

-3t_ioO H

OU

*

*

*

*

*

Oen

2iu•VO

1w

*

**

*

*

*

*

2iso

affl

*

*

*

*

*

*

*

*

aSu

O***

***

*

*

*

*

oos

guU***

*

*

*

*

*

*

*

1a

73m

*He

•3

a73

*

*

*

**

o

*

73

sV)

.§

**

*

*

*

u§oxfiU

.3

*

***

*

*

o11en

B ȇ l

**

**

*****

*

***

*

Tipo decomponente

ProcedimientoProcedimientoDecoradorDecoradorProcedimiento FDecoradorDecoradorDecoradorDecoradorDecoradorProcedimientoDecoradorDecoradorProcedimientoDecoradorDecoradorProcedimientoProcedimientoProcedimiento FDecoradorDecoradorDecoradorProcedimiento FProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimientoProcedimiento FDecoradorDecoradorProcedimientoDecoradorDecoradorDecoradorFunciónFunción

Tabla 5.2 Componentes usados en cada requerimiento.

42

La Tabla 5.3 muestra las ecuaciones de tipo que utilizan los sistemas de contabilidad para cadatipo de Unión de crédito.

Ecuación de tipo(Requerimiento)

SaldosAnalítico de cuentasAnalítico por díaMayorAuxiliares normalesAuxiliares con cuentas sin movimientoAuxiliares de varios períodosBalanza de comprobación previaBalanza de comprobación por díaEstado de resultadosBalance generalCierre mensualCierre del ejercicio

Unión de créditoComercial

**

***

*

***

Industrial**

**

*

***#

Agropecuaria*

***

*

*****

Tabla 5.3 Ecuaciones de tipo utilizadas en cada tipo de sistema de contabilidad.

5.2 Estrategia de implementación de componentes.

Hasta este punto se deja de hacer referencia a los aspectos de análisis y diseño de la arquitecturade software para la línea de sistemas de contabilidad. En seguida se da una descripción de lascaracterísticas del medio de desarrollo Delphi y por qué su elección, para después continuar conel último paso de la Ingeniería de dominios: la codificación (implementación de loscomponentes).

En el área de reuso de software existen soluciones que proponen el uso de la programaciónorientada a objetos para el desarrollo de componentes reusables, haciendo uso principalmente deparametrización de componentes [Smaragdakis 98]. Esta característica, si bien es muy útil, no seencuentra en todos los lenguajes orientados a objetos, este es el caso de Delphi, Visual Basic yotras herramientas comerciales. Para el desarrollo de líneas de productos la parametrización decomponentes ha facilitado su implementación, pero en lenguajes que no la poseen no se hamostrado una técnica que pueda sustituirla [Weiss 99].

El presente trabajo muestra una estrategia de extensión del lenguaje de un ambiente de desarrollo,para añadir el soporte de parametrización de componentes. Debido a que utilizamos un ambientecuyo lenguaje es orientado a objetos, cada componente se implementa como una claseparametrizada, cuyo parámetro es la clase que implementa el componente del siguiente nivel(hacia abajo) en la jerarquía.

Algunos autores han utilizado parametrización de clases con un propósito similar al nuestro, peroen lenguajes que soportan directamente la parametrización (p. ej. templates de C++). Elmecanismo ha sido utilizado con herencia de clases. Nuestra perspectiva es que el mecanismo

43

de delegación es más flexible, por lo cual, es el elegido para este trabajo. El mecanismo dedelegación puede utilizarse en todos los lenguajes orientados a objetos.

Por la literatura encontrada para la implementación de líneas de productos, Delphi es un lenguajemuy poco usado en la comunidad de reuso de software y por lo mismo se desconocen susposibilidades para utilizarlo en la construcción de una línea de productos. Otros aspectos queinfluyeron en su elección son su potencialidad (posee todas las características de los medios dedesarrollo modernos) y su disponibilidad (producto comercial). Existen lenguajes específicospara la codificación de líneas de productos, pero están limitados a un determinado dominio y noson productos comerciales; en el caso de Delphi no importa el tipo de dominio que deseaimplementarse y puede adquirirse.

El ambiente de Delphi combina la facilidad de uso de un medio de desarrollo visual, la velocidadde un compilador optimizable de 32-bits, y las capacidades de un administrador de base de datosescalable. Delphi es único en el sentido de que integra esas tres tecnologías en un mismo mediode desarrollo [Inprise 98].

5.2.1 Características de Delphi.

Entre las características de Delphi que se encuentran útiles para el desarrollo de aplicacionesestán [Teixeira 98]:

• Es un medio de desarrollo rápido (RAD, Rapid Application Development) para hacersistemas o prototipos. Permite construir interfaces de usuario rápidamente con unmínimo de código.

• Para los desarrolladores de software comercial. Delphi en una alternativa a lenguajescomo C o C++, permite el manejo de eventos de bajo nivel para satisfacer cualquiernecesidad de software comercial.

• Para los desarrolladores de software para mercados verticales. Delphi no está bloqueadocomo si fuera un medio de desarrollo aislado. Se puede mezclar y relacionar con otrosmedios de bases de datos, editores de reportes, puede hacer uso de recursos OLE (ObjectLinking and Embedding), DDE (Dynamic Data Exchange), ODBC (Open DatábaseConnectivity), controles OCX.

• Es un medio de programación orientada a objetos que soporta clases, herencia,polimorfismo, encapsulación, interfaces y sobrecarga de funciones.

• Permite la comunicación con servidores de base de datos SQL: InterBase, Oracle,Microsoft SQL Server, Sybase, Informix y DB2.

• Permite el desarrollo de aplicaciones Internet por medio de un paquete de controlesActiveX.

Características que facilitan el reuso de software en Delphi [Kellen 96, Teixeira 98]:

• Se sugiere en los manuales de Delphi utilizar la programación orientada a objetos, enparticular la herencia de propiedades y métodos de clases ya existentes, para reusarcódigo.

44

Contiene un editor de pantallas que facilita el desarrollo de las mismas, creando unajerarquía de pantallas que heredan las propiedades visuales, facilitando el diseño ymodificación de un gran número de pantallas en aplicaciones complejas. Esta jerarquíaes independiente del código que contengan los eventos de las pantallas.Permite la creación de componentes personalizados Delphi por medio de sus capacidadesen orientación a objetos. Los componentes personalizados son agregados a la librería decomponentes (Visual Component Library) para dar más funcionalidad a Delphi.Brinda un soporte robusto para tecnologías COM, ActiveX, OLE y CORBA.Cuenta con Administrador de versiones.Posee un administrador de proyectos que permite compartir formas, formas para diálogos,módulos de datos, y patrones de proyectos. Esta característica es llamada ObjectRepository, permite a los desarroUadores hacer que sus objetos hereden las característicasy comportamientos de otros objetos que ya existan, permite compartir los objetos condesarroUadores de otros proyectos.

5.3 Implementación de componentes en Delphi.

Un programa en Delphi es construido por medio de módulos de código fuente (Pascal orientado aobjetos) denominados unidades. Cada unidad es almacenada en su propio archivo (.PAS) ypermiten:

• Dividir programas grandes en módulos que pueden ser editados de forma independiente.• Crear librerías que pueden ser compartidas entre los programas.• Incluir una o más clases en cada unidad.

En la programación tradicional de Pascal, todo el código fuente incluyendo el programa principales almacenado en archivos .PAS. Delphi utiliza un archivo - proyecto (.DPR) para almacenar elprograma "principal", mientras la mayor parte del código fuente es almacenado en archivos -unidades (.PAS). Cada aplicación está integrada por un archivo - proyecto y uno o más archivos- unidad [Inprise 98].

Una unidad esta conformada de tipos (incluyendo clases), constantes, variables, y rutinas(funciones y procedimientos). Una unidad comienza con un encabezado de unidad, seguido delas secciones: i n t e r f a c e , implementation, i n i t i a l i z a t i o n , y f i n a l i z a t i o n .Las secciones i n i t i a l i z a t i o n y f i n a l i z a t i o n son opcionales. El esquema de unaunidad se muestra en la Figura 5.1.

Figura 5.1 Esquema de las unidades.

unit Nombre_de_unidad;

interface

uses {La lista de unidades se coloca aqui.l

45

{El código de la sección Interface se coloca aquí.}

implementation

uses (La lista de unidades se coloca aquí.}

{El código de la sección Implementation se coloca aquí.}

initialization{El código de la sección Initialization se coloca aquí.}

finalization{El código de la sección Finalization se coloca aquí.}

end.

La intención al explicar la forma de programar en Delphi (por medio de unidades) y se muestra elesquema de una unidad, es porque los componentes desarrollados utilizan de manera primordiallas secciones i n t e r f a c e e implementation, así como la cláusula uses.

Por cada componente identificado en la arquitectura, se construirá una unidad de Delphi. En lasección i n t e r f a c e se declaran las clases, funciones, procedimientos y variables a exportar, deesta forma otra unidad puede hacer uso de lo declarado en i n t e r f ace . En la secciónimplementation se colocan también clases, funciones, procedimientos y variables, pero sinposibilidad de exportar, sólo tienen un funcionamiento interno. Las seccionesi n i t i a l i z a t i o n y f i n a l i z a t i o n no son utilizadas.

La manera de hacer uso de las clases, funciones, etc., declaradas en otra unidad, es por medio dela cláusula uses. En uses se listan todas las otras unidades que deseamos utilizar. Loscomponentes hacen uso de esta característica de las unidades, para construir una secuencia lineal(semejante a una cadena) de llamadas de componentes, en donde cada componente llama alsiguiente componente (componente inferior) de la ecuación de tipo, por medio de uses . Laestructura general que tienen los componentes es mostrada en la Figura 5.2:

Figura 5.2 Estructura general.

unit Nombre_del_componente;

interface

uses Nombre_del_siguiente_componente;

typeTNombre__del_componente = class

Infer : TNombre_del_síguíente_componente; ( Declaración de la clase inferior{ Más variables - propiedades se declaran aquí }constructor Créate { var Inferp : TNombre del siguiente_componente );procedure Procesos;{ Más procedimientos - métodos se declaran aquí }

end;

implementation

46

uses Nombre_del_módulo_de_datos, Componente_Globales,{ Más unidades se declaran aquí } ;

constructor TNombre_del_componente.Créate(var Inferp : TNombre_del_síguíente_componente);

begininherited Créate;Infer := Inferp; { Inicialización de la clase inferior }

end;

procedure TNombre_del_componente.Procesos;begin

{ El código del componente se coloca aquí }

Infer.ProcesoS; { Llamada a Procesos de la clase inferior }

end;

{ El código de los otros procedimientos se coloca aquí }

end.

En la sección i n t e r f a c e se declara el nombre de la unidad que contiene al siguientecomponente {componente inferior) de la secuencia, y una clase. La clase podrá hacer referenciaa la clase {clase inferior) contenida en el componente inferior, por medio de una dependencia declases, la cual se realiza al declarar como una variable - propiedad a la clase inferior, yposteriormente asignándole a la variable, como valor, la clase inferior (realizado en el constructorCréa te) .

Como parte de la clase, se declara un constructor, el método principal, y dependiendo delcomponente, es posible la declaración de otros métodos.

En la sección implementa t ion , vuelve a colocarse la cláusula uses , pero en esta ocasiónpara llamar a las unidades Nombre_del_módulo_de_datos y Componente_Globales.El módulo de datos es una unidad que contiene las interfaces (elementos que utiliza Delphi pararealizar las transacciones de información, entre las aplicaciones y las bases de datos) con la basede datos del sistema de contabilidad. El módulo es generado automáticamente por Delphi almomento de definir las interfaces. Cada componente que realice alguna transacción deinformación con la base4e datos, debe incluirlo en la cláusula uses . En cuanto a componenteGlobales, éste se refiere al nombre de la unidad que contiene las variables globales en laaplicación.

El porqué estas unidades son colocadas en la cláusula uses de implemen ta t ion en lugar dela cláusula i n t e r f a c e , se debe a que, es a partir de la sección imp lemen ta t i on dondecomenzará a hacerse referencia al código contenido en las unidades, y no desde i n t e r f a c e .

El constructor tiene como propósito, que en el momento de crear la clase, la clase inferior seapasada como parámetro, e inicialice a la variable tipo clase, esto permitirá hacer referencia a laclase inferior desde la clase actual. Esta técnica es la que permite unir a los componentes entresi.

47

El procedimiento P rocesos contiene el código principal del componente, el código debecolocarse antes de ejecutarse la instrucción I n f e r . P rocesos . El procedimiento tambiénpuede tener parámetros, con los que se define el comportamiento del componente, y se pasandatos que provienen de la pantalla. La instrucción I n f e r . P r o c e s o s llama al métodoP r o c e s o s pero de la clase inferior, esto conlleva a la posibilidad de ejecuciones en secuenciade los componentes. Esta técnica es la que permite ejecutar los componentes en una jerarquía.(Véase Figura 5.3).

Debido a que un componente puede ser utilizado en varios reportes o cierres, el nombre de sucomponente inferior variará. Esto plantea un problema, porque un mismo componente no puedeser utilizado al mismo tiempo para varios reportes o cierres. La solución consiste en tener quegenerar componentes diferentes (en cuanto al nombre de su componente inferior, peromanteniendo toda su funcionalidad y propósito), para satisfacer las necesidades de cada reporte ocierre. Un ejemplo de esta situación se da en el reporte Estado de resultados (Tabla 5.1), elcomponente inferior de Sc_Regs es P c E s t a d o , pero en el reporte Balance general para elmismo componente su componente inferior es P c B a l a n c e . Dado que cada componente debeser utilizado en varios reportes o cierres, el nombre de su componente inferior podrá variardependiendo del reporte.

Componente_X Componente_Y Componente_Z

unit Componente_X unit Componente_Y unit Componente_Z

¡mplementation implementation ¡mplementation

procedure TComponente_X. Procesos _ procedure TComponente_Y.Procesos _ procedureTComponente_Z.ProcesoS

begin ^ ^ begin ^ - ^ begin

Infer.ProcesoS; Infer.ProcesoS; Infer.ProcesoS;

end; end; end;

end. end. end.

Figura 5.3 ComponenteXf Componente_Y[ Componente_Z[... ]]].

El generar componentes diferentes conlleva a la necesidad de tener un componente que sirvacomo plantilla o modelo, a partir del cual se le pueda modificar el nombre del componenteinferior; así como poder identificar el tipo de reporte al que pertenece el componente. Delcomponente plantilla, se obtendrán componentes derivados, pero con diferente nombre decomponente inferior y un identificador para distinguir a que tipo de reporte o cierre pertenecerá.

48

Los componentes que se deben implementar son componentes tipo plantilla, que sirven para lageneración de otros componentes derivados. Para solucionar el problema antes descrito, en elmomento de la implementación del componente, se definen dos palabras reservadas que harán lasveces (se interpretarán como sustituías) del componente inferior y del tipo de reporte o cierre.

En la estructura general mostrada en la Figura 5.2, se sustituirá el nombre del componenteinferior por el parámetro actual asignado al componente en el parámetro formal %%Infer%%, ypara identificar a que reporte o cierre pertenece el componente utilizaremos el parámetro formal$$ id$$ . La nueva representación de la estructura general es (Figura 5.4):

Figura 5.4 Estructura general con parámetros formales.

unit $$id$$Afo.m£>re_del_ componen te;

interface

uses %%Infer%%;

typeT$$íd$$Nombre_del_componente - class

Infer : T%%Infer%%;{ Más variables - propiedades se declaran aquí }constructor Créate( var Inferp : T%%Infer%%);procedure Procesos;{ Más procedimientos - métodos se declaran aquí }

end;

implementation

uses Nombre_del_módulo_de_datos, Componente_Globales,{ Más unidades se declaran aquí } ;

constructor T$$id$$Nombre_del_componente.Créate( var Inferp : T%%Infer%%) ;begin

inherited Créate;Infer := Inferp;

end;

procedure T$$id$$Nombre_del_componente. Procesos;begin

{ El código del componente se coloca aquí }

Infer.Procesos;end;

{ El código de los otros procedimientos se coloca aquí }

end.

Esta estructura es la que presentan generalmente los componentes para su implementación, perodependiendo del tipo de componente, la estructura variará. Los tipos de componentes serán:inicial, final, globales, función, procedimiento, decorador y procedimiento-función. Estos tiposde componentes corresponden a los declarados en la Tabla 4.5 y sección 4.3.7.

49

Las tareas de sustitución de parámetros del componente por su correspondiente valor, seránrealizadas por un Generador de Aplicaciones.

5.3.1 Componente tipo Inicial.

El componente Inicial siempre es utilizado, y su función es indicar el inicio de una serie deejecuciones, correspondientes a un proceso: reporte o cierre. Tiene la estructura mostrada en laFigura 5.5.

Figura 5.5 Componente tipo Inicial.

unit $$id$$Inicial;

interface

uses %%Infer%%;

typeT$$id$$Inicial = class

Infer : T%%Infer%%;constructor Créate( var Inferp : T%%Infer%%);procedure Procesos;

end;

implementation

constructor T$$id$$Inicial.Créate( var Inferp : T%%Infer%% );begin

inherited Créate;Infer := Inferp;

end;

procedure T$$id$$Inicial.Procesos;begin

Infer.ProcesoS;end;

end.

5.3.2 Componente tipo Final.

El componente Final siempre es utilizado, y su función es indicar el final de una serie deejecuciones, correspondientes a una proceso: reporte o cierre. En el momento de crearseinicializa las variables globales, y cuando se ejecuta ya no realiza la llamada tradicional paracontinuar con la secuencia de ejecuciones, de esta forma termina la última llamada al métodoP r o c e s o s . Tiene la estructura mostrada en la Figura 5.6.

Figura 5.6 Componente tipo Final.

unit $$id$$Final;

interface

50

typeT$$id$$Final = (;lass

constructor Créate;procedure Procesos,•

end;

implementation

uses Globales;

constructor T$$id$$Final.Créatebegin

G hay ctasG hay s antG hay pólizasG nivelG_fechalG fechaFG fechal TempG fechaF TempG_ctalG_ctaFG hay gruposG hay reglasGran Edo res

end;

= False;= False;= False;= 0;= 0;= 0;= 0;= 0;

\ t .r

_ w .

= False;= False;= 0;

procedure T$$id$$Final.ProcesosbeginG hay ctas

end;= False;

end.

5.3.3 Componente tipo Globales.

La estructura del componente Globales es muy diferente al resto de los otros componentes. Sufunción principal es proporcionar sus variables al componente que lo utilice (llame) por medio deuna cláusula u s e s . En el sentido estricto es sólo una unidad, y no posee ninguna clase deobjetos. Se aprovecha una de las características de Delphi, la de permitir exportar todos loselementos (variables, funciones, clases, etc.) declarados en la sección i n t e r f ace . En formaparecida a las clases de objetos, las unidades tienen una sección tipo public que es i n t e r f ace ,y una sección Xvpo prívate la cual es i m p l e m e n t a t i o n . El código del componente sólo esmodificado para agregar o cambiar variables, y tiene la estructura mostrada en la Figura 5.7.

Figura 5.7 Componente tipo Globales.

unit Globales;

interface { Sección: Public }

var

Year^Act, Mes_Act: Word;Year Ant, Mes Ant: Word;

51

Year_Pos, Mes_Pos: Word;G hay_ctas: Boolean;G_hay_s_ant: Boolean;G hay_polizas: Boolean;G_nivel: Integer;G_fechal: TDateTime;G_fechaF: TDateTime;G_fechaI_Temp: TDateTime;G_fechaF_Temp: TDateTime;G_ctal: String;G_ctaF: String;G_hay_grupos: Boolean;G_hay_reglas: Boolean;Gran_Edo_res: Double;

implementation { Sección: Private }

end.

5.3.4 Componente tipo Procedimiento.

El componente tipo Procedimiento es utilizado para contener el código de una colaboración,puede estar parametrizado para definir el tipo de comportamiento deseado. El código principales colocado en el método P r o c e s o s , y este código es una etapa de todo un proceso (reporte ocierre). Cuando el método P r o c e s o s está parametrizado, este componente debe iracompañado de un componente tipo decorador. Los parámetros que utiliza son: el tipo decomportamiento y variables semejantes al tipo de las globales; por medio de estos parámetros esque se introduce el valor de una variable global al componente. Tiene la estructura mostrada enla Figura 5.8.

Figura 5.8 Componente tipo Procedimiento.

unit $$id.$$Nombre_del_componente;

interface

uses %%Infer%%;

typeT$$id$$Nombre_del_componente = class

Infer : T%%Infer%%;constructor Créate ( var Inferp : T%%Infer%% );

procedure Procesos ( tipo: Byte; Definición_de_Otros_Parámetros );{ Los parámetros son opcionales }

{ Puede contener más métodos que apoyen a Procesos }end;

implementation

uses UnitDModuleC, Globales;

constructor T$$iá$$Nombre_úeL_componente.Créate ( var Inferp : T%*Inier°begin

52

inherited Créate;Infer := Inferp;

end;

procedure T$$id$$Nombre_del_componente.Procesos ( tipo: Byte;Definición_de_Otros_Parámetros );

begin

{ Código general del componente }

if tipo = 0 thenbegin

{ Código particular del componente, para el comportamiento tipo cero }end;

if tipo = 1 thenbegin

{ Código particular del componente, para el comportamiento tipo uno }end;

if tipo = X thenbegin

{ Código particular del componente, para el comportamiento tipo X }end;

{ Código general del componente }

Infer.Procesos;end;

end.

Cuando P r o c e s o s no tenga parámetros, no deben existir en su código condiciones para hacerreferencia a un tipo de comportamiento. En la cláusula u s e s de imp] e m e n t a t i o n dosunidades deben colocarse, la del módulo de interfaces a la base de datos, y la del componenteglobales. Al declarar G l o b a l e s en la cláusula, se tendrá acceso a las variables públicas.

5.3.5 Componente tipo Decorador.

El componente tipo Decorador es utilizado para definir el tipo de comportamiento en uncomponente tipo procedimiento o procedimientof. Realiza la ejecución de P r o c e s o s delcomponente inferior, con los correspondientes parámetros que definirán el comportamiento ydatos necesarios para la ejecución. Los parámetros que utiliza son: el tipo de comportamiento ylas variables globales; por medio de estos parámetros es que se introduce el valor de una variableglobal al componente. Tiene la estructura mostrada en la Figura 5.9.

Figura 5.9 Componente tipo Decorador.

unit $$id$$Nombre_del_componente;

interface

uses %%Infer%%;

type

53

T$$id$$Nombre_del_componente = classInfer : T%%Infer%%;constructor Créate( var Inferp : T%%Infer%% );procedure Procesos;

end;

implementation

uses UnitDModuleC, Globales;

constructor T$$id$$Nombre_del_componente.Créate( var Inferp : T%%Infer%% );begin

inherited Créate;Infer := Inferp;

end;

procedure T$$id$$Nombre_del_componente.Procesos;begin

Infer.Procesos ( tipo, Otros_Parámetros ) ;end;

end.

En la cláusula uses de implementation deben colocarse dos unidades, la del módulo deinterfaces a la base de datos, y la del componente Globales. Al declarar Globales en lacláusula, se tendrá acceso a las variables globales. Los parámetros de la instrucciónI n f e r . Procesos deben corresponder a los declarados en el método Procesos delcomponente inferior.

5.3.6 Componente tipo Función.

El componente tipo Función es utilizado para definir una función que apoyará a los componentesinvolucrados en un proceso (reporte o cierre). Contiene un nuevo tipo de parámetro formal(! ! gen! ! Gen), el cual será sustituido por el nombre de una unidad que permitirá alcomponente tipo función ser ejecutado (llamado) desde otros componentes de un mismo proceso.El código es colocado en una propia función y no en el método P r o c e s o s . Los parámetros queutiliza la función dependerán de los datos requeridos por la misma. La Figura 5.10 muestra suestructura.

Figura 5.10 Componente tipo Función.

unit $$id$$Nombre_del_componente;

interface

uses %%Infer%%;

typeT$$id$$Nombre_del_componente = class

Infer : T%%Infer%%;constructor Créate( var Inferp : T%%Infer%% );procedure ProcesoS;function Nombre_de_la_función ( Definición_de_Parámetros ) : Tipo de resultado;

end;

54

implementation

uses UnitDModuleC, Globales, MgenUGen;

constructor T$$id$$Wombre_del_componente.Créate( var Inferp : T%%Infer%% );begin

inherited Créate;Infer := Inferp;

end;

procedure T$$id$$Nombre_del_componente.Procesos;begin

Infer.Procesos;end;

functionT$$id$$Afomjbre_de2_componente.Nombre_de_la_función {Definición_de_Parámetros): Tipo_resultado;

begin{ Código de la función }

end;

end.

Dos aspectos a resaltar de este componente son: 1) El método P r o c e s o s solo contiene lallamada al componente inferior; esto permite colocar al componente función en cualquierposición dentro de la secuencia de componentes (colaboración), pero por orden debe ser colocadoen la categoría Funciones, la secuencia de ejecuciones no se ve afectada porque P r o c e s o s delcomponente tipo Función no contiene código adicional. 2) La forma de ejecutar (llamar) a lafunción será directamente, es decir, dentro del código de algún componente procedimiento oprocedimientof, sólo con colocar el nombre de la función, podrá utilizarse.

El componente que haga uso de un componente tipo función debe agregar en su cláusula u s e sde la sección i m p l e m e n t a t i o n un parámetro formal (! ! gen! ! Gen) como si se tratara deuna unidad más. Y para ejecutar la función, se escribirá:

variable := Obj_!!gen!!.$$id$$Nombre_Comp_Funciónl.Nombre_Comp_Función [Parámetros);

donde variable es la variable que recibirá el resultado de la función,Nombre_Comp_Función es el nombre del componente tipo función y sus correspondientesparámetros.

Existen dentro de esta instrucción dos parámetros formales: ! ! gen! ! y $$id$$, cuyopropósito es ser sustituidas por los parámetros actuales indicados por el desarrollador (tarea delGenerador de aplicaciones). El primer parámetro junto con Obj_, dará lugar al nombre de laclase generadora (descrita en el capítulo del Generador), y el segundo parámetro junto conNombre_Comp_Funciónl, dará lugar al nombre del componente (con su identificador delreporte o cierre) al que se hará referencia.

55

5.3.7 Componente tipo Procedimiento - función.

Para hacer que un componente tipo procedimiento pueda ser utilizado como una función, esdecir, pueda ejecutarse directamente el código contenido en el método P r o c e s o s desde otrocomponente, como si se tratara de una función o procedimiento que apoya a un programaprincipal; la estructura general de componentes debe incluir:

• Una variable tipo Boolean (de nombre V e r t i c a l ) para determinar cuando elcomponente está siendo llamado como parte de una secuencia de ejecuciones o como unafunción.

• Un procedimiento con el mismo nombre del componente, a través del cual se realizará laejecución del método P r o c e s o s .

Contiene el parámetro formal ! ! gen ! ! Gen, el cual será sustituido por el nombre de una unidadque permitirá al componente tipo procedimiento-función ser llamado desde otros componentes deun mismo proceso (reporte o cierre). El código principal es colocado en el método P r o c e s o s .Los parámetros que utiliza P r o c e s o s dependerán de los datos requeridos por él mismo. LaFigura 5.11 muestra su estructura.

Figura 5.11 Componente tipo Procedimiento - Función.

un i t $$id$$Nombre_del_componen t e ;

interface

uses %%Infer%%;

typeT$$id$$Nombre_del_componente = class

Infer : T%%Infer%%;Vertical : Boolean; { Declaración de variable para definir el tipo llamada }constructor Créate( var Inferp : T%%Infer%%);procedure Procesos ( tipo: Byte; Defínícíón_de_Otros_Parámetros );

{ Los parámetros son opcionales }( Parámetros de Procesos }

procedure Nombre_del_componente ( tipo: Byte; Definición_de_Otros_Parámetros );end;

implementation

uses UnitDModuleC, Globales, !!gen!!Gen;

constructor T$$id$$Nombre_del_componente.Créate( var Inferp : T%%Infer%% );begin

inherited Créate;Infer := Inferp;Vertical := True; ( Inicialización, }

( El valor True = Continuación de la secuencia de ejecuciones. }end;

procedure T$$id$$Nombre_del_componente.Procesos ( tipo: Byte;Defínición_de_Otros__Parámetros ) ;

begin

56

{ Código general del componente }

if tipo = 0 thenbegin

( Código particular del componente, para el comportamiento tipo cero }end;

if tipo = 1 thenbegin

{ Código particular del componente, para el comportamiento tipo uno }end;

if tipo = X thenbegin

{ Código particular del componente, para el comportamiento tipo X )end;

{ Código general del componente }

if Vertical then { Para continuar la ejecución en el componente inferior, }Infer.ProcesoS; { Vertical debe tener el valor de True. }

end;

procedure T$$id$$Nombre_del_componente.Nombre_del_componente( tipo: Byte; Definición_de_Otros_Parámetros ); { Para ejecutar el componente }

begin { como función. }Vertical := False;Infer.ProcesoS ( tipo, Otros_Parámetros );Vertical := True;

end;

end.

Lo primero que realiza el componente una vez que se crea, además de definir cual es elcomponente inferior, es inicializar la variable V e r t i c a l como True; con este valor lo que sepretende es que cuando terminen de ejecutarse las instrucciones del método ProcesoS, y sellegue a la condición:

if Vertical then Infer.ProcesoS;

la secuencia de ejecuciones continúe en el componente inferior; para lograr que no se realice lacontinuación de la secuencia, la variable debe tener el valor de F a l s e .

Cuando el componente sea utilizado como función, la forma de llamarlo será directamente, esdecir, dentro del código de algún componente procedimiento o procedimientof, con sólo colocarel nombre del componente. Esto es posible porque dentro del componente existe un método conel mismo nombre del componente.

Al ejecutar el método con el nombre del componente, V e r t i c a l en una primera instanciatendrá el valor de F a l s e , y posteriormente ejecuta el método ProcesoS, pero al llegar a lacondición ( i f V e r t i c a l ... ), la secuencia de ejecuciones no continuará en su componente

57

inferior, debido al valor F a l s e de V e r t i c a l . En la última instrucción del método con elnombre del componente, la variable V e r t i c a l retoma el valor True.

El componente que haga uso de un componente tipo procedimiento-función debe agregar en sucláusula u s e s de la sección i m p l e m e n t a t i o n un parámetro formal (! ! gen ! ! Gen) como sise tratara de una unidad más. Y para ejecutar el procedimiento-función, se escribirá:

Obj_!!gen!!.$$id$$Nombre_Comp_Proc_Funciónl.Nombre_Comp_Proc_Funcíón {Parámetros);

donde Nombre_Comp_Proc_Función es el nombre del componente tipo procedimiento-función y sus correspondientes parámetros.

Existen dentro de esta instrucción dos parámetros formales: ! !gen! ! y $$ id$$ , cuyopropósito es ser sustituidos por los datos que completen la instrucción (tarea del Generador deaplicaciones). La primer palabra, junto con Ob j _ , dará lugar al nombre de la clase generadora(descrita en el capítulo del Generador), y la segunda palabra, junto conNombre_Comp_Funciónl, dará lugar al nombre del componente (con su identificador delreporte o cierre) al que se hará referencia.

La integración de los componentes en la aplicación puede resultar un poco laboriosa, dada la grancantidad y variedad de componentes involucrados, además de tener que colocar un parámetroactual para cada componente de nivel inferior. Para automatizar estas tareas, la herramientaadecuada es un generador de código, descrito en el siguiente capítulo.

58

Capítulo 6. Generador de aplicaciones.

El generador de aplicaciones propuesto para la línea de productos, tiene como característicasprincipales el poseer analizadores semánticos y de un generador de los componentes de laaplicación. En este capítulo se describen las características de un generador de aplicaciones paralíneas de productos, y los pasos necesarios para realizar el ensamble de aplicaciones.

6.1 Introducción.

Al tener la arquitectura de software totalmente definida y los componentes implementados, elproceso de construcción de las aplicaciones puede ser automatizado por medio de un generadorde aplicaciones. Un generador es una herramienta generadora de código, que crea componentesy relaciones del lenguaje o patrones [Illingworth 90]. El generador es por lo general unaherramienta conversacional o posee su propio lenguaje.

Como ejemplo de generadores de código están los Wizards de los lenguajes de Microsoft comoVisual Basic (VB) o Visual C++, estos generadores producen código VB o C++ y construyenarchivos a partir de pantallas de tipo diálogo (preguntan las características deseadas del código agenerar). Las pantallas presentan una serie de paneles que ayudan al usuario a dar valores deentrada por medio de un conjunto de parámetros. Las pantallas también ofrecen consejos alelegir los parámetros, y generalmente ya tienen valores predefinidos. Esos parámetros son laentrada para un preprocesador que selecciona el código apropiado o patrón, y reemplaza losparámetros con los valores elegidos para producir un código especializado o archivo(componente o aplicación). Son conversacionales en el sentido de que ellos hacen una serie depreguntas, las cuales son respondidas, tecleando un texto o seleccionando opciones [Jacobson97].

Otro tipo de generadores poseen su propio lenguaje en lugar de ser conversacionales. Para estetipo, un script (guión, archivo con instrucciones) es escrito en un lenguaje orientado al problemao 4GL, y este es preprocesado para producir como resultado los componentes especializados oconectados a un conjunto de componentes.

Un generador hace más sistemático el proceso de construcción, esto hace al generador y al códigoque generan ser más eficiente, ya que restringe las variaciones que se deben controlar y explotarlos elementos comunes de la línea de productos [Weiss 99].

El generador desarrollado para la tesis, es del tipo conversacional, el cual por medio de un menúmuestra opciones que sirven como parámetros, y definen las características que poseerán lasaplicaciones (sistemas de contabilidad) a construir. Una vez elegidas las opciones(requerimientos) de la aplicación, el generador ejecuta los módulos (fases) que construyen lasaplicaciones: análisis semántico, generación de componentes, y generación de la clasegeneradora.

59

Invertir en herramientas específicas a la línea de productos (generador), hace más rápida laproducción de los sistemas usando el proceso de producción. El realizar un generador nosredituará en el hecho de que el costo total será pagado varias veces, además de que mejorará laeficiencia en el proceso de desarrollo de software.

6.2 Análisis semántico.

El generador de aplicaciones utiliza las ecuaciones de tipo para determinar qué componentesconstituyen los reportes y cierre de la aplicación. A partir de estas ecuaciones se generan loscomponentes elegidos y la estructura adicional que completan los archivos (pantallas, menú yproyecto) necesarios para compilar la aplicación en Delphi.

Pero, antes de generar los componentes, las ecuaciones de tipo son analizadas semánticamentepara determinar si la ecuación de tipo es válida. Al análisis también se le conoce comoverificación de reglas de diseño, porque es por medio de reglas de diseño que el análisis serealiza.

Antes de realizar un análisis tienen que haberse definido las reglas de diseño para las ecuaciones.Las reglas de diseño son restricciones al orden (posición), validez (es permitida su presencia),requerimientos (necesita de otros componentes), y repeticiones (veces que puede estar) de uncomponente. En el caso del generador de aplicaciones desarrollado para la tesis, las reglas dediseño fueron implementadas por medio de tres arreglos: Componente, R e q u i e r e , yMax_veces.

Componente y R e q u i e r e son utilizados a la par, en Componente se colocan loscomponentes involucrados en la obtención del reporte o cierre, los componentes colocados sonlos válidos; la posición donde se coloque cada uno, determinará el orden que deben tener. En elarreglo R e q u i e r e son colocados los componentes superiores que requiere un componenteinferior para su funcionamiento.

Figura 6.1 Arreglos Componente, Requiere y MaxJVeces.

Componente[1]

Componente[2]Requiere[2,1]

Componente[3]Requiere[3,1]

Componente[4]Requiere[4,1]

Componente[5]Requiere[5,1]Requiere[5,2]

•= 'Inicial';

= 'Se Ctas';= 'Inicial';

= 'Se= 'Se"

= 'Se= 'Se"

= 'Se= 'Se"= 'Se"

_Pol_T0',Ctas ' ;

_Pol_T2',Ctas ' ;

^Pol ' ;~Pol TO',"Pol T21,

60

MaxMaxMaxMaxMax

veces[1] :veces[2] :veces[3] :veces[4] :veces[5] :

= 1;= 1;= 1;= 1;= 2;

// Inicial// Se// Se// Se"// Se

Ctas"Pol TO"Pol T2"Pol

Un ejemplo es mostrado en el Figura 6.1, en este caso los componentes válidos son: I n i c i a l ,Sc_Ctas , Sc_Pol_T0, Sc_Pol_T2, Sc_Po l . Si en el análisis de una ecuación de tipo seencontrara un componente no definido en el arreglo Componente, debe indicarse un error. Sien una ecuación el componente S c C t a s estuviera después de Sc_Pol_T0, debe mostrarseotro error. El componente I n i c i a l no requiere de algún componente para su funcionamiento,en cambio Sc_Ctas requiere de I n i c i a l , Sc_Pol_T0 de Sc_Ctas , Sc_Pol_T2 deSc_Ctas , y Sc_Pol de Sc_Pol_T0 ó Sc_Pol_T2. El número máximo de veces quepueden estar presentes en una ecuación, se define en MaxVeces .

Para simplificar el análisis semántico de las ecuaciones de tipo, se optó por la construcción decuatro analizadores semánticos, en lugar de uno que fuera general para todas las ecuaciones; eltamaño de uno general sería muy grande, no definiría muchas restricciones y su administraciónsería difícil. En su lugar, cada tipo de analizador semántico analizará a un grupo de reportes ocierres; los grupos fueron definidos con base en las características similares.

• Analizador semántico para los requerimientos del Grupo Saldos: Saldos, Analítico normaly Analítico por día.

• Analizador semántico para los requerimientos del Grupo Auxiliares: Auxiliares normales,Auxiliares con cuentas sin movimiento, Auxiliares de varios períodos.

• Analizador semántico para los requerimientos del Grupo Balanza: Balanza decomprobación normal y Balanza de comprobación por día.

• Analizador semántico para los requerimientos del Grupo Mensuales: Mayor, Estado deresultados, Balance general, Cierre mensual y Cierre del ejercicio.

6.3 Clase generadora.

El generador debe producir una unidad (Delphi) que contendrá la clase generadora. La clasegeneradora define los componentes que conforman todo el proceso de una opción del sistema decontabilidad, también define un constructor para crear cada componente (objeto) y su relaciónentre cada uno de estos, de acuerdo a como fueron ordenados en su ecuación de tipo. Lasrelaciones son referencias entre los objetos por medio de dependencia de clases.

Las relaciones son realizadas a través del paso como parámetro del componente inferior (claseinferior) al momento de crear el componente superior, definiendo de esta forma una relaciónentre el componente inferior y el superior; esto se lleva a cabo con todos los componentesexcepto con el último, ya que no necesita relacionarse con otro componente.

61

La unidad será denominada como unidad generadora, y se generará una unidad por cada reporteo cierre. La unidad tiene la estructura mostrada en la Figura 6.2 (el rango deNombre_del_Componente_A a Nombre_del_Componente_Z representa a loscomponentes que existen entre los componentes I n i c i a l y F i n a l de una ecuación de tipo).

Figura 6.2 Clase generadora.

unit Nombre_del_requerimientoGen; II Nombre de un reporte o cierre del sistema de/ / contabilidad.

interface // Sección interface (Public), declara que exporta.

uses Inicial, Nombre_del_Componente_A, ... , Nombre_del_Componente_Z, Final;// En la cláusula Uses se colocan los nombres de las// unidades (componentes).

typeTNombre_del_requerimientoGen = class // Declaración de la Clase Generadora.

Inicial : TInicial;Nombre_del_componente_A : TNombre_del_componente_A; II Declaración

// de componentes.

Nombre_del_componente_ZFinal

: TNombre_del_componente_Z;: TFinal;

constructor Créate;destructor Destroy; override;procedure genérate;

end;

// Para crear componentes y relaciones.// Para liberar los componentes.// Método que contendrá la llamada// para iniciar la secuencia// de ejecuciones del proceso.

var Ohj_Nombre_del_requerimiento: TNombre_del_requerimientoGen;II Definición del objeto de la Clase generadora.

implementation // Sección implementation (Private).

constructor TNombre_del_requerimientoGen.Créate;begin // Crea los componentes y los relaciona

// secuencialmente.Finall := TFinal.Créate; // Creación de componentes por medio de llamadas a sus

// correspondientes constructores. Para relacionarlos;// el componente inferior es pasado como parámetro,// excepto para el componente Final.

Nombre_del_componente_Zl := TNombre_del_componente_Z.Créate (Finall);

Nombre_del_componente_Bl :=TNombre_del_componente_B. Créate (Nombre_del_componente_Cl)

Nombre_del_componente_Al :=TNombre_del_componente_A.Créate(Nombre_del_componente Bl)

Iniciall := TInicial.Créate(Nombre_del componente Al);end;

destructor TNombre_del_requerimientoGen.Destroy;begin // Libera los componentes.

Finall.Free;Nombre del componente Zl.Free;

62

Nombre_del_componente_Bl.Free;Nombre_del_componente_Al.Free;Iniciall.Free;

end;

procedure TNombre_del_requerimíentoGen.genérate;begin // Procedimiento que contiene la llamada para

// iniciar la secuencia de ejecuciones del proceso.Iniciall.Procesos;

end;

end.

Un aspecto relevante de esta clase es que permite la posibilidad de hacer referencias directas a losmétodos de cualquier componente. Esta clase tiene como propósito principal el crear loscomponentes y hacer sus relaciones, pero también puede tener una utilidad adicional.

Como ya fue descrito anteriormente, todo lo que sea declarado en la sección i n t e r f a c e d e unaunidad se exporta, y en este caso la unidad generadora exporta una definición de tipo de clase, yuna variable (objeto), de la cual se hará particular referencia:

Obj _Nombre_del_requerimiento

Si la unidad generadora es utilizada en la cláusula u s e s de la sección i m p l e m e n t a t i o n delos componentes involucrados, lo que se producirán son referencias circulares; es decir, unaunidad llama (uses) a otra unidad, y ésta última llama (uses) a la primera; ambas se llaman almismo tiempo.

Todos los componentes que tengan declarado el uso de Nombre_del_requerimientoGen(unidad generadora) en su cláusula u s e s de i m p l e m e n t a t i o n , producirán referenciascirculares porque la unidad generadora llamó con anterioridad a todas las unidades de loscomponentes para crearlos y relacionarlos.

Al realizar una referencia circular entre un componente y la unidad generadora, desde elcomponente se tendrá acceso a la variable, y por consiguiente es posible "accesar" a cualquiermétodo (procedimiento o función) de todos los componentes; porque la variable (objeto) es unainstancia de la clase generadora, la cuál tiene relación directa con todos los componentes, desdesu definición (declaración de la clase).

Esta posibilidad que brindan las referencias circulares se ha utilizado para poder hacer referenciasal código de los componentes sin importar la posición del componente en la arquitectura porniveles (colaboración), y es el mecanismo utilizada para poder llamar a un componente tipofunción o tipo procedimiento - función.

63

Las condiciones básicas para poder ejecutar un componente desde el interior de otro son:

• El componente a ser llamado y el componente que va a llamar, deben tener declarada enla cláusula u s e s de i m p l e m e n t a t i o n el parámetro formal: ! ! gen! ! Gen, como si setratara de una unidad más. Una de las tareas del generador de aplicaciones es encontrareste parámetro, y sustituirlo por el nombre de la unidad generadora.

• Para hacer referencia a un procedimiento o función se escribirá una sentencia con estaforma:Obj_! ! gen ! ! . $$id$$Nombre_Componentel. Nombre_Procedimiento__o_Función;.

Componentes Distribución general

Inicial

Componente_A

Componente_B

Componente_C

Componente_D

Componente_E

Componente_F

Componente_G

Componente_H

Final

Procedimientosprincipales

Funciones

Figura 6.3 Representación de la Unidad generadora como un bus de comunicaciones.

Una unidad generadora puede interpretarse como un bus de comunicaciones; por medio de launidad y de la clase generadora que contiene, es posible establecer relaciones más allá decomponente superior a componente inferior. En la Figura 6.3 son mostradas algunas de lasformas posibles de ejecución de componentes, los componentes que pueden ser ejecutados vía launidad generadora son: A, C, F, G y H, los componentes que pueden ejecutar a otros vía launidad generadora son: A, C, y E.

64

6.4 Ensamble con la pantalla al usuario.

Una vez que el generador de aplicaciones produce los componentes, y la unidad generadora decada reporte y cierre, se debe hacer manualmente la relación entre la unidad generadora y lapantalla al usuario que ejecutará el requerimiento del sistema de contabilidad.

Las pantallas son implementadas directamente en Delphi, y el único código que contienen es paraactivar las tablas temporales que el reporte o cierre va usar, y un proceso para inicializar estastablas. Para unir el código generado con la pantalla, se debe hacer lo siguiente en la unidad de lapantalla:

• Agregar una cláusula u s e s en la sección i m p l e m e n t a t i o n .

uses UnitDModuleC, Globales, Nombre_del_requerimientoGen;

• En el evento Actívate de la pantalla debe crearse el objeto de la clase generadora.

Obj_Nombre_del_requerimiento := TNombre_del_requerimientoGen. Créate;

• Dentro del código de un evento (Click, Enter, etc.) debe ejecutarse el proceso.

Obj Nombre del requerimiento.genérate;

• Al salir de la pantalla se recomienda eliminar el objeto.

Obj_Nombre_del_requerimiento.Destroy;

6.5 Construcción de aplicaciones.

Para obtener un sistema de contabilidad por medio del Generador de aplicaciones, el usuario debeseleccionar el tipo de sistema, que dependerá del tipo de Unión de crédito al que estará destinadoel sistema: Comercial, Industrial o Agropecuaria. Una vez seleccionado el tipo, automáticamentese eligen las opciones (requerimientos) que contendrá el sistema de contabilidad, el usuario tienela posibilidad de agregar o eliminar opciones. (Véase Figura 6.4).

Al tener las opciones seleccionadas debe oprimirse el botón de Verificación de reglas, para que elgenerador compruebe que las ecuaciones de tipo (cadena que define la forma de integración delos componentes del proceso) cumplen con las reglas de diseño de construcción de aplicaciones.Verifica que todas las ecuaciones sean semánticamente válidas. En caso de encontrar unaecuación de tipo que no sea válida, se muestran mensajes de error en el cuadro de descripcionestextuales. En caso de que no existan errores, con el botón de Generación de aplicación, seobtiene el código fuente de la aplicación.

65

Opciones generales

[ Entrada

¡ 17 Catálogoi Edo. de Resudados¡ | 7 Grupos y Reglasj Balance General¡ 17 Grupos j>RegJas

PÓDzasAlta de pólizas

Repartes

f 7 Saldos| 7 MayorAiniEares17 Normal

17 Cuentas M I movinentor* Vano» Peí iodosBalanza de comprobación| 7 Previa

neportesAnalítica de cuentas17 Normo! . •

Reportes mensuales ']7 Balance general|7 Edo de Hesitado*1

. T ipa| -

, Cierres,J7 Mensual

•-'17

•• Otros repolles• T~ R- de KsponsabSdades

' " VerKcaüáñ de'recjIaV' j ' Generación de epfcaciónI •>•'*

Opciones generadas por medio de componentes jp detcrrpcion

JBALANZA POR DÍAIESTADO.DE RESULTADOS¡BALANCE GENERAL¡CIERRE MENSUALICIERRÉ'DEL EJERCICIO

1 Ecuación de tipo Jjlnicial[Sc_Das[Sc_Pol_TO[Sc Pol[Sc_SA TO[Sc_SA[Sc_ValidaCtaPol[Pc_Su -imaMovs_TO[Pc_SumaMovs{Pc_AgFSA_TÓ[Pc_Ac|rSA[Pc_Arbol[Pc Poderte!¡Se Pol_TO[Sc_Pol[Pc_SumaMovs_TO[Pc SumaMovs[Pc AgrSA T0[Pc Agr|sAlPc_Arbol[Sc_Gpos_TO[Sc Gpos[Sc_6pos_T1[Sc_6pos[Sc_Regs_TÓ[Sc_JRegs[Sc_Regs T1[Sc_Regs[Pc_CM(Final]]]]]]]]]]]]]]]]]]]]]J]]I]]]]

Figura 6.4 Generador de aplicaciones para la Línea de Sistemas de Contabilidad de Uniones.

Para obtener la aplicación ejecutable, se debe compilar el proyecto Proycont.Dpr ubicado en elsubdirectono C:\AleaJE\Comps_Proy (Figura 6.5); la aplicación ejecutable Proycont.Exe debecopiarse a un nuevo subdirectono (C:\Contabilidad, etc.), así como todo el contenido delsubdirectorio C:\AleaJE\DataBases, para obtener la nueva aplicación.

AleaJE Componentes

Generador

Generados

Comp_Proy

DataBases Locales

Figura 6.5 Directorios utilizados para organizar el código

66

La estructura de los directorios utilizada para organizar el código fuente y los archivosejecutables, es mostrada en la Figura 6.5. Los directorios contienen:

• Componentes: las plantillas de componentes leídos por el Generador.• Generador: el código del generador y el Generador.Exe.• Generados: los componentes producidos por el Generador.• CompsProy: los archivos fijos que completan los sistemas de contabilidad (unidades

siempre presentes, pantallas [.Dfr], y el proyecto [Proycont.Dpr]).• DataBases: la base de datos y los scripts para crear las tablas en InterBase.• Locales: tablas temporales en Paradox.

El mantenimiento al generador se da cuando la aplicación a generar tiene otros requerimientosdiferentes a los que puede satisfacer el generador. Para tales casos se debe: agregar los nuevoscomponentes al subdirectorio C:\AleaJE\Componentes, y en el Generador agregar el código de laecuación de tipo y las reglas de diseño necesarias para generar las opciones apropiadas.

6.6 Resultados.

Como se mencionó en la sección anterior, el Generador de aplicaciones puede producir tres tiposde sistemas de contabilidad (dependiendo de la Unión de crédito): Comercial, Industrial oAgropecuaria. Los tres tipos de sistemas tienen una infraestructura básica, es decir tienenrequerimientos comunes. Todos los sistemas tienen requerimientos para: 1) mantenimiento de labase de datos (Catálogo, Grupos y reglas de agrupación del balance general, Grupos y reglas deagrupación del estado de resultados, Pólizas), 2) obtener reportes mensuales (Balance general yestado de resultados), y 3) realizar los cierres (Mensual y del Ejercicio).

Las Figuras 6.4, 6.6 y 6.7 muestran la interface del Generador con las opciones (requerimientos)seleccionadas para producir los sistemas de contabilidad para una Unión de crédito: comercial(Figura 6.4), industrial (Figura 6.6) y agropecuaria (Figura 6.7).

Puede observarse que las diferencias entre los tres tipos, radica principalmente en los reportes queposee cada tipo de sistema, con excepción de los reportes mensuales, Saldos y Mayor. Cada tipode Unión necesita requerimientos específicos, en el caso de las Uniones agropecuarias susreportes son para obtener información de un determinado rango de fechas o un día, como son susreportes de auxiliares para varios períodos, balanza por día y analítico por día. La diferenciaentre los sistemas para Uniones comerciales e industriales, es el reporte de auxiliares con cuentassin movimiento solicitado por las Uniones comerciales.

Las opciones (requerimientos) determinadas para cada tipo de sistema no impide la posibilidad deeliminar o seleccionar otras opciones en la interface. Las Uniones de crédito en dado casopueden solicitar que la información sea presentada de forma más detallada, como es el caso de lasUniones agropecuarias con sus reportes por fecha. Los sistemas para las Uniones comerciales eindustriales en dado caso pueden incorporar reportes de las Uniones agropecuarias.

67

Opciones geneidlei T i p o 11 •'•. •..•!

Entiadap Catálogo

i Eda. de Resultado*P Grupos y Regí»Balance Geneialp

¡P6 IM«. p Alia de potas

i

Reportop Saldos17 MayaAuxiliares[7 Namal|~ Cuenta» un movmentaT Varios Peí íodotBalanza de comprobaciónp Previa

r Par día

RepoileíAnalítico de cuenta*P Namalr PoiDia

neporle* •emuaJeiP Balance geneialP Ecbdeftaukado»

Cienesp Msmualp Emaáo

Olios lepnlcír R dernpornabMadei

Verificación de reglé» I Generación de apícaciñn I

OprJonei geneíadax pot medin de caniranenia* • desciipción

ESTADO DE RESULTADOSBALANCE GENERALCIERRE MENSUALCIERRE DEL EJERCICIO "«I

Ecuación de tipolnicial[Sc_aas[Sc_Pol_T01Sc_PolISc_SA_T0[Sc_SA[Sc_ValidaDaPol[Pc_BalDia[Pc SumaMovs T1[Pc SumaMovs[Pc_AgrSA_T2[Pc_AgtSAIPt_AgrNom_TO[Pt_AgrNom[FinaT]lJ]]]l]]]]]]]

Descripción de cada componente:

1

Figura 6.6 Ejemplo de un sistema de contabilidad para una Unión de crédito industrial.

Opción** gánetele* ' - . "• '.-. ?fc*O (Agropecuaria. . . -.. '

. • : -ReportesAnalHitw de cuenta*

r

; f* 'CueniptínmovMwAii P Batanea ow»

Opciones peflgidojwt por neoKi de fiOMpoifentei! y

Ecuación de tipo:\ÜXÍLÍARE?DE" VARIOS PÉRÍODaS r •' llmcialtSc_Das[Sc_Pol_T2[Sc_Pol[Sc_SA_T0{Sc_SA[Sc_Val¡daDaPol[Pc_Au : SWXILlAHtb Ut VAHIUb PtRIODDb ^¡xCSMIPc.AgrCSMISc.NomCtalFinallini]]]!]3ALANZA

Descripción de cada componente:

Inicial Define las llamadas principales, siempre está al inicio de los niveles.

ALANZAPOR DÍASTADO D E " R E S U L T A D O S

Figura 6.7 Ejemplo de un sistema de contabilidad para una Unión de crédito agropecuaria.

68

Las aplicaciones que pueden ser producidas por el Generador no se limitan a los tres tipos deUniones de crédito, antes descritos. La interface del Generador permite activar y desactivaropciones para poder producir sistemas de contabilidad "personalizados", esto amplia el númerode aplicaciones que pueden ser generadas. Los sistemas de contabilidad personalizados estándirigidos a otros tipos de Uniones de crédito.

La Figura 6.8 muestra un sistema de contabilidad personalizado con los requerimientos básicosnecesarios para funcionar y agrega reportes especiales (Otros reportes) que no están presentes enotros tipos de sistemas de contabilidad.

Opciones generales

EntiadaP CatálogoEdo. de ResultadosP Grui.cra y Reglas

1 Balance GeneidlP Grupos y Regldj

PuliídiP Alta de pólizas

Repoileíp Salde»p M*wAuxiliaicsp Normalf" l.'uenlas sn roovmenlof ^anoi "«iodosBiilaiua de comptobación

RepollosAnalítica de cuenlair Normal

r Por D'a

RepoileíP Baldru-e yeneial

p Edo :leR.™jlai1ot

Cintelp Mensualp Ejeroao

Qlioi icpntesP H. de (esponiahUades

P SIF

P Por día

Veiihcaraón áe regla» | Genaaripn dg apleaeifln|

Opciones imneradat po| mnfiu de componente» y deteripcián

BALANZA POR DÍAESTADO DE RESULTADOS

CIERRE MENSUALCÍÉRRE DEL EJERCICIO

Ecuación de tipo:InicialISc Das[Sc Pol.TOISc PolfSc SA_TOtSc_SA[Sc_ValidaQaPol[Pc_SumaMovs_T0IPc_SumaMovs[Pc_AgiSA_T01Pc_AgíSA[Pc_A[bol[Sc_Gpos_Tl[-Sc_GposlSc_Regs_T1[Sc_Regs[Pc_Balance[Sc_NomGpo[Final]]]]]]];

Descripción de cada componente:

Figura 6.8 Ejemplo para producir un sistema de contabilidad personalizado.

Hasta este punto finaliza el desarrollo de los elementos de la implementación de la línea deproductos. En el siguiente capítulo son mostradas las conclusiones y trabajos futuros de la tesis.

69

Capítulo 7. Conclusiones y trabajos futuros.

Con el desarrollo de esta Tesis se ha tratado de demostrar la viabilidad de implementar líneas deproductos de software, así como mostrar un proceso para su desarrollo. Como capítulo final, sondescritas algunas consideraciones que deben tomarse en cuenta para implementar una línea deproductos, las aportaciones de la tesis y propuestas sobre trabajos futuros.

7.1 Conclusiones.

El enfoque de desarrollo basado en líneas de productos de software cambia el paradigma deldesarrollo de software para un producto, a un desarrollo para varios productos. No obstante, sedebe tomar en cuenta que el desarrollo de una línea de productos no es aplicable a todos loscasos, porque requiere de una inversión mayor de recursos. Antes de proponer una línea deproductos es esencial realizar un análisis del mercado que justifique la inversión. Un resultadoimportante es que el tiempo de desarrollo para obtener el primer producto, es mayor que elrequerido en los métodos tradicionales. Necesita de la participación de varios clientes y de laexperiencia del personal involucrado en el desarrollo de este tipo de productos. En el aspectotécnico, los componentes tienen que ser diseñados para ser fácilmente probados y adaptados.

Entre las aportaciones que este trabajo hace en particular están:

• Propuesta de un método (ADLIS) para la obtención de una arquitectura de software parauna línea de productos.

• Estrategia de extensión del lenguaje de un ambiente de desarrollo, la cual consiste en elsoporte de parametrización de componentes por medio de clases parametrizadas.

• Mostrar que delegación es un mecanismo flexible para la implementación decomponentes.

• Utilización de referencias circulares entre unidades para la implementación dearquitecturas de software.

• Generador de líneas de productos.• Ejemplo de una línea de productos para sistemas empresariales.• Utilización de líneas de productos en aplicaciones para base de datos.

Las principales aportaciones de la tesis están centradas en los aspectos técnicos para laimplementación. La literatura encontrada para implementación de arquitecturas, muestraejemplos generalmente en lenguaje C++ haciendo uso de herencia parametrizada(parametrización por templates y herencia de clases); la tesis propone delegación como unmecanismo flexible para la implementación de arquitecturas, que no limita la posibilidad deimplementación de diversos tipos de arquitecturas de software.

70

Si bien existen actualmente muchos métodos para realizar análisis y diseños de dominios, losmejores son productos comerciales con un alto costo, y aunque no se pudo disponer de ellos, enla literatura están descritas las etapas básicas y los elementos que generan. A partir de laliteratura encontrada se determinó un método de análisis y diseño para la obtención de unaarquitectura de software.

El método que se propone no es único para obtener arquitecturas de software para líneas deproductos, se ha diseñado para facilitar la implementación de una línea de productos (sistemas decontabilidad para Uniones de crédito). Todas las fases están orientadas para obtener unaarquitectura por niveles.

De la técnica de implementación utilizada dependerá la facilidad de construcción de la línea deproductos. Decidimos utilizar programación orientada a objetos por sus características parahacer referencias a código, además de la facilidad.

Líneas de productos está emergiendo como un método importante para mantener bajos los costos,reducir e' tiempo de desarrollo, y tener una ventaja competitiva en el mercado.

7.2 Alcance de la tesis.

Actualmente, para la propuesta de Arquitecturas de software para líneas de productos existeinformación de casos exitosos en donde ésta se ha aplicado, pero aún es escasa, con teorías queaún no se han validado para todos los casos, así como su aplicabilidad para producir productoscomerciales. La información que se dispone, es debida a investigaciones de centros deingeniería de software de diversas universidades, en donde varios investigadores proponen laimplantación de líneas de productos, pero son pocos los casos que comienzan a utilizarlos, y noexiste documentación de casos en donde se utilicen para su implementación, lenguajescomerciales. La Tesis valida:

• La viabilidad de arquitecturas para el desarrollo de aplicaciones de un ambienteempresarial.

• La implementación de arquitecturas por medio de una herramienta de desarrollocomercial.

Los elementos de comprobación de la tesis son: la propuesta de un método o ciclo de vida de unaarquitectura de software para una línea de productos, la implementación de los componentes queresulten de la arquitectura, y el desarrollo de un generador de aplicaciones. Describiendo latécnica que se utilizó para la implementación de los componentes, así como del generador.

71

7.3 Trabajos futuros.

Existen muchos aspectos a estudiar en lo que respecta a las arquitecturas de software para líneasde productos, así como en técnicas o mecanismos para implementar líneas de productos. Sepuede decir que las propuestas que actualmente surgen son nuevas. Si bien la perspectiva dedesarrollar familias de sistemas no es nueva, hasta no hace muchos años comenzaron a surgir lasestrategias y técnicas para hacer realidad este tipo de soluciones.

Como posibles trabajos futuros a partir de este trabajo se proponen:

• Implementación de una arquitectura por niveles haciendo uso únicamente de la cláusulauses, pero se tendría que buscar un mecanismo para que los componentes fueransimétricos; porque habría que identificar en que momento se está llamando a ejecución elprocedimiento principal del componente y cuando al del componente inferior.

• Implementación de una arquitectura por niveles por medio de dependencia de clases, enotros lenguajes de programación orientada a objetos que no poseen herenciaparametrizada (como Java, Visual Basic, etc.).

• Investigar sobre patrones de diseño para aplicaciones de base de datos, esto simplificaríala construcción de arquitecturas para bases de datos.

• Investigar sobre métodos de análisis y diseño de dominios, y proponer uno para seraplicado en cualquier tipo de dominio. Los métodos existentes utilizan aspectos quepueden considerarse redundantes para la obtención de elementos reusables, como es elcaso de Foda [Kang 90].

• Investigar sobre la viabilidad de Foda [Kang 90] para la obtención de arquitecturas desoftware para líneas de productos.

• Determinar cuál es el contexto a nivel organización para la implantación de líneas deproductos.

Como posibles trabajos relacionados a este trabajo se proponen:

• Desarrollar un generador de aplicaciones con administrador de configuraciones oversiones, y un módulo para definir ecuaciones de tipo.

• Optimizar el código de los componentes por medio de directivas al compilador, u otrastécnicas.

• Validar el método propuesto (ADLIS) en otros dominios.

72

Apéndice A.

Código del generador de aplicaciones y componentes.

El código del generador está integrado por varias unidades, la estructura principal es mostradaen la siguiente figura:

a Generador

Defjipos

mgGenerador

P Saldos

P Balanzas

P Auxiliares

P Mensuales

Parser

agenerador es la unidad principal y hace uso de los procedimientos localizados en lasunidades de los parsers (Pbalanzas, Psaldos, Pauxiliares y Pmensuales) y mgGenerador.Los parsers a su vez hacen uso de la unidad Parser. En la unidad Deftipos son declaradastipos y constantes usadas por varias unidades.

• El código de cada tipo de componente es mostrado por medio de algunos componentesrepresentativos:

TipoInicialFinalGlobalesProcedimientoProcedimiento-FunciónDecoradorFunción

ComponenteInicialFinalGlobalesSc_CtasPe AgrSAPcAgrSA TO, Pc_AgrSA_TlSc_NomCta

73

A.2 Generador.

Código de a_Generador.{ Unidad principal que controla las llamadas a los procedimientos deanálisis y generación del código para Sistemas de contabilidad. }

unit a_generador;

interface

usesWindows, Messages, SysUtils, Classes, Graphics, Controls, Forms,Dialogs, ExtCtrls, StdCtrls, DBCtrls, DBGrids, Grids,Def_tipos, mgGenerator, DBSystem, P__saldos, P_aux i liares,P_balanzas, P_mensuales;

typeTf_generador = class(TForm)Bevell: TBevel;Labell: TLabel;Label2: TLabel;Label3: TLabel;Label4: TLabel;Label5: TLabel;Label6: TLabel;Label7: TLabel;Label8: TLabel;Label9: TLabel;LabellO: TLabel;Labelll: TLabel;Labell2: TLabel;Labell3: TLabel;Labell4: TLabel;Labell5: TLabel;cbTipo: TComboBox;boton_DRC: TButton;botón Gen: TButton;dbgMemoDRC: TDBGrid;dbmMemoDRC: TDBMemo;cbCatalogo: TCheckBox;cbGruposReglasER: TCheckBox;cbGruposReglasBG: TCheckBox;cbPolizas: TCheckBox;cbSaldos: TCheckBox;cbMayor: TCheckBox;cbAuxNormal: TCheckBox;cbAuxCSM: TCheckBox;cbAuxVP: TCheckBox;cbBzaPrevia: TCheckBox;cbPorDia: TCheckBox;cbAnaNormal: TCheckBox;cbAnaDia: TCheckBox;cbBalGral: TCheckBox;cbEdoResult: TCheckBox;cbMensual: TCheckBox;cbEjercicio: TCheckBox;cbRelResp: TCheckBox;cbSIF: TCheckBox;procedure FormShow(Sender: TObject);procedure boton_DRCClick(Sender: TObject);procedure boton^GenClick(Sender: TObject);procedure CopyArraysInt(var Target, Source: array of Integer);procedure CopyArraysStr(var Target, Source: array of String);procedure FormClose(Sender: TObject; var Action: TCloseAction);procedure InitOptions;procedure cbTipoChange(Sender: TObject);procedure OptionsFile;procedure OptionsBoolean(strOpt: String; flag: Boolean);

privatef Private declarations }

public{ Public declarations }

end;

f_generador :myGenerator :myDBSystem :Parser_saldosParser_auxiliaresParser balanzaParser mensuales

Tf_generador;TmgGenerator;TDBSystem;

: TParser_saldos;TParser_auxiliares;TParser_balanza;TParser mensuales;

// Forma (pantalla).// Generador de software.// Operaciones con una tabla.// Analizador para saldos.// Analizador para auxiliares.// Analizador para balanzas.// Analizador para reportes// mensuales.

// Ecuaciones de tipos, una por opción del sistema de contabilidad.TEQN_Saldos: String;TEQN_Mayor: 5tring;TEQN_Anali tico, TEQN_AnaliticoDia, TEQN_AnaliticoDiaN: String;TEQN_Auxiliares, TEQN_Auxiliares_CSM, TEQN_Auxiliares_VP: Str ing;TEQN_Balanza, TEQN__BalanzaDia: String;

TEQNString

// A// lNVSNV_MNV^ANV^AHV_BNV_E

// Lutiliz

// eLU_SLU_MLU~ALUALU_BLU_E

// V// aPathF: T

implem

uses U

1$R *.

// Copprocedvar inbegin

for Ta

end;

/ Copprocedvar inbegin

for Ta

end;

// Al // la procedegin// CmyGemyDBParsParsParsPars

end;

/ Eje// dif// men•rocedi/ar Eregin// IErro

// EmyDB

// •

// ETEQN

'S'S'S'S'P' P'P'P'F

// PParsParsParsParsCopy

74

_EsCado, TEQN_Balance, TEQN_CierreMensual, TEQN_CierreEjercício:;

rreglos de tipo entero, para contar el número de veces que aparecenos componentes en la construcción de una opción.aldos: TArrayl;ayor: TArrayl;nalitico, NV_AnaliticoDia, NV_AnaliticoDiaN: TArrayl;uxiliares, NV_Auxiliares_CSM, NV_Auxiliares_VP: TArrayl;alanza, NVBalanzaDia: TArrayl;stado, NV_Balance, NV_CierreMensual, NV_CierreEjercicio: TArrayl;

istas de tipo string, contienen Ion nombre de los componentesadosn la construcción de una opción (no existen repeticiones}.aldos: TArrayS;ayor: TArrayS;nalitico, LU_AnaliticoDia, LU_AnaliticoDiaN: TArrayS;uxiliares, LU_Auxiliares_CSM, LU_Auxiliares_VP: TArrayS;alanza, LU_8alanzaDia: TArrayS;stado, LUBalance, LU_CierreMensual, LU_CierreEjercicio: TArrayS;

ariables para la creación de un archivo con las opciones disponiblesl usuario.: String;extFile;

entation

DM_tablas;

DFM>

ia arreglos de tipo entero.ure Tf_generador.CopyArraysInt(var Target, Source: array of Integer);di: Integer;

indi:=Low(Source) to High(Source) dorget[indi] := Source[indi];

ia arreglos de tipo string.ure Tf_generador.CopyArraysStr(var Target, Source: array of String);di: Integer;

indi:=Low(Source) to High{Source) dorget[indi I := Source[indi];

iniciar la forma se crean los objetos para realizar el análisis ygeneración.ure Tf_generador.FormShow(Sender: TObject);

rear objetos.nerator := TmgGenerator.Créate;System := TDBSystem.Créate;er_saldos := TParser_saldos.Créate;er_auxiliares :- TParser_auxiliares.Créate;er balanza :- TParser balanza.Créate;er_mensuales := TParser_mensuales.Créate;

cuta las análisis por cada opción, se utilizan cuatro analizadoreserentes. De cada análisis se obtienen descripciones textuales osajes de error.ure Tf_generador-boton_DRCClick(Sender: TObject);rores_totales: Integer;

niciaüzar.res totales := 0;

liminar información que exista en tablas temporales.System.Init;

•*•» Opción: SALDOS •••*•

cuación de tipo._Saldos :- 'Inicial[' +c_Ctas[' +c_Pol_TO[Sc_Pol[' +c_SA_TO[Sc_SA[' +c_ValidaCtaPol[' +c_SumaMovs_TO[Pc_SumaMovs[c~AgrSA_ToTPc_AgrSA [ ' <-c_Arbol[' +t_AgrNom_TO[Pt_AgrNom[' +inalIJ)])]]]]

roceso de análisis.er_saldos.TEQN :^ TEQN_Saldos;er_saldos .Iniciaüzar;er_saldos.Análisis;er_saIdos.Descripción;ArraysInt fNV_Saldos, Parser saldos.Num veces);

CopyArraysStr(LU_Saldos, Parser_saIdos.ListaUnicos);

// Acumular mensajes.myDBSystem.AddMsg('SALDOS', Parser_saldos.Mensajes);

// Sumar errores.Errores totales := Errores totales + Parser saldos.Errores;

// **••• Opción: ANALÍTICO ••**•

// Ecuación de tipo.TEQNAnalitico := 'Inicial[' +

'SC_Ctas[' +•Sc_Pol_TO[Sc_Pol[' +'SC_SA_TO[Sc_SA[ ' +'Sc_VaHdaCtaPol [ ' +'Pc_SimaMovs_TO[Pc_SumaMovs[' +'Pc_AgrSA_TO[Pc_AgrSA(' +•Pc_Arbol [ ' +'Pt_AgrNom_Tl[Pt_AgrNom[' +•Final]]])]]]]]]!]]]•;

// Proceso de análisis.Parser_saldos.TEQN := TEQN_Analitico;Parser_saldos.Inicializar;Parser saldos.Análisis,-Parser_saldo5.Descripción;CopyArraysInt(NV_Analitico, Parser saldos.Num veces);CopyArraysStr(LU_Analitico, Parser saldos.ListaUnicos);

// Acumular mensajes.myDBSystem.AddMsg('ANALÍTICO NORMAL', Parser_saldos.Mensajes)

// Sumar errores.Errores totales := Errores totales Parser saldos.Errores;

// • •••• Opción: ANALÍTICO POR DÍA (la. Ecuación)

// Ecuación de tipo.TEQN_AnalitlcoDia := 'Inicial!' +

'ScCtas!' +'Sc_Pol_Tl[Sc_Pol[' +'Sc_SA_TO[Sc_SA[' +•Sc'validaCtaPol(' +'Pc_SumaMovs TO[Pc_SumaMovs[' +' Pc~AgrSA_TlTPc_AgrSA [' +' Pc'Arbol [' +'Final]11)1] 1] ]]])';

// Proceso de análisis.Parser_saldos.TEQN := TEQN_AnaliticoDia;Parser_saldos.Inicializar;Parser_saldos.Análisis;ParserosaIdos.Descripción;CopyArraysInt(NV_AnaliticoDia, Parser_saldos.Num_veces);CopyArraysStr(LU^AnaliticoDia, Parser_saldos.ListaUnicos);

// Acumular mensajes.myDBSystem.AddMsg('ANALÍTICO POR DÍA {la. Ecuación)',

Parser_saldos.Mensajes);

// Sumar errores.Errores totales := Errores totales Parser saldos.Errores;

// *•••• Opción: ANALÍTICO POR DÍA (2a. Ecuación) •***»

// Ecuación de tipo.TEQN_AnaliticoDlaN := 'Inicial!' +

'Pt_AgrNom_T2IPt_AgrNom[' +1 FinalJ]]';

// Proceso de análisis.Parser_saldos.TEQN := TEQN_AnaliticoDiaN;Parser_saldos.Inicializar;Parser_saldos .Análisis;Parser_saldos.Descripción;CopyArraysInt{NVAnaliticoDiaN, Parser saldos.Num veces);CopyArraysStr(LU_AnaliticoDiaN, Parsersaldos.ListaUnicos);

// Acumular mensajes.myDBSystem.AddMsg('ANALÍTICO POR DÍA (2a. Ecuación)',

Parser_saldos.Mensajes);

// Sumar errores.Errores_totales := Errores^totales + Parser saldos.Errores;

// ***** opción: Mayor * * * *

// Ecuación de tipo.TEQN_Mayor := ' Inicial[' +

'Sc^CtasI1 +' S e P o l T 0 [ 5 c P o l [ ' +

'S''''

/ /

// ParsParParParsCopyCopy

// AmyDB

// SErro

// •

// ETEQN

•'''S''•F

// PParsParsParsParsCopyCopy

// AmyDB

'arse

// SErro

// *

// ETEQN

'S'S'S'S' 1P'S'F

// PParsParsParsParsCopyCopy

// AmyDB

'arser

// SErro

/I •

// ETEQN

'S•S'3•S'S'P'S1P' P'Pc' S' F

75

c_SA_TO[Sc_SA[' +Sc_ValidaCtaPol[' +Pc_Mayor[' +Sc_NomCta[' +Final]]]]]])]';'Sc_NomCta[' +'Final]]]]]]]]';

Proceso de análisis.er mensuales.TEQN := TEQN_Mayor;ser_mensuales.Inicializar;ser_mensuales.Análisis;er_mensuales.Descripción;ArraysInt(NV_Mayor, Parser_mensuales.Num_veces);ArraysStr(LU_Mayor, Parser_mensuales.ListaUnicos);

cumular mensajes.System.AddMsg('Mayor', Parser_mensuales.Mensajes);

umar errores.res totales := Errores totales + Parser mensuales.Errores;

•••• Opción: AUXILIARES (Por cursores) *****

cuación de tipo._Auxiliares := 'Inicial!1 tSc_Ctas[' +Sc_Pol_TO[Sc_Pol[' +Sc_SA_TO|Sc_SA[' +c_ValidaCtaPol[' +Pc_AuxCursores t' + Sc_NomCta | ' +inal]]]]]]]]]';

roceso de análisis.er_auxiliares.TEQN := TEQNAuxiliares;er_auxiliares. Inicializar;er_auxiliares.Análisis;er_auxiliares. Descripción;ArraysInt(NV_Auxiliares, Parser_auxiliares.Num_veces);ArraysStr(LU_Auxi liares, Parser_auxiliares.ListaUnicos);

cumular mensajes.System.AddMsg('AUXILIARES (Por cursores)',r_auxiliares.Mensajes);

umar errores.res totales := Errores totales Parser auxiliares.Errores;

**** Opción: AUXILIARES CON CUENTAS SIN MOVIMIENTO (CSM)

cuación de tipo._Auxiliares_CSM ;= 'Inicial!' +c_Ctas[' +c_Pol_T2[Sc_Pol[' +c_SA_TO[Sc_SA[' +c_ValidaCtaPol[' +Pc_AuxCSM [ ' +c_AgrCSM[' +c_NomCta[' +inal]]

roceso de análisis.er^auxiliares.TEQN := TEQN_Auxiliares_CSM;er_auxiliares.Inicializar;er__auxiliares .Análisis;er_auxiliares.Descripción;ArraysInt(NV_Auxiliares_CSM, Parser_auxiliares.Num_veces);ArraysStr(LU_Auxiliares_CSM, Parser_auxiliares.ListaUnicos)

cumular mensajes.System.AddMsg('AUXILIARES CON CUENTAS SIN MOVIMIENTO (CSM)'_auxiliares.Mensajes);

umar errores.res totales := Errores_totales + Parser auxiliares.Errores;

•«*. Opción: AUXILIARES DE VARIOS PERIODOS (VP)

cuación de tipo._Auxiliares_VP := 'Inicial!' +c_Ctas(' tc_Pol_TO[Sc_Pol(' +c_SA_Tl[Sc_SA(' tc_ValidaCtaPol(' +c_Pol_T4lSc_Pol[' +c_SalDial' *c_Pol_T3(Sc_Pol(' +c_SumaMovs_TO[Pe SumaMovs!' +c _ A g r S A _ T 0 T P c _ A g r S A ( ' •^ f tuxCSM! ' +

c _ N o m C t a [ ' »i n a l ] ] ] ] ] ) ] ] ] ] ] ] ] ] ] ] ] ] ' ;

// Proceso de análisis.Parser_auxiliares.TEQN := TEQN_Auxiliares_VP;Parser_auxiliares.Inicializar;Parser_auxiliares.Análisis;Parser_auxiliares.Descripción;CopyArraysInt (NV_Auxiliares_VP, Parser_auxiliares .Num_veces) ;CopyArraysStr (LU_Auxiliares_VP, Parser_auxiliares. ListaUnicos) ;

// Acumular mensajes.royDBSystem.AddMsgf'AUXILIARES DE VARIOS PERIODOS (VP) ',

Parser_auxiliares.Mensajes);

// Sumar errores.Errores totales := Errores totales + Parser auxiliares.Errores;

// ***** Opción: BALANZA *****

// Ecuación de tipo.TEQN^Balanza := 'Inicial[' +

'Sc_Ctas{' +•Sc_Pol_TO[Sc_Pol[' +'Sc_SA_T0[Sc_SA í' +'Sc_ValidaCtaPol[' +' Pc_SumaMovs_Tl [ Pc_SumaMovs [' +'Pc~AgrSA_T2lPc_Ag7sA[' +'Pt_AgrNom_TO[Pt_AgrNom[' +••Final]]]]]]])]]]]]';

// Proceso de análisis.Parser_balanza.TEQN := TEQNBalanza;Parser_balanza.Inicializar;Parserebalanza.Análisis;Parser_balanza.Descripción;CopyArraysInt(NV_Balanza, Parser_balanza.Num_veces) ;CopyArraysStr(LU_Balanza, Parser_balanza.ListaUnicos);

// Acumular mensajes.myDBSystem.AddMsg('BALANZA', Parserbalanza.Mensajes) ;

// Sumar errores.Errores totales := Errores totales

// ***** Opción: BALANZA POR DÍA

// Ecuación de tipo.TEQN_BalanzaDia := ' Inicial [' +•

•Sc_Ctas[' +'Sc_Pol_TO[Sc_Pol[' +'Sc_SA__TO[Sc_SA[ ' +'Sc_ValidaCtaPol[' +'Pc_BalDia(' +'Pc_SumaMovs_Tl[Pc_SumaMovs[ ' +'Pc_AgrSA_T2lPc_AgrSA(' +'Pt_AgrNom_T 0[Pt_AgrNom[' +•Final]]]

+ Parser balanza.Errores;

// Proceso de análisis.Parser balanza.TEQN := TEQN_BalanzaDia;Parser_balanza.Inicial izar;Parser__balanza.Analisis;Parser_balanza.Descripción,•CopyArraysInt¡NV^BalanzaDia, Parser_balanza.Num veces);CopyArraysStr(LU_B3lanzaDia, Parser_balanza.ListaUnicos);

// Acumular mensajes.royDBSystem.AddMsg('BALANZA POR DÍA1, Parser_balanza .Mensajes) ;

// Sumar errores.Errores_totales := Errores totales + Parser balanza.Errores;

// ***** Opción: ESTADO DE RESULTADOS

// Ecuación de tipo.TEQN_Estado := 'Inicial[' +

'Sc_Ctas[' +•Sc_PolJTO[Sc_Pol[' +'Sc_SA_TO[Sc_SA[' +•Sc_ValidaCtaPol[' +1Pc_SumaMovs_TO[Pc_SumaMovs[' +'Pc_AgrSA_TO[Pc_AgrSA[' +'Pc_Arbol[' +'Sc_Gpos_T0[Sc_Gpos[' +'Sc_Regs_T0[Sc_Regs(' +'Pc_Estado[' +'Sc_NomGpo[' +'Final] ]]]]]]]]]]]]!]]]} ';

// Proceso de análisis.Parser_mensuales.TEQN := TEQN Estado;

Parser_mensuales.Análisis;Parser_mensuales.Descripción;

CopyCopy

// AmyDB

// SErro

// *

// ETEQN

'S•S'S'S'P•P•P'S'S'P'S•F

// PParsParsParsParsCopyCopy

// AmyDB

// SErro

// *

// ETEQN

'S•S'S'S1P1P•P'S'S'P'F

// PParsParsParsParsCopyACopyA

// AcmyDBS

// SuError

// *

// EcTEQN_

'S'S'S'Sc'Pe'Pc'Pc'P'S' P'P'Pc1Sc1Sc1Pc•Fi

// PrParse

76

ArraysInt(NV Estado, Parser_mensuales.Num_veces);ArraysStr(LU_Estado, Parser_mensuales.ListaUnicos) ;

cumular mensajes.System.AddMsg ('ESTADO DE RESULTADOS', Par ser__mensual es .Mensa jes) ;

umar errores.res totales := Errores totales + Parser mensuales.Errores;

**** Opción: BALANCE GENERAL *****

cuación de tipo._Balance := 'Inicial[' +c_Ctas[' +c_Pol_TO[Sc_Pol[' +c_SA_TO[Sc_SA[' +c_ValidaCtaPol[' +c_SumaMovs_TO[Pc_SumaMovs[' +c_AgrSA_TO[Pc_AgrSA[' +c_Arbol[' +c_Gpos_Tl[Sc_Gpos[' +c_Regs_TlIScRegs[' +c_Balance[' +c_NomGpo[' +inal]]]]] ]]]]]]]]]]]]]';

roceso de análisis.er_mensuales.TEQN := TEQN_Balance;er_mensuales.Inicializar;er_mensuales.Análisis;er_mensuales.Descripción;ArraysInt(NV_Balance, Parser_mensuales-Num_veces);ArraysStr|LU_Balance, Parser_mensuales.ListaUnicos);

cumular mensajes.System.AddMsg{'BALANCE GENERAL", Parser_mensuales.Mensajes);

umar errores.res totales := Errores totales + Parser mensuales.Errores;

**** Opción: CIERRE MENSUAL *****

cuación de tipo._CierreMensual := 'Inicial[' +c_Ctas[' +c_Pol_TO[Sc_Pol[' +c_SAjrO[Sc_SA[' +c_ValidaCtaPol[' +c_SumaMovs_TO[Pc_SumaMovs[' +c~AgrSA_TOlPc_AgrSA[' +c_Arbol[l +c_Gpos_TO[Sc_Gpos[Sc_Gpos_Tl[Sc_Gpos('c_Regs_T0[Sc_Regs[Sc_Regs_Tl[Sc_Regs['c_CM(' +inal]]]]]]]]]]]]]]]]]]]]]';

roceso de análisis.er_mensuales.TEQN := TEQN_CierreMensual;er_mensuales.Inicializar;er_mensuales.Análisis;ermensuales.Descripción;rraysInt(NV_CierreMensualrraysStr(LU_CierreMensual

Par5er_mensuales.Nuro_veces);Parser mensuales,ListaUnicos);

umular mensajes.ystem.AddMsg('CIERRE MENSUAL', Parserjnensuales.Mensajes);

mar errores.es totales := Errores totales + Parser mensuales.Errores;

**** Opción: CIERRE DEL EJERCICIO ***

uación de tipo.CierreEjercicio := 'Inicialt' +c_Ctas[' +c_Pol_TO[Sc_Pol[" +c_SA_TO[Sc_SA[" +_ValidaCtaPol[' + SumaMovs_TO[Pc_SumaMovs[' +~AgrSAjroTpc_AgrSA(' +_Arbol[' +c_PolCierre[' +c_Pol_TO[Sc_Polf' +c_SumaMovs_TO [ Pc__SumaMovs [ ' +c_AgrSA_TO(Pc_AgrSA[' +_Arbol[* +_Gpos_TO(Sc_Gpos{Sc_Gpos_Tl[Sc_Gpos[_Regs_TO[Sc_Regs{Sc_Regs_Tl[Sc_Regs[_CM[' +nal]]]}]]]]]]]]]]]]]]]]]]

oceso de análisis.r_mensuale5.TEQN := TEQN CierreEjercicio;

Parser_mensuales.Inicializar;Parser_mensuales.Análisis;Parser_mensuales. Descripción;CopyArraysInt [NV CierreEjercicio, Parser_mensuales.Num_veces);CopyArraysStr (LU CierreEjercicio, Parser_mensuales.ListaUnicos);

// Acumular mensajes.myDBSystem.AddMsgt'CIERRE DEL EJERCICIO1, Parsermensuales.Mensajes);

// Sumar errores.Errores totales := Errores totales + Parser mensuales.Errores;

// Habilitar el botón de generación en caso de no encontrarse errores.if Errores_totales = 0 thenboton_Gen.Enabled := True;

end;

// Generación del código para cada opción. Se crean las unidades requeridas// para la ejecución de determinado proceso.procedure Tf_generador.boton_GenClick(Sender: TObject);begin

// Opción: SALDOSCopyArraysInt (myGenerator .Num_times, NV_Saldos) ;CopyArraysStr(myGenerator.onlyList, LU_Saldos);myGenerator.fixComponents(TEQN_Saldos, ' Saldos', ' A ' ) ;myGenerator.genérate('Saldos', 'A ' ) ;myGenerator.fixedFiles;

// Opción: ANALÍTICO NORMALCopyArraysInt(myGenerator.Num_times, NV_Analitico) ;CopyArraysStr(myGenerator.onlyList, LUAnalitico) ;myGenerator.fixComponents(TEQN_Analitico, 'Analitico', 'B_');myGenerator.genérate('Analítico', 'B_');myGenerator.fixedFiles;

// Opción: ANALÍTICO POR DÍA (la. Ecuación)CopyArraysInt (myGenerator .Num_times, NV_AnaliticoDia) ;CopyArraysStr{myGenerator.onlyList, LU_AnaliticoDia) ;myGenerator.fixComponents(TEQN_AnaliticoDia, 'AnaliticoDia', 'C_');myGenerator.genérate('AnaliticoDia', 'C_');myGenerator.fixedFiles;

// Opción: ANALÍTICO POR DÍA (2a. Ecuación)CopyArraysInt¡myGenerator.Num_times, NV AnaliticoDiaN) ;CopyArraysStr(myGenerator.onlyList, LU_AnaliticoDiaN) ;myGenerator.fixComponents(TEQN_AnaliticoDiaN, 'AnaliticoDiaN', 'D_');myGenerator.genérate('AnaliticoDiaN', 'D_');myGenerator.fixedFiles;

// Opción: AUXILIARES (Por cursores)CopyArraysInt(myGenerator.Num_times, NVAuxiliares) ;CopyArraysStr(myGenerator.onlyList, LU_Auxiliares) ;myGenerator.fixComponents{TEQN_Auxiliares, 'Auxiliares', '£_' );myGenerator.genérate('Auxiliares', •£_');myGenerator.fixedFiles;

// Opción: AUXILIARES CON CUENTAS SIN MOVIMIENTOCopyArraysInt (myGenerator .Num_times, NV_Auxiliares_CSM) ;CopyArraysStr (myGenerator .onlyList, LU_Auxiliares_C5M) ;myGenerator. f ixComponents (TEQN_Auxiliares_CSM, 'AuxiliaresCSM', 'F_'>;myGenerator.genérate('AuxiliaresCSM', 'F ') ;myGenerator.fixedFiles;

// Opción: AUXILIARES DE VARIOS PERIODOSCopyArraysInt(myGenerator.Num_times, NV_Auxiliares_VP) ;CopyArraysStr fmyGenerator.onlyList, LU_Auxiliares_VF) ;myGenerator.fixComponents (TEQN_Auxiliares_VP, 'AuxiliaresVP', 'G_');myGenerator.genérate(' AuxiliaresVP', ' G ' ) ;myGenerator.fixedFiles;

// Opción: BALANZACopyArraysInt(myGenerator.Num_times, NV_Balanza) ;CopyArraysStr¡myGenerator.onlyList, LU Balanza);myGenerator.fixComponents(TEQN_Balanza, 'Balanza', 'H_');myGenerator.genérate('Balanza', 'H_');myGenerator.fixedFiles;

// Opción: BALANZA POR DÍACopyArraysInt(myGenerator.Num_times, NV BalanzaDia) ;CopyArraysStr(myGenerator.onlyList, LU BalanzaDia) ;myGenerator.fixComponents(TEQN_BalanzaDia, 'BalanzaDia', "I ' ) ;myGenerator.genérate('BalanzaDia', 'I ' ) ;myGenerator.fixedFiles;

// Opción: ESTADO DE RESULTADOSCopyArraysInt(myGenerator.Num_times, NV_Estado) ;CopyArraysStr(myGenerator.onlyList, LU_Estado) ;myGenerator.fixComponents(TEQM Estado, 'Estado', 'J ') ;myGenerator.genérate ('Estado', 'J_');myGenerator.fixedFiles;

Jl Opción: BALANCE GENERALCopyArraysInt(myGenerator.Num times, NV Balance) ;

CopyAmyGenmyGenmyGen

// OpCopyACopyAmyGenmyGenmyGen

// OpCopyACopyAmyGenmyGenmyGen

// OpCopyACopyAmyGenmyGenmyGen

// AlOptio

ShowMend;

// Al c// del procedu

var Abegin

// DedmTab

end;

// Inic// al uprocedubegin

// ChecbCatcbGrucbGrucbPol

cbMaycbEdocbBalcbMencbEje

cbSalcbAuxcbAuxCcbAuxVcbBzaPcbPorDcbAnacbAnaDcbRel cbSIF?

nd;

// Selec/ dest•rocedubegin

// InInitOp

if cbTcbSacbAncbAucbAucbBz

end;

if cbTcbSacbAncbAucbBz

end;

if cbTcbSacbAncbAu

77

rraysStr(myGenerator.onlyList, LU_Balance);erator.fixComponents(TEQN Balance, 'Balance', 'K_*);erator.genérate('Balance', 'K_');erator.fixedFiles;

ción: CIERRE MENSUALrraysInt(myGenerator.Num_times, NV_CierreMensual);rraysStr(myGenerator.onlyList, LU_CierreMensual);erator.fixComponents(TEQN_CierreMensual, 'CierreMensual', 'L_');erator.generate('CierreMensual', 'L_');erator.fixedFiles;

ción: CIERRE DEL EJERCICIOrraysInt(myGenerator.Num^times, NV_CierreEjercicio);rraysStr(myGenerator.onlyList, LU_CierreEjercicio);erator.fixComponents¡TEQN_CierreEjercicio, 'CierreEjercicio', 'M_erator.genérate('CierreEjercicio', 'M_');erator.fixedFiles;

ción: MayorrraysInt {myGenerator.Num_times, NV__Mayor) ;rraysStr(myGenerator.onlyList, LU_Mayor);erator.fixComponents(TEQN_Mayor, 'Mayor', 'N_');erator.genérate{'Mayor', 'N_');erator.fixedFiles;

macenar opciones elegidas en un archivo texto.nsFile;

essage('Ok.');

errar la forma se desactiva la tabla que contiene las descripcionesanálisis.re Tf_generador.FormClose{Sender: TObject;ction: TCloseAction);

sactivar temporal.las-Tempo.Active := False;

ialización de check boxes que indican si la opción estará disponiblesuario en el sistema de contabilidad,re Tf_generador.InitOptions;

ck boxes.alogo.Checked := TrueposReglasER.Checked := TrueposReglasBG.Checked := Trueizas.Checked := True

or.CheckedBesult.CheckedGral.Checkedsual.Checkedrcicio.Checked

dos.CheckedNormal.CheckedSM.CheckedP.Checkedrevia.Checkedia.CheckedNormal.Checkedia.CheckedResp.CheckedChecked

:= True;:= True;:= True;:= True;:= True;

:= False:= False:= False:= False:= False:= False:= False:= False:= False:= False

ción de opciones de acuerdo al tipo Unión de crédito al que seráinado el Sistema de contabilidad,re Tf_generador-cbTipoChange(Sender: TObject);

icialización.tions;

ipo.Text = 'Comercial' then beginldos.Checked := True;aNormal.Checked := True;xNormal.Checked := True;xCSM.Checked := True;aPrevia.Checked := True;

ipo.Text = 'Industrial' then beginldos.Checked := True;aNormal.Checked := True;xNormal.Checked := True;aPrevia.Checked := True;

ipo.Text = 'Agropecuaria' then beginldos.Checked := True;aDia.Checked := True;xNormal.Checked := True;

cbAuxVP.CheckedcbPorDia.Checked

end;

:= True;:= True;

// Almacenar opciones elegidas en un archivo texto.OptionsFile;

end;

// Salida al archivo texto de las opciones.procedure Tf_generador.OptionsBoolean(strOpt: String; flag: Boolean);begin

writeln(F, strOpt);if flag thenwriteln(F, 'True')

elsewriteln|F, 'False');

end;

// Almacenar las opciones elegidas en un archivo, que será utilizado por// el sistema de contabilidad para determinar las opciones disponibles,procedure Tf_generador.OptionsFile;begin

// Subdirectorio destino del archivo.Path := *C:\AleaJE\Comps_Proy\';

AssignFile(F,Path + 'Options.txt1);Rewrite(F) ;

// Opciones fijas.OptionsBoolean('Catalogo', cbCatalogo.Checked);OptionsBoolean('ER_Grupos', cbGruposReglasER.Checked);OptionsBoolean('ER Reglas', cbGruposReglasER.Checked);OptionsBoolean('BG^Grupos', cbGruposReglasBG.Checked);OptionsBoolean('BG_Reglas', cbGruposReglasBG.Checked);OptionsBoolean('AltaPolizas', cbPolizas.Checked);

OptionsBoolean('Mayor', cbMayor.Checked);OptionsBoolean('EdoResultados', cbEdoResult.Checked);OptionsBoolean('BalanceGeneral', cbBalGral.Checked);OptionsBoolean('Mensual', cbMensual.Checked);OptionsBoolean('Ejercicio', cbEjercicio.Checked);

// Opciones variables.OptionsBoolean('Saldos', cbSaldos.Checked);OptionsBoolean í'Normal', cbAuxNormal.Checked);OptionsBoolean('CtasSinMov', cbAuxCSM.Checked);OptionsBoolean('VariosPeriodos', cbAuxVP.Checked);OptionsBoolean('Previa', cbBzaPrevia.Checked);OptionsBoolean('PorDia', cbPorDia.Checked);OptionsBoolean('Ana_Cuentas', cbAnaNormal.Checked);OptionsBoolean ('Ana__x_Dia *, cbAnaDia .Checked);

CloseFile(F);end;

Código de DeMipos.i Unidad que define elementos globales para las unidades de: análisisD

(Parser) , generación de código (mgGenerador) , y principal (a__generador) .í

unit Def^tipos;

interface

type// Definiciones de arreglos.TArrayl = array [1..30] of Integer;TArrayS = array [1..30] of String;TMatrixS = array í1..30, 1..4] of String;

const// Máximo de componentes; debe corresponder a la cantidad de elementos// definidos en los arreglos (1..30).Global_Max comps = 30;// Máximo de variantes en un nivel; debe corresponder a la cantidad// de elementos definidos en las matrices {1..4).

Global Max opcs - 4;

implementation

end.

CódUnid

Sist

comp

los códi

unit m

interf

uses W

typeTmgGen

toktotokonlNum

Cou

publicfuncprocprocprocprocprocfuncproc

end;

implem

// Obtfunctivar ip

chbegin

iposlen ch whil

inch

end;Resuteqn

end;

// Conprocedvar tebegin

teqntokewhil

toif

enend;

end;

// Inicomponprocedvar inbegin

for Co

end;

/ Gen// que// el / El

sistem// de corres// a ufunctivar ge

inbegin

// B// c

78

igo de mgGenerator.ad que contiene la clase que genera el código para la creación de

emas de contabilidad. Los sistemas son generados por medio de

onentes definidos por el programador, que formaran el código de

procesos, y las interfaces al usuario, las cuales hacen uso delgo generado, por medio de llamadas a los procedimientos iniciales.

gGenerator;

ace

indows, SysUtils, Def_tipos;

erator ~ classenList : TArrayS; // Lista de tokens [componentes).kenCount: Integer; // Contador.en : String; // Token.yList : TArrayS; // Lista de componentes diferentes.—times : TArrayl; // Lista del número de veces que se presenta un

// componentes.nt : TArrayl; // Lista temporal utilizada para operaciones de

// conteo con los componentes.

tion nextToken(var teqn: String): String;edure buildTokenList(strTEQN: String);edure genérate(ñame, id: String);edure fixComponents (strTEQN, ñame, id: String);edure fixedFiles;edure InitCount;tion New_id(original_id, token: String): String;edure newTokenList(id: String);

entation

iene los tokens de la ecuación de tipo.on TmgGenerator.nextToken(var teqn: String): String;os, len: Integer;: Char;

:= 1;:= Length(teqn);:= teqn[ipos];

e ( (cho' [ *) and (ch<>' ] ') and (ch<>', ') and (ipos<len) ) do beginc(ipos); := teqn[ipos];

lt := Copy(teqn,1,ipos-1); := Copy(teqn,ipos+1,len);

vierte la ecuación de tipo en una lista de componentes.ure TmgGenerator.buildTokenList(strTEQN: String);qn: String;

:= strTEQN;nCount := 0;e Length(teqn) > 0 do beginken :~ nextToken(teqn); Length(token) > 0 then beginInc(tokenCount);tokenList[tokenCount] := token;d;

cializar el arreglo utilizado para contar la presencia deentes.ure TmgGenerator.InitCount;di: Integer;

indl:=Low(tokenList) to High(tokenList) dount[indi] := 0;

eración de un nuevo string identificador del componente, en caso de exista repeticiones del componente, de lo contrario se mantieneidentificador del componente.identificador es un string único diferente para cada opción delacontabilidad generada, que identifica los componentes quepondenna opción.on TmgGenerator.New_id(original^id, token: String): String;nerated_id: String;d, pos: Integer;

uscar la posición del token en onlyList, y de esta formaonocer el número de veces que fue colocado.

pos := 0;for ind:=l to tokenCount do beginif token = onlyList[ind] then beginpos := ind;Break;

end;end;

// Inicializar generated_id (resultado).generated_id := original_id;

// Incrementar el número de veces que es utilizado el componente.Inc(Count[pos]);// Definir un nuevo id en caso de existir repeticiones de un componente.if Count[pos] < Num_timesipos] then begin

generated_id := generated_id + IntToStr(Count[pos]) + *_/;end;

Result := generated_id;end;

// Generación de una nueva lista de componentes con su identificación,// para tener una lista en donde todos los nombres de los componentes// sean diferentes, sin modificar su código interno,procedure TmgGenerator.newTokenList(id: String);var temp_tokenList: TArrayS;

i: Integer;begin

// Inicializar.for i:=Low(tokenList) to High(tokenList) dotemp_tokenList[i] := '*;

// Generar el nuevo identificador.for i:=l to tokenCount dotemp_tokenList[i] :- New_id(id, tokenList[i]) + tokenList[i];

// Copiar la nueva lista.for i:=Low(tokenList) to High(tokenList) dotokenList[i] := temp_tokenList[i];

end;

// Genera la unidad que define los componentes involucrados en la ejecución// de un proceso; crea los objetos-componentes y sus interrelaciones// (establece las referencias entre los objetos) por niveles.// La unidad generada será definida como clase matriz,procedure TmgGenerator.genérate(ñame, id: String);var path: String;

F: TextFile;i: Integer;

begin// Subdirectorio de la opción.path := 'C:\AleaJE\GeneradosV;

// Inicializar el arreglo contador de componentes.InitCount;

// Asignación de identificares a los componentes de la lista.newTokenList(id);

'Gen.pas');

'Gen;');

AssignFile(F,path + ñRewrite(F);writeln(F,TUnit * + ñwriteln(F);writeln(F,'Ínterface*);writeln(F);write(F,'uses ' ) ;for i:=l to tokenCount-1 dowrite(F, tokenList[i] + ',' + #13#10 +

writeln(F, tokenList[tokenCount1 + ' ; ' ) ;writeln(F);writeln(F,'type');writeln(F,rT' + ñame + 'Gen = class1);for i:=l to tokenCount dowriteln(F,* ' + tokenList[i] + '1 : T

writeln(F,' constructor Créate;');writeln(F,' destructor Destroy; override;T);writeln(F,' procedure genérate;');writeln(F,'end;T);writeln(F);writeln(F,'var Obj_' + ñamewriteln(F); ~writeln(F,'implementation');writeln(F);writeln(F,'constructor T' + ñamewriteln(F,'begin');writeln(F, * inherited Créate;');writeln(F,* ' + tokenList[tokenCount]

tokenList[tokenCount] + *.Créate;*);for i := tokenCount-1 downto 1 do beginwrite(F,* ' + tokenList[i] + *1 := Twriteln(F, tokenList[i+1] + T1);M;

end;writeln(F,'end; ' ) ;writeln(F);writeln(F,'destructor T* + ñame t 'Gen.Destroy;'writeln(F,'begin');

tokenLis t [ i ]

*: T* + ñame + 'Gen;*);

*Gen.Créate; ' ) ;

'1 := T'

tokenLis t [ i ] + ' . C r e a t e ( '

for iwri

end;writewritewritewritewritewritewritewritewriteClose

end;

/ Gene/ de u/ que/ defi/ dent// Los// dond// subd/ iden

proceduvar tem

itoinpinPlingen

begin// Infor itemnew

end;

// Habuild

// InInitC

// Co// lafor item

// AsnewTo

// Cofor inew

// Refor itok

// InInitC

// RuinPatoutPa

for i

// gen

AssResAssRewReawhi

il//w

compone

79

:= tokenCount downto 1 do beginteln(F,' ' + tokenListfi] + 'l.Free;');

ln(F, ' inherited Destroy; ') ;ln(F,'end;');ln(F);ln(F,'procedure T1 + ñame + 'Gen.genérate;');ln(F,'begin;'¡;ln(F,' ' + tokenList[l] + 'l.ProcesoS;');ln(F,'end;');ln(F);ln(F,'end.*);File(F);

ra unidades consideradas como componentes de la aplicación; toman subdirectorio {..\C0mp0nente3) archivos texto (unidades plantilla) contienen la estructura de un archivo Unidad de Delphi, con lanición de la clase-componente y los métodos que serán ejecutadosro de una serie de etapas de ejecución. archivos texto son leídos carácter por carácter para identificare colocar en una nueva unidad generada (almacenada en elirectorio . AGenerados), los nombres de la unidad y clase, eltificador para toda la unidad, y las referencia a la clase matriz.re TmgGenerator.fixComponents(strTEQN, ñame, id: String);p_tokenList, new_tokenList: TArrayS;ken, ipos, len: Integer;ut, output: TextFile;ath, outPath: String;e: String;erated_id: String;

icializar arreglos temporales.pos:=Low(tokenList) to High(tokenList) do beginp_tokenList[ipos] := '';_tokenList[ipos] := '';

cer lista.TokenList(strTEQN);

icíalizar el arreglo contador de componentes.ount;

piar la lista de tokens a una lista temporal (temp_tokenList); lista de tokens será modificada,pos:=Low(tokenLi st) to High(tokenLi st) dop_tokenList[ipos] := tokenList[ipos];

ignación de identificares a los componentes de la lista tokenList.kenList(id);

piar la nueva lista de tokens a new_tokenList.pos:=Low(tokenList) to High(tokenList) do_tokenList[ipos] := tokenList[ipos];

gresar los valores anteriores de la lista de tokens.pos:=Low(tokenList) to High(tokenList) doenList[ipos] := temp_tokenList[ipos];

icializar el arreglo contador de componentes.ount;

tas.h := 'C:\AleaJE\Componentes\';th := 'C:\AleaJE\Generados\*;

token:=l to tokenCount do begin

Generar el nuevo identificador.erated_id := New_id(id, tokenList[itoken]);

ignFile(input, inPath + tokenList[itoken] + *.pas');et(input);ignFile(output, outPath + new_tokenList[itoken] + '.pas');ritefoutput);dln(input, line);le not EOF(input) do beginpos := 1;en := Length(line);/ Ciclo para localizar donde serán realizadas las modificaciones a/ la unidad plantilla,hile ipos <= len do beginif line[ipos] = *%* then beginif line[ipos+l] = '%' then begin

ipos := ipos + 2 ; //Skip over tag '%%'while line[ipos] O '%' do

Inc(ipos);Inc(ipos);write (output, new^jtokenList [itoken+1 ]); // Nombre del

nteend; // del siguiente nivel.

endelse begin

if line[ipos] = '$' then begin

if line[ipos+1) = '$' then beginipos := ipos + 2; //Skip over tag 'Swhile line[ipos] o 'S' do

Inc(ipos);Inc(ipos);write (output, generated_id);

end;endelse begin

if line(ipos) = '!' then beginif line[ipos*l] = '!' then begin

ipos := ipos +• 2; //Skip over tagwhile linefipos] <> '!' do

Inc(iposJ ;Inc(ipos);write(output, narae);

end;endelse

write{output, line(ipos]);end;

end;

Inc(ipos);end;writeln(output);readln(input, line);

end;CióseFile(input);CloseFile(output);

end;end;

// Identificador de la// unidad.

// Referencia// matriz.

// Escritura sin// modificaciones.

// Copia// aplicprocedurvar R F,

flagbegin

// DefR_F :

fTag

r una unidad donde se defininen variables globales a toda laación generada (Sistema de contabilidad).e TmgGenerator.fixedFiles;R_D: String;Boolean;

inición de rutas.: 'C:\AleaJE\Componentes\';= 'C:\AleaJE\Comps_Proy\';- Faise;

// Ruta Fuente.// Ruta Destino.

CopyFile(PChar(R_Fend;

'Globales.pas1), PChar(R_D + 'Globales.pas' flag};

Código de Parser.{ Unidad que define la super-clase TParser, contiene los métodos para•

obtener una lista de tokens y realizar el análisis sintáctico de laecuación de tipo (cadena de componentes), dando como resultadodescripciones textuales de la función de cada componente o los erroresque se encuentren.}

unit Parser;

uses Def_tipos;

typeTParser = class

TEQN : String; // Ecuación de tipo.Num_tokens : Integer; // Número de tokens.Mensajes : String; // Mensajes: errores o descripciones.Errores : Integer; // Número de errores.Max_comps : Integer; // Máximo de componentes; debe corresponder

// a la cantidad de elementos definidos en// los arreglos.

Max__opcs : Integer; // Máximo de variantes en un nivel; debe// corresponder a la cantidad de elementos// definidos en las matrices.// Lista de componentes. (TEQN)// Lista de componentes. (Parser)// Lista de componentes. (Sin repeticiones)// Máximo número de repeticiones// por componente.

Num_veces : TArrayl; // Número de repeticiones// encontradas por componente.

// Componentes que puede requirir un Nivel; sólo es necesario uno// [Componentel 6 Componente2 ó Componente3 ó Componente4J.Requiere : TMatrixS;

constructor Créate;function SiguienteToken(var teqn: String): String;procedure InicializarLista(teqn: String);procedure Análisis;

end;

ListaTokens: TArrayS;Componente : TArrayS;ListaUnicos: TArrayS;Max_veces : TArrayl;

impleme

// Al cconstrubegin

Num_tMensaErrorMax_cMax o

end;

// Obtifunctiovar ipo

ch:begin

ipos len :ch :=while

incch

end;Resulteqn

nd;

// La e// o arproceduvar tokbeginNum_t

whiletok

if IL

endend;

end;

// Real// los funcion// y la// resuproceduvar num

Rec

poscoltok

token.VeriDis

diferenbegin

// Infor iRec

// ConErrore// TeMensaj

// In

for i:// C// Reco

// B// pposifor

if

enend;

if p////Me

Inend

80

ntot ícr.

rear un parser se inicializan también las varlab Les.ctor TParser.Créate;

okensjesesompspcs

: = 0;:- '';:= 0;:= Global_Max_comps;:= Global_Max_opcs;

ene cada token (componente) de la ecuación de tipo,n TParser.SiguienteToken(var teqn: String): String;s, len: Integer; Char;

:= 1;= Lengthiteqn); teqn[ipos] ; ( (cho1 [') and fcho' ] ') and ícho', ') and (ipos<lenl ) do begin(ipos);:- teqn(ipos];

t := Copy(teqn,1,ipos-1);:= Copy(teqn,ipos+1,len);

cuación de tipo es fragmentada en tokens, que formarán una listareglo de tokens (componentes).re TParser.InicializarLista(teqn: String);en: String;

okens := 0;

Length(teqn) > 0 do beginen := SiguienteToken(teqn);

Lengthftoken) > 0 then beginnc(Num_tokens);istaTokens[Num^tokensI := token;;

iza el análisis sintáctico; determinando si es correcto el orden decomponentes, los componentes necesarios para el adecuadoamiento,s veces que pueden colocarse, proporciona en forma textual losltados: errores y descripciones.re TParser.Análisis;_vacios, repeticiones: Integer; // Contadores.orridos: TArrayS; // Arreglo que contiene que componente ya

// fue analizado.// índices.// Para saber si un nivel ya fue colocado.//Almacena temporalmente el valor de un

// Componente veri ficado.// índice - contador de componentes

ición, i, j, k: Integerocado: Boolean;en_aux¡String;

ficado: Boolean;tintos: Integer;tes.

icialización de variables,:«l to Max^comps doorridos[i] := ' ';tador de errores.s :* 0;xto para mensajes.es := '';

icia análisis.

=l to Num__tokens do beginolocar en la lista Recorridos los componentes que ya han sidoanalizados.rridos[iJ := ListaTokens(i];

uscar la posición del token en la lista Componentes;ara poder hacer referencia con la matriz Requiere,ción := 0;j:=l to Max_comps do begin ListaTokens[i] = ComponenteJj] then beginposición :- j;break;d;

osición = 0 then begin Cuando el componente no existe dentro de los posibles, hacer su mensaje de error.nsajes := Mensajes +'Error: El componente ' + ListaTokens[i] + ' no está ' +'incorporado a la lista de componentes posibles para ' +1 la construcción de esta opción. ';c(Errores);

else begin// Variable tipo Contador, para identificar si el nivel no requiere// de otros niveles.num_vacios := 0;// Variable bandera, para conocer si el nivel requerido fue colocado.colocado := False;

// Verificar los componentes requeridos,for j:=1 to Max_opcs do begin// Recorrer el reglón (definido por posícion] de la matriz

Requiere,// cada columna (definida por j) determina el nivel que requiere,if Requiere[posición,j] <> ' ' then begin

for k; = 1 to i do begin// En la lista de Recorridos se averigua si el nivel// requerido (Requiere(posición,j]) fue colocado.if Requiere[posición,j] = Recorridos[k] then begin

// Se encuentra colocado eL nivel requerido.colocado := True;

end;end;

endelse begin

Inc(num_vacios); // Si en la columna de la matriz Requiereend; // no existe componente, es decir está vacia,

end; // incrementa el contador 'num_vacios'.// Cuando en esta posición (renglón de la// matriz) todas las columnas están vacias,// el componente no requiere de otros.

if num_vacios - Max_opcs then// Significa que el componente no requiere de otros para su

utilización.colocado := True;

if colocado = False then begin// Al no encontrarse el nivel requerido hacer el mensaje de error.Mensajes : - Mensajes + 'Error: ' +

Componente[posición] + ' requiere uno de los siguientes niveles:

for j:=1 to Max^opcs do beginif Requiere[posición,j] <> ' ' thenMensajes := Mensajes + Requiere [posición, j ] +• ' ' ;

end;Mensajes := Mensajes +

'para la construcción de esta opción. ';Inc(Errores);

end;end;

end;

// Inicializar contador.Distintos := 0;// Verificar el número de veces que se coloca un componente,for i:=l to Num_tokens do begintoken__aux : = ListaTokens [ i ];

// Comprobar que el componente no haya sido ya verificado.Verificado :- False;if i > 1 then begin

for j:=i-l downto 1 do beginif token_aux = ListaTokens[j) then beginVerificado := True;Break;

end;end;

end;

if not Verificado then begin// Contar el número de repeticiones del componente.repeticiones := 0;for j:=l to Num_tokens do begin

if token_aux =* ListaTokens [j ] then beginInc(repeticiones);

end;end;

// Buscar la posición del token en la lista Componentes.posición := 0;for j:=l to Max_comps do begin

if ListaTokens[i] = Componente[j] then beginposición :- j;break;

end;end;

if posición o 0 then begin// En caso de encontrarse el componente colocado, verificar si es// válido el número de veces que fue colocado.if repeticiones > Max_veces[posición] then begin

// Si excede el número de veces permitido, hacer el mensaje de:ror.

Mensajes := Mensajes > 'Error: ' + Componente[posicion] +' excede el número de veces que puede colocarse. ';

Inc(Errores);

enend;

end;

end.

Cód{ Defig

de Tsintcompcomp

unit P

interf

uses P

typeTPar

coprpr

end;

implem

constrbegin

inherend;

// Ini// de proceduvar i, begin

// Ifor ComLiLiMaxNumforR

end;

// Cr// vaInici

// De// Co// ge// Re// Co

Compo

CompoReq

CompoReq

CompoReq

CompoReq

CompoReq

CompoReq

CompoReq

81

end;// Guardar el número de veces que se encuentra el componente,// se ut11 izara en el momento de generación del código;// un componente se debe generar su número de veces definido.Inc(Distintos);Num_veces[Distintos] := repeticiones;// Guardar el componente en la lista de no repetidos.ListaUnicos[Distintos] :~ Componente[posición];

end;d; // if not Verificado,

igo de P_Balanzas.ne la clase TParser_balanza la cual hereda los métodos y propiedades

Parser, el propósito es agregar los métodos que definen las reglasácticas, cantidad de repeticiones, y descripciones textuales;letan el Parser para las opciones del Grupo Balanza: Balanza derobación normal y Balanza de comprobación por dia. }

_balanzas;

ace

arser;

ser_balanza = class(TParser)nstructor Créate;ocedure Inicializar;ocedure Descripción;

entation

uctor TParser_balanza.Créate;

ited Créate;

cializa las variables utilizadas para el análisis, carga las reglascontrucción de componentes y la cantidad de repeticiones.re TParser_balanza.Inicializar;j: Integer;

nicialización,i:=l to Max_comps do beginponente(i] := ' ';staTokens[i] :3 '';staUnicos[i] := '';_veces[i] := 0;_veces[i] := 0; j:=1 to Max_opcs doequiere(i,j] :~ ' ';

ea una lista de tokens (componentes) que se utilizarán paralidar la ecuación de tipo.alizarLista(TEQN);

finición de restricciones. (Regias de construcción).mponentes representa los componentes involucrados en laneración de la opción.quiere representa alguno de los componentes que requieremponente.

nente[1] := 'Inicial';

nente[2] := 'Sc_Ctas';uiere[2,1] := 'Inicial';

nente[3] := 'Sc_Pol_T0';uiere(3,1] := 'Sc_Ctas';

nente[4] := 'Sc_Pol';uiere[4,1] := 'Sc_Pol_T0';

nente[5] := 'Sc_SA_T0';uiere[5,1! := 'Sc_Pol';

nente[6] := 'Sc_SA';uiere[6,1] := 'Sc_SAJT0';

nente[7] := 'Sc_ValidaCtaPol';uieren, 11 := 'Sc_SA' ;

nente[8] ;= 'Pc_BalDia';uiere(8,lj := 'Sc_ValidaCtaPol';

Componente[9] :=Requiere[9,1] :»Requiere[9,2] :=

Componente[10] :-Requiere[10,1] :=

Componente[11} :=Requiere[11,1] :=

Componente[12] :=Requiere[12,1] :=

Componente[13] :=Requiere[13,1] :=

Componente[14 J : =Requiere[14,1] :=

Componente[15] :=Requiere[15,1] :=

1Pc_SumaMovs_Tl';'5c_ValidaCtaPol''Pc_BalDia';

' Pc__5umaMovs' ;'Pc_SumaMovs_Tl'

•Pc_AgrSA_T2';1Pc_SumaMovs';

'Pc_AgrSA';'Pc_AgrSA_T2';

'Pt_AgrNom_TO';'Pc_AgrSA';

'Pt_AgrNom';'Pt_AgrNom_TO';

'Final';'Pt_AgrNom';

// Número de ocasiones que puede repetirse el componente dentro// de todo el proceso.Max_veces[U := 1; // InicialMax^veces[2) := 1; // Sc_CtasMax_veces[3] : = 1; // Sc_Pol_T0Max veces[4] := 1; // Sc_PolMax'veces[5] := 1; // Sc_5A_T0Max_veces[6] : = 1; // Sc_SAMax_veces[7] := 1; // Sc_ValidaCtaPolMax^veces[8] := 1; // Pc_BaiDÍaMax veces[9] := 1; // Pc_SumaMovs_TlMax_veces[10] := 1; // Pc_SumaMovsMax_veces[ll] := 1; // Pc_AgrSA_T2Max_veces[12] := 1; // Pc_AgrSAMax^veces[13) := 1; // Pt_AgrNom_T0Max_veces[14} := 1; // Pt_AgrNomMax_veces[15] := 1; // Final

end;

// Carga la descripción de cada componente; contiene su función, categoría// y requerimientos.procedure TParser_balanza.descripción;var Texto: String;

i: Integer;begin

if Errores = 0 then beginMensajes := 'Ecuación de tipo: ' + TEQN + ' ' +• tH3#10#13(H0 +

'Descripción de cada componente: ';for i:=1 to Num_tokens do beginTexto :- ' ';"if ListaTokensti] - 'Inicial' then Texto := *13IUOH13#1O +'Inicial: Define las llamadas principales, siempre está al inicio '

'de los niveles. ';

if ListaTokensti] =• 'Sc_Ctas' then Texto := #13H10tt 13M10 +'Sc_Ctas: Selecciona el catálogo de cuentas; pertenece a la ' *'categoría Selección_de_información, por lo que se coloca antes ' >•'de los componentes que ejecutan operaciones con la información; ' +'la posición entre componentes de esta categoría, no importa. ' +'Requiere de Inicial, para efectos de mantener una secuencia ' +'de ejecuciones. ';

if ListaTokensti] = 'Sc_Pol_T0' then Texto := #13(H0#13(H0 *'Sc_Pol_T0: Hace la llamada de ejecución a Sc_Pol, con ' *'sus correspondientes parámetros; pertenece a la categoría Llamadas

'por lo que siempre va acompañado de un componente parametrizado; '

'su posición es anterior al componente parametrizado. ' +'Requiere de Sc_Ctas, para efectos de mantener una secuencia ' -t-'de ejecuciones. ';

if ListaTokensti] * 'Sc_Pol' then Texto := #13#10#13(H0 +•Sc_Pol: Selecciona las pólizas del periodo; pertenece a la ' <•'categoría Selección_de_información, por lo que se coloca antes ' +'de los componentes que ejecutan operaciones con la información; ' +'la posición entre componentes de esta categoría, no importa. ' +'Requiere del componente que contenga la llamada con los parámetros

'adecuados, para ejecutarlo. ';if ListaTokensti] = 'Sc_SA_T0' thenTexto := #13H0#13#10 +'Sc_SA_T0: Hace la llamada de ejecución a ' +'Sc_SA, con sus correspondientes parámetros; ' +'pertenece a la categoría Llamadas por lo que siempre va acompañado

1 +

'de un componente parametrizado; su posición es anterior al ' +'componente parametrizado. • +'Requiere de Sc_Pol, para efectos de mantener una secuencia ' +'de ejecuciones. ';

if ListaTokens [il - *Sc_SA' then Texto := #13#lO»13ftiO +'Sc_SA: Selecciona los saldos anteriores; pertenece ' +

'a

'd1 l'R

'aif 'S'p'V

+'o'R's

if 'P'b

'h's

1 f'l

1 e'S'R's

if Te'P' 'p

+'d'c'R'd

if 'P'p

'c'R

+

'aif Te1P' P'p

'd'c'R's

if Te'P'c'c'c'R

'a

if 'P'P'la'c'p'e

if L'P'ta'c

'la'Re

+'ad

if L'Fi'de

Mensend;

end;•nd;

•nd.

82

la categoria Selección_de_información, por lo que :oloca

e los componentes que ejecutan operaciones con la información; ' +a posición entre componentes de esta categor ia, no importa. ' +equiere de 1 componente que contenga la llamada con Los parámetros

decuados, para ejecutarlo. ';ListaTckensIi) = ' Sc_VaiidaCtaPol' then Texto := #13#I0(H3tH0 *•c_ValidaCtaPol: Comprueba que exista la suficiente información ' fara la ejecuc ion del proceso; pertenece a la categoría ' *•er Lf ica_informacion, por lo que se coloca antes del Inicio de las

peraciones con la información. ' +•equiere de 5c_SA, para efectos de mantener una ' +ecuencia de ejecuciones. ';

ListaTokensti] = 'Pc_BalDia' then Texto :=» #tL3#10ttl3#10 +•c_BalDia: Componente que tiene la función de obtener la ' +alanza de comprobación del día indicado por el usuario, para esto

ace de uso de componentes que se utilizan en la obtención de ' +aldos, tiene el control de llamadas para varios componentes, y al

inal determina que componente continuará con la secuencia de ' +lamadas verticales; pertenece a la categoria Balanzas, su posición

s después de la categoría Verifica_información o ' +elección_de_información. ' +equiere de Sc_ValidaCtaPol, para efectos de mantener una ' +ecuencia de ejecuciones. ';ListaTokens[i] = 'Pc_SumaMovs_Tl' thenxto := #13#10(H3(HO ••c_SumaMovs_Tl: Hace la llamada de ejecución a ' +Pc__SumaMovs, con sus correspondientes parámetros; ' *•ertenece a la categoría Llamadas por lo que siempre va acompañado

e un componente parametrizado; su posición es anterior al ' +omponente parametrizado. ' >equiere de 3c_VaiidaCtaPol o Pc_BalDia, para efectos ' *•e mantener una secuencia de ejecuciones. ';ListaTokensfi] = ' Pc__SumaMovs' then Texto := Hl3ltlOIU3tUO *•c_3umaMovs: Obtiene los saldos de las cuentas de detalle; ' >ertenece a la categoría Balanza_suma, su posición es después de la

ategoría Verifica_información o Selección_de_infoi:mación. ' +•equiere del componente que contenga la llamada con los parámetros

decuados, para ejecutarlo. ';ListaTokensti] = 'Pc_AgrSA_T2' thenxto := #13M0K13IU0 +c_AgrSA_T2: Hace la llamada de ejecución a ' +c_AgrSA con sus correspondientes parámetros; ' +•ertenece a la categoría Llamadas por lo que s iempre va acompañado

e un componente parametrizado; su posición es anterior al ' +omponente parametrizado. ' +equiere de Pc_SumaMovs, para efectos de mantener una ' *•ecuencia de ejecuciones. ';ListaTokensti] = 'Pc_AgrSA* thenxto := #13#10tH3(HO +c_AgrSA: Suma a los saldos actuales de las ' +uentas sus correspondientes saldos anteriores; pertenece a la ' +ategoria Balanza_anteriores; su posición es posterior a la ' *•ategoría Balanza_suma. ' +equiere del componente que contenga la llamada con los parámetros

decuados, para ejecutarlo. ';

ListaTokensti] =» ' Pt_AgrNom_T0' then Texto := fH3#10(H3K10 *•t_AgrNom_T0: Hace la llamada de ejecución a ' +t_AgrNom con sus correspondientes parámetros; pertenece a ' * categoria Llamadas por lo que siempre va acompañado de un ' >omponente parametrizado; su posición es anterior al componente ' +•arametrizado. Requiere de Pc_AgrSA, para ' +•fectos de mantener una secuencia de ejecuciones. ';istaTokensti] = 'Pt^AgrNom' then Texto := )U3JH0K13#lu *•t_AgrNom: Coloca el nombre de cada cuenta a una o var ias ' +blas que muestran la información al usuario; pertenece a la ' +ategoría Asignar_nombres_de_cuentas; su posición es posterior a '

s categorías de operaciones. ' +quiere del componente que contenga la llamada con los parámetros

ecuados, para ejecutarlo. ';

istaTokensti] = 'Final' then Texto := #13*10*13010 +nal: Define las variables globales, siempre está al final ' + los niveles. ';

ajes := Mensajes + Texto;

A.3 Componentes.

Código de Inicial.// Componente inicial para todas Las opciones a generar (ecuaciones detipo) .

unit S$idS$Inicial;

interface

typeT$$id$$Inicial = class

Super : T^SuperVft;constructor Create(var Superp : TV,Supert•);procedure ProcesoS;

end;

implementation

constructor T$$id$$Inicial .Créate (var Superp : T'MSuperV.begin

inherited Créate;Super := Superp;

end;

procedure T$$id$$Inicial.ProcesoS;begin

Super.ProcesoS;end;

end.

Código de Final.// Componente final para todas las opciones a generar (ecuaciones de tipo).// Inicializa variables globales,unit $Sid$$Final;

interface

typeTS$id$$Final = class

constructor Créate;procedure ProcesoS;

end;

implementation

uses Globales;

constructor TS$id$$Final.Créate;begin

G hay ctasG hay s antG hay pólizasG nivelG_fechalG_fechaFG fechal TempG fechaF TempG ctalG_CtaFG_hay_gruposG hay reglasGran Edo Res

end;

= False;=« False;= False;* 0;» 0;• 0;• 0;- 0;= '' ;= . i ;

• False;= False;=> 0;

procedure T$$id$$Final.ProcesosDeginG hay ctas

end;= False;

Código de Globales.// Unidad donde se declaran las variables globales,unit Globales;

interface // Sección (Public).

YearYearYearG_hG_hG hG nG_feG_feG_feG_feG_ctG_ctG_haG_haGran

implem

end.

Cód// Sel// Obtunit S

interf

uses V

typeT$$i

Incopr

end;

implem

uses U

constrbegin

inheInfe

end;

procedvar habegin

// Ihay_

// Bwith

//CiSQSQSQSQPaPa

//Op//if

end;

G_ha

Infeend;

/ódV Sum/ Tip/ Tip/ Tipnit S

83

_Act, Mes^Act: Word;__Ant, Mes^.^nt: Word;_Pos, Mes_Pos: Word;ay_ctas: Boolean;ay_s_ant: Boolean;ay^polizas: Boolean;ivel: Integer;chal: TDateTime;chaF: TDateTime;chaI_Temp: TDateTime;chaF_Temp: TDateTime;al: String;aF: String;y_grupos: Boolean;y_reglas: Boolean; Edo Res: Double;

entation // Sección (Private).

igo de Sc_Ctas.ecciona información de la base de datos.iene el catálogo de cuentas del periodo,5idSSSc_Ctas;

ace

AInfer*^;

d$$Sc_Ctas - classfer : T^Infer**;nstructor Créate (var Inferp : T'í> ̂ Infer *,'A) ;ocedure ProcesoS;

entation

nitDModuieC/ Globales;

uctor T$SidSSSc_Ctas .Créate (var Inferp : T'hMnfer'f't,) ;

rited Créate;r := Inferp;

ure T3Sid$SSc_Ctas.ProcesoS;y_ctas: Boolean;

nicializac variables.ctas := False;

uscar Catálogo de Cuentas. DModuleC.qryCuenta do beqin Construir la instrucción y pasarle los parámetros.óse;L.Clear;L.Addf'SELECT * FROM Cuenta ' ) ;L.Add('WHERE year_cta = :pyear AND mes_cta = :pmes ' ) ;L.AddCORDER BY cuenta_cta' ) ;ramByName('pyear').AsInteger := Year_Act;ramByName ('pmes') .AsInteger :=• Mes_Act;

Ejecución del query (Select).en; Si existe información, entonces ... not IsEmpty thenhay_ctas :- True;

y_ctas := hay^ctas;

r.ProcesoS;

igo de Pc_AgrSA.ar al saldo actual de las cuentas o grupos, su saldo anterior.o 0 : Para cuentas.o 1 : Para un rango de cuentas.o 2 : Para grupos.SidSSPc AgrSA;

typeTS3id$$Pc_Agr3A = class

Infer : TVUnfer**;Vertical: Boolean;

constructor Créate(var Inferp : TV4 Infer< K) ;procedure Procesos(tipo: Byte; hay_s_ant: Boolean; ctal, ctaF: String);procedure Pc_AgrSA{tipo: Byte; hay_s_ant: Boolean;

ctal, ctaF: String);end;

i mp1eme n t a t i o n

uses UnitDModuleC, Globales, !!gen!!Gen;

constructor T$$idSSPc_AgrSA.Create(var Inferp :

Té%Inter%%) ;begin

inherited Créate;Infer := Inferp;Vertical := True;

end;

procedure TS$id$$Pc_AgrSA.Procesos(tipo: Byte;

hay_s_ant: Boolean; ctal, ctaF: String};var xsal_ant, xsaldo_so: Double;

xcta_ant, xgrupo: String;grabar: Boolean;

begin

// Inicializar variables.xsal_ant := 0 ;xsaldo_so := 0;

if hay_s_ant then beginwith DModuleC.qrySal_ant do begin

First;

if tipo = 2 then begin

xgrupo := Copy ¡ FieldByName('Cta_dpol') .AsString, 1,4);

xsaldo_so :- 0;

end;

while not EOF do begin

if (tipo =• 0) or (tipo D 1) then beginxcta_ant := FieldByName( 1CUENTA_ANT t)-AsString;xsal_ant :=• FieldByName{'SALDO_ANT') .AsFloat;

end;

grabar :=* False;

if tipo * 2 then begin

if xgrupo = Copy(FieldByName('Cta_dpol') .AsString,1, 4) then beginxcta_ant := FieldByName('CUENTA_ANT').AsString; //xsal_ant :- FieldByName('SALDO_ANT*).AsFloat; //

xsaldo_so := xsaldo_so + xsal_ant;

end

else begin

xsal_ant := xsaldo_so;xcta_ant := xgrupo + '-00-00-00-00-0000';

grabar := True;end;

end;

if tipo - 0 then

grabar := True;

if tipo = 1 then

if (xcta_ant >= ctal) and (xcta^ant <- ctaF) thengrabar := True;

if grabar then begin

// Buscar en Rep_so.

with DModuleC.Rep_so do beginif Lócate('CUENTA_SO', xcta_ant, []) then begin

Edit;

FieldByName{'SAL_A_SO').AsFloat := xsal_ant;

xsaldo_so := FieldByName('SALD0_S0').AsFloat;

FieldByName('SALDO_SO*).AsFloat := xsal_ant + xsaldo so;Post;

endelse begin

Append;

FieldByName('CUENTA_SO').AsString := xcta_ant;

FieldByName('SAL_A_SO').AsFloat := xsal_ant;FieldByName{'SALDO_SO').AsFloat := xsal_ant;

FieldByNameCDEBE_SO').AsFloat := 0;

FieldByName('HABER_S0').AsFloat := 0;Post;

end;end;

e

end

if I

end;

proce

(tibegin

VerPro

Verend;

end.

Cód// Wr

/ Tiunit

inter

uses

typeT$$

Ic

pend

imple

uses

const•egininh

Infend;

•roce

iegin

Inf

end;

and.

84

if tipo = 2 then begin

xsa ido_so := 0;

xgrupo := Ccpy í xcta_ant, 1, -1) ;

end;

end;

Nex t ;

end;

if tipo = 2 then begin

// Almacenar el último grupo.

xsal_ant := xsaldo_so;xcta_ant : =« xgrupo + '-00-00-00-00-0000';

// Buscar en Rep_so.with DModuleC.Rep_so do begin

if Lócate ( 'CUENTA^SO', xcta__ant, [ji then begin

Edit;

FieldByName('SAL_A_SO').AsFloat := xsal_ant;

xsaldo_so := FieldByName('SALDO_SO').AsFloat;FieldByName('SALDO^SO').AsFloat :- xsal_ant + xsaldo_so;

Post;endelse begin

Append;FieldByName ('CUENTA_SO') .AsString : =» xcta_ant;

:= xsal_ant;

:= xsal^ant;:= 0;

:= 0;

FieldByName('SAL_A_SO').AsFloatFieldByName('SALDO^SO').AsFloatFieldByName('DEBE_SO').AsFloatFieldByNamet'HABER_SO').AsFloatPost;

end;end;

end; // De: tipo = 2

nd;

;

Vertical thennfer.Procesos;

dure TS$idS$Pc_AgrSA.Pc_AgrSA

po: Byte; hay_s_ant: Boolean; ctal, ctaF: String);

tical := False;cesos (tipo, hay_s_ant, ctal, cf.aF) ;

tical := True;

igo de Pc_AgrSA_T0.apper para el componente Pc_AgrSA.

po 0 : Para cuentas,$Sid$$Pc_AgrSAJT0;

face

V̂ Infer*,'*>;

idS$Pc_AgrSA_T0 = classnfer : TTmnfer'n;onstructor Créate (var Inferp r T'^InferV*);

rocedure Procesos;;

mentation

Globales;

ructor TS$idS5Pc_AgrSA_T0.Créate(var Inferp : TVAInferVM ;

erited Créate;

er := Inferp;

dure TSSid$$Pc_AgrSA_T0.ProcesoS;

er.Procesos(0, G_hay_s_ant, ' ', ' ' ) ;

Código de Pc_AgrSA_T1.// Wrapper para el componente Pc_AgrSA-// Tipo 1 : Para un rango de cuentas.unit $Sid$$Pc_AgrSAJTl;

interface

uses ífclnfers'S;

typeT$$id$$Pc__AgrSA_Tl = class

Infer : Tlllnferl%;constructor Créate(var Inferp : TV^ InferM) ;procedure Procesos jt

end;

implementation

uses Globales;

constructor T$$id$$Pc_AgrSA__Tl .Créate (var Inferp : T'UInferM);begin

inherited Créate;Infer := Inferp;

end;

procedure T$$id$SPc__AgrSA_Tl. ProcesoS;begin

Infer.Procesos(1, G_hay_s_ant, G_ctal, G_ctaF"¡;end;

end.

Resuend;

Código de Sc_NomCta.// Contiene una función que regresa el nombre de una cuenta.unit $$idSSSc_NomCta;

interface

uses %%Infer%%;

typeT$$id$$Sc_NomCta = class

Infer : T'UInferSS;constructor Créate(var Inferp : TU %Infer VA);procedure ProcesoS;funetion Sc_NomCta(cuenta: String): String;

end;

implementation

uses UnitDModuleC, Globales, !!gen!!Gen;

constructor TSSidSSSc_NomCta .Créate (var Inferp : T'AíInferM) ;begin

inherited Créate;Infer := Inferp;

end;

procedure TS$idSSSc_NomCta.ProcesoS;begin

Infer.ProcesoS;end;

function TS$idS$Sc_NomCta.Sc_NomCta(cuenta: String): String;var xnombre: String;begin

// Inicializa variable; en caso de no encontrarse// el nombre mostrar el nombre vacio.xnombre := '';

// Buscar el nombre de la cuenta,with DModuleC.seekCuenta do begin

// Construir la instrucción y pasarle los parámetros.Cióse;SQL.Clear;SQL.AddCSELECT * FROM Cuenta WHERE cuenta_cta = ¡accountSQL.AddCAND year_cta =• :pyear AND mes_cta = :pmes');ParamByName('account').AsString := cuenta;ParamByName('pyear').Aslnteger := Year_Act;ParamByName('pmes').Aslnteger := Mes_Act;

// Ejecución del query (Select).Open;// SI existe información, entonces ...if not IsEmpty thenxnombre := FieldByName('Nombre^cta1).AsString;

end;

85

lt := xnombre;

Apéndice B.

Planes de negocio.

En noviembre de 1998, el Fondo de Apoyo a la Innovación y el Desarrollo TecnológicoRÓMULO GARZA lanzó una convocatoria para participar en el concurso de proyectosoriginales, como propuesta de proyecto se presentó el establecimiento de una empresa productorade software basada en el modelo de líneas de productos.

La propuesta está conformada de un sumario, un plan de negocios y un plan técnico. Los planesmostrados describen un análisis desde el punto de vista de negocios para el establecimiento deuna empresa, así como el técnico para la elaboración de productos. La intención de los planes esrealizar un estudio de factibilidad de la empresa y de los productos.

La presente tesis fue elaborada a partir de esta propuesta, enfocándose principalmente en losaspectos técnicos involucrados en la implementación de una línea de productos.

86

B.l Sumario.

Empresa RapiSoftBasada en el Modelo de Líneas de Productos

Antecedentes.

Una de las características "normales" asociadas con la producción de software, es la grandificultad "inherente" en su desarrollo. La producción de software está caracterizada por unrezago en los tiempos de entrega de los productos, la poca fiabilidad de las soluciones propuestas,la falta de cumplimiento con lo que los usuarios solicitaron y el alto costo. A este estado de cosasse le ha dado en llamar la crisis del software.

Actualmente existen tres formas en que puede operar la producción de software: 1) una empresatiene un departamento de desarrollo para desarrollo "a la medida", 2) una empresa producesoftware "a la medida" para otra empresa cliente, y 3) una empresa produce paquetes (un mismoproducto con características que son útiles a una gran cantidad de usuarios).

Si bien la última forma de producción (3) es la que contribuye de manera más significativa adisminuir la crisis, solo es aplicable a situaciones particulares en las que las empresas puedenaprovechar un paquete. La mayoría de los procesos de información que son de vital importanciapara las empresas no son resueltos por los paquetes. De ahí que las empresas tiendan a seguirutilizando las otras dos formas de producción. En el caso de las empresas medianas y grandes,éstas tienen sus propios desarrolladores de software, pero las más pequeñas deben contratar eldesarrollo con empresas especializadas en desarrollo de software, resultando muy costoso para lapequeña empresa.

Combinar una estrategia que incorpore la producción a gran escala (varias aplicaciones) y queestas aplicaciones sean a la medida, para la producción de software parece ofrecer una alternativade solución bastante atractiva. Los productos que resultarían de esta estrategia, serían "paquetes"que incorporan soluciones específicas para cada cliente. Aquí pareciera existir una contradicción,por paquete se entiende una solución no específica, de la cual se producen muchas copias. Luego,¿cómo es posible producir "paquetes" que incorporen soluciones específicas y que permitanincorporar fácilmente los cambios?

Una respuesta a la pregunta anterior es recurrir a la estrategia de producción de líneas deproductos. En los ambientes de manufactura, un mismo producto, con ligeras variantes, esproducido en lotes pequeños o medianos para satisfacer las necesidades específicas de un grupoigual de usuarios. Las máquinas herramientas actuales tienen la flexibilidad suficiente como parasatisfacer necesidades específicas, sin que eso eleve los costos de producción. En tales ambientes,una línea de productos consiste en un grupo de productos que son similares en términosgenerales, pero que tienen ligeras diferencias entre sí.

Aplicaciones computacionales que existen en varias empresas tienen una semejanza a las líneasde productos, porque son sistemas similares con ligeras diferencias entre ellos. Algo que difieresubstancialmente con respecto a los ambientes de manufactura es el proceso de producción.

87

Tradicionalmente el software se suele desarrollar completamente para cada una de las distintasempresas, sólo en algunos casos los desarroUadores aprovechan de manera casual las aplicacionessimilares desarrolladas para otros clientes.

Objetivo particular.

Establecer una empresa de producción de software utilizando el enfoque de líneas de productosen el dominio de las Uniones de Crédito, las cuales actualmente no cuentan con suficiente apoyode sistemas computacionales; con el propósito de brindar una solución integral de bajo costo,adecuada a las necesidades concretas que tales instituciones tienen.

Nuestro propósito consiste en el establecimiento de una empresa que brinde servicios dedesarrollo de aplicaciones computacionales siguiendo la estrategia mencionada, limitando suoperación a las Uniones de Crédito. La empresa vendería a los clientes sus productos en forma deversiones (igual se hace actualmente con los paquetes), y las actualizaciones que son efectuadaspor cambios en el entorno podrán ser distribuidas a bajo costo (comparado con lo que unaempresa típica cobraría).

Mercado.

Para que el enfoque propuesto tenga éxito, es un requisito básico que exista un númeroimportante de usuarios de la alternativa tecnológica que se obtenga. Consideramos que lasinstituciones financieras conocidas como Uniones de Crédito cumplen satisfactoriamente nuestroobjetivo.

Las Uniones de Crédito utilizan sistemas de información que no satisfacen todas sus necesidades,algunas adquieren productos comerciales a los cuales es imposible efectuarle modificaciones,teniendo que adaptar parcialmente su operación a la forma de operar de los sistemas adquiridos.Otra opción que tienen las Uniones es comprar un producto desarrollado para ellas, conocidocomo Kepler cuyo costo es elevadísimo. Haciendo imposible su adquisición para la mayoría delas Uniones. Como última opción, las Uniones contratan los servicios de programadores odesarroUadores independientes. Desafortunadamente esta forma de proceder resulta serdemasiado costosa y en ocasiones poco práctica.

Dentro de las instituciones que constituyen el sistema bancario nacional están las Uniones deCrédito Comerciales, Industriales, Agropecuarias y de Servicios; y como parte de susobligaciones, éstas deben presentar información puntual y confiable sobre sus estados financierosa Nacional Financiera (NAFIN) y a la Comisión Nacional Bancaria y de Valores (CNBV),haciéndolas acreedoras de multas en caso de retrasos o errores. Frecuentemente incurren enmultas debido a la falta de sistemas que los apoyen adecuadamente en sus actividades.

Cada Unión vive una situación particular y tiene actividades propias a su giro (Comercial,Industrial, Agropecuario, Servicios, etc.), pero todas están regidas por la CNBV, la cual dictanormas sobre la información que deberán presentar, dictándoles el tipo y forma de presentaciónde la información. Adicionalmente, cada Unión debe presentar información dependiendo de su

giro a NAFIN, a la misma CNBV, y producir información propia para el control administrativo(crediticio y contable).

En nuestro país existe una gran cantidad de Uniones, pero en su mayoría son muy pequeñas tantoen la cantidad de personal, como en los recursos financieros que manejan. Proporcionalmenteresulta una fuerte erogación lo que deben dedicar al desarrollo de sistemas computacionales queapoyen sus actividades. Esto da lugar a que actualmente no cuenten con la infraestructura desoftware adecuada, dificultando a la Unión en su operación, y al Gobierno de México en lavigilancia y control que establece para las Uniones..

Nuestra propuesta ya ha sido aplicada exitosamente en varios proyectos de tamaño reducido. Elnuevo reto que implicaría este proyecto es con relación a la utilización de un ambiente dedesarrollo integral, que produzca a un bajo costo soluciones tan eficientes como aquellas que seproducirían en una estrategia de desarrollo de software a la medida.

Instauración de una empresa.

La estrategia de líneas de productos puede ser fácilmente incorporada por una empresa dedesarrollo de sistemas de información. La empresa vendería a los clientes sus productos en formade versiones, las actualizaciones que se realicen por cambios en el entorno, podrán serdistribuidas a bajo costo (comparado con lo que una empresa típica cobraría).

La empresa de desarrollo mantendría su operación gracias a un número abundante de clientes enun mercado vertical (nicho de mercado), cada Unión pagaría por los sistemas, montos muchísimomenores a los vigentes. Además, cada cliente tendría la ventaja de que su sistema estaríaespecialmente adecuado a sus necesidades particulares, no teniendo que modificar su forma deoperar.

La cantidad de Uniones de Crédito en el país no la tiene totalmente definida la CNBV, antes de lacrisis bancaria en el país existían más de 200 Uniones, actualmente muchas están enreestructuración o se le va a revocar su licencia; pero se tienen al menos 79 Uniones operandocorrectamente, previendo que en un futuro algunas más puedan sanearse.

Competidores y posición competitiva.

Como empresa competidora, existe solamente una empresa conocida como Kepler, que desarrollasistemas de información para Uniones de Crédito. La desventaja de sus productos es el altocosto, sus productos están desarrollados para un ambiente MS-DOS, tecnología que actualmenteestá en desuso (Ms-Dos presenta problemas de compatibilidad con los ambientes Windows), esun producto que se supone posee las características comunes que satisfacen a la mayoría de lasUniones (situación que no sucede, dado que cada Unión tiene sus propias necesidades), losusuarios tienen que adecuarse a la forma de trabajo del sistema, las actualizaciones omodificaciones son lentas y costosas. Kepler está ubicada en el D.F., y ha vendido sus productosa muy pocas Uniones del Centro del País, se han dedicado a desarrollar aplicaciones para otrostipos de empresas.

89

La otra forma de competencia son las pequeñas empresas o personas, que brindan sus serviciospara el desarrollo de aplicaciones, así como los departamentos de sistemas de las Uniones quetambién desarrollan sistemas; las aplicaciones que construyen sólo satisfacen las necesidades deuna Unión, y tratan de venderlas a otras, pero se enfrentan a la problemática de las otrasnecesidades propias de la Unión, teniendo la necesidad de crear otros módulos al sistema, ytambién tienen dificultades al realizar las modificaciones al código ya existente.

La empresa que se propone, como tal no tiene competencia, ya que no existe alguna quedesarrolle Sistemas de información para varias Uniones de crédito, y que estos sistemas esténadecuados a los requerimientos de cada Unión.

90

B.2 Plan Técnico.

Contenido.

1. Objetivo de la empresa y contexto.2. Arquitecturas de software para líneas de productos.3. Objetivos particulares.4. Descripción modular.5. Descripción de actividades.6. Plan de producción.7. Análisis de costos del producto.8. Licencias y propiedad intelectual.9. Confíabilidad.10. Mantenimiento y atención al cliente.11. Calidad total.

1. Objetivo y contexto.

El objetivo de la empresa es desarrollar sistemas de información por medio de un método devanguardia para el desarrollo de software, definido como Arquitecturas de Software para Líneasde Productos. Estos sistemas de información deberán satisfacer las necesidades básicas decontrol de información de los departamentos de contabilidad y operación de créditos, de Unionesde crédito de diversos sectores industriales y de servicios del país.

Tradicionalmente cuando se tiene la necesidad de desarrollar sistemas que satisfagan a una grancantidad de clientes (Uniones de crédito), se puede elegir alguna de las siguientes opciones:

1. Construcción de un sistema estándar (paquete).2. Construcción de sistemas individuales para cada cliente.

En la primera opción los clientes tienen que adaptarse a las posibilidades que ofrezca el sistemaestándar, limitando el potencial de beneficios que pueden brindar los sistemas de información.Los clientes saben que los sistemas de información pueden "manipular" la información demuchas maneras, pero con los sistemas estándar no pueden:

• Agregar otras opciones (Módulos para reportes específicos, Formas de presentación deinformación, Módulos para reportes propios de la Unión de crédito, etc.).

• Modificar las opciones presentes, con el propósito de adecuarlos a sus necesidades.

Las Uniones de crédito que adquieren este tipo de sistemas, necesitan de otros productos (Excel,Lotus, etc.) para poder realizar sus actividades, debido a lo restringido de los sistemas estándares(COI-Aspel, etc.).

En la segunda opción para desarrollar sistemas, se construyen sistemas a la medida para cadaUnión de crédito. Esta opción es la que debería tomarse ya que todas las Uniones aunque tienenun marco en común, es decir varias operaciones y actividades son similares, todas tienen

91

necesidades específicas, debidas principalmente al sector económico en que se encuentren; estasdiferencias son generalmente reportes de información específica.

2. Arquitecturas de software para Líneas de Productos.

Una estrategia de solución, que está emergiendo para resolver la problemática del desarrollo desistemas es arquitecturas de software para líneas de productos. Las arquitecturas de software hanestado implícitamente en los sistemas de software, generalmente dividendo los programas enmódulos, definiendo las interacciones entre los módulos, y construyendo sistemas a partir delensamble de módulos.

Una arquitectura es una estructura del software, una forma de organizar el software encomponentes; en arquitecturas de software para líneas de productos de manera análoga a unaplanta de producción, una línea de productos de software puede ser desarrollada de tal maneraque exploten un conjunto de características en común, por medio de componentes de softwarereutilizables con un enfoque que rompe el tradicional concepto de los proyectos individuales.

En línea de productos, el desarrollo de nuevos sistemas llega a convertirse más en materia degeneración que de creación; la actividad predominante es la integración en lugar de laprogramación. Así como la evolución de un sólo producto (modificaciones, actualizaciones)debe ser considerada dentro de un contexto más amplio, la evolución de la línea de productoscomo un todo. [Solderitsch 96]

Línea de productos enfatiza el reuso, a veces en formas que no son muy evidentes. Los aspectosque pueden ser reusados por todos los miembros de una línea de productos son [Bronsword 96]:componentes, personal, eliminación de defectos, experiencia en la planeación de proyectos,análisis de desempeño, procesos, métodos, herramientas, y la elaboración de sistemas prototipo.

Líneas de productos introducen en el proceso de desarrollo de software, estructuras o modelos dediseño de software que permiten la construcción de sistemas con el objetivo de reutilizar suscomponentes para futuros sistemas; en un esquema formal y organizado, sin dar demasiadaimportancia a la complejidad y tamaño de los nuevos sistemas.

3. Objetivos particulares.

Dos objetivos particulares se pretenden, además de desarrollar sistemas por medio de líneas deproductos, el primero consiste en tener una propuesta de solución que permita realizar elmantenimiento de los sistemas en menor tiempo (modificar la menor cantidad de código posible,fácil forma de agregar y adaptar otras opciones al sistema).

El segundo objetivo pretende el desarrollo y aplicación de componentes reusables para laproducción y mantenimiento de varios sistemas que posean infraestructuras similares. El reusopor componentes es ventajoso porque: [Sodhi 99]

• Incrementa la productividad.• Mejora la productividad.• Disminuye los costos.

92

• Reduce el tiempo de desarrollo de software.• Reduce el mantenimiento y tiempo de reparación.• Mejora la estandarización.• Incrementa la portabilidad.• Contribuye a la evolución del sistema.• Mejora el desempeño.

El proyecto utilizará la programación orientada a objetos, desde una perspectiva diferente a latradicional, logrando un mejor reuso del software.

4. Descripción modular.

Los siguientes diagramas representan los elementos del sistema de información para Uniones deCrédito. Describe los módulos que conformarán el sistema. (Esquema funcional)

Nivel 1. Sistema Unión de Crédito

Módulo:Contabilidad

Módulo:Créditos

Desde una perspectiva general el sistema está dividido en el módulo de contabilidad y el módulode control de créditos.

Nivel 2. Módulo Contabilidad

Catálogo de cuentas

Reglas de contabilidad

Pólizas Reportes auxiliares

Reportes oficiales

Cierre mensual

Cierre del ejercicio

Descripción del módulo de Contabilidad.

• Catálogo de cuentas: Realizará opciones de altas, bajas, modificación y consulta decuentas que formarán el catálogo.

• Reglas de contabilidad: Realizará las opciones de altas, bajas, modificación y consulta dereglas que es necesaria para la construcción de reportes; son reglas de agrupación decuentas, que se utilizan para generar los reportes mensuales (balance general y estado deresultados).

• Pólizas: Ejecutará opciones de altas, bajas, modificación y consulta de pólizas.• Reportes auxiliares: Reporte de saldos de cuentas, diario contable, mayor (saldos a nivel

mayor), balanzas de comprobación, y auxiliares de cuentas.• Reportes oficiales: Realizará los reportes de balance general y estado de resultados.• Cierre mensual: Ejecutará el cierre mensual (cierre del período).

93

Cierre del ejercicio. Es una operación especial que se realiza al final del año (final delejercicio), cancela los saldos de las cuentas del último mes (diciembre), crea una póliza decierre del ejercicio, y abre el nuevo período y ejercicio.

Nivel 2.

Socios

Tasas

Módulo de Créditos

Cobros

Reportes

Descripción del módulo de Operación de Créditos.

• Tasas: Realizará opciones de altas, bajas, modificación y consulta de tasas de interésbancario, para el cálculo de operaciones en cobros y reportes.

• Socios: Permitirá altas, bajas, modificación y consulta de socios de la Unión de crédito,controla información como nombre del socio, dirección, nombre de la empresa, giro, etc.

• Créditos: Controlará las altas, bajas, modificación y consulta de los créditos que seotorguen a los socios de la Unión.

• Cobros: Controlará los cobros de interés y pagos parciales de los créditos.• Reportes: Realizará reportes de responsabilidades por socio, obligaciones vigentes de los

socios, cuenta corriente.

5. Descripción de actividades.

Las actividades para el desarrollo del sistema involucran en su inicio, actividades para laconstrucción de la Arquitectura de Software, y posteriormente el desarrollo de componentes eintegración de la aplicación.

Descripción de las tareas.

• Establecimiento de la declaración del producto: Definición de las característicastecnológicas del sistema, definición de la infraestructura básica que necesitan las Uniones,y especificación de las limitaciones.

• Análisis de dominio: Recopilación y análisis de la información proporcionada por lasUniones, para determinar semejanzas y variaciones entre los diferentes productossolicitados. Elaboración del modelo de contexto, describe el medio en el cual lasaplicaciones serán usadas y operadas. Elaboración del modelo de características,perspectiva del usuario final de las capacidades que tendrán las aplicaciones.

• Diseño del dominio: Realización de un análisis funcional de las aplicaciones; se elaboranmodelos de flujo de datos, análisis de operaciones para determinar semejanzas yvariaciones, y finalmente se elaboran modelos de interacción de procesos, diagramas deestructura modular.

• Desarrollo de componentes: Codificación de los componentes, obtenidos de lamodelación arquitectónica.

• Pruebas de los componentes: Desarrollo de pruebas de unidad de los componentes ycorrecciones en los componentes.

94

• Desarrollo del generador de aplicaciones: Implementación de un generador deaplicaciones con analizador de reglas de diseño, generación de componentes, ydeterminación del mecanismo para integrar los componentes a las pantallas de losusuarios.

• Pruebas de integración de la aplicación: Realización de pruebas de integraciónascendente, y pruebas de validación y aceptación para validar los requisitos iniciales.

• Entrega de productos: Elaboración de manuales para el usuario y entrega del sistema.

6. Plan de producción.

Una vez desarrollados los componentes que constituirán la infraestructura básica de los sistemasde información para las Uniones de Crédito; la forma de producir las aplicaciones tendrá elsiguiente plan:

Análisis decontexto

Requerimientosdel usuario

Modelaciónde dominio

Análisis enbase a lamodelacióndel dominio

Modelación dela arquitecturade software

Especificacióndel desempeñode la aplicación

Arquitecturade softwaredel dominio

Diseño delsistema desoftware enbase a laarquitecturadel dominio

Desarrollo decomponentesreusables

Arquitecturade softwaredélaaplicación

Componentesreusables

Desarrollo delsoftware de laaplicación

7. Análisis de costos del producto.

Aplicación

El costo principal del producto es el tiempo que se invierta al desarrollo del proyecto; y otrosgastos que están involucrados para el desarrollo de software, como el costo del software yhardware. La distribución de las personas y del tiempo es:

Tarea

Establecimiento de requerimientosAnálisis del dominioDiseño del dominioDesarrollo de componentes reusablesPruebas de los componentesGenerador de aplicacionesPruebas de la aplicaciónEntrega de productos de software

Personas

22323323

Horas por personaA6

28201008

3246

B630448881646

C

44

84

6

Total horas por tarea

12581081882452818

Nota al cuadro: A y B son analistas y programadores, C es analista.

95

El Costo total de horas del proyecto es de 468 horas. (Actualmente el salario mensual de unprogramador es de alrededor de $7000, dividido entre los días laborales [22] y posteriormenteentre ocho, para obtener el salario por hora, se obtiene que el costo por hora es de $39.7).

7.1 Hardware y software.

Para el proyecto se necesita de dos computadoras personales y una impresora:

Tipo de equipoPC Dell Dimensión V400CProcesador Intel Celeron 400 MhzHD 4.3 GB, 32MB SDRAM, Modem,Windows Office

Impresora HP DeskJet 692C

Cantidad2

1

Costo$1,000.00 dls.

$180.00 dls.

El costo del equipo para el proyecto será de $2180.00 dls. El software a utilizar es BorlandDelphi 4 (Inprise Corporation), su costo es de $445.00 dls. El Costo total del hardware ysoftware para el proyecto es de $2,625.00 dls. mas IVA.

8. Licencias y propiedad intelectual.

Se limitará el uso que se haga del sistema de información para Uniones de crédito mediante laconcesión de licencias limitadas a los clientes; esto limitará a los clientes del empleo de variascopias de programas individuales al mismo tiempo, e impedirá utilizar copias en variascomputadoras, excepto en las computadoras determinadas.

Nos reservamos el derecho de patentar toda secuencia de instrucciones destinadas a ser utilizadas,directa o indirectamente, en el sistema de información para Uniones de crédito, para realizar unafunción o una tarea o para obtener un resultado determinado, cualquiera que fuera su forma deexpresión y fijación. Pudiendo ser objeto de inscripción en el Registro de la PropiedadIntelectual.

Nos reservamos el derecho de patentar los productos que se deriven de la Arquitectura desoftware, la secuencia de instrucciones de los componentes que constituyen la Arquitectura desoftware, y las interfaces de comunicación entre componentes, cualquiera que fuera su forma deexpresión y fijación.

9. Confíabilidad.

La confiabilidad en los sistemas de información depende en gran parte de los fallos o deficienciasque presente el sistema; estos fallos se producen por problemas en el diseño o en laimplementación. La forma de asegurar la confiabilidad en el sistema de información paraUniones de crédito será por medio de las dos etapas de pruebas del desarrollo del proyecto; en laprimera etapa se prueba que los componentes funcionen correctamente de forma individual, deacuerdo a los requerimientos de la Arquitectura de software diseñada; en la otra etapa de pruebasse verifica de forma integral el funcionamiento de la aplicación, corroborando con losrequerimientos del cliente.

96

10. Mantenimiento y atención al cliente.

Al hablar de mantenimiento en la aplicación, es referirse al mantenimiento de la arquitectura, lacual nos facilita el mantenimiento en la codificación, ya que se tienen identificadas lasoperaciones del sistema; cuando una operación local en un componente es modificada, está noafectará a otros componentes externos, dado que los accesos entre componentes son por medio deinterfaces lógicas.

Una arquitectura además de facilitar el mantenimiento en el código, también facilita adecuar unsistema a los requerimientos del cliente, o aumentarle nuevas opciones; ya que sólo se construyenlos nuevos componentes, y se integran por medio de su interfaz lógica. Cada nuevo componentese agrega a la línea de productos para su posterior compilación.

Un problema que ocurre con los sistemas de información que utilizan las Uniones de crédito, esla dificultad o nula posibilidad de modificación a sus sistemas; está problemática actualmente seha agravado, ya el organismo que las rige (Comisión Nacional Bancaria y de Valores) hamodificado muchas de sus políticas y procedimientos para las Operaciones en contabilidad yOperación de créditos. Las Uniones de crédito además de necesitar un sistema de informaciónadecuado a sus requerimientos, necesitan que a estos sistemas se les pueda dar un mantenimientode una forma rápida y confiable. Al vender un sistema a alguna Unión de crédito también sedebe vender una póliza de mantenimiento del sistema, que garantice a la empresa que suinversión será útil, ya que estos sistemas pueden volverse obsoletos o inservibles.

11. Calidad total.

Para cumplir con las expectativas de los clientes, se realizan durante el desarrollo de laaplicación, pruebas que validen el cumplimiento de los requerimientos especificados. En laetapa de pruebas de integración se comprueba el funcionamiento, de acuerdo a las necesidadesdel cliente. Dada la posibilidad de construir aplicaciones a la medida, se garantiza que laaplicación debe satisfacer las necesidades propias de la Unión de crédito.

97

B.3 Plan de negocios.

Contenido.

1. Empresa.2. Identificación del proyecto.3. Descripción detallada del producto o servicio.4. Análisis del mercado5. Evolución y ciclo de vida del producto.6. Estrategia de venta del producto.7. Estrategia de publicidad y promoción.8. Inversiones requeridas y costo de un proyecto.9. Estrategia de precios.10. Financiamiento.11. Proyecciones financieras.

1. Empresa.

La empresa a constituir es RapiSoft, su misión de la de producir software de calidad en el menortiempo, y está formada por alumnos de una Institución Educativa.

2. Identificación del proyecto.

RapiSoft producirá sistemas de información para la administración de Uniones de crédito,produciendo a gran escala sistemas que tengan un dominio en común, y a la vez estos sistemasestarán hechos "a la medida" del cliente. Utilizando para ello, tecnología de vanguardia enmétodos de desarrollo software, principalmente los referentes al reuso de software; métodos quenos conducirán a una mejor manera de producción de software, asegurando una producciónrápida y de excelente calidad, para la total satisfacción del cliente.

Nuestro enfoque es cambiar la forma de desarrollo de software: Producir sistemas "a la medida" agran escala.

2.1 La oportunidad.

Las Uniones de crédito son un nicho de mercado que no ha sido explotado de forma adecuada,todas las Uniones trabajan con sistemas de información, pero sólo aquellas que han invertido enla construcción de sus propios sistemas son las que operan de mejor forma, pero en su mayoríason productos de poca calidad. Existe la oportunidad de ofrecerles un producto de calidad y abajo precio; ya que los costos de desarrollo serían distribuidos entre varias Uniones y a largoplazo. Este tipo de instituciones por su naturaleza, tienen acceso a diversas fuentes definanciamiento y también cuentan con recursos propios.

Un aspecto importante para las Uniones es el que sus sistemas de información puedan seractualizados, actualmente esto está ocurriendo con mucha frecuencia, ya que la CNBV estámodificando muchas políticas en la operación en las Uniones, para un mejor control y vigilancia

98

por parte de la CNBV. Las modificaciones y actualizaciones a los sistemas son de vitalimportancia a la Uniones, ya que por cada retraso en la entrega de información a la CNBV, se lesimpone fuertes multas (existen multas con las que se podría comprar un sistema de información).Los sistemas de información en las Uniones son importantes, porque son sus herramientas para larealización de sus actividades.

Nuestra ventaja competitiva es la producción de software a la medida, de forma rápida yconfiable (dado que sus componentes serán probados y usados en varias empresas), y elmantenimiento también será de la misma forma.

3. Descripción detallada del producto y servicio.(Redactada en forma de documento de presentación del producto para el cliente)

En un mundo donde cada vez más se considera a la computación, como un elemento de apoyo enlas actividades diarias. Empresas como las Uniones de crédito no deben ser la excepción, parautilizar la tecnología como una herramienta que facilite sus operaciones.

Es de vital importancia para las Uniones dar un buen servicio a sus clientes (socios de la Unión),y para ello los sistemas de información apoyan de una manera rápida y confiable.

RapiSoft produce el producto: Sistema Integral para la Administración de Uniones de Crédito(SIAUC), cuya función es la de automatizar las operaciones y actividades que realizan elDepartamento de contabilidad y el Departamento de Control de Créditos de una Unión deCrédito.

SIAUC a diferencia de otros productos, opera en un ambiente Windows y permite el trabajo engrupo, es decir varias personas pueden estar usando el sistema al mismo tiempo, sin problemas ensu funcionamiento, y está adecuado para satisfacer las necesidades propias de la Unión. EnRapiSoft nuestra intención no es sólo venderle un producto, es ser su equipo de apoyo encuestiones de tecnologías de información. Estamos al tanto de las políticas gubernamentales quehan surgido de parte de la CNBV y de Nacional Financiera (NAFIN), para un nuevo control yforma de operación de las Uniones. Políticas que han provocado que los sistemas deinformación tengan que actualizarse o los nuevos requerimientos.

Como su equipo de apoyo, siempre estaremos en disposición de realizar el mantenimiento delsistema, y en un menor tiempo a cualquier posible competidor, así como garantizándole unapronta y confiable actualización-mantenimiento, de acuerdo a los nuevos requerimientos de losOrganismos Gubernamentales.

SIAUC está compuesto de dos módulos: Contabilidad y Créditos. En el primer módulo seencuentran las opciones que satisfacen las necesidades básicas a cubrir del Departamento decontabilidad, y en el módulo de Créditos las del Departamento de Operación Créditos.

99

Descripción de las opciones del módulo Contabilidad:

• Catálogo de cuentas: Ejecuta altas, bajas, modificación y consulta de las cuentas queformarán al catálogo de cuentas. RapiSoñ proporciona sin un mayor costo del sistema, elcatálogo de cuentas definido por la CNBV.

• Reglas de contabilidad: Realiza las altas, bajas, modificación y consulta de las reglas deagrupación que estípula la CNBV, para la construcción de reportes como el Balancegeneral y el Estado de resultados.

• Pólizas: Ejecuta las altas, bajas, modificación y consulta de pólizas, permitiendo manejarvarios tipos de pólizas, generación automática del número consecutivo de la póliza,comprobación de saldos, ingreso de conceptos particulares.

• Reportes diarios: Reporte de Saldos (muestra la información de saldos de las cuentas, lasuma de los cargos y abonos, así como su saldo anterior), Diario contable (muestra por díalas pólizas que fueron operadas, sus saldos, cargos y abonos), Mayor (muestra los saldosde las cuentas a nivel mayor), Balanzas de comprobación, y Auxiliares de cuentas.

• Reportes mensuales: Realiza el Balance General y Estado de resultados.• Cierres: Realiza los cierres mensuales, y al final de año el cierre del ejercicio.

Descripción de las opciones del módulo de Créditos:

• Tasas: Realiza las altas, bajas, modificación y consulta de tasas de interés bancario, parael cálculo de operaciones en cobros y reportes.

• Socios: Permite altas, bajas, modificación y consulta de socios de la Unión de crédito,controla información como nombre del socio, dirección, nombre de la empresa, giro, etc.

• Créditos: Controla las altas, bajas, modificación y consulta de los créditos que se otorguena los socios de la Unión.

• Cobros: Controla los cobros de interés y pagos parciales de los créditos.• Reportes: Responsabilidades por socio (muestra información sobre el estado de un

crédito, montos, pagos, adeudo, de un socio), Obligaciones vigentes de los socios(desglosa información sobre los adeudos de los socios en un período definido por elusuario), Cuenta corriente (estado de las partidas de debe y haber de las operaciones).

Las posibilidades del sistema no terminan aquí, ya que a partir de un estudio a su Unión, sedeterminarán sus necesidades particulares a cubrir; incorporándole a su sistema otrascaracterísticas, que harán de su sistema una herramienta integral, y en un futuro mantenerloactualizado con otras opciones.

Como herramienta integral SIAUC elimina el estar utilizando varias herramientas (Excel, Lotus)para realizar el trabajo de la Unión. SIAUC concentra todas las posibles actividades de la Uniónque pueden ser automatizadas por medio de un Sistema de Información.

100

4. Análisis del mercado.

4.1 El cliente.

Una Unión de Crédito es una institución financiera cooperativa, controlada por sus miembros(socios) y propiedad de sus miembros, formada para permitir a las personas ahorrar, tomarpréstamos, obtener servicios financieros relacionados, y participar en su administración. Estasinstituciones son parte del sector bancario y financiero de México, regidas por la ComisiónNacional Bancaria y de Valores (Gobierno de México). Su función es la de complementar elapoyo crediticio a la micro, pequeña, y mediana empresa, en condiciones más favorables que lasinstituciones bancarias de mayor tamaño (Bancomer, Banamex, etc.).

Generalmente las Uniones son formadas por personas o empresas que tienen el mismo giro oactividad, existen Uniones de ganaderos, industriales, agricultores, empleados del sector salud,muebleros, constructores, etc. Las Uniones han fomentado el desarrollo de personas y pequeñasempresas que no tienen acceso al crédito, desde hace más de 25 años en todo el país.

4.2 Factores económicos.

Desde 1995 nuestro país vive una crisis económica cuyas causas no describiremos, pero que si hacontribuido a un deterioro económico del país; perjudicando entre muchos, a los pequeñosempresarios y socios de las Uniones, viendo disminuidos en sus actividades (mercantiles,comerciales, de servicios, etc.), sus ingresos o ganancias. Esto ha provocado una serie deproblemas: los socios al no tener utilidades, no pagan sus adeudos (créditos), la Unión al norecibir pagos incrementa su cartera vencida (adeudos que ya pasaron su fecha de vencimiento);todo la anterior aunado a tasas de interés altas e inestables. Esto ha provocado que muchasUniones hayan tenido que cerrar por su mala situación financiera.

Se debe reconocer que muchas Uniones han sido cerradas o tienen problemas económicos yjurídicos; esto es debido principalmente por las malas administraciones de los directores de lasUniones, ya que estuvieron otorgando créditos sin garantías, y también sin una buenajustificación.

A pesar de la clausura de muchas Uniones en el país, actualmente existe una buena cantidad deellas, algunas con buena situación económica, otras en reestructuración, pero todas sosteniéndosecon sus propios recursos. Todas las Uniones que estén operando actualmente, tienen muchasposibilidades de salir adelante, a pesar de la situación económica.

Con base a entrevistas con personas de las Uniones de crédito del Noreste del país, se estima queestén operando al menos 79 Uniones en el país. La cantidad exacta no se sabe, actualmente laCNBV está realizando auditorias a las Uniones para determinar cuales son viables, y se lesapoyará para otorgar créditos, con recursos de fondos de fomento como NAFIN, FIRA, FondoMinero, etc.

101

4.3 Mercado.

El mercado desde nuestro enfoque es amplio, y aunque pudo ser mayor en el pasado, la cantidadactual de Uniones es un número considerable, teniendo como reto el satisfacer a una granvariedad de tipos de Uniones (agropecuarias, industriales, etc.). Si bien nuestro enfoque es haciael mercado de Uniones de Crédito, existen otras organizaciones auxiliares del crédito que tienenesquemas semejantes a la operación de las Uniones, que ampliarían el mercado: Arrendadoras,Cajas de Ahorro, Sociedades de Ahorro y Préstamo, Grupos Financieros.

De nuestra investigación también encontramos Instituciones parecidas a las Uniones de Créditoen otros países: Colombia, Panamá y Nicaragua. Denominadas es estos países como Entidadesde Crédito Social, y Cooperativas o Uniones Populares; en su mayoría apoyadas por organismosinternacionales como el Banco Interamericano de Desarrollo (BID).

El concepto de Unión de Crédito no es propio de México, surgió en Europa el siglo pasado, y éstaidea ha sido tomada en muchos países, lo que nos hace suponer que este tipo de Institucionestambién se encuentren en la mayoría de los países sudamericanos, centroamericanos y del caribe.Otro elemento que apoyaría esta suposición, es el hecho de que el BID apoya estas instituciones.

El crédito como tal, ha probado a través de muchos años, ser un elemento indispensable para eldesarrollo de todo tipo empresas, y siempre existirán instituciones que apoyen a pequeñosempresarios que no pueden acceder a los créditos de la banca tradicional; porque también sonimportantes para el desarrollo de las naciones.

5. Evolución y ciclo de vida del producto.

SIAUC no tiene un tiempo de vida límite, porque desde el inicio de su desarrollo está orientado aser un sistema evolutivo. SIAUC se adaptará a las nuevas necesidades que surjan en eltranscurso del tiempo. Los sistemas de información para Uniones no deben ser consideradoscomo productos que al ser entregados al cliente termina su elaboración; los sistemas deinformación para las Uniones son sistemas dinámicos que deben ser mantenidos con frecuencia,debido a las modificaciones o nuevos procedimientos (esquemas de reestructuración de créditos,nuevos catálogos de cuentas, etc.) impuestos por NAFIN o la CNBV.

SIAUC estará desarrollado para funcionar en ambientes Windows de Microsoft (Windows forWorkgroups, Windows 95, 98, Windows NT, Server, Workstation), y en cualquier plataforma detipo PC, tecnologías que actualmente dominan el mercado, y muy probablemente seguirándominando, debido al monopolio y la débil competencia que tienen las empresas proveedoras deestos productos. Por lo que se prevé el funcionamiento de SIAUC en las siguientes versiones deWindows y nuevas tecnologías para PCs.

6. Estrategia de venta del producto.

RapiSoft planea vender SIAUC a Uniones de Crédito que no posean sistemas de informaciónpara controlar la cartera de créditos y la contabilidad, así como a Uniones que ya posean sistemasde información "hechos a la medida", ya sea para contabilidad y/o créditos.

102

La siguiente lista describe acciones a realizar para introducir el producto a la Unión:

• Crear la necesidad al cliente de utilizar sistemas que operen en ambientes Windows,indicándole que como ventaja tendrá una forma fácil y rápida de operar los sistemas (unambiente amigable).

• Crear la necesidad de utilizar sistemas con tecnología de vanguardia y confiable, lo cualle permitirá realizar las operaciones más rápidamente.

• Resaltar que es ventajoso trabajar con sistemas para trabajo en grupo.• A diferencia de otros productos RapiSoft no cobra por licencias de uso, no limita la

cantidad de usuarios que pueden usar el sistema al mismo tiempo, la cantidad de usuariosestá limitada a la capacidad de los recursos de HW y SW.

• Es una solución de bajo costo, con posibilidad de pago en plazos.• Se le garantiza un sistema libre de fallas.• Promover la idea de convertirse en su equipo de apoyo para cuestiones computacionales.• No sólo se está vendiendo el producto también se vende la garantía de que el sistema no

se volverá obsoleto; como su equipo de apoyo que siempre le realizará el mantenimientorápidamente.

• Resaltar que el mantenimiento y el desarrollo del sistema será más rápido que cualquiercompetencia que exista.

• Realización de un análisis de requerimientos, para construir un sistema que satisfaga lasnecesidades propias de la Unión.

• SIAUC está construido para cumplir con los requerimientos de la CNBV.• Tener conocimiento de las políticas y modificaciones que da conocer la CNBV y NAFIN,

a través de boletines.• Indicar que SIAUC está construido con los mejores algoritmos computacionales, para dar

respuestas rápidas y confiables.• Existe la posibilidad de vender la parte de SIAUC referente a Operación de Créditos o la

parte de Contabilidad, pero el objetivo es venderlo completo.• El tener un producto como SIAUC, asegura que sus actualizaciones serán rápidas para

evitar retrasos en la entrega de la información a NAFIN y CNBV, y evitar multas.

Otros aspectos que le dan un valor agregado a SIAUC.

• Atención vía telefónica sobre dudas en la operación del sistema.• Brindar capacitación sin costo del sistema, a una cantidad limitada de personas.• Mantenimiento de SIAUC vía Internet o comunicación tipo Acceso Remoto, estos medios

facilitarán el mantenimiento a los sistemas de las Uniones que estén ubicadas en ciudadesalejadas de Monterrey. A través de estos medios de comunicación se enviará el sistema omódulos que necesite, manuales, etc.

7. Estrategia de publicidad y promoción.

La imagen que se va ha proyectar de SIAUC es la de un sistema con un funcionamiento rápido,confiable, fácil en su uso, libre de fallas, construido "a la medida", y con la capacidad de tenermás características. La imagen de SIAUC siempre estará acompañada de la imagen de laempresa: RapiSoft desarrolla sistemas con calidad, confiables, robustos, rápidos, y en un tiempo

103

menor al de la competencia. RapiSoft siempre brindará apoyo a la empresa cliente, proyectandouna relación de trabajo responsable.

RapiSoft planea usar una variedad de recursos para promocionar el sistema de información, enaquellas áreas que la experiencia ha mostrado ser las más efectivas.

• Presentación particular de SIAUC a los directivos y personal de una Unión de Crédito.• Envío de cartas con información de la compañía y del producto a directivos de las

Uniones.• Distribución del SIAUC en una versión para demostración, que permita utilizar el sistema

y observar sus características y ventajas.• Exhibición en Convenciones y Reuniones de las Asociaciones de Uniones de Crédito.• Exhibición en Ferias de computación y productos para el sector financiero.• Promover entre las Uniones la idea de tener páginas de Internet promoviendo los

Servicios de las Uniones, las cuales pueden ser solventadas por una cuota anual pagadaentre todas las Uniones, su costo también podría disminuirse al cobrar por publicidad ensus páginas, publicidad de RapiSoft. Otra opción sería que la páginas fueran nuestras,permitiendo que los Uniones promovieran sus servicios, a cambio de nuestra publicidad.

• Promover el diseño de páginas Internet, en donde su fin sea un medio de comunicaciónentre el personal de las Uniones de Crédito; sirviendo para enviar preguntas, dudas, oplantear problemas en las Uniones, y el mismo personal de otras Uniones den posiblessoluciones, respuestas, etc. RapiSoft insertaría publicidad en estas páginas. (Ej. www.cu-cafe.com).

8. Inversiones requeridas y costo de un proyecto.

Las inversiones para el establecimiento de la empresa y para el desarrollo del sistema, estándividas en tres rubros: Equipo, Gastos de operación y Nómina.

8.1 Equipo.

La inversión en equipo está conformada por el gasto en hardware y software. Como etapainicial se necesitará de:

TipoHW

HWSW

EquipoPC Dell Dimensión V400C.Procesador Intel Celeron 400 Mhz. HD 4.3 GB, 32MBSDRAM, Modem, Windows Office.Impresora HP DeskJet 692CBorland Delphi 4

Cantidad2

11

CostoUS$1000.00

US$180.00US$445.00

El costo total del hardware y software para el proyecto es de US$2,625.00, multiplicado por unaparidad de 10 pesos por dólar, más el IVA: $30187.50 pesos. Se tiene planeado recuperar estainversión en un plazo de un año, por lo que podría considerarse como un gasto mensual surecuperación ($2515.00 pesos mensuales). Este gasto sólo se aplicaría al costo del producto,durante el primer año de la empresa.

104

8.2 Gastos de operación.

Para obtener los gastos de operación se realiza una suma de los gastos mensuales de: Renta delocal amueblado($3500.00), Energía ($45.00), Agua ($30.00), Teléfono ($200.00), Internet ($

200.00), y Accesorios y papelería ($50.00); lo cual da una suma de $4,025.00 pesos(gastos por mes).

8.3 Nómina para el proyecto.

La nómina mensual se obtendrá a partir de la definición del sueldo de las personas que laboren enel proyecto. Se definirá el sueldo de los integrantes igual al de un programador de una empresaprivada ($7000), dividido entre los días laborales por mes (22) y posteriormente entre ocho, paraobtener el salario por hora ($39.7).

En el plan técnico se definió que el total de horas para realizar el proyecto es de 468, multiplicadopor 39.7, da un costo del proyecto de $18,579.00 pesos.

8.4 Costo de un proyecto.

Sí al inicio sólo se consiguiera un cliente y dado que el proyecto dura cuatro meses, el costo delsistema SIAUC sería la suma de nómina ($18579.00), mas costo de equipo ($2515.00 por 4), masgastos de operación ($4025.00 por 4), dando un total de $44,739.00

SIAUC es vendido en primera instancia como un sistema con la infraestructura básica paracontrol de Uniones, por lo que agregarle los módulos que satisfagan los requerimientos propiosde cada Unión, requerirá de un estudio para determinar el costo de los nuevos módulos. Estoaumentaría el costo de desarrollo.

Tomando como base los módulos del sistema de la competencia Kepler, a SIAUC le faltaríanocho módulos (para Kepler estos módulos son generales y aplicables a cualquier Unión, situaciónque no se cumple), y de acuerdo a nuestras estimaciones aumentaría el costo a $70,469.00, peroesta no es una cantidad definitiva, porque en la mayoría de los casos será menor.

Uno de nuestros objetivos es vender el sistema a dos Uniones, de esta forma el costo total serepartiría entre estas dos Uniones.

9. Estrategia de precios.

Debido a que somos una empresa en inicio de operaciones, hemos definido dos etapas para laestrategia de precios: etapa de inicio de operaciones y etapa de crecimiento.

En la etapa de inicio de operaciones, por las inversiones realizadas para la formación de laempresa, se tendrá que hacer una agresiva introducción al mercado, para asegurar la recuperaciónde las inversiones y nuestra continuidad. RapiSoñ planea ofrecer el producto SIAUC condescuentos en la etapa de inicio. Para hacer los descuentos, el margen de utilidad no existirá enla venta, pero si se cobrará por los conceptos de nómina, equipo y gastos de operación. En caso

105

de necesitarse un mayor descuento, los integrantes de la empresa estarían de acuerdo en disminuir30% de su salario, lo cual haría disminuir el costo del sistema en un 13%; todo esto con laintención de vender el producto a la Unión y recuperar las inversiones iniciales.

La capacidad de descuento de nuestro único competidor (Kepler) se desconoce, pero el precio desu producto se encuentra entre $72500.00 y $88000.00 (dependiendo de la versión); y durante laetapa de inicio se planea estar por debajo de los precios de Kepler. De acuerdo a nuestrasestimaciones siempre podremos estar por abajo, dado que en la medida que se desarrollen másproyectos, tendremos mayor código reutilizable, y nuestros costos en el desarrollo de softwareserán a su vez menores.

En la etapa de crecimiento comenzará a incluirse en el costo de la venta del sistema un margen deutilidad (10%), se eliminaría el concepto de equipo, y se mantendría igual el concepto por nóminay gastos de operación. Al llegar a esta etapa se tendrá un mayor margen en el manejo de precios,podría sustituirse lo que se cobraba por el concepto de recuperación de equipo, por un nuevomargen de utilidad (22.5%). Un objetivo será también la reducción de los gastos de operación, yobtener mayor utilidad y menor precio de los sistemas.

10. Financiamiento.

La primera opción para obtener financiamiento es una misma Unión de crédito, para obtener uncrédito se debe como primer requisito ser socio (ingresar con la compra de una acción), y dejaruna garantía. Los montos de vencimientos son negociables; tienen sus propios tipos de créditos.Obtener un financiamiento con una Unión es más ventajoso que con un Banco tradicional. Estáncreadas para apoyar a la microempresa.

Se puede en dado caso obtener el equipo de computo a través de Instituciones bancarias(Bancomer, Bital, etc.), que venden equipo de cómputo a plazos. Existen tiendas de cómputoque también venden software y hardware a crédito.

11. Proyecciones financieras.

Usando niveles de ventas mínimos y el precio de SIAUC de $68990.00 (precio estimado deSIAUC, a partir de un promedio del costo por los módulos que se agregan para completar elsistema), se prevén los siguientes resultados durante los primeros tres años. Se consideran lossiguientes supuestos:

• Las ventas para el primer año se supone será de dos sistemas, el segundo de tres, y en eltercero cuatro.

• Los gastos de operación se mantendrán constantes.• El costo de equipo de liquida en el primer año.• La nómina se mantiene constante.

106

RubroVentas

Menos:Gastos de operaciónCosto de equipoNómina

Diferencia

2000137980

483003018755740

(+)3753

2001206970

483000

55740

(+) 102930

2002275960

483000

55740

(+)171920

Total620910

14490030187

167220

278603

Como objetivos tenemos: reusar el código en la mayor proporción posible y mantener los costosde desarrollo en las mismas proporciones, aún y cuando se tengan más aplicaciones que entregar.

En el enfoque de Arquitecturas de Software para Líneas de Productos, el costo de desarrollo se vadisminuyendo en la medida que se construyan más aplicaciones, en el enfoque tradicional loscostos se van incrementando.

Costo

Tradicional

Líneas de productos

No. de aplicaciones

107

Referencias.[Bailin 92]

[Bass 97]

[Bass 98]

[Batory 92]

[Batory 98]

[Bergey 98]

[Booch 94]

[Booch 98]

[Bronsword 96]

[Camegie 98]

[Clemens 97]

[Clemens 98]

[Coad 90]

[Coad 92]

[Cohén 96]

Bailin, S. "Domain analysis with Kapture". CTA Inc., 1992.

Bass, Len; Clements, Paul; Cohén, Sholom; Northrop, Linda; Withey, James."Product Line Practice Workshop Report" (CMU/SEI-97-TR-003). CarnegieMellon University, Software Engineering Institute, 1997.

Bass, Len; Clements, Paul; Kazman, Rick. "Software Architecture in Practice".Addison-Wesley, 1998.

Batory, Don; O'Malley, S. "The design and implementation of hierarchicalsoftware systems with reusables components". ACM Transactions on softwareEngineering and methodology, vol. 1, no. 4, October 1992.

Batory, Don. "Product-Line Architectures". University of Texas at Austin, Dept.Computer Sciences, 1998.

Bergey, John; Clements, Paul. "DoD Product Line Practice Workshop Report"(CMU/SEI-98-TR-007). Carnegie Mellon University, Software EngineeringInstitute, 1998.

Booch, G. "Object-oriented analysis and design with applications". Addison-Wesley, 1994.

Booch, Grady; Rumbaugh, James; Jacobson, Ivar. "The Unifíed ModelingLanguage. User's Guide". Addison-Wesley, 1998.

Bronsword, Lisa; Clemens, Paul. "A Case Study in Successful Product LineDevelopment" (CMU/SEI-96-TR-016). Carnegie Mellon University, SoftwareEngineering Institute, 1996.

Carnegie Mellon University. "Product Line Systems". Carnegie MellonUniversity. 1998.URL: http://www.sei.cmu.edu/plp/product_line_overview.html

Clemens, Paul. "Report of the reuse and product lines working group of WISR8"(CMU/SEI-97-SR-010). Carnegie Mellon University, Software EngineeringInstitute, 1997.

Clemens, Paul; Northrop, Linda; et al. "A framework for software product linepractice. Versión 1.0" (CMU/SEI-98-SR-010). Carnegie Mellon University,Software Engineering Institute, 1998.

Coad, Peter; Yourdon, Edward. "Object-oriented analysis". Prentice-Hall, 1990.

Coad, Peter. "Object-oriented patterns". Communications of the ACM, Vol. 35,No. 9, September 1992.

Cohén, Sholom; Friedman, Seymour; Lorraine, Martin; Royer, Tom; Solderisch,Nancy; Webster, Robert. "Concept of operations for the ESC product line

108

[Czarnecki 99]

[Dean 95]

[Garlan 96]

[Garlan 98]

[Holibaugh 92]

[HP 93]

[Illingworth 90]

[Inprise 96]

[Inprise 98]

[Jacobson 97]

[Kang 90]

[Karlsson 95]

[Kellen 96]

[Martin 93]

[Mcllroy 69]

approach" (CMU/SEI-96-TR-018). Carnegie Mellon University, SoftwareEngineering Institute, 1996.

Czarnecki, K.; Eisenecker, U. "Synthesizing objects". In proceedings ofECOOP'99 Object-Oriented Programming, LNCS, Spnnger- Verlag, 1999.URL: http://nero.prakinf.tu-ilmenau.de/^czar/ocoop99

Dean, Thomas R.; James R. Cordy. "A Syntactic Theory of SoftwareArchitecture". IEEE Transactions on Software Engineering, Vol. 21, No. 4, April1995.

Garlan, David; Shaw, Mary. "Software Architecture. Perspective on an emergingdiscipline". Prentice-Hall, 1996.

Garlan, David; Kazman, Rick. "Architectures for software systems. Course -Intro Part I". Carnegie Mellon University, 1998.

Holibaugh, R. "Joda method". Software Engineering Institute, Carnegie MellonUniversity, 1992.

Hewlett-Packard Laboratories. "Company presentation on systematic softwarereuse". Hewlett-Packard Laboratories, 1993.

Illingworth, Valerie; Glaser, Edward; et al. "Dictionary of computing". OxfordUniversity Press. 1990.

Inprise Corporation. "Component Writer's Guide for Delphi". InpriseCorporation. 1996.

Inprise Corporation. "User's Guide. Delphi for Windows 95/NT. Versión 4".Inprise Corporation. 1998.

Jacobson, Ivar; Griss, Martin; Jonsson, Patrick. "Software reuse. Architectureprocess and organization for business success". Addison-Wesley, 1997.

Kang, Kyo; Cohén, Sholom; Hess, James; Novak, William; Peterson, Spencer."Featured-oriented domain analysis feasibility study". Software EngineeringInstitute, Carnegie Mellon University. 1990.

Karlsson, Even-André. "Software reuse. A holistic approach". John Wiley &Sons. 1995.

Kellen, Vince; Todd, Bill. "Delphi 2: A Developer's Guide". M&T Books. 1996.

Martin, James; Odell, James. "Principies of Object-oriented analysis and design".Prentice-Hall, 1993.

Mcllroy, D. "Mass produced software components". NATO Conf. on SoftwareEngineering. 1969.

109

[Pressman 93]

[Radding 98]

[Rumbaugh91]

[Shlaer 88]

[Smaragdakis 98]

[Sodhi 99]

[Solderitsch 96]

[Teixeira 98]

[Umar 97]

[U.S.DOD 94]

[Weiss 99]

Sitios en Internet:

Pressman, Roger S. "Ingeniería de software, un enfoque práctico". 3a. Edición.McGraw-Hill. 1993.

Radding, Alan. "Hidden Costs of Code Reuse". InformationWeek. Nov 1998.

Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick;Lorensen, William. "Object-oriented modeling and design". Prentice-Hall, 1991.

Shlaer, Sally; Mellor, Stephen J. "Object-oriented systems analysis. Modelling theworld in Data". Prentice-Hall, 1988.

Smaragdakis, Yannis; Batory, Don. "Implementing layered designs with mixinslayers". 12th European conference on object-oriented programming, (ECOOP 98).

Sodhi, Jag; Sodhi, Prince. "Software reuse. Domain analysis and design".McGraw-Hill, 1999.

Solderitsch, N. "Product Line Asset Support Concept of Operations" (STARS-VC-K017R1/001/00). Loral Systems-East, 1996.

Teixiera, Steve; Pacheco, Xavier. "Delphi 4 Developer's Guide". SamsPublishing. 1998.

Umar, Amjad. "Object-Oriented Client/Server Internet Environments". Prentice-Hall. 1997.

U.S. Department of Defense. "Proceedings of software technology conference".U.S. Air Forcé Software Technology Support Center, 1994.

Weíss, David M.; Lai, Chi Tau Robert. "Software Product-Line Engineering. AFamily-Based Software Development Process". Addison-Wesley Longman, Inc.1999.

Carnegie Mellon University, Software Engineering Institute, 1998.Origins of Software Architecture Study. http://www.sei.cmu.edu/architecture/roots.htmlThe Product Line Practice Iniatiative. http://www.sei.cmu.edu/plp/plp-init.html

Otras fuentes de información.

- UCREDI S.A. de C.V.Hidaldo 940, Col. El mirador. Monterrey, Nuevo León.

- UCREM S.A. de C.V.Padre Mier 249 Poniente, Col. Centro. Monterrey, Nuevo León.Unión de Crédito Agroindustrial y Comercial de Tizayuca S.A. de C.V.Poniente 6, entre Sur 6 y Sur 5, Cuenca Lechera. Tizayuca, Hidalgo.Unión de Crédito Promotora para el Desarrollo Económico del Edo. de Méx. S.A. de C.V.Pino Suárez 404-BIS, Col. Centro. Toluca, Edo. de México.

110