1 Conceptos Introductorios.

Todava no se ha escrito una historia aceptable de la AS. Desde que Mary Shaw o David Garlan researan escuetamente la prehistoria de la especialidad a principios de los 90, los mismos prrafos han sido reutilizados una y otra vez en la literatura, sin mayor exploracin de las fuentes referidas en la resea primaria y con prisa por ir al grano, que usualmente no es de carcter histrico. En este estudio se ha optado, ms bien, por inspeccionar las fuentes ms de cerca, con el objeto de sealar las supervivencias y las re-semantizaciones que han experimentado las ideas fundadoras en la AS contempornea, definir con mayor claridad el contexto, entender que muchas contribuciones que pasaron por complementarias han sido en realidad antagnicas y comprender mejor por qu algunas ideas que surgieron hace cuatro dcadas demoraron un cuarto de siglo en materializarse.

Esta decisin involucra algo ms que el perfeccionamiento de la lectura que pueda hacerse de un conjunto de acontecimientos curiosos. Las formas divergentes en que se han interpretado dichas ideas, despus de todo, permiten distinguir corrientes de pensamiento diversas, cuyas diferencias distan de ser triviales a la hora de plasmar las ideas en una metodologa. Todo lo que parece ser un simple elemento de juicio, no pocas veces implica una disyuntiva. Situar las inflexiones de la breve historia de la AS en un contexto temporal, asimismo, ayudar a comprender mejor cules son sus contribuciones perdurables y cules sus manifestaciones contingentes al espritu de los tiempos y a las modas tecnolgicas que se han ido sucediendo.

Si bien la AS acostumbra remontar sus antecedentes al menos hasta la dcada de 1960, su historia no ha sido tan continua como la del campo ms amplio en el que se inscribe, la ingeniera de software [Pfl02] [Pre01]. Despus de las tempranas inspiraciones del legendario Edsger Dijkstra, de David Parnas y de Fred Brooks, la AS qued en estado de vida latente durante unos cuantos aos, hasta comenzar su expansin explosiva con los manifiestos de Dewayne Perry de AT&T Bell Laboratories de New Jersey y Alexander Wolf de la Universidad de Colorado [PW92]. Puede decirse que Perry y Wolf fundaron la disciplina, y su llamamiento fue respondido en primera instancia por los miembros de lo que podra llamarse la escuela estructuralista de Carnegie Mellon: David Garlan, Mary Shaw, Paul Clements, Robert Allen. Se trata entonces de una prctica joven, de apenas unos doce aos de trabajo constante, que en estos momentos experimenta una nueva ola creativa en el desarrollo cabal de sus tcnicas en la obra de Rick Kazman, Mark Klein, Len Bass y otros metodlogos en el contexto del SEI, en la misma universidad. A comienzos del siglo XXI comienzan ya a discernirse tendencias, cuyas desavenencias mutuas todava son leves: al menos una en el sur de California (Irvine y Los ngeles) con Nenad Medvidovic, David Rosenblum y Richard Taylor, otra en el SRI de Menlo Park con Mark Moriconi y sus colegas y otra ms vinculada a las recomendaciones formales de la IEEE y los trabajos de Rich Hilliard. Hoy se percibe tambin un conjunto de

posturas europeas que enfatizan mayormente cuestiones metodolgicas vinculadas con escenarios y procuran inscribir la arquitectura de software en el ciclo de vida, comenzando por la elicitacin de los requerimientos. Antes de Perry y Wolf, empero, se formularon ideas que seran fundamentales para la disciplina ulterior. Comencemos entonces por el principio, aunque siempre cabr la posibilidad de discutir cul puede haber sido el momento preciso en el que todo comenz.

Cada vez que se narra la historia de la arquitectura de software (o de la ingeniera de software, segn el caso), se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de la Universidad Tecnolgica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una estructuracin correcta de los sistemas de software antes de lanzarse a programar, escribiendo cdigo de cualquier manera [Dij68a]. Dijkstra, quien sostena que las ciencias de la computacin eran una rama aplicada de las matemticas y sugera seguir pasos formales para descomponer problemas mayores, fue uno de los introductores de la nocin de sistemas operativos organizados en capas que se comunican slo con las capas adyacentes y que se superponen como capas de cebolla. Invent o ayud a precisar adems docenas de conceptos: el algoritmo del camino ms corto, los stacks, los vectores, los semforos, los abrazos mortales. De sus ensayos arranca la tradicin de hacer referencia a niveles de abstraccin que ha sido tan comn en la arquitectura subsiguiente. Aunque Dijkstra no utiliza el trmino arquitectura para describir el diseo conceptual del software, sus conceptos sientan las bases para lo que luego expresaran Niklaus Wirth [Wir71] como stepwise refinement y DeRemer y Kron [DK76] como programming-in-the large (o programacin en grande), ideas que poco a poco iran decantando entre los ingenieros primero y los arquitectos despus.

En la conferencia de la NATO de 1969, un ao despus de la sesin en que se fundara la ingeniera de software, P. I. Sharp formul estas sorprendentes apreciaciones comentando las ideas de Dijkstra: Pienso que tenemos algo, aparte de la ingeniera de software: algo de lo que hemos hablado muy poco pero que deberamos poner sobre el tapete y concentrar la atencin en ello. Es la cuestin de la arquitectura de software. La arquitectura es diferente de la ingeniera. Como ejemplo de lo que quiero decir, echemos una mirada a OS/360. Partes de OS/360 estn extremadamente bien codificadas. Partes de OS, si vamos al detalle, han utilizado tcnicas que hemos acordado constituyen buena prctica de programacin. La razn de que OS sea un amontonamiento amorfo de programas es que no tuvo arquitecto. Su diseo fue delegado a series de grupos de ingenieros, cada uno de los cuales invent su propia arquitectura. Y cuando esos pedazos se clavaron todos juntos no produjeron una tersa y bella pieza de software [NATO76: 150]. Sharp contina su alegacin afirmando que con el tiempo probablemente llegue a hablarse de la escuela de arquitectura de software de Dijkstra y se lamenta que en la industria de su tiempo se preste tan poca o ninguna atencin a la arquitectura. La frase siguiente tambin es extremadamente visionaria: Lo que sucede es que las especificaciones de software se consideran especificaciones funcionales. Slo hablamos sobre lo que queremos que haga el programa. Es mi creencia que cualquiera que sea responsable de la implementacin de una pieza de software debe especificar ms que esto. Debe especificar el diseo, la forma; y dentro de ese marco de referencia, los programadores e ingenieros deben crear algo. Ningn ingeniero o programador, ninguna herramienta de programacin, nos ayudar, o ayudar al negocio del

software, a maquillar un diseo feo. El control, la administracin, la educacin y todas las cosas buenas de las que hablamos son importantes; pero la gente que implementa debe entender lo que el arquitecto tiene en mente [dem]. Nadie volvi a hablar del asunto en esa conferencia, sin embargo. Por unos aos, arquitectura fue una metfora de la que se ech mano cada tanto, pero sin precisin semntica ni consistencia pragmtica. En 1969 Fred Brooks Jr y Ken Iverson llamaban arquitectura a la estructura conceptual de un sistema en la perspectiva del programador. En 1971, C. R. Spooner titul uno de sus ensayos Una arquitectura de software para los 70s [Spo71], sin que la mayor parte de la historiografa de la AS registrara ese antecedente.

En 1975, Brooks, diseador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el concepto de arquitectura del sistema para designar la especificacin completa y detallada de la interfaz de usuario y consideraba que el arquitecto es un agente del usuario, igual que lo es quien disea su casa [Bro75], empleando una nomenclatura que ya nadie aplica de ese modo. En el mismo texto, identificaba y razonaba sobre las estructuras de alto nivel y reconoca la importancia de las decisiones tomadas a ese nivel de diseo. Tambin distingua entre arquitectura e implementacin; mientras aquella deca qu hacer, la implementacin se ocupa de cmo. Aunque el concepto de AS actual y el de Brooks difieren en no escasa medida, el texto de Brooks The mythical man-month sigue siendo, un cuarto de siglo ms tarde, el ms ledo en ingeniera de software. Se ha sealado que Dijkstra y Brooks, el primero partidario de un formalismo matemtico y el segundo de considerar las variables humanas, constituyen dos personalidades opuestas, que se sitan en los orgenes de las metodologas fuertes y de las heterodoxias giles, respectivamente [Tra02]; pero eso ser otra historia.

Una novedad importante en la dcada de 1970 fue el advenimiento del diseo estructurado y de los primeros modelos explcitos de desarrollo de software. Estos modelos comenzaron a basarse en una estrategia ms orgnica, evolutiva, cclica, dejando atrs las metforas del desarrollo en cascada que se inspiraban ms bien en la lnea de montaje de la ingeniera del hardware y la manufactura. Surgieron entonces las primeras investigaciones acadmicas en materia de diseo de sistemas complejos o intensivos. Poco a poco el diseo se fue independizando de la implementacin, y se forjaron herramientas, tcnicas y lenguajes de modelado especficos.

En la misma poca, otro precursor importante, David Parnas, demostr que los criterios seleccionados en la descomposicin de un sistema impactan en la estructura de los programas y propuso diversos principios de diseo que deban seguirse a fin de obtener una estructura adecuada. Parnas desarroll temas tales como mdulos con ocultamiento de informacin [Par72], estructuras de software [Par74] y familias de programas [Par76], enfatizando siempre la bsqueda de calidad del software, medible en trminos de economas en los procesos de desarrollo y mantenimiento. Aunque Dijkstra, con sus frases lapidarias y memorables, se ha

convertido en la figura legendaria por excelencia de los mitos de origen de la AS, Parnas ha sido sin duda el introductor de algunas de sus nociones ms esenciales y permanentes.

En 1972, Parnas public un ensayo en el que discuta la forma en que la modularidad en el diseo de sistemas poda mejorar la flexibilidad y el control conceptual del sistema, acortando los tiempos de desarrollo [Par72]. Introdujo entonces el concepto de ocultamiento de informacin (information hiding), uno de los principios de diseo fundamentales en diseo de software an en la actualidad. La herencia de este concepto en la ingeniera y la arquitectura ulterior es inmensa, y se confunde estrechamente con la idea de abstraccin. En la segunda de las descomposiciones que propone Parnas comienza a utilizarse el ocultamiento de informacin como criterio. Los mdulos ya no se corresponden con las etapas de procesamiento. ? Cada mdulo en la segunda descomposicin se caracteriza por su conocimiento de una decisin de diseo oculta para todos los otros mdulos. Su interfaz o definicin se escoge para que revele tan poco como sea posible sobre su forma interna de trabajo [Par72]. Cada mdulo deviene entonces una caja negra para los dems mdulos del sistema, los cuales podrn acceder a aqul a travs de interfaces bien definidas, en gran medida invariables. Es fcil reconocer en este principio ideas ya presentadas por Dijkstra en su implementacin del THE-Multiprogramming System [Dij68a]. Pero la significacin del artculo de 1972 radica en la idea de Parnas de basar la tcnica de modularizacin en decisiones de diseo, mientras que los niveles de abstraccin de Dijkstra involucraban ms bien (igual que su famosa invectiva en contra del Go-to) tcnicas de programacin.

El concepto de ocultamiento se fue mezclando con encapsulamiento y abstraccin, tras algunos avatares de avance y retroceso. Los arquitectos ms escrupulosos distinguen entre encapsulamiento y ocultamiento, considerando a aqul como una capacidad de los lenguajes de programacin y a ste como un principio ms general de diseo. De hecho, Parnas no hablaba en trminos de programacin orientada a objeto, sino de mdulos y sub-rutinas, porque el momento de los objetos no haba llegado todava. El pensamiento de Parnas sobre familias de programas, en particular, anticipa ideas que luego habran de desarrollarse a propsito de los estilos de arquitectura: Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o lo sern alguna vez) a los cuales es provechoso o til considerar como grupo. Esto evita el uso de conceptos ambiguos tales como similitud funcional que surgen a veces cuando se describen dominios. Por ejemplo, los ambientes de ingeniera de software y los juegos de video no se consideran usualmente en el mismo dominio, aunque podran considerarse miembros de la misma familia de programas en una discusin sobre herramientas que ayuden a construir interfaces grficas, que casualmente ambos utilizan. Una familia de programas puede enumerarse en principio mediante la especificacin del rbol de decisin que se atraviesa para llegar a cada miembro de la familia. Las hojas del rbol representan sistemas ejecutables. El concepto soporta la nocin de derivar un miembro de la familia a partir de uno ya existente. El procedimiento consiste en seguir hacia atrs el rbol hasta que se alcanza un nodo (punto de decisin)

genealgicamente comn a ambos, y luego proceder hacia abajo hasta llegar al miembro deseado. El concepto tambin soporta la nocin de derivar varios miembros de la familia de un punto de decisin comn, aclarando la semejanza y las diferencias entre ellos.

Las decisiones iniciales son las que ms probablemente permanecern constantes entre los miembros; las decisiones ms tardas (cerca de las hojas) en un rbol prudentemente estructurado deberan representar decisiones susceptibles de cambiarse trivialmente, tales como los valores de tiempo de compilacin o las constantes de tiempo de carga. La significacin del concepto de familia de programas para la AS es que ella corresponde a las decisiones cerca del tope del rbol de decisin de Parnas. Es importante considerar que el rbol de Parnas es top-down no slo porque se construye y recorre de lo general a lo particular, sino porque sus races se encuentran hacia arriba (o a la izquierda si el modelo es horizontal). No menos esencial es tener en cuenta que el rbol se ofreci como alternativa a mtodos de descomposicin basados en diagramas de flujo, por los que la AS no ha mostrado nunca demasiada propensin.

Deca Parnas que las decisiones tempranas de desarrollo seran las que probablemente permaneceran invariantes en el desarrollo ulterior de una solucin. Esas decisiones tempranas constituyen de hecho lo que hoy se llamaran decisiones arquitectnicas. Como escriben Clements y Northrop [CN96] en todo el desenvolvimiento ulterior de la disciplina permanecera en primer plano esta misma idea: la estructura es primordial (structure matters), y la eleccin de la estructura correcta ha de ser crtica para el xito del desarrollo de una solucin. Ni duda cabe que la eleccin de la estructura correcta sintetiza, como ninguna otra expresin, el programa y la razn de ser de la AS.

En la dcada de 1980, los mtodos de desarrollo estructurado demostraron no escalar suficientemente y fueron dejando el lugar a un nuevo paradigma, el de la programacin orientada a objetos. En teora, pareca posible modelar el dominio del problema y el de la solucin en un lenguaje de implementacin. La investigacin que llev a lo que despus sera el diseo orientado a objetos puede remontarse incluso a la dcada de 1960 con Simula, un lenguaje de programacin de simulaciones, el primero que proporcionaba tipos de datos abstractos y clases, y despus fue refinada con el advenimiento de Smalltalk. Paralelamente, hacia fines de la dcada de 1980 y comienzos de la siguiente, la expresin arquitectura de software comienza a aparecer en la literatura para hacer referencia a la configuracin morfolgica de una aplicacin.

Mientras se considera que la ingeniera de software se fund en 1968, cuando F.L. Bauer us ese sintagma por primera vez en la conferencia de la OTAN de Garmisch, Alemania, la AS, como disciplina bien delimitada, es mucho ms nueva de lo que generalmente se sospecha. El primer texto que vuelve a reivindicar las abstracciones de alto nivel, reclamando un espacio para esa reflexin y augurando que el uso de esas abstracciones en el proceso de desarrollo pueden resultar en un nivel de arquitectura de software en el

diseo es uno de Mary Shaw [Shaw84] seguido por otro llamado Larger scale systems require higher level abstractions [Shaw89]. Se hablaba entonces de un nivel de abstraccin en el conjunto; todava no estaban en su lugar los elementos de juicio que permitieran reclamar la necesidad de una disciplina y una profesin particulares. El primer estudio en que aparece la expresin arquitectura de software en el sentido en que hoy lo conocemos es sin duda el de Perry y Wolf [PW92]; ocurri tan tarde como en 1992, aunque el trabajo se fue gestando desde 1989. En l, los autores proponen concebir la AS por analoga con la arquitectura de edificios, una analoga de la que luego algunos abusaron [WWI99], otros encontraron til y para unos pocos ha devenido inaceptable [BR01]. El artculo comienza diciendo exactamente: El propsito de este paper es construir el fundamento para la arquitectura de software. Primero desarrollaremos una intuicin para la arquitectura de software recurriendo a diversas disciplinas arquitectnicas bien definidas. Sobre la base de esa intuicin, presentamos un modelo para la arquitectura de software que consiste en tres componentes: elementos, forma y razn (rationale). Los elementos son elementos ya sea de procesamiento, datos o conexin. La forma se define en trminos de las propiedades de, y las relaciones entre, los elementos, es decir, restricciones operadas sobre ellos. La razn proporciona una base subyacente para la arquitectura en trminos de las restricciones del sistema, que lo ms frecuente es que se deriven de los requerimientos del sistema. Discutimos los componentes del modelo en el contexto tanto de la arquitectura como de los estilos arquitectnicos.... La declaracin, como puede verse, no tiene una palabra de desperdicio: cada idea cuenta, cada intuicin ha permanecido viva desde entonces. Los autores prosiguen reseando el progreso de las tcnicas de diseo en la dcada de 1970, en la que los investigadores pusieron en claro que el diseo es una actividad separada de la implementacin y que requiere notaciones, tcnicas y herramientas especiales. Los resultados de esta investigacin comienzan ahora (decan en 1992) a penetrar el mercado en la forma de herramientas de ingeniera asistida por computadoras, CASE. Pero uno de los resultados del uso de estas herramientas ha sido que se produjo la absorcin de las herramientas de diseo por los lenguajes de implementacin. Esta integracin ha tendido a esfumar, si es que no a confundir, la diferencia entre diseo e implementacin. En la dcada de 1980 se perfeccionaron las tcnicas descriptivas y las notaciones formales, permitindonos razonar mejor sobre los sistemas de software. Para la caracterizacin de lo que suceder en la dcada siguiente ellos formulan esta otra frase que ha quedado inscripta en la historia mayor de la especialidad: La dcada de 1990, creemos, ser la dcada de la arquitectura de software. Usamos el trmino arquitectura en contraste con diseo, para evocar nociones de codificacin, de abstraccin, de estndares, de entrenamiento formal (de los arquitectos de software) y de estilo. ? Es tiempo de reexaminar el papel de la arquitectura de software en el contexto ms amplio del proceso de software y de su administracin, as como sealar las nuevas tcnicas que han sido adoptadas. Considerada como disciplina por mrito propio, la AS ha de ser, para ellos, beneficiosa como marco de referencia para satisfacer requerimientos, una base esencial para la estimacin de costos y administracin del proceso y para el anlisis de las dependencias y la consistencia del sistema.

Dando cumplimiento a las profecas de Perry y Wolf, la dcada de 1990 fue sin duda la de la consolidacin y diseminacin de la AS en una escala sin precedentes. Las contribuciones ms importantes surgieron en torno

del instituto de ingeniera de la informacin de la Universidad Carnegie Mellon (CMU SEI), antes que de cualesquiera organismos de industria. En la misma dcada, demasiado prdiga en acontecimientos, surge tambin la programacin basada en componentes, que en su momento de mayor impacto impuls a algunos arquitectos mayores, como Paul Clements [Cle96b], a afirmar que la AS promova un modelo que deba ser ms de integracin de componentes pre-programados que de programacin.

Un segundo gran tema de la poca fue el surgimiento de los patrones, cristalizada en dos textos fundamentales, el de la Banda de los Cuatro en 1995 [Gof95] y la serie POSA desde 1996 [BMR+96]. El primero de ellos promueve una expansin de la programacin orientada a objetos, mientras que el segundo desenvuelve un marco ligeramente ms ligado a la AS. Este movimiento no ha hecho ms que expandirse desde entonces. El originador de la idea de patrones fue Christopher Alexander, quien incidentalmente fue arquitecto de edificios; Alexander desarroll en diversos estudios de la dcada de 1970 temas de anlisis del sentido de los planos, las formas, la edificacin y la construccin, en procura de un modelo constructivo y humano de arquitectura, elaborada de forma que tenga en cuenta las necesidades de los habitantes [Ale77]. El arquitecto (y puede copiarse aqu lo que deca Fred Brooks) debe ser un agente del usuario.

A lo largo de una cadena de intermediarios y pensadores originales, las ideas llegaron por fin a la informtica diez aos ms tarde. Si bien la idea de arquitectura implcita en el trabajo actual con patrones est ms cerca de la implementacin y el cdigo, y aunque la reutilizacin de patrones guarda estrecha relacin con la tradicin del diseo concreto orientado a objetos [Lar03], algunos arquitectos emanados de la escuela de Carnegie Mellon formalizaron un acercamiento con esa estrategia [Shaw96] [MKM+96] [MKM+97]. Tanto en los patrones como en la arquitectura, la idea dominante es la de re-utilizacin. A impulsos de otra idea mayor de la poca (la crisis del software), la bibliografa sobre el impacto econmico de la re-utilizacin alcanza hoy magnitudes de cuatro dgitos.

Como quiera que sea, la AS de este perodo realiz su trabajo de homogeneizacin de la terminologa, desarroll la tipificacin de los estilos arquitectnicos y elabor lenguajes de descripcin de arquitectura (ADLs), temas que en este estudio se tratan en documentos separados. Tambin se consolid la concepcin de las vistas arquitectnicas, reconocidas en todos y cada uno de los frameworks generalizadores que se han propuesto (4+1, TOGAF, RM/ODP, IEEE), como luego se ver.

Uno de los acontecimientos arquitectnicos ms importantes del ao 2000 fue la hoy clebre tesis de Roy Fielding que present el modelo REST, el cual establece definitivamente el tema de las tecnologas de Internet y los modelos orientados a servicios y recursos en el centro de las preocupaciones de la disciplina [Fie00]. En el mismo ao se publica la versin definitiva de la recomendacin IEEE Std 1471, que procura homogeneizar y ordenar la nomenclatura de descripcin arquitectnica y homologa los estilos como un

modelo fundamental de representacin conceptual.

En el siglo XXI, la AS aparece dominada por estrategias orientadas a lneas de productos y por establecer modalidades de anlisis, diseo, verificacin, refinamiento, recuperacin, diseo basado en escenarios, estudios de casos y hasta justificacin econmica, redefiniendo todas las metodologas ligadas al ciclo de vida en trminos arquitectnicos. Todo lo que se ha hecho en ingeniera debe formularse de nuevo, integrando la AS en el conjunto. La produccin de estas nuevas metodologas ha sido masiva, y una vez ms tiene como epicentro el trabajo del Software Engineering Institute en Carnegie Mellon. La aparicin de las metodologas basadas en arquitectura, junto con la popularizacin de los mtodos giles en general y Extreme Programming en particular, han causado un reordenamiento del campo de los mtodos, hasta entonces dominados por las estrategias de diseo de peso pesado. Despus de la AS y de las tcticas radicales, las metodologas nunca volvern a ser las mismas.

La semblanza que se ha trazado no es ms que una visin selectiva de las etapas recorridas por la AS. Los lineamientos de ese proceso podran dibujarse de maneras distintas, ya sea enfatizando los hallazgos formales, las intuiciones dominantes de cada perodo o las diferencias que median entre la abstraccin cualitativa de la arquitectura y las cuantificaciones que han sido la norma en ingeniera de software.

1.1 La arquitectura de 4+1 vistas.

Definiciones

No es novedad que ninguna definicin de la AS es respaldada unnimemente por la totalidad de los arquitectos. El nmero de definiciones circulantes alcanza un orden de tres dgitos, amenazando llegar a cuatro. De hecho, existen grandes compilaciones de definiciones alternativas o contrapuestas, como la coleccin que se encuentra en el SEI (http://www.sei.cmu.edu/architecture/definitions.html), a la que cada quien puede agregar la suya. En general, las definiciones entremezclan despreocupadamente (1) el trabajo dinmico de estipulacin de la arquitectura dentro del proceso de ingeniera o el diseo (su lugar en el ciclo de vida), (2) la configuracin o topologa esttica de sistemas de software contemplada desde un elevado nivel de abstraccin y (3) la caracterizacin de la disciplina que se ocupa de uno de esos dos asuntos, o de ambos.

Una definicin reconocida es la de Clements [Cle96a]: La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la

supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones.

En una definicin semejante, hay que aclararlo, la idea de componente no es la de la correspondiente tecnologa de desarrollo (COM, CORBA Component Model, EJB), sino la de elemento propio de un estilo. Un componente es una cosa, una entidad, a la que los arquitectos prefieren llamar componente antes que objeto, por razones que se vern en otros documentos de esta serie pero que ya es obvio imaginar cules han de ser.

A despecho de la abundancia de definiciones del campo de la AS, existe en general acuerdo de que ella se refiere a la estructura a grandes rasgos del sistema, estructura consistente en componentes y relaciones entre ellos [BCK98]. Estas cuestiones estructurales se vinculan con el diseo, pues la AS es despus de todo una forma de diseo de software que se manifiesta tempranamente en el proceso de creacin de un sistema; pero este diseo ocurre a un nivel ms abstracto que el de los algoritmos y las estructuras de datos. En el que muchos consideran un ensayo seminal de la disciplina, Mary Shaw y David Garlan sugieren que dichas cuestiones estructurales incluyen organizacin a grandes rasgos y estructura global de control; protocolos para la comunicacin, la sincronizacin y el acceso a datos; la asignacin de funcionalidad a elementos del diseo; la distribucin fsica; la composicin de los elementos de diseo; escalabilidad y rendimiento; y seleccin entre alternativas de diseo [GS94].

En una definicin tal vez demasiado amplia, David Garlan [Gar00] establece que la AS constituye un puente entre el requerimiento y el cdigo, ocupando el lugar que en los grficos antiguos se reservaba para el diseo. La definicin oficial de AS se ha acordado que sea la que brinda el documento de IEEE Std 14712000, adoptada tambin por Microsoft, que reza as: La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin. Aunque las literaturas de ambos campos rara vez convergen, entendemos que es productivo contrastar esa definicin con la de ingeniera de software, conforme al estndar IEEE 610.12.1990: La aplicacin de una estrategia sistemtica, disciplinada y cuantificable al desarrollo, aplicacin y mantenimiento del software; esto es, la aplicacin de la ingeniera al software. Obsrvese entonces que la nocin clave de la arquitectura es la organizacin (un concepto cualitativo o estructural), mientras que la ingeniera tiene fundamentalmente que ver con una sistematicidad susceptible de cuantificarse.

Antes el nmero y variedad de definiciones existentes de AS, Mary Shaw y David Garlan [SG95] proporcionaron una sistematizacin iluminadora, explicando las diferencias entre definiciones en funcin de

distintas clases de modelos. Destilando las definiciones y los puntos de vista implcitos o explcitos, los autores clasifican los modelos de esta forma: 1) Modelos estructurales: Sostienen que la AS est compuesta por componentes, conexiones entre ellos y (usualmente) otros aspectos tales como configuracin, estilo, restricciones, semntica, anlisis, propiedades, racionalizaciones, requerimientos, necesidades de los participantes. El trabajo en esta rea est caracterizada por el desarrollo de lenguajes de descripcin arquitectnica (ADLs). 2) Modelos de framework: Son similares a la vista estructural, pero su nfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composicin. Los modelos de framework a menudo se refieren a dominios o clases de problemas especficos. El trabajo que ejemplifica esta variante incluye arquitecturas de software especficas de dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes especficos, como PRISM. 3) Modelos dinmicos: Enfatizan la cualidad conductual de los sistemas. Dinmico puede referirse a los cambios en la configuracin del sistema, o a la dinmica involucrada en el progreso de la computacin, tales como valores cambiantes de datos. 4) Modelos de proceso: Se concentran en la construccin de la arquitectura, y en los pasos o procesos involucrados en esa construccin. En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el actual trabajo sobre programacin de procesos para derivar arquitecturas. 5) Modelos funcionales: Una minora considera la arquitectura como un conjunto de componentes funcionales, organizados en capas que proporcionan servicios hacia arriba. Es tal vez til pensar en esta visin como un framework particular. Ninguna de estas vistas excluye a las otras, ni representa un conflicto fundamental sobre lo que es o debe ser la AS. Por el contrario, representan un espectro en la comunidad de investigacin sobre distintos nfasis que pueden aplicarse a la arquitectura: sobre sus partes constituyentes, su totalidad, la forma en que se comporta una vez construida, o el proceso de su construccin. Tomadas en su conjunto, destacan ms bien un consenso. Independientemente de las discrepancias entre las diversas definiciones, es comn entre todos los autores el concepto de la arquitectura como un punto de vista que concierne a un alto nivel de abstraccin. Revisamos las diversas definiciones del concepto de abstraccin en un apartado especfico ms adelante en este estudio. Es casi seguro que la percepcin de la AS que prevalece entre quienes no han tenido contacto con ella, as como los estereotipos dominantes sobre su naturaleza, o los nombres que se escogeran como sus personalidades ms importantes, difieren sustancialmente de lo que es el caso en el interior de la especialidad. Este sera acaso un ejercicio digno de llevarse a cabo alguna vez.

1.2 Desarrollo orientado a objetos.

Conceptos fundamentales

Ms all de que hoy existan numerosos conceptos en el plano detallado de las tcnicas y metodologas, la AS se articula alrededor de unos pocos conceptos y principios esenciales y unas pocas herramientas caractersticas.

Estilos En el texto fundacional de la AS, Perry y Wolf establecen el razonamiento sobre estilos de arquitectura como uno de los aspectos fundamentales de la disciplina. Un estilo es un concepto descriptivo que define una forma de articulacin u organizacin arquitectnica. El conjunto de los estilos cataloga las formas bsicas posibles de estructuras de software, mientras que las formas complejas se articulan mediante composicin de los estilos fundamentales.

Sucintamente descriptos, los estilos conjugan elementos (o componentes, como se los llama aqu), conectores, configuraciones y restricciones. Al estipular los conectores como elemento de juicio de primera clase, el concepto de estilo, incidentalmente, se sita en un orden de discurso y de mtodo que el modelado orientado a objetos en general y UML en particular no cubren satisfactoriamente. La descripcin de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un lenguaje de descripcin arquitectnica o en lenguajes formales de especificacin. A diferencia de los patrones de diseos, que son centenares, los estilos se ordenan en seis o siete clases fundamentales y unos veinte ejemplares, como mximo. Es digno de sealarse el empeo por subsumir todas las formas existentes de aplicaciones en un conjunto de dimensiones tan modestas. Las arquitecturas complejas o compuestas resultan del agregado o la composicin de estilos ms bsicos. Algunos estilos tpicos son las arquitecturas basadas en flujo de datos, las peer-to-peer, las de invocacin implcita, las jerrquicas, las centradas en datos o las de intrprete-mquina virtual.

Hemos tratado el tema de las definiciones, los catlogos de estilos, las propiedades de cada uno, el lugar de los estilos en la AS y su relacin con los patrones de diseo y con la estrategia arquitectnica de Microsoft en un documento separado, en torno del cual se podrn discutir las cuestiones relacionadas con ellos.

Lenguajes de descripcin arquitectnica Los lenguajes de descripcin de arquitecturas, o ADLs, ocupan una parte importante del trabajo arquitectnico desde la fundacin de la disciplina. Se trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas de extraccin acadmica, que fueron surgiendo desde comienzos de la dcada de 1990 hasta la actualidad, ms o menos en contemporaneidad con el proyecto de unificacin de los lenguajes de modelado bajo la forma de UML. Los ADL difiere sustancialmente de UML, que al menos en su versin 1.x se estima inadecuado en su capacidad para expresar conectores en particular y en su modelo semntico en general para las clases de descripcin y anlisis que se requieren. Los ADLs permiten modelar una arquitectura mucho antes que se lleve a cabo la programacin de las aplicaciones que la componen, analizar su adecuacin, determinar sus puntos crticos y eventualmente simular su comportamiento. Los ADLs son bien conocidos en los estudios universitarios de AS, pero muy pocos arquitectos de industria parecen conocerlos y son menos an quienes los utilizan como instrumento en el diseo arquitectnico de sus proyectos. Hay unos veinte ADLs de primera magnitud y tal vez unos cuarenta o cincuenta propuestos en ponencias que no han resistido el paso del tiempo o que no han encontrado su camino en el mercado. Se han analizado esos lenguajes descriptivos en un documento aparte, en el cual se invita asimismo a su discusin.

Frameworks y Vistas En esta seccin se examinarn primero las propuestas sobre organizacin de vistas desarrolladas en el contexto de los frameworks ms influyentes. En segundo lugar, se analizar algo ms formalmente la historia y el significado del concepto de vistas en s, ya que en la mayor parte de la literatura no acadmica la significacin precisa del concepto y su funcin tcnica se suelen dar por sentadas o se definen a la ligera y de formas cambiantes.

Existen unos cuantos organismos de estndares (ISO, CEN, IEEE, OMG) que han codificado diferentes aspectos de la AS, cuando no la AS en su totalidad, con el objetivo de homogeneizar la terminologa, los modelos y los procedimientos. Los emergentes del trabajo de sus comits son especificaciones y recomendaciones de variada naturaleza, como RM-ODP, RUP, RDS, MDA, MOF, MEMO, XMI o IEEE 14712000. Casi cualquier combinacin de tres o cuatro letras del alfabeto corresponde al acrnimo de algn estndar a tener en cuenta. La AS hace mencin eventual de esas doctrinas y los acadmicos ocupan sillas preferenciales en los organismos, pero su tratamiento exhaustivo en la literatura de investigacin decididamente no califica como uno de los grandes temas prioritarios. Las recomendaciones de los marcos se tratan con sumo respeto pero tambin con alguna reticencia, tal vez porque se estima que los organismos privilegiaran ms un acuerdo regido por una necesidad de equidistancia que una adecuada fundamentacin formal, porque cualquier versin del estndar que se mencione en un paper habr caducado cuando se lo publique, o por alguna otra razn que dejamos abierta para que se discuta.

Hay una excepcin, sin embargo. Tanto los marcos arquitectnicos como las metodologas de modelado de los organismos acostumbran ordenar las diferentes perspectivas de una arquitectura en trminos de vistas (views). La mayora de los frameworks y estrategias reconoce entre tres y seis vistas, que son las que se incluyen en el cuadro. Una vista es, para definirla sucintamente, un subconjunto resultante de practicar una seleccin o abstraccin sobre una realidad, desde un punto de vista determinado [Hil99]. Zachman (Niveles) Scope Empresa Sistema lgico Tecnologa Representacin Funcionamiento Tabla 1 - Vistas en los marcos de referencia TOGAF (Arquitecturas) Negocios Datos Aplicacin Tecnologa 4+1 (Vistas) Lgica Proceso Fsica Desarrollo Casos de uso [BRJ99] (Vistas) Diseo Proceso Implementacin Despliegue Casos de uso POSA (Vistas) Lgica Proceso Fsica Desarrollo Microsoft (Vistas) Lgica Conceptual Fsica

El marco de referencia para la arquitectura empresarial de John Zachman [Zac87] identifica 36

vistas en la arquitectura (celdas) basadas en seis niveles (scope, empresa, sistema lgico,

tecnologa, representacin detallada y funcionamiento empresarial) y seis aspectos (datos, funcin, red, gente, tiempo, motivacin). En el uso corriente de AS se ha estimado que este modelo es excesivamente rgido y sobre-articulado. Parecera existir cierto consenso sobre su excesiva ambicin y su posible obsolescencia. Los manuales recientes de ingeniera de software (por ejemplo [Pre02] [Pfl02]) suelen omitir toda referencia a este marco, que se estima perteneciente a una esfera de Information Management y estrategia empresarial, antes que inscripto en el campo de la arquitectura. El framework ha estado tambin bajo nutrido fuego crtico [Cib98] [Keen91]. No obstante, hay que reconocer que tres de las vistas propuestas por Zachman tan tempranamente como en 1982 (conceptual, lgica y fsica) se corresponden con el modelo de vistas de los marcos de referencia posteriores.

El Modelo de Referencia para Procesamiento Distribuido Abierto (RM-ODP) es un estndar de ISO y

de ITU (ex-CCITT) que define un marco para la especificacin arquitectnica de grandes sistemas distribuidos. Define, entre otras cosas, cinco puntos de vista (viewpoints) para un sistema y su entorno: empresa, informacin, computacin, ingeniera y tecnologa. Los cinco puntos de vista no corresponden a etapas de proceso de desarrollo o refinamiento. De los cuatro estndares bsicos que componen el modelo, los dos primeros se refieren a la motivacin general del mismo y a sus fundamentos conceptuales y analticos; el tercero (ISO/IEC 10746-3; UTI-T X.903) a la arquitectura, definiendo los puntos de vistas referidos; y el cuarto (ISO/IEC 10746-4; UTI-T X.904) a la formalizacin de la semntica arquitectnica. RM-ODP se supone neutral en relacin con la metodologa, las formas de modelado y la tecnologa a implementarse, pero recomienda el uso de lenguajes formales de especificacin como LOTOS, ESTELLE, SDL o Z. Se supone que un modelo pensado con similares propsitos, como CORBA, debera ser 100% conforme con la referencia, pero en verdad no es as; CORBA, por ejemplo, no proporciona soporte para el viewpoint empresarial, su modelo computacional revela desviaciones significativas del ISO/IEC o el UTI-T correspondiente, su modelo de binding es ms restringido (carece de multicast o plug and play) y aunque hay RFPs que documentan estas divergencias, hasta donde puede saberse permanecen an sin resolver; en los viewpoints de ingeniera y tecnologa las discrepancias son menores, pero son muchsimas, y en ninguno hay concordancia en la nomenclatura [DIR99]. Los modelos mayores de industria como COM o J2EE son todava ms divergentes y las verificaciones de conformidad son un trmite extremadamente complejo. RM-ODP, adems, no especifica nada acerca de conectores entre sistemas, integracin de tecnologas legacy o soporte de sistemas multi-paradigmas [Bez98]. Hoy en da la interoperabilidad se garantiza ms a travs de tecnologas comunes de formato y protocolo ligadas a XML, SOAP, BPEL4WS o WS-I (o mediante MDA, o programando un wrapper) que por conformidad con esta clase de recomendaciones en todos los puntos de un proceso distribuido.

C4ISR Architecture Framework es el marco de referencia arquitectnico promovido por el

Departamento de Defensa de Estados Unidos (DoD). Algunos de los otros marcos listados en esta seccin se inspiran en l, como es el caso de TOGAF. En la versin 2 de C4I, completada en diciembre de 1997, la definicin de arquitectura reconocida es exactamente la misma que despus se promulgara como cannica en IEEE 1471. Las vistas arquitectnicas homologadas son la Operacional (que identifica relaciones y necesidades de informacin), la de Sistemas (que vincula capacidades y caractersticas a requerimientos operacionales) y la Tcnica (que prescribe estndares y convenciones).

El marco de referencia arquitectnico de The Open Group (TOGAF) reconoce cuatro componentes

principales, uno de los cuales es un framework de alto nivel que a su vez define cuatro vistas: Arquitectura de Negocios, Arquitectura de Datos/Informacin, Arquitectura de Aplicacin y Arquitectura Tecnolgica. The Open Group propone un modelo de descripcin arquitectnica, Architecture Description Method (ADM) que se supone independiente de las tcnicas de modelado, aunque en la versin 7 se propone Metis como herramienta.

En 1995 Philippe Kruchten propuso su clebre modelo 4+1, vinculado al Rational Unified Process

(RUP), que define cuatro vistas diferentes de la arquitectura de software: (1) La vista lgica, que comprende las abstracciones fundamentales del sistema a partir del dominio de problemas. (2) La vista de proceso: el conjunto de procesos de ejecucin independiente a partir de las abstracciones anteriores. (3) La vista fsica: un mapeado del software sobre el hardware. (4) La vista de desarrollo: la organizacin esttica de mdulos en el entorno de desarrollo. El quinto elemento considera todos los anteriores en el contexto de casos de uso [Kru95]. Lo que acadmicamente se define como AS concierne a las dos primeras vistas. El modelo 4+1 se percibe hoy como un intento se reformular una arquitectura estructural y descriptiva en trminos de objeto y de UML. Con todo, las cuatro vistas de Kruchten forman parte del repertorio estndar de los practicantes de la disciplina.

En su introduccin a UML (1.3), Grady Booch, James Rumbaugh e Ivar Jacobson han formulado un

esquema de cinco vistas interrelacionadas que conforman la arquitectura de software, caracterizada en trminos parecidos a los que uno esperara encontrar en el discurso de la vertiente estructuralista. En esta perpectiva, la arquitectura de software (a la que se dedican muy pocas pginas) es un conjunto de decisiones significativas sobre (1) la organizacin de un sistema de software; (2) la seleccin de elementos estructurales y sus interfaces a travs de los cuales se constituye el sistema; (3) su comportamiento, segn resulta de las colaboraciones entre esos elementos; (4) la composicin de esos elementos estructurales y de comportamiento en subsistemas progresivamente mayores; (5) el estilo arquitectnico que gua esta organizacin: los elementos estticos y dinmicos y sus interfaces, sus colaboraciones y su composicin. Los autores proporcionan luego un esquema de cinco vistas posibles de la arquitectura de un sistema: (1) La vista de casos de uso, como la perciben los usuarios,

analistas y encargados de las pruebas; (2) la vista de diseo que comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solucin; (3) la vista de procesos que conforman los hilos y procesos que forman los mecanismos de sincronizacin y concurrencia; (4) la vista de implementacin que incluye los componentes y archivos sobre el sistema fsico; (5) la vista de despliegue que comprende los nodos que forma la topologa de hardware sobre la que se ejecuta el sistema [BRJ99: 26-27]. Aunque las vistas no estn expresadas en los mismos trminos estructuralistas que campean en su caracterizacin de la arquitectura, y aunque la relacin entre vistas y decisiones arquitectnicas es de simple yuxtaposicin informal de ideas antes que de integracin rigurosa, es natural inferir que las vistas que ms claramente se vinculan con la semntica arquitectnica son la de diseo y la de proceso.

En los albores de la moderna prctica de los patrones, Buschmann y otros presentan listas

discrepantes de vistas en su texto popularmente conocido como POSA [BMR+96]. En la primera se las llama arquitecturas, y son: (1) Arquitectura conceptual: componentes, conectores; (2) Arquitectura de mdulos: subsistemas, mdulos, exportaciones, importaciones; (3) Arquitectura de cdigo: archivos, directorios, bibliotecas, inclusiones; (4) Arquitectura de ejecucin: tareas, hilos, procesos. La segunda lista de vistas, por su parte, incluye: (1) Vista lgica: el modelo de objetos del diseo, o un modelo correspondiente tal como un diagrama de relacin; (2) Vista de proceso: aspectos de concurrencia y sincronizacin; (3) Vista fsica: el mapeo del software en el hardware y sus aspectos distribuidos; (4) Vista de desarrollo: la organizacin esttica del software en su entorno de desarrollo. Esta segunda lista coincide con el modelo 4+1 de Kruchten, pero sin tanto nfasis en el quinto elemento.

Bass, Clements y Kazman presentan en 1998 una taxonoma de nueve vistas, decididamente

sesgadas hacia el diseo concreto y la implementacin: (1) Estructura de mdulo; las unidades son asignaciones de tareas. (2) Estructura lgica o conceptual. Las unidades son abstracciones de los requerimientos funcionales del sistema. (3) Estructura de procesos o de coordinacin. Las unidades son procesos o threads. (4) Estructura fsica. (5) Estructura de uso. Las unidades son procedimientos o mdulos, vinculados por relaciones de presuncin-de-presencia-correcta. (6) Estructura de llamados. Las unidades son usualmente (sub)procedimientos, vinculados por invocaciones o llamados. (7) Flujo de datos. Las unidades son programas o mdulos, la relacin es de envo de datos. (8) Flujo de control; las unidades son programas, mdulos o estados del sistema. (9) Estructura de clases. Las unidades son objetos [BCK98]. Esta taxonoma de vista no coincide con ninguna otra.

La recomendacin IEEE Std 1471-2000 procura establecer una base comn para la descripcin de

arquitecturas de software, e implementa para ello tres trminos bsicos, que son arquitectura, vista y punto de vista. La arquitectura se define como la organizacin fundamental de un sistema, encarnada en sus componentes, las relaciones entre ellos y con su entorno, y los principios que gobiernan su

diseo y evolucin. Los elementos que resultan definitorios en la utilidad, costo y riego de un sistema son en ocasiones fsicos y otras veces lgicos. En otros casos ms, son principios permanentes o patrones que generan estructuras organizacionales duraderas. Trminos como vista o punto de vista son tambin centrales. En la recomendacin se los utiliza en un sentido ligeramente distinto al del uso comn. Aunque reflejan el uso establecido en los estndares y en la investigacin de ingeniera, el propsito del estndar es introducir un grado de formalizacin homogeneizando informalmente la nomenclatura. En dicha nomenclatura, un punto de vista (viewpoint) define un patrn o plantilla (template) para representar un conjunto de incumbencias (concerns) relativo a una arquitectura, mientras que una vista (view) es la representacin concreta de un sistema en particular desde una perspectiva unitaria. Un punto de vista permite la formalizacin de grupos de modelos. Una vista tambin se compone de modelos, aunque posee tambin atributos adicionales. Los modelos proporcionan la descripcin especfica, o contenido, de una arquitectura. Por ejemplo, una vista estructural consistira de un conjunto de modelos de la estructura del sistema. Los elementos de tales modelos incluiran componentes identificables y sus interfaces, as como interconexiones entre los componentes. La concordancia entre la recomendacin de IEEE y el concepto de estilo se establece con claridad en trminos del llamado punto de vista estructural. Otros puntos de vista reconocidos en la recomendacin son el conductual y el de interconexin fsica. El punto de vista estructural ha sido motivado (afirman los redactores del estndar) por el trabajo en lenguajes de descripcin arquitectnica (ADLs). El punto de vista estructural, dicen, se ha desarrollado en el campo de la AS desde 1994 y es hoy de amplio uso.

La estrategia de arquitectura de Microsoft define, en consonancia con las conceptualizaciones ms

generalizadas, cuatro vistas, ocasionalmente llamadas tambin arquitecturas: Negocios, Aplicacin, Informacin y Tecnologa [Platt02]. La vista que aqu interesa es la de la aplicacin, que incluye, entre otras cosas: (1) Descripciones de servicios automatizados que dan soporte a los procesos de negocios; (2) descripciones de las interacciones e interdependencias (interfaces) de los sistemas aplicativos de la organizacin, y (3) planes para el desarrollo de nuevas aplicaciones y la revisin de las antiguas, basados en los objetivos de la empresa y la evolucin de las plataformas tecnolgicas. Cada arquitectura, a su vez, se articula en vistas tambin familiares desde los das de OMT que son (1) la Vista Conceptual, cercana a la semntica de negocios y a la percepcin de los usuarios no tcnicos; (2) la Vista Lgica, que define los componentes funcionales y su relacin en el interior de un sistema, en base a la cual los arquitectos construyen modelos de aplicacin que representan la perspectiva lgica de la arquitectura de una aplicacin; (3) la Vista Fsica, que es la menos abstracta y que ilustra los componentes especficos de una implementacin y sus relaciones.

Ahora que se han examinado cules son las vistas que proponen los diferentes frameworks, habra que precisar mejor el significado especficamente arquitectnico de las vistas. Como expresa Rich Hilliard [Hil99],

a quien seguimos en este tratamiento, aunque expresiones tales como mltiples vistas son algo as como el Santo Grial de la ingeniera de software, de requerimientos y de sistemas, su estatus en la AS es bastante ms oscuro. Las razones para ello son mltiples. En primer lugar, no existe una fundamentacin coherente para su uso en la disciplina. En segundo trmino, muchos estudiosos las consideran problemticas, porque la existencia de mltiples vistas introduce problemas de integracin y consistencia entre las diferentes vistas. Sin embargo, los arquitectos practicantes las usan de todas maneras, porque simplifican la visualizacin de sistemas complejos.

La idea de contemplar un sistema complejo desde mltiples puntos de vista no es nativa de la AS contempornea, ni es una invencin de Kruchten, sino que se origina por lo menos en la dcada de 1970, en el trabajo de Douglas Ross sobre anlisis estructurado [Ross77]. La motivacin para introducir mltiples vistas radica en la separacin de incumbencias (separations of concerns). Las vistas se introdujeron como una herramienta conceptual para poder manejar la complejidad de lo que ya por aquel entonces se llamaban artefactos, tales como especificaciones de requerimientos o modelos de diseo. En las contribuciones ms tempranas, las mltiples vistas de un modelo se basaban en perspectivas fijas, puntos de vistas o viewpoints; casi siempre los puntos de vista eran dos, el funcional y el de datos, ninguno de los cuales aparece en arquitectura.

En la dcada de 1980, sin embargo, las vistas comenzaron a multiplicarse, al punto que se realizaron surveys interdisciplinarios y se organizaron conferencias especficas sobre la cuestin, como Viewpoints96. No hay un lmite necesario para el nmero de vistas posibles, ni un procedimiento formal para establecer lo que una vista debe o no abstraer. El estndar IEEE 1471 no delimita el nmero posible de vistas, ya que se estima que no puede haber acuerdo en ello, pero seala lineamientos para su constitucin y considera que un viewpoint es a una vista como una clase es a un objeto. Hay una lista corta de vistas que se usa en los textos generales de AS y una lista larga que gira en torno de UML, el cual especifica nueve clases de diagramas correspondientes a ocho vistas, como se indica en el cuadro. Diferentes textos de los mismos autores, por ejemplo [BRJ99] y [RJB00], utilizan distintas terminologas no conciliadas; vistas y puntos de vista no siempre se caracterizan como conceptos distintos y el uso de la terminologa, an en el interior de cada texto, es informal e inconsistente. Es difcil creer que esto se encuentra unificado de alguna manera. Cuando los promotores de UML hablan de arquitectura, a instancias de Kruchten, cambian su modelo de vistas por uno que se refiere no a puntos de perspectiva o a incumbencias de los participantes, sino a niveles de abstraccin; pero an as, como se ha visto, su definicin de arquitectura difiere de la definicin estndar. rea Estructural Vista Vista esttica Diagramas Diagrama de clases Conceptos principales Clase, asociacin, generalizacin, dependencia, realizacin, interfaz

Vista de casos de uso Vista de implementacin Vista de despliegue Dinmica

Diagramas de casos de uso Diagrama de componentes Diagrama de despliegue

Caso de uso, actor, asociacin, extensin, inclusin, generalizacin de casos de uso Componente, interfaz, dependencia, realizacin Nodo, componente, dependencia, localizacin Estado, evento, transicin, accin Estado, actividad, transicin de terminacin, divisin, unin Interaccin, objeto, mensaje, activacin Colaboracin, interaccin, rol de colaboracin, mensaje Paquete, subsistema, modelo

Vista de mquinas de Diagrama de estados estados Vista de actividad Diagrama de actividad Diagrama de secuencia Vista de interaccin Diagrama de colaboracin Diagrama de clases

Gestin del Vista de gestin del modelo modelo

Tabla 2 - Vistas y diagramas de UML, basado en [RJB00: 22]

Como lo subraya Hilliard, en sus textos iniciales la modalidad clsica de la AS, encarnada en Garlan y Shaw, no habla de vistas en absoluto; la AS clsica se funda en una vista singular e implcita, de carcter estructural. Muchos arquitectos de la corriente principal evitan hablar de vistas, porque cuando las ellas proliferan se hace necesario o bien elaborar lenguajes formales especficos para tratar cada una de ellas, o bien multiplicar salvajemente las extensiones del lenguaje unificado. Sin duda las vistas son una simplificacin conveniente, o ms bien un principio de orden; pero su abundancia y sus complicadas relaciones recprocas generan tambin nuevos rdenes de complejidad.

Podra discutirse el concepto y la articulacin de las diferentes vistas un largo rato, y de hecho los muchos simposios que han habido sobre el particular fueron de inters pero inconcluyentes. Se acostumbra poner las vistas que denotan niveles de abstraccin en cuadros superpuestos, por ejemplo, como si fueran anlogas a las capas del modelo OSI, pero son ambas representaciones estrictamente homlogas? Constituye el conjunto de las vistas un sistema? Por qu cada vez que se enumeran los artefactos caractersticos de cada vista aparece la palabra etctera o la expresin elementos principales?

Procesos y Metodologas En los diferentes marcos, las vistas estticas se corresponden con las perspectivas particulares de los diferentes participantes (stakeholders), mientras que las vistas dinmicas tienen que ver con etapas del proceso, ciclo de vida o metodologa, caracterizadas como requerimiento, anlisis, diseo (o construccin, o modelado), implementacin, integracin (prueba de conformidad, testing, evaluacin). La terminologa, lo mismo que la articulacin temporal del proceso o el ciclo, depende de cada marco. Llegando al territorio de la metodologa, hay que decir que durante varios aos la AS discurri sin elaborarlas ms que circunstancialmente, como si se estimara compatible con las prcticas establecidas en ingeniera de

software, cualesquiera fuesen: RUP, RAD, RDS, ARIS, PERA, CIMOSA, GRAI, GERAM, CMM. Hoy en da la metodologa dominante en la industria es tal vez el Modelo de Madurez de la Capacidad (CMM), aunque el SEI no la considera formalmente como tal.

Desde 1998 y cada vez con mayor intensidad, sin embargo, el SEI y otros organismos comenzaron a elaborar mtodos especficos de procesos de ingeniera que sistematizan el rol de la arquitectura en la totalidad del proceso, desde la elicitacin de requerimientos hasta la terminacin. Algunos de esos mtodos son Architecture Based Design (ABD), Software Architecture Analysis Method (SAAM), Quality Attribute Workshops (QAW), Quality Attribute-Oriented Software Architecture Design Method (QASAR), AttributeDriven Design (ADD), Architecture Tradeoff Analysis Method (ATAM), Active Review for Intermediate Design (ARID), Cost-Benefits Analysis Method (CBAM), Family-Architecture Analysis Method (FAAM), Architecture Level Modifiability Analysis (ALMA), y Software Architecture Comparison Analysis Method (SACAM). Al lado de esos mtodos est surgiendo un nutrido conjunto de tcnicas de documentacin; mtodos, tcnicas y estudios de casos se analizarn en este estudio en documentos separados. Habiendo al menos una docena de mtodos complejamente engranados entre s, el lector puede perderse con facilidad en un laberinto bibliogrfico donde no siempre se discierne cules de estos mtodos incluyen a cules otros, cules son sus relaciones con tcnicas consagradas de ingeniera, cules se encuentran vigentes y cules obsoletos. Un documento actual que describe a grandes rasgos la mayora de esos mtodos es [KNK03]. En general, la AS de la corriente principal todava no se ha expedido en relacin con los llamados mtodos giles. No hay un solo mtodo, sino una multiplicidad de posturas ms o menos radicales y combativas: Extreme Programming, SCRUM, Crystal Methods Framework, Feature-Driven Development, DSDM, Lean Development, Adaptive Software Development, Agile Modeling, Pragmatic Programming [ASR+02] [CLC03]. De hecho, la comunidad de los metodlogos, que opera a una cierta distancia de las iniciativas formales de la AS, se encuentra dividida tras lo que ha sido y sigue siendo el gran debate metodolgico entre los mtodos pesados (o rigurosos) de tipo SEI/CMM por un lado y los mtodos giles por el otro [Hig01]. Los tericos de cada bando han sido, entre otros, Tom De Marco, Ed Yourdon y Tim Lister en la faccin rigurosa y Ken Orr, Jim Highsmith, Martin Fowler y Michael Jackson del lado gil-extremo, con Philippe Kruchten y RUP buscando establecerse en ambos terrenos.

Ambos grupos operan en el contexto de la crisis del software, que se da por sentada, alegando que es la mentalidad del bando opuesto lo que la ha ocasionado. Los pesados, mirados por los giles como formalistas fracasados, enfatizan el modelado, el control y la documentacin escrupulosa; los giles, acusados por los pesados de hackers irresponsables que pretenden imponer sus juguetes en la empresa, no slo desprecian los modelos (formales o informales) sino que incluso ocasionalmente ponen en tela de juicio hasta a los propios patrones de diseo [Fow01]. Ese tema tambin ser tratado en un estudio aparte.

En lo que respecta a la estrategia arquitectnica de Microsoft, el marco general de Microsoft Solutions Framework, versin 3, no se expide sobre metodologas especficas y da cabida a una gran cantidad de alternativas, desde las densas a las ligeras. Abundan en MSF 3 referencias a mtodos rpidos y giles, a travs de citas y conceptos de una de las figuras cardinales de Cutter Consortium, Martin Fowler. La documentacin de MSF ratifica su adecuacin tanto para el CMM de SEI o UPM como para los mtodos giles en ambientes que requieren un alto grado de adaptabilidad [MS03].

Abstraccin El concepto de abstraccin (que a veces se usa en el sentido del proceso de abstraer, otra para designar una entidad) ha sufrido tambin diversas acepciones, con un ncleo de significados comn. Las diferencias en el uso del concepto de abstraccin ayudan tambin a identificar las diversas corrientes en el seno de la AS. La definicin que proporciona Grady Booch, por ejemplo, revela que el autor identifica la abstraccin arquitectnica con el encapsulamiento propio de la tecnologa de objetos: Una abstraccin escribe Booch denota las caractersticas esenciales de un objeto que lo distinguen de otras clases de objeto y provee de este modo delimitaciones conceptuales bien definidas, relativas a la perspectiva del observador [Boo91].

El concepto de abstraccin (que a veces se usa en el sentido del proceso de abstraer, otra para designar una entidad abstracta) ha sufrido tambin diversas formulaciones sintcticas, con un ncleo de significados comn. En ltimo anlisis, la abstraccin siempre conlleva una heurstica positiva al lado de una negacin. Tanto para la IEEE como para Rumbaugh, Shaw y otros autores, la abstraccin consiste en extraer las propiedades esenciales, o identificar los aspectos importantes, o examinar selectivamente ciertos aspectos de un problema, posponiendo o ignorando los detalles menos sustanciales, distractivos o irrelevantes.

La idea de abstraccin forma parte de lo que acaso sea la pieza conceptual ms importante de la AS, el concepto de estilo; un estilo se identifica a grandes rasgos o, como se dice habitualmente, en un estilo menos es ms. La misma idea prevalece en todos los conceptos y procedimientos que se consideran arquitectnicos. Para Len Bass, Paul Clements y Rick Kazman [BCK98], si una decisin debe posponerse hasta el momento de tratar las cosas a un bajo nivel, no se trata de una decisin de arquitectura. Clements y Northrop [CN96] sostienen que el trabajo de Garlan y Shaw sobre los estilos arquitectnicos nos ensea que aunque los programas pueden combinarse de maneras prcticamente infinitas, hay mucho que ganar si nos restringimos a un conjunto relativamente pequeo de elecciones cuando se trata de cooperacin e interaccin. Las ventajas incluyen mejor reutilizacin, mejores anlisis, menor tiempo se seleccin y mayor interoperabilidad. Menos es ms figura, de hecho, en el ttulo y en los contenidos de numerosos papers de la profesin [MB02] [CN96]. Conceptos como el de estilo, o marcos como MSF, revelan su naturaleza arquitectnica en su abstraccin y en su generalidad.

Escenarios Esta es una nocin arquitectnica importante y se encuentra en la base de muchos de los mtodos de diseo y desarrollo basados en arquitectura, como ALMA, SAAM y ATAM. Hay que ser precavidos y advertir desde el comienzo que lo que habitualmente se traduce como escenario no es estrictamente lo que en lengua castellana se designa como tal; la traduccin correcta debera ser ms bien guin o libreto. La traduccin literal del trmino no hace ms que aportar confusin. Desde Kruchten en adelante, se reconoce que los escenarios se dividen en dos categoras: casos de uso (secuencias de responsabilidades) y casos de cambio (modificaciones propuestas al sistema).

Los escenarios han sido bsicamente tcnicas que se implementan en la elicitacin de los requerimientos, particularmente en relacin a los operadores de sistemas. Tpicamente, la tcnica comienza instrumentando sesiones de brainstorming. Tambin se han utilizado escenarios como mtodo para comparar alternativas de diseo. Los escenarios describen una utilizacin anticipada o deseada del sistema, y tpicamente se expresan en una frase; Kazman, Abowd, Bass y Clements proponen tambin llamarlos vietas [KAB+96].

Segn algunas definiciones, como la de Clements y Northrop [CN96], los escenarios son algo as como libretos (en el sentido teatral o cinematogrfico del trmino) correspondientes a las distintas piezas de funcionalidad de un sistema. Se los considera tiles para analizar una vista determinada [Cle95a] o para mostrar la forma en que los elementos de mltiples vistas se relacionan entre s [Kru95]. Pueden concebirse tambin como una abstraccin de los requerimientos ms importantes de un sistema. Los escenarios se describen mediante texto comn en prosa utilizando lo que se llama un script y a veces se describen mediante dibujos, como por ejemplo diagramas de interaccin de objeto. Se acostumbra utilizar UML (en el contexto de 4+1) no tanto como recurso de modelado que despus generar alguna clase de cdigo, sino como instrumento de dibujo ms o menos informal; pero los propios manuales de UML y los expertos mundiales en casos de uso (David Anderson, Martin Fowler, Alistair Cockburn) recomiendan desarrollar los escenarios de requerimiento en texto, no en diagramas. Algunos autores estiman que se trata de una herramienta importante para relacionar vistas arquitectnicas, porque recorriendo un escenario puede mostrar las formas en que fragmentos o escenas de esas vistas se corresponden entre s. Los mtodos propios de la arquitectura basada en escenarios se analizan tambin en un documento aparte.

1.3 Diagramacin.
Campos de la Arquitectura de Software

La AS es hoy en da un conjunto inmenso y heterogneo de reas de investigacin terica y de formulacin prctica, por lo que conviene aunque ms no sea enumerar algunos de sus campos y sus focos. Una

semblanza semejante (de la que aqu se proporciona slo un rudimento) dudosamente debera ser esttica. La AS comenz siendo una abstraccin descriptiva puntual que en los primeros aos no investig de manera sistemtica ni las relaciones que la vinculaban con los requerimientos previos, ni los pasos metodolgicos a dar luego para comenzar a componer el diseo. Pero esa sincronicidad estructuralista no pudo sostenerse. Por el contrario, dara la impresin que, a medida que pasa el tiempo, la AS tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la ingeniera de software, slo que a un mayor nivel de abstraccin y agregando una nueva dimensin reflexiva en lo que concierne a la fundamentacin formal del proceso.

Hay unas pocas caracterizaciones (y mucha actividad de copiado y pegado) en torno de las reas que componen el territorio. David Garlan y Dewayne Perry, en su introduccin al volumen de abril de 1995 de IEEE Transactions on Software Engineering dedicado a la AS, en el cual se delinean las reas de investigacin ms promisorias, enumeran las siguientes:

Lenguajes de descripcin de arquitecturas Fundamentos formales de la AS (bases matemticas, caracterizaciones formales de propiedades

extra-funcionales tales como mantenibilidad, teoras de la interconexin, etctera).

Tcnicas de anlisis arquitectnicas Mtodos de desarrollo basados en arquitectura Recuperacin y reutilizacin de arquitectura Codificacin y gua arquitectnica Herramientas y ambientes de diseo arquitectnico Estudios de casos

Fundamental en la concepcin de Clements y Northrop [CN96] es el criterio de reusabilidad como uno de los aspectos que ms hacen por justificar la disciplina misma. Segn estos autores, el estudio actual de la AS puede ser visto como un esfuerzo ex post facto para proporcionar un almacn estructurado de este tipo de informacin reutilizable de diseo de alto nivel propio de una familia (en el sentido de Parnas). De tal manera, las decisiones de alto nivel inherentes a cada miembro de una familia de programas no necesitan ser re-inventadas, re-validadas y re-descriptas. Un razonamiento arquitectnico es adems un argumento sobre las cuestiones estructurales de un sistema. Se dira tambin que el concepto de estilo es la encarnacin principal del principio de reusabilidad en el plano arquitectnico. Paul Clements [Cle96b] define cinco temas fundamentales en torno de los cuales se agrupa la disciplina:

Diseo o seleccin de la arquitectura: Cmo crear o seleccionar una arquitectura en base de

requerimientos funcionales, de rendimiento o de calidad.

Representacin de la arquitectura: Cmo comunicar una arquitectura. Este problema se ha

manifestado como el problema de la representacin de arquitecturas utilizando recursos lingsticos, pero el problema tambin incluye la seleccin del conjunto de informacin a ser comunicada.

Evaluacin y anlisis de la arquitectura: Cmo analizar una arquitectura para predecir cualidades

del sistema en que se manifiesta. Un problema semejante es cmo comparar y escoger entre diversas arquitecturas en competencia.

Desarrollo y evolucin basados en arquitectura: Cmo construir y mantener un sistema dada una

representacin de la cual se cree que es la arquitectura que resolver el problema correspondiente.

Recuperacin de la arquitectura: Cmo hacer que un sistema legacy evolucione cuando los cambios

afectan su estructura; para los sistemas de los que se carezca de documentacin confiable, esto involucra primero una arqueologa arquitectnica que extraiga su arquitectura.

Mary Shaw [Shaw01] considera que en el 2001 los campos ms promisorios de la AS siguen teniendo que ver con el tratamiento sistemtico de los estilos, el desarrollo de lenguajes de descripcin arquitectnica, la formulacin de metodologas y (ahora) el trabajo con patrones de diseo. Se requieren todava modelos precisos que permitan razonar sobre las propiedades de una arquitectura y verificar su consistencia y completitud, as como la automatizacin del proceso de anlisis, diseo y sntesis. Sugiere que debe aprenderse una leccin a partir de la experiencia de la ingeniera de software, la cual no obstante haberse desenvuelto durante treinta aos no ha logrado plasmar un conjunto de paradigmas de investigacin comparable al de otras reas de las ciencias de la computacin. Estima que la AS se encuentra ya en su fase de desarrollo y extensin, pero que tanto las ideas como las herramientas distan de estar maduras.

Un campo que no figura en estas listas pero sobre el cual se est trabajando intensamente es en el de la coordinacin de los ADLs que sobrevivan con UML 2.0 por un lado y con XML por el otro. Ningn lenguaje de descripcin arquitectnica en el futuro prximo (excepto los que tengan un nicho tcnico muy particular) ser viable si no satisface esos dos requisitos.

Los ejercicios que pueden hacerse para precisar los campos de la AS son incontables. Ahora que la AS se ha abismado en el desarrollo de metodologas, hace falta, por ejemplo, establecer con ms claridad en qu difieren sus elaboraciones en torno del diseo, del anlisis de requerimientos o de justificacin econmica de las llevadas a cabo por la ingeniera de software. Asimismo, se est esperando todava una lista sistemtica y exhaustiva que describa los dominios de incumbencia de la disciplina, as como un examen del riesgo de

duplicacin de esfuerzos entre campos disciplinarios mal comunicados, una situacin que a primera vista parecera contradictoria con el principio de reusabilidad.

2 Diseo orientado a objetos.

Modalidades y tendencias

En la dcada de 1990 se establece definitivamente la AS como un dominio todava hoy separado de manera confusa de ese marco global que es la ingeniera y de esa prctica puntual que es el diseo. Aunque no hay un discurso explcito y autoconsciente sobre escuelas de AS, ni se ha publicado un estudio reconocido y sistemtico que analice las particularidades de cada una, en la actualidad se pueden distinguir a grandes rasgos unas seis corrientes. Algunas distinciones estn implcitas por ejemplo en [MT00], pero la bibliografa sobre corrientes y alternativas prcticamente no existe y la que sigue habr de ser por un tiempo una de las pocas propuestas contemporneas sobre el particular.

Ahora bien, articular una taxonoma de estrategias no admite una solucin simple y determinista. En distintos momentos de su trayectoria, algunos practicantes de la AS se mueven ocasionalmente de una tctica a otra, o evolucionan de un punto de vista ms genrico a otro ms particular, o realizan diferentes trabajos operando en marcos distintos. Adems, con la excepcin del gran debate metodolgico entre mtodos pesados y ligeros [Hig01], las discusiones entre las distintas posturas rara vez se han manifestado como choques frontales entre ideologas irreconciliables, por lo que a menudo hay que leer entre lneas para darse cuenta que una afirmacin cualquiera es una crtica a otra manera de ver las cosas, o trasunta una toma definida de posicin. Fuera de la metodologa, el nico factor reconocible de discordia ha sido, hasta la fecha, la preminencia de UML y el diseo orientado a objetos. Todo lo dems parece ser ms o menos negociable. La divisin preliminar de escuelas de AS que proponemos es la siguiente:

1) Arquitectura como etapa de ingeniera y diseo orientada a objetos. Es el modelo de James Rumbaugh, Ivar Jacobson, Grady Booch, Craig Larman y otros, ligado estrechamente al mundo de UML y Rational. No cabe duda que se trata de una corriente especfica: Rumbaugh, Jacobson y Booch han sido llamados Los Tres Amigos; de lo que s puede dudarse es que se trate de una postura arquitectnica. En este postura, la arquitectura se restringe a las fases iniciales y preliminares del proceso y concierne a los niveles ms elevados de abstraccin, pero no est sistemticamente ligada al requerimiento que viene antes o a la composicin del diseo que viene despus. Lo que sigue al momento arquitectnico es business as usual, y a cualquier configuracin, topologa o morfologa de las piezas del sistema se la llama arquitectura. En esta escuela, si bien se reconoce el valor primordial de la abstraccin (nadie despus de Dijkstra osara oponerse a ello) y del ocultamiento de informacin promovido por Parnas, estos conceptos tienen que ver

ms con el encapsulamiento en clases y objetos que con la visin de conjunto arquitectnica. Para este movimiento, la arquitectura se confunde tambin con el modelado y el diseo, los cuales constituyen los conceptos dominantes. En esta corriente se manifiesta predileccin por un modelado denso y una profusin de diagramas, tendiente al modelo metodolgico CMM o a UPM; no hay, empero, una precripcin formal. Importa ms la abundancia y el detalle de diagramas y tcnicas disponibles que la simplicidad de la visin de conjunto. Cuando aqu se habla de estilos, se los confunde con patrones arquitectnicos o de diseo [Lar03]. Jams se hace referencia a los lenguajes de descripcin arquitectnica, que representan uno de los assets reconocidos de la AS; sucede como si la disponibilidad de un lenguaje unificado de modelado los tornara superfluos. La definicin de arquitectura que se promueve en esta corriente tiene que ver con aspectos formales a la hora del desarrollo; esta arquitectura es isomorfa a la estructura de las piezas de cdigo. Una definicin tpica y demostrativa sera la de Grady Booch; para l, la AS es la estructura lgica y fsica de un sistema, forjada por todas las decisiones estratgicas y tcticas que se aplican durante el desarrollo [Boo91]. Otras definiciones revelan que la AS, en esta perspectiva, concierne a decisiones sobre organizacin, seleccin de elementos estructurales, comportamiento, composicin y estilo arquitectnico susceptibles de ser descriptas a travs de las cinco vistas clsicas del modelo 4+1 de Kruchten [Kru95] [BRJ99: 26-28].

2.1 Diseo del sistema en base a procesos.

Arquitectura estructural, basada en un modelo esttico de estilos, ADLs y vistas. Constituye la corriente fundacional y clsica de la disciplina. Los representantes de esta corriente son todos acadmicos, mayormente de la Universidad Carnegie Mellon en Pittsburgh: Mary Shaw, Paul Clements, David Garlan, Robert Allen, Gregory Abowd, John Ockerbloom. Se trata tambin de la visin de la AS dominante en la academia, y aunque es la que ha hecho el esfuerzo ms importante por el reconocimiento de la AS como disciplina, sus categoras y herramientas son todava mal conocidas en la prctica industrial. En el interior del movimiento se pueden observar distintas divisiones. Hay una variante informal de boxologa y una vertiente ms formalista, representada por el grupo de Mark Moriconi en el SRI de Menlo Park. En principio se pueden reconocer tres modalidades en cuanto a la formalizacin; los ms informales utilizan descripciones verbales o diagramas de cajas, los de talante intermedio se sirven de ADLs y los ms exigentes usan lenguajes formales de especificacin como CHAM y Z. En toda la corriente, el diseo arquitectnico no slo es el de ms alto nivel de abstraccin, sino que adems no tiene por qu coincidir con la configuracin explcita de las aplicaciones; rara vez se encontrarn referencias a lenguajes de programacin o piezas de cdigo, y en general nadie habla de clases o de objetos. Mientras algunos participantes excluyen el modelo de datos de las incumbencias de la AS (Shaw, Garlan, etc), otros insisten en su relevancia (Medvidovic, Taylor). Todo estructuralismo es esttico; hasta fines del siglo XX, no est muy claro el tema de la posicin del modelado arquitectnico en el ciclo de vida.

2.1.1 Actividades y casos de uso.

Fase de Planificacin y Especificacin de Requisitos

Esta fase se corresponde con la Especificacin de Requisitos tradicional ampliada con un Borrador de Modelo Conceptual y con una definicin de Casos de Uso de alto nivel. En esta fase se decidira si se aborda la construccin del sistema mediante desarrollo orientado a objetos o no, por lo que, en principio, es independiente del paradigma empleado posteriormente.

IV.2.1 Actividades Las actividades de esta fase son las siguientes: Definir el Plan-Borrador. Crear el Informe de Investigacin Preliminar. Definir los Requisitos. Registrar Trminos en el Glosario. (continuado en posteriores fases) Implementar un Prototipo. (opcional) Definir Casos de Uso (de alto nivel y esenciales). Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior) Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior) Refinar el Plan. El orden no es estricto, lo normal es que las distintas actividades se solapen en el tiempo. Esto sucede tambin en las actividades de las fases de diseo, que se vern ms adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificacin de proyectos software, como las correspondientes a creacin de planes e informes preliminares. IV.2.2 Requisitos El formato del documento de Especificacin de Requisitos no est definido en UML, pero se ha incluido este punto para resaltar que la actividad de definicin de requisitos es un paso clave en la creacin de cualquier producto software. Para entender y describir los requisitos la tcnica de casos de uso constituye una valiosa ayuda. IV.2.3 Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales. Ntese que UML no define un formato para describir un caso de uso. Tan slo define la manera de representar la relacin entre actores y casos de uso en un diagrama: El Diagrama de Casos de Uso, definido en la pgina 9. Sin embargo, un caso de uso individual no es un diagrama, es un documento de texto. En la siguiente seccin se define el formato textual para la descripcin de un caso de uso que se va a utilizar en este documento.. Un escenario es un camino concreto a travs del caso de uso, una secuencia especfica de acciones e interacciones entre los actores y el sistema. Ms adelante se ver la representacin de los escenarios correspondientes a un caso de uso por medio de Diagramas de Secuencia. En un primer momento interesa abordar un caso de uso desde un nivel de abstraccin alto, utilizando el formato de alto nivel. Cuando se quiere describir un caso de uso con ms detalle se usa el formato expandido. IV.2.3.1 Casos de Uso de Alto Nivel El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se est usando un cajero automtico: - Caso de Uso: Realizar Reintegro - Actores: Cliente - Tipo: primario

- Descripcin: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va. En un caso de uso descrito a alto nivel la descripcin es muy general, normalmente se condensa en dos o tres frases. Es til para comprender el mbito y el grado de complejidad del sistema. IV.2.3.2 Casos de Uso Expandidos Los casos de uso que se consideren los ms importantes y que se considere que son los que ms influencian al resto, se describen a un nivel ms detallado: en el formato expandido. La principal diferencia con un caso de uso de alto nivel est en que incluye un apartado de Curso Tpico de Eventos, pero tambin incluye otros apartados como se ve en el siguiente ejemplo: - Caso de Uso: Realizar Reintegro - Actores: Cliente (iniciador) - Propsito: Realizar una operacin de reintegro de una cuenta del banco - Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va. - Tipo: primario y esencial - Referencias: Funciones: R1.3, R1.7 - Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. 2. Pide la clave de identificacin. 3. Introduce la clave. 4. Presenta las opciones de operaciones disponibles. 5. Selecciona la operacin de Reintegro. 6. Pide la cantidad a retirar. 7. Introduce la cantidad requerida. 8. Procesa la peticin y da el dinero solicitado. Devuelve la tarjeta y genera un recibo. 9. Recoge la tarjeta. 10. Recoge el recibo. 11. Recoge el dinero y se va. Cursos Alternativos: Lnea 4: La clave es incorrecta. Se indica el error y se cancela la operacin. Lnea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operacin. El significado de cada apartado de este formato es como sigue: - Caso de Uso: Nombre del Caso de Uso - Actores: Lista de actores (agentes externos), indicando quin inicia el caso de uso. Los actores son normalmente roles que un ser humano desempea, pero puede ser cualquier tipo de sistema. - Propsito: Intencin del caso de uso. - Visin General: Repeticin del caso de uso de alto nivel, o un resumen similar.

- Tipo: 1. primario, secundario u opcional (descritos ms adelante). 2. esencial o real (descritos ms adelante). - Referencias: Casos de uso relacionados y funciones del sistema que aparecen en los requisitos. - Curso Tpico de Eventos: Descripcin de la interaccin entre los actores y el sistema mediante las acciones numeradas de cada uno. Describe la secuencia ms comn de eventos, cuando todo va bien y el proceso se completa satisfactoriamente. En caso de haber alternativas con grado similar de probabilidad se pueden aadir secciones adicionales a la seccin principal, como se ver ms adelante. - Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la descripcin de la excepcin. IV.2.3.3 Identificacin de Casos de Uso La identificacin de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisin de los documentos de requisitos existentes, y en el uso de la tcnica de brainstorming entre los miembros del equipo de desarrollo. Como gua para la identificacin inicial de casos de uso hay dos mtodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organizacin. 2. Para cada actor, identificar los procesos que inicia o en los que participa. b) Basado en Eventos 1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso. Ejemplos de casos de uso: Pedir un producto. Matricularse en un curso de la facultad. Comprobar la ortografa de un documento en un procesador de textos. Comprar un libro en una tienda de libros en Internet IV.2.3.4 Identificacin de los Lmites del Sistema En la descripcin de un caso de uso se hace referencia en todo momento al sistema. Para que los casos de uso tengan un significado completo es necesario que el sistema est definido con precisin. Al definir los lmites del sistema se establece una diferenciacin entre lo que es interno y lo que es externo al sistema. El entorno exterior se representa mediante los actores. Ejemplos de sistemas son: El hardware y software de un sistema informtico. Un departamento de una organizacin. Una organizacin entera. Si no se est haciendo reingeniera del proceso de negocio lo ms normal es escoger como sistema el primero de los ejemplos: el hardware y el software del sistema que se quiere construir. IV.2.3.5 Tipos de Casos de Uso a) Segn Importancia Para establecer una primera aproximacin a la priorizacin de casos de uso que identifiquemos los vamos a distinguir entre:

 Primarios: Representan los procesos principales, los ms comunes, como Realizar Reintegro en el caso del cajero automtico. Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales como Aadir Nueva Operacin. Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. b) Segn el Grado de Compromiso con el Diseo En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solucin, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnologa y de la implementacin. Un caso de uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstraccin. Por el contrario, un caso de uso real describe concretamente el proceso en trminos del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta a un tipo de interfaz especfica, y se baja a detalles como pantallas y objetos en las mismas. Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero automtico tenemos la siguiente descripcin del Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura para tarjetas. 2. Pide el PIN (Personal Identification Number). 3. Introduce el PIN a travs del teclado numrico. 4. Presenta las opciones de operaciones disponibles. 5. etc. 6. etc. En principio, los casos de uso reales deberan ser creados en la fase de Diseo de Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definicin de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida. No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de compromiso con el diseo es un continuo, y una descripcin especfica de un caso de uso estar situada en algn punto de la lnea entre Casos de Uso Esenciales y Reales, normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros. IV.2.3.6 Consejos Relativos a Casos de Uso a) Nombre El nombre de un Caso de Uso debera ser un verbo, para enfatizar que se trata de un proceso, por ejemplo: Comprar Artculos o Realizar Pedido. b) Alternativas equiprobables Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas opciones, todas ellas consideradas normales se puede completar el Curso Tpico de Eventos con secciones adicionales. As, si en un determinado nmero de lnea hay una bifurcacin se pueden poner opciones que dirigen el caso de uso a una seccin que se detalla al final del Curso Tpico de Eventos, en la siguiente forma: - Curso Tpico de Eventos:

- Seccin: Principal Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando Actor llega al sistema. 2. Pide la operacin a realizar. 3. Escoge la operacin A. 4. Presenta las opciones de pago. 5. Selecciona el tipo de pago: a. Si se paga al contado ver seccin Pago al Contado. b. Si se paga con tarjeta ver seccin Pago con Tarjeta. 6. Genera recibo. 7. Recoge el recibo y se va. Cursos Alternativos: Lneas 3 y 5: Selecciona Cancelar. Se cancela la operacin. - Seccin: Pago al Contado Accin del Actor Respuesta del Sistema 1. Mete los billetes correspondientes 2. Coge los billetes y sigue pidiendo dinero hasta que la cantidad est satisfecha 3. Devuelve el cambio. Cursos Alternativos: Lnea 3: No hay cambio suficiente. Se cancela la operacin. - Seccin: Pago con Tarjeta ... IV.2.4 Construccin del Modelo de Casos de Uso Para construir el Modelo de Casos de Uso en la fase de Planificacin y Especificacin de Requisitos se siguen los siguientes pasos: 1. Despus de listar las funciones del sistema, se definen los lmites del sistema y se identifican los actores y los casos de uso. 2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios, secundarios u opcionales. 3. Se dibuja el Diagrama de Casos de Uso. 4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se ilustran tales relaciones en el Diagrama de Casos de Uso. 5. Los casos de uso ms crticos, importantes y que conllevan un mayor riesgo, se describen en el formato expandido esencial. Se deja la definicin en formato expandido esencial del resto de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la complejidad del problema de una sola vez. 6. Se crean casos de uso reales slo cuando: Descripciones ms detalladas ayudan significativamente a incrementar la comprensin del problema. El cliente pide que los procesos se describan de esta forma. 7. Ordenar segn prioridad los casos de uso (este paso se va a ver a continuacin). IV.2.5 Planificacin de Casos de Uso segn Ciclos de Desarrollo La decisin de qu partes del sistema abordar en cada ciclo de desarrollo se va a tomar basndose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementacin de uno o ms casos de uso, o versiones simplificadas de casos de uso. Se

asigna una versin simplificada cuando el caso de uso completo es demasiado complejo para ser tratado en un solo ciclo (ver Figura 37).

Para tomar la decisin de qu casos de uso se van a tratar primero es necesario ordenarlos segn prioridad. Las caractersticas de un caso de uso especfico que van a hacer que un caso de uso tenga una prioridad alta son las siguientes: a. Impacto significativo en el diseo de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del dominio o requiere persistencia en los datos. b. Se obtiene una mejor comprensin del diseo con un nivel de esfuerzo relativamente bajo. c. Incluye funciones complejas, crticas en el tiempo o de nivel elevado de riesgo. d. Implica bien un trabajo de investigacin significante, o bien el uso de una tecnologa nueva o arriesgada. e. Representa un proceso de gran importancia en la lnea de negocio. f. Supone directamente un aumento de beneficios o una disminucin de costes. Para realizar la clasificacin se puede asignar a cada caso de uso una valoracin numrica de cada uno de estos puntos, para conseguir una puntuacin total aplicando pesos a cada apartado. En la siguiente tabla se muestra un ejemplo de tal tipo de clasificacin: Peso 3 2 4 1 3 4 Suma Caso de Uso a b c d e f Realizar reintegro 5 4 1 0 5 2 50 ... IV.2.5.1 Caso de Uso Inicializacin Prcticamente todos los sistemas van a tener un caso de uso Inicializacin. Aunque puede ser que no tenga una prioridad alta en la clasificacin realizada segn el punto anterior, normalmente va a interesar que sea desarrollado desde el principio. Inicialmente se desarrolla una versin simplificada, que se va completando en cada ciclo de desarrollo para

satisfacer las necesidades de inicializacin de los casos de uso que se tratan en dicho ciclo. As se tiene un sistema en cada ciclo de desarrollo que puede funcionar.
http://www.clikear.com/manuales/uml/faseconstruccionaltonivel.asp 2.1.2 Interfaces de usuario. http://www.sia.eui.upm.es/docent/IU/TemaIU1.ppt#257,2,Diapositiva 2 http://www.sia.eui.upm.es/docent/iu.html

Conceptos Generales La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware y software de una computadora que presentan informacin al usuario y le permiten interactuar con la informacin y con el computadora. Tambin se puede considerar parte de la IU la documentacin (manuales, ayuda, referencia, tutoriales) que acompaa al hardware y al software. Si la IU est bien diseada, el usuario encontrar la respuesta que espera a su accin. Si no es as puede ser frustrante su operacin, ya que el usuario habitualmente tiende a culparse a s mismo por no saber usar el objeto. Los programas son usados por usuarios con distintos niveles de conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz vlida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interaccin que ms se adece a sus objetivos en cada momento. La mayora de los programas y sistemas operativos ofrecen varias formas de interaccin al usuario. Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseador (analoga de la construccin de una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a travs de su experiencia. El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones adecuadas para modificar el mismo. Los modelos subyacen en la interaccin con las computadoras, de ah su importancia. Modelo del usuario: El usuario tiene su visin personal del sistema, y espera que ste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudindolo, ya sea realizando tests de usabilidad, entrevistas, o a travs de una realimentacin. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo.

Para ello son de gran utilidad las metforas, que asocian un dominio nuevo a uno ya conocido por el usuario. Un ejemplo tpico es la metfora del escritorio, comn a la mayora de las interfaces grficas actuales. Modelo del diseador: El diseador mezcla las necesidades, ideas, deseos del usuario y los materiales de que dispone el programador para disear un producto de software. Es un intermediario entre ambos. El modelo del diseador describe los objetos que utiliza el usuario, su presentacin al mismo y las tcnicas de interaccin para su manipulacin. Consta de tres partes: presentacin, interaccin y relaciones entre los objetos (Figura 1). La presentacin es lo que primero capta la atencin del usuario, pero ms tarde pasa a un segundo plano, y adquiere ms importancia la interaccin con el producto para poder satisfacer sus expectativas. La presentacin no es lo ms relevante y un abuso en la misma (por ejemplo, en el color) puede ser contraproducente, distrayendo al usuario. La segunda parte del modelo define las tcnicas de interaccin del usuario, a travs de diversos dispositivos. La tercera es la ms importante, y es donde el diseador determina la metfora adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia arriba. Una vez definida la metfora y los objetos del interfaz, los aspectos visuales saldrn de una manera lgica y fcil. Estos modelos deben estar claros para los participantes en el desarrollo de un producto, de forma que se consiga una interfaz atractiva y a la vez efectiva para el trabajo con el programa. Una interfaz no es simplemente una cara bonita; esto puede impresionar a primera vista pero decepcionar a la larga. Lo importante es que el programa se adapte bien al modelo del usuario, cosa que se puede comprobar utilizando el programa ms all de la primera impresin. Modelo del programador: Es el ms fcil de visualizar, al poderse especificar formalmente. Est constituido por los objetos que manipula el programador, distintos de los que trata el usuario (ejemplo: el programador llama base de datos a lo que el usuario podra llamar agenda). Estos objetos deben esconderse del usuario. Los conocimientos del programador incluyen la plataforma de desarrollo, el sistema operativo, las herramientas de desarrollo y especificaciones. Sin embargo, esto no significa necesariamente que tenga la habilidad de proporcionar al usuario los modelos y metforas ms adecuadas. Muchos no consideran el modelo del

usuario del programa, y s sus propias expectativas acerca de cmo trabajar con la computadora. 2. Principios para el Diseo de Interfaces de Usuario Existen principios relevantes para el diseo e implementacin de IU, ya sea para las IU grficas, como para la Web. Anticipacin Las aplicaciones deberan intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la informacin, recopilarla o invocar las herramientas que va a utilizar. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura se ilustra como el procesador de texto se anticipa a las necesidades del usuario, proporcionando las caractersticas del texto seleccionado -fuente, tamao, alineacin, etc.- permitiendo que el usuario pueda modificarlas gilmente. Autonoma La computadora, la IU y el entorno de trabajo deben estar a disposicin del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender rpidamente a usar la aplicacin. Sin embargo, est comprobado que el entorno de trabajo debe tener ciertas cotas, es decir, ser explorable pero no azaroso. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura 3 se visualiza un diseo incorrecto de interfaz de usuario. La cantidad de opciones propuestas propone un grado de complejidad que no permite que el usuario pueda aprender a utilizar el sistema en forma progresiva. Es importante utilizar mecanismos indicadores de estado del sistema que mantengan a los usuarios alertas e informados. No puede existir autonoma en ausencia de control, y el control no puede ser ejercido sin informacin suficiente. Adems, se debe mantener informacin del estado del sistema en ubicaciones fciles de visualizar. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura 4 se ejemplifica una incorrecta disposicin de componentes en la IU. El reloj no debe ser incorporado en el men del sistema ya que aporta confusin al usuario. Para mantenerlo informado sera mas adecuado colocarlo en la barra de estado del sistema.

Percepcin del Color Aunque se utilicen convenciones de color en la IU, se deberan usar otros mecanismos secundarios para proveer la informacin a aquellos usuarios con problemas en la visualizacin de colores En la Figura 5 se representa un mecanismo secundario muy utilizado para ejecucin de comandos: los comandos abreviados (shortcut-keys). Sin embargo la aplicacin presenta un problema de inconsistencia ya que define combinaciones de teclas que difieren a lo esperado por el usuario, por ejemplo Alt+< en lugar de Alt+B. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") Valores por Defecto No se debe utilizar la palabra "Defecto" en una aplicacin o servicio. Puede ser reemplazada por "Estndar" o "Definida por el Usuario", "Restaurar Valores Iniciales" o algn otro trmino especifico que describa lo que est sucediendo. Los valores por defecto deberan ser opciones inteligentes y sensatas. Adems, los mismos tienen que ser fciles de modificar. Consistencia Para lograr una mayor consistencia en la IU se requiere profundizar en diferentes aspectos que estn catalogados en niveles. Se realiza un ordenamiento de mayor a menor consistencia: 1. Interpretacin del comportamiento del usuario: la IU debe comprender el significado que le
atribuye un usuario a cada requerimiento. Ejemplo: mantener el significado de las los comandos abreviados (shortcut-keys) definidos por el usuario. 2. Estructuras invisibles: se requiere una definicin clara de las mismas, ya que sino el usuario nunca podra llegar a descubrir su uso. Ejemplo: la ampliacin de ventanas mediante la extensin de sus bordes. 3. Pequeas estructuras visibles: se puede establecer un conjunto de objetos visibles capaces de ser controlados por el usuario, que permitan ahorrar tiempo en la ejecucin de tareas especficas. Ejemplo: cono y/o botn para impresin. 4. Una sola aplicacin o servicio: la IU permite visualizar a la aplicacin o servicio utilizado como un componente nico. Ejemplo: La IU despliega un nico men, pudiendo adems acceder al mismo mediante comandos abreviados. 5. Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicacin o servicio utilizado como un conjunto de componentes. Ejemplo: La IU se presenta como un conjunto de barras de comandos desplegadas en diferentes lugares de la pantalla, pudiendo ser desactivadas en forma independiente. 6. Consistencia del ambiente: la IU se mantiene en concordancia con el ambiente de trabajo. Ejemplo: La IU utiliza objetos de control como menes, botones de comandos de manera anloga a otras IU que se usen en el ambiente de trabajo.

7. Consistencia de la plataforma: La IU es concordante con la plataforma. Ejemplo: La IU

tiene un esquema basado en ventanas, el cual es acorde al manejo del sistema operativo Windows.

(Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura 6 puede observarse la mejora en la consistencia de las pequeas estructuras visibles (3.) para los sistemas grficos basados en ventanas. La inclusin de la opcin X para cerrar la ventana operacin comunmente utilizada en estas aplicaciones- simplifica la operatividad del mismo. La inconsistencia en el comportamiento de componentes de la IU debe ser fcil de visualizar. Se debe evitar la uniformidad en los componentes de la IU. Los objetos deben ser consistentes con su comportamiento. Si dos objetos actan en forma diferente, deben lucir diferentes. La nica forma de verificar si la IU satisface las expectativas del usuario es mediante testeo. Eficiencia del Usuario Se debe considerar la productividad del usuario antes que la productividad de la mquina. Si el usuario debe esperar la respuesta del sistema por un perodo prolongado, estas prdidas de tiempo se pueden convertir en prdidas econmicas para la organizacin. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los problemas. Los menes y etiquetas de botones deberan tener las palabras claves del proceso. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura 7 se demuestra como una incorrecta definicin de las palabras clave de las etiquetas de los botones de comando puede confundir al usuario. Los botones OK y Apply aparentan realizar el mismo proceso. Esto puede solucionarse suprimiendo uno de ellos si realizan la misma tarea o etiquetndolos con los nombres de los procesos especficos que ejecutan. Ley de Fitt El tiempo para alcanzar un objetivo es una funcin de la distancia y tamao del objetivo. Es por ello, que es conveniente usar objetos grandes para las funciones importantes. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo")

En la Figura 8 se puede apreciar la relacin entre los elementos de diseo de pantalla y su percepcin visual. El nmero de elementos visuales que perciben son: en el caso a) 1 (el fondo); en b) 3 (la lnea, lo que est encima y lo que est debajo); en c) son 5 (el espacio fuera del recuadro, el recuadro, la lnea y el espacio encima y debajo de sta); finalmente, en d) el nmero se eleva a 35, siguiendo el mismo criterio. Conclusin: cada elemento nuevo que se aade influye ms de lo que se piensa en el usuario. Interfaces Explorables Siempre que sea posible se debe permitir que el usuario pueda salir gilmente de la IU, dejando una marca del estado de avance de su trabajo, para que pueda continuarlo en otra oportunidad. Para aquellos usuarios que sean noveles en el uso de la aplicacin, se deber proveer de guas para realizar tareas que no sean habituales. Es conveniente que el usuario pueda incorporar elementos visuales estables que permitan, no solamente un desplazamiento rpido a ciertos puntos del trabajo que est realizando, sino tambin un sentido de "casa" o punto de partida. La IU debe poder realizar la inversa de cualquier accin que pueda llegar a ser de riesgo, de esta forma se apoya al usuario a explorar el sistema sin temores. Siempre se debe contar con un comando "Deshacer". Este suprimir la necesidad de tener que contar con dilogos de confirmacin para cada accin que realice en sistema. El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por ello que la IU debe tener un objeto fcil de accionar con el cual poder finalizar la aplicacin. Objetos de Interfaz Humana Los objetos de interfaz humana no son necesariamente los objetos que se encuentran en los sistemas orientados a objetos. Estos pueden ser vistos, escuchados, tocados o percibidos de alguna forma. Adems, estos objetos deberan ser entendibles, consistentes y estables. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura 9 se presentan barras de controles que simplifican la operacin de un sistema. A travs de las ilustraciones que poseen los mismos, el usuario puede aprender fcilmente su uso. Si se mantienen para estos botones las mismas

asignaciones de procesos en diferentes sistemas, la comprensin del funcionamiento de los mismos se hace mas sencilla. Uso de Metforas Las buenas metforas crean figuras mentales fciles de recordar. La IU puede contener objetos asociados al modelo conceptual en forma visual, con sonido u otra caracterstica perceptible por el usuario que ayude a simplificar el uso del sistema. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura 10 se compara la aplicacin de metforas en el desarrollo de una IU. En el primer caso, se utiliza incorrectamente la metfora de una cmara de video para representar el procesamiento de un documento por una impresora. Se puede observar que el botn << carece de sentido, ya que no se puede volver atrs un trabajo que ya ha sido impreso. En el segundo caso, la metfora de la agenda es utilizada correctamente para la implementacin de una agenda electrnica. Curva de Aprendizaje El aprendizaje de un producto y su usabilidad no son mutuamente excluyentes. El ideal es que la curva de aprendizaje sea nula, y que el usuario principiante pueda alcanzar el dominio total de la aplicacin sin esfuerzo. Reduccin de Latencia Siempre que sea posible, el uso de tramas (multi-threading) permite colocar la latencia en segundo plano (background). Las tcnicas de trabajo multitarea posibilitan el trabajo ininterrumpido del usuario, realizando las tareas de transmisin y computacin de datos en segundo plano. Proteccin del Trabajo Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por error de su parte, problemas de transmisin de datos, de energa, o alguna otra razn inevitable. Auditora del Sistema La mayora de los navegadores de Internet (browsers), no mantienen informacin acerca de la situacin del usuario en el entorno, pero para cualquier aplicacin es conveniente conocer un conjunto de caractersticas tales como: hora de acceso al sistema, ubicacin del usuario en el sistema y lugares a los que ha accedido, entre

otros. Adems, el usuario debera poder salir del sistema y al volver a ingresar continuar trabajando en lugar dnde haba dejado. Legibilidad Para que la IU favorezca la usabilidad del sistema de software, la informacin que se exhiba en ella debe ser fcil de ubicar y leer. Para lograr obtener este resultado se deben tener en cuenta algunas como: el texto que aparezca en la IU debera tener un alto contraste, se debe utilizar combinaciones de colores como el texto en negro sobre fondo blanco o amarillo suave. El tamao de las fuentes tiene que ser lo suficientemente grande como para poder ser ledo en monitores estndar. Es importante hacer clara la presentacin visual (colocacin/agrupacin de objetos, evitar la presentacin de excesiva informacin. (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") En la Figura 11 se describe una comparacin de disposicin de los objetos en pantalla. La figura de la izquierda, combina una disposicin asimtrica de la informacin con un conjunto de colores que no facilita la lectura. La figura de la derecha realiza la presentacin de la informacin utilizando una gama de colores homognea y una alineacin del texto que favorece a la legibilidad del mismo. Interfaces Visibles El uso de Internet, ha favorecido la implementacin de interfaces invisibles. Esto significa que el usuario siempre ve una pgina especfica, pero nunca puede conocer la totalidad del espacio de pginas de Internet. La navegacin en las aplicaciones debe ser reducida a la mnima expresin. El usuario debe sentir que se mantiene en un nico lugar y que el que va variando es su trabajo. Esto no solamente elimina la necesidad de mantener mapas u otras ayudas de navegacin, sino que adems brindan al usuario una sensacin de autonoma. 3. Utilizacin de Prototipos en la Implementacin de IU Niveles de Prototipado Se puede hacer una clasificacin de los principales tipos de prototipos, variando su grado de complejidad, de acuerdo a las caractersticas que consideren y a su operabilidad para realizar simulaciones.
Prototipos Estticos: son aquellos que no permiten la alteracin de sus componentes, pero sirven para identificar y resolver problemas de diseo. En esta categora se incluyen las presentaciones sobre reproductores, papel u otro medio de visualizacin.

Prototipos Dinmicos: permiten la evaluacin de un modelo del sistema sobre una estacin de trabajo o una terminal. Estos prototipos involucran aspectos de diseo mas detallados que los prototipos estticos, incluyendo la validacin del diseo del sistema en trminos de requerimientos no funcionales, por ejemplo de performance. Prototipos Robustos: deben ser relativamente completos en la simulacin de las caractersticas dinmicas de la interfaz (presentacin de mensajes de error, entrada y edicin de datos, etc.). Esta categora puede ser utilizada para validar los objetivos de diseo.

El nivel de sofisticacin del prototipo debera incrementarse a lo largo del proceso de diseo de interfaces de usuario. La informacin recolectada durante las tareas de anlisis del sistema y la especificacin de los requisitos del usuario constituyen los datos clave para el proceso de prototipacin. 4. Heursticas para la Evaluacin de IU Las heursticas ayudan a poder analizar las IU y localizar problemas que afecten la utilizacin de las mismas. Algunas pautas para evaluar una IU son:
Visibilidad del estado del sistema Semejanza del sistema al mundo real Control y libertad por parte del usuario Consistencia y estandarizacin Prevencin de Errores Reconocimiento de acciones y opciones Flexibilidad y eficiencia en el uso Esttica y diseo minimalista Reconocimiento de errores, diagnstico y recuperacin Ayuda y documentacin

Para establecer medidas que indiquen la severidad de los problemas en el uso de las interfaces, se deben conocer los factores que determinan el grado de un problema:
La frecuencia de ocurrencia. El impacto que causa la ocurrencia del problema. La persistencia del problema. El impacto en el mercado.

Medidas de severidad de un problema en la IU: 0: No puede llegar a considerarse un problema. 1: Es un problema "cosmtico" que no necesita ser corregido a menos que se disponga tiempo extra en el proyecto. 2: Es un problema menor y su correccin puede tener baja prioridad.

3: Es un problema mayor y su correccin debera tener alta prioridad. 4: Es una catstrofe para la utilizacin de la aplicacin y es imperativo corregir el error. Para la evaluacin de los problemas en las IU es conveniente que contar con mas de un evaluador; de esta forma los resultados son mas confiables. 5. Caso Prctico Para complementar los aspectos tericos, se realiza una ejemplificacin de una de las actividades propuestas por la metodologa Mtrica Versin 2 para el diseo de interfaces de usuario. La metodologa Mtrica Versin 2 contempla la simulacin de dilogos de pantalla para la actividad EFS 4 "Definir Interfaces de Usuario", a partir de las principales funciones interactivas, eventos y consultas identificados en la fase de anlisis. Siguiendo la metodologa, la tarea 4.1 prescribe las siguientes acciones:
Definir los formatos individuales de las pantallas utilizadas. Describir de modo detallado los dilogos entre pantallas y el encadenamiento entre las mismas. Determinar los dilogos que se consideran crticos. Realizar una maqueta dinmica.

Asimismo, la tarea 4.2 indica:

Obtener una definicin de los formatos de los informes generados. Definir los formularios utilizados (si fuera necesario). Verificar si los diseos realizados estn de acuerdo con los estndares de la unidad y obtener la validacin y conformidad de los usuarios.

Para acotar el presente trabajo, se realiza un desarrollo del primer punto de la tarea 4.1 propuesta en la metodologa, exponiendo algunos de los productos resultantes.
Tarea 4.1.1. Definir los formatos individuales de las pantallas utilizadas.

Caso Prctico: Construccin de un sistema de Gestin de Alquiler de Automviles (AGA 2000). Requisitos de interfaces de usuario:
La interfaz con el usuario se har mediante pantallas con mens desplegables.

Se describe a modo de ejemplo, el formato de la pantalla principal del sistema AGA 2000 y sus componentes (Figura 12). Descripcin de componentes Barra de Ttulo: se utiliza para desplegar el ttulo de la pantalla desplegada. Si la ventana est activa, la barra de titulo tendr un color diferente al resto de las ventanas desplegadas. Men Principal: contiene un conjunto de botones que permiten desplegar la totalidad de las pantallas del sistema. Usuario del Sistema: indica el nombre del usuario que est utilizando el sistema, el cual ha sido previamente ingresado con una contrasea como requisito para acceder al sistema. Reloj del Sistema: indica la hora actual del sistema. Area de Trabajo: es el lugar donde se despliegan las pantallas que son activadas a travs del Men Principal. Maximizar/Restaurar Ventana: botn que se utiliza para ampliar o reducir el tamao de la pantalla. Minimizar Ventana: control que se utiliza para quitar de primer plano de trabajo una ventana, sin cerrarla. Cerrar Ventana: control que se usa para cerrar una ventana. Puede utilizarse para la descripcin de las pantallas, las operaciones que se especifican en los diagramas de la Historia de Vida de las Entidades del sistema anteriormente presentado (AGA 2000). Cada operacin representa una pantalla diferente, por lo que se expondrn algunas de ellas (Figuras 13 y 14) con el objeto de ilustrar el diseo de las mismas. Opciones de Men Operaciones

Avera

Alta avera, Actualizacin perodo Avera, Borrado de avera.

Cliente

Alta cliente, Modificar direccin, Emisin tarjeta, Cancelacin tarjeta, Renovacin tarjeta.

Entrega

Alta entrega, Borrar Entrega

Entrega/Vehculo

Alta entrega / vehculo, Borrar entrega / vehculo

Fabricante

Alta fabricante, Actualizar datos

Factura Fabricante

Alta factura fabricante, Borrar factura fabricante

Modelo

Alta modelo, Borrar modelo

Modelo/Pedido

Alta modelo/pedido, Borrar modelo/pedido

Oficina

Alta oficina, Borrar oficina

Pago Cliente

Alta pago cliente, Borrar pago cliente

Pago Fabricante

Alta pago fabricante, Borrar pago fabricante

Pedido

Alta pedido, Borrar pedido

Reserva vehculo

Alta reserva vehculo, Borrar reserva vehculo

Seguro

Alta seguro, Modificar porcentaje seguro, Borrar seguro

Ejemplos de pantalla para la operacin de Alta de Fabricante y Alta de Pedidos (Para ver el grfico faltante haga click en el men superior "Bajar Trabajo") El encadenamiento de las pantallas est determinado a partir de la pantalla principal del sistema, permitiendo desplegar cualquiera de las pantallas utilizadas para las operaciones anteriormente descriptas. Dichas pantallas pueden ser activadas o cerradas en forma independiente. 6. Conclusiones Las integracin de los principios, prototipos y heursticas de evaluacin durante el proceso de diseo de IU permite la creacin de interfaces que satisfacen las expectativas del Modelo del Usuario, el cual es el punto de vista mas importante para garantizar la aceptacin de un sistema. Entre las caractersticas que contribuyen a construir una interfaz sencilla de utilizar, sobresale la utilizacin de metforas como ayuda para simplificar al usuario en la operacin del sistema. La prototipacin es un proceso de uso frecuente durante el diseo de IU. A travs diferentes niveles evolutivos de prototipos se pueden lograr simulaciones del sistema a construir con un alto grado de detalle, pudiendo validar los requisitos de diseo que se hayan propuesto. Las heursticas de evaluacin de IU permiten identificar problemas que interfieran en la operacin del sistema, resultando de ellas un diagnstico que puede ser utilizado como retroalimentacin para una nueva versin optimizada de la interfaz de usuario. 7. Bibliografa
Gua de Estudio del Mdulo III "Metodologa de Construccin de Sistemas de Software" de la Maestra en Ingeniera del Software, Escuela de Posgrado, Instituto Tecnolgico de Buenos Aires. Molich, R., y Nielsen, J.,"Improving a human computer dialogue", Communications of the ACM 33, 3 (March), pp 338-348, 1990. Molich, R., y Nielsen, J., "Heuristic evaluation of user interfaces", Proceedings of the ACM CHI90 Conference, pp. 249-256, 1990. Molich, R., y Nielsen, J., "Enhancing the explanatory power of usability heuristics", Proceedings of the ACM CHI94 Conference, pp. 152-158, 1994. Durrett, H.J., "General Approach to Rapid Prototyping",

http://swt.edu/~hd01/4326/PROTOTYP.htm, 1997.

Datos del Autor Leopoldo Sebastin M. Gmez Licenciado en Ciencias de la Computacin (U.N.S.) Perito Informtico Oficial Poder Judicial del Neuqun Argentina http://www.angelfire.com/journal2/lead/index.html Abstract El diseo de interfaces de usuario es una tarea que ha adquirido relevancia en el desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los motivos que conduzca a un sistema al xito o al fracaso. Los principios que se presentan son de utilidad para creacin de interfaces funcionales y de fcil operacin. A pesar de no ser capaces de resolver todos los aspectos propios del contexto con el que se est trabajando, pueden ser combinados con la prototipacin y la aplicacin de heursticas de evaluacin para facilitar el proceso de diseo. El presente artculo se centra en los componentes de software de las interfaces de usuario, quedando fuera del alcance de mismo otros aspectos, como hardware y documentacin. Lo anteriormente expuesto se complementa con un caso prctico de diseo de interfaces de usuario, producto de realizar la actividad de "Definicin de Interfaces de Usuario" (EFS 4) de la metodologa Mtrica Versin 2. Key words: evaluation, heuristics, principles, prototypes, user interfaces.

Trabajo enviado por: Leopoldo Sebastin M. Gmez gomezsebastian@yahoo.com http://www.monografias.com/trabajos11/heuri/heuri.shtml

Conceptos avanzados sobre interfaces de usuario

En cuanto a la creacin de las interfaces de usuario, esta ha sido un rea del desarrollo de software que ha evolucionado drmaticamente a partir de la dcada de los setentas. La interfaz de usuario es el vnculo entre el usuario y el programa de computadora. Una interfaz es un conjunto de comandos o menes a travs de los cuales el usuario se comunica con el programa.

Las interfaces de usuario es una de las partes ms importantes de cualquier programa ya que esta determina que tan fcilmente es posible que el programa haga lo que el usuario quiere hacer. Un programa muy poderoso con una interfaz pobremente elaborada tiene poco valor. La elaboracin de una interfaz de usuario, bien diseada, exige una gran dedicacin pues generalmente las interfaces son grandes, complejas y difciles de implementar depurar y modificar. Hoy en da las interfaces de directa (tambin llamadas interfaces grficas de usuario, GUI por sus siglas en ingls) son prcticamente universales. Las interfaces que utilizan ventanas, conos y menes se han convertido en estndar de materiales computacionales. La interfaz es el punto de encuentro entre el usuario y la computadora. En esta interaccin el usuario juzga la utilidad de la interfaz, y el hardware y el software se convierten en simples herramientas sobre los cuales fue construida la interfaz. La definicin de interfaz en si es un tanto arbitraria, aunque esto dependera de la naturaleza de la tarea que se tiene enfrente. Existen muchos tipos de software para la creacin de interfaces de usuario. El sistema de ventanas permite la divisin de la pantalla en diferentes regiones rectangulares, llamadas ``ventanas''. El sistema de ventanas XWindows para Unix divide la funcionalidad de la ventana en dos capas: el sistema de ventanas, el cual es la interfaz funcional, y el administrador de ventanas. El sistema de ventanas prove de procedimientos que permiten a la el dibujar figuras en la pantalla y sirve como medio de entrada de las acciones del usuario. El administrador de ventanas le permite al usuario final el mover las ventanas por la pantalla, y es el responsable de desplegar las lneas de ttulo bordes e conos alrededor de las ventanas. La parte central de un sistema de ventanas es el conjunto de herramientas (toolkit), el cual contiene los objetos grficos (widgets) ms empleados tales como menes, botones, barras de scroll, y campos para entrada de texto. El toolkit generalmente se conecta a los programas de aplicacin a travs de una serie de procedimientos definidos por el programador. La

funcin de estos procedimiento es el de decidir la forma en que se comportaran los objetos grficos. Ejemplos de toolkits son el Motif/X11 y los widgets definidos en los toolboxes para Windows y Macintosh. Los toolkits virtuales le permiten a una aplicacin el que sta sea escrita una sola vez y esta vez se pueda ejecutar en Windows, MacOS o Unix. Otro nombre para estos toolkits es ``sistemas de desarrollo multiplataforma''. [Rivera Loaiza, 1999].

http://www.fismat.umich.mx/~elizalde/tesis/node46.html

2.2 Diseo de la lgica. 2.2.1 Clases y Objetos.

Introduccin
Cuando se escribe un programa en un lenguaje orientado a objetos, definimos una plantilla o clase que describe las caractersiticas y el comportamiento de un conjunto de objetos similares. La clase automvil describe las caractersticas comunes de todos los automviles: sus atributos y su comportamiento. Los atributos o propiedades se refieren a la marca o fabricante, el color, las dimensiones, si tienen dos, tres, cuatro o ms puertas, la potencia, si utiliza como combustible la gasolina o gasoil, etc. El comportamiento se refiere a la posibilidad de desplazarse por una carretera, frenar, acelerar, cambiar de marcha, girar, etc. Luego, tenemos automviles concretos, por ejemplo el automvil propio de una determinada marca, color, potencia, etc, el automvil del vecino de otra marca, de otro color, etc, , el automvil de un amigo, etc. Una clase es por tanto una pantilla implementada en software que describe un conjunto de objetos con atributos y comportamiento similares. Una instancia u objeto de una clase es una representacin concreta y especfica de una clase y que reside en la memoria del ordenador.

Atributos Los atributos son las caractersiticas individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades. Los atributos se guardan en variables denominadas de instancia, y cada objeto particular puede tener valores distintos para estas variables. Las variables de instancia tambin denominados miembros dato, son declaradas en la clase pero sus valores son fijados y cambiados en el objeto. Adems de las variables de instancia hay variables de clase, las cuales se aplican a la clase y a todas sus instancias. Por ejemplo, el nmero de ruedas de un automvil es el mismo cuatro, para todos los automviles.

Comportamiento El comportamiento de los objetos de una clase se implementa mediante funciones miembro o mtodos. Un mtodo es un conjunto de instrucciones que realizan una determinada tarea y son similares a las funciones de los lenguajes estructurados. Del mismo modo que hay variables de instancia y de clase, tambin hay mtodos de instancia y de clase. En el primer caso, un objeto llama a un mtodo para realizar una determinada tarea, en el segundo, el mtodo se llama desde la propia clase.

El proyecto
El proyecto consta de dos archivos, el primero contiene la clase Rectangulo que se guarda en el archivo Rectangulo.java y no tiene el mtodo main. La ltima casilla del asistente de creacin de clases New Java File debe de estar desactivada. La otra clase, es la que describe la aplicacin RectanguloApp1 y se guarda en el archivo RectanguloApp1.java, esta clase tiene que tener el mtodo main, por lo tanto, la ltima casilla del asistente de creacin de clases New Java File debe de estar activada.

Un proyecto puede constar de varias clases (normalmente se sita cada clase en un archivo) pero solamente una tiene el mtodo main y representa la aplicacin. Para distinguir la clase que describe la aplicacin de las dems le hemos aadido el sufijo App. rectangulo1: Rectangulo.java, RectanguloApp1.java

La clase
Para crear una clase se utiliza la palabra reservada class y a continuacin el nombre de la clase. La definicin de la clase se pone entre las llaves de apertura y cierre. El nombre de la clase empieza por letra mayscula.
class Rectangulo{ //miembros dato //funciones miembro }

Los miembros dato

Los valores de los atributos se guardan en los miembros dato o variables de instancia. Los nombres de dichas variables comienzan por letra minscula. Vamos a crear una clase denominada Rectangulo, que describa las caractersticas comunes a estas figuras planas que son las siguientes:

El origen del rectngulo: el origen o posicin de la esquina superior izquierda del rectngulo en el plano determinado por dos nmeros enteros x e y. Las dimensiones del rectngulo: ancho y alto, otros dos nmeros enteros.

class Rectangulo{ int x;

int y; int ancho; int alto; //faltan las funciones miembro

Las funciones miembro

En el lenguaje C++ las funciones miembro se declaran, se definen y se llaman. En el lenguaje Java las funciones miembro o mtodos solamente se definen y se llaman. El nombre de las funciones miembro o mtodos comieza por letra minscula y deben sugerir acciones (mover, calcular, etc.). La definicin de una funcin tiene el siguiente formato:
tipo nombreFuncion(tipo parm1, tipo parm2, tipo parm3){ //...sentencias }

Entre las llaves de apertura y cierre se coloca la definicin de la funcin. tipo indica el tipo de dato que puede ser predefinido int, double, etc, o definido por el usuario, una clase cualquiera. Para llamar a un funcin miembro o mtodo se escribe
retorno=objeto.nombreFuncion(arg1, arg2, arg3);

Cuando se llama a la funcin, los argumentos arg1, arg2, arg3 se copian en los parmetros parm1, parm2, parm3 y se ejecutan las sentencias dentro de la funcin. La funcin finaliza cuando se llega al final de su bloque de definicin o cuando encuentra una sentencia return. Cuando se llama a la funcin, el valor devuelto mediante la sentencia return se asigna a la variable retorno. Cuando una funcin no devuelve nada se dice de tipo void. Para llamar a la funcin, se escribe
objeto.nombreFuncion(arg1, arg2, arg3);

Estudiaremos ms adelante con ms detalle como se definen las funciones. Una funcin suele finalizar cuando llega al final del bloque de su definicin

void funcion(....){ //sentencias... }

Una funcin puede finalizar antes del llegar al final de su definicin

void funcion(....){ //sentencias... if(condicion) return; //sentencias.. }

Una funcin puede devolver un valor (un tipo de dato primitivo o un objeto).
double funcion(....){ double suma=0.0; //sentencias... return suma; }

Cualquier variable declarada dentro de la funcin tiene una vida temporal, existiendo en memoria, mientras la funcin est activa. Se trata de variables locales a la funcin. Por ejemplo:
void nombreFuncion(int parm){ //... int i=5; //... }

La variable parm, existe desde el comienzo hasta el final de la funcin. La variable local i, existe desde el punto de su declaracin hasta el final del bloque de la funcin. Se ha de tener en cuenta que las funciones miembro tienen acceso a los miembros dato, por tanto, es importante en el diseo de una clase decidir qu variables son miembros dato, qu variables son locales a las funciones miembro, y qu valores les pasamos a dichas funciones. Los ejemplos nos ayudarn a entender esta distincin. Hemos definido los atributos o miembros dato de la clase Rectangulo, ahora le vamos aadir un comportamiento: los objetos de la clase Rectangulo o rectngulos sabrn calcular su rea, tendrn capacidad para trasladarse a otro punto del plano, sabrn si contienen en su interior un punto determinado del plano. La funcin que calcula el rea realizar la siguiente tarea, calcular el producto del ancho por el alto del rectngulo y devolver el resultado. La funcin devuelve un entero es por tanto, de tipo int. No es necasario pasarle datos ya que tiene acceso a los miembros dato ancho y alto que guardan la anchura y la altura de un rectngulo concreto.

class Rectangulo{ int x; int y; int ancho; int alto; int calcularArea(){ return (ancho*alto); } }

A la funcin que desplaza el rectngulo horizontalmente en dx, y verticalmente en dy, le pasamos dichos desplazamientos, y a partir de estos datos actualizar los valores que guardan sus miembros dato x e y. La funcin no devuelve nada es de tipo void.
class Rectangulo{ int x; int y; int ancho; int alto; void desplazar(int dx, int dy){ x+=dx; y+=dy; } }

La funcin que determina si un punto est o no en el interior del rectngulo, devolver true si el punto se encuentra en el interior del rectngulo y devolver false si no se encuentra, es decir, ser una funcin del tipo boolean. La funcin necesitar conocer las coordenadas de dicho punto. Para que un punto de coordenadas x1 e y1 est dentro de un rectngulo cuyo origen es x e y, y cuyas dimensiones son ancho y alto, se deber cumplir a la vez cuatro condiciones x1>x y a la vez x1<x+ancho Tambin se debe cumplir y1>y y a la vez y1<y+alto Como se tienen que cumplir las cuatro condiciones a la vez, se unen mediante el operador lgico AND simbolizado por &&.
class Rectangulo{ int x; int y; int ancho; int alto; boolean estaDentro(int x1, int y1){ if((x1>x)&&(x1<x+ancho)&&(y1>y)&&(y1<y+ancho)){ return true;

} }

} return false;

En el lenguaje Java, si la primera condicin es falsa no se evalan las restantes expresiones ya que el resultado es false. Ahora bien, si la primera es verdadera true, se pasa a evaluar la segunda, si sta el falsa el resultado es false, y as sucesivamente.

Los contructores
Un objeto de una clase se crea llamando a una funcin especial denominada constructor de la clase. El constructor se llama de forma automtica cuando se crea un objeto, para situarlo en memoria e inicializar los miembros dato declarados en la clase. El constructor tiene el mismo nombre que la clase. Lo especfico del constructor es que no tiene tipo de retorno.
class Rectangulo{ int x; int y; int ancho; int alto; Rectangulo(int x1, int y1, int w, int h){ x=x1; y=y1; ancho=w; alto=h; } }

El constructor recibe cuatro nmeros que guardan los parmetros x1, y1, w y h, y con ellos inicializa los miembros dato x, y, ancho y alto. Una clase puede tener ms de un constructor. Por ejemplo, el siguiente constructor crea un rectngulo cuyo origen est en el punto (0, 0).
class Rectangulo{ int x; int y; int ancho; int alto; Rectangulo(int w, int h){ x=0; y=0; ancho=w; alto=h; } }

Este constructor crea un rectngulo de dimensiones nulas situado en el punto (0, 0),
class Rectangulo{ int x; int y; int ancho; int alto; Rectangulo(){ x=0; y=0; ancho=0; alto=0; } }

Con estas porciones de cdigo definimos la clase, y la guardamos en un archivo que tenga el mismo nombre que la clase Rectangulo y con extensin .java.
public class Rectangulo { int x; int y; int ancho; int alto; public Rectangulo() { x=0; y=0; ancho=0; alto=0; } public Rectangulo(int x1, int y1, int w, int h) { x=x1; y=y1; ancho=w; alto=h; } public Rectangulo(int w, int h) { x=0; y=0; ancho=w; alto=h; } int calcularArea(){ return (ancho*alto); } void desplazar(int dx, int dy){ x+=dx; y+=dy; } boolean estaDentro(int x1, int y1){ if((x1>x)&&(x1<x+ancho)&&(y1>y)&&(y1<y+ancho)){ return true; } return false; } }

Los objetos
Para crear un objeto de una clase se usa la palabra reservada new. Por ejemplo,
Rectangulo rect1=new Rectangulo(10, 20, 40, 80);

new reserva espacio en memoria para los miembros dato y devuelve una referencia que se guarda en la variable rect1 del tipo Rectangulo que denominamos ahora objeto. Dicha sentencia, crea un objeto denominado rect1 de la clase Rectangulo llamando al segundo constructor en el listado. El rectngulo estar situado en el punto de coordenadas x=10, y=20; tendr una anchura de ancho=40 y una altura de alto=80.
Rectangulo rect2=new Rectangulo(40, 80);

Crea un objeto denominado rect2 de la clase Rectangulo llamando al tercer constructor, dicho rectngulo estar situado en el punto de coordenadas x=0, y=0; y tendr una anchura de ancho=40 y una altura de alto=80.
Rectangulo rect3=new Rectangulo();

Crea un objeto denominado rect3 de la clase Rectangulo llamando al primer constructor, dicho rectngulo estar situado en el punto de coordenadas x=0, y=0; y tendr una anchura de ancho=0 y una altura de alto=0.

Acceso a los miembros

Desde un objeto se puede acceder a los miembros mediante la siguiente sintaxis objeto.miembro; Por ejemplo, podemos acceder al miembro dato ancho, para cambiar la anchura de un objeto rectngulo.
rect1.ancho=100;

El rectngulo rect1 que tena inicialmente una anchura de 40, mediante esta sentencia se la cambiamos a 100.

Desde un objeto llamamos a las funciones miembro para realizar una determinada tarea. Por ejemplo, desde el rectngulo rect1 llamamos a la funcin calcularArea para calcular el rea de dicho rectngulo.
rect1.calcularArea();

La funcin miembro area devuelve un entero, que guardaremos en una variable entera medidaArea, para luego usar este dato.
int medidaArea=rect1.calcularArea(); System.out.println("El rea del rectngulo es "+medidaArea);

Para desplazar el rectngulo rect2, 10 unidades hacia la derecha y 20 hacia abajo, escribiremos
rect2.desplazar(10, 20);

Podemos verificar mediante el siguiente cdigo si el punto (20, 30) est en el interior del rectngulo rect1.
if(rect1.estaDentro(20,30)){ System.out.println("El punto est dentro del rectngulo"); }else{ System.out.println("El punto est fuera del rectngulo"); }

rect1.dentro() devuelve true si el punto (20, 30) que se le pasa a dicha funcin miembro est en el interior del rectngulo rect1, ejecutndose la primera sentencia, en caso contrario se ejecuta la segunda. Como veremos ms adelante no siempre es posible acceder a los miembros, si establecemos controles de acceso a los mismos.
public class RectanguloApp1 { public static void main(String[] args) { Rectangulo rect1=new Rectangulo(10, 20, 40, 80); Rectangulo rect2=new Rectangulo(40, 80); Rectangulo rect3=new Rectangulo(); int medidaArea=rect1.calcularArea(); System.out.println("El rea del rectngulo es "+medidaArea); rect2.desplazar(10, 20); if(rect1.estaDentro(20,30)){ System.out.println("El punto est dentro del rectngulo"); }else{ System.out.println("El punto est fuera del rectngulo"); } } }

La vida de un objeto
En el lenguaje C++, los objetos que se crean con new se han de eliminar con delete. new reserva espacio en memoria para el objeto y delete libera dicha memoria. En el lenguaje Java no es necesario liberar la memoria reservada, el recolector de basura (garbage collector) se encarga de hacerlo por nosotros, liberando al programador de una de las tareas que ms quebraderos de cabeza le producen, olvidarse de liberar la memoria reservada. Veamos un ejemplo
public class UnaClase { public static void main(String[] args) { Image granImagen=creaImagen(); mostrar(graImagen); while(condicion){ calcular(); } } }

El objeto granImagen, continua en memoria hasta que se alcanza el final de la funcin main, aunque solamente es necesario hasta el bucle while. En C o en C++ eliminariamos dicho objeto liberando la memoria que ocupa mediante delete. El equivalente en Java es el de asignar al objeto granImagen el valor null.
public class UnaClase { public static void main(String[] args) { Image granImagen=creaImagen(); mostrar(graImagen); granImagen=null; while(condicion){ calcular(); } } }

A partir de la sentencia marcada en letra negrita el recolector de basura se encargar de liberar la memoria ocupada por dicha imagen. As pues, se asignar el valor null a las referencias a objetos temporales que ocupen mucha memoria tan pronto como no sean necesarios. Creamos dos objetos de la clase rectngulo, del mismo modo que en el apartado anterior
Rectangulo rect1=new Rectangulo(10, 20, 40, 80);

Rectangulo rect3=new Rectangulo();

Si escribimos
rect3=rect1;

En rect3 se guarda la referencia al objeto rect1. La referencia al objeto rect3 se pierde. El recolector se encarga de liberar el espacio en memoria ocupado por el objeto rect3. La destruccin de un objeto es una tarea (thread) de baja prioridad que lleva a cabo la Mquina Virtual Java (JVM). Por tanto, nunca podemos saber cuando se va a destruir un objeto. Puede haber situaciones en las que es necesario realizar ciertas operaciones que no puede realizar el recolector de basura (garbage collector) cuando se destruye un objeto. Por ejemplo, se han abierto varios archivos durante la vida de un objeto, y se desea que los archivos estn cerrados cuando dicho objeto desaparece. Se puede definir en la clase un mtodo denominado finalize que realice esta tarea. Este mtodo es llamado por el recolector de basura inmeditamente antes de que el objeto sea destrudo.

Identificadores
Cmo se escriben los nombres de la variables, de las clases, de las funciones, etc., es un asunto muy importante de cara a la comprensin y el mantenimiento de cdigo. En la introduccin a los fundamentos del lenguaje Java hemos tratado ya de los identificadores. El cdigo debe de ser tanto ms fcil de leer y de entender como sea posible. Alguien que lea el cdigo, incluso despus de cierto tiempo, debe ser capaz de entender lo que hace a primera vista, aunque los detalles internos, es decir, cmo lo hace, precise un estudio detallado. Vemos primero un ejemplo que muestra un cdigo poco legible y por tanto, muy difcil de mantener
public class Cuen{ private int ba; Cuen(int ba){ this.ba=ba; } public void dep(int i){

ba+=i; } public boolean ret(int i){ if(ba>=i){ ba-=i; return true; } return false; } public int get(){ return ba; } }

Las abreviaciones empleadas solamente tienen significado para el programador en el momento de escribir el cdigo, ya que puede olvidarse de su significado con el tiempo. Otros programadores del grupo tienen que descifrar el significado del nombre de cada variable o de cada funcin. El tiempo extra que se gasta en escribir con claridad el nombre de los diversos elementos que entran en el programa, se ahorra ms adelante durante su desarrollo, depuracin, y mejora, es decir, durante todo el ciclo de vida del programa.
public class CuentaBancaria{ private int balance; CuentaBancaria(int balance){ this.balance=balance; } public void depositar(int cantidad){ balance+=cantidad; } public boolean retirar(int cantidad){ if(balance>=cantidad){ balance-=cantidad; return true; } return false; } public int obtenerBalance(){ return balance; } }

Este es una programa sencillo de una cuenta bancaria. El tipo de dato puede ser entero (int o long), si la unidad monetaria tiene poco valor como la peseta, o un nmero decimal (double) si la unidad monetaria es de gran valor como el Euro y el Dlar. El cdigo de las funciones miembro es muy sencillo y su significado se hace evidente al leer el programa. La funcin retirar es de tipo boolean, ya que no (false) estamos autorizados a retirar una cantidad mayor que la existente en ese momento en el banco. Sin

embargo, si (true) estamos autorizados a retirar una cantidad menor que la que tenemos en la cuenta. Hay dos formas de reutilizar el cdigo, mediante la composicin y mediante la herencia. La composicin significa utlizar objetos dentro de otros objetos. Por ejemplo, un applet es un objeto que contiene en su interior otros objetos como botones, etiquetas, etc. Cada uno de los controles est descrito por una clase. Vamos a estudiar una nueva aproximacin a la clase Rectangulo definiendo el origen, no como un par de coordenadas x e y (nmeros enteros) sino como objetos de una nueva clase denominada Punto. rectangulo: Punto.java, Rectangulo.java, RectanguloApp.java

La clase Punto
La clase Punto tiene dos miembros dato, la abscisa x y la ordenada y de un punto del plano. Definimos dos constructores uno por defecto que sita el punto en el origen, y otro constructor explcito que proporciona las coordenadas x e y de un punto concreto.
public class Punto { int x; int y; //funciones miembro }

El constructor explcito de la clase Punto podemos escribirlo de dos formas

public Punto(int x1, int y1) { x = x1; y = y1; }

Cuando el nombre de los parmetros es el mismo que el nombre de los miembros datos escribimos
public Punto(int x, int y) { this.x = x; this.y = y; }

this.x que est a la izquierda y que recibe el dato x que se le pasa al constructor se refiere al miembro dato, mientras que x que est a la derecha es el parmetro. this es una palabra

reservada que guarda una refrencia al objeto propio, u objeto actual. Tendremos ocasin a lo largo del curso de encontrar esta palabra en distintas situaciones. La funcin miembro desplazar simplemente cambia la posicin del punto desde (x, y) a (x+dx, y+dy). La funcin desplazar cuando es llamada recibe en sus dos parmetros dx y dy el desplazamiento del punto y actualiza las coordenadas x e y del punto. La funcin no retorna ningn valor
public void desplazar(int dx, int dy){ x+=dx; y+=dy; }

Para crear un objeto de la clase Punto cuyas coordenadas x e y valgan repectivamente 10 y 23 escribimos
Punto p=new Punto(10, 23);

Para desplazar el punto p 10 unidades hacia la izquierda y 40 hacia abajo, llamamos desde el objeto p a la funcin desplazar y le pasamos el desplazamiento horizontal y vertical.
p.desplazar(-10, 40);

El cdigo completo de la clase Punto, es el siguiente

public class Punto { int x = 0; int y = 0; public Punto(int x, int y) { this.x = x; this.y = y; } public Punto() { x=0; y=0; } void desplazar(int dx, int dy){ x+=dx; y+=dy; } }

La clase Rectangulo
La clase Rectangulo tiene como miembros dato, el origen que es un objeto de la clase Punto y las dimensiones ancho y alto.

public class Rectangulo { Punto origen; int ancho ; int alto ; //funciones miembro }

El constructor por defecto, crea un rectngulo situado en el punto 0,0 y con dimensiones nulas
public Rectangulo() { origen = new Punto(0, 0); ancho=0; alto=0; }

El constructor explcito crea un rectngulo situado en un determinado punto p y con unas dimensiones que se le pasan en el constructor
public Rectangulo(Punto p, int w, int h) { origen = p; ancho = w; alto = h; }

Podemos definir otros constructores en trminos del constructor explcito usando la palabra reservada this.
public Rectangulo(Punto p) { this(p, 0, 0); } public Rectangulo(int w, int h) { this(new Punto(0, 0), w, h); }

El primero crea un rectngulo de dimensiones nulas situado en el punto p. El segundo, crea un rectngulo de unas determinadas dimensiones situndolo en el punto 0, 0. Dentro del cuerpo de cada constructor se llama al constructor explcito mediante this pasndole en sus parmetros los valores apropiados. Para desplazar un rectngulo, trasladamos su origen (esquina superior izquierda) a otra posicin, sin cambiar su anchura o altura. Desde el objeto origen, llamamos a la funcin desplazar miembro de la clase Punto
void desplazar(int dx, int dy) { origen.desplazar(dx, dy); }

El cdigo completo de la nueva clase Rectangulo, es el siguiente.

public class Rectangulo { Punto origen; int ancho ; int alto ; public Rectangulo() { origen = new Punto(0, 0); ancho=0; alto=0; } public Rectangulo(Punto p) { this(p, 0, 0); } public Rectangulo(int w, int h) { this(new Punto(0, 0), w, h); } public Rectangulo(Punto p, int w, int h) { origen = p; ancho = w; alto = h; } void desplazar(int dx, int dy) { origen.desplazar(dx, dy); } int calcularArea() { return ancho * alto; }

Objetos de la clase Rectangulo

Para crear un rectngulo rect1 situado en el punto (0, 0) y cuyas dimensiones son 100 y 200 escribimos
Rectangulo rect1=new Rectangulo(100, 200);

Para crear un rectngulo rect2, situado en el punto de coordenadas 44, 70 y de dimensiones nulas escribimos
Punto p=new Punto(44, 70); Rectangulo rect2=new Rectangulo(p);

O bien, en una sla lnea

Rectangulo rect2=new Rectangulo(new Punto(44, 70));

Para desplazar el rectngulo rect1 desde el punto (100, 200) a otro punto situado 40 unidades hacia la derecha y 20 hacia abajo, sin modificar sus dimensiones, escribimos
rect1.desplazar(40, 20);

Para hallar y mostrar el rea del rectngulo rect1 podemos escribir

System.out.println("el rea es "+rect1.calcularArea());

Para hallar el rea de un rectngulo de 100 unidades de largo y 50 de alto y guardar el resultado en la variable entera areaRect, escribimos en una sla lnea.
int areaRect=new Rectangulo(100, 50).calcularArea(); public class RectanguloApp { public static void main(String[] args) { Rectangulo rect1=new Rectangulo(100, 200); Rectangulo rect2=new Rectangulo(new Punto(44, 70)); Rectangulo rect3=new Rectangulo(); rect1.desplazar(40, 20); System.out.println("el rea es "+rect1.calcularArea()); int areaRect=new Rectangulo(100, 50).calcularArea(); System.out.println("el rea es "+areaRect); } } }

Hemos aprendido a diferenciar entre clase y objetos, a acceder desde un objeto a los miembros datos y a las funciones miembro. Vamos a utilizar clases importantes en el lenguaje Java y a crear objetos de dichas clases. Empezaremos por la clase String una de las ms importantes del lenguaje Java. Ms adelante, volveremos a estudiar otros ejemplos para que el lector se acostumbre a crear sus propias clases.

Las clases del lenguaje Java

Como habremos observado, y apreciaremos an ms en la parte correspondiente a la creacin de applets, el IDE JBuilder proporciona un sistema de ayuda a medida que vamos escribiendo el cdigo. Tambin, podemos situar el cursor sobre el nombre de una clase, al pulsar el botn derecho del ratn, aparece un men flotante. Seleccionando el primer elemento del men, Browse symbol at cursor, aparece la definicin de la clase. Los paneles cambian, podemos seleccionar la funcin miembro que nos interesa en el panel de estructura (inferior izquierda) y ver su cdigo fuente en el panel de contenido (a la derecha).

En la figura podemos ver la clase String y en el panel de contenido la definicin de una de las funciones miembro substring que hemos seleccionado en el panel de estructura. Por encima de la definicin aparece la documentacin relativa a dicha funcin. Para volver al cdigo fuente de nuestra clase pulsamos en el botn "home" encima del panel de navegacin.

La clase String
string: StringApp.java Dentro de un objeto de la clases String o StringBuffer, Java crea un array de caracteres de una forma similar a como lo hace el lenguaje C++. A este array se accede a travs de las funciones miembro de la clase. Los strings u objetos de la clase String se pueden crear explcitamente o implcitamente. Para crear un string implcitamente basta poner una cadena de caracteres entre comillas dobles. Por ejemplo, cuando se escribe

System.out.println("El primer programa");

Java crea un objeto de la clase String automticamente. Para crear un string explcitamente escribimos
String str=new String("El primer programa");

Tambin se puede escribir, alternativamente

String str="El primer programa";

Para crear un string nulo se puede hacer de estas dos formas

String str=""; String str=new String();

Un string nulo es aqul que no contiene caracteres, pero es un objeto de la clase String. Sin embargo,
String str;

est declarando un objeto str de la clase String, pero an no se ha creado ningn objeto de esta clase.

Cmo se obtiene informacin acerca del string

Una vez creado un objeto de la clase String podemos obtener informacin relevante acerca del objeto a travs de las funciones miembro. Para obtener la longitud, nmero de caracteres que guarda un string se llama a la funcin miembro length.
String str="El primer programa"; int longitud=str.length();

Podemos conocer si un string comienza con un determinado prefijo, llamando al mtodo startsWith, que devuelve true o false, segn que el string comience o no por dicho prefijo
String str="El primer programa"; boolean resultado=str.startsWith("El");

En este ejemplo la variable resultado tomar el valor true. De modo similar, podemos saber si un string finaliza con un conjunto dado de caracteres, mediante la funcin miembro endsWith.

String str="El primer programa"; boolean resultado=str.endsWith("programa");

Si se quiere obtener la posicin de la primera ocurrencia de la letra p, se usa la funcin indexOf.

String str="El primer programa"; int pos=str.indexOf('p');

Para obtener las sucesivas posiciones de la letra p, se llama a otra versin de la misma funcin
pos=str.indexOf('p', pos+1);

El segundo argumento le dice a la funcin indexOf que empiece a buscar la primera ocurrencia de la letra p a partir de la posicin pos+1. Otra versin de indexOf busca la primera ocurrencia de un substring dentro del string.
String str="El primer programa"; int pos=str.indexOf("pro");

Vemos que una clase puede definir varias funciones miembro con el mismo nombre pero que tienen distinto nmero de parmetros o de distinto tipo.

Comparacin de strings
equals: EqualsApp.java La comparacin de strings nos da la oportunidad de distinguir entre el operador lgico == y la funcin miembro equals de la clase String. En el siguiente cdigo
String str1="El lenguaje Java"; String str2=new String("El lenguaje Java"); if(str1==str2){ System.out.println("Los mismos objetos"); }else{ System.out.println("Distintos objetos"); } if(str1.equals(str2)){ System.out.println("El mismo contenido"); }else{ System.out.println("Distinto contenido"); }

Esta porcin de cdigo devolver que str1 y str2 son dstintos objetos pero con el mismo contenido. str1 y str2 ocupan posiciones distintas en memoria pero guradan los mismos datos. Cambiemos la segunda sentencia y escribamos
String str1="El lenguaje Java"; String str2=str1; System.out.prinln("Son el mimso objeto "+(str1==str2);

Los objetos str1 y str2 guardan la misma referencia al objeto de la clase String creado. La expresin (str1==str2) devolver true. Asi pues, el mtodo equals compara un string con un objeto cualquiera que puede ser otro string, y devuelve true cuando dos strings son iguales o false si son distintos.
String str="El lenguaje Java"; boolean resultado=str.equals("El lenguaje Java");

La variable resultado tomar el valor true. La funcin miembro comapareTo devuelve un entero menor que cero si el objeto string es menor (en orden alfabtico) que el string dado, cero si son iguales, y mayor que cero si el objeto string es mayor que el string dado.
String str="Toms"; int resultado=str.compareTo("Alberto");

La variable entera resultado tomar un valor mayor que cero, ya que Toms est despus de Alberto en orden alfabtico.
String str="Alberto"; int resultado=str.compareTo("Toms");

La variable entera resultado tomar un valor menor que cero, ya que Alberto est antes que Toms en orden alfabtico.

Extraer un substring de un string

En muchas ocasiones es necesario extraer una porcin o substring de un string dado. Para este propsito hay una funcin miembro de la clase String denominada substring.

Para estraer un substring desde una posicin determinada hasta el final del string escribimos
String str="El lenguaje Java"; String subStr=str.substring(12);

Se obtendr el substring "Java". Una segunda versin de la funcin miembro substring, nos permite extraer un substring especificando la posicin de comienzo y la el final.
String str="El lenguaje Java"; String subStr=str.substring(3, 11);

Se obtendr el substring "lenguaje". Recurdese, que las posiciones se empiezan a contar desde cero.

Convertir un nmero a string

Para convertir un nmero en string se emplea la funcin miembro esttica valueOf (ms adelante explicaremos este tipo de funciones).
int valor=10; String str=String.valueOf(valor);

La clase String proporciona versiones de valueOf para convertir los datos primitivos: int, long, float, double. Esta funcin se emplea mucho cuando programamos applets, por ejemplo, cuando queremos mostrar el resultado de un clculo en el rea de trabajo de la ventana o en un control de edicin.

Convertir un string en nmero

Cuando introducimos caracteres en un control de edicin a veces es inevitable que aparezcan espacios ya sea al comienzo o al final. Para eliminar estos espacios tenemos la funcin miembro trim
String str=" 12 "; String str1=str.trim();

Para convertir un string en nmero entero, primero quitamos los espacios en blanco al principio y al final y luego, llamamos a la funcin miembro esttica parseInt de la clase Integer (clase envolvente que describe los nmeros enteros)
String str=" 12 "; int numero=Integer.parseInt(str.trim());

Para convertir un string en nmero decimal (double) se requieren dos pasos: convertir el string en un objeto de la clase envolvente Double, mediante la funcin miembro esttica valueOf, y a continuacin convertir el objeto de la clase Double en un tipo primitivo double mediante la funcin doubleValue
String str="12.35 "; double numero=Double.valueOf(str).doubleValue();

Se puede hacer el mismo procedimiento para convertir un string a nmero entero

String str="12"; int numero=Integer.valueOf(str).intValue();

La clase StringBuffer
En la seccin dedicada a los operadores hemos visto que es posible concatenar cadenas de caracteres, es, decir, objetos de la clase String. Ahora bien, los objetos de la clase String son constantes lo cual significa que por defecto, solamente se pueden crear y leer pero no se pueden modificar. Imaginemos una funcin miembro a la cual se le pasa un array de cadenas de caracteres. Los arrays se estudiarn en la siguiente pgina.
public class CrearMensaje{ public String getMensaje(String[] palabras){ String mensaje=""; for(int i=0; i<palabras.length; i++){ mensaje+=" "+palabras[i]; } return mensaje; } //... }

Cada vez que se aade una nueva palabra, se reserva una nueva porcin de memoria y se desecha la vieja porcin de memoria que es ms pequea (una palabra menos) para que sea

liberada por el recolector de basura (grabage collector). Si el bucle se realiza 1000 veces, habr 1000 porciones de memoria que el recolector de basura ha de identificar y liberar. Para evitar este trabajo extra al recolector de basura, se puede emplear la clase StringBuffer que nos permite crear objetos dinmicos, que pueden modificarse.
public class CrearMensaje{ public String getMensaje(String[] palabras){ StringBuffer mensaje=new StringBuffer(); for(int i=0; i<palabras.length; i++){ mensaje.append(" "); mensaje.append(palabras[i]); } return mensaje.toString(); } //... }

La funcin append incrementa la memoria reservada para el objeto mensaje con una palabra ms sin crear nueva memoria, cada vez que se ejecuta el bucle. La funcin toString, que veremos ms adelante, convierte un objeto en una cadena de caracteres. Crear una clase denominada Lista cuyo miembro dato sea un array de nmeros enteros y cuyas funciones miembro realicen las siguientes tareas:

Hallar y devolver el valor mayor Hallar y devolver el valor menor Hallar y devolver el valor medio Ordenar los nmeros enteros de menor a mayor Mostrar la lista ordenada separando los elementos por un tabulador lista: Lista.java, ListaApp.java

Definicin de la clase Lista

Empezamos la definicin de la clase escribiendo la palabra reservada class y a continuacin el nombre de la clase Lista.

Los miembros dato

Los miembros dato de la clase Lista sern un array de enteros x, y opcionalmente la dimensin del array n.
public class Lista { int[] x; //array de datos int n; //dimensin

El constructor
Al constructor de la clase Lista se le pasar un array de enteros para inicializar los miembros dato
public Lista(int[] x) { this.x=x; n=x.length; }

Como apreciamos basta una simple asignacin para inicializar el miembro dato x que es un array de enteros, con el array de enteros x que se le pasa al constructor. Por otra parte, cuando se le pasa a una funcin un array se le pasa implcitamente la dimensin del array, que se puede obtener a partir de su miembro dato length.

Las funciones miembro

Las funciones miembro tienen acceso a los miembros dato, el array de enteros x y la dimensin del array n.

El valor medio

Para hallar el valor medio, se suman todos los elementos del array y se divide el resultado por el nmero de elementos.
double valorMedio(){ int suma=0; for(int i=0; i<n; i++){ suma+=x[i]; } return (double)suma/n; }

Para codificar esta funcin se ha de tener algunas precauciones. La suma de todos los elementos del array se guarda en la variable local suma. Dicha variable local ha de ser inicializada a cero, ya que una variable local contrariamente a lo que sucede a los miembros

dato o variables de instancia es inicializada con cualquier valor en el momento en que es declarada. La divisin de dos enteros suma y n (nmero de elementos del array) es un nmero entero. Por tanto, se ha de promocionar el entero suma de int a double para efectuar la divisin y devolver el resultado de esta operacin.

El valor mayor
int valorMayor(){ int mayor=x[0]; for(int i=1; i<n; i++){ if(x[i]>mayor) mayor=x[i]; } return mayor; }

Se compara cada elemento del array con el valor de la variable local mayor, que inicialmente tiene el valor del primer elemento del array, si un elemento del array es mayor que dicha variable auxiliar se guarda en ella el valor de dicho elemento del array. Finalmente, se devuelve el valor mayor calculado

El valor menor
int valorMenor(){ int menor=x[0]; for(int i=1; i<n; i++){ if(x[i]<menor) menor=x[i]; } return menor; }

El cdigo es similar a la funcin valorMayor

Ordenar un conjunto de nmeros

En el proceso de ordenacin se ha de intercambiar los valores que guardan elementos del array. Veamos como sera el cdigo correspondiente al intercambio de los valores que guardan dos variables x e y. Para intercambiar el contenido de dos recipientes x e y sin que se mezclen, precisamos de un recipiente auxiliar aux vaco. Se vuelca el contenido del recipiente x en el recipiente aux, el recipiente y se vuelca en x, y por ltimo, el recipiente aux se vuelca en y. Al final del proceso, el recipiente aux vuelve a estar vaco como al principio. En la figura se esquematiza este proceso.
aux=x; x=y; y=aux;

Para ordenar una lista de nmeros emplearemos el mtodo de la burbuja, un mtodo tan simple como poco eficaz. Se compara el primer elemento, ndice 0, con todos los dems elementos de la lista, si el primer elemento es mayor que el elemento j, se intercambian sus valores, siguiendo el procedimiento explicado en la figura anterior. Se continua este procedimiento con todos los elementos del array menos el ltimo. La figura explica de forma grfica este procedimiento.
void ordenar(){ int aux; for(int i=0; i<n-1; i++){ for(int j=i+1; j<n; j++){ if(x[i]>x[j]){ aux=x[j]; x[j]=x[i]; x[i]=aux; } } } }

Caben ahora algunas mejoras en el programa, as la funcin ordenar la podemos utilizar para hallar el valor mayor, y el valor menor. Si tenemos una lista ordenada en orden ascendente, el ltimo elemento de la lista ser el valor mayor y el primero, el valor menor.

De este modo, podemos usar una funcin en otra funciones, lo que resulta en un ahorro de cdigo, y en un aumento de la legibilidad del programa.
int valorMayor(){ ordenar(); return x[n-1]; } int valorMenor(){ ordenar(); return x[0]; }

Imprimir la lista ordenada

Imprimimos la lista ordenada separando sus elementos por un tabulador. Primero, se llama a la funcin ordenar, y despues se imprime un elemento a continuacin del otro mediante System.out.print. Recurdese, que System.out.println imprime y a continuacin pasa a la siguiente lnea.
void imprimir(){ ordenar(); for(int i=0; i<n; i++){ System.out.print("\t"+x[i]); } System.out.println(""); }

El cdigo completo de la clase Lista, es el siguiente

public class Lista { int[] x; //array de datos int n; //dimensin public Lista(int[] x) { this.x=x; n=x.length; } double valorMedio(){ int suma=0; for(int i=0; i<n; i++){ suma+=x[i]; } return (double)suma/n; } int valorMayor(){ int mayor=x[0]; for(int i=1; i<n; i++){ if(x[i]>mayor) mayor=x[i]; } return mayor; } int valorMenor(){ int menor=x[0];

for(int i=1; i<n; i++){ if(x[i]<menor) menor=x[i]; } return menor; } void ordenar(){ int aux; for(int i=0; i<n-1; i++){ for(int j=i+1; j<n; j++){ if(x[i]>x[j]){ aux=x[j]; x[j]=x[i]; x[i]=aux; } } } } void imprimir(){ ordenar(); for(int i=0; i<n; i++){ System.out.print("\t"+x[i]); } System.out.println(""); } }

Los objetos de la clase Lista

A partir de un array de enteros podemos crear un objeto lista de la clase Lista.
int[] valores={10, -4, 23, 12, 16}; Lista lista=new Lista(valores);

Estas dos sentencias las podemos convertir en una

Lista lista=new Lista(new int[] {10, -4, 23, 12, 16});

En el resto del cdigo, el objeto lista llama a las funciones miembro

System.out.println("Valor mayor "+lista.valorMayor()); System.out.println("Valor menor "+lista.valorMenor()); System.out.println("Valor medio "+lista.valorMedio()); lista.imprimir();

http://www.sc.ehu.es/sbweb/fisica/cursoJava/fundamentos/clases1/poo1.htm 2.2.2 Interaccin.

2.2.3 Estados y Transiciones.

III.1.1 Diagramas De Actividades Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinmico de un sistema: Diagramas de secuencia Diagramas de colaboracin Diagramas de estados Diagramas de casos de uso Diagramas de actividades En este captulo nos centraremos en los diagramas de actividades que sirven fundamentalmente para modelar el flujo de control entre actividades. La idea es generar una especie de diagrama Pert, en el que se puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, as como las tareas concurrentes que pueden realizarse a la vez. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos. Grficamente un diagrama de actividades ser un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cmo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecucin de un proceso ms complejo. Por este motivo, en un diagrama de actividades aparecern acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido. III.1.2 Contenido del diagrama de actividades Bsicamente un diagrama de actividades contiene: Estados de actividad Estados de accin Transiciones Objetos III.1.2.1 Estados de actividad y estados de accin La representacin de ambos es un rectngulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una accin. La forma de expresar tanto una actividad como una accin, no queda impuesta por UML, se podra utilizar lenguaje natural, una especificacin formal de expresiones, un metalenguaje, etc. La idea central es la siguiente: Un estado que represente una accin es atmico, lo que significa que su ejecucin se puede considerar instantnea y no puede ser interrumpida En la Figura 21, podemos ver ejemplos de estados de accin.

Figura 21 Estados de Accin En cambio un estado de actividad, s puede descomponerse en ms sub-actividades representadas a travs de otros diagramas de actividades. Adems estos estados s pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestin, as como definicin de submquinas, como podemos ver en la Figura 22.

Figura 22 Estado de Actividad III.1.2.2 Transiciones Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de accin. Esta transicin se produce como resultado de la finalizacin del estado del que parte el arco dirigido que marca la transicin. Como todo flujo de control debe empezar y terminar en algn momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo de la Figura 23.

Figura 23 Transiciones sin disparadores III.1.2.3 Bifurcaciones

Un flujo de control no tiene porqu ser siempre secuencial, puede presentar caminos alternativos. Para poder representar dichos caminos alternativos o bifurcacin se utilizar como smbolo el rombo. Dicha bifurcacin tendr una transicin de entrada y dos o ms de salida. En cada transicin de salida se colocar una expresin booleana que ser evaluada una vez al llegar a la bifurcacin, las guardas de la bifurcacin han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecucin del flujo de control quedara interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transicin obligada a un determinado estado cuando el resto de guardas han fallado. En la Figura 24 podemos ver un ejemplo de bifurcacin.

Figura 24 Bifurcacin III.1.2.4 Divisin y unin No slo existe el flujo secuencial y la bifurcacin, tambin hay algunos casos en los que se requieren tareas concurrentes. UML representa grficamente el proceso de divisin, que representa la concurrencia, y el momento de la unin de nuevo al flujo de control secuencial, por una lnea horizontal ancha. En la Figura 25 podemos ver cmo se representa grficamente.

Figura 25 Divisin y unin

III.1.2.5 Calles Cuando se modelan flujos de trabajo de organizaciones, es especialmente til dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles. Cada calle representa a la parte de la organizacin responsable de las actividades que aparecen en esa calle. Grficamente quedara como se muestra en la Figura 26.

Figura 26 Calles
http://www.clikear.com/manuales/uml/modelodinamico.asp

3 Construccin. 3.1 Despliegue de componentes y arquitectnico. III.2.1 Componentes Los componentes pertenecen al mundo fsico, es decir, representan un bloque de construccin al modelar aspectos fsicos de un sistema. Una caracterstica bsica de un componente es que: debe definir una abstraccin precisa con una interfaz bien definida, y permitiendo reemplazar fcilmente los componentes ms viejos con otros ms nuevos y compatibles. En UML todos los elementos fsicos se modelan como componentes. UML proporciona una representacin grfica para estos como se puede ver en la Figura 27, en la que XXXX.dll, es el nombre del componente.

Figura 27 Representacin de un componente Cada componente debe tener un nombre que lo distinga de los dems. Al igual que las clases los componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles, como se puede ver en la Figura 28.

Figura 28 Representacin extendida de un componente Vamos a ver con ms detalle cules son los parecidos y las diferencias entre los componentes y las clases. PARECIDOS Ambos tienen nombre Ambos pueden realizar un conjunto de interfaces. Pueden participar en relaciones de dependencia, generalizacin y asociacin. Ambos pueden anidarse Ambos pueden tener instancias Ambos pueden participar en interacciones DIFERENCIAS Las Clases Los Componentes Representan abstracciones lgicas Representan elementos fsicos Es decir los componentes pueden estar en nodos y las clases no Pueden tener atributos y operacionesdirectamente accesibles. Slo tienen operaciones y estas son alcanzables a travs de la interfaz del componente.
3.2 Tcnicas de desarrollo de las arquitecturas de referencia en diferentes dominios.

III.2.1.1 Interfaces Tanto los servicios propio de una clase como los de un componente, se especifican a travs de una Interfaz. Por ejemplo, todas las facilidades ms conocidas de los sistemas operativos, basados en componentes (COM+, CORBA, etc.), utilizan las interfaces como lazo de unin entre unos componentes y otros. La relacin entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icnica como se indica en la Figura 29, y de forma expandida como se muestra en la Figura 30.

Figura 29 Componentes e interfaces, formato icnico

Figura 30 Componentes e interfaces, formato extendido

3.2.1 Los modelos de componentes.

III.2.1.2 Tipos de componentes Existen bsicamente tres tipos de componentes: ? Componentes de despliegue: componentes necesarios y suficientes para formar un sistema ejecutable, como pueden ser las bibliotecas dinmicas (DLLs) y ejecutables (EXEs). ? Componentes producto del trabajo: estos componentes son bsicamente productos que quedan al final del proceso de desarrollo. Consisten en cosas como archivos de cdigo fuente y de datos a partir de los cuales se crean los componentes de despliegue. ? Componentes de ejecucin: son componentes que se crean como consecuencia de un sistema en ejecucin. Es el caso de un objeto COM+ que se instancia a partir de una DLL. III.2.1.3 Organizacin de componentes Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases. Adems se pueden especificar entre ellos relaciones de dependencia, generalizacin, asociacin (incluyendo agregacin), y realizacin. III.2.1.4 Estereotipos de componentes UML define cinco estereotipos estndar que se aplican a los componentes: executable Componente que se puede ejecutar en un nodo. library Biblioteca de objetos esttica o dinmica. table Componentes que representa una tabla de una base de datos. file Componente que representa un documento que contiene cdigo fuente o datos. document Componente que representa un documento. UML no especifica iconos predefinidos para estos estereotipos.

III.2.2 Despliegue III.2.2.1 Nodos Al igual que los componentes los nodos pertenecen al mundo material. Vamos a definir un nodo como un elemento fsico, que existe en tiempo de ejecucin y representa un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento. Los nodos sirven para modelar la topologa del hardware sobre el que se ejecuta el sistema. Un nodo representa normalmente un procesador o un dispositivo sobre el que se pueden desplegar los componentes. Un nodo debe tener un nombre asignado que lo distinga del resto de nodos. Adems los nodos se representan grficamente como se indica en la Figura 31.

Figura 31 Nodos III.2.2.2 Nodos y componentes En muchos aspectos los nodos y los componentes tienen caractersticas parecidas. Vamos a ver con ms detalle cuales son los parecidos y las diferencias entre los componentes y los nodos. PARECIDOS Ambos tienen nombre Pueden participar en relaciones de dependencia, generalizacin y asociacin. Ambos pueden anidarse Ambos pueden tener instancias Ambos pueden participar en interacciones DIFERENCIAS Los Nodos Los Componentes Son los elementos donde se ejecutan los componentes. Son los elementos que participan en la ejecucin de un sistema. Representan el despliegue fsico de los componentes. Representan el empaquetamiento fsico de los elementos lgicos. La relacin entre un nodo y los componentes que despliega se pueden representar mediante una relacin de dependencia como se indica en la Figura 32. Los nodos se pueden agrupar en paquetes igual que los las clases y los componentes. Los tipos de relacin ms comn entre nodos es la asociacin. Una asociacin entre nodos viene a representar una conexin fsica entre nodos como se puede ver en la Figura 33.

Figura 32 Relacin entre nodos y componentes

Figura 33 Conexiones entre nodos Existen dos tipos de diagramas que sirven para modelar los aspectos fsicos de un sistema orientado a objetos: Diagramas de Componentes Diagramas de Despliegue Seguidamente veremos para qu sirve cada uno de ellos y cual es su representacin grfica. III.2.3 Diagramas de Componentes Un diagrama de componentes muestra la organizacin y las dependencias entre un conjunto de componentes. Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte esttica (diagrama de clases), como dinmica (diagramas de secuencia, colaboracin, estados y de actividades), pero llegado el momento todo esto se debe materializar en un sistema implementado que utilizar partes ya implementadas de otros sistemas, todo esto es lo que pretendemos modelar con los diagramas de componentes. III.2.3.1 Algunos conceptos Un diagrama de componentes muestra un conjunto de componentes y sus relaciones de manera grfica a travs del uso de nodos y arcos entre estos. Normalmente los diagramas de componentes contienen: Componentes Interfaces Relaciones de dependencia, generalizacin, asociaciones y realizacin. Paquetes o subsistemas Instancias de algunas clases

Visto de otro modo un diagrama de componentes puede ser un tipo especial de diagrama de clases que se centra en los componentes fsicos del sistema. III.2.3.2 Usos ms comunes a) Modelado de Cdigo Fuente Los diagramas de componentes se pueden utilizar para modelar la gestin de la configuracin de los archivos de cdigo fuente, tomando como productos de trabajo precisamente estos ficheros. Esto resulta bastante til por ejemplo cuando se han implementado unas partes con Java otras con C, etc. El resultado de esta implementacin pueden ser multitud de ficheros ejecutables con caractersticas particulares, de manera que la mejor forma de controlarlos es estableciendo gestin de configuracin. Para poder llevar a cabo esta gestin con xito ser necesario definir los estereotipos de ficheros que se quieren tener bajo control as como las relaciones entre dichos tipos de ficheros. Para modelar el cdigo fuente de un sistema: Hay que identificar el conjunto de archivos de cdigo fuente de inters y modelarlos como componentes estereotipados como archivos. Si el sistema es muy grande es necesario utilizar los paquetes para agrupar los archivos de cdigo fuente. Es necesario identificar la versin del componente. b) Modelado de una versin ejecutable y bibliotecas. La utilizacin de los componentes para modelar versiones ejecutables se centra en la definicin de todos los elementos que componen lo que se conoce como versin ejecutable, es decir la documentacin, los ficheros que se entregan etc. Para modelar una versin ejecutable es preciso: Identificar el conjunto de componentes que se pretende modelar. Identificar el estereotipo de cada componente del conjunto seleccionado. Para cada componente de este conjunto hay que considerar las relaciones con los vecinos. Esto implica definir las interfaces importadas por ciertos componentes y las exportadas por otros. c) Modelado de una base de datos fsica Para modelar una base de datos fsica es necesario: Identificar las clases del modelo que representan el esquema lgico de la base de datos. Seleccionar una estrategia para hacer corresponder las clases con tablas. As como la distribucin fsica de la/s base/s de datos. Para poder visualizar, especificar, construir y documentar dicha correspondencia es necesario crear un diagrama de componentes que tenga componentes estereotipados como tablas. Donde sea posible es aconsejable utilizar herramientas que ayuden a transformar diseo lgico en fsico. III.2.4 Diagramas de Despliegue III.2.4.1 Tcnicas ms comunes de modelado a) Modelado de un sistema empotrado El desarrollo de un sistema empotrado es ms que el desarrollo de un sistema software. Hay que manejar el mundo fsico. Los diagramas de despliegue son tiles para facilitar la comunicacin entre los ingenieros de hardware y los de software.

Para modelar un sistema empotrado es necesario: Identificar los dispositivos y nodos propios del sistema. Proporcionar seales visuales, sobre todo para los dispositivos poco usuales. Modelar las relaciones entre esos procesadores y dispositivos en un diagrama de despliegue. Si es necesario hay que detallar cualquier dispositivo inteligente, modelando su estructura en un diagrama de despliegue ms pormenorizado. b) Modelado de un sistema cliente servidor La divisin entre cliente y servidor en un sistema es complicada ya que implica tomar algunas decisiones sobre dnde colocar fsicamente sus componentes software, qu cantidad de software debe residir en el cliente, etc. Para modelar un sistema cliente/servidor hay que hace lo siguiente: Identificar los nodos que representan los procesadores cliente y servidor del sistema. Destacar los dispositivos relacionados con el comportamiento del sistema. Proporcionar seales visuales para esos procesadores y dispositivos a travs de estereotipos. Modelar la tipologa de esos nodos mediante un diagrama de despliegue. III.2.5 Arquitectura del Sistema III.2.5.1 Arquitectura de tres niveles La llamada Arquitectura en Tres Niveles, es la ms comn en sistemas de informacin que adems de tener una interfaz de usuario contemplan la persistencia de los datos. Una descripcin de los tres niveles sera la siguiente: Nivel 1: Presentacin ventanas, informes, etc. Nivel 2: Lgica de la Aplicacin tareas y reglas que gobiernan el proceso. Nivel 3: Almacenamiento mecanismo de almacenamiento. III.2.5.2 Arquitectura de tres niveles orientadas a objetos a) Descomposicin del nivel de lgica de la aplicacin En el diseo orientado a objetos, el nivel de lgica de la aplicacin se descompone en subniveles que son los siguientes: Objetos del Dominio: son clases que representan objetos del dominio. Por ejemplo en un problema de ventas, una Venta sera un objeto del dominio. Servicios: se hace referencia a funciones de interaccin con la base de datos, informes, comunicaciones, seguridad, etc. III.2.5.3 Arquitectura MULTI-nivel La arquitectura de tres niveles puede pasar a llamarse de Mltiples Niveles si tenemos en cuenta el hecho de que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada uno de ellos cada vez ms. Por ejemplo el nivel de Servicios, se puede descomponer en servicios de alto y de bajo nivel, identificando como de alto nivel los servicios de generacin de informes y como de bajo nivel los de manejo de ficheros de entrada y salida. El motivo que lleva a descomponer la arquitectura del sistema en diferentes niveles es mltiple: Separacin de la lgica de la aplicacin en componentes separados que sean ms fcilmente reutilizables.

 Distribucin de niveles en diferentes nodos fsicos de computacin. Reparto de recursos humanos en diferentes niveles de la arquitectura. III.2.5.4 Paquetes La forma que tiene UML de agrupar elementos en subsistemas es a travs del uso de Paquetes, pudindose anidar los paquetes formando jerarquas de paquetes. De hecho un sistema que no tenga necesidad de ser descompuesto en subsistemas se puede considerar como con un nico paquete que lo abarca todo. Grficamente un paquete viene representado como se indica en la Figura 34.

Figura 34 Representacin de un paquete en UML En la Figura 35, vemos cmo se representa la arquitectura del sistema con la notacin de paquetes.

Figura 35 Arquitectura de un sistema utilizando paquetes III.2.5.5 Identificacin de Paquetes Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora de agrupar los diferentes elementos en paquetes. Conviene agrupar elementos que proporcionen un mismo servicio. Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de cohesin, es decir deben estar muy relacionados. Los elementos que estn en diferentes paquetes deben tener poca relacin, es decir deben colaborar lo menos posible.

3.2.2 Arquitectura de referencia para sistemas de tiempo real fuente de alimentacin.

Estilos arquitectnicos

El tpico ms urgente y exitoso en arquitectura de software en los ltimos cuatro o cinco aos es, sin duda, el de los patrones (patterns), tanto en lo que concierne a los patrones de diseo como a los de arquitectura. Inmediatamente despus, en una relacin a veces de complementariedad, otras de oposicin, se encuentra la sistematizacin de los llamados estilos arquitectnicos. Cada vez que alguien celebra la mayora de edad de la arquitectura de software, y aunque seale otros logros como la codificacin de los ADLs o las tcnicas de refinamiento, esos dos temas se destacan ms que cualesquiera otros [Gar00] [Shaw01]. Sin embargo, slo en contadas ocasiones la literatura tcnica existente se ocupa de analizar el vnculo entre estilos y patrones [Shaw94] [SG95] [SC96] [BMR+96] [MKM+97] [Hil01a] [Hil01b]. Se los yuxtapone cada vez que se enumeran las ideas y herramientas disponibles, se seala con frecuencia su aire de familia, pero no se articula formal y sistemticamente su relacin.

Habr que admitir desde el vamos que ambos asuntos preocupan y tienen como destinatarios a distintas clases de profesionales, o diferentes stakeholders, como ahora se recomienda llamar: quienes trabajan con estilos favorecen un tratamiento estructural que concierne ms bien a la teora, la investigacin acadmica y la arquitectura en el nivel de abstraccin ms elevado, mientras que quienes se ocupan de patrones se ocupan de cuestiones que estn ms cerca del diseo, la prctica, la implementacin, el proceso, el refinamiento, el cdigo. Los patrones coronan una prctica de diseo que se origina antes que la arquitectura de software se distinguiera como discurso en perpetuo estado de formacin y proclamara su independencia de la ingeniera en general y el modelado en particular. Los estilos, en cambio, expresan la arquitectura en el sentido ms formal y terico, constituyendo un tpico esencial de lo que Goguen ha llamado el campo seco de la disciplina [Gog92]. Ms adelante volveremos sobre esta distincin.

Conviene caracterizar el escenario que ha motivado la aparicin del concepto de estilo, antes siquiera de intentar definirlo. Desde los inicios de la arquitectura de software, se observ que en la prctica del diseo y la implementacin ciertas regularidades de configuracin aparecan una y otra vez como respuesta a similares demandas. El nmero de esas formas no pareca ser muy grande. Muy pronto se las llam estilos, por analoga con el uso del trmino en arquitectura de edificios. Un estilo describe entonces una clase de arquitectura, o piezas identificables de las arquitecturas empricamente dadas. Esas piezas se encuentran repetidamente en la prctica, trasuntando la existencia de decisiones estructurales coherentes. Una vez que se han identificado los estilos, es lgico y natural pensar en re-utilizarlos en situaciones semejantes que se presenten en el futuro [Kaz01]. Igual que los patrones de arquitectura y diseo, todos los estilos tienen un

nombre: cliente-servidor, modelo-vista-controlador, tubera-filtros, arquitectura en capas

Como conceptos, los estilos fueron formulados por primera vez cuando el escenario tecnolgico era sustancialmente distinto del que se manifiesta hoy en da. Es por eso que en este estudio se analizarn las definiciones de los estilos arquitectnicos que se han propuesto, as como su posicin en el campo de las vistas de arquitectura, su lugar en la metodologa y su relacin con los patrones, tomando en consideracin las innovaciones experimentadas por el campo de los estilos desde su formulacin inicial en 1992, coincidente con el instante que la IEEE identifica como el del nacimiento de la arquitectura de software en sentido estricto. Desde que surgieran tanto la disciplina como los estilos no slo se han generalizado arquitecturas de cliente-servidor, sino que experimentaron su auge primero las configuraciones en varias capas y luego las basadas en componentes, en recursos (la Web) y en servicios (los Web services). Las metodologas de ingeniera tambin experimentaron evoluciones naturales y hasta revoluciones extremas, de modo que habr que analizar en algn momento si ciertas prcticas que antes se daban por sentadas siguen o no en pie y en qu estado de salud se encuentran; y como el trabajo que se est leyendo se realiza en un momento en que son unos cuantos los que hablan de crisis, habr que ver si las ideas en juego tienden a acentuar los problemas o constituyen una va de solucin.

En el estudio que sigue se analizar el repertorio de los estilos como un asunto de inherente inters descriptivo, taxonmico y heurstico. Tambin se ahondar en su relacin con patrones y usos como una forma de vincular la teora con la prctica, aunque se sepa que sus mundos conceptuales difieren. Lo importante aqu es que la teora del arquitecto derive en la prctica de la implementacin de sistemas, que en ocasiones se presenta como dominada por un pragmatismo propio de hackers o fundamentalistas de la orientacin a objetos, como si la empiria de la implementacin no se coordinara con ningn orden de carcter terico (aparte de los objetos, por supuesto), o como si el conocimiento experto que se pretende re-utilizar en el bajo nivel no pudiera dar cuenta de sus propias razones estructurales. El marco en el que se desenvuelve el presente estudio es el de la estrategia de arquitectura de Microsoft, que en los ltimos aos ha hecho especial hincapi en las arquitecturas basadas en servicios y en patrones de diseo. El propsito es no slo delimitar y tipificar un campo tan estrechamente relacionado con esa estrategia como pudiera ser el de las investigaciones acadmicas en arquitectura, sino establecer una nomenclatura de formas arquitectnicas que la documentacin que ha comunicado la estrategia global de Microsoft no tuvo oportunidad de poner en foco, dando por sentadas la mayor parte de las cuestiones de naturaleza terica y concentrndose en la prctica [Platt02]. Este texto servir entonces como puente entre (1) una estrategia particular de arquitectura, (2) instancias de aplicacin de estilos en productos, lenguajes y sistemas de Microsoft y (3) el dominio terico de la arquitectura de software en general.

Arriba

Definiciones de estilo

Cuando se habla de una arquitectura en tres capas, o una arquitectura cliente-servidor, u orientada a servicios, implcitamente se est haciendo referencia a un campo de posibilidades articulatorias, a una especie de taxonoma de las configuraciones posibles, en cuyo contexto la caracterizacin tipolgica particular adquiere un significado distintivo. No tiene caso, a fin de cuentas, hablar de tipos arquitectnicos si no se clarifica cul es la tipologa total en la que cada uno de ellos engrana. Definir una arquitectura como (por ejemplo) orientada a servicios ciertamente la tipifica, la distingue, la singulariza; pero cules son las otras arquitecturas alternativas? Es esa arquitectura especfica una clase abarcadora, o es apenas una variante que est incluida en otros conjuntos clases ms amplios? En qu orden de magnitud se encuentra el nmero de las opciones con las cuales contrasta? O bien, cuntas otras formas podran adoptarse? Ocho? Cien? A qu otras se asemeja ms la estructura escogida? Cul es su modelo peculiar de tradeoff? Desde Ferdinand de Saussure, la semntica lingstica sabe que un determinado signo (arquitectura orientada a servicios, en este caso) adquiere un valor de significacin cabal tanto por ser lo que es, como por el hecho de ser lo que otros signos no son. La idea dominante de esta seccin del documento ser proporcionar las definiciones denotativas de la clase: qu es un estilo; la de la seccin siguiente, definir el valor de los ejemplares en el sistema de las posibilidades: sabiendo lo que son los estilos, definir cuntos hay y cules son.

La cuestin no es slo clasificatoria. El hecho es que optar por una forma arquitectnica no solamente tiene valor distintivo, sino que define una situacin pragmtica. Una vez que los tipos adquieren una dimensin semntica precisa y diferencial, se ver que a su significado se asocian conceptos, herramientas, problemas, experiencias y antecedentes especficos. Despus de recibir nombres variados tales como clases de arquitectura, tipos arquitectnicos, arquetipos recurrentes, especies, paradigmas topolgicos, marcos comunes y varias docenas ms, desde hace ms de una dcada esas cualificaciones arquitectnicas se vienen denominando estilos, o alternativamente patrones de arquitectura. Llamarlas estilos subraya explcitamente la existencia de una taxonoma de las alternativas estilsticas; llamarlas patrones, por el contrario, establece su vinculacin con otros patrones posibles pero de distinta clase: de diseo, de organizacin o proceso, de cdigo, de interfaz de usuario, de prueba, de anlisis, de refactoring.

Los estilos slo se manifiestan en arquitectura terica descriptiva de alto nivel de abstraccin; los patrones, por todas partes. Los partidarios de los estilos se definen desde el inicio como arquitectos; los que se agrupan en torno de los patrones se confunden a veces con ingenieros y diseadores, cuando no con programadores con conciencia sistemtica o lo que alguna vez se llam analistas de software. El primer

grupo ha abundado en taxonomas internas de los estilos y en reflexin terica; el segundo se ha mantenido, en general, refractario al impulso taxonmico, llevado por una actitud resueltamente emprica. Ambos, con mayor o menor plenitud y autoconciencia, participan del campo abarcativo de la arquitectura de software. Los estilos se encuentran en el centro de la arquitectura y constituyen buena parte de su sustancia. Los patrones de arquitectura estn claramente dentro de la disciplina arquitectnica, solapndose con los estilos, mientras que los patrones de diseo se encuentran ms bien en la periferia, si es que no decididamente afuera.

En lo que sigue, y atenindonos a la recomendacin IEEE-1471, arquitectura de software se entender como la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones de los componentes con cada uno de los otros y con el entorno, y los principios que orientan su diseo y evolucin. Debe quedar claro que en esta definicin el concepto de componente es genrico e informal, y no se refiere slo a lo que tcnicamente se concibe como tal en modelos de componentes como CORBA Component Model, J2EE (JavaBeans o EJB), ActiveX, COM, COM+ o .NET. En todo caso, la definicin de arquitectura a la que aqu habremos de atenernos es la misma que se establece en la documentacin fundamental de la estrategia de arquitectura de Microsoft [Platt02].

Segn esa definicin, estilos y arquitectura nacen en el mismo momento. Con una sola excepcin (documentada en el prrafo siguiente) no he podido encontrar referencias a la palabra estilo anteriores a 1992. Todava en julio de ese ao Robert Allen y David Garlan [AG92] de la Universidad de Carnegie Mellon se refieren a paradigmas de arquitectura y estructuras de sistemas, mencionando entre ellos lo que luego sera el familiar estilo tubera-filtros, los modelos de pizarra y los de flujo de datos. Con nombres idnticos, esos paradigmas pasaran a llamarse estilos un mes ms tarde en todos los textos de la misma escuela primero y en toda la arquitectura de software despus.

Un ao antes, sin embargo, aparece una mencin casi accidental a los estilos de arquitectura en una escuela que no volvera a prestar atencin al concepto casi hasta el siglo siguiente. En 1991 los promotores de OMT del Centro de Investigacin y Desarrollo de General Electric en Shenectady liderados por James Rumbaugh haban hablado de la existencia es estilos arquitectnicos [RBP+91: 198], arquitecturas comunes [p. 199], marcos de referencia arquitectnicos prototpicos [p. 211] o formas comunes [ p. 212] que se aplican en la fase de diseo; aunque el espritu es el mismo que el que anim la idea de los estilos, el inventario difiere. Los autores, en efecto, mencionan clases de sistemas que incluyen (1) transformaciones en lote; (2) transformaciones continuas; (3) interfaz interactiva, (4) simulacin dinmica de objetos del mundo real, (5) sistemas de tiempo real, (6) administrador de transacciones con almacenamiento y actualizacin de datos [p. 211-216]. Algunas de estas clases, llamadas las cinco veces que se menciona su conjunto con cinco denominaciones diferentes, se pueden reconocer con los nombres siempre cambiados en

los catlogos ulteriores de estilos de la arquitectura estructuralista [AG92] [Shaw94] [GS94] [BCK98] [Fie00]. El equipo de Rumbaugh no volvi a mencionar la idea de estilos arquitectnicos (ni la de arquitectura) fuera de esas pginas referidas, consumando el divorcio implcito entre lo que podra llamarse la escuela de diseo orientada a objetos y la escuela de arquitectura estructuralista, mayormente eclctica.

Las primeras definiciones explcitas y autoconscientes de estilo parecen haber sido propuestas por Dewayne Perry de AT&T Bell Laboratories de New Jersey y Alexander Wolf de la Universidad de Colorado [PW92]. En octubre de 1992, estos autores profetizan que la dcada de 1990 habra de ser la de la arquitectura de software, y definen esa arquitectura en contraste con la idea de diseo. Ledo hoy, y aunque el acontecimiento es ms reciente de lo que parece, su llamamiento resulta proftico y fundacional hasta lo inverosmil; en l, la arquitectura y los estilos se inauguran simblicamente en una misma frase definitoria: La dcada de 1990, creemos, ser la dcada de la arquitectura de software. Usamos el trmino arquitectura, en contraste con diseo, para evocar nociones de codificacin, de abstraccin, de estndares, de entrenamiento formal (de arquitectos de software) y de estilo [PB92]. Advierten, adems, que curiosamente no existen arquitecturas que tengan un nombre, como no sea en relacin con estructuras de hardware. Por analoga con la arquitectura de edificios, establecen que una arquitectura se define mediante este modelo:

Arquitectura de Software = { Elementos, Forma, Razon }

Siguiendo con el razonamiento, encuentran tres clases de elementos: de procesamiento (que suministran la transformacin de los datos), de datos (que contienen la informacin a procesar) y de conexin (por ejemplo, llamadas a procedimientos, mensajes, etc). La forma define las propiedades y las relaciones. La razn, finalmente, captura la motivacin para la eleccin de los elementos y sus formas. Luego definen un estilo arquitectnico como una abstraccin de tipos de elementos y aspectos formales a partir de diversas arquitecturas especficas. Un estilo arquitectnico encapsula decisiones esenciales sobre los elementos arquitectnicos y enfatiza restricciones importantes de los elementos y sus relaciones posibles. En nfasis en las restricciones (constraints) proporciona una visibilidad a ciertos aspectos de la arquitectura, de modo tal que la violacin de esos aspectos y la insensibilidad hacia ellos se tornen ms manifiestas. Un segundo nfasis, ms circunstancial, concierne a la susceptibilidad de los estilos arquitectnicos a ser reutilizados. Llamativamente, en el estudio que inaugura la idea de los estilos arquitectnicos (y al margen de una referencia a arquitecturas secuenciales y paralelas) no aparece todava ningn atisbo de tipologa estilstica.

Llamo la atencin respecto de que la definicin minimalista propuesta por Perry y Wolf para los estilos ha sido incluso reducida a una que comprende nicamente elementos y relaciones para definir no slo los estilos, sino la incumbencia global (el contenido y los lmites) de la propia arquitectura de software [BCK98]. Sealo tambin que antes de Perry y Wolf ciertamente se hablaba de arquitectura, e incluso de arquitectura

de software, para denotar la configuracin o la organizacin de un sistema o de sus modelos; pero no se hablaba de arquitectura de software como un nivel de abstraccin merecedor de una disciplina especfica.

Algunos aos ms tarde Mary Shaw y Paul Clements [SC96] identifican los estilos arquitectnicos como un conjunto de reglas de diseo que identifica las clases de componentes y conectores que se pueden utilizar para componer en sistema o subsistema, junto con las restricciones locales o globales de la forma en que la composicin se lleva a cabo. Los componentes, incluyendo los subsistemas encapsulados, se pueden distinguir por la naturaleza de su computacin: por ejemplo, si retienen estado entre una invocacin y otra, y de ser as, si ese estado es pblico para otros componentes. Los tipos de componentes tambin se pueden distinguir conforme a su forma de empaquetado, o dicho de otro modo, de acuerdo con las formas en que interactan con otros componentes. El empaquetado es usualmente implcito, lo que tiende a ocultar importantes propiedades de los componentes. Para clarificar las abstracciones se asla la definicin de esas interacciones bajo la forma de conectores: por ejemplo, los procesos interactan por medio de protocolos de transferencia de mensajes, o por flujo de datos a travs de tuberas (pipes). Es en gran medida la interaccin entre los componentes, mediados por conectores, lo que confiere a los distintos estilos sus caractersticas distintivas. Ntese que en esta definicin de estilo, que se quiere mantener abstracta, entre las entidades de primera clase no aparece prcticamente nada que se refiera a datos o modelo de datos.

Tampoco aparece explcitamente en la caracterizacin de David Garlan, Andrew Kompanek, Ralph Melton y Robert Monroe [GKM+96], tambin de Carnegie Mellon, que definen el estilo como una entidad consistente en cuatro elementos: (1) Un vocabulario de elementos de diseo: componentes y conectores tales como tuberas, filtros, clientes, servidores, parsers, bases de datos, etctera. (2) Reglas de diseo o restricciones que determinan las composiciones permitidas de esos elementos. (3) Una interpretacin semntica que proporciona significados precisos a las composiciones. (4) Anlisis susceptibles de practicarse sobre los sistemas construidos en un estilo, por ejemplo anlisis de disponibilidad para estilos basados en procesamiento en tiempo real, o deteccin de abrazos mortales para modelos cliente-servidor. En un artculo conexo, Garlan, Allen y Ockerbloom establecen dos grandes categoras de estilos: (1) Idiomas y patrones, que incluye estructuras globales de organizacin, como ser sistemas en capas, tubera-filtros, clienteservidor, pizarras, MVC, etctera. (2) Modelos de referencia, que son organizaciones de sistemas que prescriben configuraciones especficas de dominio o reas de aplicacin, a menudo parametrizadas [GAO94].

En un ensayo de 1996 en el que aportan fundamentos para una caracterizacin formal de las conexiones arquitectnicas, Robert Allen y David Garlan [AG96] asimilan los estilos arquitectnicos a descripciones informales de arquitectura basadas en una coleccin de componentes computacionales, junto a una coleccin de conectores que describen las interacciones entre los componentes. Consideran que esta es una descripcin deliberadamente abstracta, que ignora aspectos importantes de una estructura arquitectnica,

tales como una descomposicin jerrquica, la asignacin de computacin a los procesadores, la coordinacin global y el plan de tareas. En esta concepcin, los estilos califican como una macro-arquitectura, en tanto que los patrones de diseo (como por ejemplo el MVC) seran ms bien micro-arquitecturas.

En 1999 Mark Klein y Rick Kazman proponen una definicin segn la cual un estilo arquitectnico es una descripcin del patrn de los datos y la interaccin de control entre los componentes, ligada a una descripcin informal de los beneficios e inconvenientes aparejados por el uso del estilo. Los estilos arquitectnicos, afirman, son artefactos de ingeniera importantes porque definen clases de diseo junto con las propiedades conocidas asociadas a ellos. Ofrecen evidencia basada en la experiencia sobre la forma en que se ha utilizado histricamente cada clase, junto con razonamiento cualitativo para explicar por qu cada clase tiene esas propiedades especficas [KK99]. Los datos, relegados u omitidos por Perry y Wolf, aparecen nuevamente, dando la impresin que el campo general de los estilistas se divide entre una minora que los considera esenciales y una mayora que no [FT02]. Con el tiempo, casi nadie propone nuevas definiciones de estilo, sino que comienzan a repetirse las definiciones consagradas. Llegado el siglo XXI, Roy Thomas Fielding [Fie00] sintetiza la definicin de estilo pleonsticamente, diciendo que un estilo arquitectnico es un conjunto coordinado de restricciones arquitectnicas que restringe los roles/rasgos de los elementos arquitectnicos y las relaciones permitidas entre esos elementos dentro de la arquitectura que se conforma a ese estilo. Mientras que existen innumerables definiciones alternativas de arquitectura de software o de Web service, las definiciones de estilo ostentan muchos menos grados de libertad.

Ms all de las idiosincracias de expresin, con las definiciones vertidas hasta este punto queda claro que los estilos son entidades que ocurren en un nivel sumamente abstracto, puramente arquitectnico, que no coincide ni con la fase de anlisis propuesta por la temprana metodologa de modelado orientada a objetos (aunque s un poco con la de diseo), ni con lo que ms tarde se definiran como paradigmas de arquitectura, ni con los patrones arquitectnicos. Propongo analizar estas tres discordancias una por una: 1. El anlisis de la metodologa de objetos, tal como se enuncia en [RBP+91] est muy cerca del requerimiento y la percepcin de un usuario o cliente tcnicamente agnstico, un protagonista que en el terreno de los estilos no juega ningn papel. En arquitectura de software, los estilos surgen de la experiencia que el arquitecto posee; de ningn modo vienen impuestos de manera explcita en lo que el cliente le pide. 2. Los paradigmas como la arquitectura orientada a objetos (p.ej. CORBA), a componentes (COM, JavaBeans, EJB, CORBA Component Model) o a servicios, tal como se los define en [WF04], se relacionan con tecnologas particulares de implementacin, un elemento de juicio que en el campo de los estilos se trata a un nivel ms genrico y distante, si es que se llega a tratar alguna vez. Dependiendo de la clasificacin que se trate, estos paradigmas tipifican ms bien como sub-estilos de estilos ms englobantes (peer-to-peer, distribuidos, etc) o encarnan la forma de implementacin de otros estilos cualesquiera. 3. Los patrones arquitectnicos, por su parte, se han materializado con referencia a lenguajes y paradigmas tambin especficos de desarrollo, mientras que ningn estilo presupone o establece preceptivas al respecto. Si hay algn cdigo en las inmediaciones de un estilo, ser cdigo del

lenguaje de descripcin arquitectnica o del lenguaje de modelado; de ninguna manera ser cdigo de lenguaje de programacin. Lo mismo en cuanto a las representaciones visuales: los estilos se describen mediante simples cajas y lneas, mientras que los patrones suelen representarse en UML [Lar03].

En las definiciones consideradas, y a pesar de algunas excepciones, como las enumeraciones de Taylor y Medvidovic [TMA+95] o Mehta y Medvidovic [MM04], se percibe una unanimidad que no suele encontrarse con frecuencia en otros territorios de la arquitectura de software. La idea de estilo arquitectnico ha sido, en rigor, uno de los conceptos mejor consensuados de toda la profesin, quiz por el hecho de ser tambin uno de los ms simples. Pero aunque posee un ncleo invariante, las discrepancias comienzan a manifestarse cuando se trata (a) de enumerar todos los estilos existentes y (b) de suministrar la articulacin matricial de lo que (pensndolo bien) constituye, a nivel arquitectnico, una ambiciosa clasificacin de todos los tipos de aplicaciones posibles. Predeciblemente, la disyuntiva (b) demostrar ser ms aguda y rebelde que el dilema (a), porque, como lo estableci Georg Cantor, hay ms clases de cosas que cosas, an cuando las cosas sean infinitas. A la larga, las enumeraciones de estilos de grano ms fino que se publicaron histricamente contienen todos los ejemplares de las colecciones de grano ms grueso, pero nadie orden el mundo dos veces de la misma manera.

Para dar un ejemplo que se sita en el lmite del escndalo, el estilo cliente-servidor ha sido clasificado ya sea como variante del estilo basado en datos [Shaw94], como estilo de flujo de datos [And91] [SC96], como arquitectura distribuida [GS94], como estilo jerrquico [Fie00], como miembro del estilo de mquinas virtuales [variante de BCK98], como estilo orientado a objetos [Richard Upchurch], como estilo de llamaday-retorno [BCK98] o como estilo independiente [TMA+95]. Mientras las clasificaciones jerrquicas ms complejas incluyen como mucho seis clases bsicas de estilos, la comunidad de los arquitectos se las ha ingeniado para que un ejemplar pertenezca alternativamente a ocho. Los grandes frameworks que despus revisaremos (TOGAF, RM-ODP, 4+1, IEEE) homologan los estilos como concepto, pero ninguno se atreve a brindar una taxonoma exhaustiva de referencia. Hay, entonces, ms clasificaciones divergentes de estilos que estilos de arquitectura, cosa notable para nmeros tan pequeos, pero susceptible de esperarse en razn de la diversidad de puntos de vista.

Arriba

Catlogos de estilos

Aqu se considerarn solamente las enumeraciones primarias de la literatura temprana, lo que podramos llamar taxonomas de primer orden. Una vez que se hayan descripto los estilos individuales en la seccin siguiente, se dedicar otro apartado para examinar de qu forma determinadas percepciones ligadas a

dominios derivaron en otras articulaciones como las que han propuesto Roy Fielding [Fie00] y Gregory Andrews [And91]. Cuntos y cules son los estilos, entonces? En un estudio comparativo de los estilos, Mary Shaw [Shaw94] considera los siguientes, mezclando referencias a las mismas entidades a veces en trminos de arquitecturas, otras invocando modelos de diseo: 1. Arquitecturas orientadas a objeto 2. Arquitecturas basadas en estados 3. Arquitecturas de flujo de datos: Arquitecturas de control de realimentacin 4. Arquitecturas de tiempo real 5. Modelo de diseo de descomposicin funcional 6. Modelo de diseo orientado por eventos 7. Modelo de diseo de control de procesos 8. Modelo de diseo de tabla de decisin 9. Modelo de diseo de estructura de datos

El mismo ao, Mary Shaw, junto con David Garlan [GS94], propone una taxonoma diferente, en la que se entremezclan lo que antes llamaba arquitecturas con los modelos de diseo: 1. Tubera-filtros 2. Organizacin de abstraccin de datos y orientacin a objetos 3. Invocacin implcita, basada en eventos 4. Sistemas en capas 5. Repositorios 6. Intrpretes orientados por tablas 7. Procesos distribuidos, ya sea en funcin de la topologa (anillo, estrella, etc) o de los protocolos entre procesos (p. ej. algoritmo de pulsacin o heartbeat). Una forma particular de proceso distribuido es, por ejemplo, la arquitectura cliente-servidor. 8. Organizaciones programa principal / subrutina. 9. Arquitecturas de software especficas de dominio 10. 11. 12. Sistemas de transicin de estado Sistemas de procesos de control Estilos heterogneos

De particular inters es el catlogo de patrones arquitectnicos, que es como el influyente grupo de Buschmann denomina a entidades que, con un empaquetado un poco distinto, no son otra cosa que los estilos. Efectivamente, esos patrones expresan esquemas de organizacin estructural fundamentales para los sistemas de software. Proporcionan un conjunto de subsistemas predefinidos, especifican sus

responsabilidades e incluyen guas y lineamientos para organizar las relaciones entre ellos. En la hoy familiar clasificacin de POSA [BMR+96] Buschmann, Meunier, Rohnert, Sommerlad y Stal enumeran estos patrones:

1. Del fango a la estructura

- Capas - Tubera-filtros - Pizarra

2. Sistemas distribuidos

- Broker (p. ej. CORBA, DCOM, la World Wide Web)

3. Sistemas interactivos

- Model-View-Controller - Presentation-Abstraction-Control

4. Sistemas adaptables

- Reflection (metanivel que hace al software consciente de s mismo) - Microkernel (ncleo de funcionalidad mnima)

En Software Architecture in Practice, un texto fundamental de Bass, Clements y Kazman [BCK98] se proporciona una sistematizacin de clases de estilo en cinco grupos:

1. Flujo de datos (movimiento de datos, sin control del receptor de lo que viene corriente arriba)

- Proceso secuencial por lotes - Red de flujo de datos - Tubera-filtros

2. Llamado y retorno (estilo dominado por orden de computacin, usualmente con un solo thread de control)

- Programa principal / Subrutinas - Tipos de dato abstracto - Objetos - Cliente-servidor basado en llamadas - Sistemas en capas

3. Componentes independientes (dominado por patrones de comunicacin entre procesos independientes, casi siempre concurrentes)

- Sistemas orientados por eventos - Procesos de comunicacin

4. Centrados en datos (dominado por un almacenamiento central complejo, manipulado por computaciones independientes)

- Repositorio - Pizarra

5. Mquina virtual (caracterizado por la traduccin de una instruccin en alguna otra)

- Intrprete

Es interesante el hecho que se proporcionen slo cinco clases abarcativas; no he tenido oportunidad de examinar si todos los estilos propuestos encajan en ellas, lo que las clasificaciones posteriores parecen desmentir. Mientras que en los inicios de la arquitectura de software se alentaba la idea de que todas las estructuras posibles en diseo de software seran susceptibles de reducirse a una media docena de estilos bsicos, lo que en realidad sucedi fue que en los comienzos del siglo XXI se alcanza una fase barroca y las enumeraciones de estilos se tornan ms y ms detalladas y exhaustivas. Considerando solamente los estilos que contemplan alguna forma de distribucin o topologa de red, Roy Fielding [Fie00] establece la siguiente taxonoma:

1. Estilos de flujo de datos

1.1. Tubera-filtros 1.2. Tubera-filtros uniforme

2. Estilos de replicacin

2.1. Repositorio replicado 2.2. Cache

3. Estilos jerrquicos

3.1. Cliente-servidor 3.2. Sistemas en capas y Cliente-servidor en capas 3.3. Cliente-Servidor sin estado

3.4. Cliente-servidor con cache en cliente 3.5. Cliente-servidor con cache en cliente y servidor sin estado 3.6. Sesin remota 3.7. Acceso a datos remoto

4. Estilos de cdigo mvil

4.1. Mquina virtual 4.2. Evaluacin remota 4.3. Cdigo a demanda 4.4. Cdigo a demanda en capas 4.5. Agente mvil

5. Estilos peer-to-peer

5.1. Integracin basada en eventos 5.2. C2 5.3. Objetos distribuidos 5.4. Objetos distribuidos brokered

6. Transferencia de estado representacional (REST)

Cuando las clasificaciones de estilos se tornan copiosas, dara la impresin que algunos sub-estilos se introducen en el cuadro por ser combinatoriamente posibles, y no tanto porque existan importantes implementaciones de referencia, o porque sea tcnicamente necesario. En un proyecto que se ha desarrollado en China hacia el ao 2001, he podido encontrar una clasificacin que si bien no pretende ser totalizadora, agrupa los estilos de manera peculiar, agregando una clase no prevista por Bass, Clements y Kazman [BCK98], llamando a las restantes de la misma manera, pero practicando enroques posicionales de algunos ejemplares:

1. Sistemas de flujo de datos, incluyendo

- Secuencial por lotes - Tubera y filtro

2. Sistemas de invocacin y retorno (call-and-return), incluyendo

- Programa principal y sub-rutina - Sistemas orientados a objeto - Niveles jerrquicos

3. Componentes independientes, incluyendo

- Procesos comunicantes - Sistemas basados en eventos

4. Mquinas virtuales, incluyendo

- Intrpretes - Sistemas basados en reglas - Cliente-servidor

5. Sistemas centrados en datos, incluyendo

- Bases de datos - Sistemas de hipertexto - Pizarras

6. Paradigmas de procesos de control

En un documento annimo compilado por Richard Upchurch, del Departmento de Ciencias de la Computacin y Informacin de la Universidad de Massachusetts en Dartmouth se proporciona una lista de posibles estilos arquitectnicos, incluyendo: 1. Programa principal y subrutinas 2. Estilos jerrquicos 3. Orientado a objetos (cliente-servidor) 4. Procesos de comunicacin 5. Tubera y filtros 6. Intrpretes 7. Sistemas de bases de datos transaccionales 8. Sistemas de pizarra 9. Software bus 10. 11. 12. Sistemas expertos Paso de mensajes Amo-esclavo

13. 14. 15. 16. 17.

Asincrnico / sincrnico paralelo Sistemas de tiempo real Arquitecturas especficas de dominio Sistemas en red, distribuidos Arquitecturas heterogneas

Esta lista de lavandera puede que denote la transicin hacia las listas enciclopdicas, que por lo comn suelen ser poco cuidadosas en cuanto a mantener en claro los criterios de articulacin de la taxonoma. En 2001, David Garlan [Gar01], uno de los fundadores del campo, proporciona una lista ms articulada:

1. Flujo de datos

- Secuencial en lotes - Red de flujo de datos (tuberas y filtros) - Bucle de control cerrado

2. Llamada y Retorno

- Programa principal / subrutinas - Ocultamiento de informacin (ADT, objeto, cliente/servidor elemental)

3. Procesos interactivos

- Procesos comunicantes - Sistemas de eventos (invocacin implcita, eventos puros)

4. Repositorio Orientado a Datos

- Bases de datos transaccionales (cliente/servidor genuino) - Pizarra - Compilador moderno

5. Datos Compartidos

- Documentos compuestos - Hipertexto - Fortran COMMON - Procesos LW

6. Jerrquicos

- En capas (intrpretes)

Tambin seala los inconvenientes de la vida real que embarran el terreno de las taxonomas: los estilos casi siempre se usan combinados; cada capa o componente puede ser internamente de un estilo diferente al de la totalidad; muchos estilos se encuentran ligados a dominios especficos, o a lneas de producto particulares.

Cada tanto se encuentran tambin presentaciones relativas a estilos arquitectnicos que no coinciden con los usos mayoritariamente aceptados del concepto. Un ejemplo sera el artculo de Taylor, Medvidovic y otros en que se formul la presentacin pblica de Chiron-2 [TMA+95]. Una vez ms, sin intencin de elaborar un catlogo exhaustivo, los autores identifican estilos tales como tubera-filtro, arquitecturas de pizarra (propias de la Inteligencia Artificial), el estilo cliente-servidor, el modelo de callback (que opera bajo control de la interfaz de usuario), el modelo-vista-controlador (explotado comnmente en aplicaciones de Smalltalk), el estilo Arch y su meta-modelo asociado, y el estilo C2. Otra taxonoma excntrica se postula en [MMP00], donde se enumeran algunos estilos motivados por conectores de software como tubera-filtro, alimentacin de datos en tiempo real, arquitectura definida por eventos, estilo basado en mensajes y estilo de flujo de datos.

En los ltimos cuatro o cinco aos se han realizado esfuerzos para definir los estilos de una manera ms formal, empleando ADLs como Aesop o Wright, o notaciones en lenguajes de especificacin como Z o lenguajes con semntica formal como CHAM. Le Metayer [LeM98], por ejemplo, propone formalizar los estilos y otros conceptos anlogos en trminos de gramtica de grafos, enfatizando la geometra de las arquitecturas como un objeto independiente. Bernardo, Ciancarini y Donatiello han formalizado los tipos arquitectnicos empleando lgebra de procesos [BCD02]. En nuestro estudio de los lenguajes de descripcin de arquitectura (ADLs) hemos referido algunos lenguajes capaces de especificar estilos, implcita o explcitamente, ejemplificando la definicin de uno de ellos en la mayora de los ADLs disponibles y en alguno que otro lenguaje formal de especificacin.

Arriba

Descripcin de los estilos

Los estilos que habrn de describirse a continuacin no aspiran a ser todos los que se han propuesto, sino apenas los ms representativos y vigentes. De ms est decir que, como se ha visto, la agrupacin de estilos y sub-estilos es susceptible de realizarse de mltiples formas, conforme a los criterios que se apliquen

en la constitucin de los ejemplares. No se ha de rendir cuentas aqu por la congruencia de la clasificacin (nadie ha hecho lo propio con las suyas), porque cada vez que se la ha revisado en modo outline, se cedi a la tentacin de cambiar su estructura, la cual seguir sufriendo metamorfosis despus de despachado el artculo. Se podr apreciar que, en consonancia con los usos de la especialidad, la caracterizacin de los estilos no constituye un reflejo pormenorizado de los detalles de sus estructuras, sino una visin deliberadamente sucinta y genrica que destaca sus valores esenciales y sus rasgos distintivos. Entre acumular pormenores que podran recabarse en otras fuentes y mantener el caudal descriptivo de cada estilo en una magnitud que facilite su comparacin rpida con los dems se ha escogido, saussureanamente, lo segundo.

En cuanto a las formas de representacin esquemtica, se ha optado por reproducir el estilo grfico caracterstico de la literatura principal del gnero, el cual es deliberadamente informal y minimalista, en lugar de aplicar una notacin formal o ms elaborada. La notacin se establecer entonces en trminos de lo que Shaw y Clements llaman boxology [SC96]. Huelga decir que la descripcin de los estilos puede hacerse tambin en trminos de lenguajes descriptivos de arquitectura (ADLs) y las respectivas notaciones de las herramientas que se asocian con ellos, segn puede verse en un estudio separado [Rey04b]. Resta anticipar que algunas especies de software conspicuas en la prctica no aparecen en los catlogos usuales de estilo. La ausencia ms notoria concierne a los sistemas de workflow, que seguramente heredan el prejuicio ancestral de los ingenieros y arquitectos ms refinados en contra de los diagramas de flujo y las abstracciones procesuales. Fred Brooks, por ejemplo, considera el diagrama de flujo como una abstraccin muy pobre de la estructura de un sistema [Bro75] [Bro86].

Arriba

Estilos de Flujo de Datos

Esta familia de estilos enfatiza la reutilizacin y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos. Ejemplares de la misma seran las arquitecturas de tubera-filtros y las de proceso secuencial en lote.

Arriba

Tubera y filtros

Siempre se encuadra este estilo dentro de las llamadas arquitecturas de flujo de datos. Es sin duda alguna el estilo que se defini ms temprano [AG92] y el que puede identificarse topolgica, procesual y taxonmicamente con menor ambigedad. Histricamente el se relaciona con las redes de proceso descriptas por Kahn hacia 1974 y con el proceso secuenciales comunicantes (CSP) ideados por Tony Hoare cuatro aos ms tarde. Ha prevalecido el nombre de tubera-filtros por ms que se sabe muy bien que los llamados filtros no realizan forzosamente tareas de filtrado, como ser eliminacin de campos o registros, sino que ejecutan formas variables de transformacin, una de las cuales puede ser el filtrado. En uno de los trabajos recientes ms completos sobre este estilo, Ernst-Erich Doberkat [Dob03] lo define en estos trminos.

Una tubera (pipeline) es una popular arquitectura que conecta componentes computacionales (filtros) a travs de conectores (pipes), de modo que las computaciones se ejecutan a la manera de un flujo. Los datos se transportan a travs de las tuberas entre los filtros, transformando gradualmente las entradas en salidas. [] Debido a su simplicidad y su facilidad para captar una funcionalidad, es una arquitectura mascota cada vez que se trata de demostrar ideas sobre la formalizacin del espacio de diseo arquitectnico, igual que el tipo de datos stack lo fue en las especificaciones algebraicas o en los tipos de datos abstractos.

El sistema tubera-filtros se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada. Los datos entran al sistema y fluyen a travs de los componentes. En el estilo secuencial por lotes (batch sequential) los componentes son programas independientes; el supuesto es que cada paso se ejecuta hasta completarse antes que se inicie el paso siguiente. Garlan y Shaw sostienen que la variante por lotes es un caso degenerado del estilo, en el cual las tuberas se han vuelto residuales [SG94].

Fig. 1 - Compilador en tubera-filtro

La aplicacin tpica del estilo es un procesamiento clsico de datos: el cliente hace un requerimiento; el requerimiento se valida; un Web Service toma el objeto de la base de datos; se lo convierte a HTML; se efecta la representacin en pantalla. El estilo tubera-filtros propiamente dicho enfatiza la transformacin incremental de los datos por sucesivos componentes. El caso tpico es la familia UNIX de Sistemas operativos, pero hay otros ejemplos como la secuencia de procesos de los compiladores (sobre todo los ms antiguos), el tratamiento de documentos XML como rfaga en SAX, ciertos mecanismos de determinados motores de servidores de bases de datos, algunos procesos de workflow y subconjuntos de piezas encadenadas en productos tales como Microsoft Commerce Server. Puede verse, por ejemplo, una fina caracterizacin de conceptos de programacin relativos al estilo de lnea de tubera en la documentacin del

Software Development Kit de ese producto (http://msdn.microsoft.com/library/enus/comsrv2k/htm/cs_sp_pipelineobj_woce.asp). Aunque la lnea de tuberas no se define all como estilo, se la describe como un framework de software extensible que establece y vincula una o ms etapas de un proceso de negocios, ejecutndolas en secuencia hasta completar una tarea determinada. Por ejemplo, el Order Processing Pipeline proporciona la secuencia de pasos necesaria para procesar las compras en un sitio de Web. En la primera etapa, se obtiene la informacin del producto de la base de datos de catlogo; en la siguiente, se procesa la direccin del comprador; otra etapa resuelve la modalidad de pago; una etapa ulterior confecciona la factura y otra ms realiza el envo del pedido. Cada etapa de la tarea representa una categora de trabajo.

En la estrategia de arquitectura de Microsoft, que se encuentra mayormente orientada a servicios, el modelo tubera-filtros tiene sin embargo su lugar de referencia. No est caracterizado literalmente como estilo, por cierto, pero figura en la documentacin de patrones y prcticas como uno de los patrones ms comnmente usados para los componentes de negocios, junto con los patrones de eventos y los de workflow [MS02a:4550]. La presentacin de las caractersticas del estilo en esta literatura coincide puntualmente con las ideas dominantes en el campo de los estilos arquitectnicos, lo mismo que las recomendaciones prcticas para su uso [GAO94] [Gar95] [MKM+97] [SC96] [Shaw94]. La documentacin establece, en efecto, que el estilo se debe usar cuando:

Se puede especificar la secuencia de un nmero conocido de pasos. No se requiere esperar la respuesta asincrnica de cada paso. Se busca que todos los componentes situados corriente abajo sean capaces de inspeccionar y

actuar sobre los datos que vienen de corriente arriba (pero no viceversa).

Igualmente, se reconocen como ventajas del estilo tubera-filtros:

Es simple de entender e implementar. Es posible implementar procesos complejos con editores

grficos de lneas de tuberas o con comandos de lnea.

Fuerza un procesamiento secuencial. Es fcil de envolver (wrap) en una transaccin atmica. Los filtros se pueden empaquetar, y hacer paralelos o distribuidos.

Aunque Garlan y Shaw sealan que el estilo tiene una pltora de devotos seguidores religiosos que afirman que es til en cualquier contexto [SG94], hace tiempo que se conocen sus desventajas:

El patrn puede resultar demasiado simplista, especialmente para orquestacin de servicios que

podran ramificar la ejecucin de la lgica de negocios de formas complicadas.

No maneja con demasiada eficiencia construcciones condicionales, bucles y otras lgicas de control

de flujo. Agregar un paso suplementario afecta la performance de cada ejecucin de la tubera.

Una desventaja adicional referida en la literatura sobre estilos concierne a que eventualmente

pueden llegar a requerirse buffers de tamao indefinido, por ejemplo en las tuberas de clasificacin de datos.

El estilo no es apto para manejar situaciones interactivas, sobre todo cuando se requieren

actualizaciones incrementales de la representacin en pantalla.

La independencia de los filtros implica que es muy posible la duplicacin de funciones de

preparacin que son efectuadas por otros filtros (por ejemplo, el control de correccin de un objeto de fecha).

Histricamente, los primeros compiladores operaban conforme a un estilo de tubera y filtro bastante puro, en ocasiones en variantes de proceso por lotes. A medida que los compiladores se tornaron ms sofisticados, se fueron aadiendo elementos tales como tablas de smbolos, generalmente compartidas por varios filtros. El aadido de formas intermedias de representacin, gramticas de atributo, rboles de parsing de atributos, compilaciones convergentes a formatos intermedios (como los compiladores que generan formato de lenguaje intermedio MSIL en el .NET Framework a partir de distintos lenguajes fuentes) y otras complicaciones y aadiduras, fueron haciendo que el modelo de tubo secuencial llegara a ser inadecuado para representar estos procesos, siendo preferible optar por otros estilos, como el de repositorio.

En nuestro documento sobre los lenguajes de descripcin arquitectnicos (ADLs), hemos ejemplificado el estilo utilizando el lenguaje de especificacin CHAM, aplicado al encadenamiento de pasos del compilador de Lisp que viene incluido como ejemplo en el Software Development Kit de Microsoft .NET Framework. Roy Fielding considera a tubera-filtros como una de las variantes del estilo ms genrico de flujo de datos. La otra variante sera tubera y filtro uniforme. En ella se agrega la restriccin de que todos los filtros deben poseer la misma interfaz. El ejemplo primario se encuentra en el sistema operativo Unix, donde los procesos de filtro tienen un flujo de entrada de caracteres (stdin) y dos flujos de salida (stdout y stderr) [Fie00]. La literatura de estilos y la de patrones arquitectnicos y de diseo abunda en variaciones del modelo bsico: lneas de tuberas, esquemas de apertura en abanico, tuberas acclicas. En la documentacin de Microsoft se ha dado tratamiento explcito a patrones tales como el filtro de intercepcin (intercepting filter) y las cadenas de filtros componibles [MS04b] que vendran a ser derivaciones concretas del estilo abstracto en las vistas ligadas al desarrollo de una solucin.

Arriba

Estilos Centrados en Datos

Esta familia de estilos enfatiza la integrabilidad de los datos. Se estima apropiada para sistemas que se fundan en acceso y actualizacin de datos en estructuras de almacenamiento. Sub-estilos caractersticos de la familia seran los repositorios, las bases de datos, las arquitecturas basadas en hipertextos y las arquitecturas de pizarra.

Arquitecturas de Pizarra o Repositorio

En esta arquitectura hay dos componentes principales: una estructura de datos que representa el estado actual y una coleccin de componentes independientes que operan sobre l [SG96]. En base a esta distincin se han definidos dos subcategoras principales del estilo: 1. Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, el repositorio puede ser una base de datos tradicional (implcitamente no cliente-servidor). 2. Si el estado actual de la estructura de datos dispara los procesos a ejecutar, el repositorio es lo que se llama una pizarra pura o un tablero de control.

Fig. 2 - Pizarra [basado en GS94]

Estos sistemas se han usado en aplicaciones que requieren complejas interpretaciones de proceso de seales (reconocimiento de patrones, reconocimiento de habla, etc), o en sistemas que involucran acceso compartido a datos con agentes dbilmente acoplados. Tambin se han implementado estilos de este tipo en procesos en lotes de base de datos y ambientes de programacin organizados como colecciones de

herramientas en torno a un repositorio comn. Muchos ms sistemas de los que se cree estn organizados como repositorios: bibliotecas de componentes reutilizables, grandes bases de datos y motores de bsqueda. Algunas arquitecturas de compiladores que suelen presentarse como representativas del estilo tuberafiltros, se podran representar mejor como propias del estilo de pizarra, dado que muchos compiladores contemporneos operan en base a informacin compartida tal como tablas de smbolos, rboles sintcticos abstractos (AST), etctera. As como los estilos lineales de tubera-filtros suelen evolucionar hacia (o ser comprendidos mejor como) estilos de pizarra o repositorio, stos suelen hacer morphing a estilos de mquinas virtuales o intrpretes [GS94].

El documento clsico que describe el estilo, Blackboard Systems, de H. Penny Nii [Nii86], bien conocido en Inteligencia Artificial, es en rigor anterior en seis aos al surgimiento de la idea de estilos en arquitectura de software. Los estilos de pizarra no son slo una curiosidad histrica; por el contrario, se los utiliza en exploraciones recientes de inteligencia artificial distribuida o cooperativa, en robtica, en modelos multiagentes, en programacin evolutiva, en gramticas complejas, en modelos de crecimiento afines a los LSystems de Lindenmayer, etc. Un sistema de pizarra se implementa para resolver problemas en los cuales las entidades individuales se manifiestan incapaces de aproximarse a una solucin, o para los que no existe una solucin analtica, o para los que s existe pero es inviable por la dimensin del espacio de bsqueda. Todo modelo de este tipo consiste en las siguientes tres partes:

- Fuentes de conocimiento, necesarias para resolver el problema. - Una pizarra que representa el estado actual de la resolucin del problema. - Una estrategia, que regula el orden en que operan las fuentes.

Al comienzo del proceso de resolucin, se establece el problema en la pizarra. Las fuentes tratan de resolverlo cambiando el estado. La nica forma en que se comunican entre s es a travs de la pizarra. Finalmente, si de la cooperacin resulta una solucin adecuada, sta aparece en la pizarra como paso final.

En un desarrollo colateral, la relacin entre este modelo de resolucin de problemas y los lenguajes formales fue establecida hacia 1989 por los hngaros E. Csuhaj-Varj y J. Kelemen. En su esquema, las fuentes de conocimiento corresponden a gramticas, el cambio del estado de la pizarra a la re-escritura de formas secuenciales, y la estrategia es representada por modelos de derivacin de modo que la solucin corresponda a una frase terminal. Estas correspondencias han sido estudiadas primariamente en modelos de programacin evolutiva, modelos ecolgicos, ecogramticas, sistemas emergentes, caos determinista, algoritmos genticos y vida artificial, y en el desarrollo de meta-heursticas del tipo de la simulacin de templado o la bsqueda tab, temas todos que son demasiado especializados para tratar detalladamente en este contexto [Rey04a]. ltimamente se est hablando mucho de agentes distribuidos, pero ms en el

sentido de entidades distribuidas en los cnones de la programacin orientada a objetos, que en el de los sistemas complejos y emergentes.

A mi juicio, el estilo de pizarra tiene pleno sentido si tanto los agentes (o las fuentes de conocimiento) como la pizarra se entienden en trminos virtuales y genricos, como clases que son susceptibles de instanciarse en diversas variedades de objetos computacionales. De ser as, se podra incluir en este estilo un inmenso repertorio de aplicaciones de optimizacin y bsqueda en programacin gentica y evolutiva que de otro modo no encontrara un estilo en el cual encuadrarse. En un programa gentico, efectivamente, una poblacin (que vendra a ser homloga a la fuente) evoluciona produciendo soluciones que se contrastan contra un criterio de adecuacin (que sera la pizarra). La estrategia sera aqu el algoritmo gentico propiamente dicho (mutaciones, crossover, reproduccin, evaluacin de fitness, seleccin de los ms aptos, repeticin del ciclo). Considero que todas las arquitecturas basadas en elementos autnomos pero globalmente orientadas a una meta de convergencia hacia valores u objetivos (como las redes neuronales, los modelos evolutivos y memticos, los autmatas celulares y las redes booleanas aleatorias) son susceptibles de encuadrarse en la misma variedad estilstica.

La estrategia de arquitectura de Microsoft no hace demasiado hincapi en el estilo de pizarra y las referencias a repositorios son ms bien convencionales o implcitas; tampoco lo hacen las estrategias mayores alternativas de la industria. Pero es de esperarse que el florecimiento de las arquitecturas basadas en agentes inteligentes o autnomos resulte, ms temprano que tarde, en un redescubrimiento de este estilo, hasta ahora marginal, raro, heterodoxo y desganadamente descriptos por los arquitectos.

Arriba

Estilos de Llamada y Retorno

Esta familia de estilos enfatiza la modificabilidad y la escalabilidad. Son los estilos ms generalizados en sistemas en gran escala. Miembros de la familia son las arquitecturas de programa principal y subrutina, los sistemas basados en llamadas a procedimientos remotos, los sistemas orientados a objeto y los sistemas jerrquicos en capas.

Arriba

Model-View-Controller (MVC)

Reconocido como estilo arquitectnico por Taylor y Medvidovic [TMA+95], muy rara vez mencionado en los surveys estilsticos usuales, considerado una micro-arquitectura por Robert Allen y David Garlan [AG97], el MVC ha sido propio de las aplicaciones en Smalltalk por lo menos desde 1992, antes que se generalizaran las arquitecturas en capas mltiples. En ocasiones se lo define ms bien como un patrn de diseo o como prctica recurrente, y en estos trminos es referido en el marco de la estrategia arquitectnica de Microsoft. En la documentacin correspondiente es tratado a veces en trminos de un estilo decididamente abstracto [MS03a] y otras como patrn de aplicacin ligado a una implementacin especfica en Visual C++ o en ASP.NET [MS03b]. Buschmann y otros lo consideran un patrn correspondiente al estilo de los sistemas interactivos [BMR+96].

Un propsito comn en numerosos sistemas es el de tomar datos de un almacenamiento y mostrarlos al usuario. Luego que el usuario introduce modificaciones, las mismas se reflejan en el almacenamiento. Dado que el flujo de informacin ocurre entre el almacenamiento y la interfaz, una tentacin comn, un impulso espontneo (hoy se llamara un anti-patrn) es unir ambas piezas para reducir la cantidad de cdigo y optimizar la performance. Sin embargo, esta idea es antagnica al hecho de que la interfaz suele cambiar, o acostumbra depender de distintas clases de dispositivos (clientes ricos, browsers, PDAs); la programacin de interfaces de HTML, adems, requiere habilidades muy distintas de la programacin de lgica de negocios. Otro problema es que las aplicaciones tienden a incorporar lgica de negocios que van ms all de la transmisin de datos.

Fig. 3 - Model-View-Controller [segn MS03a]

El patrn conocido como Modelo-Vista-Controlador (MVC) separa el modelado del dominio, la presentacin y las acciones basadas en datos ingresados por el usuario en tres clases diferentes [Bur92]:

- Modelo. El modelo administra el comportamiento y los datos del dominio de aplicacin, responde a requerimientos de informacin sobre su estado (usualmente formulados desde la vista) y responde a instrucciones de cambiar el estado (habitualmente desde el controlador). - Vista. Maneja la visualizacin de la informacin. - Controlador. Interpreta las acciones del ratn y el teclado, informando al modelo y/o a la vista para que cambien segn resulte apropiado.

Tanto la vista como el controlador dependen del modelo, el cual no depende de las otras clases. Esta separacin permite construir y probar el modelo independientemente de la representacin visual. La separacin entre vista y controlador puede ser secundaria en aplicaciones de clientes ricos y, de hecho, muchos frameworks de interfaz implementan ambos roles en un solo objeto. En aplicaciones de Web, por otra parte, la separacin entre la vista (el browser) y el controlador (los componentes del lado del servidor que manejan los requerimientos de HTTP) est mucho ms taxativamente definida. Entre las ventajas del estilo sealadas en la documentacin de Patterns & Practices de Microsoft estn las siguientes:

Soporte de vistas mltiples. Dado que la vista se halla separada del modelo y no hay dependencia

directa del modelo con respecto a la vista, la interfaz de usuario puede mostrar mltiples vistas de los mismos datos simultneamente. Por ejemplo, mltiples pginas de una aplicacin de Web pueden utilizar el mismo modelo de objetos, mostrado de maneras diferentes.

Adaptacin al cambio. Los requerimientos de interfaz de usuario tienden a cambiar con mayor

rapidez que las reglas de negocios. Los usuarios pueden preferir distintas opciones de representacin, o requerir soporte para nuevos dispositivos como telfonos celulares o PDAs. Dado que el modelo no depende de las vistas, agregar nuevas opciones de presentacin generalmente no afecta al modelo. Este patrn sent las bases para especializaciones ulteriores, tales como Page Controller y Front Controller.

Entre las desventajas, se han sealado:

Complejidad. El patrn introduce nuevos niveles de indireccin y por lo tanto aumenta ligeramente

la complejidad de la solucin. Tambin se profundiza la orientacin a eventos del cdigo de la interfaz de usuario, que puede llegar a ser difcil de depurar. En rigor, la configuracin basada en eventos de dicha interfaz corresponde a un estilo particular (arquitectura basada en eventos) que aqu se examina por separado.

Costo de actualizaciones frecuentes. Desacoplar el modelo de la vista no significa que los

desarrolladores del modelo puedan ignorar la naturaleza de las vistas.

Si el modelo experimenta cambios frecuentes, por ejemplo, podra desbordar las vistas con una lluvia de requerimientos de actualizacin. Hace pocos aos suceda que algunas vistas, tales como las pantallas grficas, involucraban ms tiempo para plasmar el dibujo que el que demandaban los nuevos requerimientos de actualizacin.

Este estilo o sub-estilo ha sido ampliamente tratado en la documentacin de arquitectura de Microsoft. Una

visin sistemtica del mismo, tratado como patrn de solucin, puede consultarse en http://msdn.microsoft.com/practices/type/Patterns/Enterprise/DesMVC/. Hay documentacin separada respecto de la implementacin del patrn en ASP.NET en http://msdn.microsoft.com/practices/type/Patterns/Enterprise/ImpMVCinASP/, y presentaciones en detalle de otros patrones asociados. Los Mobile Web Forms que forman parte del repertorio de interfaces de Visual Studio .NET apropiadas para las llamadas Mobile Web Applications, implementan (en conjuncin con las prestaciones adaptativas de ASP.NET) un ejemplo claro de un elegante modelo derivado de MVC.

Arriba

Arquitecturas en Capas

Los sistemas o arquitecturas en capas constituyen uno de los estilos que aparecen con mayor frecuencia mencionados como categoras mayores del catlogo, o, por el contrario, como una de las posibles encarnaciones de algn estilo ms envolvente. En [GS94] Garlan y Shaw definen el estilo en capas como una organizacin jerrquica tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior. Instrumentan as una vieja idea de organizacin estratigrfica que se remonta a las concepciones formuladas por el patriarca Edsger Dijkstra en la dcada de 1960, largamente explotada en los aos subsiguientes. En algunos ejemplares, las capas internas estn ocultas a todas las dems, menos para las capas externas adyacentes, y excepto para funciones puntuales de exportacin; en estos sistemas, los componentes implementan mquinas virtuales en alguna de las capas de la jerarqua. En otros sistemas, las capas pueden ser slo parcialmente opacas. En la prctica, las capas suelen ser entidades complejas, compuestas de varios paquetes o subsistemas. El uso de arquitecturas en capas, explcitas o implcitas, es frecuentsimo; solamente en Pattern Almanac 2000 [Ris00] hay cerca de cien patrones que son variantes del patrn bsico de capas. Patrones de uso comn relativos al estilo son Faade, Adapter, Bridge y Strategy [Gof95] [MS04c].

En un estilo en capas, los conectores se definen mediante los protocolos que determinan las formas de la interaccin. Los diagramas de sistemas clsicos en capas dibujaban las capas en adyacencia, sin conectores, flechas ni interfaces; en algunos casos se suele representar la naturaleza jerrquica del sistema en forma de crculos concntricos [GS94: 11]. Las restricciones topolgicas del estilo pueden incluir una limitacin, ms o menos rigurosa, que exige a cada capa operar slo con capas adyacentes, y a los elementos de una capa entenderse slo con otros elementos de la misma; se supone que si esta exigencia se relaja, el estilo deja de ser puro y pierde algo de su capacidad heurstica [MS04c]; tambin se pierde, naturalmente, la posibilidad de reemplazar de cuajo una capa sin afectar a las restantes, disminuye la flexibilidad del conjunto y se

complica su mantenimiento. Las formas ms rgidas no admiten ni siquiera pass-through: cada capa debe hacer algo, siempre. En la literatura especializada hay multitud de argumentos a favor y en contra del rigor de esta clase de prescripciones. A veces se argumenta que el cruce superfluo de muchos niveles involucra eventuales degradaciones de performance; pero muchas ms veces se sacrifica la pureza de la arquitectura en capas precisamente para mejorarla: colocando, por ejemplo, reglas de negocios en los procedimientos almacenados de las bases de datos, o articulando instrucciones de consulta en la capa de la interface del usuario.

Casos representativos de este estilo son muchos de los protocolos de comunicacin en capas. En ellos cada capa proporciona un sustrato para la comunicacin a algn nivel de abstraccin, y los niveles ms bajos suelen estar asociados con conexiones de hardware. El ejemplo ms caracterstico es el modelo OSI con los siete niveles que todo el mundo recuerda haber aprendido de memoria en la escuela: nivel fsico, vnculo de datos, red, transporte, sesin, presentacin y aplicacin. El estilo tambin se encuentra en forma ms o menos pura en arquitecturas de bases de datos y sistemas operativos, as como en las especificaciones relacionadas con XML. Don Box, Aaron Skonnard y John Lam, por ejemplo, suministran este mapa en capas de la tecnologa de XML [BSL00]. Abstracto Clases y objetos Especfico de aplicacin Abstracto Clases y objetos Tipos e instancias Elementos y atributos Entidades y documentos Archivos y paquetes Concreto Sectores y bitstreams Especfico de aplicacin XML Schemas (Metadata) XML 1.0 + Namespaces XML 1.0 Especfico de Sistema operativo o Protocolo Especfico del hardware

Elementos estructurales XML Information Set (InfoSet)

Tabla 1 - Capas de XML

Aunque un documento XML se percibe como un texto plano humanamente legible (tan plano que puede ser tratado como rfaga mediante Sax), su estructura involucra un conjunto complejo de especificaciones jerrquicas estratificadas: el proceso que trate con entidades como external identifier o processing instructions, no necesita armar caracteres de marcacin componiendo bits, ni implementar instrucciones primitivas de protocolo de red, ni lidiar con el proceso bsico de localizar un archivo en un directorio del disco.

La presencia del estilo en una tecnologa tan envolvente como hoy en da es XML, as como en otros enclaves tecnolgicos, induce a que subrayemos aqu su importancia. A nivel arquitectnico, se puede tratar con XML

en diversos planos de abstraccin. Si un proyecto determinado implementa de manera explcita operaciones de parsing o tokenizacin de XML crudo en una solucin de negocios, ello puede significar que se est operando a un nivel indebido de abstraccin, pues esas operaciones ya deberan estar resueltas a niveles inferiores ya sea por el sistema operativo, por bibliotecas de clases, por modelos de objeto, por interfaces o por entornos de programacin.

El nmero mnimo de capas es obviamente dos, y en ese umbral la literatura arquitectnica sita a veces al sub-estilo cliente-servidor como el modelo arquetpico del estilo de capas y el que se encuentra con mayor frecuencia en las aplicaciones en red. Este modelo particular dudosamente necesite descripcin, pero de todos modos aqu va: Un componente servidor, que ofrece ciertos servicios, escucha que algn otro componente requiera uno; un componente cliente solicita ese servicio al servidor a travs de un conector. El servidor ejecuta el requerimiento (o lo rechaza) y devuelve una respuesta.

La descripcin, que a fuerza de ser elemental pudo haber incomodado al lector arquitecto de software, subraya empero tres caractersticas no triviales: una, que cuando se habla de estilos todas las entidades unitarias son componentes, aunque no lo sean en trminos de COM o JavaBeans; dos, que en este contexto todas las relaciones asumen la forma de conectores, an cuando en la vida real la relacin de un cliente con un servidor pueda llegar a ser no-conectada; tres, que el plano de abstraccin del discurso estilstico es tal que nadie se acuerda de los drivers ni practica diferencias entre modelos alternativos de programacin. Que la relacin entre clientes y servidores sea continua o discontinua y que algunas de las partes guarden memoria de estado y cursores o dejen de hacerlo es secundario, aunque algunos autores sensibles a los matices han previsto sub-estilos distintos que corresponden a estos casos [Fie00]. Dada la popularidad de las tecnologas de bases de datos conformes a este modelo, la literatura sobre cliente-servidor ha llegado a ser inabarcable. La bibliografa sobre cliente-servidor en trminos de estilo arquitectnico, sin embargo, es comparativamente modesta.

Las ventajas del estilo en capas son obvias. Primero que nada, el estilo soporta un diseo basado en niveles de abstraccin crecientes, lo cual a su vez permite a los implementadores la particin de un problema complejo en una secuencia de pasos incrementales. En segundo lugar, el estilo admite muy naturalmente optimizaciones y refinamientos. En tercer lugar, proporciona amplia reutilizacin. Al igual que los tipos de datos abstractos, se pueden utilizar diferentes implementaciones o versiones de una misma capa en la medida que soporten las mismas interfaces de cara a las capas adyacentes. Esto conduce a la posibilidad de definir interfaces de capa estndar, a partir de las cuales se pueden construir extensiones o prestaciones especficas.

Fig. 4 - Arquitectura en 3 capas con cliente flaco en Windows DNA

Tambin se han sealado algunas desventajas de este estilo [GS96]. Muchos problemas no admiten un buen mapeo en una estructura jerrquica. Incluso cuando un sistema se puede establecer lgicamente en capas, consideraciones de performance pueden requerir acoplamientos especficos entre capas de alto y bajo nivel. A veces es tambin extremadamente difcil encontrar el nivel de abstraccin correcto; por ejemplo, la comunidad de comunicacin ha encontrado complejo mapear los protocolos existentes en el framework ISO, de modo que muchos protocolos agrupan diversas capas, ocasionando que en el mercado proliferen los drivers o los servicios monolticos. Adems, los cambios en las capas de bajo nivel tienden a filtrarse hacia las de alto nivel, en especial si se utiliza una modalidad relajada; tambin se admite que la arquitectura en capas ayuda a controlar y encapsular aplicaciones complejas, pero complica no siempre razonablemente las aplicaciones simples [MS04c].

En lo que se refiere a las arquitecturas caractersticas de Microsoft, el estilo en varias capas hizo su aparicin explcita con las estrategias de desarrollo que se conocieron como Windows DNA, que elocuentemente expresaron y otorgaron justificacin a lo que la recomendacin de la IEEE 1471 propone llamar separacin de incumbencias. En aquellos tiempos, adems, la prioridad esencial consista en discutir con la aristocracia cunto ms genricos, abstractos y simples eran los componentes en relacin con los objetos, o en convencer a la muchedumbre de que era mucho ms refinado programar con ellos que con funciones de APIs. En trminos estilsticos, sin embargo, los documentos de arquitectura de Microsoft, que en algn momento impulsaron con fuerza el diseo en capas como idea dominante (al lado del modelo de componentes), se ha inclinado en los ltimos aos hacia las arquitecturas basadas en servicios y el grueso de la industria apunta al mismo rumbo. La separacin y especializacin de interfaces de usuario, reglas de negocios y estructuras de datos (o sus equivalentes arquitectnicos en otros dominios), sin embargo,

conservan todava plena relevancia. La documentacin correspondiente ha elaborado numerosos patrones de arquitectura y diseo derivados de este estilo, como Layered Application [MS04c] y Three-layered Services Application [MS04d].

A pesar de la versatilidad de REST o de SOAP y de que el ruido ms fuerte viene de este lado, las arquitecturas en capas distan de ser un estilo fsil. La informacin sobre el estilo de componentes Windows DNA todava est all [Red99] y el modelo posee virtudes estilsticas de distribucin, preservacin de identidad, seguridad, performance, escalabilidad, sincronicidad, balanceo de carga, robustez y acidez transaccional que siguen siendo competitivas y que no se valoran hasta que uno se muda a un contexto que obliga a atenerse a un estilo que carece de ellas.

Arriba

Arquitecturas Orientadas a Objetos

Nombres alternativos para este estilo han sido Arquitecturas Basadas en Objetos, Abstraccin de Datos y Organizacin Orientada a Objectos. Los componentes de este estilo son los objetos, o ms bien instancias de los tipos de dato abstractos. En la caracterizacin clsica de David Garlan y Mary Shaw [GS94], los objetos representan una clase de componentes que ellos llaman managers, debido a que son responsables de preservar la integridad de su propia representacin. Un rasgo importante de este aspecto es que la representacin interna de un objeto no es accesible desde otros objetos. En la semblanza de estos autores curiosamente no se establece como cuestin definitoria el principio de herencia. Ellos piensan que, a pesar de que la relacin de herencia es un mecanismo organizador importante para definir los tipos de objeto en un sistema concreto, ella no posee una funcin arquitectnica directa. En particular, en dicha concepcin la relacin de herencia no puede concebirse como un conector, puesto que no define la interaccin entre los componentes de un sistema. Adems, en un escenario arquitectnico la herencia de propiedades no se restringe a los tipos de objeto, sino que puede incluir conectores e incluso estilos arquitectnicos enteros.

Si hubiera que resumir las caractersticas de las arquitecturas OO, se podra decir que:

Los componentes del estilo se basan en principios OO: encapsulamiento, herencia y polimorfismo.

Son asimismo las unidades de modelado, diseo e implementacin, y los objetos y sus interacciones son el centro de las incumbencias en el diseo de la arquitectura y en la estructura de la aplicacin.

Las interfaces estn separadas de las implementaciones. En general la distribucin de objetos es

transparente, y en el estado de arte de la tecnologa (lo mismo que para los componentes en el

sentido de CBSE) apenas importa si los objetos son locales o remotos. El mejor ejemplo de OO para sistemas distribuidos es Common Object Request Broker Architecture (CORBA), en la cual las interfaces se definen mediante Interface Description Language (IDL); un Object Request Broker media las interacciones entre objetos clientes y objetos servidores en ambientes distribuidos.

En cuanto a las restricciones, puede admitirse o no que una interfaz pueda ser implementada por

mltiples clases. En tanto componentes, los objetos interactan a travs de invocaciones de funciones y procedimientos. Hay muchas variantes del estilo; algunos sistemas, por ejemplo, admiten que los objetos sean tareas concurrentes; otros permiten que los objetos posean mltiples interfaces.

Se puede considerar el estilo como perteneciente a una familia arquitectnica ms amplia, que algunos autores llaman Arquitecturas de Llamada-y-Retorno (Call-and-Return). Desde este punto de vista, sumando las APIs clsicas, los componentes (en el sentido COM y JavaBeans) y los objetos, C-R ha sido el tipo dominante en los ltimos 20 aos.

En lo que se refiere a las ventajas y desventajas de esta arquitectura, enumerarlas solamente llevara ms espacio del que se dispone en este estudio, de modo que apenas sealar las ms obvias. Entre las cualidades, la ms bsica concierne a que se puede modificar la implementacin de un objeto sin afectar a sus clientes. Asimismo es posible descomponer problemas en colecciones de agentes en interaccin. Adems, por supuesto (y esa es la idea clave), un objeto es ante todo una entidad reutilizable en el entorno de desarrollo.

Entre las limitaciones, el principal problema del estilo se manifiesta en el hecho de que para poder interactuar con otro objeto a travs de una invocacin de procedimiento, se debe conocer su identidad. Esta situacin contrasta con lo que es el caso en estilos tubera-filtros, donde los filtros no necesitan poseer informacin sobre los otros filtros que constituyen el sistema. La consecuencia inmediata de esta caracterstica es que cuando se modifica un objeto (por ejemplo, se cambia el nombre de un mtodo, o el tipo de dato de algn argumento de invocacin) se deben modificar tambin todos los objetos que lo invocan. Tambin se presentan problemas de efectos colaterales en cascada: si A usa B y C tambin lo usa, el efecto de C sobre B puede afectar a A.

En la literatura sobre estilos, las arquitecturas orientadas a objeto han sido clasificadas de formas diferentes, conforme a los diferentes puntos de vista que alternativamente enfatizan la jerarqua de componentes, su distribucin topolgica o las variedades de conectores. En su famosa disertacin sobre REST, Roy Fielding subordina las arquitecturas de objetos distribuidos a los estilos peer-to-peer, al lado de la integracin basada

en eventos y el estilo C2 [Fie00]. Si se sita la idea de llamado y respuesta como organizadora del estilo, los sub-estilos seran:

- Programa principal y subrutinas. Es el paradigma clsico de programacin. El objetivo es descomponer un programa en pequeas piezas susceptibles de modificarse independientemente. - Estilo orientado a objetos o tipo de dato abstracto. Esta vendra a ser la versin moderna de las arquitecturas C-R. Esta variante enfatiza el vnculo entre datos y mtodos para manipular los datos, valindose de interfaces pblicas. La abstraccin de objetos forma componentes que proporcionan servicios de caja negra y componentes que requieren esos servicios. El encapsulamiento oculta los detalles de implementacin. El acceso al objeto se logra a travs de operaciones, tpicamente conocidas como mtodos, que son formas acotadas de invocacin de procedimientos. - Sistemas en capas. En este estilo los componentes se asignan a capas. Cada capa se comunica con sus vecinas inmediatas; a veces, sin embargo, razones no funcionales de practicidad, performance, escalabilidad o lo que fuere hace que se toleren excepciones a la regla. Hemos analizado este estilo por separado.

En los estudios arquitectnicos de estilos, y posiblemente por efecto de un nfasis que es ms estructural que esencialista (ms basado en las relaciones que en las cosas que componen un sistema), el modelo de objetos aparece como relativamente subordinado en relacin con la importancia que ha tenido en otros mbitos de la ingeniera de software, en los que la orientacin a objeto ha sido y sigue siendo dominante. Pero entre los estilos, se lo sita al lado de las arquitecturas basadas en componentes y las orientadas a servicios, ya sea en paridad de condiciones o como precedente histrico [WF04]. El argumento de la superioridad y la masa crtica de las herramientas de modelado orientadas a objeto no se sostiene a nivel de estilos arquitectnicos, ni debera ser relevante en cuanto al estilo de implementacin.

Arriba

Arquitecturas Basadas en Componentes

Los sistemas de software basados en componentes se basan en principios definidos por una ingeniera de software especfica (CBSE) [BW98]. En un principio, hacia 1994, se planteaba como una modalidad que extenda o superaba la tecnologa de objetos, como en un famoso artculo de BYTE cuyo encabezado rezaba as: ComponentWare La computacin Orientada a Objetos ha fracasado. Pero el software de componentes, como los controles de Visual Basic, est teniendo xito. Aqu explicamos por qu (Mayo de 1994, pp. 46-56). Con el paso de los aos el antagonismo se fue aplacando y las herramientas (orientadas a objeto o no) fueron adaptadas para producir componentes. En la mayora de los casos, los componentes terminan siendo formas especiales de DLLs que admiten late binding, que necesitan registracin y que no

requieren que sea expuesto el cdigo fuente de la clase [Szy95].

Hay un buen nmero de definiciones de componentes, pero Clemens Alden Szyperski proporciona una que es bastante operativa: un componente de software, dice, es una unidad de composicin con interfaces especificadas contractualmente y dependencias del contexto explcitas [Szy02]. Que sea una unidad de composicin y no de construccin quiere decir que no es preciso confeccionarla: se puede comprar hecha, o se puede producir en casa para que otras aplicaciones de la empresa la utilicen en sus propias composiciones. Pragmticamente se puede tambin definir un componente (no en el sentido estilstico, sino en el de CBSE) como un artefacto diseado y desarrollado de acuerdo ya sea con CORBA Component Model (CCM), JavaBeans y Enterprise JavaBeans en J2EE y lo que alternativamente se llam OLE, COM, ActiveX y COM+, y luego .NET. En un estilo de este tipo:

Los componentes en el sentido estilstico son componentes en el sentido de CBSE y son las

unidades de modelado, diseo e implementacin.

Las interfaces estn separadas de las implementaciones, y las interfaces y sus interacciones son el

centro de incumbencias en el diseo arquitectnico. Los componentes soportan algn rgimen de introspeccin, de modo que su funcionalidad y propiedades puedan ser descubiertas y utilizadas en tiempo de ejecucin.

En tecnologa COM IUnknown es una interfaz explcita de introspeccin que soporta la operacin QueryInterface.

En cuanto a las restricciones, puede admitirse que una interfaz sea implementada por mltiples

componentes. Usualmente, los estados de un componente no son accesibles desde el exterior [Szy02]. Que los componentes sean locales o distribuidos es transparente en la tecnologa actual.

El marco arquitectnico estndar para la tecnologa de componentes est constituido por los cinco puntos de vista de RM-ODP (Empresa, Informacin, Computacin, Ingeniera y Tecnologa). La evaluacin dominante del estilo de componentes subraya su mayor versatilidad respecto del modelo de objetos, pero tambin su menor adaptabilidad comparado con el estilo orientado a servicios. Las tecnologas de componentes del perodo de inmadurez, asimismo, se consideraban afectadas por problemas de incompatibilidad de versiones e inestabilidad que ya han sido largamente superados en toda la industria.

En la estrategia arquitectnica de Microsoft el estilo de componentes, en el contexto de las arquitecturas en capas de Windows DNA ha sido, como ya se ha dicho, unos de los vectores tecnolgicos ms importantes a

fines del siglo XX; el framework de .NET permite construir componentes avanzados e interoperar componentes y servicios a nivel de la tecnologa COM+ 1.5, no como prestacin legacy, sino en el contexto mayor (estilsticamente mixto) de servicios de componentes [MS03c].

Arriba

Estilos de Cdigo Mvil

Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los intrpretes, los sistemas basados en reglas y los procesadores de lenguaje de comando. Fuera de las mquinas virtuales y los intrpretes, los otros miembros del conjunto han sido rara vez estudiados desde el punto de vista estilstico. Los sistemas basados en reglas, que a veces se agrupan como miembros de la familia de estilos basados en datos, han sido estudiados particularmente por Murrell, Gamble, Stiger y Plant [MPG96] [SG97] [GSP99].

Arriba

Arquitectura de Mquinas Virtuales

La arquitectura de mquinas virtuales se ha llamado tambin intrpretes basados en tablas [GS94] [SC96]. De hecho, todo intrprete involucra una mquina virtual implementada en software. Se puede decir que un intrprete incluye un seudo-programa a interpretar y una mquina de interpretacin. El seudo-programa a su vez incluye el programa mismo y el anlogo que hace el intrprete de su estado de ejecucin (o registro de activacin). La mquina de interpretacin incluye tanto la definicin del intrprete como el estado actual de su ejecucin. De este modo, un intrprete posee por lo general cuatro componentes: (1) una mquina de interpretacin que lleva a cabo la tarea, (2) una memoria que contiene el seudo-cdigo a interpretar, (3) una representacin del estado de control de la mquina de interpretacin, y (4) una representacin del estado actual del programa que se simula.

El estilo comprende bsicamente dos formas o sub-estilos, que se han llamado intrpretes y sistemas basados en reglas. Ambas variedades abarcan, sin duda, un extenso espectro que va desde los llamados lenguajes de alto nivel hasta los paradigmas declarativos no secuenciales de programacin, que todo el mundo sabe que implementan un proxy (una especie de nivel de impostura) que encubren al usuario operaciones que en ltima instancia se resuelven en instrucciones de mquinas afines al paradigma secuencial imperativo de siempre.

Fig. 5 - Intrprete [basado en GS94]

El estilo es su conjunto se utiliza habitualmente para construir mquinas virtuales que reducen el vaco que media entre el engine de computacin esperado por la semntica del programa y el engine fsicamente disponible. Las aplicaciones inscriptas en este estilo simulan funcionalidades no nativas al hardware y software en que se implementan, o capacidades que exceden a (o que no coinciden con) las capacidades del paradigma de programacin que se est implementando. Dado que hasta cierto punto las mquinas virtuales no son una opcin sino que devienen inevtiables en ciertos contextos, nadie se ha entretenido identificando sus ventajas y demritos.

Las mquinas virtuales no son una invencin reciente ligada a Java, sino que existen desde muy antiguo. En la dcada de 1950, los precursores de los ingenieros de software sugirieron una mquina virtual basada en un lenguaje de mquina universal de bytecodes (un ejemplo fue UNCOL), de manera que las aplicaciones podan escribirse en las capas ms altas y ejecutarse donde fuere sin tener que recompilarse, siempre que hubiera una mquina virtual entre el programa por un lado y el sistema operativo y la mquina real por el otro [Con58]. En 1968 Alan Kay implement una mquina virtual vinculada a un sistema orientado a objetos [Kay68] y luego particip con Dan Ingalls en el desarrollo de la MV de Smalltalk hacia 1972. Numerosos lenguajes y ambientes de scripting utilizan mquinas virtuales: Perl, Javascript, Windows Script Host (WSH), Python, PHP, Pascal. WSH, por ejemplo, tolera programacin en casi cualquier lenguaje de scripting que se atenga a ciertas especificaciones simples.

En la nueva estrategia arquitectnica de Microsoft la mquina virtual por excelencia guarda relacin con el Common Language Runtime, acaso unas de las dos piezas esenciales del framework .NET (la otra es la biblioteca de clases). El CLR admite, en efecto, diversos paradigmas puros y templados: programacin funcional (Lisp, Scheme, F#, Haskell), programacin imperativa orientada a objetos (C#, J#, C++, Python) y estructurada en bloques (Oberon), ambientes de objetos puros (Smallscript / Smalltalk), programacin

lgica declarativa (Prolog, P#), diseo basado en contratos (Eiffel), modelado matemtico (Fortran), scripting interpretado (Perl), meta-programacin (SML, Mondrian), programacin cercana a la semntica de negocios (Cobol), programacin centrada en reportes (Visual ASNA RPG), adems de todos los matices y composiciones heterogneas a que haya lugar. Si bien el lenguaje final de implementacin se encuentra en un punto del proceso bastante alejado de la ideacin arquitectnica en que se despliegan los estilos, el efecto de la disponibilidad de estas capacidades en el diseo inicial de un sistema no es para nada trivial. Con una mquina virtual comn el proceso evita la redundancia de motores compitiendo por recursos y unifica debuggers y profilers. La congruencia entre la naturaleza semntica y sintctica del modelo y la de los lenguajes de programacin concretos ha sido, despus de todo, una de las banderas del modelado orientado a objetos, desde OMT hasta UML, pasando por el modelado no slo de las aplicaciones sino de las bases de datos [RBP+91].

Arriba

Estilos heterogneos

Antes de pasar a la familia ms fuertemente referida en los ltimos tiempos, incluyo en este grupo formas compuestas o indciles a la clasificacin en las categoras habituales. Es por cierto objetable y poco elegante que existan clases residuales de este tipo en una taxonoma, pero ninguna clasificacin conocida ha podido resolver este dilema conceptual. En este apartado podran agregarse formas que aparecen espordicamente en los censos de estilos, como los sistemas de control de procesos industriales, sistemas de transicin de estados, arquitecturas especficas de dominios [GS94] o estilos derivados de otros estilos, como GenVoca, C2 o REST.

Arriba

Sistemas de control de procesos

Desde el punto de vista arquitectnico, mientras casi todos los dems estilos se pueden definir en funcin de componentes y conectores, los sistemas de control de procesos se caracterizan no slo por los tipos de componentes, sino por las relaciones que mantienen entre ellos. El objetivo de un sistema de esta clase es mantener ciertos valores dentro de ciertos rangos especificados, llamados puntos fijos o valores de calibracin; el caso ms clsico es el de los termostatos. Existen mecanismos tanto de retroalimentacin (feedback) como de prealimentacin (feedforward), y tanto reductores de oscilacin como amplificadores;

pero el tipo de retroalimentacin negativa es el ms comn. En uno de los pocos tratamientos arquitectnicos de esta clase de modelos cibernticos, Shaw y Garlan recomiendan separar los tres elementos del bucle de control (mecanismos para cambiar los valores de variables y algoritmos de control, elementos de datos; esquema del bucle). La ventaja sealada para este estilo radica en su elasticidad ante perturbaciones externas [SG96].

Arriba

Arquitecturas Basadas en Atributos

Aunque algunas otras veces se ha inventado un nuevo estilo para agregarlo al inventario de las variedades existentes, como en este caso, en el de Arch, C2 o REST, la literatura estilstica suele ser de carcter reactivo e historicista antes que creativa e innovadora, como si el nmero de estilos se quisiera mantener deliberadamente bajo. La arquitectura basada en atributos o ABAS fue propuesta por Klein y Klazman [KK99]. La intencin de estos autores es asociar a la definicin del estilo arquitectnico un framework de razonamiento (ya sea cuantitativo o cualitativo) basado en modelos de atributos especficos. Su objetivo se funda en la premisa que dicha asociacin proporciona las bases para crear una disciplina de diseo arquitectnico, tornando el diseo en un proceso predecible, antes que en una metodologa ad hoc. Con ello se lograra que la arquitectura de software estuviera ms cerca de ser una disciplina de ingeniera, aportando el beneficio esencial de la ingeniera (predictibilidad) al diseo arquitectnico.

El modelo de Klein y Kazman en realidad no tipifica como un estilo en estado puro, sino como una asociacin entre la idea de estilo con anlisis arquitectnico y atributos de calidad. En este contexto, los estilos arquitectnicos definen las condiciones en que han de ser usados. Adems de especificar los habituales componentes y conectores, los estilos basados en atributos incluyen atributos de calidad especficos que declaran el comportamiento de los componentes en interaccin. Por ejemplo, en las arquitecturas tuberafiltros, se especifica que se considere de qu manera ha de ser administrada la performance y se presta atencin a los supuestos que rigen el comportamiento de los filtros y al efecto de su re-utilizacin. Agregando condiciones, un estilo deviene mtodo.

Dado el carcter peculiar de ABAS no se proceder aqu a su anlisis. Llamo la atencin no obstante sobre su naturaleza dinmica e instrumental. Por lo general los arquitectos del campo de los estilos, mayormente estructuralistas, no se ocupan de cuestiones procesales tales como disciplinas de desarrollo, refinamiento, evaluacin o anlisis de riesgo, que corresponderan ms bien a las incumbencias de los ingenieros. En la estrategia de arquitectura de Microsoft, empero, hay amplias elaboraciones en este sentido bajo la forma de

una metodologa de verificacin de patrones de software [AEA+03]; la metodologa est expresamente orientada a patrones en el sentido de Christopher Alexander [Ale77], pero es por completo aplicable a estilos arquitectnicos debido a la proximidad de las nociones de patrn y estilo.

Arriba

Estilos Peer-to-Peer

Esta familia, tambin llamada de componentes independientes, enfatiza la modificabilidad por medio de la separacin de las diversas partes que intervienen en la computacin. Consiste por lo general en procesos independientes o entidades que se comunican a travs de mensajes. Cada entidad puede enviar mensajes a otras entidades, pero no controlarlas directamente. Los mensajes pueden ser enviados a componentes nominados o propalados mediante broadcast. Miembros de la familia son los estilos basados en eventos, en mensajes (Chiron-2), en servicios y en recursos. Gregory Andrews [And91] elabor la taxonoma ms detallada a la fecha de estilos basados en transferencia de mensajes, distinguiendo ocho categoras: (1) Flujo de datos en un sentido a travs de redes de filtros. (2) Requerimientos y respuestas entre clientes y servidores. (3) Interaccin de ida y vuelta o pulsacin entre procesos vecinos. (4) Pruebas y ecos en grafos incompletos. (5) Broadcasts entre procesos en grafos completos. (6) Token passing asincrnico. (7) Coordinacin entre procesos de servidor decentralizados. (8) Operadores replicados que comparten una bolsa de tareas.

Arriba

Arquitecturas Basadas en Eventos

Las arquitecturas basadas en eventos se han llamado tambin de invocacin implcita [SG96]. Otros nombres propuestos para el mismo estilo han sido integracin reactiva o difusin (broadcast) selectiva. Por supuesto que existen estrategias de programacin basadas en eventos, sobre todo referidas a interfaces de usuario, y hay adems eventos en los modelos de objetos y componentes, pero no es a eso a lo que se refiere primariamente el estilo, aunque esa variedad no est del todo excluida. En trminos de patrones de diseo, el patrn que corresponde ms estrechamente a este estilo es el que se conoce como Observer, un trmino que se hizo popular en Smalltalk a principios de los ochenta; en el mundo de Java se le conoce como modelo de delegacin de eventos[Lar03].

Las arquitecturas basadas en eventos se vinculan histricamente con sistemas basados en actores, daemons y redes de conmutacin de paquetes (publicacin-suscripcin). Los conectores de estos sistemas incluyen procedimientos de llamada tradicionales y vnculos entre anuncios de eventos e invocacin de procedimientos. La idea dominante en la invocacin implcita es que, en lugar de invocar un procedimiento en forma directa (como se hara en un estilo orientado a objetos) un componente puede anunciar mediante difusin uno o ms eventos. Un componente de un sistema puede anunciar su inters en un evento determinado asociando un procedimiento con la manifestacin de dicho evento. Un caso clsico en ambientes Microsoft sera el Servicio de Notificacin de SQL Server. Cuando el evento se anuncia, el sistema invoca todos los procedimientos que se han registrado para l. De este modo, el anuncio de un evento implcitamente ocasiona la invocacin de determinados procedimientos en otros mdulos. Tambin hay elementos de arquitectura de publicacin-suscripcin en el modelo de replicacin de SQL Server (definido en su documentacin como una metfora de industria), en el Publish-Subscribe Toolkit de BizTalk Server 2002 [Chu02] o el Publish-Subscribe API de Windows CE .NET 4.2.

Desde el punto de vista arquitectnico, los componentes de un estilo de invocacin implcita son mdulos cuyas interfaces proporcionan tanto una coleccin de procedimientos (igual que en el estilo de tipos de datos abstractos) como un conjunto de eventos. Los procedimientos se pueden invocar a la manera usual en modelos orientados a objeto, o mediante el sistema de suscripcin que se ha descripto.

Los ejemplos de sistemas que utilizan esta arquitectura son numerosos. El estilo se utiliza en ambientes de integracin de herramientas, en sistemas de gestin de base de datos para asegurar las restricciones de consistencia (bajo la forma de disparadores, por ejemplo), en interfaces de usuario para separar la presentacin de los datos de los procedimientos que gestionan datos, y en editores sintcticamente orientados para proporcionar verificacin semntica incremental.

Un estilo perteneciente a esta clase es C2 o Chiron-2. Una aplicacin de arquitectura C2 est constituida por componentes que se comunican a travs de buses; la comunicacin est basada en eventos. Un componente puede enviar o recibir eventos hacia o desde los buses a los que est conectado. Componentes y buses se pueden componer topolgicamente de distintas maneras, siguiendo reglas y restricciones particulares. Cada componente posee dos puntos de conexin, llamados respectivamente top y bottom. El esquema no admite ciclos, de modo que un componente no puede recibir una notificacin generada por l mismo [DNR99].

En la estrategia arquitectnica de Microsoft, este estilo (llamado ms bien un patrn recurrente de diseo) juega un papel de alguna importancia [MS02a]. En este estilo y en ese contexto, los eventos se disparan bajo condiciones de negocios particulares, debindose escribir cdigo para responder a esos eventos. Este patrn puede utilizarse cuando se desea que sucedan varias actividades, tal que todas ellas reciben los

mismos datos de iniciacin y no pueden comunicarse entre s. Diferentes implementaciones del evento pueden o no ejecutarse, dependiendo de informacin de filtro especfica. Si las implementaciones se han configurado para que corran secuencialmente, el orden no puede garantizarse. Las prescripciones de Microsoft para el uso del modelo de eventos sealan que este estilo puede utilizarse cuando:

Se desea manejar independientemente y de forma aislada diversas implementaciones de una

funcin especfica.

Las respuestas de una implementacin no afectan la forma en que trabajan otras

implementaciones.

Todas las implementaciones son de escritura solamente o de dispararse-y-olvidar, tal que la salida

del proceso de negocios no est definida por ninguna implementacin, o es definida slo por una implementacin de negocios especfica.

Entre las ventajas enumeradas en relacin con el modelo se sealan:

Se optimiza el mantenimiento haciendo que procesos de negocios que no estn relacionados sean

independientes.

Se alienta el desarrollo en paralelo, lo que puede resultar en mejoras de performance. Es fcil de empaquetar en una transaccin atmica. Es agnstica en lo que respecta a si las implementaciones corren sincrnica o asincrnicamente

porque no se espera una respuesta.

Se puede agregar un componente registrndolo para los eventos del sistema; se pueden

reemplazar componentes.

Entre las desventajas:

El estilo no permite construir respuestas complejas a funciones de negocios. Un componente no puede utilizar los datos o el estado de otro componente para efectuar su tarea. Cuando un componente anuncia un evento, no tiene idea sobre qu otros componentes estn

interesados en l, ni el orden en que sern invocados, ni el momento en que finalizan lo que tienen que hacer. Pueden surgir problemas de performance global y de manejo de recursos cuando se comparte un repositorio comn para coordinar la interaccin.

En esta estrategia juega un rol importante el Servicio de Eventos, el cual a su vez proporciona un buen punto de partida para la implementacin del estilo o patrn, segn se est concibiendo la arquitectura o implementndola. Se puede consultar informacin detallada sobre Enterprise Service Events en el artculo sobre COM+ Events incluido en la documentacin del SDK de COM+ en Microsoft Developers Network (http://msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_events_2y9f.asp ). La arquitectura del servicio de notificacin de SQL Server (basada en XML) est descripta en http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sqlntsv/htm/ns_overarch_5to4.asp.

Arriba

Arquitecturas Orientadas a Servicios

Slo recientemente estas arquitecturas que los conocedores llaman SOA han recibido tratamiento intensivo en el campo de exploracin de los estilos. Al mismo tiempo se percibe una tendencia a promoverlas de un sub-estilo propio de las configuraciones distribuidas que antes eran a un estilo en plenitud. Esta promocin ocurre al comps de las predicciones convergentes de Giga o de Gartner que (despus de un par de aos de titubeo y consolidacin) las visualizan en sus pronsticos y cuadrantes mgicos como la tendencia que habr de ser dominante en la primera dcada del nuevo milenio. Ahora bien, este predominio no se funda en la idea de servicios en general, comunicados de cualquier manera, sino que ms especficamente va de la mano de la expansin de los Web services basados en XML, en los cuales los formatos de intercambio se basan en XML 1.0 Namespaces y el protocolo de eleccin es SOAP. SOAP significa un formato de mensajes que es XML, comunicado sobre un transporte que por defecto es HTTP, pero que puede ser tambin HTTPs, SMTP, FTP, IIOP, MQ o casi cualquier otro, o puede incluir prestaciones sofisticadas de ltima generacin como WS-Routing, WS-Attachment, WS-Referral, etctera.

Alrededor de los Web services, que dominan el campo de un estilo SOA ms amplio que podra incluir otras opciones, se han generado las controversias que usualmente acompaan a toda idea exitosa. Al principio hasta resultaba difcil encontrar una definicin aceptable y consensuada que no fuera una frmula optimista de mercadotecnia. El grupo de tareas de W3C, por ejemplo, demor un ao y medio en ofrecer la primera definicin cannica apta para consumo arquitectnico, que no viene mal reproducir aqu:

Un Web service es un sistema de software diseado para soportar interaccin mquina-a-mquina sobre una red. Posee una interfaz descripta en un formato procesable por mquina (especficamente WSDL). Otros sistemas interactan con el Web service de una manera prescripta por su descripcin utilizando mensajes

SOAP, tpicamente transportados usando HTTP con una serializacin en XML en conjuncin con otros estndares relacionados a la Web [Cha03]

En la literatura clsica referida a estilos, las arquitecturas basadas en servicios podran engranar con lo que Garlan & Shaw definen como el estilo de procesos distribuidos. Otros autores hablan de Arquitecturas de Componentes Independientes que se comunican a travs de mensajes. Segn esta perspectiva, no del todo congruente con la masa crtica que han ganado las arquitecturas orientadas a servicios en los ltimos aos, habra dos variantes del estilo:

- Participantes especificados (named): Estilo de proceso de comunicacin. El ejemplar ms conocido sera el modelo cliente-servidor. Si el servidor trabaja sincrnicamente, retorna control al cliente junto con los datos; si lo hace asincrnicamente, slo retorna los datos al cliente, el cual mantiene su propio hilo de control. - Participantes no especificados (unnamed): Paradigma publish/subscribe, o estilo de eventos.

Los estilos de la familia de la orientacin a servicios, empero, se han agrupado de muchas maneras diversas, segn surge del apartado que dedicamos a las taxonomas estilsticas [Mit02] [Fie00]. Existen ya unos cuantos textos consagrados a analizar los Web services basados en XML en trminos de arquitectura de software en general y de estilos arquitectnicos en particular; especialmente recomendables son el volumen de Ron Schmelzer y otros [Sch+02] y Architecting Web Services de W. Oellermann [Oel01].

No es intencin de este estudio describir en detalle las peculiaridades de este estilo, suficientemente caracterizado desde diferentes puntos de vista en la documentacin primaria de la estrategia de arquitectura de Microsoft [Ms02a] [MS02b]. Lo que s vale la pena destacar es la forma en la cual el estilo redefine los viejos modelos de ORPC propios de las arquitecturas orientadas a objetos y componentes, y al hacerlo establece un modelo en el que es casi razonable pensar que cualquier entidad computacional (nativamente o mediando un wrapper) podra llegar a conversar o a integrarse con cualquier otra (dem) una vez resueltas las inevitables coordinaciones de ontologa. En el cuadro siguiente he referido las caractersticas del modelo de llamado-respuesta propio del estilo, en contraste con tecnologas clsicas bien conocidas de comunicacin entre componentes y objetos en ambientes DCOM, CORBA y Java.

Lo que hace diferentes a los Web services de otros mecanismos de RPC como RMI, CORBA o DCOM es que utiliza estndares de Web para los formatos de datos y los protocolos de aplicacin. Esto no slo es un factor de correccin poltica, sino que permite que las aplicaciones interoperen con mayor libertad, dado que las organizaciones ya seguramente cuentan con una infraestructura activa de HTTP y pueden implementar tratamiento de XML y SOAP en casi cualquier lenguaje y plataforma, ya sea descargando un par de kits, adquiriendo el paquete de lenguaje o biblioteca que proporcione la funcionalidad o programndolo a mano. Esto no admite ni punto de comparacin con lo que implicara, por ejemplo, implementar CORBA en todas

las plataformas participantes. Por aadidura, la descripcin, publicacin, descubrimiento, localizacin e invocacin de los Web services se puede hacer en tiempo de ejecucin, de modo que los servicios que interactan pueden figurarse la forma de operar de sus contrapartes, sin haber sido diseados especficamente caso por caso. Por primera vez, esta dinamicidad es plenamente viable. DCOM Protocolo RPC Formato de mensaje Descripcin RPC NDR CORBA IIOP CDR Java RMI IIOP o JRMP Java Serialization Format Java RMI Registry o JNDI Web Services SOAP XML 1.0 Namespaces WSDL UDDI

IDL

OMG IDL Naming Service IOR

Descubrimiento Registry Denominacin Marshalling GUID, OBJREF

Java.rmi.naming URI Serializacin

Type Dynamic Java.rmi Library Invocation/Skeleton Marshalling o Marshaller Interface Serializacin Tabla 2 - Modelos de RPC

Desde el punto de vista arquitectnico, se puede hacer ahora una caracterizacin sucinta de las caractersticas del estilo:

Un servicio es una entidad de software que encapsula funcionalidad de negocios y proporciona dicha

funcionalidad a otras entidades a travs de interfaces pblicas bien definidas.

Los componentes del estilo (o sea los servicios) estn dbilmente acoplados. El servicio puede

recibir requerimientos de cualquier origen. La funcionalidad del servicio se puede ampliar o modificar sin rendir cuentas a quienes lo requieran. Los servicios son las unidades de implementacin, diseo e implementacin.

Los componentes que requieran un servicio pueden descubrirlo y utilizarlo dinmicamente mediante

UDDI y sus estndares sucesores. En general (aunque hay alternativas) no se mantiene persistencia de estado y tampoco se pretende que un servicio recuerde nada entre un requerimiento y el siguiente.

Las especificaciones de RM-ODP son lo suficientemente amplias para servir de marco de referencia estndar tanto a objetos como a componentes y servicios, pero las herramientas usuales de diseo (por ejemplo UML) no poseen una notacin primaria ptima que permita modelar servicios, a despecho de docenas de propuestas en todos los congresos de modelado. Un servicio puede incluir de hecho muchas interfaces y poseer propiedades tales como descripcin de protocolos, puntos de entrada y caractersticas del servicio mismo. Algunas de estas notaciones son provistas por lenguajes declarativos basados en XML, como WSDL (Web Service Description Language).

Como todos los otros estilos, las SOA poseen ventajas y desventajas. Como se trata de una tecnologa que est en su pico de expansin, virtudes y defectos estn variando mientras esto se escribe. Las especificaciones fundamentales de toda la industria (y la siguiente versin de las capacidades de transporte, documentos agregados y formatos, ruteo, transaccin, workflow, seguridad, etctera) se definen primariamente en http://www.ws-i.org. En cuanto a una comparacin entre las tres arquitecturas en paridad de complejidad y prestigio (OOA, CBA y SOA) puede consultarse la reciente evaluacin de Wang y Fung [WF04] o los infaltables documentos comparativos de las empresas analistas de la industria.

En la documentacin de la estrategia de arquitectura de Microsoft se encontrar abundante informacin y lineamientos referidos al estilo arquitectnico orientado a servicios. De hecho, la informacin disponible es demasiado profusa para tratarla aqu en detalle. Comenzando por Application Architecture for .NET [MS02a], y Application Conceptual View [MS02b], el lector encontrar sobrada orientacin y patrones de diseo y arquitectura correspondientes a este estilo en el sitio de Microsoft Patterns & Practices, as como en la casi totalidad de las bibliotecas de MSDN de los ltimos aos. En el futuro prximo, el modelo de programacin de Longhorn permitir agregar a la ya extensa funcionalidad de los servicios una nueva concepcin relacional del sistema de archivos, soporte extensivo de shell y prcticamente toda la riqueza del API de Win32 en trminos de cdigo manejado [Rec04].

Arriba

Arquitecturas Basadas en Recursos

Una de las ms elocuentes presentaciones de arquitecturas peer-to-peer ha sido la disertacin doctoral de Roy Fielding, elaborada con anterioridad pero expuesta con mayor impacto en el ao 2000 [Fie00]. Es en ella donde se encuentra la caracterizacin ms detallada del estilo denominado Representational State Transfer o REST. Aunque la literatura especializada tiende a considerar a REST una variante menor de las arquitecturas basadas en servicios, Fielding considera que REST resulta de la composicin de varios estilos ms bsicos, incluyendo repositorio replicado, cache, cliente-servidor, sistema en capas, sistema sin estado, mquina virtual, cdigo a demanda e interfaz uniforme [FT02]. Fielding no solamente expande ms all de lo habitual y quiz ms de lo prudente el catlogo de estilos existentes, sino que su tratamiento estilstico se basa en Perry y Wolf [PW92] antes que en Garlan y Shaw [GS94], debido a que la literatura sobre estilos que se deriva de este ltimo texto slo considera elementos, conectores y restricciones, sin tomar en consideracin los datos, que para el caso de REST al menos constituyen una dimensin esencial.

En sntesis muy apretada, podra decirse que REST define recursos identificables y mtodos para acceder y manipular el estado de esos recursos. El caso de referencia es nada menos que la World Wide Web, donde los URIs identifican los recursos y HTTP es el protocolo de acceso. El argumento central de Fielding es que HTTP mismo, con su conjunto mnimo de mtodos y su semntica simplsima, es suficientemente general para modelar cualquier dominio de aplicacin. De esta manera, el modelado tradicional orientado a objetos deviene innecesario y es reemplazado por el modelado de entidades tales como familias jerrquicas de recursos abstractos con una interfaz comn y una semntica definida por el propio HTTP. REST es en parte una resea de una arquitectura existente y en parte un proyecto para un estilo nuevo. La caracterizacin de REST constituye una lectura creativa de la lgica dinmica que rige el funcionamiento de la Web (una especie de ingeniera inversa de muy alto nivel), al lado de una propuesta de nuevos rasgos y optimizaciones, o restricciones adicionales: REST, por ejemplo, no permite el paso de cookies y propone la eliminacin de MIME debido a su tendencia estructural a la corrupcin y a su discrepancia lgica con HTTP. REST se construye expresamente como una articulacin compuesta a partir de estilos y sub-estilos preexistentes, con el agregado de restricciones especficas. En la figura 6, RR corresponde a Repositorio Replicado, CS a Cliente-Servidor, LS a sistema en capas, VM a Mquina Virtual y as sucesivamente en funcin de la nomenclatura referida en la clasificacin de Fielding [Fie00], revisada oportunamente. En este sentido, REST constituye un ejemplo de referencia para derivar descripciones de arquitecturas de la vida real en base a un procedimiento de composicin estilstica, tal como se ilustra en la Figura 6.

Fig. 6 - Composicin de REST [FT02]

La especificacin REST posee algunas peculiaridades emanadas de su lgica orientada a recursos que la hacen diferente de otras implementaciones tales como WebDAV, ebXML, BPML, XLANG, UDDI, WSCK o BPEL4WS que se analizar en un documento especfico sobre arquitecturas orientadas a servicios. Sobre una comparacin entre dichas variantes puede consultarse el anlisis de Mitchell [Mit02].

La polmica sobre si REST constituye una revolucionaria inflexin en los estilos orientados a servicios (la nueva generacin de Web services) o si es una variante colateral todava subsiste. En opinin de Jrgen Thelin, REST es un estilo caracterstico de las arquitecturas basadas en recursos, antes que en mensajes, y la especificacin total de Web services sera un superconjunto de dicha estrategia, susceptible de visualizarse como estilo de recursos o de servicios, segn convenga. Como quiera que sea, los organismos de estndares que han elaborado SOAP 1.2 y WSDL 1.2, as como WS-I, han incorporado ideas de REST, tales como atenuar el concepto originario que entenda los Web services como meros objetos distribuidos en una red, o concebir las interacciones ms en trminos de intercambios asincrnicos de documentos que como una modalidad nueva de llamada remota a procedimientos [Cha03] [ http://www.ws-i.org]. El lema de REST es, despus de todo, Adis objetos, adis RPC.

Arriba

El Lugar del Estilo en Arquitectura de Software

A fin de determinar cmo se vinculan los estilos con otros conceptos y el espacio que ocupan en el marco conceptual de la arquitectura o en las secuencias de procesos de la metodologa, habra que mapear buena parte, si es que no la totalidad del espacio de la arquitectura de software, a su vez complejamente vinculado con otros campos que nunca fueron demarcados de manera definitiva. Mientras algunos claman por una disciplina autnoma de diseo (Mitchell Kapor, Terry Winograd), otros estudiosos (Peter Denning, Dewayne Perry) discriminan con distincin y claridad el mbito de la arquitectura y el del diseo, y no admitiran jams cruzar la lnea que los separa. Como quiera que se organice la totalidad, no es intencin de este texto construir un nuevo mapa que se agregue a los muchos esquemas panpticos que ya se postularon. Por lo general stos encuentran su sentido en estructuras y paradigmas cuya vigencia, generalidad y relevancia es a veces incierta, o que estn sesgadas no siempre con discrecin en favor de una doctrina especfica de modelado y de desarrollo (que en la mayora de los casos est previsiblemente orientada a objetos). Est claro que casi cualquier tecnologa puede de alguna forma implementar casi cualquier cosa; pero si todo fuera rigurosa y elegantemente reducible a objetos, ni falta que hara distinguir entre estilos.

Los estilos son susceptibles de asignarse a diversas posiciones en el seno de vistas y modelos mayores, aunque llamativamente la literatura sobre estilos no ha sido jams sistemtica ni explcita al respecto. Nunca nadie ha expresado que el discurso sobre estilos concierna a una coordenada especfica de algn marco definido, como si el posicionamiento en dicho contexto fuera irrelevante, o resultara obvio para cualquier arquitecto bien informado. La verdad es que si ya disponamos de un marco abarcativo (4+1, pongamos por caso, o la matriz de Zachman, o la estrategia global de Microsoft) situar en l la teora y la prctica de los

estilos dista de ser algo que pueda decidirse siempre con transparencia. Los estilos son histricamente ms tardos que esos marcos, y surgieron porque haba necesidad de compensar una ausencia tanto en el canon esttico de las matrices de vistas como en el paradigma dinmico de los procesos, metodologas de diseo o disciplinas de desarrollo de soluciones.

El concepto de vistas arquitectnicas (views), as como los frameworks arquitectnicos establecidos en las fases tempranas de la arquitectura de software, suministran diferentes organizaciones del espacio de conceptos, mtodos, tcnicas, herramientas y procesos segn distintos criterios y con variados nfasis. Las terminologas globalizadoras son inestables y no siempre fciles de comparar entre s; se ha hablado de frameworks, modelos de referencia, escenarios, vistas (views), metodologas y paradigmas. Algunos ejemplares abarcativos han sido consistentes en el uso de la terminologa, otros no tanto. An en el caso de que la terminologa sea sintcticamente invariante (como sucede en epistemologa con el clebre paradigma de Thomas Kuhn) la semntica que se le imprime no siempre ha sido la misma, ni en los documentos oficiales ni en su aplicacin por terceras partes.

En general, los grandes marcos son agnsticos en lo que se refiere a metodologas y notaciones. Por metodologas me refiero a entidades tales como Microsoft Solutions Framework, RUP, modelos de procesos de ingeniera de software (DADP, DSSA, FODA, FORM, FAST, ODM, ROSE) o los llamados Mtodos giles (Lean Development, eXtreme Programming, Adaptive Software Development). Por notaciones quiero significar ya sea los lenguajes de descripcin de arquitectura o ADLs (Acme/Armani, Aesop, C2SADEL, Darwin, Jacal, LILEANNA, MetaH, Rapide, Wright, xADL), los lenguajes formales de especificacin (Alloy, CHAM, CSP, LARCH, Z, clculo ?, VDM), las tcnicas de anlisis y diseo como SADT y los lenguajes de modelado como UML (el cual, incidentalmente, ha debido ser re-semantizado y extendido de maneras ms bien tortuosas para poder integrar en su conjunto nativo modelado arquitectnico en general y de estilos en particular).

Otras propuestas que han surgido y que eventualmente se presentan como marcos de referencia envolventes, como la de MDP/EDOC/MDA (dependientes de OMG), han mapeado (o estn en proceso de hacerlo) sus estructuras conceptuales contra algunos de los grandes marcos de referencia, tales como RMODP, o sobre marcos nomencladores como IEEE Std 1471, que se ha hecho pblico en el ao 2000.

Algunos autores han introducido modelos de vistas y puntos de vista (views, viewpoints) insertas en marcos de referencia (frameworks) y numerosos organismos de estandarizacin han hecho lo propio. Las pginas de cabecera de la estrategia de arquitectura de Microsoft reconocen algunos de esos marcos como modelos primarios de referencia. Los que aqu mencionaramos, sealando la posible ubicacin de los estilos, son los siguientes:

El marco de referencia para la arquitectura empresarial de Zachman [Zac87] es uno de los ms

conocidos. Identifica 36 vistas en la arquitectura (celdas) basadas en seis niveles (scope, empresa, sistema lgico, tecnologa, representacin detallada y funcionamiento empresarial) y seis aspectos (datos, funcin, red, gente, tiempo, motivacin). En el uso corriente de arquitectura de software se ha estimado que este modelo es excesivamente rgido y sobre-articulado. En la literatura arquitectnica sobre estilos, en general, no se lo ha aplicado en forma explcita y al menos off the record parecera existir cierto acuerdo sobre su posible obsolescencia. Los manuales recientes de ingeniera de software (por ejemplo [Pre02]) suelen omitir toda referencia a este marco.

El Modelo de Referencia para Procesamiento Distribuido Abierto (RM-ODP) es un estndar ISO/ITU

que brinda un marco para la especificacin arquitectnica de grandes sistemas distribuidos. Define, entre otras cosas, cinco puntos de vista (viewpoints) para un sistema y su entorno: Empresa, Informacin, Computacin, Ingeniera y Tecnologa. Los cinco puntos de vista no corresponden a etapas de proceso de desarrollo o refinamiento. De los cuatro estndares bsicos, los dos primeros se refieren a la motivacin general del modelo y a sus fundamentos conceptuales y analticos, el tercero (ISO/IEC 10746-3; UTI-T X.903) a la arquitectura, definiendo los puntos de vistas referidos; y el cuarto (ISO/IEC 10746-4; UTI-T X.904) a la formalizacin de la semntica arquitectnica. RM-ODP se supone neutral en relacin con la metodologa, las formas de modelado y la tecnologa a implementarse, y es particularmente incierto situar los estilos en su contexto.

El marco de referencia arquitectnico de The Open Group (TOGAF) reconoce cuatro componentes

principales, uno de los cuales es un framework de alto nivel que a su vez define cuatro vistas: Arquitectura de Negocios, Arquitectura de Datos/Informacin, Arquitectura de Aplicacin y Arquitectura Tecnolgica. En marzo de 2000, Rick Hilliard elabor un preciso informe sobre el impacto de las recomendaciones de IEEE sobre el marco de TOGAF, estimando que ambos son complementarios y compatibles, pero recomendando que TOGAF se mueva hacia el marco categorial de IEEE antes que la inversa [Hil00]. Tal como est expresado el marco de referencia, los estilos se articulan con mayor claridad en la vista de Arquitectura de Aplicacin.

En 1995 Philippe Kruchten propuso su clebre modelo 4+1, vinculado al Rational Unified Process

(RUP), que define cuatro vistas diferentes de la arquitectura de software: (1) La vista lgica, que comprende las abstracciones fundamentales del sistema a partir del dominio de problemas. (2) La vista de proceso: el conjunto de procesos de ejecucin independiente a partir de las abstracciones anteriores. (3) La vista fsica: un mapeado del software sobre el hardware. (4) La vista de desarrollo: la organizacin esttica de mdulos en el entorno de desarrollo. El quinto elemento considera todos los anteriores en el contexto de casos de uso [Kru95]. Es palmario que los estilos afectan a las dos primeras vistas, mientras que los patrones tienen que ver ms bien con la ltima. En cuanto a los estilos, Kruchten menciona la posible implementacin de algunos de ellos (pipe-filter, cliente-servidor)

en relacin con la vista de proceso, mientras que recomienda adoptar un estilo en capas en la vista de desarrollo [Kru95: 3, 5]. Cuando se lee el artculo de Kruchten (un par de aos posterior al surgimiento de los estilos en el discurso arquitectnico) es inevitable la sensacin de que lo que l llama estilo tiene ms que ver con la notacin grfica que usa para la representacin (siempre ligada a ideas de objeto) que con la estructura de componentes, conectores y restricciones que segn se ha consensuado definen un estilo. Ya en la vista lgica, por ejemplo, los componentes son clases y los conectores estn ligados a conceptos de herencia; en la vista de desarrollo sus clases devienen mdulos o subsistemas ms o menos neutros, pero todo el mundo sabe qu entidad resulta cuando se instancia una clase, sobre todo cuando las incumbencias enfatizadas son portabilidad y re-utilizacin [Kru95: 14-15]. El modelo 4+1 se percibe hoy como un intento se reformular una arquitectura estructural y descriptiva en trminos de objetos y de UML, lo cual ocasiona que ningn estilo se manifieste con alguna continuidad en las diferentes vistas. En arquitectura de software en general se admite que no hay estilos puros y que hay inflexiones en un estilo que son como encapsulamientos en miniatura de algn otro tipo; pero los estilos no trasmutan tan fcilmente en funcin de la vista adoptada. Con todo, las cuatro vistas de Kruchten forman parte del repertorio estndar de los practicantes de la disciplina.

En su introduccin a UML (1.3), Grady Booch, James Rumbaugh e Ivar Jacobson han formulado un

esquema de cinco vistas interrelacionadas que conforman la arquitectura de software, caracterizada en trminos parecidos a los que uno esperara encontrar en el discurso de la vertiente estructuralista. En esta perspectiva, la arquitectura de software (a la que se dedican muy pocas pginas) es un conjunto de decisiones significativas sobre (1) la organizacin de un sistema de software; (2) la seleccin de elementos estructurales y sus interfaces a travs de los cuales se constituye el sistema; (3) su comportamiento, segn resulta de las colaboraciones entre esos elementos; (4) la composicin de esos elementos estructurales y de comportamiento en subsistemas progresivamente mayores; (5) el estilo arquitectnico que gua esta organizacin: los elementos estticos y dinmicos y sus interfaces, sus colaboraciones y su composicin. Los autores proporcionan luego un esquema de cinco vistas posibles de la arquitectura de un sistema: (1) La vista de casos de uso, como la perciben los usuarios, analistas y encargados de las pruebas; (2) la vista de diseo que comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solucin; (3) la vista de procesos que conforman los hilos y procesos que forman los mecanismos de sincronizacin y concurrencia; (4) la vista de implementacin que incluye los componentes y archivos sobre el sistema fsico; (5) la vista de despliegue que comprende los nodos que forma la topologa de hardware sobre la que se ejecuta el sistema [BRJ99: 26-27]. Aunque las vistas no estn expresadas en los mismos trminos estructuralistas que campean en su caracterizacin de la arquitectura, y aunque la relacin entre vistas y decisiones arquitectnicas es de simple yuxtaposicin informal de ideas antes que de

integracin rigurosa, es natural inferir que las vistas que ms claramente se vinculan con la semntica estilstica son la de diseo y la de proceso.

En los albores de la moderna prctica de los patrones, Buschmann y otros presentan listas

discrepantes de vistas en su texto popularmente conocido como POSA [BMR+96]. En la primera se las llama arquitecturas, y son: (1) Arquitectura conceptual: componentes, conectores; (2) Arquitectura de mdulos: subsistemas, mdulos, exportaciones, importaciones; (3) Arquitectura de cdigo: archivos, directorios, bibliotecas, inclusiones; (4) Arquitectura de ejecucin: tareas, hilos, procesos. La segunda lista de vistas, por su parte, incluye: (1) Vista lgica: el modelo de objetos del diseo, o un modelo correspondiente tal como un diagrama de relacin; (2) Vista de proceso: aspectos de concurrencia y sincronizacin; (3) Vista fsica: el mapeo del software en el hardware y sus aspectos distribuidos; (4) Vista de desarrollo: la organizacin esttica del software en su entorno de desarrollo. Esta segunda lista coincide con el modelo 4+1 de Kruchten, pero sin tanto nfasis en el quinto elemento.

Bass, Clements y Kazman presentan en 1998 una taxonoma de nueve vistas, decididamente

sesgadas hacia el diseo concreto y la implementacin: (1) Estructura de mdulo. Las unidades son asignaciones de tareas. (2) Estructura lgica o conceptual. Las unidades son abstracciones de los requerimientos funcionales del sistema. (3) Estructura de procesos o de coordinacin. Las unidades son procesos o threads. (4) Estructura fsica. (5) Estructura de uso. Las unidades son procedimientos o mdulos, vinculados por relaciones de presuncin-de-presencia-correcta. (6) Estructura de llamados. Las unidades son usualmente (sub)procedimientos, vinculados por invocaciones o llamados. (7) Flujo de datos. Las unidades son programas o mdulos, la relacin es de envo de datos. (8) Flujo de control; las unidades son programas, mdulos o estados del sistema. (9) Estructura de clases. Las unidades son objetos; las relaciones son hereda-de o es-una-instancia-de [BCK98]. De acuerdo con el punto de vista de la formulacin de estilos, la situacin de stos en este marco puede variar sustancialmente.

La recomendacin IEEE Std 1471-2000 procura establecer una base comn para la descripcin de

arquitecturas de software, e implementa para ello tres trminos bsicos, que son arquitectura, vista y punto de vista. La arquitectura se define como la organizacin fundamental de un sistema, encarnada en sus componentes, las relaciones entre ellos y con su entorno, y los principios que gobiernan su diseo y evolucin. Los elementos que resultan definitorios en la utilidad, costo y riesgo de un sistema son en ocasiones fsicos y otras veces lgicos. En otros casos ms, son principios permanentes o patrones que generan estructuras organizacionales duraderas. Trminos como vista o punto de vista son tambin centrales. En la recomendacin se los utiliza en un sentido ligeramente distinto al del uso comn. Aunque reflejan el uso establecido en los estndares y en la investigacin de ingeniera, el propsito del estndar es introducir un grado de formalizacin homogeneizando informalmente la

nomenclatura. En dicha nomenclatura, un punto de vista (viewpoint) define un patrn o plantilla (template) para representar un conjunto de incumbencias (concerns) relativo a una arquitectura, mientras que una vista (view) es la representacin concreta de un sistema en particular desde una perspectiva unitaria. Un punto de vista permite la formalizacin de grupos de modelos. Una vista tambin se compone de modelos, aunque posee tambin atributos adicionales. Los modelos proporcionan la descripcin especfica, o contenido, de una arquitectura. Por ejemplo, una vista estructural consistira de un conjunto de modelos de la estructura del sistema. Los elementos de tales modelos incluiran componentes identificables y sus interfaces, as como interconexiones entre los componentes. La concordancia entre la recomendacin de IEEE y el concepto de estilo se establece con claridad en trminos del llamado punto de vista estructural. Otros puntos de vista reconocidos en la recomendacin son el conductual y el de interconexin fsica. El punto de vista estructural ha sido motivado (afirman los redactores del estndar) por el trabajo en lenguajes de descripcin arquitectnica (ADLs). El punto de vista estructural, dicen, se ha desarrollado en el campo de la arquitectura de software desde 1994 y es hoy de amplio uso. Este punto de vista es a menudo implcito en la descripcin arquitectnica contempornea y de hecho ha decantado en el concepto de estilo, plena y expresamente reconocido por la IEEE. En cuanto a los patrones, la recomendacin de IEEE no ha especificado ninguna provisin respecto a principios de reutilizacin que constituyen la esencia del concepto de patrones. Ante tal circunstancia, Rich Hilliard, uno de sus redactores, propone extender el modelo en esa direccin [Hil01]. En un estudio sobre el particular, Hilliard ha analizado puntos de vista, estilos y patrones como tres modelos alternativos de descripcin del conocimiento arquitectnico [Hil01b].

La estrategia de arquitectura de Microsoft define, en consonancia con las conceptualizaciones ms

generalizadas, cuatro vistas, ocasionalmente llamadas tambin arquitecturas: Negocios, Aplicacin, Informacin y Tecnologa [Platt02]. La vista que aqu interesa es la de la aplicacin, que incluye, entre otras cosas: (1) Descripciones de servicios automatizados que dan soporte a los procesos de negocios; (2) descripciones de las interacciones e interdependencias (interfaces) de los sistemas aplicativos de la organizacin, y (3) planes para el desarrollo de nuevas aplicaciones y la revisin de las antiguas, basados en los objetivos de la empresa y la evolucin de las plataformas tecnolgicas. Cada arquitectura, a su vez, se articula en vistas tambin familiares desde los das de OMT que son (1) la Vista Conceptual, cercana a la semntica de negocios de los usuarios no tcnicos; (2) la Vista Lgica, que define los componentes funcionales y su relacin en el interior de un sistema, en base a la cual los arquitectos construyen modelos de aplicacin que representan la perspectiva lgica de la arquitectura de una aplicacin; (3) la Vista Fsica, que es la menos abstracta y que ilustra los componentes especficos de una implementacin y sus relaciones. En este marco global, los estilos pueden verse como una formulacin que, en la arquitectura de una aplicacin, orienta la configuracin de su vista

lgica. Este posicionamiento se refrenda en la relacin que Michael Platt establece a propsito de los patrones de aplicacin, la cual tambin coincide con el tratamiento que se ha dado histricamente a la relacin entre estilos y patrones [Platt02] [Shaw96] [MKM97] [Land02]. Zachman (Niveles) Scope Empresa Tecnologa Representacin Funcionamiento TOGAF 4+1 (Arquitecturas) (Vistas) Negocios Datos Tecnologa Lgica Proceso Fsica [BRJ99] (Vistas) Diseo Proceso POSA (Vistas) Lgica Proceso Desarrollo Microsoft (Vistas) Lgica Conceptual Fsica

Sistema lgico Aplicacin

Implementacin Fsica

Desarrollo Despliegue Casos de Casos de uso uso

Tabla 3 - Posiciones y vistas en los marcos de referencia

A excepcin del modelo RM-ODP, cuya naturaleza y objetivos no son comparables a las de las otras formulaciones, los grandes marcos se avienen a situarse en una grilla que define niveles, arquitecturas o vistas. Segn sea esttica o dinmicamente, sus posiciones representan las perspectivas conceptuales o los momentos de materializacin del proceso de desarrollo de un sistema, tal como se refleja en la tabla 3. En la misma se han sombreado las perspectivas desde las cuales la problemtica de los estilos y patrones arquitectnicos se perciben con mayor claridad o se presentan con mayor pertinencia. Con la excepcin de los casos de uso, que en realidad se superponen a las otras vistas, podra decirse que hacia arriba de la regin sombreada se encuentra la perspectiva de usuarios, negocios y empresas de los que surge el requerimiento, y hacia abajo la regin de los patrones de diseo y el cdigo de los que resulta la implementacin.

Un escenario tan complejo y una historia tan prdiga en incidentes como las de la ingeniera y la arquitectura de software podran articularse tambin segn otras narrativas. Hacia 1992, por ejemplo, Joseph Goguen, del Laboratorio de Computacin de la Universidad de Oxford, estimaba que el desarrollo de sistemas hasta aquel entonces se haba desplegado en dos campos, que l llamaba el Hmedo y el Seco [Gog92]. El campo Hmedo est dominado fundamentalmente por la mentalidad del hacker: el desarrollador de sistemas desea crear un sistema lo ms rpido posible y para ello utiliza tantos principios heursticos de diseo como pueda conseguir para alcanzar el objetivo. El sistema puede o no quedar documentado en el proceso. Si el sistema funciona, a la larga, ello es porque no est desarrollado segn un proceso al azar, sino que se han utilizado patrones heursticos de diseo, basados en experiencias previas y ancdotas que fueron pasando de un programador a otro. Salvando las distancias, la definicin de Goguen de la mentalidad seca parece una descripcin anticipada de lo que despus sera el espritu de al menos algunas de las facciones de la programacin gil, la misma que ha hecho que Martin Fowler se preguntara Is design dead? [Fow01].

El campo de desarrollo alternativo es el de la comunidad Seca, en el que slo se utilizan metodologas formales. Estos principios de diseo se han propagado merced a la iniciativa de los que Ince [Ince88] llama nuevos puritanos matemticos. Aunque un observador externo podra juzgar que los diseos fundados matemticamente son difciles de expresar y de interpretar en un primer examen, un estudio ms detallado revela que no son slo piezas arbitrarias de especificacin matemtica, sino que de hecho se atienen a ciertos patrones de diseo. El objetivo de la investigacin en estilos arquitectnicos ha sido vincular las dos metodologas en trminos de sus principios de diseo, por una parte heursticos y por la otra formales, constituyendo una estrategia que permita un diseo slido, correcto y riguroso y que facilite mejor verificacin y validacin. Ejemplos tempranos de esta convergencia entre principios secos y hmedos son los principios de diseo sentados por investigadores como Jackson, Storer y otros ms, que desde mediados de la dcada de 1980 identificaron una serie de reglas para construir diseos estructurados a partir de las piezas de construccin (building blocks) de programas, tales como secuencias de instruccin, seleccin e iteracin. Estos y otros principios de diseo han decantado en la investigacin que finalmente condujo a la arquitectura de software y a los estilos arquitectnicos tal como se los conoce hoy en da.

Arriba

Estilos y patrones

La dinmica incontenible de la produccin de patrones en la prctica de la arquitectura de software, su carcter entusiasta, cuando no militante, y la profusin de sus manifestaciones han atenuado la idea de que los patrones de diseo constituyen slo uno de los paradigmas, marcos o formas del diseo arquitectnico, cada uno de los cuales posee una historia y una fundamentacin distinta, y presenta, como todas las cosas en este terreno, sus sesgos, sus beneficios y sus limitaciones. Todo el mundo acepta que existen diversas clases de patrones: de anlisis, de arquitectura (divididos en progresivamente estructurales, sistemas distribuidos, sistemas interactivos, sistemas adaptables), de diseo (conductuales, creacionales, estructurales), de organizacin o proceso, de programacin y los llamados idiomas, entre otros. Cada autor que escribe sobre el asunto agrega una clase diferente, y los estndares en vigencia no hacen ningn esfuerzo para poner un lmite a la proliferacin de variedades y ejemplares. Como sea, concentrmonos inicialmente en los patrones de diseo.

Un patrn de diseo, obviamente, debe encajar por un lado con otros tipos de patrones imaginables y por el otro con la teora, la prctica y los marcos que en general rigen el diseo. Cules son las grandes estrategias de diseo, si puede saberse? Una vez ms, cuando llega el momento de disponer en un mapa las

estrategias, los marcos de referencia o los paradigmas de diseo disponibles se encuentra multitud de propuestas clasificatorias que a veces no coinciden siquiera en la identificacin de la disciplina en que se formulan. De todas maneras, estimo que es razonable pensar que las estrategias mayores de diseo pueden subsumirse en un conjunto relativamente manejable de cuatro o cinco tipos, uno de los cuales es, precisamente, el diseo orientado por patrones. Estas estrategias no necesariamente son excluyentes y antagnicas, pero se encuentran bastante bien delimitadas en la literatura usual [Tek00].

1. Diseo arquitectnico basado en artefactos. Incluira modalidades bien conocidas de diseo

orientado a objetos, tales como el OMT de Rumbaugh [RBP+91] y el OAT de Booch [Boo91]. En OMT, que puede considerarse representativo de la clase, la metodologa de diseo se divide en tres fases, que son Anlisis, Diseo del Sistema y Diseo de Objetos. En la fase de anlisis se aplican tres tcnicas de modelado que son modelado de objetos, modelado dinmico y modelado funcional. En la fase de diseo de sistema tienen especial papel lo que Rumbaugh llama implementacin de control de software y la adopcin de un marco de referencia arquitectnico, punto en el que se reconoce la existencia de varios prototipos que permiten ahorrar esfuerzos o se pueden tomar como puntos de partida. Algunos de esos marcos de referencia se refieren con nombres tales como transformaciones por lotes, transformaciones continuas, interfaz interactiva, simulacin dinmica, sistema en tiempo real y administrador de transacciones [RBP+91:211-216]. No cuesta mucho encontrar la analoga entre dichos marcos y los estilos arquitectnicos, concepto que en esa poca todava no haba hecho su aparicin. En el sealamiento de las ventajas del uso de un marco preexistente tambin puede verse un reflejo de la idea de patrn, una categora que no aparece jams en todo el marco de la OMT, aunque ya haba sido propuesta por el arquitecto britnico Christopher Alexander varios aos antes, en 1977 [Ale77].

2. Diseo arquitectnico basado en casos de uso. Un caso de uso se define como una secuencia de
acciones que el sistema proporciona para los actores [JBR99]. Los actores representan roles externos con los que el sistema debe interactuar. Los actores, junto con los casos de uso, forman el modelo de casos de uso. Este se define como un modelo de las funciones que deber cumplir el sistema y de su entorno, y sirve como una especie de contrato entre el cliente y los desarrolladores. El Proceso Unificado de Jacobson, Booch y Rumbaugh [JBR99] aplica una arquitectura orientada por casos de uso. El PU consiste en core workflows que definen el contenido esttico del proceso y describen el proceso en trminos de actividades, operadores (workers) y artefactos. La organizacin del proceso en el tiempo se define en fases. El PU se compone de seis de estos workflows: Modelado de Negocios, Requerimientos, Anlisis, Diseo, Implementacin y Prueba. Estos diagramas de flujo resultan en los siguientes modelos separados: modelo de negocio & dominio, modelo de caso de uso, modelo de anlisis, modelo de diseo, modelo de implementacin y modelo de prueba. De acuerdo con el punto de vista, el concepto de estilo puede caer en diversas coordenadas del modelo, en las cercanas de las fases y los modelos de anlisis y diseo. La oportunidad es propicia para subrayar que mientras el concepto de patrn responde con naturalidad a un diseo orientado a objetos, el de estilo arquitectnico posee un carcter estructural diferente y es de hecho un recin llegado al mundo del modelado O-O. La estrategia de diseo basada en casos de uso, dominada ampliamente por la orientacin a objetos (tantos en los modelos de alto nivel como en la implementacin) y por notaciones ligadas a UML, est experimentando recin en estos das reformulaciones y extensiones a fin de acomodarse a configuraciones arquitectnicas que no estn estrictamente articuladas como objetos (basadas en servicios, por ejemplo), as como a conceptos de descripcin arquitectnica y estilos [Hil99] [St01] [GP02] [Har03].

3. Diseo arquitectnico basado en lnea de producto. Comprende un conjunto de productos que

comparten una coleccin de rasgos que satisfacen las necesidades de un determinado mercado o rea de actividad. Esta modalidad ha sido impulsada y definida sobre todo por Clements, Northrop, Bass y Kazman [CN96] [BCK98]. En la estrategia de arquitectura de Microsoft, este modelo est soportado por un profuso conjunto de lineamientos, herramientas y patrones arquitectnicos especficos, incluyendo patrones y modelos .NET para aplicaciones de lnea de negocios, modelos aplicativos en capas como arquitecturas de referencia para industrias, etctera [http://www.microsoft.com/resources/practices/].

4. Diseo arquitectnico basado en dominios. Considerado una extensin del anterior, se origina en
una fase de anlisis de dominio que, segn Prieto-Daz y Arango, puede ser definido como la identificacin, la captura y la organizacin del conocimiento sobre el dominio del problema, con el

objeto de hacerlo reutilizable en la creacin de nuevos sistemas [PA91]. El modelo del dominio se puede representar mediante distintas formas de representacin bien conocidas en ingeniera del conocimiento, tales como clases, diagramas de entidad-relacin, frames, redes semnticas y reglas. Se han publicado diversos mtodos de anlisis de dominio [Gom92], [KCH+90], [PA91], [SCK+96] y [Cza99]. Se han realizado diversos surveys de estos mtodos, como [Arr94] y [WP92]. En [Cza98] se puede encontrar una referencia completa y relativamente actualizada de los mtodos de ingeniera de dominios. Relacionado con este paradigma se encuentra la llamada arquitectura de software especfica de dominio (DSSA) [HR4] [TC92]. DSSA se puede considerar como una arquitectura de mltiples scopes, que deriva una descripcin arquitectnica para una familia de sistemas antes que para un solo sistema. Los artefactos bsicos de una estrategia DSSA son el modelo de dominio, los requerimientos de referencia y la arquitectura de referencia. El mtodo comienza con una fase de anlisis del dominio sobre un conjunto de aplicaciones con problemas o funciones comunes. El anlisis se basa en escenarios, a partir de los cuales se derivan requerimientos funcionales, informacin de flujo de datos y de flujo de control. El modelo de dominio incluye escenarios, el diccionario de dominio, los diagramas de bloque de contexto, los diagramas ER, los modelos de flujo de datos, los diagramas de transicin de estado y los modelos de objeto. En la prxima versin mayor de Visual Studio.NET (Whidbey), Microsoft incluir, al lado de los lenguajes convencionales de propsito general, un conjunto de lenguajes especficos de dominio (DSL), tales como Business Process DSL, Web Service Interaction DSL, Business Entity DSL y Logical Systems Architecture DSL. Esos lenguajes de alto nivel, mayormente grficos, han sido anticipados por Keith Short [Sho03] en un documento reciente.

5. Diseo arquitectnico basado en patrones. Las ideas del mitolgico pionero Christopher Alexander

[Ale77] sobre lenguajes de patrones han sido masivamente adoptadas y han conducido a la actual efervescencia por los patrones de diseo, sobre todo a partir del impulso que le confirieron las propuestas de la llamada Banda de los Cuatro: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides [GoF95]. Similares a los patrones de Alexander, los patrones de diseo de software propuestos por la Banda buscan codificar y hacer reutilizables un conjunto de principios a fin de disear aplicaciones de alta calidad. Los patrones de diseo se aplican en principio slo en la fase de diseo, aunque a la larga la comunidad ha comenzado a definir y aplicar patrones en las otras etapas del proceso de desarrollo, desde la concepcin arquitectnica inicial hasta la implementacin del cdigo. Se han definido, por ejemplo, lenguas o idiomas (idioms) en la fase de implementacin [Cop92] que mapean diseos orientados a objeto sobre constructos de lenguaje orientado a objeto. Otros autores han aplicado patrones en la fase de anlisis para derivar modelos analticos [Fow96]. Finalmente (y esto es lo que ms interesa en nuestro contexto), los estilos se han aplicado en la fase de anlisis arquitectnico en trminos de patrones de arquitectura [BMR+96]. Estos patrones de arquitectura son similares a los patrones de diseo pero se concentran en la estructura de alto nivel del sistema. Algunos autores sienten que estos patrones arquitectnicos son virtualmente lo mismo que los estilos [Shaw94] [SG95], aunque est claro que ocurren en diferentes momentos del ciclo corresponden a distintos niveles de abstraccin.

Los patrones abundan en un orden de magnitud de tres dgitos, llegando a cuatro, y gana ms puntos quien ms variedades enumera; los sub-estilos se han congelado alrededor de la veintena agrupados en cinco o seis estilos mayores, y se considera mejor terico a quien los subsume en el orden ms simple. An cuando los foros de discusin abundan en pullas de los acadmicos por el desorden proliferante de los patrones y en quejas de los implementadores por la naturaleza abstracta de los estilos, desde muy temprano hay claras convergencias entre ambos conceptos, an cuando se reconoce que los patrones se refieren ms bien a prcticas de re-utilizacin y los estilos conciernen a teoras sobre la estructuras de los sistemas a veces ms formales que concretas. Algunas formulaciones que describen patrones pueden leerse como si se refirieran a estilos, y tambin viceversa. Escribe Alexander, en su peculiar lenguaje aforstico:

Como un elemento en el mundo, cada patrn es una relacin entre cierto contexto, cierto sistema de fuerzas que ocurre repetidas veces en ese contexto y cierta configuracin espacial que permite que esas fuerzas se resuelvan. Como un elemento de lenguaje, un patrn es una instruccin que muestra la forma en que esta configuracin espacial puede usarse, una y otra vez, para resolver ese sistema de fuerzas, donde quiera que

el contexto la torne relevante El patrn es, en suma, al mismo tiempo una cosa que pasa en el mundo y la regla que nos dice cmo crear esa cosa y cundo debemos crearla. Es tanto un proceso como una cosa; tanto una descripcin de una cosa que est viva como una descripcin del proceso que generar esa cosa.

Casi un cuarto de siglo ms tarde, Roy Fielding [Fie00] reconoce que los patrones de Alexander tienen ms en comn con los estilos que con los patrones de diseo de la investigacin en OOPL. Las definiciones relacionadas con los patrones y las prcticas son diversas, y no he podido encontrar (excepto en la literatura derivativa) dos caracterizaciones que reconozcan las mismas clases o que se sirva de una terminologa estable.

Un protagonista de primera lnea en el revuelo que se ha suscitado en torno de los patrones es el texto de Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal Pattern-oriented software architecture (POSA). En l los patrones arquitectnicos son aproximadamente lo mismo que lo que se acostumbra definir como estilos y ambos trminos se usan de manera indistinta. En POSA los patrones expresan un esquema de organizacin estructural para los sistemas de software. Proporcionan un conjunto de subsistemas predefinidos, especifica sus responsabilidades e incluye reglas y lineamientos para organizar la relacin entre ellos. Algunos patrones coinciden con los estilos hasta en el nombre con que se los designa. Escriben los autores: El patrn arquitectnico de tubera-filtros proporciona una estructura para sistemas que procesan un flujo de datos. Cada paso del procesamiento est encapsulado en un componente de filtro. El dato pasa a travs de la tubera entre los filtros adyacentes. La recombinacin de filtros permite construir familias de sistemas interrelacionados [BMR+96: 53]. Tipo de Patrn Fase de Desarrollo

Comentario

Problemas

Soluciones

Problemas Relacionados a arquitectnicos, la interaccin adaptabilidad a Patrones de de objetos requerimientos Arquitectura dentro o entre cambiantes, niveles performance, arquitectnicos modularidad, acoplamiento Conceptos de ciencia de Patrones de computacin Diseo en general, independiente de aplicacin Patrones de Usualmente Anlisis especficos de aplicacin o industria Claridad de diseo, multiplicacin de clases, adaptabilidad a requerimientos cambiantes, etc Modelado del dominio, completitud, integracin y

Patrones de llamadas entre objetos (similar a los patrones de diseo), Diseo inicial decisiones y criterios arquitectnicos, empaquetado de funcionalidad Comportamiento de factora, ClaseDiseo detallado ResponsabilidadContrato (CRC) Modelos de dominio, conocimiento sobre lo que Anlisis

equilibrio de objetivos mltiples, planeamiento para capacidades adicionales comunes Desarrollo o procesos de Productividad, Patrones de administracin comunicacin Proceso o de de proyectos, o efectiva y Organizacin tcnicas, o eficiente estructuras de organizacin

habr de incluirse (p. ej. logging & reinicio)

Armado de equipo, ciclo de vida del software, asignacin de Planeamiento roles, prescripciones de comunicacin

Idiomas

Operaciones comunes bien conocidas en un Sumamente Estndares de nuevo especficos de un codificacin y ambiente, o a lenguaje, proyecto travs de un plataforma o grupo. ambiente Legibilidad, predictibilidad.

Implementacin, Mantemimiento, Despliegue

Tabla 4 - Taxonoma (parcial) de patrones [Sar00]

Mientras en POSA y en la mayora de los textos de la especialidad el vnculo que se establece con mayor frecuencia es entre estilos y patrones de arquitectura, Robert Monroe, Andrew Kompanek, Ralph Melton y David Garlan exploran ms bien la estrecha relacin entre estilos y patrones de diseo [MKM+97]. En primer lugar, siguiendo a Mary Shaw [Shaw96], estiman que los estilos se pueden comprender como clases de patrones, o tal vez ms adecuadamente como lenguajes de patrones. Un estilo proporciona de este modo un lenguaje de diseo con un vocabulario y un framework a partir de los cuales los arquitectos pueden construir patrones de diseo para resolver problemas especficos. Los estilos se vinculan adems con conjuntos de usos idiomticos o patrones de arquitectura que ofician como microarquitecturas; a partir de ellas es fcil derivar patrones de diseo. Lo mismo se aplica cuando un patrn de diseo debe coordinar diversos principios que se originan en ms de un estilo de arquitectura. Sea cual fuere el caso, los estilos se comprenden mejor afirma Monroe como un lenguaje para construir patrones (anlogo a las metodologas OO como OMT) y no como una variante peculiar de patrones de diseo, como pretenden Gamma y sus colegas. Aunque los aspectos de diseo involucrados en estilos, patrones y modelos de objeto se superponen en algunos respectos, ninguno envuelve por completo a los dems; cada uno tiene algo que ofrecer, bajo la forma de colecciones de modelos y de mecanismos de representacin.

Al lado de las propuestas meta-estilsticas que hemos visto, puede apreciarse que toda vez que surge la pregunta de qu hacer con los estilos, de inmediato aparece una respuesta que apunta para el lado de las prcticas y los patrones. Podra decirse que mientras los estilos han enfatizado descriptivamente las configuraciones de una arquitectura, desarrollando incluso lenguajes y notaciones capaces de expresarlas

formalmente, los patrones, an los que se han caracterizado como arquitectnicos, se encuentran ms ligados al uso y ms cerca del plano fsico, sin disponer todava de un lenguaje de especificacin y sin estar acomodados (segn lo testimonian innumerables talleres de OOPSLA y otros similares) en una taxonoma que ordene razonablemente sus clases y en un mapa que los site inequvocamente en la trama de los grandes marcos de referencia. Aunque todava no se ha consensuado una taxonoma unificada de estilos, ellos ayudarn, sin duda, a establecer y organizar los contextos en que se implementen los patrones.

En cuanto a los patrones de arquitectura, su relacin con los estilos arquitectnicos es perceptible, pero indirecta y variable incluso dentro de la obra de un mismo autor. En 1996, Mary Shaw bosquej algunos patrones arquitectnicos que se asemejan parcialmente a algunos estilos delineados por ella misma con anterioridad, pero no explora la relacin de derivacin o composicin entre ambos conceptos. En esta oportunidad, un patrn arquitectnico se define por (1) un modelo de sistema que captura intuitivamente la forma en que estn integrados los elementos; (2) componentes; (3) conectores que establecen las reglas de la interaccin entre los componentes; y (4) una estructura de control que gobierna la ejecucin. Entre los patrones referidos de este modo se encuentran la lnea de tubera (pipeline), el patrn arquitectnico de abstraccin de datos, los procesos comunicantes a travs de mensajes, los sistemas de invocacin implcita, los repositorios, los intrpretes, programa principal/subrutinas y sistemas en capas [Shaw96]. A pesar que muchos de sus ejemplos de referencia remiten a la literatura sobre estilos, la palabra estilo no figura en todo el cuerpo del documento. Generalmente se reconoce que se trata de una misma idea bsica reformulada con una organizacin ligeramente distinta [Now99].

Robert Allen [All97] sostiene que los patrones son similares a los estilos en la medida en que definen una familia de sistemas de software que comparte caractersticas comunes, pero tambin seala que difieren en dos importantes respectos. En primer lugar, un estilo representa especficamente una familia arquitectnica, construida a partir de bloques de construccin arquitectnicos, tales como los componentes y los conectores. Los patrones, en cambio, atraviesan diferentes niveles de abstraccin y etapas del ciclo de vida partiendo del anlisis del dominio, pasando por la arquitectura de software y yendo hacia abajo hasta el nivel de los lenguajes de programacin. En segundo lugar, la comunidad que promueve los patrones se ha concentrado, hasta la fecha, en el problema de vincular soluciones con contextos de problemas y en definir cmo seleccionar los patrones apropiados, ms que en la descripcin y anlisis de soluciones prospectivas. Por esta razn, los patrones se basan en presentaciones informales en estilo de libro de texto de familias de sistemas, ms que en representaciones de sistemas precisas y semnticamente ricas. Asimismo, los patrones de interaccin tpicamente se dejan implcitos en el patrn de composicin del sistema, en vez de ser tratados como conceptos dignos de ser tratados en sus propios trminos.

En [SC96] Mary Shaw y Paul Clements proponen una cuidadosa discriminacin entre los estilos

arquitectnicos existentes, seguida de una gua de diseo que oriente sobre la forma de escoger el estilo apropiado en un proyecto, dado que cada uno de ellos es apropiado para ciertas clases de problemas, pero no para otras. Para llevar a cabo su propsito, establecen una estrategia de clasificacin bidimensional considerando por un lado variables de control y por el otro cuestiones relativas a datos como los dos ejes organizadores dominantes. Una vez hecho esto, sitan los estilos mayores dentro del cuadro y luego utilizan discriminaciones de grano ms fino para elaborar variaciones de los estilos. Esta operacin proporciona un framework para organizar una gua de diseo, que parcialmente nutren con recetas de cocina (rules of thumb). Est muy claro en este discurso el intento de derivar cnones de uso conducentes a lo que hoy se conoce como patrones, lo cual es explcito a lo largo del estudio. Su objetivo es derivar orientaciones pragmticas a partir de las particularidades estilsticas. Incluyo una versin ligeramente alterada de las recetas de Shaw y Clements no para su uso heurstico, sino para ilustrar la modalidad de razonamiento y su convergencia con la literatura de prcticas.

Si su problema puede ser descompuesto en etapas sucesivas, considere el estilo secuencial por

lotes o las arquitecturas en tubera.

Si adems cada etapa es incremental, de modo que las etapas posteriores pueden comenzar antes

que las anteriores finalizen, considere una arquitectura en tubera.

Si su problema involucra transformaciones sobre continuos flujos de datos (o sobre flujos muy

prolongados), considere una arquitectura en tuberas.

Sin embargo, si su problema involucra el traspaso de ricas representaciones de datos, evite lneas

de tubera restringidas a ASCII.

Si son centrales la comprensin de los datos de la aplicacin, su manejo y su representacin,

considere una arquitectura de repositorio o de tipo de dato abstracto. Si los datos son perdurables, concntrese en repositorios.

Si es posible que la representacin de los datos cambie a lo largo del tiempo de vida del programa,

entonces los tipos de datos abstractos pueden confinar el cambio en el interior de componentes particulares.

Si est considerando repositorios y los datos de entrada son ruidosos (baja relacin seal-ruido) y

el orden de ejecucin no puede determinarse a priori, considere una pizarra [Nii86].

Si est considerando repositorios y el orden de ejecucin est determinado por un flujo de

requerimientos entrantes y los datos estn altamente estructurados, considere un sistema de gestin de base de datos.

Si su sistema involucra continua accin de control, est embebido en un sistema fsico y est sujeto

a perturbaciones externas impredecibles de modo que los algoritmos prestablecidos se tornan ineficientes, considere una arquitectura de bucle cerrado de control [Shaw95a].

Si ha diseado una computacin pero no dispone de una mquina en la que pueda ejecutarla,

considere una arquitectura de intrprete.

Si su tarea requiere un alto grado de flexibilidad/configurabilidad, acoplamiento laxo entre tareas y

tareas reactivas, considere procesos interactivos.

Si tiene motivos para no vincular receptores de seales con sus originadores, considere una

arquitectura de eventos.

Si las tareas son de naturaleza jerrquica, considere un worker replicado o un estilo de pulsacin

(heartbeat).

Si las tareas estn divididas entre productores y consumidores, considere cliente/servidor. Si tiene sentido que todas las tareas se comuniquen mutuamente en un grafo totalmente conexo,

considere un estilo de token passing.

Kazman y Klein consideran que los estilos arquitectnicos son artefactos de ingeniera importantes porque definen clases de diseo, junto con sus propiedades conocidas. Ofrecen evidencia basada en la experiencia sobre cmo se ha utilizado cada clase histricamente, junto con razonamiento cualitativo para explicar por qu cada clase posee propiedades especficas. Usar el estilo tubera-filtros cuando se desea reutilizacin y la performance no es una prioridad cardinal es un ejemplo del tipo de descripcin que se encuentra en las definiciones de ese estilo. Los estilos son entonces una poderosa herramienta para el reutilizador porque proporcionan una sabidura decantada por muchos diseadores precedentes que afrontaron problemas similares. El arquitecto puede echar mano de esa experiencia de la misma forma en que los patrones de diseo orientados a objeto dan a los ms novicios acceso a una vasta fuente de experiencia elaborada por la comunidad de diseo orientada a objetos [Gof95].

Arriba

Los estilos como valor contable

Un segmento importante de los estudios relativos a estilos se abocan a examinar su relacin con los lenguajes de descripcin de arquitecturas, que hemos examinado en un documento aparte [SC96] [Rey04b]. De hecho, los ms importantes estudios comparativos de ADLs consideran que la capacidad de expresar un

estilo es definitoria entre las prestaciones de estos lenguajes [CI96]. En [AAG95] Gregory Abowd, Robert Allen y David Garlan proponen un framework formal para la definicin de los estilos arquitectnicos que permita realizar anlisis dentro de un estilo determinado y entre los diferentes estilos. Pero la pregunta que cabe formularse en un estudio como el presente es no tanto qu pueden hacer los arquitectos a propsito de los estilos, sino cul es la utilidad de stos, no ya para la arquitectura de software como un fin en s misma, o como un logro sintctico-semntico para la consolidacin de una nomenclatura, sino en relacin con los fines pragmticos a los que esta disciplina emergente debe servir.

David Garlan [Gar95] [GKM+96] define en primer lugar cuatro aspectos salientes de los estilos arquitectnicos de los que todo modelo debe dar cuenta: proporcionar un vocabulario de elementos de diseo, establecer reglas de composicin, definir una clara interpretacin semntica y los anlisis de consistencia y adecuacin que pueden practicarse sobre l . Luego de ello caracteriza tres formas de comprender un estilo:

1. Estilo como lenguaje. En esta perspectiva, un vocabulario estilstico de diseo se modela como un

conjunto de producciones gramaticales. Las reglas de configuracin se definen como reglas de una gramtica independientes del contexto o sensitivas a l. Se puede entonces asignar una interpretacin semntica usando cualquiera de las tcnicas estndar para asignar significado a los lenguajes. Los anlisis seran los que se pueden ejecutar sobre programas arquitectnicos: verificar satisfaccin de reglas gramaticales, anlisis de flujo, compilacin, etctera. Caracterstica de esta perspectiva es la elaboracin de Aboud, Allen y Garlan [AAG93], donde un estilo se percibe como una semntica denotacional para los diagramas de arquitectura.

2. Estilo como sistema de tipos. En esta perspectiva el vocabulario arquitectnico se define como un
conjunto de tipos. Por ejemplo, un estilo de tubera y filtros define tipos como filtros y tuberas. Si se especifica en un contexto orientado a objetos, son posibles las definiciones jerrquicas: filtro sera una subclase de un componente ms genrico, y tubera una subclase de un conector. Se pueden mantener restricciones sobre estos tipos como invariantes de los tipos de datos, realizadas operacionalmente en el cdigo de los procedimientos que pueden modificar las instancias de los tipos. De all en ms, el anlisis puede explotar el sistema de tipos, ejecutar verificacin de tipo y otras manipulaciones arquitectnicas que dependen de los tipos involucrados.

3. Estilo como teora. En esta perspectiva, un estilo se define como un conjunto de axiomas y reglas

de inferencia. El vocabulario no se representa directamente, sino en trminos de las propiedades lgicas de los elementos. Por ejemplo, el hecho de que un componente arquitectnico sea un filtro permitira deducir que sus puertos son o bien de entrada o bien de salida. De la misma manera, el hecho de que algo sea una tubera permite deducir que posee dos extremos, uno para lectura y el otro para escritura. Las restricciones de configuracin se definen como axiomas adicionales. El anlisis tiene lugar mediante la prueba de un nuevo teorema que extiende la teora de dicho estilo. Representativo de esta estrategia es el trabajo de Mark Moriconi y sus colegas [MQ94, MQR95].

Ms all de los matices que aporta cada mirada, es constante la referencia a los estilos como facilitadores del proceso de reutilizacin. Para David Garlan, Andrew Kompanek, Ralph Melton y Robert Monroe, los diseadores de sistemas reconocen cada vez con ms frecuencia la importancia de explotar el conocimiento de diseo en la ingeniera de un nuevo sistema. Una forma de hacerlo es definir un estilo arquitectnico. Antes que llegue el momento de pensar en patrones ms cercanos a lo que ha de suceder en la mquina, el estilo determina un vocabulario coherente de elementos de diseo y reglas para su composicin. Estructur el

espacio de diseo para una familia relacionada en un estilo puede, en principio, simplificar drsticamente el proceso de construccin de un sistema, reducir costos de implementacin a travs de una infraestructura reutilizable y mejorar la integridad del sistema a travs de anlisis y verificaciones especficas del estilo [GKM+96]. Precisando un poco ms la idea, los autores enumeran elocuentes ventajas del mtodo: 1. Los estilos promueven reutilizacin de diseo. Las soluciones de rutina con propiedades bien entendidas se pueden aplicar otra vez a nuevos problemas con alguna confianza. 2. El uso de estilos puede conducir a una significativa reutilizacin de cdigo. Los aspectos invariantes de un estilo conduce a replicar implementaciones. Por ejemplo, se pueden usar primitivas de un sistema tubera-filtros para manejar tareas semejantes de agendado de tareas, sincronizacin y comunicacin a travs de tuberas, o un sistema cliente-servidor puede tomar ventaja de mecanismos de RPC preexistentes y de capacidades de generacin de stub. 3. Es ms fcil para otros entender la organizacin de un sistema si se utilizan estructuras convencionales. Por ejemplo, la tipificacin de un sistema como cliente-servidor de inmediato evoca una fuerte imagen respecto a cuales son sus piezas y cmo se vinculan recprocamente. 4. El uso de estilos estandarizados sustenta la interoperabilidad. Por ejemplo, el protocolo de pila del modelo OSI para arquitecturas en red, o los estndares de XML y SOAP para intercambios de mensaje en arquitecturas orientadas a servicios. 5. Al acotar el espacio de diseo, un estilo arquitectnico permite de inmediato anlisis especializados especficos del estilo. Por ejemplo, se pueden utilizar herramientas ya probadas para un estilo tuberafiltros para determinar la capacidad, la latencia y la ausencia de abrazos mortales. Esos anlisis no estaran disponibles si el sistema fuera categorizado de una manera ad hoc, o si se implementara otro estilo. 6. Es usualmente posible, e incluso deseable, proporcionar visualizaciones especficas de un estilo. Esto proporciona representaciones grficas y textuales que coinciden con intuiciones especficas de dominio sobre cmo deben representarse los diseos en l [GKM+96].

La misma idea es expresada en forma parecida por Nenan Medvidovic. En su opinin, la investigacin en arquitectura de software se orienta a reducir costos de desarrollo de aplicaciones y aumentar el potencial para la comunalidad entre diferentes miembros de una familia estrechamente relacionada de productos. Un aspecto de esta investigacin es el desarrollo de estilos de arquitectura de software, formas cannicas de organizar los componentes en una familia de estilos. Tpicamente, los estilos reflejan y explotan propiedades clave de uno o ms dominios de aplicaciones y patrones recurrentes de diseo de aplicaciones dentro de ese dominio. Como tales, los estilos arquitectnicos poseen potencial para proporcionar una estructura prearmada, salida de la caja, de reutilizacin de componentes [MT97].

Un concepto complementario es el de discordancia arquitectnica (architectural mismatch), que describe conflictos de interoperabilidad susceptibles de encontrarse en el plano arquitectnico, anticipndose a su manifestacin en las fases de diseo o implementacin. Ha sido acuado por David Garlan, Robert Allen y John Ockerbloom [GAO95] y refrendado por Ahmed Abd-Allah [Abd96] y Ramesh Sitaraman [Sit97] en el contexto de estudios de casos utilizando Aesop; pero si bien la idea es de manifiesta utilidad, no ha sido generalizada al conjunto de estilos ni se ha generado una teora acabada de composicin o prediccin arquitectnica, sealndose que para ello se requiere ulterior investigacin [KGP+99] [MM04].

Todos estos nuevos conceptos y exploraciones, por ms preliminares que sean, son por cierto muy provechosos. All donde existan lenguajes formales para la especificacin rigurosa de estilos, la cosa tendr adems cierta respetabilidad cientfica. Pero si bien la literatura usual exalta la conveniencia de pensar en trminos tericos de estilo como algo que tendr incidencia en las estructuras de las prcticas ulteriores, se han hecho muy pocas evaluaciones de las relaciones entre las arquitecturas beneficiadas por la aplicacin de la idea de estilo (o cualesquiera otros conceptos estructurales) con factores sistemticos de beneficio, variables de negocios, calidad de gestin operacional, fidelidad al requerimiento, multiplicacin de eficiencia, satisfaccin del cliente, valor agregado, time to market, ahorro de mantenimiento y guarismos de TCO o retorno de inversin. La pregunta clave es: Valen los estilos lo que cuestan? Se ha valorizado el tradeoff entre la reusabilidad que se goza en el momento de diseo y la inusabilidad por saturacin de ancho de banda (o por otras razones bien conocidas) en que podra llegar a traducirse? [Kru92] [Big94] [GAO95] [Shaw95b] Alcanza con admitir o advertir sobre eventuales desventajas sin proporcionar mtricas exhaustivas, modelos rigurosos de comparacin, benchmarks? Alcanza con evaluar la performance de distintos ADLs que slo prueban la eficiencia del modelo arquitectnico abstracto, sin medir la resultante de aplicar un estilo en lugar de otro (o de ninguno) en una solucin final?

Un problema adicional es que distintos patrones presuponen diferentes metodologas de diseo. Las arquitecturas de llamada y retorno, por ejemplo, se asocian histricamente a estructuras de programas y jerarquas de control que a su vez se vinculan a notaciones especficas, como los diagramas de Warnier-Orr o los diagramas de Jackson, elaboradas en la dcada de 1970. Es bien sabido que las arquitecturas orientadas a objetos requieren otras metodologas, y lo mismo se aplica a los estilos modulares orientados a componentes [Pre02: 226-233]. Hay toda una variedad de mtodos de diseo, con literaturas y herramientas especficas: Hipo II, OOD (incluyendo RUP), cleanroom, Gist, Leonardo, KBSA. Hay otro conjunto parecido que versa sobre modelos de proceso: lineal-secuencial, de prototipos, RAD, incremental, en espiral, win-win, de desarrollo concurrente, basado en componentes, PSP, CMM, CMMI. ltimamente ha surgido un conjunto de mtodos autodenominados giles en relacin confusa con todo el campo: eXtreme Programming, Scrum, Crystal Methods, Lean Development, Feature Driven Development, Agile Modeling y una formalizacin gil de RAD, Dynamic System Development Method [CLC02].

Ni hablar de tcnicas de prototipado, modelos de ciclo de vida e ingeniera de requerimientos, que se han constituido en ciencias aparte. Ninguno de estos mtodos y procesos, complejamente relacionados entre s, se ha estudiado en relacin con factores estilsticos, como si la decisin de escoger un estilo sobre otro no tuviera consecuencias metodolgicas. El estado de arte de la tipificacin de mtodos de diseo de DACS, por ejemplo, se remonta a una poca anterior a la consolidacin de la arquitectura basada en estilos y al surgimiento de los patrones. Los textos sobre estilos, con las excepciones anotadas, suelen ser silenciosos

sobre cuestiones ingenieriles, sean ellas clsicas o posmodernas. Mientras los mtodos giles suelen ser locuaces respecto del uso de patrones, son en cambio reticentes en lo que concierne a arquitectura en general y estilos en particular; y tambin viceversa.

En el viejo modelado con OMT el requerimiento del usuario penetraba en la semntica y la estructura del modelo hasta bien consumada la fase analtica del ciclo de diseo y el usuario deba comprender, cuando no homologar, las conclusiones del anlisis. En contraste, da la impresin que los estilos aparecen demasiado pronto en el ciclo, a un nivel de abstraccin que es demasiado alto para llegar a impactar en el cdigo, pero que ya en nada se asemeja a lo que el usuario piensa. La respuesta a estas y otras inquietudes que circulan en foros y listas de inters pero que pocos transportan a libros y ponencias, es que el sentido comn dicta que los estilos pueden ser beneficiosos, que deben serlo, aunque taxativamente no se sabe a ciencia cierta si as es. La postura del autor de este documento sostiene que es posible que los estilos constituyan una idea esencial en la eficacia de la solucin, tanto o ms que los patrones y con menos riesgo de catstrofe que el que supone (digamos) una metodologa como XP entendida a la manera fundamentalista [BMM+98] [Beck99]; pero esta seguir siendo una expresin de deseos en tanto el campo no impulse la bsqueda de un fuerte respaldo cuantitativo y una buena provisin de estudios de casos. Si bien se percibe por ejemplo en Forum Risks o en ACM Software Engineering Notes que las causas de riesgo reportadas se originan abrumadoramente en decisiones primarias de diseo, a diferencia de los patrones (que disponen ya de amplias colecciones de anti-patrones que ilustran los errores estructurales ms comunes), los estilos no cuentan todava con una buena teora de los anti-estilos.

Por ahora, se percibe un movimiento emergente que procura establecer el rol de decisiones arquitectnicas como la eleccin de estilo en el ciclo de vida, en la correspondencia con los requerimientos y en el costo, riesgo y calidad de la solucin. Despus de justificar su autonoma, una arquitectura que hasta ahora ha sido cualitativa y abstracta ha descubierto que alcanzar su plena justificacin cuando clarifique su relacin sistemtica con una ingeniera cuantitativa y concreta. En lugar de definir su posicionamiento en el ciclo de las metodologas tradicionales, se han desarrollado mtodos especficos llamados diversamente Software Architecture Analysis Method (SAAM), Architecture Tradeoff Analysis Method (ATAM) [Kaz98] [KBK99], Quality Attribute Workshop, Cost-Benefits Analysis Method (CBAM) [KAK01] y Attribute-Driven Design Method. Desde sus mismos nombres expresan con claridad y distincin que se est buscando determinar los nexos entre los requerimientos y la teora, y las consecuencias de la teora sobre la prctica subsiguiente. Estn surgiendo tambin minuciosos estudios de casos de misin crtica, reportando evaluaciones de desarrollos estilsticamente orientados con presencia de contratistas, usuarios de interfaz y arquitectos participantes [BCL+03], y cuantificando en moneda el costo de las decisiones arquitectnicas [AKK01] [KAK02]. La mejor referencia unitaria por ahora es el estudio de Rick Kazman, Robert Nord y Mark Klein [KNK03]. Si bien las categoras metodolgicas suenan prometedoras, detrs de esta constelacin de

mtodos nuevos se perciben las iniciativas de unos pocos autores, en una lnea de trabajo que posee menos de cinco aos de sedimentacin de experiencias.

Hay referencias a estas dimensiones en la Gua de Operaciones de Arquitectura de Microsoft Patterns & Practices (inscripta en Microsoft Operations Framework, MOF) [MS04a], as como una metodologa formal completa basada en Microsoft Solution Framework para la verificacin de patrones, en plena conformidad con la famosa regla de tres, bien conocida para la comunidad nucleada alrededor de patrones y antipatrones [AEA03] [http://www.antipatterns.com/whatisapattern/]. Entre los patrones testeados en esa metodologa se enumeran algunos que estn prximos al espritu de los estilos: Model-View-Controller, filtros de intercepcin, interfaz de servicios, aplicaciones en capas, replicacin amo-esclavo, transferencia de datos.

Pero en la literatura usual de circulacin abierta no hay todava una evaluacin prolija del impacto de las abstracciones de arquitectura y diseo sobre las dimensiones de consistencia con requerimientos que traje a colacin, que para los tcnicos de las escuelas Seca y Hmeda no seran funcionales, pero para las empresas lo son en grado sumo. Existe toda una inmensa disciplina especializada en evaluacin de arquitecturas, dividida en escuelas y metodologas que han llegado a ser tantas que debieron clasificarse en tipos (evaluacin basada en escenarios, en cuestionarios, en listas de verificacin, en simulacin, en mtricas?); pero esta tcnica est lejos de estar integrada a conceptos descriptivos y abstractos como los que dominan el campo estructural, y slo de tarde en tarde se vinculan los mtodos de evaluacin con las variables de diseo teorizadas como estilos o puestas en prctica como patrones [KK99] [KKB+99] [Har03].

Grupos especficos, como el de Mark Moriconi y sus colegas, han insistido en vincular los estilos con procesos, utilizando los estilos para factorear patrones de refinamiento [MQR95]; Moriconi, vinculado a SRI International de Menlo Park, se ha destacado como estudioso de los efectos semnticos del cambio en las aplicaciones, la representacin y el refinamiento de las especificaciones visuales, el papel de la lgica en el desarrollo y otros temas que vinculan la formalizacin ms pura con la prctica ms crtica. Pero lo que afirmaba David Garlan en 1994 respecto de que todava no estaba claro en qu medida y de qu manera se podan usar los estilos en relacin con el refinamiento, sigue siendo verdad una dcada ms tarde. Lo que Garlan mismo piensa a propsito de refinamiento, a fin de cuentas, se refiere a las dimensiones de optimizacin del software, antes que a la satisfaccin de los requerimientos del cliente, que en ltima instancia no tienen mucho que ver con el orden de la computacin [Gar94] [Gar96]. Toda la literatura que gira en torno de arquitectura de alto nivel en general y estilos en particular reconoce que las elaboraciones metodolgicas son preliminares; esta afirmacin, as como el resonante silencio respecto de la vigencia de las metodologas clsicas (con la excepcin de OOD) llevan a pensar que en el futuro abundarn ms las formulaciones from scratch de disciplinas de diseo basadas en arquitectura (con componentes como SAAM,

ATAM, ADDM, CBAM, etc) que la aplicacin de parches y extensiones a las estrategias antiguas.

El mismo retraso y preliminariedad se observa en una especializacin que ha decantado como un conjunto de modelos econmicos para evaluar el impacto de costo de reutilizacin de software. Se trata de un campo extremadamente desarrollado y nutrido; un survey como el de Edward Wiles (del Departamento de Ciencias de la Computacin de la Universidad de Aberystwyth, Gales) ha cruzado nada menos que siete tcnicas genricas de anlisis de inversin con veinticinco modelos evaluativos de reutilizacin, desde el famoso COCOMO de Barry Boehm y el modelo Gaffney-Durek a otros menos conocidos [Wil99]. Todos esos estudios se refieren a entidades de diseo y programacin; en el campo de la arquitectura y los estilos habr que trabajar bastante para llegar a semejante orden de magnitud. De los 5988 ttulos que registra la bibliografa sobre reutilizacin de software de Lombard Hill (http://www.lombardhill.com) no hay uno solo que se refiera al impacto econmico del uso de diseo basado en estilos. La gran expansin de la economa de software es de hecho anterior a la generalizacin de la arquitectura, los estilos y los patrones, cuyos procesos de rendicin de cuentas recin se estn estableciendo.

En fin, cabe concluir que todava hay mucho por hacer en el posicionamiento de los estilos en un marco de vistas y metodologas, por no decir nada del contexto de negocios. Muchas veces se ha criticado el cuadro abarcativo de Zachman por su falta de especificidad tcnica; pero tal vez haya que recuperar su espritu y su visin integral para plantear cuestiones semejantes en el debido nivel de prioridad.

Arriba

Conclusiones

En el desarrollo de este estudio, se han descripto en forma sucinta algunos estilos arquitectnicos representativos y sealado su posicionamiento en marcos y modelos de referencia ms amplios, su lugar frente a la estrategia arquitectnica de Microsoft y sus vnculos y antagonismos con el campo emergente de los patrones de arquitectura y diseo.

A modo de sntesis, podra decirse que los estilos han llegado a la arquitectura de software para quedarse y que ya han hecho mella tanto en el desarrollo de los lenguajes especficos de descripcin arquitectnica como en los lenguajes ms amplios de modelado, as como en las recomendaciones envolventes de la IEEE. Tanto en los modelos de referencia estructurales como en las metodologas diacrnicas, los estilos ocupan un lugar decididamente ms abstracto y un nicho temporal anterior al diseo orientado a patrones. Este es un campo por ahora amorfo, desestructurado, al cual los estilos bien podran aportarle (en retribucin por las

ideas sobre reutilizacin) un indicador sobre cmo construir alguna vez las taxonomas, los ordenamientos y los modelos que a todas luces se estn necesitando. Ms all de los logros formales de la arquitectura basada en estilos, es evidente que en el terreno de las relaciones entre teora y prctica resta todava mucho por hacer.

Arriba

Referencias bibliogrficas

[AG92] Robert Allen y David Garlan. A formal approach to software architectures. Proceedings of the IFIP Congress 92, Setiembre de 1992.

[AAG93] Gregory Abowd, Robert Allen y David Garlan. Using style to understand descriptions of software architecture. Proceedings of SIGSOFT'93: Foundations of Software Engineering, Software Engineering Notes 18(5), pp. 9-20. ACM Press, Diciembre de 1993.

[AAG95] Gregory Abowd, Robert Allen y David Garlan. Formalizing style to understand descriptions of software architecture. Technical Report, CMU-CS-95-111, Enero de 1995.

[Abd96] Ahmed Abd-Allah. Composing heterogeneous software architectures. Tesis doctoral, Department of Computer Sciences, USC, Agosto de 1996.

[AEA+03] Mohammad Al-Sabt, Matthew Evans, Geethika Agastya, Dayasankar Saminathan, Vijay Srinivasan y Larry Brader. Testing Software Patterns. Microsoft Patterns & Practices, Version 1.0.0. http://msdn.microsoft.com/architecture/patterns/Tsp/default.aspx, Octubre de 2003.

[AG96] Robert Allen y David Garlan, The Wright Architectural Description Language, Technical Report, Carnegie Mellon University. Verano de 1996.

[AKK01] Jayatirtha Asundi, Rick Kazman, Mark Klein. Using economic considerations to choose among architecture design alternatives. Technical Report, CMU/SEI-2001-TR-035, ESC-TR-2001-035, Diciembre de 2001.

[Ale77] Christopher Alexander. A pattern language. Oxford University Press, 1977.

[All97] Robert Allen. A formal approach to Software Architecture. Technical Report, CMU-CS-97-144, 1997.

[And91] Gregory R. Andrews. Paradigms for Process Interaction in Distributed Programs. ACM Computing Surveys, 23(1), pp. 49-90, Marzo de 1991.

[Arr94] Guillermo Arango. Domain Analysis Methods. En Software Reusability, R. Schfer, Prieto-Daz y M. Matsumoto (Eds.), Ellis Horwood, Nueva York, pp. 17-49, 1994.

[BCD02] Marco Bernardo, Paolo Ciancarini, y Lorenzo Donatiello. On The Formalization of Architectural Types With Process Algebras. Proceedings of the ACM Transactions on Software Engineering and Methodology, 11(4):386-426, 2002.

[BCK98] Len Bass, Paul Clements y Rick Kazman. Software Architecture in Practice. Reading, AddisonWesley, 1998.

[BCL+03] Mario Barbacci, Paul Clements, Anthony Lattanze, Linda Northrop, William Wood. Using the Architecture Tradeoff Analysis MethodSM (ATAMSM) to evaluate the software architecture for a product line of avionics systems: A case study. Technical Note, CMU/SEI-2003-TN-012, Julio de 2003.

[Beck99] Kent Beck. Extreme Programming Explained: Embrace change. Reading, Addison-Wesley, 1999.

[Big94] T. J. Biggerstaff. The Library Scaling Problem and the Limits of Concrete Component Reuse. Proceedings of the Third International Conference on Software Reuse, pp. 102-109, Rio de Janeiro, Noviembre de 1994.

[BMM+98] William Brown, Raphael Malveau, Hays Skip McCormick, Thomas Mawbray. Anti-Patterns: Refactoring software, architectures, and projects in crisis. John Wiley & Sons, 1998.

[BMR+96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal. Patternoriented software architecture A system of patterns. John Wiley & Sons, 1996.

[Boo91] Grady Booch. Object-Oriented Design with Applications. The Benjamin/Cummings Publishing Company, Inc, 1991.

[BRJ99] Grady Booch, James Rumbaugh e Ivar Jacobson. El Lenguaje Unificado de Modelado. Madrid, Addison-Wesley, 1999.

[Bro75] Frederick Brooks Jr. The mythical man-month. Reading, Addison-Wesley. 1975.

[Bro86] Frederick Brooks Jr. No silver bullet: Essence and accidents of software engineering. En H. G. Kluger (ed.), Information Processing, North Holland, Elsevier Science Publications, 1986.

[BSL00] Don Box, Aaron Skonnard y John Lam. Essential XML. Beyond markup. Reading, Addison-Wesley, 2000.

[Bur92] Steve Burbeck. Application programming in Smalltalk-80: How to use Model-View-Controller (MVC). University of Illinois in Urbana-Champaign, Smalltalk Archive, http://stwww.cs.uiuc.edu/users/smarch/st-docs/mvc.html.

[BW98] Alan Brown y Kurt Wallnau. The current state of CBSE. IEEE Software, pp.37-46, Octubre de 1998.

[Cha03] Michael Champion. Towards a reference architecture for Web services. XML Conference and Exposition 2003, Filadelfia, 2003.

[Chu02] Martin Chung. Publish-Subscribe Toolkit documentation for Microsoft BizTalk Server 2002. MSDN Library, http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbiz2k2/html/bts_PubSubEAI.asp, Mayo de 2002.

[Cle96] Paul Clements. A Survey of Architecture Description Languages. Proceedings of the International Workshop on Software Specification and Design, Alemania, 1996.

[CLC02] David Cohen, Mikael Lindvall y Patricia Costa. Agile Software Development: A DACS State-of-the-art Report. Nueva York, DACS, http://www.dacs.dtic.mil/techs/agile/agile.pdf, Enero de 2002.

[CN96] Paul Clements y Linda Northrop. Software Architecture: An Executive Overview. Technical Report, CMU/SEI-96-TR-003, Pittsburg, Carnegie Mellon University, 1996.

[Con58] M. Conway. Proposal for a universal computer-oriented language. Communications of the ACM, 1(10), pp. 5-8, Octubre de 1958.

[Cop92] James O. Coplien. Advanced C++ Programming Styles and Idioms. Reading, Addison-Wesley, 1992.

[Cza98] Krzysztof Czarnecki. Generative Programming: Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment-Based Component Models. Tesis de doctorado, Technical University of Ilmenau, 1998.

[DNR99] Elisabetta Di Nitto y David Rosenblum. Exploiting ADLs to specify architectural styles induced by middleware infrastructures. Proceedings of the 21st International Conference on Software Engineering (ICSE99), Los Angeles, 16 al 22 de Mayo de 1999.

[Dob02] Ernst-Erich Doberkat. Pipes and filters: Modelling a software architecture through relations. Internes Memorandum des Fachbereich Informatik Lehrstuhl fr Software Technologie, Universidad de Dortmund, Memo N 123, Junio de 2002.

[Fie00] Roy Thomas Fielding. Architectural styles and the design of network-based software architectures. Tesis doctoral, University of California, Irvine, 2000.

[FT02] Roy Thomas Fielding y Richard Taylor. Principled design of the modern Web architecture. ACM Transactions on Internet Technologies, 2(2), pp. 115-150, Mayo de 2002.

[Fow96] Martin Fowler. Analysis Patterns: Reusable Object Models. Reading, Addison-Wesley, 1996.

[Fow01] Martin Fowler. Is design dead?. Proceedings of the XP 2000 Conference, 2001.

[GAO94] David Garlan, Robert Allen y John Ockerbloom. Exploiting style in architectural design environments. Proceedings of SIGSOFT'94: Foundations of Software Engineering. ACM Press, Diciembre de 1994.

[GAO95] David Garlan, Robert Allen y John Ockerbloom. Architectural Mismatch, or, Why Its Hard to Build Systems out of Existing Parts. Proceedings of the 17th InternationalConference on Software Engineering, pp. 179-185, Seattle, Abril de 1995.

[Gar95] David Garlan. What is style. Proceedings of Dagshtul Workshop on Software Architecture. Febrero de 1995.

[Gar96] David Garlan. Style-based refinement. En A. L. Wolf, ed., Proceedings of the Second International Software Architecture Workshop (ISAW-2), pp. 72-75, San Francisco, Octubre de 1996.

[Gar00] David Garlan. Software Architecture: A Roadmap. En The future of software architecture, A. Finkelstein (ed.), ACM Press, 2000.

[Gar01] David Garlan. Next generation software architectures: Recent research and future directions. Presentacin, Columbia University, Enero de 2001.

[GB98] Hkan Grahn y Jan Bosch. Some initial performance characteristics of three architectural styles. WOSP, http://citeseer.nj.nec.com/50862.html, 1998.

[GD90] David Garlan y Norman Delisle. Formal specifications as reusable frameworks. En VDM90: VDM and Z - Formal Methods in Software Development, pp. 150-163, Kiel, Abril de 1990. Springer-Verlag, LNCS 428.

[GKM+96] David Garlan, Andrew Kompanek, Ralph Melton y Robert Monroe. Architectural Style: An ObjectOriented Approach. http://www.cs.cmu.edu/afs/cs/project/able/www/able/papers_bib.html, Febrero de 1996.

[GoF95] Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Design Patterns: Elements of reusable object-oriented software. Reading, Addison-Wesley, 1995.

[Gog92] Joseph Goguen. The dry and the wet. Monograph PR-100, Programming Research Group, Oxford University Computer Laboratory, 1992.

[Gom92] Hassan Gomaa. An Object-Oriented Domain Analysis and Modeling Method for Software Reuse. Proceedings of the Hawaii International Conference on System Sciences, Hawaii, Enero de 1992.

[GP92] Nicolas Guelfi, Gilles Perrouin. Rigorous engineering of software architectures: Integrating ADLs, UML and development methodologies. Luxembourg Ministry of Higher Education and Research, Proyecto MEN/IST/01/001, 2002.

[GS94] David Garlan y Mary Shaw. An introduction to software architecture. CMU Software Engineering Institute Technical Report, CMU/SEI-94-TR-21, ESC-TR-94-21, 1994.

[GSP99] R. F. Gamble, P. R. Stiger y R. T. Plant. Rule-based systems formalized within a software architectural style. Knowledge-Based Systems, v. 12, pp. 13-26, 1999.

[Har03] Maarit Harsu. From architectural requirements to architectural design. Report 34, Institute of Software Systems, Tampere University of Technology, Mayo de 2003

[Hil99] Rich Hilliard. Using the UML for architectural descriptions. Lecture Notes in Computer Science, vol. 1723, 1999,

[Hil00] Rich Hilliard. Impact assessment of the IEEE 1471 on The Open Group Architecture Framework, http://www.opengroup.org/togaf/procs/p1471-togaf-impact.pdf.

[Hil01a] Rich Hilliard. IEEE Std 1471 and beyond. Position paper, SEI First Architecture Representation Workshop, 16 y 17 de enero de 2001.

[Hil01b] Rich Hilliard. Three models for the description of architectural knowledge: Viewpoints, styles and patterns. Presentado a WICSA-2, enero de 2001.

[HR94] Frederick Hayes-Roth. Architecture-Based Acquisition and Development of Software: Guidelines and Recommendations from the ARPA Domain-Specific Software Architecture (DSSA) Program, 1994.

[IEEE00] IEEE Std 1471-2000. IEEE Recommended Practice for Architectural Description of Software Intensive Systems, IEEE, 2000.

[Ince88] Darrell Ince. Software development: Fashioning the Baroque, Oxford Science Publications, Oxford University Press, New York, 1988.

[JBR99] Ivar Jacobson, Grady Booch y James Rumbaugh. The Unified Software Development Process. Reading, Addison-Wesley, 1999.

[KAK01] Rick Kazman, Jai Asundi y Mark Klein. Quantifying the Costs and Benefits of Architectural Decisions,. Proceedings of the 23rd International Conference on Software Engineering (ICSE 2001). Toronto, 12 al 19 de Mayo de 2001, pp. 297-306. Los Alamitos, IEEE Computer Society, 2001.

[KAK02] Rick Kazman, Jai Asundi y Mark Klein. Making architecture design decisions: An economic approach. Technical Report, CMU/SEI-2002-TR-035, ESC-TR-2002-035, Setiembre de 2002.

[Kay68] A. Kay. FLEX, a flexible extensible language. Tesis doctoral, Universidad de Utah, 1968.

[Kaz98] Rick Kazman. The Architectural Tradeoff Analysis Method. Software Engineering Institute, CMU/SEI-98-TR-008, Julio de 1998.

[Kaz01] Rick Kazman. Software Architecture. En Handbook of Software Engineering and Knowledge Engineering, S-K Chang (ed.), World Scientific Publishing, 2001.

[KBK99] Rick Kazman, Mario Barbacci, Mark Klein, Jeromy Carrire y Steven Woods, Experience with Performing Architecture Tradeoff Analysis,. Proceedings of the 21st International Conference on Software Engineering (ICSE 99), Los Angeles, 16 al 22 de Mayo de 1999, pp. 54-63. Nueva York, Association for Computing Machinery, 1999.

[KCH+90] Kyo Kang, Sholom Cohen, James Hess, William Nowak y A. Spencer Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report, CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Noviembee de 1990.

[KGP+99] R. Keshav, R. Gamble, J. Payton y K. Frasier. Architecture integration elements. Technical Report UTULSA-MCS-16-99, Mayo de 1999.

[KK99] Mark Klein y Rick Kazman. Attribute-based architectural styles. Technical Report, CMU/SEI-99-TR022, ESC-TR-99-022, Carnegie Mellon University, Octubre de 1999.

[KKB+99] Mark Klein, Rick Kazman, Len Bass, Jeromy Carriere, Mario Barbacci y Howard Lipson. Attributebased architecture styles. En Patric Donohoe (ed.), Software Architecture, pp. 225-243. Kluwer Academic Publishers, 1999.

[KNK03] Rick Kazman, Robert Nord y Mark Klein. A life-cycle view of architecture analysis and design methods. Technical Note, CMU/SEI-2003-TN-026, Setiembre de 2003.

[Kru92] Charles W. Krueger. Software Reuse. ACM Computing Surveys, vol. 24(2), pp. 131-183, Junio de 1992.

[Kru95] Philippe B. Kruchten. Architectural blueprints: The 4+1 view model of architecture. IEEE Software, 12(6):4250, 1995.

[Land02] Rikard Land. A brief survey of software architecture. Mlardalen Real-Time Research Center (MRTC) Report. Vsters, Suecia, Febrero de 2002.

[Lar03] Craig Larman. UML y Patrones. 2a edicin, Madrid, Prentice Hall.

[LeM98] Daniel Le Mtayer. Describind architectural styles using graph grammars. IEEE Transactions of Software Engineering, 24(7), pp. 521-533, 1998.

[Mit02] Kevin Mitchell. A matter of style: Web Services architectural patterns. XML Conference & Exposition 2002, Baltimore, 8 al 13 de diciembre de 2002.

[MKM+96] Robert Monroe, Andrew Kompanek, Ralph Melton y David Garlan. Stylized architecture, design patterns, and objects. http://citeseer.nj.nec.com/monroe96stylized.html.

[MKM+97] Robert Monroe, Andrew Kompanek, Ralph Melton y David Garlan. Architectural Styles, design patterns, and objects. IEEE Software, pp. 43-52, Enero de 1997.

[MM04] Nikunj Mehta y Nenad Medvidovic. Toward composition of style-conformant software architectures. Technical Report, USC-CSE-2004-500, University of Southern California Center for Software Engineering, Enero de 2004.

[MMP00] Nikunj Mehta, Nenad Medvidovic y Sandeep Phadke. Towards a taxonomy of software connectors. Proceedings of the 22nd International Conference on Software Engineering (ICSE 2000), pp. 178-187, Limerick, Irlanda, 4 al 11 de junio de 2000.

[MPG96] S. Murrell, R. Plant y R. Gamble. Defining architectural styles for knowledge-based systems. AAAI-95, Workshop on Verification and Validation of Knowledge-Based Systems and Subsystems, pp. 51-58. Agosto de 1996.

[MQ94] Mark Moriconi y Xiaoliei Qian. Correctness and composition of software architectures. Proceedings of ACM SIGSOFT94: Symposium on Foundations of Software Engineering. Nueva Orleans, Diciembre de 1994.

[MQR95] Mark Moriconi, Xiaolei Qian y Robert Riemenschneider. Corrects architecture refinement. IEEE Transactions of Software Engineering, 1995.

[MS02a] Application Architecture for .NET: Designing applications and services. Microsoft Patterns & Practices. http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/enus/dnbda/html/distapp.asp, 2002.

[MS02b] Application Conceptual View. Microsoft Patterns & Practices. http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/enus/dnea/html/eaappconland.asp, 2002.

[MS03a] Enterprise Solution Patterns: Model-View-Controller. Microsoft Patterns & Practices, http://msdn.microsoft.com/practices/type/Patterns/Enterprise/DesMVC/, 2003.

[MS03b] Enterprise Solution Patterns: Implementing Model-View-Controller in ASP.NET. Microsoft Patterns & Practices, http://msdn.microsoft.com/practices/type/Patterns/Enterprise/ImpMVCinASP/, 2003.

[MS03c] COM+ (Component Services), Version 1.5. Platform SDK. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_comppr.asp, 2003

[MS04a] Operations Architecture Guide. Microsoft Patterns & Practices, http://www.microsoft.com/technet/itsolutions/techguide/msf/default.mspx, 2004.

[MS04b] Intercepting filter. Version 1.0.1. Microsoft Patterns & Practices, http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/enus/dnpatterns/html/DesInterceptingFilter.asp, 2004.

[MS04c] Layered application. Version 1.0.1. Microsoft Patterns & Practices, http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/enus/dnpatterns/html/ArcLayeredApplication.asp, 2004.

[MS04d] Three-layered services application. Microsoft Patterns & Practices, http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/enus/dnpatterns/html/ArcThreeLayeredSvcsApp.asp, 2004.

[MT97] Nenad Medvidovic y Richard Taylor. Exploiting architectural style to develop a family of applications. IEEE Proceedings of Software Engineering, 144(5-6), pp. 237-248, 1997.

[Nii86] H. Penny Nii. Blackboard Systems, parts 1 & 2. AI Magazine (7)3:38-53 & 7(4):62-69, 1986.

[Now99] Palle Nowak. Structures and interactions. Tesis de doctorado, Universidad del Sur de Dinamarca, 1999.

[Oel02] William Oellermann, Jr. Architecting Web Services. Apress, 2001.

[PA91] Rubn Prieto-Daz y Guillermo Arango. Domain Analysis and Software Systems Modeling. IEEE Computer Society Press, Los Alamitos, 1991.

[Platt02] Michael Platt. Microsoft Architecture Overview: Executive summary, http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnea/html/eaarchover.asp, 2002.

[Pre02] Roger Pressman. Ingeniera del Software: Un enfoque prctico. Madrid, McGraw Hill, 2001.

[PW92] Dewayne E. Perry y Alexander L. Wolf. Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes, 17(4), pp. 4052, Octubre de 1992.

[RBP+91] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy y William Lorensen. Objectoriented modeling and design. Englewood Cliffs, Prentice Hall, 1991.

[Rec04] Brent Rector. Introducing Longhorn for developers. Microsoft Press, 2004.

[Red99] Frank Redmond III. Introduction to designing and building Windows DNA applications. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndna/html/windnadesign_intro.asp, Junio de 1999.

[Rey04a] Carlos Reynoso. Teoras y mtodos de la complejidad y el caos. En proceso de edicin en Gedisa, Barcelona.

[Rey04b] Carlos Reynoso. Lenguajes de descripcin de arquitecturas (ADLs). 2004.

[Ris00] Linda Rising. Pattern Almanac 2000. Reading, Addison-Wesley.

[Sar00] Toby Sarver. Pattern refactoring workshop. Position paper, OOSPLA 2000, http://www.laputan.org/patterns/positions/Sarver.html, 2000.

[SC96] Mary Shaw y Paul Clements. A field guide to Boxology: Preliminary classification of architectural styles for software systems. Documento de Computer Science Department and Software Engineering Institute, Carnegie Mellon University. Abril de 1996. Publicado en Proceedings of the 21st International Computer Software and Applications Conference, 1997.

[Sch+02] Ron Schmelzer, Travis Vandersypen, Jason Bloomberg, Maddhu Siddalingaiah, Sam Hunting y Michael Qualls. XML and Web Services unleashed. SAMS, 2002.

[SCK+96] Mark Simos, Dick Creps, Carol Klinger, L. Levine y Dean Allemang. Organization Domain Modeling (ODM) Guidebook, Version 2.0. Informal Technical Report for STARS, STARS-VC-A025/001/00, 14 de junio de 1996, http://www.synquiry.com.

[SG96] Mary Shaw y David Garlan. Software Architecture: Perspectives on an emerging discipline. Upper Saddle River, Prentice Hall, 1996.

[SG97] P. R. Stiger y R. F. Gamble. Blackboard systems formalized within a software architectural style. International Conference on Systems, Man, Cybernetics, Octubre de 1997.

[Shaw01] Mary Shaw. The coming-of-age of software architecture research. International Conference of Software Engineering, 2001, pp. 656-664.

[Shaw95a] Mary Shaw. Comparing architectural design styles. IEEE Software 0740-7459, 1995.

[Shaw95b] Mary Shaw. Architectural Issues in Software Reuse: Its Not Just the Functionality, Its the Packaging. Proceedings of IEEE Symposium on Software Reusability, pp. 3-6, Seattle, Abril de 1995.

[Shaw96] Mary Shaw. Some Patterns for Software Architecture, en Pattern Languages of Program Design, Vol. 2, J. Vlissides, J. Coplien, y N. Kerth (eds.), Reading, Addison-Wesley, pp. 255-269, 1996.

[Sho03] Keith Short. Modeling languages for distributed application. Microsoft, Octubre de 2003. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsent/html/vsent_ModelingLangs.asp.

[Sit97] Ramesh Sitaraman. Integration of software systems at an abstract architectural level. Tesis doctoral, Dept. MCS, Universidad de Tulsa, 1997.

[St01] Harald Strrle. Towards architectural modeling with UML subsystems. Ludwig-MaximiliansUniversitt, Munich, http://www.pst.informatik.uni-muenchen.de/lehre/WS0102/architektur/UML01AM.pdf, 2001.

[Szy95] Clemens Alden Szyperski. Component Oriented Programming: A refined variation of ObjectOriented Programming. The Oberon Tribune, 1(2), Diciembre de 1995.

[Szy02] Clemens Alden Szyperski. Component software: Beyond Object-Oriented programming. Reading, Addison-Wesley, 2002.

[TC92] Will Tracz y Lou Coglianese. DSSA Engineering Process Guidelines. Technical Report, ADAGE-IBM9202, IBM Federal Systems Company, Diciembre de 1992.

[Tek00] Bedir Tekinerdogan. Synthesis-based architecture design. Disertacin doctoral, Departamento de Ciencias de la Computacin, Universidad de Twente, Enschede, Holanda, 2000.

[TMA+95] Richard Taylor, Nenad Medvidovic, Kenneth Anderson, James Whitehead, Jason Robbins, Kari Nies, Peyman Oreizy y Deborah Dubrow. A Component- and Message-Based Architectural Style for GUI Software. Proceedings of the 17th International Conference on Software Engineering, 23 al 30 de Abril de 1995, Seattle, ACM Press, pp. 295-304, 1995.

[WF04] Guijun Wang y Casey Fung. Architecture paradigms and their influences and impacts on componente-based software systems. Proceedings of the 37th Hawaii Intrnational Conference on System Sciences, 2004.

[Wil99] Edward Wiles. Economic models of software reuse: A survey, comparison and partial validation. Technical Report UWA-DCS-99-032, Department of Computer Sciences, University of Wales, Aberystwyth, 1999.

[WP92] Steven Wartik y Rubn Prieto-Daz. Criteria for Comparing Domain Analysis Approaches. International Journal of Software Engineering and Knowledge Engineering, 2(3), pp. 403-431, Setiembre de 1992.

[Zac87] John A. Zachman. A Framework for information systems architecture. IBM Systems Journal, 26(3), pp. 276-292, 1987.

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_ar q/style.asp#1

IV.1 Proceso de Desarrollo

Cuando se va a construir un sistema software es necesario conocer un lenguaje de programacin, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solucin sea cuidadosamente diseada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cmo se realiza el anlisis y el diseo, y cmo se relacionan los productos de ambos, entonces la construccin de sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo formado por varias personas. Para este curso se va a seguir el mtodo de desarrollo orientado a objetos que propone Craig Larman [Larman99]. Este proceso no fija una metodologa estricta, sino que define una serie de actividades que pueden realizarse en cada fase, las cuales deben adaptarse segn las condiciones del proyecto que se est llevando a cabo. Se ha escogido seguir este proceso debido a que aplica los ltimos avances en Ingeniera del Software, y a que adopta un enfoque eminentemente prctico, aportando soluciones a las principales dudas y/o problemas con los que se enfrenta el desarrollador. Su mayor aportacin consiste en atar los cabos sueltos que anteriores mtodos dejan. La notacin que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la proporcionada por UML, que se ha convertido en el estndar de facto en cuanto a notacin orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros equipos la documentacin, pues es de esperar que cualquier desarrollador versado en orientacin a objetos conozca y use UML (o se est planteando su uso). Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema funcionando, proporcionando as una visin completa y coherente de la produccin de sistemas software. El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo especficos. El ciclo de vida est dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. As no se pierde de vista la motivacin principal que debera estar en cualquier proceso de construccin de software: el resolver una necesidad del usuario/cliente. IV.1.1 Visin General El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que nos vamos a encontrar al intentar desarrollar cualquier sistema software de tamao medio-alto. El proceso est formado por una serie de actividades y subactividades, cuya realizacin se va repitiendo en el tiempo aplicadas a distintos elementos.

En este apartado se va a presentar una visin general para poder tener una idea del proceso a alto nivel, y ms adelante se vern los pasos que componen cada fase. Las tres fases al nivel ms alto son las siguientes: Planificacin y Especificacin de Requisitos: Planificacin, definicin de requisitos, construccin de prototipos, etc. Construccin: La construccin del sistema. Las fases dentro de esta etapa son las siguientes: - Diseo de Alto Nivel: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema. - Diseo de Bajo Nivel: El sistema se especifica en detalle, describiendo cmo va a funcionar internamente para satisfacer lo especificado en el Diseo de Alto Nivel. - Implementacin: Se lleva lo especificado en el Diseo de Bajo Nivel a un lenguaje de programacin. - Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificacin y Especificacin de Requisitos. Instalacin: La puesta en marcha del sistema en el entorno previsto de uso. De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque iterativo, tomando en cada iteracin un subconjunto de los requisitos (agrupados segn casos de uso) y llevndolo a travs del diseo de alto y bajo nivel hasta la implementacin y pruebas, tal y como se muestra en la Figura 36. El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximacin se consigue disminuir el grado de complejidad que se trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema funcionando que se puede contrastar con el usuario/cliente.

Figura 36 Desarrollo Iterativo en la Construccin

3.2.3 Arquitectura de referencia para sistemas mviles con conexin a Internet.

Fase de Planificacin y Especificacin de Requisitos

Esta fase se corresponde con la Especificacin de Requisitos tradicional ampliada con un Borrador de Modelo Conceptual y con una definicin de Casos de Uso de alto nivel. En esta fase se decidira si se aborda la construccin del sistema mediante desarrollo orientado a objetos o no, por lo que, en principio, es independiente del paradigma empleado posteriormente. IV.2.1 Actividades Las actividades de esta fase son las siguientes: Definir el Plan-Borrador. Crear el Informe de Investigacin Preliminar. Definir los Requisitos.

 Registrar Trminos en el Glosario. (continuado en posteriores fases) Implementar un Prototipo. (opcional) Definir Casos de Uso (de alto nivel y esenciales). Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior) Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior) Refinar el Plan. El orden no es estricto, lo normal es que las distintas actividades se solapen en el tiempo. Esto sucede tambin en las actividades de las fases de diseo, que se vern ms adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificacin de proyectos software, como las correspondientes a creacin de planes e informes preliminares. IV.2.2 Requisitos El formato del documento de Especificacin de Requisitos no est definido en UML, pero se ha incluido este punto para resaltar que la actividad de definicin de requisitos es un paso clave en la creacin de cualquier producto software. Para entender y describir los requisitos la tcnica de casos de uso constituye una valiosa ayuda. IV.2.3 Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales. Ntese que UML no define un formato para describir un caso de uso. Tan slo define la manera de representar la relacin entre actores y casos de uso en un diagrama: El Diagrama de Casos de Uso, definido en la pgina 9. Sin embargo, un caso de uso individual no es un diagrama, es un documento de texto. En la siguiente seccin se define el formato textual para la descripcin de un caso de uso que se va a utilizar en este documento.. Un escenario es un camino concreto a travs del caso de uso, una secuencia especfica de acciones e interacciones entre los actores y el sistema. Ms adelante se ver la representacin de los escenarios correspondientes a un caso de uso por medio de Diagramas de Secuencia. En un primer momento interesa abordar un caso de uso desde un nivel de abstraccin alto, utilizando el formato de alto nivel. Cuando se quiere describir un caso de uso con ms detalle se usa el formato expandido. IV.2.3.1 Casos de Uso de Alto Nivel

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se est usando un cajero automtico: - Caso de Uso: Realizar Reintegro - Actores: Cliente - Tipo: primario - Descripcin: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va. En un caso de uso descrito a alto nivel la descripcin es muy general, normalmente se condensa en dos o tres frases. Es til para comprender el mbito y el grado de complejidad del sistema. IV.2.3.2 Casos de Uso Expandidos Los casos de uso que se consideren los ms importantes y que se considere que son los que ms influencian al resto, se describen a un nivel ms detallado: en el formato expandido. La principal diferencia con un caso de uso de alto nivel est en que incluye un apartado de Curso Tpico de Eventos, pero tambin incluye otros apartados como se ve en el siguiente ejemplo: - Caso de Uso: Realizar Reintegro - Actores: Cliente (iniciador) - Propsito: Realizar una operacin de reintegro de una cuenta del banco - Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va. - Tipo: primario y esencial - Referencias: Funciones: R1.3, R1.7 - Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. 2. Pide la clave de identificacin. 3. Introduce la clave. 4. Presenta las opciones de operaciones disponibles. 5. Selecciona la operacin de Reintegro. 6. Pide la cantidad a retirar.

7. Introduce la cantidad requerida. 8. Procesa la peticin y da el dinero solicitado. Devuelve la tarjeta y genera un recibo. 9. Recoge la tarjeta. 10. Recoge el recibo. 11. Recoge el dinero y se va. Cursos Alternativos: Lnea 4: La clave es incorrecta. Se indica el error y se cancela la operacin. Lnea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operacin. El significado de cada apartado de este formato es como sigue: - Caso de Uso: Nombre del Caso de Uso - Actores: Lista de actores (agentes externos), indicando quin inicia el caso de uso. Los actores son normalmente roles que un ser humano desempea, pero puede ser cualquier tipo de sistema. - Propsito: Intencin del caso de uso. - Visin General: Repeticin del caso de uso de alto nivel, o un resumen similar. - Tipo: 1. primario, secundario u opcional (descritos ms adelante). 2. esencial o real (descritos ms adelante). - Referencias: Casos de uso relacionados y funciones del sistema que aparecen en los requisitos. - Curso Tpico de Eventos: Descripcin de la interaccin entre los actores y el sistema mediante las acciones numeradas de cada uno. Describe la secuencia ms comn de eventos, cuando todo va bien y el proceso se completa satisfactoriamente. En caso de haber alternativas con grado similar de probabilidad se pueden aadir secciones adicionales a la seccin principal, como se ver ms adelante. - Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la descripcin de la excepcin. IV.2.3.3 Identificacin de Casos de Uso La identificacin de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la revisin de los documentos de requisitos existentes, y en el uso de la tcnica de brainstorming entre los miembros del equipo de desarrollo. Como gua para la identificacin inicial de casos de uso hay dos mtodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organizacin. 2. Para cada actor, identificar los procesos que inicia o en los que participa. b) Basado en Eventos

1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso. Ejemplos de casos de uso: Pedir un producto. Matricularse en un curso de la facultad. Comprobar la ortografa de un documento en un procesador de textos. Comprar un libro en una tienda de libros en Internet IV.2.3.4 Identificacin de los Lmites del Sistema En la descripcin de un caso de uso se hace referencia en todo momento al sistema. Para que los casos de uso tengan un significado completo es necesario que el sistema est definido con precisin. Al definir los lmites del sistema se establece una diferenciacin entre lo que es interno y lo que es externo al sistema. El entorno exterior se representa mediante los actores. Ejemplos de sistemas son: El hardware y software de un sistema informtico. Un departamento de una organizacin. Una organizacin entera. Si no se est haciendo reingeniera del proceso de negocio lo ms normal es escoger como sistema el primero de los ejemplos: el hardware y el software del sistema que se quiere construir. IV.2.3.5 Tipos de Casos de Uso a) Segn Importancia Para establecer una primera aproximacin a la priorizacin de casos de uso que identifiquemos los vamos a distinguir entre: Primarios: Representan los procesos principales, los ms comunes, como Realizar Reintegro en el caso del cajero automtico. Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales como Aadir Nueva Operacin. Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. b) Segn el Grado de Compromiso con el Diseo En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solucin, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnologa y de la implementacin. Un caso de uso definido a nivel abstracto se denomina

esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstraccin. Por el contrario, un caso de uso real describe concretamente el proceso en trminos del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta a un tipo de interfaz especfica, y se baja a detalles como pantallas y objetos en las mismas. Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero automtico tenemos la siguiente descripcin del Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura para tarjetas. 2. Pide el PIN (Personal Identification Number). 3. Introduce el PIN a travs del teclado numrico. 4. Presenta las opciones de operaciones disponibles. 5. etc. 6. etc. En principio, los casos de uso reales deberan ser creados en la fase de Diseo de Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definicin de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida. No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de compromiso con el diseo es un continuo, y una descripcin especfica de un caso de uso estar situada en algn punto de la lnea entre Casos de Uso Esenciales y Reales, normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros. IV.2.3.6 Consejos Relativos a Casos de Uso a) Nombre El nombre de un Caso de Uso debera ser un verbo, para enfatizar que se trata de un proceso, por ejemplo: Comprar Artculos o Realizar Pedido. b) Alternativas equiprobables Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas opciones, todas ellas consideradas normales se puede completar el Curso Tpico de Eventos con secciones adicionales. As, si en un determinado nmero de lnea hay una bifurcacin se pueden poner opciones que dirigen el caso de uso a una seccin que se detalla al final del Curso Tpico de Eventos,

en la siguiente forma: - Curso Tpico de Eventos: - Seccin: Principal Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando Actor llega al sistema. 2. Pide la operacin a realizar. 3. Escoge la operacin A. 4. Presenta las opciones de pago. 5. Selecciona el tipo de pago: a. Si se paga al contado ver seccin Pago al Contado. b. Si se paga con tarjeta ver seccin Pago con Tarjeta. 6. Genera recibo. 7. Recoge el recibo y se va. Cursos Alternativos: Lneas 3 y 5: Selecciona Cancelar. Se cancela la operacin. - Seccin: Pago al Contado Accin del Actor Respuesta del Sistema 1. Mete los billetes correspondientes 2. Coge los billetes y sigue pidiendo dinero hasta que la cantidad est satisfecha 3. Devuelve el cambio. Cursos Alternativos: Lnea 3: No hay cambio suficiente. Se cancela la operacin. - Seccin: Pago con Tarjeta ... IV.2.4 Construccin del Modelo de Casos de Uso Para construir el Modelo de Casos de Uso en la fase de Planificacin y Especificacin de Requisitos se siguen los siguientes pasos: 1. Despus de listar las funciones del sistema, se definen los lmites del sistema y se identifican los actores y los casos de uso. 2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios, secundarios u opcionales. 3. Se dibuja el Diagrama de Casos de Uso. 4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se ilustran tales relaciones en el Diagrama de Casos de Uso. 5. Los casos de uso ms crticos, importantes y que conllevan un mayor riesgo, se describen

en el formato expandido esencial. Se deja la definicin en formato expandido esencial del resto de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la complejidad del problema de una sola vez. 6. Se crean casos de uso reales slo cuando: Descripciones ms detalladas ayudan significativamente a incrementar la comprensin del problema. El cliente pide que los procesos se describan de esta forma. 7. Ordenar segn prioridad los casos de uso (este paso se va a ver a continuacin). IV.2.5 Planificacin de Casos de Uso segn Ciclos de Desarrollo La decisin de qu partes del sistema abordar en cada ciclo de desarrollo se va a tomar basndose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementacin de uno o ms casos de uso, o versiones simplificadas de casos de uso. Se asigna una versin simplificada cuando el caso de uso completo es demasiado complejo para ser tratado en un solo ciclo (ver Figura 37).

Para tomar la decisin de qu casos de uso se van a tratar primero es necesario ordenarlos segn prioridad. Las caractersticas de un caso de uso especfico que van a hacer que un caso de uso tenga una prioridad alta son las siguientes: a. Impacto significativo en el diseo de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del dominio o requiere persistencia en los datos. b. Se obtiene una mejor comprensin del diseo con un nivel de esfuerzo relativamente bajo.

c. Incluye funciones complejas, crticas en el tiempo o de nivel elevado de riesgo. d. Implica bien un trabajo de investigacin significante, o bien el uso de una tecnologa nueva o arriesgada. e. Representa un proceso de gran importancia en la lnea de negocio. f. Supone directamente un aumento de beneficios o una disminucin de costes. Para realizar la clasificacin se puede asignar a cada caso de uso una valoracin numrica de cada uno de estos puntos, para conseguir una puntuacin total aplicando pesos a cada apartado. En la siguiente tabla se muestra un ejemplo de tal tipo de clasificacin: Peso 3 2 4 1 3 4 Suma Caso de Uso a b c d e f Realizar reintegro 5 4 1 0 5 2 50 ... IV.2.5.1 Caso de Uso Inicializacin Prcticamente todos los sistemas van a tener un caso de uso Inicializacin. Aunque puede ser que no tenga una prioridad alta en la clasificacin realizada segn el punto anterior, normalmente va a interesar que sea desarrollado desde el principio. Inicialmente se desarrolla una versin simplificada, que se va completando en cada ciclo de desarrollo para satisfacer las necesidades de inicializacin de los casos de uso que se tratan en dicho ciclo. As se tiene un sistema en cada ciclo de desarrollo que puede funcionar.

3.2.4 Arquitectura de referencia para sistemas de informacin.

IV.3 Fase de Construccin: Diseo de Alto Nivel

En la fase de Diseo de Alto Nivel de un ciclo de desarrollo se investiga sobre el problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se est tratando. Se intenta llegar a una buena comprensin del problema por parte del equipo de desarrollo, sin entrar en cmo va a ser la solucin en cuanto a detalles de implementacin. Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseo de Alto Nivel hay una serie de actividades de planificacin. Estas actividades consisten en actualizar los modelos que se tengan segn lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha analizado y diseado y lo que finalmente se construye. Una vez se tienen los modelos acordes con lo implementado se empieza el nuevo ciclo de desarrollo con la fase de Diseo de Alto Nivel. En esta fase se trabaja con los modelos de Diseo de Alto Nivel construidos en la fase anterior, amplindolos con los conceptos correspondientes a los casos de uso que se traten

en el ciclo de desarrollo actual. IV.3.1 Actividades Las actividades de la fase de Diseo de Alto Nivel son las siguientes: 1. Definir Casos de Uso Esenciales en formato expandido. (si no estn definidos ) 2. Refinar los Diagramas de Casos de Uso. 3. Refinar el Modelo Conceptual. 4. Refinar el Glosario. (continuado en posteriores fases) 5. Definir los Diagramas de Secuencia del Sistema. 6. Definir Contratos de Operacin. 7. Definir Diagramas de Estados. (opcional) IV.3.2 Modelo Conceptual Una parte de la investigacin sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de Estructura Esttica de UML, al que se va a llamar Modelo Conceptual. En el Modelo Conceptual se tiene una representacin de conceptos del mundo real, no de componentes software. El objetivo de la creacin de un Modelo Conceptual es aumentar la comprensin del problema. Por tanto, a la hora de incluir conceptos en el modelo, es mejor crear un modelo con muchos conceptos que quedarse corto y olvidar algn concepto importante. IV.3.2.1 Identificacin de Conceptos Para identificar conceptos hay que basarse en el documento de Especificacin de Requisitos y en el conocimiento general acerca del dominio del problema. En la Tabla 1 se muestran algunas categoras tpicas, junto con ejemplos pertenecientes al dominio de los supermercados y al de la reserva de billetes de avin: Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de requisitos o, ms concretamente, en la descripcin de los casos de uso. No es un mtodo infalible, pero puede servir de gua para empezar. Para poner nombre a los conceptos se puede usar la analoga con el cartgrafo, resumida en los siguientes tres puntos: Usar los nombres existentes en el territorio: Hay que usar el vocabulario del dominio para nombrar conceptos y atributos. Excluir caractersticas irrelevantes: Al igual que el cartgrafo elimina caractersticas no relevantes segn la finalidad del mapa (por ejemplo datos de poblacin en un mapa de carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son pertinentes en base a los requisitos. No aadir cosas que no estn ah: Si algo no pertenece al dominio del problema no se aade al modelo. IV.3.2.2 Creacin del Modelo Conceptual Para crear el Modelo Conceptual se siguen los siguientes pasos: 1. Hacer una lista de conceptos candidato usando la Lista de Categoras de Conceptos de la Tabla 1 y la bsqueda de sustantivos relacionados con los requisitos en consideracin en este ciclo. 2. Representarlos en un diagrama.

3. Aadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer. 4. Aadir los atributos necesarios para contener toda la informacin que se necesite conocer de cada concepto. IV.3.2.3 Identificacin de Asociaciones Una asociacin es una relacin entre conceptos que indica una conexin con sentido y que es de inters en el conjunto de casos de uso que se est tratando. Se incluyen en el modelo las asociaciones siguientes: Asociaciones para las que el conocimiento de la relacin necesita mantenerse por un cierto perodo de tiempo (asociaciones necesita-conocer). Asociaciones derivadas de la Lista de Asociaciones Tpicas que se muestra en la Tabla 2. Tabla 1 Lista de Conceptos Tpicos Tipo de Concepto Ejemplos Objetos fsicos o tangibles Avin Terminal de Caja Especificaciones, diseos o descripciones de cosas Especificacin de Producto Descripcin de Vuelo Lugares Supermercado Aeropuerto Transacciones Venta, Pago Reserva Lneas de una transaccin Artculo de Venta Roles de una persona Cajero Piloto Contenedores de otras cosas Supermercado, Cesta Avin Cosas en un contenedor Artculo Pasajero Otros ordenadores o sistemas electromecnicos externos a nuestro sistema Sistema de Autorizacin de Tarjetas de Crdito Sistema Controlador de Trfico Areo Conceptos abstractos Hambre Organizaciones Departamento de Ventas Compaa Area Toto Eventos Venta, Robo, Reunin Vuelo, Accidente, Aterrizaje Reglas y polticas Poltica de Devoluciones Poltica de Cancelaciones Catlogos Catlogo de Productos Catlogo de Piezas Archivos financieros, de trabajo, de contratos, de asuntos legales Recibo, Contrato de Empleo Registro de Revisiones Instrumentos y servicios financieros Lnea de Crdito Stock Manuales, libros Manual del Empleado

Manual de Reparaciones Tabla 2 Lista de Asociaciones Tpicas Categora Ejemplos A es una parte fsica de B Ala Avin A es una parte lgica de B Artculo en Venta Venta A est fsicamente contenido en B Artculo Estantera Pasajero Avin A est lgicamente contenido en B Descripcin de Artculo Catlogo A es una descripcin de B Descripcin de Artculo Artculo A es un elemento en una transaccin o un informe B Trabajo de Reparacin Registro de Reparaciones A es registrado/archivado/capturado en B Venta Terminal de Caja A es un miembro de B Cajero Supermercado Piloto Compaa Area A es una subunidad organizativa de B Seccin Supermercado Mantenimiento Compaa Area A usa o gestiona B Cajero Terminal de Caja Piloto Avin A comunica con B Cliente Cajero Empleado de Agencia de Viajes Pasajero A est relacionado con una transaccin B Cliente Pago Pasajero Billete A es una transaccin relacionada con otra transaccin B Pago Venta Reserva Cancelacin A est junto a B Ciudad Ciudad A posee B Supermercado Terminal de Caja Compaa Area Avin Una vez identificadas las asociaciones se representan en el Modelo Conceptual con la multiplicidad adecuada. IV.3.2.4 Identificacin de Atributos Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de informacin de los casos de uso que se estn desarrollando en ese momento. Los atributos deben tomar valor en tipos simples (nmero, texto, etc.), pues los tipos complejos deberan ser modelados como conceptos y ser relacionados mediante asociaciones. Incluso cuando un valor es de un tipo simple es ms conveniente representarlo como concepto en las siguientes ocasiones: Se compone de distintas secciones. Por ejemplo: un nmero de telfono, el nombre de una persona, etc. Tiene operaciones asociadas, tales como validacin. Ejemplo: NIF. Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin. Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesetas o en euros. Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo definitivo, pues a lo largo del desarrollo se va refinando segn se le aaden

conceptos que se haban pasado por alto. IV.3.3 Glosario En el glosario debe aparecer una descripcin textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigedad. Se ordena alfabticamente por trmino. Un formato tipo para el glosario es el que se muestra en la Tabla 3. Tabla 3 Formato tipo de Glosario Trmino Categora Descripcin Banco concepto Entidad que ofrece servicios financieros a sus clientes Realizar Reintegro caso de uso El Cliente realiza un reintegro de su cuenta ... ... ... IV.3.4 Diagramas de Secuencia del Sistema Adems de investigar sobre los conceptos del sistema y su estructura, tambin es preciso investigar en el Diseo de Alto Nivel sobre el comportamiento del sistema, visto ste como una caja negra. Una parte de la descripcin del comportamiento del sistema se realiza mediante los Diagramas de Secuencia del Sistema. En cada caso de uso se muestra una interaccin de actores con el sistema. En esta interaccin los actores generan eventos, solicitando al sistema operaciones. Por ejemplo, en el caso de una reserva de un billete de avin, el empleado de la agencia de viajes solicita al sistema de reservas que realice una reserva. El evento que supone esa solicitud inicia una operacin en el sistema de reservas. Los casos de uso representan una interaccin genrica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecucin real del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular. Un Diagrama de Secuencia de Sistema se representa usando la notacin para diagramas de secuencia de UML (ver pgina 11). En l se muestra para un escenario particular de un caso de uso los eventos que los actores generan, su orden, y los eventos que se intercambian entre sistemas. Para cada caso de uso que se est tratando se realiza un diagrama para el curso tpico de eventos, y adems se realiza un diagrama para los cursos alternativos de mayor inters. En la Figura 38 se muestra el Diagrama de Secuencia del Sistema para el caso de uso Realizar Reintegro de un cajero automtico.

Figura 38 Ejemplo de Diagrama de Secuencia del Sistema IV.3.4.1 Construccin de un Diagrama de Secuencia del Sistema Para construir un Diagrama de Secuencia del Sistema para el curso tpico de eventos de un caso de uso, se siguen los siguientes pasos: 1. Representar el sistema como un objeto con una lnea debajo. 2. Identificar los actores que directamente operan con el sistema, y dibujar una lnea para cada uno de ellos. 3. Partiendo del texto del curso tpico de eventos del caso de uso, identificar los eventos (externos) del sistema que cada actor genera y representarlos en el diagrama. 4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama. Los eventos del sistema deberan expresarse en base a la nocin de operacin que representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere finalizarOperacin a presionadaTeclaEnter, porque captura la finalidad de la operacin sin realizar compromisos en cuanto a la interfaz usada. IV.3.5 Contratos de Operaciones Una vez se tienen las Operaciones del Sistema identificadas en los Diagramas de Secuencia, se describe mediante contratos el comportamiento esperado del sistema en cada operacin. Un Contrato es un documento que describe qu es lo que se espera de una operacin. Tiene

una redaccin en estilo declarativo, enfatizando en el qu ms que en el cmo. Lo ms comn es expresar los contratos en forma de pre- y post-condiciones en torno a cambios de estado. Se puede escribir un contrato para un mtodo individual de una clase software, o para una operacin del sistema completa. En este punto se ver nicamente ste ltimo caso. Un Contrato de Operacin del Sistema describe cambios en el estado del sistema cuando una operacin del sistema es invocada. A continuacin se ve un ejemplo de Contrato: Contrato Nombre: leerTarjeta (nmero_tarjeta: nmero) Responsabilidades: Comprobar que la tarjeta numero_tarjeta es correcta y presentar las opciones disponibles. Referencias Cruzadas: Funciones del Sistema: R1.2, R1.6, R1.7 Casos de Uso: Reintegro Notas: Excepciones: Si la tarjeta es ilegible o no pertenece a los tipos de tarjetas aceptadas, indicar que ha habido un error. Salida: Pre-condiciones: No hay una operacin activa. Post-condiciones: Una nueva Operacin se ha creado. (creacin de instancia). La Operacin se ha asociado con Cajero. (asociacin formada). La descripcin de cada apartado de un contrato es como sigue: Nombre: Nombre de la operacin y parmetros. Responsabilidades: Una descripcin informal de las responsabilidades que la operacin debe desempear. Referencias Cruzadas: Nmeros de referencia en los requisitos de funciones del sistema, casos de uso, etc. Notas: Comentarios de diseo, algoritmos, etc. Excepciones: Casos excepcionales. Situaciones que debemos tener en cuenta que pueden pasar. Se indica tambin qu se hace cuando ocurre la excepcin. Salida: Salidas que no corresponden a la interfaz de usuario, como mensajes o registros que se envan fuera del sistema. (En la mayor parte de las operaciones del sistema este apartado queda vaco) Pre-condiciones: Suposiciones acerca del estado del sistema antes de ejecutar la operacin. Post-condiciones: El estado del sistema despus de completar la operacin. IV.3.5.1 Construccin de un Contrato Los pasos a seguir para construir un contrato son los siguientes: 1. Identificar las operaciones del sistema a partir de los Diagramas de Secuencia del Sistema. 2. Para cada operacin del sistema construir un contrato. 3. Empezar escribiendo el apartado de Responsabilidades, describiendo informalmente el propsito de la operacin. Este es el apartado ms importante del contrato. 4. A continuacin rellenar el apartado de Post-condiciones, describiendo declarativamente los cambios de estado que sufren los objetos en el Modelo Conceptual. Puede ser que este apartado quede vaco si no cambia el valor de ningn dato de los maneja el sistema (por ejemplo en una operacin del sistema que tan solo se encarga de sacar por pantalla algo al

usuario). 5. Para describir las post-condiciones, usar las siguientes categoras: Creacin y borrado de instancias. Modificacin de atributos. Asociaciones formadas y retiradas. 6. Completar el resto de apartados en su caso. IV.3.5.2 Post-condiciones Las post-condiciones se basan en el Modelo Conceptual, en los cambios que sufren los elementos del mismo una vez se ha realizado la operacin. Es mejor usar el tiempo pasado o el pretrito perfecto al redactar una post-condicin, para enfatizar que se trata de declaraciones sobre un cambio en el estado que ya ha pasado. Por ejemplo es mejor decir se ha creado un nuevo Cliente que decir crear un Cliente. Cuando se ha creado un objeto, lo normal es que se haya asociado a algn otro objeto ya existente, porque si no queda aislado del resto del sistema. Por tanto, al escribir las postcondiciones hay que acordarse de aadir asociaciones a los objetos creados. Olvidar incluir estas asociaciones es el fallo ms comn cometido al escribir las post-condiciones de un contrato. IV.3.6 Diagramas de Estados Para modelar el comportamiento del sistema pueden usarse los Diagramas de Estados que define UML (ver pgina 13). Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos: - Una clase software. - Un concepto. - Un caso de uso. En la fase de Diseo de Alto Nivel slo se hara para los dos ltimos tipos de elemento, pues una clase software pertenece al Diagrama de Clases de Diseo. Puesto que el sistema entero puede ser representado por un concepto, tambin se puede modelar el comportamiento del sistema completo mediante un Diagrama de Estados. La utilidad de un Diagrama de Estados en esta fase reside en mostrar la secuencia permitida de eventos externos que pueden ser reconocidos y tratados por el sistema. Por ejemplo, no se puede insertar una tarjeta en un cajero automtico si se est en el transcurso de una operacin. Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de Estados del sistema sera una combinacin de los diagramas de todos los casos de uso. El uso de Diagramas de Estados es opcional. Tan solo los usaremos cuando consideremos que nos ayudan a expresar mejor el comportamiento del elemento descrito.

3.2.5 Arquitectura de referencia para ambientes virtuales de aprendizaje.

Fase de Construccin: Diseo de Bajo Nivel

En la fase de Diseo de Bajo Nivel se crea una solucin a nivel lgico para satisfacer los requisitos, basndose en el conocimiento reunido en la fase de Diseo de Alto Nivel. Los modelos ms importantes en esta fase son el Diagrama de Clases de Diseo y los Diagramas de Interaccin, que se realizan en paralelo y que definen los elementos que forman parte del sistema orientado a objetos que se va a construir (clases y objetos) y cmo colaboran entre s para realizar las funciones que se piden al sistema, segn stas se definieron en los contratos de operaciones del sistema. IV.4.1 Actividades Las actividades que se realizan en la etapa de Diseo de Bajo Nivel son las siguientes: 1. Definir los Casos de Uso Reales. 2. Definir Informes e Interfaz de Usuario. 3. Refinar la Arquitectura del Sistema. 4. Definir los Diagramas de Interaccin. 5. Definir el Diagrama de Clases de Diseo. (en paralelo con los Diagramas de Interaccin) 6. Definir el Esquema de Base de Datos. El paso de Refinar la Arquitectura del Sistema no tiene por qu realizarse en la posicin 3, puede realizarse antes o despus. IV.4.2 Casos de Uso Reales Un Caso de Uso Real describe el diseo real del caso de uso segn una tecnologa concreta de entrada y de salida y su implementacin. Si el caso de uso implica una interfaz de usuario, el caso de uso real incluir bocetos de las ventanas y detalles de la interaccin a bajo nivel con los widgets (botn, lista seleccionable, campo editable, etc.) de la ventana. Como alternativa a la creacin de los Casos de Uso Reales, el desarrollador puede crear bocetos de la interfaz en papel, y dejar los detalles para la fase de implementacin. IV.4.3 Diagramas de Interaccin Los Diagramas de Interaccin muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato Hay dos clases de Diagramas de Interaccin: 1. Diagramas de Colaboracin. 2. Diagramas de Secuencia. La notacin en UML para ambos es la definida en la pgina 11. De entre ambos tipos, los Diagramas de Colaboracin tienen una mayor expresividad y mayor economa espacial (una interaccin compleja puede ser muy larga en un Diagrama de Secuencia), sin embargo en ellos la secuencia de interaccin entre objetos es ms difcil de seguir que en un Diagrama de Secuencia. Ambos tipos de diagramas expresan la misma informacin, por lo que se puede usar cualquiera de los dos para expresar la interaccin entre los objetos del sistema. La creacin de los Diagramas de Interaccin de un sistema es una de las actividades ms importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creacin de estos diagramas, por tanto, debera ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero. IV.4.3.1 Creacin de Diagramas de Interaccin

Para crear los Diagramas de Colaboracin o de Secuencia se pueden seguir los siguientes consejos: Crear un diagrama separado para cada operacin del sistema en desarrollo en el ciclo de desarrollo actual. - Para cada evento del sistema, hacer un diagrama con l como mensaje inicial. Usando los apartados de responsabilidades y de post-condiciones del contrato de operacin, y la descripcin del caso de uso como punto de partida, disear un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas. Si el diagrama se complica, dividirlo en dos diagramas ms pequeos. Para ello se termina la secuencia de mensajes en un mensaje determinado, y en el segundo diagrama se comienza con el mensaje que termin el primero. Debe indicarse en el primer diagrama que el resto de la interaccin se detalla en el segundo. El comportamiento dinmico del sistema que se describe en un Diagrama de Interaccin debe ser acorde con la estructura esttica del sistema que se refleja en el Diagrama de Clases de Diseo. Es aconsejable realizar un Diagrama de Clases de Diseo borrador antes de comenzar con los Diagramas de Interaccin. La capacidad de realizar una buena asignacin de responsabilidades a los distintos objetos es una habilidad clave, y se va adquiriendo segn aumenta la experiencia en el desarrollo orientado a objetos. Responsabilidad es como un contrato u obligacin de una clase o tipo. Las responsabilidades estn ligadas a las obligaciones de un objeto en cuanto a su comportamiento. Bsicamente, estas responsabilidades pueden ser de tipo Conocer o de tipo Hacer: Conocer: - Conocer datos privados encapsulados. - Conocer los objetos relacionados. - Conocer las cosas que puede calcular o derivar. Hacer: - Hacer algo l mismo. - Iniciar una accin en otros objetos. - Controlar y coordinar actividades en otros objetos. Por ejemplo, puedo decir que un Recibo es responsable de calcular el total (tipo hacer), o que una Transaccin es responsable de saber su fecha (tipo conocer). Las responsabilidades de tipo conocer se pueden inferir normalmente del Modelo Conceptual. Una responsabilidad no es lo mismo que un mtodo, pero los mtodos se implementan para satisfacer responsabilidades. IV.4.4 Diagrama de Clases de Diseo Un Diagrama de Clases de Diseo muestra la especificacin para las clases software de una aplicacin. Incluye la siguiente informacin: Clases, asociaciones y atributos. Interfaces, con sus operaciones y constantes. Mtodos. Navegabilidad. Dependencias. A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseo muestra definiciones de entidades software ms que conceptos del mundo real. En la Figura 39 se muestra un ejemplo de Diagrama de Clases de Diseo sencillo.

Figura 39 Ejemplo de Diagrama de Clases de Diseo IV.4.4.1 Relaciones de Dependencia para Representar Visibilidad entre Clases Cuando una clase conoce a otra por un medio que no es a travs de un atributo (una asociacin con la navegabilidad adecuada), entonces es preciso indicar esta situacin por medio de una dependencia. Un objeto debe conocer a otro para poder llamar a uno de sus mtodos, se dice entonces que el primer objeto tiene visibilidad sobre el segundo. La visibilidad ms directa es por medio de atributo, cuando hay una asociacin entre ambas clases y se puede navegar de la primera a la segunda (un atributo de la primera es un puntero a un objeto de la segunda). Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de dependencia: - Parmetro: Cuando a un mtodo de una clase se le pasa como parmetro un objeto de otra clase, se dice que la primera tiene visibilidad de parmetro sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <> (<> en ingls). - Local: Cuando en un mtodo de una clase se define una variable local que es un objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo <>. - Global: Cuando hay una variable global en el sistema, instancia de una clase A, y un mtodo de una clase B llama a un mtodo de A, se dice que la clase B tiene visibilidad global sobre la clase A. La relacin de dependencia entre ambas clases se etiqueta con el

estereotipo <>. No es necesario representar la relacin de dependencia entre clases que ya estn relacionadas por medio de una asociacin, que se trata de una dependencia ms fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qu elementos hay que revisar cuando se realiza un cambio en el diseo de un elemento del sistema. a) Solitario: Caso Particular de Visibilidad global El uso de variables globales no se aconseja por los efectos laterales que se pueden presentar, pero hay un caso en el que s hay cierta globalidad: las clases que slo van a tener una instancia. Suele tratarse de clases que se han creado en el Diseo de Bajo Nivel, que no aparecan en el Modelo Conceptual. Varias clases de nuestro sistema pueden querer llamar a los mtodos de la nica instancia de una clase de ese tipo, entonces s se considera que es beneficioso que se pueda acceder a esa instancia como un valor accesible de forma global. Una solucin elegante para este caso se implementa mediante un mtodo de clase para obtener esa nica instancia (los mtodos de clase los permiten algunos lenguajes orientados a objetos, por ejemplo Java), en vez de definirla directamente como una variable global. Para indicar que una clase slo va a tener una instancia, se etiqueta la clase con el estereotipo <> (<> en ingls), y las relaciones de dependencia entre las clases que la usan y se etiquetan tambin <> en vez de <>. A continuacin se muestra un ejemplo del cdigo en Java de una clase solitario: public class Solitario { // se define la instancia como atributo de clase (static) Solitario static instancia := null; // mtodo de clase que devuelve la instancia public static Solitario dar_instancia() { if (instancia = = null) { // si no est creada la instancia la crea instancia := new Solitario(); } return instancia; } ... // otros mtodos de la clase } Cuando otra clase quiere llamar a un mtodo de la instancia incluye el siguiente cdigo: variable Solitario; variable = Solitario.dar_instancia(); variable.mtodo(); // llamada al mtodo que necesitamos IV.4.4.2 Construccin de un Diagrama de Clases de Diseo Normalmente se tiene una idea de un Diagrama de Clases, con una asignacin de responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases Borrador, puede seguirse la siguiente estrategia: 1. Identificar todas las clases participantes en la solucin software. Esto se lleva a cabo analizando los Diagramas de Interaccin. 2. Representarlas en un diagrama de clases. 3. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual.

4. Aadir los mtodos, segn aparecen en los Diagramas de Interaccin. 5. Aadir informacin de tipo a los atributos y mtodos. 6. Aadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. 7. Aadir flechas de navegabilidad a las asociaciones para indicar la direccin de visibilidad de los atributos. 8. Aadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos. Algunos de estos pasos se van realizando segn se vayan completando los Diagramas de Interaccin correspondientes. No existe precedencia entre la realizacin del Diagrama de Clases de Diseo y los Diagramas de Interaccin. Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja primero ms en el de clases y otras veces se trabaja primero ms en los de interaccin. No todas las clases que aparecan en el Modelo Conceptual tienen por qu aparecer en el Diagrama de Clases de Diseo. De hecho, tan solo se incluirn aquellas clases que tengan inters en cuanto a que se les ha asignado algn tipo de responsabilidad en el diseo del sistema. No hay, por tanto, un transicin directa entre el Modelo Conceptual y el Diagrama de Clases de Diseo, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensin de un dominio, y el segundo en una solucin software. En el Diagrama de Clases de Diseo se aaden los detalles referentes al lenguaje de programacin que se vaya a usar. Por ejemplo, los tipos de los atributos y parmetros se expresarn en el lenguaje de implementacin escogido. IV.4.4.3 Navegabilidad La navegabilidad es una propiedad de un rol (un extremo de una asociacin) que indica que es posible navegar unidireccionalmente a travs de la asociacin, desde objetos de la clase origen a objetos de la clase destino. Como se vio en la parte II, se representa en UML mediante una flecha. La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la clase origen. En la implementacin se traducir en la clase origen como un atributo que sea una referencia a la clase destino. Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una funcin, deben ser necesarias, si no es as deben eliminarse. Las situaciones ms comunes en las que parece que se necesita definir una asociacin con navegabilidad de A a B son: A enva un mensaje a B. A crea una instancia B. A necesita mantener una conexin con B. IV.4.4.4 Visibilidad de Atributos y Mtodos Los atributos y los mtodos deben tener una visibilidad asignada, que puede ser: + Visibilidad pblica. # Visibilidad protegida. - Visibilidad privada. Tambin puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementacin que sean necesarios para completar el Diagrama de Clases. IV.4.5 Otros Aspectos en el Diseo del Sistema En los puntos anteriores se ha hablado de decisiones de diseo a un nivel de granularidad

fina, con las clases y objetos como unidades de decisin. En el diseo de un sistema es necesario tambin tomar decisiones a un nivel ms alto sobre la descomposicin de un sistema en subsistemas y sobre la arquitectura del sistema (ver seccin III.2.5). Esta parte del Diseo de Bajo Nivel es lo que se denomina Diseo del Sistema. Estas decisiones no se toman de forma distinta en un desarrollo orientado a objetos a como se llevan a cabo en un desarrollo tradicional. Por tanto, no se va a entrar en este documento en cmo se realiza esta actividad. S hay que tener en cuenta que las posibles divisiones en subsistemas tienen que hacerse en base a las clases definidas en el Diagrama de Clases del Diseo.

3.2.6 Arquitecturas de referencia para lneas de productos.

III.2.4 Diagramas de Despliegue III.2.4.1 Tcnicas ms comunes de modelado a) Modelado de un sistema empotrado El desarrollo de un sistema empotrado es ms que el desarrollo de un sistema software. Hay que manejar el mundo fsico. Los diagramas de despliegue son tiles para facilitar la comunicacin entre los ingenieros de hardware y los de software. Para modelar un sistema empotrado es necesario: Identificar los dispositivos y nodos propios del sistema. Proporcionar seales visuales, sobre todo para los dispositivos poco usuales. Modelar las relaciones entre esos procesadores y dispositivos en un diagrama de despliegue. Si es necesario hay que detallar cualquier dispositivo inteligente, modelando su estructura en un diagrama de despliegue ms pormenorizado. b) Modelado de un sistema cliente servidor La divisin entre cliente y servidor en un sistema es complicada ya que implica tomar algunas decisiones sobre dnde colocar fsicamente sus componentes software, qu cantidad de software debe residir en el cliente, etc. Para modelar un sistema cliente/servidor hay que hace lo siguiente: Identificar los nodos que representan los procesadores cliente y servidor del sistema. Destacar los dispositivos relacionados con el comportamiento del sistema. Proporcionar seales visuales para esos procesadores y dispositivos a travs de estereotipos. Modelar la tipologa de esos nodos mediante un diagrama de despliegue. III.2.5 Arquitectura del Sistema III.2.5.1 Arquitectura de tres niveles La llamada Arquitectura en Tres Niveles, es la ms comn en sistemas de informacin que adems de tener una interfaz de usuario contemplan la persistencia de los datos. Una descripcin de los tres niveles sera la siguiente: Nivel 1: Presentacin ventanas, informes, etc. Nivel 2: Lgica de la Aplicacin tareas y reglas que gobiernan el proceso. Nivel 3: Almacenamiento mecanismo de almacenamiento.

III.2.5.2 Arquitectura de tres niveles orientadas a objetos a) Descomposicin del nivel de lgica de la aplicacin En el diseo orientado a objetos, el nivel de lgica de la aplicacin se descompone en subniveles que son los siguientes: Objetos del Dominio: son clases que representan objetos del dominio. Por ejemplo en un problema de ventas, una Venta sera un objeto del dominio. Servicios: se hace referencia a funciones de interaccin con la base de datos, informes, comunicaciones, seguridad, etc. III.2.5.3 Arquitectura MULTI-nivel La arquitectura de tres niveles puede pasar a llamarse de Mltiples Niveles si tenemos en cuenta el hecho de que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada uno de ellos cada vez ms. Por ejemplo el nivel de Servicios, se puede descomponer en servicios de alto y de bajo nivel, identificando como de alto nivel los servicios de generacin de informes y como de bajo nivel los de manejo de ficheros de entrada y salida. El motivo que lleva a descomponer la arquitectura del sistema en diferentes niveles es mltiple: Separacin de la lgica de la aplicacin en componentes separados que sean ms fcilmente reutilizables. Distribucin de niveles en diferentes nodos fsicos de computacin. Reparto de recursos humanos en diferentes niveles de la arquitectura. III.2.5.4 Paquetes La forma que tiene UML de agrupar elementos en subsistemas es a travs del uso de Paquetes, pudindose anidar los paquetes formando jerarquas de paquetes. De hecho un sistema que no tenga necesidad de ser descompuesto en subsistemas se puede considerar como con un nico paquete que lo abarca todo. Grficamente un paquete viene representado como se indica en la Figura 34.

Figura 34 Representacin de un paquete en UML En la Figura 35, vemos cmo se representa la arquitectura del sistema con la notacin de paquetes.

Figura 35 Arquitectura de un sistema utilizando paquetes III.2.5.5 Identificacin de Paquetes Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora de agrupar los diferentes elementos en paquetes. Conviene agrupar elementos que proporcionen un mismo servicio. Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de cohesin, es decir deben estar muy relacionados. Los elementos que estn en diferentes paquetes deben tener poca relacin, es decir deben colaborar lo menos posible.
http://www.clikear.com/manuales/uml/modelofisico.asp 4 Pruebas de software.

Fases de Implementacin y Pruebas

Una vez se tiene completo el Diagrama de Clases de Diseo, se pasa a la implementacin en el lenguaje de programacin elegido. El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se puede probar con los futuros usuarios, e incluso poner en produccin si se ha planificado una instalacin gradual. Una vez se tiene una versin estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo. [Booch99] El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson.

Addison Wesley Iberoamericana, 1999. [Fowler99] UML Distilled. M. Fowler, K. Scott. Addison-Wesley, 99. [Larman99] UML y Patrones. C. Larman. Prentice Hall, 1999. [OMG99] Unified Modeling Language Specification, v1.3. Object Management Group (OMG), 1999. [OMG02] UML Home Page. Object Management Group (OMG). http://www.uml.org/
4.1 Definiciones. 4.1.1 Prueba, caso de prueba, defecto, falla, error, verificacin, validacin.

Prueba de software Ejecucin de un programa con la intencin de descubrir un error tcnica experimental para la bsqueda de errores en los programas Tipos de pruebas Unidad integracin validacin sistema

4.1.2 Relacin entre defecto-falla error. 4.1.3 Pruebas estructurales, funcionales y aleatorias. 4.1.4 Documentacin del diseo de las pruebas. 4.2 Proceso de pruebas. 4.2.1 Generar un plan de pruebas. 4.2.2 Disear pruebas especificas. 4.2.3 Tomar configuracin del software a probar. 4.2.4 Configurar las pruebas. 4.2.5 Evaluar resultados. 4.2.5.1 Depuracin. 4.2.5.2 Anlisis de errores. 4.3 Tcnicas de diseo de casos de pruebas. 4.4 Enfoque prctico recomendado para el diseo de casos. 4.5 Estrategias de aplicacin de las pruebas. 4.5.1 De unidad. Pruebas de unidad Errores interfaces entre mdulos interfaces entrada/salida estructuras de datos locales clculos flujo de control caminos de procesamiento de errores

Pruebas de unidad Necesitamos drivers (conductores) stubs (resguardos) driver Unidad bajo prueba stub_C stub_A stub_Y
4.5.2 De integracin. Pruebas de integracin Errores comunicacin a travs de la interface efectos colaterales perniciosos acumulacin notable de errores de clculo acceso incoherente a estructuras de datos globales tiempos de respuesta Pruebas de integracin estrategias descendente ascendente sandwitch

4.5.3 Del sistema.

4.5.4 De aceptacin.

http://lsi.ugr.es/~ig1/docis/pruso.pdf 5 Implantacin y mantenimiento.

Factibilidad Econmica

Se refiere a los gastos que pueda generar durante el desarrollo del sistema, el cual se traduce principalmente en gastos de papelera (cintas de impresoras, fotocopias, hojas blancas, encuadernacin, entre otros) y otros gastos como energa elctrica e Internet mostrada en la tabla nmero 2; Hay que destacar que esta investigacin no busca ninguna renumeracin o beneficio econmico. En cuanto a los recursos necesarios para el desarrollo de "PCSOFT", se utilizar la informacin obtenida de las entrevistas no estructuradas (anexo 2) que se aplicarn a los futuros usuarios potenciales del sistema PCSOFT.

Factibilidad Operativa

El sistema PCSOFT podr ser utilizado por cualquier persona que sepa manejar un computador y este interesado por el tema. Adems esta investigacin podr ser utilizado en un futuro como soporte para la realizacin de un sistema que pueda ser portado a una plataforma WEB que podr ser visitado por una gran cantidad de usuarios a travs de Internet. En cuanto al mantenimiento del sistema, solo se requiere algunas actualizaciones, para que su contenido siempre este vigente.
Factibilidad Tcnica

Hardware:
o o o o o o o o o o o Tarjeta madre pii celeron/ video 8 mb Disco duro de 6.0 gb Ram 64 mb Monitor svga 14 Modem 56kb Caja minitower Teclado 101/102 teclas Floppy 3.5 hd Kit multimedia 24x Scanner PlusTek Opticpro p12. Hewlett Packard Deskjet 840c

Software:
o o o o o o Sistema Operativo: Windows Millenium. Lenguajes de Programacin: Macronedia Director 8.5 Suite de Oficina: Microsoft Office 2000 Software Publicitario: Microsoft Publisher 2000 Software de Diseo Grfico: Corel Draw 8 Software Compresor de Datos: Winzip 7.0

CRONOGRAMA DE ACTIVIDADES El siguiente cronograma est basado en el diagrama de Gantt, referenciado por Senn (1989). Este diagrama consiste en un grfico de barras donde las ordenadas representan las actividades y las abscisas el tiempo, representado en meses. La lnea punteada de la grfica indica la fase actual del desarrollo del sistema.

Actividades

Tiempo en Meses

1,5

0,5

1,5

0,5

Fuente: Elaboracin Propia. GLOSARIO DE TERMINOS

CEKIT: Compaa Editorial Electrnica. CETTICO: Centro de transferencia tecnolgico en Informtica y Comunicaciones. Hardware: parte fsica o material de una computadora. MOOM: Metodologa orientada a objetos para desarrollar software multimedia. Multimedia: Tecnologa que permite combinar sonidos, fotografas, grficos, datos y videos, integrndolos para diversos fines. PC: Siglas de Personal Computer. Plataforma presentada por IBM en 1981. PCSOFT: Soporte multimedia para el mantenimiento y reparacin de PC en su nivel bsico. Perifrico: cualquier dispositivo o mquina que pueda conectarse a una computadora. Existen perifricos de entrada, de salida y de entrada/salida. Sistema Operativo: es un conjunto de programas que hacen un enlace entre el usuario y la mquina, a fin de facilitar su utilizacin. Software: es la parte lgica que trabaja una computadora.

5.1 Implantacin e Integracin de casos de uso y componentes de software.

Etapa de Desarrollo e Implantacin En esta etapa, el auditor en informtica va a ejercer su funcin de manera prctica, es decir, comienza a ejecutar sus tareas con profesionalismo, tica personal y aplicando sus conocimientos y experiencias, de acuerdo con el plan aprobado en la etapa anterior; con el fin de obtener un producto final de calidad y beneficios tangibles para el negocio. Esta Fase comprende los siguientes puntos explicados paso por paso:

Concertacin de fechas:

Fechas de entrevistas, de visitas y de aplicacin de cuestionarios. La accin es inmediata y hay que corroborar las fechas aprobadas o actualizadas. Las visitas se realizan con el objetivo de validar el uso de polticas y procedimientos de seguridad y control, como el registro de acceso a centros de cmputo y reas en donde existe documentacin o tecnologa importante para el negocio. Se solicita al responsable de informtica una lista con los nombres, puestos y departamentos del personal de informtica y de las reas usuarias involucradas en el proyecto.

Verificacin de las tareas y productos involucrados:

El personal involucrado tambin debe ser revisado al igual que tareas y productos. Se verifica si la tarea anterior alter el orden de las acciones mencionadas en el plan detallado, y hay que asegurar que los cambios sean mnimos y de bajo impacto en el plan. Tambin se tienen que documentar los cambios necesarios y justificados.

Clasificar tcnicas y herramientas:

Verificar la lista de mtodos, tcnicas y herramientas sugeridas por el rea auditada, junto con los cuestionarios sugeridos con el objetivo de asegurar que sean los requeridos para cada rea que se auditar. Actualizar cuestionarios solo si es necesario, y elaborar la entrevista con base en la experiencia, cuestionarios y necesidades del proyecto.

Realizacin de entrevistas y cuestionarios:

Efectuar cada una de las entrevistas en las fechas y horas planeadas y aplicar cada uno de los cuestionarios en las fechas planeadas. (siempre hay que documentar todo los hechos). Obtener apoyo requerido (reportes, copias, documentos fuente, entre otros). Registrar entrevistas y cuestionarios pendientes.

Efectuar visitas para la verificacin:

Hacer visitas a centros de cmputos o a los usuarios de informtica. Notificar la visita a los representantes de dicho departamento. Registrar la informacin ms relevante y obtener el soporte requerido. Registrar visitas pendientes.

Elaboracin de informes preliminares:

Por lo general son de largo plazo y su informacin es sacada detalladamente de las vistas realizadas, comentarios documentados y previamente analizados. Luego se elabora observaciones y conclusiones de cada uno de los componentes y reas auditadas y llenar la hoja de resumen de observaciones y recomendaciones de la auditora informtica.

Revisin de estos informes:

Se tiene que verificar detalladamente cada rea comprendida con la ayuda de borradores revisados. Asegurarse de registrar por escrito el soporte requerido para validar cada una de las observaciones (copias de reporte, documentos fuente, etc.). Y por ultimo, concertar citas con el responsable de informtica y los usuarios para sacar conclusiones.

Clasificacin y documentacin de los informes, para su correcta lectura:

Registrar de manera formal cada observacin, conclusin y recomendacin sugerida, revisada y aprobada y luego clasificar la informacin por componente de rea auditada.

Finalizacin de tareas o productos pendientes:

Se analizar la informacin emanada de cada entrevista, visita o cuestionario, y luego actualizar, documentar y clasificar el informe de la auditora.

Elaboracin del informe final de la auditora en informtica:

Elaborar un informe orientado a la alta direccin y otro mas detallado (que contenga antecedentes, observaciones, recomendaciones, etc.) para el responsable de informtica y los usuarios clave.

Presentacin a la alta direccin e involucrados clave:

Se debe verificar que los informes sean claros, completos y congruentes entre s. Comprobar que se encuentre con el soporte documentado de lo mencionado en los informes y formalizar la fecha de la presentacin de informes a la alta direccin.

Aprobacin del proyecto y compromiso ejecutivo:

Se obtiene la aprobacin y el compromiso formal de la alta direccin para luego elaborar un plan de implantacin general de acciones sugeridas y clasificadas por plazos sugeridos. Luego se presenta el costo beneficio del plan a seguir. Y por ultimo se delega a informtica y las reas usuarias la implantacin de las acciones recomendadas. En este momento nos encontramos en la etapa media del proceso de la auditora. La etapa de formalizacin ya se encuentra determinada, y la etapa de desarrollo se encuentra en ejecucin, para pasar luego a la etapa de implantacin. Esta es la ms importante para los involucrados en el proyecto de auditora en informtica, ya que termina la tarea de los auditores y comienza para los responsables de las reas usuarias y de informtica. Ellos ejecutaran las acciones recomendadas en los informes detallados y aprobados por la alta direccin. La funcin del auditor se convierte as en una labor de seguimiento y apoyo. Los elementos clave de la etapa de implantacin son:

Definicin de requerimientos para el xito de la etapa de implantacin (la ejecuta el responsable de informtica):

Se analizan algunos aspectos (recursos humano, materiales tecnolgicos, inversiones, etc.) que se necesitan para ejecutar las acciones recomendadas en los plazos acordados anteriormente.

Desarrollo del plan (tambin a cargo del responsable de informtica):

Se documentan dichos requerimientos y, de ser necesario, solicitar la aprobacin de la alta direccin.

Implantacin de las acciones sugeridas por auditoria en informtica (responsable de inf.):

Primero hay que verificar que se cuente con los recursos estimados en la tarea anterior. Consultar los informes para verificar acciones y tiempos de terminacin Elaborar un plan de implantacin que tenga:

Tareas Productos terminados

Responsables e involucrados Fechas de inicio y trmino Fechas de revisin Verificar tareas, productos terminados, etc. del plan de implantacin Ejecutar cada una de las tareas Seguimiento a la implantacin (esta tarea le corresponde al auditor en informtica):

Tiene que solicitar el plan de implantacin para revisar su congruencia con los informes de la auditora en informtica. Luego comprobar el cumplimiento formal de las tareas en los tiempos y formas que considere convenientes para asegurar resultados. Documentar debilidades y anomalas relevantes. Y por ultimo, sugerir acciones para el cumplimiento oportuno de la implantacin al nivel que se considere pertinente.

http://html.rincondelvago.com/calidad_2.html http://www.monografias.com/trabajos11/antep/antep.shtml#ALCAN 5.2 Mantenimiento del software. Hay que tener un buen plan de mantenimiento del programa de software para competir y dar calidad al producto dentro del mercado. Para lograr lo anterior debemos tener disponible un mantenimiento correctivo que nos permita resolver problemas emergentes, un mantenimiento preventivo que ayude a resolver posibles fallas y a mejorar el producto es decir; una constante renovacin y mejora. Siempre debemos tomar en cuenta lo anterior para programar la publicacin de nuevas versiones al mismo tiempo que desarrollamos a la par nuevos programas adyacentes que sirvan ya sea como interfase o como herramientas de paquetes y soporte. Por ltimo hay que planear un soporte controlado a usuarios y ofrecer la garanta del producto requerida por el mercado.

http://www.software.net.mx/desarrolladores/minegocio/mktventas/Desarollo+y+Venta+de+ mi+software.htm