WIXLIB

INGENIERlA DEL SOFTWARE. UN ENFOQUE PRbCTICOy revisarse, las de objetos de datos deberían identificarse, se deberían estudiar las organizaciones alternativas de datos y debería evaluarse el impacto delmodelado de datos sobre el diseño del software. Porejemplo, la especificación de una lista enlazada conmúltiples anillos puede satisfacer los requisitos de losdatos pero puede llevar a un diseño del software pocoflexible. Una organización de datos alternativa nospodría llevar a obtener mejores resultados.Orientación por materia. Un almacén de datosestá organizado por las materias importantes delnegocio, más que por los procesos o funciones delnegocio. Esto nos lleva a una exclusión de datos quepodrían ser necesarios para una función particulardel negocio, pero que generalmente no son necesarios para la minería de datos.Integración. Sin tener en cuenta la fuente de datos,da consistencia nombrar convenciones, unidades ymedidas, estructuras de codificación y atributos físicos incluso cuando la inconsistencia existe a través delas diferentes bases de datos orientadas a aplicaciones.Restricciones de tiempo. Para un entorno de aplicación orientado a transacción, los datos son precisosen el momento del acceso y por un periodo de tiemporelativamente pequeño (normalmente de 60 a 90 días)antes del acceso. Sin embargo, en un almacén de datos,se accede a los datos en un momento específico deltiempo (por ejemplo, los clientes con los que se hacontactado el mismo día que el nuevo producto ha sidoanunciado en la prensa comercial). El horizonte típicode tiempo de un almacén de datos es de 5 a 10 años.No volatilidad. A diferencia de las típicas basesde datos de aplicaciones de negocios que atraviesanuna continua corriente de cambios (insertar, borrar,actualizar), en el almacén de datos los datos se cargan, pero después de la primera transferencia, losdatos no cambian.¿Qué principios son aplicablespara el diseño de datos?2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas. El diseño de una estructura dedatos eficaz debe tener en cuenta las operaciones quese van a llevar a cabo sobre dicha estructura de datos(vea [AH083]). Por ejemplo, imagínese una estructura de datos hecha con un conjunto de elementos dedatos diversos. La estructura de datos se va a manipular con varias funciones principales del software. Después de la evaluación de la operación realizada sobrela estructura de datos, se define un tipo de datos abstracto para usarlo en el diseño del software subsiguiente.La especificación de los tipos de datos abstractos puedesimplificar considerablementeel diseño del software.3. Se debería establecer un diccionario de datos yusarlo para definir el diseño de los datos y del programa. El concepto de diccionario de datos se introdujo en el Capítulo 12. Un diccionario de datosrepresenta explícitamente las relaciones entre losobjetos de datos y las restricciones de los elementosde una estructura de datos. Los algoritmos que debenaprovecharse de estas relaciones específicas puedendefinirse más fácilmente si existe una especificaciónde datos tipo diccionario.4. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño. Sepuede usar un proceso de refinamiento paso a paso parael diseño de datos. Es decir, la organización general dedatos puede definirse durante el análisis de requisitos;refinarse durante los trabajos de diseño de datos y e s pcificarse en detalle durante el diseño a nivel de componentes. El enfoque descendente del diseño de dataproporciona ventajas análogas al enfoque descendentedel diseño de software: se diseñan y evalúan primeramente los atributos estructurales principales de maneraque se pueda establecer la arquitectura de los datos.5. La representación de las estructuras de datos deberían conocerla sólo aquellos módulos que debanhacer uso directo de los datos contenidos dentro dela estructura. El concepto de ocultación de información y el concepto relacionado de acoplamiento(Capítulo 13) proporciona una importante visión dela calidad del diseño del software. Este principioalude a la importancia de estos conceptos así comoW%CLAVEUn almacén de datos contiene todos los datos utilizadosen una empresa. Su objetivo es facilitar el accesoa ((conocimiento)) que de otro modo no se dispondría.Estas características presentan un cuadro Único dedesafíos de diseño para el arquitecto de datos.14.2.2. Diseño de datos a nivel de componentesEl diseño de datos a nivel de componentes se centraen la representación de estructuras de datos a las que seaccede directamente a través de uno o más componentes del software. Wasserman [WASSO] ha propuesto unconjunto de principios que pueden emplearse para especificar y diseñar dicha estructura de datos. En realidad,el diseño de datos empieza durante la creación del modelo de análisis. Recordando que el análisis de requisitosy el diseño a menudo se solapan, consideramos elsiguiente conjunto de principios [WASSO] para la especificación de datos:1. Los principios del análisis sistemático aplicados a lafunción y al comportamiento deberían aplicarse también a los datos. Invertimos mucho tiempo y esfuerzoen obtener, revisar y especificar los requisitos funcionales y el diseño preliminar. Las representacionesde flujo de datos y contenido deberían desarrollarse240

