IMPLANTACIÓN DE LINEAS DE PRODUCTOS DE SOFTWARE MEDIANTE HERRAMIENTAS COMERCIALES
T E S I S
MAESTRÍA EN CIENCIAS
ESPECIALIDAD EN TECNOLOGÍA INFORMÁTICA
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
CAMPUS MONTERREY
DIVISIÓN DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES
CÉSAR FREDY LUCAS GONZÁLEZ
PORJULIO DE 2000
Dedico esta tesis a mis papás, con quienes siempre estaré 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 y ayuda 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 su disposició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 de Crédito de Monterrey: UCREDI y UCREM, por su colaboración e información proporcionada.
Resumen.
Una arquitectura de software para líneas de productos es un modelo de diseño, utilizado para producir una línea de productos de software (aplicaciones que tienen aspectos comunes y variaciones pronosticadas). Esta arquitectura es desarrollada de tal manera que explote el conjunto de características comunes y las variaciones presentes en los productos de la línea, por medio de componentes de software reutilizables, con un enfoque que rompe el tradicional concepto de desarrollo de proyectos para un solo producto. A esta propuesta de desarrollo de software 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 de generación que de elaboración; la actividad predominante es la integración en lugar de la programació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 productos como un todo.
Desarrollar líneas de productos involucra seguir un método de análisis y diseño para obtener la arquitectura, y una vez obtenida seguir una técnica de implementación. Esta investigación propone un método de análisis y diseño para la línea de sistemas de contabilidad para Uniones de cré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, pero pocos están orientados a facilitar la implementación. Principalmente se centran en la determinación de las variaciones y semejanzas. El método propuesto tiene como resultado la obtención de arquitecturas de software por niveles, en donde cada nivel corresponde a un componente reutilizable.
La principal técnica de implementación de arquitecturas de software es por medio de herencia parametrizada, característica presente en lenguajes como CLOS, C++ y otros. Pero, la mayoría de los ambientes comerciales de desarrollo no la presentan. La técnica de implementación propuesta, sustituye la herencia parametrizada por delegación, y hace uso de referencias circulares 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 simplificar el proceso de producción, genera automáticamente diferentes sistemas de contabilidad. Un generador de aplicaciones para una línea de productos, tiene características propias que lo hacen diferente a los generadores tradicionales, como analizadores semánticos para reglas de diseño y generación de diversos tipos de componentes.
Índice general
Reconocimientos v
Resumen vi
Índice de figuras x
Índice de tablas xi
Capítulo 1 Introducción
1.1 El desarrollo de software 1
1.2 Objetivo de la tesis 3
1.3 Estructura del documento de la tesis 3
Capítulo 2 Marco de referencia
2.1 La motivación para el reuso 4
2.2 Beneficios 5
2.3 Componentes 6
2.4 Obstáculos para el desarrollo de componentes 6
2.5 Clasificación de los métodos de reuso 7
2.6 Arquitecturas de software 9
2.7 Arquitecturas de software líneas de productos 10
2.8 Ingeniería de dominios 12
Capítulo 3 Método de análisis y diseño para la línea de sistemas
3.1 Los métodos actuales 14
3.2 Método ADLIS 16
3.2.1 Fase de Análisis 16
3.2.1.1 Definición del dominio de aplicaciones 16
3.2.1.2 Análisis de contexto 17
3.2.1.3 Descripción de las aplicaciones y definición de requerimientos 17 3.2.1.4 Análisis de requerimientos entre productos 17
3.2.1.5 Análisis de características 17
3.2.1.6 Definición del patrón de diseño 18
3.2.2 Fase de Diseño 18
3.2.2.1 Diagramas de flujo de datos 18
3.2.2.2 Modelo operacional 19
3.2.2.3 Registro de colaboraciones 20
3.2.2.4 Componentes complementarios 21
Capítulo 4 Aplicación del método ADLIS
4.1 Fase de Análisis 22
4.1.1 Definición del dominio de aplicaciones 22
4.1.2 Análisis de contexto 24
4.1.3 Descripción de la aplicación y definición de requerimientos 25
4.1.4 Análisis de requerimientos entre productos 27
4.1.5 Análisis de características 28
4.1.6 Definición del patrón de diseño 28
4.2 Fase de Diseño 30
4.2.1 Diagramas de flujo de datos 31
4.2.2 Colaboración 31
4.2.3 Registro de operaciones 34
4.2.4 Componentes complementarios 38
Capítulo 5 Implementación
5.1 Arquitectura por niveles y gramática GenVoca 40
5.2 Estrategia de implementación de componentes 43
5.2.1 Características de Delphi 44
5.3 Implementación de componentes en Delphi 45
5.3.1 Componente tipo Inicial 50
5.3.2 Componente tipo Final 50
5.3.3 Componente tipo Globales 51
5.3.4 Componente tipo Procedimiento 52
5.3.5 Componente tipo Decorador 53
5.3.6 Componente tipo Función 54
5.3.7 Componente tipo Procedimiento-función 56
Capítulo 6 Generador
6.1 Introducción 59
6.2 Análisis semántico 60
6.3 Clase generadora 61
6.4 Ensamble con la pantalla al usuario 65
6.5 Construcción de aplicaciones 65
6.6 Resultados 67
Capítulo 7 Conclusiones
7.1 Conclusiones 70
7.2 Alcance de la tesis 71
7.3 Trabajos futuros 72
Apéndice A Código del generador de aplicaciones y componentes
A.l Descripción 73
A.2 Unidades del generador de aplicaciones 74
A.3 Ejemplos de componentes 83
Apéndice B Planes de Misión XXI
B.l Sumario 87
B,.2 Plan técnico 91
B.3 Plan de negocios 98
Referencias 108
VITA 111
Índice de figuras.
1.1 Producción en una línea de productos 2
2.1 Ejes de clasificación de los métodos de reuso 8
2.2 Diapositiva de la materia: Arquitecturas para sistemas de software 9
2.3 Procesamiento de datos clásico 10
3.1 Ciclo de vida de ADLIS 15
4.1 Modelo de contexto del sistema de contabilidad 24
4.2 Diagrama de características 29
4.3 Patrón para el diseño 30
4.4 Diagrama de flujo de datos del reporte Saldos 32
4.5 Colaboración del reporte Saldos 33
4.6 Definición de tipos a las operaciones del reporte Saldos 34 4.7 Colaboración del reporte Saldos con su estructura final 39
5.1 Esquema de las unidades 45
5.2 Estructura general 46
5.3 Componente_X[Componente_Y[Componente_Z[...]]] 48
5.4 Estructura general con parámetros formales 49
5.5 Componente tipo inicial 50
5.6 Componente tipo final 50
5.7 Componente tipo globales 51
5.8 Componente tipo procedimiento 52
5.9 Componente tipo decorador 53
5.10 Componente tipo función 54
5.11 Componente tipo procedimiento - función 56
6.1 Arreglos: Componente, Requiere, y Max veces 60
6.2 Clase generadora 62
6.3 Representación de la Unidad generadora como un bus de comunicaciones 64 6.4 Generador de aplicaciones para la Línea de Sistemas de Contabilidad de Uniones 66
6.5 Directorios utilizados para organizar el código 66
6.6 Ejemplo de un sistema de contabilidad para una Unión de crédito industrial 68 6.7 Ejemplo de un sistema de contabilidad para una Unión de crédito agropecuaria 68 6.8 Ejemplo para producir un sistema de contabilidad personalizado 69
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 comunidad involucrada en la ingeniería en sistemas computacionales ha tratado de dar soluciones a un problema en particular de los sistemas computacionales, el desarrollo de software. No por el hecho mismo, que el desarrollo de software sea un problema, sino por las necesidades o demandas actuales del mercado del software.
El fin último o propósito del desarrollo de software es obtener una aplicación, un programa computacional que nos dé un resultado útil a nuestros propósitos; esta aplicación puede considerarse como "el producto", y el medio de producción son los métodos y herramientas para el desarrollo de software. Existen productos de muy diversos tipos, pero en particular nos centraremos en aquellos que involucran mucho tiempo en su desarrollo, bastantes recursos o son utilizados para situaciones críticas, estos productos pueden clasificarse como sistemas complejos y son a los que se hará referencia.
Para obtener un producto de software se sigue un método basado en un ciclo de desarrollo que generalmente tiene las etapas de: análisis, diseño, codificación, prueba y mantenimiento; existen otros ciclos que varían en cuanto a la definición de otras etapas o en la forma de repetir las etapas, pero todos con un objetivo en común, la obtención de un producto de software de alta calidad. Estos métodos han dado muy buenos resultados pero sólo se enfocan a la producción de un solo sistema. Su perspectiva es la de producir un solo producto. Como ejemplos de estos mé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étodos tradicionales de software. Como sucede con el software para mercados verticales, en donde se tienen que producir aplicaciones que tienen aspectos comunes y variaciones pronosticadas (a este tipo de aplicaciones en conjunto se les denomina familia de sistemas). Actualmente existe una ausencia de métodos que nos lleven a la obtención de varias aplicaciones de una familia de sistemas, en un mismo ciclo de desarrollo [Czarnecki 99].
Por las formas de producción tradicionales de software, existen otras comunidades que han calificado al proceso de desarrollo de software más como una actividad artesanal, en lugar de ser una técnica, propia de una ingeniería, dado que otras ingenierías han logrado un nivel de industrialización o automatización para la producción de diversos productos, con un menor grado de participación humana.
Si bien las formas actuales de producción de software han dado buenos resultados, no tenemos por qué estar sujetos a estas formas tradicionales, que por su naturaleza no pueden ser aplicadas en todas las situaciones que se nos presenten, y por consiguiente no deben ser consideradas como las mejores soluciones para el desarrollo de aplicaciones con aspectos comunes y variaciones pronosticadas.
Una de las nuevas propuestas de desarrollo de software que han surgido, se le ha denominado líneas de productos de software [Bronsword 96], la cual se basa en el desarrollo de una arquitectura de software (estructura o forma de organización del código) [Garlan 96] que facilite la construcción de aplicaciones de una familia de sistemas, de manera análoga a una línea de producción industrial (línea automatizada). La propuesta de arquitectura de software para líneas de productos no define la estrategia a seguir, tampoco si debe utilizarse el paradigma de objetos o el 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 utilizando mecanismos avanzados (tales como, templates de C++), dejando sin explorar las posibilidades que presentan otros ambientes de uso comercial (Delphi, Visual Basic, etc.), los cuales tienen las características básicas que permiten la implementación de arquitecturas por medio del paradigma de objetos. Tales ambientes a diferencia de otros lenguajes, son herramientas de desarrollo más rápidas y enfocadas al desarrollo de sistemas.
La implementación de una arquitectura no es sólo un asunto de programar clases y tratar de reusar por medio de la herencia, polimorfismo y encapsulación en sus formas tradicionales. Se necesita una estrategia para la implementación de aplicaciones por medio de una línea de productos. Varias estrategias se han propuesto para su implementación en los lenguajes especializados; pero actualmente se desconoce una estrategia para su implementación en ambientes comerciales.
La elaboración de las aplicaciones en la propuesta de líneas de productos de software es realizada por 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 la arquitectura de software para línea de productos), los requeridos para producir el código de uno de los varios productos. La Figura 1.1 representa la secuencia de producción de las aplicaciones.
HA- A Arquitectura de software
para una linea de productos Componentes imple me ruados
Productos Figura 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, la
1.2 Objetivo de la tesis.
Explorar la viabilidad del desarrollo de Arquitecturas de software para líneas de productos y su implementación por medio de una herramienta comercial, como una solución alternativa al desarrollo de aplicaciones para mercados verticales. Describiendo un método para su construcción, incluyendo las etapas de su ciclo de vida y los aspectos técnicos para su implementació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 bases teó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 software para 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 de soluciones 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 involucrados para su desarrollo.
Segunda parte:
• Método ADLIS. Descripción de deficiencias de los métodos actuales de análisis y diseño orientados a objetos. Propuesta de un método para el análisis y diseño de arquitecturas de software para sistemas de contabilidad de Uniones de crédito. El método posee etapas a seguir para el análisis y diseño, del apego a estas etapas dependerá la facilidad de implementació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 la implementación de arquitecturas por niveles en Delphi, y formas de implementación de los 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 de sistemas es el enfoque de líneas de productos de software. Este enfoque está ubicado en el área del reuso de software. El reuso de software es considerado como una de las más importantes soluciones a los problemas del desarrollo de software, debido a varios beneficios que ofrece. En este capítulo se describe la teoría que fundamenta el desarrollo de software basado en líneas de productos. Inicia con la descripción de la necesidad del reuso, sus beneficios y la definición de componentes reusables. Posteriormente es definido el enfoque de líneas de productos dentro del contexto de reuso de software, y finaliza con la explicación de los conceptos de arquitecturas de software 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 un elemento indispensable del mundo moderno. El ciberespacio depende del software, así como bancos, centros comerciales, industrias, laboratorios de investigación, escuelas y otras organizaciones de nuestra sociedad. El software, además de ser una herramienta de apoyo en las actividades de los individuos, se ha convertido en un elemento más de competitividad entre las empresas. Si bien algunas empresas desean software rápido y confiable para tener una mejor posición competitiva, otras en cambio no podrían operar sin éste.
Desafortunadamente, existen problemas que afligen al desarrollo del software. Estos se pueden dividir bajo muchas perspectivas, pero los responsables de los desarrollos de software se centran sobre los aspectos de "fondo": (1) la planificación y estimación de costos son frecuentemente imprecisas, (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 los costos. Dos alternativas de solución se han propuesto para lograr esas metas. Una se ha enfocado a la mejora en la eficiencia de los procesos de desarrollo, y la otra propone el reuso de software en mayores proporciones [Jacobson 97].
La primera alternativa tiene como objetivo incrementar la eficiencia de la organización que produce el software. La mejora se centra en la "productividad del proceso", el cual es un concepto 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 el proceso, y la mejora consiste en superarlas constantemente.
La segunda alternativa es el reuso. La definición de reuso sistemático de código es [Mcllroy
extendió lo idea de "sistemas de componentes" más allá de únicamente el código, a requerimientos, modelos de análisis, diseño, y pruebas. Todas las etapas del proceso de desarrollo 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 significativos en costos y tiempo.
Iniciando con experimentos en 1984, Hewlett-Packard en el transcurso de diez años logró niveles de reuso del 25 al 50% enfirmware para instrumentos e impresoras. Una línea de instrumentos alcanzó un 83%. Algunas organizaciones han obtenido niveles de reuso de alrededor del 90% en determinados 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 de reuso de software, la administración de una empresa desarrolladora de software puede esperar ganancias 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 y el 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 único que 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 construir aplicaciones personalizadas y baratas [Umar 97]. Los componentes reducen el costo y la complejidad 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 un conjunto de tareas limitadas dentro de una aplicación. Por ejemplo, Microsoft Draw es un componente dentro de las aplicaciones Microsoft. Este componente en particular es de alto nivel ya que realiza funciones tipo usuario-final (dibuja cajas, flechas, círculos, etc.). Sin embargo, no es una aplicación aislada, ésta solamente trabaja con otros componentes de aplicaciones [Umar 97]. Los componentes son usados como elementos "plug and play" para construir aplicaciones completas.
Una de las características importantes de un componente de software de alta calidad es la reusabilidad. El componente debe diseñarse e implementarse para que pueda volver a usarse en muchos programas diferentes. En los setenta se construyeron bibliotecas de subrutinas científicas y de ingeniería. Esas bibliotecas de subrutinas reutilizaban de forma efectiva algoritmos bien definidos [Pressman 92]. Hoy en día, se ha extendido la visión de componentes para abarcar no sólo algoritmos, sino también estructuras de datos. Un componente encapsula tanto 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 chips reutilizables, y de cómo esto puede multiplicar el poder de invención en toda esta industria (sólo basta ver las novedades electrónicas que aparecen constantemente). A pesar de los beneficios prometedores que puede traer el desarrollar software a partir de componentes, esto no es tan fácil de lograr.
Dada la gran cantidad de información que existe sobre tecnologías de software, muchas empresas han comenzado a desarrollar utilizando enfoques orientados a componentes, considerando que los componentes son objetos. Un estudio del grupo de información Cutter Information Group
de los objetos. Pero el hecho de utilizar programación orientada a objetos, no garantiza el reuso del software, se involucran varios aspectos para lograrlo, basta decir que existen varios tipos de componentes reusables con diferentes beneficios [Radding 98]:
• Objetos GUI reusables, reducen el tiempo de desarrollo y mejoran la calidad y consistencia pero proveen solamente un modesto beneficio en términos de todo el costo de desarrollo de la aplicación.
• Componentes server-side, constituyen lógica de negocios reutilizable que pueden proveer un beneficio significativo pero requieren mucho análisis y diseño de antemano. También requieren una base arquitectónica (modelo de diseño).
• Componentes de infraestructura y frameworks de servicios son servicios genéricos para transacciones, mensajes, seguridad y conectividad de bases de datos. Eliminan la necesidad de construir repetidamente infraestructura que todas las aplicaciones usan, pero requieren mucho análisis, diseño y programación compleja. Están basados en estándares y pueden ser comprados.
• Patrones de alto nivel permiten a las organizaciones lograr reuso del diseño e identificar componentes con alto potencial de reuso, pero los desarrolladores deben construir o adquirir esos componentes.
• Aplicaciones empacadas permiten a las compañías adquirir funcionalidad con una complejidad menor al de construirlas por ellas mismas. Sin embargo, estas aplicaciones no 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, es improbable que sin una arquitectura los componentes trabajen para la siguiente aplicación. Al menos las organizaciones necesitarán de una arquitectura de sistemas, una arquitectura de dominio de negocios y una infraestructura para su implementación [Radding 98].
Sin una arquitectura, las organizaciones no serán capaces de construir o comprar componentes reusables que sean consistentes.
Tecnologías de software basadas en componentes como ActiveX, OLE, Appleís de Java, IDL de CORBA, sugieren el desarrollo de componentes, pero no presentan una estrategia para el desarrollo de aplicaciones por medio del reuso de componentes, no proponen un desarrollo a nivel sistema; esas tecnologías definen y controlan interfaces de componentes de manera independiente 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 del reuso, el destino del reuso y lo granular de los componentes. El alcance del reuso tiene tres diferentes 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 los componentes de propósito general como funciones matemáticas y paquetes para interfaces a usuarios. También denominado como reuso horizontal. El comportamiento de los componentes es común en varios dominios.
• Reuso de dominios constituye el reuso dentro de un dominio de aplicaciones. Por ejemplo, en el dominio de las telecomunicaciones, un subsistema de administración de desempeño. En este caso, el subsistema es estandarizado dentro del dominio, y como componente 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, de forma análoga a una línea de producción industrial. La semántica de los componentes está limitada al tipo de aplicaciones. Una línea de productos requiere de una arquitectura gené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 para reusar 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 sus servicios 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 como las funciones para acceso a bases de datos, funciones para manipulación de estructuras de datos 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 los subsistemas 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 en base 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 by picking out parts and plugging them togcther, just like Tinkertoys „.."
• The hard cold truth:
H's more like having a bathtub fuü of Tinkertoy, Lego, Erector setf Lincoln logs, Bloek Cily, and six other iricontpatíl»ie kit* — picking o«t parts that fit specific fujudions and expectíng theoi to ñ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 los sistemas son construidos, las interacciones entre estos elementos, patrones que guían su composición y restricciones de esos patrones [Garlan 96]. La arquitectura de un sistema de software:
• Define al sistema en términos de elementos o componentes computacionales y las interacciones entre estos.
• Muestra la correspondencia entre los requerimientos y los elementos del sistema construido.
• Define las propiedades (escala, capacidad, flujo, consistencia, compatibilidad) a nivel sistema. 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 como clientes, servidores, tablas, procedimientos, y las interacciones entre estos componentes se realiza por medio de llamadas a procedimientos y acceso a variables. Las propiedades dependerán de las 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 el batch - 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 |~—fl 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 un programa, dada la secuencia de procesos mostrada. El desarrollar por medio de los componentes de una arquitectura de software, brinda otras posibilidades diferentes a las de un programa, estas diferencias se muestran en la Tabla 2.1 [Garlan 98].
Arquitectura Interacciones entre partes Propiedades estructurales Declarativo
En su mayor parte es estática Desempeño a nivel sistema Fuera del límite modular
Programa Implementación de partes Propiedades computacionales Operacional
En su mayor parte es dinámica Desempeño algorítmico Dentro 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 software especializada, que de forma similar a una línea de producción de una industria, produce una línea de productos de software (aplicaciones). Esta arquitectura es elaborada de tal manera que explote un conjunto de características en común, por medio de componentes de software reutilizables.
El enfoque de arquitecturas de software para líneas de productos consiste en el uso de una arquitectura de software con el propósito de construir múltiples aplicaciones en un dominio
[Batory 98]. Las arquitecturas de software han estado implícitamente en los sistemas de software, generalmente dividendo los programas en módulos, definiendo las interacciones entre los 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 y variaciones pronosticadas es una familia de productos. Una familia de productos no necesita constituir una línea de productos necesariamente, dado que se puede construir los miembros de una familia de sistemas de forma individual. Pero, construir una familia de sistemas como una línea de productos aprovecha y amortiza inversiones anteriores al máximo grado posible. La suma del costo de construcción de una línea de productos, llega a ser mucho menor que la suma del costo de construcción de sistemas individuales. Producir un nuevo sistema llega a ser menor en materia de elaboración, que uno desarrollado o modificado (de un sistema anterior, o de una versión genérica de un miembro "prototipo" de una familia). Las incertidumbres asociadas con la construcción de un sistema sin precedentes son nulificadas, o al menos aisladas, por el método de líneas de productos, pues los problemas generalmente ya han sido encontrados y resueltos por anteriores miembros de la familia [Bronsword 96].
Una línea de productos es una familia de sistemas diseñada (arquitectura de software) para tomar ventaja 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 de construcción que de elaboración; la actividad predominante es la integración en lugar de la programació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 productos como un todo [Solderitsch 96].
Una línea de productos enfatiza el reuso, a veces en formas que no son muy evidentes. Los aspectos 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. Los componentes son diseñados para reusarlos, el concepto de reuso del código es aplicado a lo largo y ancho del desarrollo, este esfuerzo (frecuentemente difícil) es considerado una inversión. Los diseños de componentes exitosos son capturados y reusados. Este proceso también incluye el diseño de las interfaces de los componentes, su documentación, sus planes de prueba y procedimientos, y algunos modelos (tal como modelos de desempeño) usados para predecir su comportamiento.
• Personal: debido a la generalidad de las aplicaciones, el personal puede ser transferido entre proyectos dependiendo de como se requiera. Esta experiencia es aplicable en toda la línea de productos.
• Eliminación de defectos: ya que los errores son eliminados en un componente de un producto, incrementando la calidad de los componentes corregidos y de todos los otros productos, esto genera confianza y la calidad se incrementa.
• Experiencia en la planeación de proyectos: porque la experiencia obtenida es un indicador de alta fiabilidad en el desempeño, presupuesto y calendarización; haciendo a estos tres aspectos más predecibles.
• Análisis de desempeño: Modelos de desempeño, análisis de planeación, características de sistemas distribuidos (tal como, ausencia de deadlocks), asignación de procesos a procesadores, esquemas de tolerancia de fallas y políticas de redes, pueden ser transferidas de producto a producto.
• Procesos, métodos y herramientas: procedimientos de control de configuración, planes de documentación y procesos aprobados, herramientas y otras actividades de soporte para el desarrollo que se realicen, pueden ser transferidas de producto a producto.
• Sistemas de muestra: Productos desarrollados sirven como prototipos de demostración de alta calidad. La satisfacción del cliente se incrementa (y el riesgo disminuye). Los productos 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 de miembros en la línea de productos, tienen un diseño para el cambio, nos dan una ventaja competitiva en el mercado con respecto al tipo de aplicaciones, la inversión económica en la producció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 la literatura, muestran que no existe una práctica estándar para la obtención de una arquitectura de software para líneas de productos, pues en cada proyecto utilizaron diferentes métodos. Aunque no existe una práctica estándar, los aspectos técnicos para realizar el reuso de software están bien establecidos, definiendo que en el proceso de obtención de la arquitectura deben considerarse los siguientes elementos [Bronsword 96]:
• Análisis de dominio: producir un modelo de dominio de una línea de productos que identifique cuales son las generalidades de todos los miembros, e identificar las formas en las cuales pueden variar de uno a otro.
• Metodología de diseño a partir de un diseño basado en componentes: aplicando los principios de separación de concerns (intereses), el ocultamiento de la información para identificar los componentes que la arquitectura comprende, y asignar roles y responsabilidades a cada uno; cada componente diseñado tendrá una interface que provea los servicios al sistema, de una forma independiente a la implementación.
• Arquitectura de referencia: adoptar una infraestructura estándar (esqueleto) que se aplique 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ún momento 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 de reuso. Desarrollar por medio de reuso considera para la construcción de una aplicación, la
existencia de los componentes, los cuales pudieron haber sido comprados o desarrollados con anterioridad; a partir de los componentes es que se realiza un análisis y diseño para obtener la aplicación. Desarrollar para reusar tiene el propósito de diseñar los componentes reusables y posteriormente realizar su implementación, también puede considerarse el desarrollo de un generador de aplicaciones para simplificar la construcción de las aplicaciones.
La comunidad ha establecido que desarrollar para reusar sea denominado Ingeniería de Dominios, y desarrollar por medio de reuso, Ingeniería de Aplicaciones.
Los objetivos de la ingeniería de dominios son identificar, derivar, organizar, abstraer y representar las similitudes y diferencias entre las características de un dominio de aplicaciones en particular. Esto facilitará la reusabilidad en los productos.
Ingeniería de dominios se define como [Sodhi 99]: un proceso para construir un elemento que pueda ser administrado y reusado. Las etapas que la comprenden son:
• Análisis del dominio: es el proceso de descubrir aspectos comunes y diferentes en varios sistemas que estén relacionados, limitar con cuidado el dominio, organizar y entender las relaciones 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 de características. El alcance del dominio determina qué sistemas y características corresponden al dominio y cuáles no. La modelación de características identifica las características variables y comunes de los conceptos del dominio y las dependencias entre las características variables [Czarnecki 99].
• Diseño del dominio: Su propósito es desarrollar una arquitectura común para la familia de 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 al usuario, menús, etc.).
La secuencia de etapas de la Ingeniería de dominios, constituyen un marco importante, pero se requiere de un método de análisis, diseño, e implementación para el desarrollo de una línea de productos de un dominio en particular. De acuerdo con la clasificación de [Karlsson 95], el método propuesto en la tesis, está ubicado en el de línea de productos, desarrollado para un método interno, y con componentes extensos. Para la clasificación de componentes de [Radding 96], los componentes son del tipo server-side. El método propuesto aplica el enfoque de ingenierí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, el cual comprende a las etapas de análisis y diseño de la Ingeniería de dominios; los productos resultantes del método son: modelo de dominio, arquitectura de software para la línea de productos y componentes reusables.
La etapa de implementación de la línea de productos, es mostrada en los Capítulos 5 y 6. El Capítulo 5 describe una técnica de implementación de componentes, y el Capítulo 6 las características de un generador de aplicaciones.
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 seguir para su obtención, tampoco si debe utilizarse el paradigma de objetos o el estructurado para su codificación, pero con su teoría establece los conceptos y propósito. El desarrollo de una arquitectura de software para una línea de productos comprende etapas parecidas a las del ciclo de vida clásico pero con alcances diferentes. Con base a la teoría y definiciones de ingeniería de dominios y de arquitecturas de software, en este capítulo se propone un método para el análisis y diseño de familia de sistemas. El capítulo inicia describiendo las deficiencias de los métodos de análisis y diseño orientado a objetos, razón por la cuál no se utilizó un método de este tipo para el desarrollo 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 ha definido [Czarnecki 99]. En cambio, existe actualmente una gran variedad de métodos de análisis y diseño de dominios; la mayoría de estos orientadas a objetos (00), dado los beneficios que brinda este tipo de programación [Rumbaugh 91] [Shlaer 88] [Booch 94] [Coad 90] [Martin 93].
Pero, la mayoría de los métodos de análisis y diseño 0 0 también se enfocan en el desarrollo de un solo sistema, en lugar de producir una línea de sistemas. Además, no soportan de forma adecuada el reuso de software. Específicamente, tienen las siguientes deficiencias [Czarnecki 99][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 el desarrollo por medio de reuso. El propósito del desarrollo para reuso no es sólo un sistema, sino una línea de sistemas. Esto permite la producción de componentes reusables. El proceso del desarrollo por medio de reuso ha sido diseñado para utilizar los elementos reusables producidos durante el desarrollo para reusar. Los actuales procesos de 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 y diseño 0 0 se enfocan al proceso de un solo sistema, estos carecen de una fase de alcance del dominio, en donde la clase (tipo) de sistemas sea seleccionada. También, el análisis y diseño 0 0 se enfoca en satisfacer "al cliente" de un solo sistema, en lugar de analizar y satisfacer los requerimientos de una clase de sistemas.
• Ningún mecanismo de diferenciación para modelar variabilidad entre una aplicación y entre varias aplicaciones: las actuales notaciones OO no hacen diferenciación entre la variabilidad que exista dentro de la aplicación, por ejemplo, la variabilidad de los objetos en el tiempo y el uso de diferentes variantes de un objeto en diferentes situaciones en una
aplicación; y en caso de la variabilidad entre aplicaciones, no existe diferenciación de variabilidad entre diferentes aplicaciones para diferentes usuarios y contextos de uso.
Además, los mecanismos de implementación para codificar la variabilidad entre aplicaciones, como el polimorfismo dinámico, da como resultado frameworks o componentes grandes y por consiguiente aplicaciones grandes.
Ninguna notación para modelar la variabilidad que sea independiente de la implementación: además de que las actuales notaciones 0 0 no permiten modelar la variabilidad de una forma independiente a la implementación, por ejemplo, cuando se dibuja 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 para representar un punto de variación dado.
En la literatura, el marco teórico de los métodos que corresponden a la Ingeniería de dominios como 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 para la obtención de los elementos comunes entre aplicaciones relacionadas. Estos métodos son productos comerciales de alto costo.
Para el desarrollo de la arquitectura de software para la línea de productos proponemos la definición de un propio método. El método propuesto (ADLIS, descrito en la sección 3.2) se fundamenta en varias técnicas (Foda, casos de uso, arquitecturas por niveles) tomando lo más adecuado de ellas, con el propósito de obtener modelos arquitectónicos aptos para la producción de familias de sistemas.
Análisis del dominio Diseño del dominio Implementación del dominio
Análisis
del dominio modelo del dominio
Desarrollo de la Arquitectura de
software
arquitectura de software para líneas de productos
Desarrollo de los componentes
reusables y Generador
Proceso Producto
Figura 3.1 Ciclo de vida de ADLIS.
componentes reusables y
generador
Desarrollo de la aplicación por
medio del Generador
El desarrollo de una línea de productos por medio de ADLIS comprende etapas parecidas a las del 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 el alcance, analizar el espacio del problema y definir el espacio de la solución (modelo del dominio).
• Diseño del dominio o modelación arquitectónica, es un proceso cuyo objetivo es dar una representación de la estructura modular que conformará la arquitectura de software. La arquitectura de software para líneas de productos define módulos que serán componentes reusables. Por medio de este proceso se estructura y captura la información relevante para 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 derivados del diseño, así como el desarrollo de un generador de aplicaciones que produzca los diferentes productos. De acuerdo a los requerimientos del cliente, al generador se le indican las características del producto deseado, para de esta forma obtener una aplicació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 componentes genéricos y específicos de un dominio de aplicaciones. Estos componentes genéricos abstraen la funcionalidad y el diseño de las aplicaciones. La naturaleza genérica de los componentes es creada abstrayendo "factores" que hacen una aplicación semejante de otras aplicaciones en un dominio particular. ADLIS es aplicado para el desarrollo de una familia de sistemas de contabilidad 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 los sistemas del dominio para descubrir y explotar las características semejantes. El análisis revela el conjunto de características que son comunes en una familia de sistemas y es representado de una forma que ayude al desarrollo e implementación de los productos. Como parte del análisis se 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 de un análisis, para determinar las justificaciones del desarrollo de una línea de productos. De este análisis depende el éxito o fracaso, ya que una línea de productos no debe aplicarse en todos los casos de desarrollo de software; el análisis previene de realizar inversiones cuantiosas. Entre los aspectos que debe contener el análisis están: definición de la familia de sistemas, definición del mercado y justificaciones.
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 el dominio y elementos externos (medios operativos, requerimientos de datos, etc.) son analizadas, así como las variaciones son evaluadas. Los resultados son documentados en un diagrama de contexto, el cual muestra las entidades externas y los flujos de datos entre el dominio y las entidades externas.
3.2.1.3 Descripción detallada de las aplicaciones y definición de requerimientos.
Durante esta etapa, es realizado un análisis de las aplicaciones y sus requerimientos. Los aspectos que debe contener son: definición de las aplicaciones (miembros de la familia de sistemas), determinar los requerimientos de las aplicaciones, determinar que requerimientos hacen diferentes a las aplicaciones, e identificar los requerimientos que no serán analizados por el mé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 por medio de una clasificación de los tipos de operaciones que realizan: 1) los requerimientos que realizan operaciones de mantenimiento de información, y 2) los requerimientos que realizan operaciones de reglas de negocio. Los requerimientos que involucran operaciones de mantenimiento de información (altas, bajas y modificaciones de datos) no son analizados, su implementació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 para identificar la variabilidad y semejanzas; el resultado del análisis es la definición de las caracterí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 un diagrama, y estos son clasificados por sus características. Las características describen el contexto del dominio de las aplicaciones, las operaciones necesarias y la representación de variaciones. Sus resultados son importantes porque el modelo de características generaliza y parametriza los modelos producidos. Las características se definen como alternativas, opcionales y principales. Las características principales representan las características base y sus relaciones. Las características alternativas u opcionales representan la especialización de características más generales, representan qué cambios muy probablemente ocurren en diferentes circunstancias.
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á de guía para el diseño de cada requerimiento. Su definición se debe al patrón de comportamiento que generalmente siguen las aplicaciones.
La identificación del patrón también debe apoyarse en un análisis previo con un pequeño grupo de diagramas de flujo de datos; primero se proponen etapas de procesamiento, posteriormente se comprueba que sean aplicables para todos los casos, y por último se establece un orden o secuencia.
Una vez definido el patrón de etapas de procesos, este es utilizado como un medio de estandarización en todos los diseños (diagramas de flujo de datos). Es decir, todos los procesos contenidos en un diseño estarán ordenados de acuerdo al patrón. Por otra parte, en el momento de realizar los diseños, los procesos pueden seguir esta secuencia de acciones, como una estrategia 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álisis operacional a estos. En el análisis operacional se identifican las características del comportamiento de los procesos de los diagramas de flujo de datos. Esta actividad produce funciones para posteriormente estructurarlas, dando una secuencia a dichas funciones en un modelo operacional denominado colaboración. El control y flujo de datos de una aplicación individual 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, esto permite identificar los procesos y los resultados. En la construcción de los DFD's se debe procurar:
• 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 derecho las 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 siguientes
• 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ón de 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. Se enfoca en la identificación de operaciones concurrentes y módulos comunes orientados al dominio. Define el orden y características de las operaciones. Hace uso de un registro de operaciones 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 los procesos resultantes de la tabla de clasificación (estos procesos a su vez son resultado del análisis operacional del DFD). Las etapas del patrón son utilizadas en la colaboración para ordenar las operaciones, 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 la asignación de los nombres a las operaciones. El nombre de una operación depende de la categoría donde se encuentra y su función en general. Los grupos de las operaciones también facilitan 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 un registro de las operaciones (Sección 3.2.2.3), a través del cual se identifica qué operaciones ya fueron definidas.
El orden que determina el patrón de diseño, no restringe la posibilidad de colocar una operación de la categoría Selección de información dentro de alguna de las otras; salvo esta excepción, la intención principal es seguir el orden del patrón de diseño.
El último paso en la etapa de la elaboración de la colaboración, es la aplicación de tres reglas para identificar los tipos de comportamiento de las operaciones:
• En los diagramas de flujo de datos, se localizan los procesos de cálculos que involucren operaciones para un determinado rango de información. Los enunciados que describen estos procesos son revisados para identificarles las preposiciones, y de esta forma asignar el tipo de comportamiento para la operación.
• En los diagramas de flujo de datos, se localizan los procesos que dan formatos de presentación de la información, por cada resultado diferente que den, le es asignado un tipo de comportamiento a su operación.
• A cada tipo de comportamiento identificado se le asigna un número consecutivo, al primer 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 las operaciones 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 lista denominada registro de operaciones. De igual forma, cada tipo de comportamiento identificado de alguna operación, es agregado al registro de operaciones como si se tratará de una operación má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 se identifican en el proceso del diseño y análisis operacional. Permite identificar si una nueva operación que se proponga, ya había sido definida. Su propósito principal es el de servir de referencia, para utilizar las operaciones ya definidas en las nuevas colaboraciones. Junto con las operaciones se registran sus diferentes tipos de comportamiento, únicamente por el número de tipo de comportamiento asignado.
Una tarea a realizar una vez obtenida la tabla de registro de operaciones, es identificar las operaciones que hacen las veces de funciones. La identificación también es con ayuda de los DFD's. Para estas operaciones se hace una clasificación:
a) Las operaciones que no tienen una participación directa en la secuencia principal de ejecució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 de ejecución de operaciones, su propósito principal es ser una etapa en la secuencia de la colaboración, pero para otras colaboraciones se utiliza como una función que apoya a otra operació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, en la que se muestra la nueva categoría, las operaciones que corresponden a cada categoría, y la asignación a cada operación de un tipo que determina su función en la colaboración.
A partir de este punto las operaciones son denominadas como componentes, dado que es el término técnico que se utiliza para su implementación. Para simplificar la utilización de los nombres de las operaciones en la implementación, éstas son renombradas por un nombre más corto.
3.2.2.4 Componentes complementarios.
Tres componentes se agregan al conjunto de los componentes ya identificados: Inicial, Final y Globales. Los componentes Inicial y Final tienen como propósito delimitar el inicio y final de la colaboración. No contienen algún código a ejecutar. El componente inicial es colocado al inicio de los componentes que correspondan a una colaboración, con el componente final ocurre lo mismo pero en la posición final.
Las variables globales identificadas en los análisis operacionales (Tabla 4.3) estarán contenidas en un componente denominado Globales.
Estos componentes junto con la categoría de Funciones, dan como resultado la estructura final de la colaboración. El propósito de tener un tipo de categoría como Funciones, es separar los componentes 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 la colaboración, pero por medio de una técnica en la codificación, cualquier componente puede acceder a sus variables contenidas.
Con esta última etapa termina la definición del método ADLIS, en el siguiente capítulo es mostrada la aplicación del método para una línea de sistemas de contabilidad.
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, se ha definido un método para el análisis y diseño de líneas de sistemas. La aplicación de ADLIS para el desarrollo de una arquitectura de software para una línea de productos comprende etapas parecidas a las del ciclo de vida clásico pero con alcances diferentes. El capítulo muestra la aplicación de ADLIS en la producción de una línea de sistemas de contabilidad para Uniones de cré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ón de los sistemas del dominio para descubrir y explotar las características y la definición de un patrón para el diseño. Con base al seguimiento del método ADLIS, las siguientes secciones describen 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 la arquitectura. El dominio de aplicaciones elegido, es el de Sistemas de Contabilidad para Uniones de Crédito, el cual consideraremos nuestra línea de productos. Los productos resultantes son 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 de Uniones 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, tomar préstamos, obtener servicios financieros relacionados y participar en su administración. Estas instituciones son parte del sector bancario y financiero de México, regidas por la Comisión Nacional Bancaria y de Valores (Gobierno de México). Su función es la de complementar el apoyo crediticio a la micro, pequeña, y mediana empresa, en condiciones más favorables que las instituciones bancarias de mayor tamaño (Bancomer, Banamex, etc.).
Generalmente las Uniones son formadas por personas del mismo giro o actividad, existen Uniones 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 de contabilidad, las características que presentan son las propias de los sistemas para una línea de productos:
