Towards A QoS Modeling and Modularization Framework forComponent-based Systems

Sumant Tambe, Akshay Dabholkar, Aniruddha Gokhale, Amogh KavimandanDepartment of EECS, Vanderbilt University, Nashville, TN, USA

{sutambe, aky, gokhale, amoghk}@dre.vanderbilt.edu

Abstract

Current domain-specific modeling (DSM) frameworksfor designing component-based systems provide modelingsupport for system’s structural as well as non-functionalor quality of service (QoS) concerns. However, the focusof such frameworks on system’s non-functional concerns isan after-thought and their support is at best adhoc. Fur-ther, such frameworks lack strong decoupling between themodeling of the system’s structural composition and theirQoS requirements. This lack of QoS modularization limits(1) reusability of such frameworks, (2) ease of their mainte-nance when new non-functional characteristics are added,and (3) independent evolution of the modeling frameworksalong both the structural and non-functional dimensions.

This paper describes Component QoS Modeling Lan-guage (CQML), which is a reusable, extensible, andplatform-independent QoS modeling language that pro-vides strong separation between the structural and non-functional dimensions. CQML supports independent evolu-tion of structural metamodel of composition modeling lan-guages as well as QoS metamodel. To evaluate, we superim-pose CQML on a purely structural modeling language andautomatically generate, configure, and deploy component-based fault-monitoring infrastructure using aspect-orientedmodeling (AOM) techniques.

1 IntroductionRecent advances in domain-specific modeling

(DSM) [14] have resulted in DSM tool suites for de-signing large, component-based software systems withmultiple quality of service (QoS) requirements, such aspredictable latencies, fault-tolerance and security. Re-cent successes with DSM tools in this area include theEmbedded Systems Modeling Language (ESML) [9] foravionics mission computing, SysWeaver [5] for embeddedsystems, and our earlier work on the Platform IndependentComponent Modeling Language (PICML) [2] for a rangeof distributed, real-time systems. These DSM tools pro-

vide support for component-based software engineering(CBSE) [3] wherein systems can be modeled by compos-ing multiple different components, each encapsulating areusable unit of functionality.

Despite the number of benefits of these DSM tools andtechniques, however, designing operational QoS-intensivesystems remains a significantly hard problem due to mul-tiple crosscutting non-functional characteristics (i.e., thesecondary concerns) that must be satisfied simultaneouslyalong with system’s functional composition (i.e., primary)concern.

As an example of a non-functional requirement that af-fects system’s structural dimension consider fault-tolerancerequirements, such as various replication styles (active, pas-sive). Such fault-tolerance requirements may be speci-fied at several different levels of granularity, such as per-component basis, across a group of components, and acrossnested component groups. Replication is the most widelyused pattern for developing highly available systems, inher-ently requires additional copies of components that mustbe composed with original business components. More-over, for detecting failures of distributed components live-ness monitoring infrastructure must be composed parallelto the business components that are monitored. This illus-trates the scattering of the fault-tolerance concern across thesystem functional composition dimension.

Scattering (crosscutting) of fault-tolerance concerns isnot only observed along the system’s structural concern butalso along other non-functional concerns, such as deploy-ment. The impact of the fault-tolerance concerns on the de-ployment concern is also non trivial since the deploymentmust now account for the placement of the replicated busi-ness components, proxy components as well as the place-ment of the monitoring components to enable timely detec-tion of failures of business components.

To assist in designing systems where non-functional con-cerns crosscut with structural concerns, DSM tools mustprovide strong decoupling between system’s structural con-cerns, deployment concerns, and non-functional concernsand combine them when the final system is realized. Such

decoupling should not only provide different views for dif-ferent concern models but should also enable evolution ofthe modeling capabilities of each view independently. Evo-lution of the modeling capabilities of a concern view oftenrequires enhancements to the meta-model of the view. Sup-porting independent evolution of meta-models of each con-cern view shortens the development lifecycle by allowingparallel enhancements to the modeling capabilities (i.e., themeta-model) and models pertaining to the view.

Moreover, platform-independent notion of QoS require-ments is largely independent of the structural capabilitiesof the chosen implementation platform. For example, theCORBA Component Model [12] (CCM) is considered tobe a richer component model compared to Enterprise JavaBeans (EJB) as the former borrows several concepts fromthe latter and adds its own, such as a wider variety ofcomponent types, a notion of assembly, required and pro-vided interfaces using ports, and event-based communica-tion. This structural variability is clearly visible in plat-form specific modeling tools. However, such variability inthe structural capabilities of the contemporary componentplatforms need not prevent their corresponding DSM toolsfrom having a platform-independent modeling support forQoS such as fault-tolerance, timeliness, authentication andauthorization and network level QoS. All of which have lit-tle or no bearing on the structural capabilities of the plat-form. However, contemporary DSM tools are based on ad-hoc designs of meta-models for modeling QoS, which cou-ple them tightly with structural capabilities, prevent theirreuse in other component platforms and limits extensibility.Moreover, QoS and structural modeling capabilities (meta-models) are hard to evolve independently of each other.

This paper describes our solution to address these limita-tions of DSM design tools for CBSE. We describe Compo-nent QoS Modeling Language (CQML), which is a reusableand platform-independent framework developed using theGeneric Modeling Environment (GME) [10]. CQML is de-signed to superimpose on a wide range of system structuralcomposition modeling languages as long as they conformto a small set of invariant properties defined by CQML.

CQML has an extensible QoS modeling framework thatallows declarative QoS requirements to be associated withstructural component models. In this paper we demonstratehow QoS modeling capabilities can be superimposed on apurely structural modeling language. Moreover, we showhow CQML’s fault-tolerance modeling capabilities can beused to automatically generate runtime fault monitoring in-frastructure using the structural modeling capabilities of theunderlying language.

The remainder of this paper is organized as follows: Sec-tion 2 describes extensible QoS modeling capabilities ofCQML; Section 3 evaluates the capabilities of CQML; Sec-tion 4 describes related research; and Section 5 concludes

the paper.

2 Solution: Extensible QoS Modeling UsingCQML

In this section we describe the design of the Com-ponent QoS Modeling Language (CQML), which is aplatform-independent, QoS modeling framework that al-lows component-based system developers and designersto express QoS design intent at different levels of gran-ularity using intuitive visual representations. CQML hasbeen developed using the Generic Modeling Environment(GME) [10] toolkit. CQML is capable of separating sys-tem’s QoS concerns from the primary concern: structuralcomposition. It also supports QoS modeling for a mul-titude of component-based platforms because CQML de-pends only on the commonalities present across them. Fig-ure 1 shows the process of using CQML. We now describehow CQML uses this process to resolve the challenges de-scribed in the previous section.

Figure 1: Process Model for Reusing CQML for QoS Mod-ularization and Weaving

2.1 Identifying Invariant Properties of Component-based Structural Modeling Languages

Our focus is on general component-based systems,which are composed using multiple components orches-trated to form application workflows. Contemporary com-ponent models often have first class support for primitives,such as components, connectors, and methods. The struc-tural artifacts of a component-based system can be realizedusing these primitives in a language specifically designedfor modeling system structure.

Since CQML is aimed specifically at modularizingnon-functional concerns of component-based systems ina platform-independent manner, CQML requires an un-derlying base composition modeling language that al-lows construction and manipulation of platform-specificstructural models. Many platform-specific as well asplatform-independent component structural modeling lan-guages, such as Embedded Systems Modeling Lan-guage(ESML) [9] for embedded systems, J2EEML [17]

2

for Enterprise Java Beans, and Platform Independent Com-ponent Modeling Language (PICML) [2] for Light-weightCORBA Component Model [12] (LwCCM) exist today thatcapture various composition semantics. In this paper wehave focused on languages developed using GME sinceCQML is also developed using GME. However, the con-cepts behind CQML can be applied in other tool environ-ments.

Figure 2: A Feature Model of Composition Modeling Lan-guage

We refer to such a structural modeling language as sys-tem composition modeling language or base language inshort. We formalize the features of a base language in afeature model [4] shown in Figure 2. CQML is designedtaking into account the mandatory and optional featurespresent in such languages. The base language should havefirst class modeling support for components, connectors,and remotely invocable methods at the minimum. ESML,J2EEML, and PICML support all the mandatory entitiesmentioned in Figure 2 and therefore these languages canplay the role of a base language for CQML as shown in step(1) in Figure 1. In step (2), meta-modeling compositiontechniques are used to “mix-in” the metamodel of CQMLwith that of the base composition modeling language with-out affecting the syntax and semantics of the structural mod-eling language. In step (3), the composed meta-model isused to create the instances of the composition modelinglanguage, which has enhanced QoS modeling capabilitiesdue to CQML.

2.2 Extensible Design of CQML

Based on the feature model of component-based model-ing languages, CQML builds an extensible QoS modelinglayer. CQML has an ability to associate declarative QoScharacteristics to one or more of the invariant properties ofthe underlying base language. We have designed severaldeclarative QoS characteristics that are applicable to a gen-eral class of component-based systems. We have developed(1) FailOverUnit [16], which modularizes fault-tolerancerequirements of one or more components and assemblies,(2) PortSecurityQoS, which modularizes security aspectsof port based communication, (3) NetworkQoS [1], whichmodularizes network level QoS requirements while invok-ing remote methods. Some examples of the above concrete

QoS characteristics are shown in Figure 3. A FailOverUnitis used to annotate component A as a fault-tolerant compo-nent. For connections between component B and C, net-work level QoS attributes (e.g., priority of communicationtraffic) are associated using NetworkQoS modeling element.In this paper, we do not explain the semantics of all theabove concrete QoS characteristics in detail, however, in-terested readers are encouraged to read [1] and [16] toread more on NetworkQoS and FailOverUnit modeling re-spectively.

Figure 3: Declarative QoS Modeling Capability of CQML

To support evolution of QoS metamodel without affect-ing the structural metamodel, CQML defines a set of ab-stract QoS elements: Component-QoS, Connection-QoS,Port-QoS, Assembly-QoS and Method-QoS. As the namesuggests, each abstract QoS element is associated with itscorresponding element from the base language. For ex-ample, abstract Component-QoS can be associated with aComponent in the base language. Moreover, all the concreteQoS models (e.g., FailOverUnit) must be derived from oneor more abstract QoS types as shown in Figure 4.

Figure 4: Simplified Meta Model of CQML

CQML can be extended with new concrete declarativeQoS modeling capabilities by inheriting from the basic setof abstract QoS elements. To enhance CQML with a con-crete QoS characteristic, a language designer has to ex-

3

tend the metamodel of CQML at the well-defined pointsof extension represented by the five abstract QoS elements.The concrete QoS elements simply derive from the abstractQoS elements defined in CQML. By doing so the con-crete modeling entities inherit the abstract syntax, staticsemantics, relationships, integrity constraints, and visual-ization constrains of the abstract QoS entities defined inthe meta-model of CQML. For example, as shown in Fig-ure 4, FailOverUnit inherits association constraints fromthe abstract ComponentQoS and AssemblyQoS. Therefore,FailOverUnit can be associated with components and as-semblies only and never with ports or connections.

View separation of QoS elements and structural elementsis achieved by controlling the visibility of concrete QoSmodeling elements using visualization constraints definedon abstract QoS elements. CQML defines visibility con-straints on them such that they project QoS concerns in theQoS view of GME model editor, which is different fromthe view where structural concerns are edited and manipu-lated. All the concrete QoS elements inherit association andvisualization constraints from one or more abstract QoS el-ements defined by CQML as shown in Figure 4.

Along with the basic five abstract QoS elements, thesevisualization and association constraints constitute thegeneric QoS modeling framework of CQML. Although de-signing a new language construct – in this case a new QoScharacteristic – is an extremely thoughtful process, a signif-icant portion of design decisions are already taken for thelanguage designer in the generic QoS modeling frameworkof CQML. The reuse promoted by CQML design and itsgeneric QoS entities thus lends itself to easier component-based systems modeling enhancements. It prevents rein-vention of previously designed artifacts for every new QoSconcern that is added.

3 EvaluationRationale. An important responsibility of a fault-tolerantsystem is to monitor the running system for faults and whenfaults are detected they must be reported to higher levelcomponents so that appropriate recovery procedure can beinitiated. Developers of fault-tolerant DRE systems mustalso reason about how the monitoring subsystem will bedeployed and configured so that failure of business compo-nents can be detected and reported in a timely and reliableway. This additional responsibility of designing, deploying,and configuring monitoring subsystem delays developers’main task of developing business logic. Therefore, an auto-mated support for generating, deploying, configuring live-ness monitoring infrastructure is highly desirable.

Methodology. To demonstrate the capabilities of CQML,in this section we present an AOM solution to automaticallygenerate, deploy, and configure liveness monitoring infras-tructure for fault-tolerant component-based systems from

their requirements. We use CQML’s FailOverUnit model-ing capability to capture fault-tolerance requirements of oneor more components. In this paper, we use it as a way ofannotating a group of components for which runtime moni-toring infrastructure should be generated.

Our solution uses Constraint Specification AspectWeaver (C-SAW) [15], which is a generalized model-to-model transformation engine for manipulating domain-specific models, which is implemented as a plug-in for theGeneric Modeling Environment. It can also be used to in-strument structural changes within the model according tosome higher-level requirement that represents a crosscuttingconcern. We used PICML as our base structural modelinglanguage and we composed CQML’s QoS meta-model withthe structural meta-model of PICML.

Figure 5: Automatic Weaving of Monitoring ComponentsUsing Embedded Constraint Language Specification

As shown in Figure 5, we have developed model trans-formation specifications for CQML models using C-SAW’sinput language: Embedded Constraint Language (ECL).These specifications transform CQML models (shown by(1) in Figure 5) with FailOverUnit into structural models(shown by (2) in Figure 5) containing monitoring compo-nents, their interconnections, and their deployment informa-tion. The model-to-model transformation bridges the gapbetween the higher-level fault-tolerance requirements cap-tured using FailOverUnit and lower-level structural mod-els used by existing modeling tools, such as deployment,configuration and packaging tools that generate platform-specific metadata based on structural models. Such a trans-formation requires several steps, including (1) generatingmodels of monitoring components, (2) generating the nec-essary interconnections between the instances of monitor-ing components, and (3) generate deployment and config-uration models for instances of monitoring components so

4

that they are deployed along with the business componentswhen the system is deployed.

Algorithm 1 Transformation Algorithm for GeneratingMonitoring Infrastructure

1: M : Systems’s structural model with annotations.2: D : Deployment model of the system3: Me : Extended M with monitoring components4: De : Deployment model of Me5: c : A business component6: Sc : A set of collocated components such that c ∈ Sc7: HBc : Heartbeat component monitoring c8: F : Fault Detector component.

9: Input: M, D10: Output: Me, De (Initially empty)

11: begin12: Me := M13: De := D14: SF := /0

15: F := New fault detector component16: Me := Me∪F17: SF := SF ∪F18: De := De∪SF19: for each component c in M do20: if a FailOverUnit is associated with c21: let HBc := New heartbeat component for c.22: Me := Me∪HBc23: let i := New connection from F to HBc.24: Me := Me∪ i25: let c ∈ Sc and Sc ∈ D26: Sc := Sc∪HBc27: De := De∪Sc28: endif29: end for30: end

The algorithm behind the transformation is shown in Al-gorithm 1. The transformation accepts system’s structuralmodel and a deployment model as input and produces anextended structural model with monitoring components andan extended deployment model with placement of mon-itoring components as output. A deployment model canbe viewed as a simple mapping of components to physicalhosts in a system. Components are called collocated com-ponents when they are hosted in the same process on thesame host. When a process or a host dies, all the compo-nents hosted in that process/host become unavailable, whichcan be detected remotely using monitoring infrastructure.

The algorithm begins with a copy of system’s structuraland deployment model in the corresponding extended mod-els. For every structural model, a new Fault Detector com-ponent is added in the extended model along with its place-

ment in the deployment model. Followed by that, for everybusiness component in the original structural model, a newHeartbeat component is added that is collocated with thebusiness component. The collocated components are placedin the same process as that of the business component atrun-time. A connection from the FaultDetector componentto every new Heartbeat component is created so that the for-mer can poll the liveness of the later at runtime. As a resultof the algorithm, monitoring components are weaved-in theoriginal structural and deployment models of the system.

The above algorithm that we developed for generatingmonitoring components for PICML models can be used un-changed to generate monitoring components for J2EEMLas well as ESML models. In that sense, strong separa-tion of structural modeling from QoS modeling allows us towrite generic model transformation algorithms using ECLthat work across variety of structural modeling languages aslong as they satisfy the minimal invariant properties speci-fied in Section 2.1.

The actual implementation of the Heartbeat and Fault-Detector components is provided as a library using Com-ponent Integrated ACE ORB (CIAO), which is our open-source implementation of OMG’s Light-weight CORBAComponent Model specification. The component libraryuses the OMG’s IDL 3.0 interfaces shown in Listing 1. TheFaultDetector component periodically invokes isAlive re-mote method on all the instances of the Heartbeat compo-nent. The implementation of isAlive method in Heartbeatcomponent returns true indicating the fact that it is “alive”.If a Heartbeat component does not respond within a con-figurable timeout period, the FaultDetector concludes thatthe Heartbeat component and the collocated business com-ponent have failed. It initiates a recovery procedure afterdetecting the failure.

Listing 1 OMG’s IDL 3.0 Interfaces Used by The FaultMonitoring Infrastructure Generated by ECL Transforma-tionmodule Monitor { // A module defines a namespace.interface Monitorable { // An interface for checking liveness.

bool isAlive(void); // Returns true if component is alive.};component Heartbeat { // Implements Monitorable interface.

provides Monitorable alive; // Used by the FaultDetector.};component FaultDetector { // Polls liveness

requires Monitorable poll; // Uses Heartbeat components.};}

Finally, existing model interpreters for generating validXML-based metadata (shown by Step 3 in Figure 5) are in-voked on the weaved-in structural and deployment model togenerate packaging and deployment descriptors.

5

4 Related WorkCapturing QoS specifications at design-time has long

been a goal of researchers [7, 18]. A prior effort, calledComponent Quality Modeling Language [18], developedby Aagadel is a platform-independent, general-purpose lan-guage for defining QoS properties. It allows both in-terface annotation as well as component type annotation.Moreover, it has support for UML integration based ona lightweight QoS profile and has QoS negotiation capa-bilities. All the previous work on QoS specification lan-guages including QML [7] (QoS Modeling Language) andQuO [19] (Quality Objects) is superseded by [18].

Therefore, we limit our comparison of QoS specifica-tion languages to the quality modeling language developedby Aagedal. Our CQML has been designed to be super-imposed on domain specific component-based system com-position modeling languages and not with interface defini-tion languages as in the case of Aagedal’s QoS language.The latter allows QoS annotations at type level (IDL inter-face and component definition) only and therefore, cannotbe used to specify QoS requirements on components on aper-instance basis. Although, the QoS specification capa-bility in our CQML is not as general as in Aagedal’s qualitymodeling language, instance level QoS specification is pos-sible in our CQML.

Lightweight and heavyweight extensions for UML arepossible to create QoS profiles using extensibility mecha-nisms provided by UML. Lightweight extensions use onlythe mechanism of stereotypes, tagged values, and con-straints. Heavyweight extensions require modification tothe UML metamodel, which is naturally more intrusive thanlightweight approaches. The OMG has adopted UML pro-file [11] for schedulability, performance and time specifi-cation, which is based on lightweight extensibility mecha-nisms of UML. OMG has also adopted a more general pro-file for modeling QoS [13]. This UML profile provides away to specify the QoS ontology with QoS characteristics.It has support for attaching QoS requirements to UML ac-tivity diagrams. A common feature between these UMLprofiles and CQML is that both have first class support forQoS concerns. Compared to the lightweight mechanismsof above-mentioned UML profiles, CQML requires heavy-weight metamodel level composition of two languages. Abenefit of this approach is that the full strength of themetaprogramming environment can be leveraged in the pro-cess.

Another approach [6] for managing QoS is based on theQuO framework. It is an aspect-based approach to pro-gramming QoS adaptive applications that separates the QoSand adaptation concerns from the functional and distribu-tion concerns. It puts more emphasis on encapsulating thesystem adaptation and interactions as an aspect. But it ismore applicable to the CORBA-based platforms. The work

described in [8] shows similarities between network-levelconfigurable protocols and aspects. Both of the above men-tioned approaches focus on lower-level OS and network re-lated QoS whereas CQML is an AOM approach that focuseson the higher level platform-independent QoS concerns incomponent based systems and provides intuitive, visual ab-stractions. These lower-level concerns can be modeled asseparate declarative QoS aspects in CQML.

5 Concluding RemarksLarge-scale component-based systems often incur sec-

ondary non-functional concerns comprising quality of ser-vice (QoS), which crosscut the system’s primary concern:structural composition. The scattering and tangling of thesesecondary concerns impede comprehensibility, reusabilityand evolution of component-based systems. A Domain-specific Modeling (DSM)-based approach holds promise toaddress these challenges because it raises the level of ab-straction at which the systems are designed and reasonedabout. The complexity of system design incurred due tothe crosscutting concerns, however, is not eliminated evenat a higher level of abstraction because of lack of the rightDSM-level modularizing abstractions.

The key contribution of this paper is to address the chal-lenges in DSM tools for component-based system devel-opment. We described a reusable, platform-independentComponent QoS Modeling Language (CQML) which whencomposed with a host structural modeling language, en-hances the host language with declarative QoS modelingcapability without breaking the syntax, semantics and thetool support of the host language. CQML not only pro-vides separate views to specify and manipulate QoS con-cerns and system’s structural concerns but also allows QoSmetamodel to be extended without affecting the structuralmodeling capabilities of the host language. We evaluatedthis capability of CQML by composing it with a rich struc-tural modeling language: PICML [2]. Finally, we alsodemonstrated how CQML’s fault-tolerance models can beused to automatically generate structural and deploymentmodels of fault monitoring infrastructure using an aspect-oriented model weaver.

The capabilities of CQML are available in open sourcefrom the CoSMIC tool web site at www.dre.vanderbilt.edu/cosmic.

References[1] Jaiganesh Balasubramanian, Sumant Tambe, Bal-

akrishnan Dasarathy, Shrirang Gadgil, FrederickPorter, Aniruddha Gokhale, and Douglas C. Schmidt.NetQoPE: A Model-Driven Network QoS Provision-ing Engine for Enterprise Distributed Real-time andEmbedded Systems. In Proceedings of the 14th IEEEReal-time and Embedded Technology and Applica-

6

tions Symposium, pages 113–122, St. Louis, MO,USA, April 2008.

[2] Krishnakumar Balasubramanian. Model-Driven En-gineering of Component-based Distributed, Real-timeand Embedded Systems. PhD thesis, Department ofElectrical Engineering and Computer Science, Van-derbilt University, Nashville, September 2007.

[3] Clemens Szyperski. Component Software — Be-yond Object-Oriented Programming - Second Edition.Addison-Wesley, Reading, Massachusetts, 2002.

[4] Krzysztof Czarnecki and Ulrich W. Eisenecker. Gen-erative Programming: Methods, Tools, and Appli-cations. Addison-Wesley, Reading, Massachusetts,2000.

[5] Dionisio de Niz, Gaurav Bhatia, and Raj Rajkumar.Model-Based Development of Embedded Systems:The SysWeaver Approach. In Proceedings of the12th IEEE Real-Time and Embedded Technology andApplications Symposium (RTAS’06), pages 231–242,Washington, DC, USA, August 2006. IEEE ComputerSociety.

[6] Gary Duzan, Joseph Loyall, Richard Schantz, RichardShapiro, and John Zinky. Building Adaptive Dis-tributed Applications with Middleware and Aspects.In AOSD ’04: Proceedings of the 3rd internationalconference on Aspect-oriented software development,pages 66–73, New York, NY, USA, 2004. ACM Press.

[7] Svend Frolund and Jari Koistinen. Quality of ServiceSpecification in Distributed Object Systems. IEE/BCSDistributed Systems Engineering Journal, 5:179–202,December 1998.

[8] Matti Hiltunen, François Taïani, and Richard Schlicht-ing. Reflections on Aspects and Configurable Pro-tocols. In AOSD ’06: Proceedings of the 5th inter-national conference on Aspect-oriented software de-velopment, pages 87–98, New York, NY, USA, 2006.ACM Press.

[9] Gabor Karsai, Sandeep Neema, Ben Abbott, andDavid Sharp. A Modeling Language and Its Support-ing Tools for Avionics Systems. In Proceedings of21st Digital Avionics Systems Conference, Los Alami-tos, CA, August 2002. IEEE Computer Society.

[10] Akos Ledeczi, Arpad Bakay, Miklos Maroti, PeterVolgysei, Greg Nordstrom, Jonathan Sprinkle, andGabor Karsai. Composing Domain-Specific DesignEnvironments. IEEE Computer, pages 44–51, Novem-ber 2001.

[11] Object Management Group. UML Profile for Schedu-lability, Performance, and Time Specification, FinalAdopted Specification ptc/02-03-02 edition, March2002.

[12] Object Management Group. Light Weight CORBAComponent Model Revised Submission, OMG Docu-ment realtime/03-05-05 edition, May 2003.

[13] Object Management Group. UML Profile for Mod-eling Quality of Service and Fault Tolerance Char-acteristics and Mechanisms Joint Revised Submis-sion, OMG Document realtime/03-05-02 edition, May2003.

[14] Douglas C. Schmidt. Model-Driven Engineering.IEEE Computer, 39(2):25–31, 2006.

[15] Software Composition and Modeling (Softcom) Lab-oratory. Constraint-Specification Aspect Weaver(C-SAW). www.cis.uab.edu/ gray/Research/C-SAW,University of Alabama at Birmingham, Birmingham,AL.

[16] Sumant Tambe, Jaiganesh Balasubramanian, Anirud-dha Gokhale, and Thomas Damiano. MDDPro:Model-Driven Dependability Provisioning in Enter-prise Distributed Real-Time and Embedded Systems.In Proceedings of the International Service Availabil-ity Symposium (ISAS), pages 127–144, Durham, NewHampshire, USA, 2007.

[17] Jules White, Douglas C. Schmidt, and AniruddhaGokhale. Simplifying autonomic enterprise java beanapplications via model-driven engineering and sim-ulation. Journal of Software and System Modeling,7(1):3–23, 2008.

[18] Jan Øyvind Aagedal. Quality of Service Support inDevelopment of Distributed Systems. PhD thesis, Uni-versity of Oslo, Oslo, March 2001.

[19] John A. Zinky, David E. Bakken, and RichardSchantz. Architectural Support for Quality of Servicefor CORBA Objects. Theory and Practice of ObjectSystems, 3(1):1–20, 1997.

7