CAPfTULO 14DISENO A R Q U I T E C T 6 N I C O7. Un diseño del software y un lenguaje de programación debería soportar la especificación y realizaciónde los tipos abstractos de datos. La implementaciónde una estructura de datos sofisticada puede hacerseexcesivamente difícil si no existen los medios de especificación directa de la estructura en el lenguaje de programación escogido para dicha implementación.Los principios descritos anteriormente forman unabase para un enfoque de diseño de datos a nivel de componentes que puede integrarse en las fases de análisis ydiseño.a «la importancia de separar la visión lógica de unobjeto de datos de su visión física» [WASSO].6. Debería desarrollarse una biblioteca de estructurasde datos útiles y de las operaciones que se les pueden aplicar. Las estructuras de datos y las operaciones deberían considerarse como recursos para eldiseño del software. Las estructuras de datos puedendiseñarse para que se puedan reutilizar. Una biblioteca de plantillas de estructuras de datos (tipos abstractos de datos) puede reducir el esfuerzo del diseñoy de la especificación de datos.,Cuando un constructor utiliza el término «centre hall colonial para describir una casa, la mayoría de la gente familiarizada con las casas en los Estados Unidos sería capazde recrear una imagen general de cómo sería esa casa y decómo sena su diseño de plantas. El constructor ha utilizado un estilo arquitectónico a modo de mecanismo descriptivo para diferenciar esa casa de otros estilos (porejemplo, A--ame, raised ranch, Cape Cod). Pero, lo másimportante, es que el estilo arquitectónico es también unpatrón de construcción. Más adelante se deberán definirlos detalles de la casa, se especificarán sus dimensionesfinales, se le añadirán características personalizadas y sedeterminarán los materiales de construcción, pero el patrón--«centre hall colonial»- guía al constructor en su trabajo.'. ' '* .-,.¿Qué es un estiloarquitectónico14.3.1. Una breve taxonomía de estilos y patronesAunque durante los pasados 50 años se han creado cientos de miles de sistemas basados en computadora, la granmayoría pueden ser clasificados (ver [SHA96], [BAS98],[BUS98]) dentro de uno de los estilos arquitectónicos:Arquitecturas centradas de datos. En el centro de estaarquitectura se encuentra un almacén de datos (por ejemplo,un documento o una base de datos) al que otros componentesacceden con frecuencia para actualizar, añadir, borrar o bienmodificar los datos del almacén. La figura 14.1 representa unestilo típico basada en los datos. El software de cliente accedea un almacén centrai. En algunos casos, el almacén de datos espasivo. Esto significa que el software de cliente accede a losdatos independientemente de cualquier cambio en los datos ode las acciones de otro software de cliente. Una variación eneste acceso transforma el almacén en una ,pizarra» que envíanotificaciones al software de cliente cuando los datos de interés del cliente cambian.3Referencia WebElproyecto ABLE de lo CMU cuenta con trabajos yejemplos muy útiles sobre estilos arquitectónicos:tom.cs.cmu.edu/able/El software construido para sistemas basados en computadoras también cuenta con diversos estilos arquitectónicos'. Cada estilo describe una categoría del sistemaque contiene: (1) un conjunto de componentes (por ejemplo, una base de datos, módulos computacionales) querealizan una función requerida por el sistema; (2) un conjunto de conectores que posibilitan la «comunicación, lacoordinación y la cooperación» entre los componentes;(3) restricciones que definen cómo se pueden integrarlos componentes que forman el sistema; y (4) modelossemánticos que permiten al diseñador entender las propiedades globales de un sistema para analizar las propiedades conocidas de sus partes constituyentes [BAS98].En la siguiente sección, abordamos los patrones arquitectónicos comúnmente utilizados para el oftwaredelclienteAlmacén de eclienteclienteFIGURA 14.1. Arquitectura basada en los datos.' Los términos estilos y patrones se utilizan indistintamente en estecapítulo.24 1

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICOLas arquitecturas basadas en los datos promueven la capacidad de integración (integrability) [BAS98]. Por consiguiente, los componentes existentes pueden cambiarse o loscomponentes del nuevo cliente pueden añadirse a la arquitectura sin involucrar a otros clientes (porque los componentes del cliente operan independientemente). Además, losdatos pueden ser transferidos entre los clientes utilizando unmecanismo de pizarra (por ejemplo, el componente de pizarra sirve para coordinar la transferencia de información entreclientes). Los componentes cliente son procesos ejecutadosindependientemente.Tu beríasFiltroFiltro(a) Tuberías y filtrosFiltroño estágenierío.FiltroFiltroFiltro(bi Secuencia1 por lotesFIGURA 14.2. Arauitecturas de fluio de datos.Arquitecturas de flujo de datos. Esta arquitectura seaplica cuando los datos de entrada son transformados a través de una serie de componentes computacionales o manipulativos en los datos de salida. Un patrón tubería y filtro(Fig. 14.2.a) tiene un grupo de componentes, llamados filtros, conectados por tuberías que transmiten datos de uncomponente al siguiente. Cada filtro trabaja independientemente de aquellos componentes que se encuentran en elflujo de entrada o de salida; está diseñado para recibir laentrada de datos de una cierta forma y producir una salidade datos (hacia el siguiente filtro) de una forma específica.Sin embargo, el filtro no necesita conocer el trabajo de losfiltros vecinos.Arquitecturas orientadas a objetos. Los componentes de un sistema encapsulan los datos y las operacionesque se deben realizar para manipular los datos. La comllnicación y la coordinación entre componentes se consiguea través del paso de mensajes.Arquitecturas estratificadas. La estructura básica deuna arquitectura estratificada se representa en la Figura14.3. Se crean diferentes capas y cada una realiza operaciones que progresivamente se aproximan más al cuadrode instrucciones de la máquina. En la capa externa, loscomponentes sirven a las operaciones de interfaz de usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las capas intermediasproporcionan servicios de utilidad y funciones del software de aplicaciones.Si el flujo de datos degenera en una simple línea de transformadores (Fig. 14.2.b) se le denomina secuencia1 porlotes. Este patrón aplica una serie de componentes secuenciales (filtros) para transformarlos.Arquitecturas de llamada y retorno. Este estilo arquitectónico permite al diseñador del software (arquitecto delsistema) construir una estructura de programa relativamentefácil de modificar y ajustar a escala. Existen dos subestilos[BAS98] dentro de esta categoría:arquitecturas de programa principallsuhprograma:esta estructura clásica de programación descomponelas funciones en una jerarquía de control donde unprograma «principal» llama a un número de componentes del programa, los cuales, en respuesta, puedentambién llamar a otros componentes. La Figura 13.3representa una arquitectura de este tipo.arquitecturas de llamada de procedimiento remoto:los componentes de una arquitectura de programaprincipal/subprograma, están distribuidos entre variascomputadoras en una red.FIGURA 14.3. Arquitectura ectratificada.242

CAPITULO 1 4DISENO A R Q U I T E C T 6 N I C Ocuál es el papel de los componentes dentro de esa jerarquía decontrol? ¿Cómo transfieren el control los componentes dentro del sistema? ¿Cómo se comparte el control entre componentes? ¿Cuál es la topología de control (por ejemplo, la formageométrica3 que adopta el control)?, ¿Está el control sincronizado o los componentes actúan asincrónicamente?Los estilos arquitectónicos citados anteriormente sonsólo una pe ueña parte de los que dispone el diseñadorde software . Una vez que la ingeniería de requisitosdefine las características y las restricciones del sistemaque ha de ser construido, se escoge el patrón arquitectónico (estilo) o la combinación de patrones (estilos)que mejor encajan con las características y restricciones. En muchos casos, puede ser apropiado más de unpatrón y se podrían diseñar y evaluar estilos arquitectónicos alternativos.9¿Cómo se evalúa un estiloarquitectónico que se ha derivado?Datos. ¿Cómo se comunican los datos entre componentes? ¿El flujo de datos es continuo o son objetos de datos quepasan de un componente a otro, o los datos están disponiblesglobalmente para ser compartidos entre los componentes delsistema? ¿Existen los componentes de datos (por ejemplo,una pizarra o almacén), y si es así, cuál es su papel? ¿Cómointeractúan los componentes funcionales con los componentes de datos? ¿Los componentes de datos son activos opasivos (por ejemplo, los componentes de datos interactúanactivamente con otros componentes del sistema)?¿Cómointeractúan los datos y el control dentro del sistema?14.3.2. Organización y refinamientoPuesto que el proceso de diseño deja a menudo al ingeniero con un número de alternativas arquitectónicas, esimportante establecer un conjunto de criterios de diseño que puedan ser utilizados para evaluar un diseñoarquitectónico derivado. Las siguientes cuestiones[BAS98] proporcionan una idea del estilo arquitectónico que ha sido derivado:Estas preguntas proporcionan al diseñador una evaluación temprana de la calidad del diseño y sientan lasbases para un análisis más detallado de la arquitectura.Control. ¿Cómo se gestiona el control dentro de la arquitectura? ¿Existe una jerarquía de control diferente, y si es así,2. Elicitación de requisitos. Esta información es requerida como parte de los requisitos de ingeniería y seutiliza para asegurarse de que todos los clientes, usuarios y partícipes implicados han sido atendidos.Las preguntas citadas en la sección anterior proporcionan una evaluación preliminar del estilo arquitectónicoescogido para un sistema concreto. Sin embargo, parala consecución efectiva del diseño, se necesita un método de evaluación de la calidad de la arquitectura máscompleto. En las siguientes secciones, consideramosdos enfoques diferentes para el análisis de diseños arquitectónicos alternativos. El primer enfoque utiliza unmétodo iterativo para evaluar el diseño de los compromisos. El segundo enfoque aplica una pseudotécnicacuantitativa para evaluar la calidad del diseño.Referencia Web/'Se puede encontrar información detallada sobre análisisde compromiso de software arquitectónico en:www.sei.cmu.edu/ata/ata-method.html3. Describir los patroneslestilos arquitectónicos escogidos para derivar los escenarios y requisitos. El(1os)estilo(s) debería describirse utilizando vistas arquitectónicas como:vista de módulo: para analizar el trabajo asignadopor componente y el grado de ocultación de información que se ha alcanzadovista de proceso: para analizar la actuación delsistemavista d e j u j o de datos: para analizar el grado enel que la arquitectura cumple los requisitos funcionales14.4.1. Un método de análisis de compromisopara la arquitecturaEl Instituto de Ingeniería de Software (SEI) ha desarrollado un Método de análisis de compromiso para laarquitectura (MACA)[KAZ98] que establece un pro ceso de evaluación iterativo para las arquitecturas desoftware. Las actividades de análisis de diseño mencionadas abajo se realizan iterativamente:1. Recopilación de escenarios. En el Capítulo 11 serecogen un grupo de casos de uso para representarel sistema desde el punto de vista del usuario.En los Capíiulos 8 y 19 se estudian ols atributos de calidad.*Ver [SHA97],[BAS98]y [BUS981 para un estudio detallado de estilos y patrones arquitectónicos.Una jerarquía es una forma geométrica, pero también podemosencontrar mecanismos de control semejantes en un sistemacliente/servidor.243

INGENIERfA DEL S O F T W A R E . U N E N F O Q U E PRÁCTICOAsada [SHA96] propone varios modelos simples paraayudar al diseñador a determinar el grado al cual unaarquitectura particular alcanza los criterios de «bondad#predefinidos. Estos criterios, a veces llamados dimensiones del diseño, a menudo abarcan los atributos decalidad definidos en la sección anterior: fiabilidad, rendimiento, seguridad, facilidad de mantenimiento, flexibilidad, capacidad de prueba, movilidad, reutilizacióne interoperatibilidad, entre otros.El primer modelo, denominado análisis del espectro,evalúa un diseño arquitectónico en un espectro de «bondad» desde el mejor diseño posible hasta el peor. Una vezque la arquitectura del software ha sido propuesta, se analiza asignando una «puntuación» a cada una de lasdimensiones del diseño. Estas notas de las dimensionesse suman para determinar la calificación total, S, deldiseño como un todo. Los casos de notas más bajas4 sonasignados a un diseño hipotético, y se computa la sumade notas de la peor arquitectura, S,. La mejor nota, S,,se computa para un diseño óptimo5. Entonces calculamos el índice del espectro, Z,,mediante la ecuación:4 . Evaluar los atributos de calidad considerando cadaatributo de forma aislada. El número de atributosde calidad escogidos para el análisis depende deltiempo disponible para la revisión y del grado derelevancia de dichos atributos para el sistema actual.Los atributos de calidad parala evaluación del diseñoarquitectónico incluyen: fiabilidad, rendimiento,seguridad, facilidad de mantenimiento, flexibilidad,capacidad de

Durante muchos años, la arquitectura de datos estu- vo limitada, generalmente, a las estructuras de datos a nivel del programa y a las bases de datos a nivel de apli- cación. Pero hoy, las empresas grandes y pequeñas están inundadas de datos. No es inusual, incluso para una mediana empresa, tener docenas de bases de datos sir-