PRISMA: Towards Quality, Aspect Oriented and Dynamic Software Architectures Jennifer Pérez, Isidro Ramos, Javier Jaén, Patricio Letelier Department of Information Systems and Computation Politechnic University of Valencia Camino de Vera s/n E-46071 Valencia – Spain
Abstract The development of software systems must be done using platforms that allow the description of quality, complex, distributed, dynamic and reusable architectural models. We present in this paper PRISMA, an architectural modelling approach based on aspects and components, that uses a component definition language (components, connectors and systems) to define architectural types at a high abstraction level and a configuration language to design the architecture of software systems. The component definition language increases reuse allowing importation of COTS and reduces complexity by integrating two modern software development approaches: Component-Based Software Development and Aspect-Oriented Software Development. The configuration language designs the architecture of software systems by creating and interconnecting instances of the defined types including possible imported COTS. PRISMA has a metalevel with reflexive properties for these two languages. For this reason, the types of PRISMA may evolve and the topologies of PRISMA may be reconfigured dynamically. Key Words: Software Architecture, Component Definition Language, Configuration Language, Components, Aspects, Reuse, Evolution, Quality
1. Introduction Nowadays, information systems are more and more difficult to develop due to their complex structures and
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
{jeperez | iramos | fjaen | letelier}@dsic.upv.es Elena Navarro Department of Computer Science University of Castilla-LaMancha Avda. España s/n 02071 Valencia – Spain
[email protected] dynamic nature. The high competitiveness of the market and the volatile business rules generate continuous changes on the information systems requirements. For these reasons, the development of software systems must be done using platforms that allow the description of quality, complex, distributed, dynamic and reusable architectural models. Moreover, these architectural models must satisfy the quality requirements established by the product and the user. The object oriented approach cannot account for all the requirements of current and complex information systems. For this reason, two approaches for developing software systems have emerged: Component-Based Software Development (CBSD) and Aspect-Oriented Software Development (AOSD). The high competitiveness increases the relevance of the evolution and reuse in order to minimize the time and the cost invested in the development and maintenance processes. As a consequence, the COTS (commercial off-the-self) importation has acquired relevance, because tools that allow the reuse of its components and the COTS importation achieve the highest reuse and a quality code. Concerning software evolution, it is important to take into account the two types of software evolution: requirements-driven and context-driven. The first one is the change of the user requiremens and second one is the change of the context where the applications are actually run. If a model can support these two types of software evolution in a simply and natural way, it will improve the quality behavior of its applications.Apart from these quality factors, there are others that should be considered in the development of architectural models in order to improve the architectural systems. Currently, it is difficult to find an approach that overcome all these issues. For this reason, we present in this paper an approach which achieves to cover them.
This approach is called PRISMA and uses an extension of OASIS [15] to define the semantics of architectural models in a formal way. OASIS is a formal language to define conceptual models of object-oriented information systems. Its extension has been necessary because despite of the fact that it verifies and generates applications automatically from the object-oriented conceptual models (Model compiler), does not allow to specify software architectures. In this way, PRISMA preserves the OASIS advantages that are very useful for validating its architectural models. In PRISMA two languages are defined: a component definition language and a configuration language. Both languages can be compiled to generate automatically the code of the product following the paradigm of automatic programming [3].The component definition language defines architectural types with a high abstraction level, its main advantages are software reuse allowing importation of COTS and complexity reduction by integrating two modern software development: CBSD and AOSD. The configuration language designs the architecture of software systems by creating and interconnecting instances of the defined types including all the imported COTS. In other words, this language specifies the topology of an specific software system. Every type of our architectural model consists of a set of aspects: functional, distribution, coordination, quality, context-awareness, etc. This is the PRISMA way of combining CBSD and AOSD. In addition, PRISMA supports the requierements-driven and context-driven evolution. The former is solved by means of a metalevel and reflexive properties for the two presented languages and the latter defining a context-awareness aspect. The PRISMA metalevel allows the evolution types and the dynamic reconfiguration of topologies. Each aspect of a type has a base level and may have a metalevel. The metalevel reifies the properties that may be evolved following the OASIS reflection ([6]). Apart from the quality provided by evolution and reuse, PRISMA takes into account other quality attributes in the quality aspect in order to achieve quality architectural models The structure of the chapter is the following: first, a brief summary of related work is given. In Section 3 the PRISMA architectural model, the metamodel, and the component definition and configuration languages are presented and described. In section 4 conclusions are shown and finally, future work is presented in section 5.
2. Related Work A great deal of work has been done so far dealing with architectural models, components, architecture definition languages, dynamic reconfiguration and other aspects related with the implementation of complex
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
systems. Part of the work is focused on finding a consensus about the different concepts and approaches but due to the lack of a semantic commitment in the field, an important formalization effort is required to achieve a reasonable level of integration. We take into account different solutions of interest for our model: Component Based Design and the Separation of Concerns or Aspect Oriented Programming together with a powerful reflexive metalevel. The smooth integration of the considered solutions and the high abstraction level are the main features of PRISMA. The work developed by Garlan ([10]) has been of great inspiration for us in our effort to define the first order citizens of our model. The main types defined are: systems, connectors, components, in/out ports, in/out roles and interfaces. Also the work by Andrade & Fiadeiro ([And01]) about the notion of contract has been considered making a difference from the one presented in [18] and [5]. Our motivation is similar to the Model-Driven Architecture (MDA) approach proposed by the OMG group ([20]) for system's interoperability and integration. MDA encourages modelling using UML extensions in an independent way of the final implementation platforms. They propose separation of concerns and different abstraction levels in the modelling process. Transformation techniques and inter-level relationships are used in order to produce the final implementation. A wide variety of Component Definition Languages has been proposed. Each one has positive and negative aspects. An interesting comparison between these languages is done in the work by [17]. The proposal by Loques & Leite ([16]) is very similar to our approach. Their Model R-RIO incorporates dynamic reconfiguration by means of a reflexive architecture but the use of a metalevel is quite different from ours. Other approaches use metaprogramming techniques but at an implementation level such as the work by [9]. In GUARANA [19] a complex metalevel is defined at compilation time in an ad-hoc and independent way of the proposed model. The Separation of Concerns approach followed in the Aspect Oriented Design methods such as the work by [2] has also been taken into account in our model. But we use a higher abstraction level, namely conceptual design. We consider that it is very important to provide a graphical notation for the PRISMA languages. There are several works that study the use of UML for the description of software architectures ([10, 14]). All of them agree with the fact that UML (at least 1.4 version) is not the solution because there are types (ports, connectors, etc) that do not have a direct representation. For this reason, there are some works that propose modifications using UML extension mechanisms
[18,23]. However, the announced 2.0 UML version could solve these problems. Due to the strong momentum of UML and its support by modern software production tools we consider UML as the first alternative for the graphical representation of PRISMA. Nowadays, there are different proposals to measure the quality attributes, some of them measure attributes qualitatively and the remaining ones quantitatively. Moreover, some proposals automate some of their activities as Win-Win[11], NOFUN[4], QRL[22]. We decided to select QRL to specify our quality attributes, because it has a precise operational semantics allowing an automatic trading and negotiation process. Context awareness is not a new idea but it is a very important issue when developing and maintaining selfconfigurable or auto-adaptative aplications. A detailed study of context aware applications is described in [8] and divides such applications in three categories. The first category includes applications that present context dependent information and services to the user. The second category are applications that start services automatically when certain contextual conditions are met. The third category involves applications that tag information with some description of context (e.g. the context in which the information was obtained). Concerning the languages supporting the model we will use extensions of our OASIS specification language to cope with the specifications of the different aspects at the base level and the meta-level of the PRISMA Model. Model Compiler Techniques will be used to generate the final implementation code for each aspect.
Distribution Aspect: The distribution aspect specifies the features that define the dynamic relocation of the instances. Quality Aspect: The quality aspect specifies the non functional quality requirements. The Quality Requirements Language (QRL) [22] is used to describe the quality attributes of a type. QRL has a precise operational semantics allowing an automatic trading and negotiation process. In this way we include in our PRISMA model the automatic generation of MultiOrganisational Web-based Systems applications. Context-Awareness Aspect: The context-awareness aspect provides context-information and supports inspection in order to retrieve the structural properties of the provided information. Evolution Aspect: The evolution aspect specifies the evolution of types due to changes on the information system’s requirements. This aspect is based on the concept of OASIS reflection to provide types dynamic behaviour. The reflection allows to change the structure and the behaviour of a type. A type (component, connector, system) of our architectural model can be seen as a prism. This prism has one side for each aspect. We must take into account that the evolution aspect is not a separate side of the prism but rather is on the top of each side of the prism at the metalevel (see figure 1). Each side will define a metalevel if some types in the side reifies some property of the base level. Any section of the OASIS specification can undergo this reification process giving the languages their reflexive capability.
3. Architectural Model PRISMA is a model to define architectures of complex software systems. The PRISMA types are defined by composition of aspects: functional, quality, distribution, coordination, etc, and may vary depending on the architectural type and the information system kind under consideration. The code overlapping [13,21] problem of the AOSD is solved by our model because aspects integration is done with a high abstraction level and code generation for each aspect is done independently. Next we present several aspects that a PRISMA type may include. Functional Aspect: The functional aspect captures the semantics of the information system by defining its structure and behaviour. Coordination Aspect: The coordination aspect defines the business rules and the synchronisation between types during its communication. Moreover the choreography or protocol is defined, extending the “contract” concept of Andrade & Fiadeiro ([1]).
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
Figure 1. A Prisma Type
The reification is done from the base level. For this reason, it is impossible that a type specifies its metalevel without its base level. The relationship between metalevel and base level within one aspect is 1:N. Our architectural model consists of different types. All them are in the metamodel of PRISMA (figures 2-6) so that they may be modified by means of the reflection mechanism. Next the different types are described.
Interface: An interface defines a set of services. There are different types of interfaces, one for each type of aspect.
Connector: A connector is a type of the information system which acts as a coordinator between elements. It is composed by aspects (coordination, functional, distribution, quality, context-awareness, etc) and a set of inroles and outroles, whose type is a specific interface. Connectors link and synchronise components, systems and other connectors by means of their roles.
Figure 2. Interfaces section of the PRISMA metamodel
Aspect: An aspect defines completely the structure and the behaviour of an element from a specific point of view. An aspect is the join of a set of interfaces and the semantics specification of its structure and behaviour (state changes, triggers, protocols, etc). There are different types of aspects: functional, distribution, coordination, quality, context-awareness, etc. Each one is defined in an orthogonal way.
Figure 5. Connectors section of the PRISMA metamodel
System: A system is a component that includes a set of connectors, components and other systems correctly connected. From this composition emergent properties may arise. Moreover, a system defines its bindings between its ports and the ports of the included components.
Figure 3. Aspects section of the PRISMA metamodel
Component: A component is a type of the information system which does not act like a coordinator between other elements. It is composed by a set of aspects (functional, distribution, quality, context-awareness, etc) and by one or more inports and outports, whose type is an specific interface. Components interact with other architectural types by means of their ports.
Figure 4. Components section of the PRISMA metamodel
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
Figure 6. Systems section of the PRISMA metamodel
3.1. Component Definition Language The component definition language of PRISMA defines the types of the architecture. This language has as first-class constructors: interfaces, aspects, components and connectors. The fact that interfaces and aspects are first-class constructors increases reusability because an interface may be used by several aspects and an aspect may be used by several types of elements. Moreover, components, connectors and systems may be reused in different architectural models. The model allows for COTS importation because the specification of aspects is optional. In this case, elements of PRISMA are like black boxes with specific quality requirements. Whenever the type is a COTS, the functional aspect is not present and the quality aspect is interpreted as a query. The query process consist on
searching and trading in the web components or web services that satisfy the established non-functional quality requirements. At the end of this process, the component is instantiated to the one found maximising the utility criteria specified in the non-functional quality requirements. However, there are COTS that make the valuation of the product’s quality difficult because their quality attributes are either not specified in a precise way or not defined at all. This is a disadvantage because no automatic selection and valuation processes of COTS based on these attributes may be implemented. If the functional aspect is present, i.e. non imported component, the non-functional quality requirements adds quality information to the component. In this case, the quality aspect establishes the quality rating of the type and its instances must satisfy this quality rating in all theirs life cycles. 3.1.1. Interfaces and Aspects. A functional interface specifies a set of services, their parameters and types. An interface describes the partial view that an element has one of the aspect of another element. A functional aspect is specified using the OASIS elemental class template presented in [15]. This template describes attributes, services, valuations, derivations, preconditions, triggers, integrity constrains and the protocol of a component. Next, interface definitions and one functional aspect are presented. In this example we can see the functionality of a component which bids in on an electronical auction. The Bidder defines the semantics of Bidding and Maintenance interfaces and specifies this functionality modifying attributes (constants and variables) by means of valuations and protocols. In the valuations section of the Bidder aspect, the effect of executing ChangeLowPlayer is described. In the protocols section, the allowed lives of a component instance are specified based on relevant states. Interface Bidding { Bid; Pay; }
Interface Maintenance { Create; Update; ChangeLowPlayer(state: boolean); Destroy; }
Functional Aspect Bidder specifies Bidding, Maintenance
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
{ Constant Attributes Identifier: string; Name: string; SurName: string; Variable Attributes Address : string; VisaNumber : string; ExpireVISA: date; LowPlayer: boolean; DEFAULT false; Private_Services Create; Update; ChangeLowPlayer(state:boolean); Destroy; Bid; Pay; Valuations [ChangesLowPlayer(state)] LowPlayer = estate; Protocols CREATION { create.BIDDER; BIDDER { update + ChangeLowPlayer.LOWPLAYER + bid + pay + destroy; LOWPLAYER { update + ChangeLowPlayer.BIDDER + destroy; }
In the component, distribution aspect specifies services to obtain metrics values in order to implement complex distribution strategies as the ones shown in [24, 7]. In connectors and systems, it defines the distribution policies and strategies to be applied at run time following the gathered measures of the established metrics. The specification of co-ordination interfaces is very similar to that proposed for other types of interfaces. A coordination aspect specifies the attributes, services, synchronizations and connectors’ choreography. This aspect cannot be specified in components and systems. Synchronizations define the allowed connections between roles types. This specification is realized by means of interfaces in order to achieve a higher abstraction level and to increase the reuse of coordination aspects so that a coordination aspect can be used by several types of connectors. The choreography specifies the coordination process, the glue that the connector applies to synchronise its connected types. The choreography is specified by means of interfaces. The quality interfaces offer services to measure the quality of a component. A quality aspect specifies the quality attributes that the system wants to evaluate, the quality level that the type must satisfy and the different metrics to use in order to measure the quality of a type.
The quality can be measured at different levels of granularity inside a product software (complete application, component, interfaces, use case, web service, etc). In our model, the quality aspect measures the quality of components and connectors. However, a systems quality is the combination of the valuations of the types that are included. Context-awareness must give specifications of five interfaces [12]: ISource, IGatherer, IAggregator, IAnalyzer and INotifier. These interfaces are defined in the context-awareness aspect of PRISMA. - ISource: its services are related to schema management. - IGatherer: its services gather context information from sources at a given rate (sampling period) and cache the corresponding information - IAggregator: its services elaborates complex information by correlating information provided by other parties. - IAnalyzer: its services establish categories and assign descriptors to such categories. - INotifier: its services provides the asynchronous notification of information. 3.1.2. Components, Connectors and Systems. A component has a collection of input and output ports whose types are functional or distributed interfaces. Consequently, two kinds of ports can be defined, those acting on a component’s functional and a distributed aspects respectively. Input ports define all the attributes and services that are offered to external types (server behaviour) whereas output ports define attributes and services that are required from other types (client behaviour). A component definition must always contain a functional aspect (except COTS). However, having a distributed aspect is optional and only components exhibiting a distributed behaviour should incorporate it. It is important to note that only the interfaces (functional or distributed) existing in a component’s definition are valid candidate types when defining new ports. A connector’s definition consists of two types: a set of input and output roles, and a list of allowed types of components, systems or other connectors that can be eventually connected. Roles have the same semantics as ports in components. In other words, each role in a connector must have a type which is selected among the available functional or distributed interfaces defined in the connector. However, coordination interfaces may not be used when defining roles. These interfaces are used instead to make visible a given coordination aspect to external types. All the above requirements make
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
functional and a co-ordination aspects mandatory whereas distributed ones are still optional. Finally, a system’s definition is equivalent to that of a component because a system is a complex component. Therefore, a system is a composition of connected types (components, connectors and nested subsystems) with emerging functional and distributed aspects. Let us note that including a connector in a system’s definition results in including also all the types that are connected by the connector (components, other connectors and systems). Additional connections must be specified when defining a system. These are called bindings and connect the system with its internal types by means of well known interfaces (similar to every synchronization in connectors). Component Customer { Inports Inport1: Maintenance ; Outports OutPort1: Bidding; Functional Aspect Bidder;
} 3.1.3. Evolution Aspect. A metalevel can be constructed automatically from the component’s definition language. This metalevel serves the purpose of enabling evolution of certain linguistic types in a specification. In order to achieve this goal, i.e. being able to automatically obtain a metalevel, a reification process for those evolving types must be defined. In our approach a reify operator is proposed whose operational semantics will allow for an automatic reification process. Its semantics will certainly depend on the linguistic granularity to which it is applied. Each linguistic construction to be reified will have a different metalevel generation which will be defined by means of specific transformation patterns. Evolution can be achieved at two levels: structural and behavioural. Structural evolution is achieved by reifying the properties or attributes of the types in a specification whereas behavioural evolution is achieved by reifying those sections that define some behaviour. This last kind of evolution incorporates kinematics to the language (behavioural evolution without structural change). All the types presented so far can be linguistically expressed as a term with a tree-like structure. So we can see the reify operator as a mapping between trees, one representing a sub-term in the specification language and another representing a sub-term at the metalevel. In order to perform this transformation the reify operator applies the proper pattern. The selected pattern will express how the matching term in the definition language is transformed into a proper term (describing metaproperties and meta-events) at the metalevel.
Auction1.Outport2>> IS1.Outport1;
3.2. The Configuration Language The configuration language is used to define instances and the topology of the architectural model. In order to do so all needed connectors, components and systems types must be imported. Then all the necessary instances of the imported types can be defined and, finally, the topology of the model is expressed by interconnecting such instances. Such interconnection process is achieved by creating instances of connector’s synchronizations and system’s binding. Next a simple arquitectural model for a simple auction system is presented. Figure 7 illustrates this example: two components Customer1 and Product1 are connected by means of the Auction1 connector and these three elements are encapsulated by a system, elements and the system are comunicated using bindings.
Fig. 7. An Architectural Model Example Architectural Model
Auction
Import Customer, Auction, Product, InformationSystem; Customer1: Customer; Auction1: Auction; Product1: Product; IS1: InformationSystem;
Product1.Outport1>> IS1.Outport2; } } End Arquitectural Model Auction;
4. Conclusions In this chapter a new model: PRISMA has been presented for software architectural modelling. Its main characteristics are the blending of Component Based Design and the Separation of Concerns or Aspect Oriented Programming. Both aspects together with the full use of reflexive techniques are introduced at a very abstract level: the Conceptual Model Specification Level. By means of a 3-tiers metalevel architecture the dynamic reconfiguration aspects are solved in a powerful way. PRISMA is a flexible and integrated model for the specification of complex architectural models of distributed and dynamic systems. The high abstraction level used facilitates the reuse of software artefacts and the independence of concerns by means of a separate compilation process using a Model Compiler approach. Two languages are used for specifying architectural models: the component definition language used for defining the different artefact types and the Configuration Language allowing the definition and combination of different instances of the previous types. COTS components are integrated in the system directly or as a result of a web-based trading process based on the Component Quality Aspect. Concerning the quality of the architectural models designed using PRISMA, first, they satisfy the established non-functional quality requirements, because the types must have into account the quality attributes specified in their quality aspect and the second, the architectural models have quality behabiour and code structure due to the reuse and evolution of PRISMA.
Attachements AuctionSession{ Bidder1.OutPort1 >> Auction1.InPort1; Auction1.OutPort1 >> Product1.InPort1; } System IS1{ Import Elements Bidder1, Product1, Auction1; Import Connections Auction Session;
BindingLinks{ IS1.Inport1 >> Bidder1.Inport1;
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
5. Future Work In the medium term a lot of work will be necessary for the PRISMA implementation. Model Compiler Techniques will be used for the generation of the Base level code (Top-Down Compiler) and the Metalevel Code (Bottom-up Compiler) from the different aspects specifications. We have selected UML as the graphical notation for the PRISMA languages and we are studying the correspondences between our types and its UML
representations. In a short time we want to present our graphical notation. A deeper understanding of the distribution, quality, co-ordination and dynamic aspects together with the introduction of new aspects will be also necessary. Long term work will include the beta- test of our approach in the problem arena.
Bibliography [1] L. F. Andrade, J. L. Fiadeiro, J. Gouveia, G. Koutsoukos, M. Wermelinger, “Coordination for Orchestration “ , 5th International Conference on Coordination Models and Languages COORDINATION, Lecture Notes in Computer Science 2315 Springer, York, UK, April 8-11, 2002, ISBN 3540-43410-0, pp. 5-13. [2] Aspect Oriented Software Development, http://aosd.net [3] R. Balzer, “A 15 Year Perspective on Automatic Programming”, IEEE Transactions on Software Engineering, November 1985, vol.11, num.11, pages 1257-1268. [4] P. Botella, X. Burgués, S. Franch, M. Huerta and G. Salazar, “Modeling non-functional requirements”, Actas de las Jornadas de Ingeniería de Requisitos Aplicada (JIRA), junio 2001. [5] A. Bracciali, A. Brogi, C. Canal, “Sistematic Component Adaptation”, In Proc IDEAS, La Habana, 2002. [6] J. A. Carsí, "OASIS como marco conceptual para la evolución del software". Ph.D. Thesis 1999. DSIC (Universidad Politécnica de Valencia). [7] S. Cheng, D. Garlan, B. Schmerl, P. Steenkiste & N.Hu, “Software Architecture-based Adaptation for Grid Computing“ , IEEE Conference on High Performance Distributed Computing, IEEE Computer Press, Scotland, July, 2002. [8] A. K. Dey & G. D. Abowd, “ Towards a better understanding of context and context-awareness”, Proceedings of the Workshop on the What, Who, Where, When and How of Context-Awareness, affiliated with the CHI 2000 Conference on Human Factors in Computer Systems, NY: ACM Press ,New York,. [9] F. McGurren, D. Conroy, “X-ADAPT: An Arquitecture for Dynamic Systems”, Workshop on Component-Oriented Programming, ECOOP, Málaga, Spain, 2002. [10] D. Garlan, A. Kompanek, “Reconciling the Needs of Architectural Description with Object-Modeling Notations”, Proceedings «UML» 2000, Springer, York, UK, October 2-6, 2000, LNCS 1939, pp.498-512. [11] H. In, D. Olson, T. Rodges, “Multi-criteria preference analysis for systematic requirements negotiation”, in Proceedings of IEEE International Computer Software and Applications Conference (COMP-SAC’2002), 2002. [12] J. Jaen, I. Ramos, “A Conceptual Model for Context-Aware Dynamic Architectures” Accepted at the 23rd International Workshop on Distributed Auto-adaptive and Reconfigurable Systems. To appear in IEEE Press, Rhodes Island, 2003 [13] G. Kiczales, E. Hilsdale, J. Huguin, M. Kersten, J. Palm, W.G. Griswold, “An Overview of AspectJ”, proceeding of the European Conference on Object-Oriented Programming, Springer-Verlag, 2001.
Proceedings of the Third International Conference On Quality Software (QSIC’03) 0-7695-2015-4/03 $ 17.00 © 2003 IEEE
[14] C. Kobrym, “Modeling Components and Frameworks with UML”. Comunications of ACM, 43(10); pp. 31-38. Octubre 2000 [15] P. Letelier, P. Sánchez, I. Ramos, O. Pastor, OASIS 3.0: "Un enfoque formal para el modelado conceptual orientado a objeto". Universidad Politécnica de Valencia, SPUPV -98.4011, ISBN 84-7721- 663-0, 1998. [16] O. Loques, A. Sztajnberg, J. Leite, M. Lobosco, "On the Integration of Meta-Level Programming and Configuration Programming", In Reflection and Software Engineering (special edition), Editors: Walter Cazzola, Robert J. Stroud, Francesco Tisato, V. 1826, Lecture Notes in Computer Science, SpringerVerlag, Heidelberg, Germany, June, 2000 pp.191-210. [17] N. Medvidovic, R. N. Taylor, “A classification and Comparison Framework for Software Architecture Description Languages”, IEEE Transactions of SW Engineering, Vol. 26, nº 1, January, 2000 [18] R. Monge, C. Alves, A. Vallecillo, “A Graphical Representation of COTS-based Software Architectures”, In Proc IDEAS, La Habana, 2002. [19] A. Oliva, I. C.Garcia, L. E. Buzato,“The Reflective Architecture of Guaraná”, Technical Report IC-98-14. Instituto de computación, Universidad de Campiñas, abril, 1998. [20] Object Management Group (OMG), http://www.omg.org [21] A. Rashid, “A Hybrid Approach to Separation of Concerns: The Story of SADES”, Third International Conference, REFLECTION 2001, Proceedings. Lecture Notes in Computer Science 2192 Springer , Kyoto, Japan, September 25-28, 2001, ISBN 3-540-42618-3, pp. 231-249 [22] A. Ruiz,“Una Aproximación Semicualitativa al Tratamiento Automático de Requisitos de Calidad: Aplicación a la Obtención Automática de Acuerdos de Nivel de Servicio en MOWS”, Ph.D. Thesis 2002. Departamento de Lenguajes y Sistemas Informáticos (Univesidad de Sevilla) [23] P. Kruchten, B. Selic, W. Kozaczynski,” Describing Software Architecture with UML”, Proceedings of ICSE , Toronto, Ontario, Canada, 12-19 Mayo, 2001 pp. 715-716. [24] Zinky J., Bakken D., Schantz R., “Architectural Support for Quality of Service for CORBA Objects,” Theory and Practice of Object Systems 3(1), 1997.
