Separation of Quality Concerns in the Development of Distributed Real-time Systems

MohammadReza Mousavi, Giovanni Russello,Michel Chaudron, Twan Basten, Michel Reniers

'KPFJQXGP󰀂'ODGFFGF󰀂5[UVGOU󰀂+PUVKVWVG󰀎

'KPFJQXGP󰀂7PKXGTUKV[󰀂QH󰀂6GEJPQNQI[󰀎󰀂'KPFJQXGP󰀎󰀂6JG󰀂0GVJGTNCPFU

'OCKN󰀜󰀂]O󰀐T󰀐OQWUCXK󰀎󰀂󰀂I󰀐TWUUGNNQ󰀎

O󰀐T󰀐X󰀐EJCWFTQP󰀎󰀂󰀂C󰀐C󰀐DCUVGP󰀎󰀂O󰀐TGPKGTU_\"VWG󰀐PN

Abstract—This paper addresses the issue ofseparation of concerns in the design andimplementation of distributed real-time systems. Itgives an overview on the activities done in thetheoretical and practical domains of the SACC(Software Architecture = Components + Coordination)project in order to provide a support for this idea.Keywords—Distributed Real-time Systems;Middleware; Formal Specification; Aspect Orientation

I. INTRODUCTION

The design of distributed real-time systems is acomplex and difficult task. For such systems manyfunctional and non-functional quality requirements(reliability, timeliness, efficiency, and flexibility) needto be reconciled simultaneously. The difficulty arisesfrom the fact that a solution for one of theserequirements seems to complicate meeting otherrequirements. Hence the interaction between differentpartial solutions to the requirements is one importantcause of the complexity of designing such systems.To simplify the design of such systems, we proposea method that has the following novel features:

• #󰀂UGRCTCVKQP󰀂CV󰀂VJG󰀂URGEKHKECVKQP󰀂CPF󰀂FGUKIP󰀂NGXGN󰀂QH

SWCNKV[󰀂U[UVGO󰀐

EQPEGTPU󰀂HTQO󰀂VJG󰀂HWPEVKQPCNKV[󰀂QH󰀂VJG• #P󰀂U[UVGO󰀂CTEJKVGEVWTG󰀂SWCNKV[󰀂EQPEGTPU󰀐

VJCV󰀂UWRRQTVU󰀂HQT󰀂VJG󰀂OKFFNGYCTG󰀂UGRCTCVKQP󰀂QH󰀂QH󰀂FKUVTKDWVKQP

OWNVKRNG• #󰀂URGEKHKECVKQP󰀂VQ󰀂CP󰀂KORNGOGPVCVKQP󰀐RTQXCDN[󰀂EQTTGEV󰀂OGVJQF󰀂HQT󰀂IGVVKPI󰀂HTQO󰀂VJG

In order to realize this goal in our project, we

develop a suite of specification languages as well asmiddleware that supports the separation of concerns inthe implementation level. An automatic translationfrom the specification formalisms to theimplementation languages will bridge the gap betweenthe two domains. Thus, the project is organized alongtwo themes: theory concerning specification techniquesand practice involved with an implementationframework.

In this paper, after the introduction, Section 2focuses on the current state of the theoretical part andSection 3 describes the main ideas of theimplementation theme. Finally, Section 4 gives theconcluding remarks and presents the future researchdirections.

II. CONCEPTS AND THEORY

In this section we give a brief introduction to themodel that we use for system design. We explain whyit provides better support for separation of concernsthan traditional software programming and modelinglanguages.

A. GAMMA: A Computational Model forSeparation of Concerns

GAMMA is an abstract language, based on multisetrewriting on a shared data-space. It is designed tosupport parallel execution of a program on a paralleland/or distributed architecture [1]. The basic andatomic piece of functionality in GAMMA is the rule.The calculus of GAMMA [2] contains somecomposition operators to compose rules into programs.However, in our approach, we eliminate all structuringdecisions at the level of GAMMA programs, and usethe abstract theory as our basic model of componentfunctionality. Since GAMMA rules can interact with

the shared data space independently, the models allowsfor temporal and spatial decoupling (see Figure 1).Henceforth, our GAMMA model is only concernedwith independent basic functionalities of a design andabstracts from several other concerns such as: relativeordering of functionalities, timing, distribution,hardware resources and the level of true concurrency.Shared Data Space(Multiset)ComponentComponent(Rule)(Rule)Component(Rule)󰀂󰀂󰀂Figure 1. GAMMA shared data space model

B. Other Concerns: Timing, Coordination, andDistribution

In our design method, non-functional aspects arespecified in their own tailor-made design language.These non-functional aspects include:

• Coordination: Coordination is concerned with

ordering, concurrency and synchronization ofindependent functionalities. In particular, wetake a process algebraic approach for formalspecification of this aspect. Basic processes(building blocks) of our coordinationexpressions are GAMMA rules. Ourcoordination language, which is a slightlymodified version of the scheduling language of[3], contains conditional, sequential, parallel,and recursion operators. This leads to amodeling framework that allows changing themodeling language of each layer and stillexploiting the formal semantics of other layers incombination.

• Timing: We distinguish between two different

attributes in the timing domain: individualperformance metrics of components vs. end-to-end requirements of an entire system [4]. Tomodel individual performance metrics, we relatesingle GAMMA rules with their estimatedexecution time as intervals. End-to-endrequirements are specified using a real-timeextension of Temporal Logic and are verified

against the combination of aspect designs.

• Distribution: We specify a distribution pattern

as a mapping from data types and rules tophysical locations. The distribution pattern maybe static in time or may dynamically change overtime.In [5], a general framework for the specification ofthese three aspects, together with GAMMAfunctionality, is sketched, and the framework is appliedon an elevator case study. In [6], we give a precisesemantics for the (GAMMA + Coordination) + Timingparadigm.

III. EXPERIMENTAL VALIDATION: ARCHITECTURE OF

AN IMPLEMENTATIONIn this section, we describe the current status of thepart of the research that is involved in developingimplementation techniques that support the designmethod presented in the preceding sections. The maingoal in the implementation domain is to design andimplement a distributed middleware that can deal withseveral aspects of design as orthogonal issues that canbe uploaded according to their respective designmodels.

A. Aspects in the Middleware

In the specification / design domain, for eachapplication several aspects such as functionality,timing, behavioural pattern (coordination), and thedistribution, are defined. In the implementation domain,the functionality aspect is mapped into applicationcomponents that are distributed (according to someinitial distribution pattern) over available nodes makingup the distributed system. The other aspects aretransformed into policy descriptors that aredownloaded into the middleware where various aspectmanagers interpret them at run time.

Aspects can be divided into application-specific andsystem-wide. Application-specific aspects are thoseconcerned with a single application (combination offunctionality, timing, etc.). In contrast, system-wideaspects effect the execution of all applicationscurrently active in the middleware. According to thisclassification, the middleware itself is divided into twolayers. In the highest layer, application-specific aspectmanagers are responsible for interpreting and enforcing

an application’s policies. In the lowest layer, globalaspect managers deal with global policy descriptors

and enforce system-wide policies.

System AspectSystemSecurityScheduleAspect SpecificationApplication AFunctionalityTimingDistributionApplication BFunctionalityTimingDistributionWeaving ProcessAspect ManagersCC3CMiddleware12Application-Specific LayerMW-ASystem-wide LayerPlatform LayerNetwork LayerFigure 2: An Architectural View of the Implementation DomainMWOSMW-AMWOSMW-BThe separation into two layers has the importantadvantage that each application can define its ownpolicies without interfering with policies of otherapplications. At the same time, it is still possible todefine global policies to apply to the overall system. B. Implementation Architecture

Figure 2 presents the case in which two applications,A and B, are defined and deployed in our system. Weuse light grey blocks for application A and dashed lineblocks for application B. For each application, the setof aspects is defined. The functionality aspect ismapped into components C1 and C2 (deployed ondifferent physical nodes) for application A andcomponent C3 for application B. The other aspects forthe two applications are downloaded into themiddleware in the application-specific layer, in theform of policy descriptor. In this way, each applicationcan define its own policies regarding several aspectsindependent from other applications. Also, application-independent aspects are defined and then downloadedas policy descriptors in the middleware at the system-wide layer.

A prototype implementation of this architecture isdone based on the JavaSpace shared data space system.On top of this prototype middleware, a case-studyabout a Traffic Management Pont is analysed byexamining the application of several distributionpolicies for different timing and bandwidth constraints.Details of the prototype implementation and the resultof this analysis are presented in [7]; the results suggestthat the idea of separation of concerns helps adjustingthe best distribution policy to specific applicationsettings.

I. CONCLUSION AND FUTURE DIRECTIONSIn this paper, we presented the main directions takenin the SACC project in order to realize separation ofconcerns in the development of distributed real-timesystems. These directions include the development of asuite of specification languages for functionality(GAMMA-based) and various non-functional aspectssuch as coordination, timing, distribution etc, and anaspect-oriented distributed middleware to supportseparation of concerns in the implementation domain.The main challenges in the theoretical part of the

project, apart from developing a sound aspect-orientedtheory, include mechanizing the proof system for thedeveloped theory, and providing a refinement /synthesis method to extract concrete systemrepresentations from general requirements. In thepractical part, developing an adaptive strategy forfinding and maintaining an optimal distribution policyis on the list of future work.

The activities in the theoretical track of the projectso far were more focused on timing aspects whilst inthe implementation track the focus was more ondistribution policies. We are aiming at bridging thisgap by both providing a formal semantics ofdistribution and implementation support for timingconstraints. Currently, the translation of GAMMAfunctionality into implementation components(JavaSpace programs) is done manually; providing anautomatic translation from specifications to programs(for functionality as well as other aspects) is anotherimportant issue in the future work. Studying anindustrial case in our framework is another plannedactivity to provide a proof of concept for our approach.

REFERENCES

[1] Jean-Pierre Banatre and Daniel Le Metayer,

Programming by Multiset Transformation, Communicationsof the ACM (CACM), 36(1):98--111, January 1993.

[2] Chris L. Hankin, Daniel Le Metayer and David Sands, A

Calculus of Gamma Programs, Proceedings of the FifthInternational Workshop on Languages and Compilers for

Parallel Machines, New Haven, Connecticut, Lecture Notesin Computer Science, vol. 757, pp. 342--355, Springer-Verlag, Berlin, 1993.

[3] Michel R.V. Chaudron, Separating Computation and

Coordination in the Design of Parallel and DistributedPrograms, PhD thesis, Department of Computer Science,Rijksuniversiteit Leiden, Leiden, The Netherlands, 1998.[4] Lynne Blair, Gordon Blair and Anders Andersen,

Separating Functional Behavior and PerformanceConstraints: Aspect-Oriented Specification, TechnicalReport MPG-98-07, Computing Department, LancasterUniversity, May 1998.

[5] MohammadReza Mousavi, Giovanni Russello, Michel

Chaudron, Michel Reniers, Twan Basten, Angelo Corsaro,Sandeep Shukla, Rajesh Gupta, Douglas C. Schmidt, UsingAspect-GAMMA in the Design of Embedded Systems, toappear in the Proceedings of 7th IEEE InternationalWorkshop on High Level Design and Validation, Cannes,France, IEEE Computer Society Press, 2002.

[6] MohammadReza Mousavi, Twan Basten, Michel Reniers,

Michel Chaudron, Giovanni Russello, SeparatingFunctionality, Behavior, and Timing in the Design ofReactive Systems: (GAMMA + Coordination) + Time,Technical Report, Department of Computer Science,Eindhoven University of Technology, 2002.

[7] Giovanni Russello, Michel Chaudron, Maarten van Steen,

Separating Distribution Policies in a Shared Data SpaceSystem, Internal Report IR-497, Department of Mathematicsand Computer Science, Vrije Universiteit, June 2002.