aspect-oriented development with stratified...

feature

0 7 4 0 - 7 4 5 9 / 0 3 / $ 1 9 . 0 0 © 2 0 0 3 I E E E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y I E E E S O F T W A R E 8 1

AOP aims to separate concerns that cross-cut a particular decomposition strategy, suchas object orientation, and traditionally usesweaving techniques2 to recombine them. It isbased on the recognition that no matterwhat criteria are used to modularize a sys-tem, there will always be system propertiesthat “cut across” module boundaries. An as-pect is a software artifact that addresses onesystem concern and must be combined (ide-ally through an automated process likeweaving) with the base modules and otheraspects to yield a complete application.

Other leading development paradigmscan also be understood as separation-of-concerns technologies. Component-baseddevelopment, for example, separates corefunctionality from connectivity and uses anassembly metaphor to create complete sys-tems from prefabricated parts, while frame-work-based development separates domain

commonalities from application variabilitiesand uses an instantiation metaphor to createindividual applications. The Object Man-agement Group’s (www.omg.org) more re-cent model-driven architecture (MDA)3 ap-proach, on the other hand, separatesplatform-independent architectural abstrac-tions from technology-specific realizationsof these abstractions, and uses a refinementor mapping metaphor to generate concrete,executable systems.

These technologies might appear to useincompatible criteria for modularizing thesoftware artifact descriptions. However,closer examination reveals that this is nottrue. Although some of the specific mecha-nisms used in these paradigms might be in-compatible, the underlying separation-of-concerns strategies they employ are not. Onthe contrary, because their modularizationcriteria are essentially orthogonal, there is a

Aspect-OrientedDevelopment withStratified Frameworks

Colin Atkinson and Thomas Kühne,University of Kaiserslautern

Aspect-orienteddevelopment is a“separation-of-concerns”technology thatpromises to improveproductivity andproduct quality insoftwaredevelopmentprojects.Architecturestratificationcombines thestrengths ofcomponent-basedframeworks andmodel-drivenarchitectures tosupport aspect-orienteddevelopment.

Separation-of-concerns technologies are key to improving themaintainability and adaptability of software artifacts.1 Thesetechnologies identify loosely coupled, modular, and reusable unitsof description from which developers can generate tailored soft-

ware systems with minimal effort. Aspect-oriented programming providesperhaps the most explicit application of the separation-of-concerns tenet.

aspect-oriented programming

high potential for synergy from their inte-grated application. The synergies betweencomponents, frameworks, and model-driven development have in fact been recog-nized for some time in leading-edge frame-work technologies such as San Francisco4

and the newest generation of developmentmethods such as Catalysis5 and KobrA.6

Despite its promise, AOP’s separation ofcross-cutting concerns has yet to be fully inte-grated with the other approaches. As a result,many developers view aspect-oriented develop-ment as an “academic” software-developmenttechnology less suited for enterprise soft-ware development than components frame-works and MDA. We describe a strategythat exploits the advantages of aspect-ori-ented development in model-driven andcomponent-based frameworks. Key to ourstrategy is the use of architecture stratifica-tion,7 rather than weaving technology, toaddress cross-cutting concerns. This notonly addresses the limitations of the indi-vidual technologies but leverages the syner-gies between them.

Structural view of systemarchitectures

In the software engineering literature,you’ll often see phrases like “The architectureof a software system is …,” implying that asingle architecture uniquely captures a givensystem’s important high-level properties. Al-though developers typically view an architec-ture from various perspectives8 or using arange of decomposition techniques emphasiz-ing different concerns (such as multipletops9), these views are usually regarded asproviding different windows onto the samebasic underlying architecture. For example,structural views describe the underlying struc-tural organization of the system, dynamicviews describe system behavior, and physicalviews describe system deployment, includingthe mapping of software onto hardware.

Of the various possible views, developersgenerally regard the structural view as themost important, because it provides the foun-dation for organizing the other views interms of the system’s components and con-nectors. It also provides the basis for classify-

ing common architecture styles.10 In practice,however, you can define several structural ar-chitectures—depending on the level of ab-straction at which you would like to see thesystem—each with different sets of connec-tors and components.

Consider Figure 1, a UML class diagramdescribing a simple banking system that usesremote and logged communication to accessaccounts holding international currencies.This representation provides a high-levelview of the component and connector typesmaking up the system’s architecture. A securecommunication protocol and a subscriptionscheme implying implicit invocation connectthe bank and account component types.

Figure 2a describes the same system, againin terms of components and connectors, but ata lower level of abstraction. In the diagram,we’ve reified the notion of international cur-rencies into new Dollar and Euro compo-nents. Even this more detailed scenario ab-stracts from other realization details—in thiscase the particulars of remote and secure com-munication. Figure 2b illustrates how we real-ize both the “logged” property of the commu-nication between bank and account in termsof lower-level interactions with a logger ob-ject, and the communication’s “remoteSecure”property in terms of lower-level interactionsinvolving object request broker objects(clientOrb and serviceOrb). Figure 2cshows an even more detailed architecture inwhich the encrypted property of the commu-nication between the object request brokers isrealized in terms of interactions with a lower-level encryption object.

Figure 2 demonstrates that there aremany valid ways to capture a system’s struc-tural architecture (that is, its componentand connector types). The prevailing prac-tice has been to pick one architecture (usu-ally the least abstract) as the “real” or“best” architecture. Developers often seethe others as temporary by-products to bediscarded once they have determined the fi-nal version. With an appropriate organiza-tion scheme, however, you can use these ar-chitectures to systematically access viewsdetailing important system concerns. More-over, these concerns are typically the type ofcross-cutting concerns AOP addresses.

We use architecture stratification to organ-ize the various architectural representations sothat they expose and relate the system’s cross-

8 2 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e

*

AccountBankCommunication

{remoteSecure,logged,international}

{subscription}

Figure 1. A simple architecture for a banking system. A secure communication protocol and a subscription schemeconnect the two components, bankand account.

cutting concerns. This lets us integrate anAOP-style separation of concerns with com-ponent, framework, and pattern technologies.

Architecture stratification Architecture stratification’s basic goal is to

identify, elaborate, and relate different archi-tectural views so that they best represent asystem’s cross-cutting concerns. Instead of ig-noring the different architectural levels, we re-gard them as individual strata in a transcend-ing architecture hierarchy. The developmentof these views is analogous to the well-estab-lished principle of stepwise refinement,11 withthe connectors between components as theentities driving the refinement.12

Figure 3 shows how this approach refinesan interaction between two components, Xand Y, and reifies it in a lower stratum—that is, a lower level of abstraction. Assum-ing X is Bank and Y is Account, the refine-ment explains how the two componentscommunicate via the object request brokersA and B. In general, the semantics of an in-teraction between two components X and Yis given by a set of lower-level componentsand interactions with less rich semantics.

In the higher stratum in Figure 3, Y is X’scommunication partner, whereas in the lowerstratum A is. Thus X turns into X', reflecting

the communication partner change. A refine-ment transformation not only replaces com-plex interactions with components and sim-pler interactions but also adapts and modifiesaffected components accordingly. The refine-ment doesn’t affect Y because the asymmetryof the client-server component interactionmodel means that a client needs to know itsserver’s identity, but a server doesn’t need toknow its clients’ identities.

Note that the fundamental characteristicsof an architectural stratum or its relation-ships to neighboring strata are independentof the notation used to capture the compo-nents and connectors involved. Thus, we canuse the stratification concept with any de-scription language, including a high-levelmodeling language such as UML, a domain-specific architecture-description language, ora low-level, general-purpose programminglanguage. When used with a high-level de-scription language, architecture stratifica-tion provides an excellent basis for the MDAapproach because it directly addresses thecentral question of how to organize and re-late different kinds of architectural models.

Refinement transformations Refinement transformations capture the

relationship between a connector in one stra-

J a n u a r y / F e b r u a r y 2 0 0 3 I E E E S O F T W A R E 8 3

dealsWith

(a)

(c)(b)

Currency

communication

communication

communication

{remoteSecure,logged}

{subscription}

dealsWith

dealsWith dealsWith

dealsWith dealsWith

receivesEvents notifies

receivesEvents notifies

Dollar EuroAccount

Dollar Euro

Dollar Euro

*

logsTo logsTo

connectsTo

logsTo logsTo

talksTo talksTo

employs employs

DES

Broadcast

Currency

Broadcast

Currency

Bank

AccountBank

AccountBank

Logger

LoggerEncryption EncryptionStrategy

uses

connectsTo

ServerOrbClientOrb

ServerOrbClientOrb{encrypted}

talksTo talksTo

Figure 2. Different levels of abstraction in a banking system’s structural architecture: (a) low detail, (b) medium detail, and (c) high detail.

tum and connectors and components in thestratum below. Such transformations define arelationship between the originating and theresulting scenarios, detailing the componentsthat must be changed or added. We deliber-ately use the “relation” concept because rela-tions are inherently undirected, and thus in-dependent of system development direction.

We could just as easily elaborate an architec-tural strata’s hierarchy using a bottom-up ap-proach as a top-down approach.

Our use of annotations to distinguish thetypes of interactions in Figure 2 lets us tie aset of refinement transformations to an an-notation language in which labels can referto concerns (subscription, for example).Although the set of refinement transforma-tions and associated interaction labels (theconcern designators such as remoteSecure,logged, and encrypted) depend on the do-main under consideration, we can generallyreuse them in architectures in similar do-mains. Moreover, the lower the level a con-cern (encrypted, for example), the morelikely it is to recur in multiple domains. Re-lating interaction labels to refinement trans-formations in this way provides a basis for adomain-specific description language capableof expressing typical domain concerns.

Other methods for organizing architec-tural representations also use explicit-inter-action refinement to help relate concepts atdifferent levels of abstraction and to drivedevelopment. However, these methods typi-cally refine interactions independently ofone another.5 To obtain a meaningful stratahierarchy like the one Figure 4 illustrates,you must systematically select a specific setof interactions to refine in each stratum. Forinstance, if you start from a stratum captur-ing mostly business-level interactions (Fig-ure 2a) and select all interactions pertainingto remote communications, you’ll get acommunication stratum. If you then selectall interactions relying on some form of per-sistence capability, you’ll get a persistencestratum, and so on. In Figure 4, white ovalsrepresent the objects or components intro-duced at one level by refining selected inter-actions from the level above.

Strata versus layers Layering is a common technique for

making the parts of a large, complex systemmore independent and reusable. At firstsight, strata like those we’ve introducedmight appear to be merely a recasting oflayers as used in traditional architecturalapproaches. This is not the case, however.Strata, although motivated by the same ba-sic goal of attaining a hierarchical structure,differ fundamentally from layers.

A layer represents a slice through a system


Y'X

A

X

B

Y

Figure 3. Interaction refinement. The lower stratum shows the interaction between X and Y in the top stratum, but at a lowerlevel of abstraction. The communication between X and Yoccurs through object request brokers A and B.

Figure 4. Stratified architecture. Working downward, each subsequent stratum is a refinement of the one above. Whiteovals represent the objects or components that result from refining an interaction in the adjacent higher-level stratum.

that packages a coherent subset of the system’sfunctionality, such as platform, infrastructure,domain, and application layers. Thus, a singlelayer can’t convey the whole system’s func-tionality. Rather, you must consider all layerssimultaneously to understand what the wholesystem does. Each architecture stratum, how-ever, describes the entire system, but with adifferent degree of abstractness. Each stratumtherefore describes what the whole systemdoes, but not how it does it. Different strataelaborate on how the system realizes a certainpart of the overall functionality. Thus, strataare more like representations of a completeprogram at different levels of abstraction (forexample, source, assembler, and binary code).

Transparency and abstraction goals canalso highlight the difference between layersand strata. When moving upward in a lay-ered architecture, the layers become notonly more application-specific, but also—like strata—more concise in the sense thattop layers use concepts with richer seman-tics than lower levels. In systems with strictlayering,12 however, lower-layer functional-ity is completely transparent to clients sev-eral layers above. In other words, code inhigher layers can’t refer to details presentseveral layers deeper. This is an advantagebecause it lets you replace complete layerswithout affecting layers above, but it is alsoa disadvantage, because such transparencycan be perceived as restrictive. Often, forreasons of efficiency or flexibility, a layermust bypass adjacent lower layers to di-rectly access low-level services. Architec-tures allowing such bypasses are generallyreferred to as having nonstrict layering.12

Rather than completely remove detail, itis usually preferable to merely abstract fromdetail. Abstraction doesn’t make details in-

accessible; rather, it makes certain details ir-relevant at a particular level of abstraction.This is what architecture stratification ac-complishes. Because each stratum describesthe full system, a client can explicitly accessany low-level functionality, but only in thecorresponding low-level stratum.

The ability to abstract from details whenpossible, but provide access where necessary,is particularly important for cross-cuttingconcerns. A major problem of weaving-basedsystems, especially when dealing with multi-ple interfering concerns, is that they aim fortransparency between the target code and allaspects respectively. (See the “ArchitectureStratification vs. Other Aspect-Oriented Ap-proaches” sidebar for a discussion of weav-ing-based approaches.) The aspect-orientedcommunity has so far been unable to fullysolve the resulting superimposition problems.

Because the concepts of layers and archi-tectural strata are orthogonal, they are fullycompatible and can be combined to organizeinformation in a model-driven architecture.We can organize the components within agiven stratum in terms of layers.

Strata, concerns, and patterns Although stratification is a simple and nat-

ural idea, to apply it effectively you must re-fine appropriate sets of interactions in onestratum to realize a well-defined concern inthe stratum below. If done correctly, the re-sulting abstraction levels disentangle differentcross-cutting concerns and present them attheir natural detail level. Different concernswill only make themselves visible when strat-ification exposes certain detail levels.

Suppose, for example, we use the classifi-cation of concerns in Table 1 as the basis forstratifying an architecture. As the strata re-


Table 1Classification of concerns

Concern Subconcern Subsubconcern

Infrastructure Coordination SchedulingSynchronization

Distribution Fault toleranceCommunication (for example, serialization)Replication

PersistenceServices Security Encryption

AuthorizationRecovery (for example, exceptions)Undo

Paradigms Functions (such as visitor pattern)Events (publish-subscribe pattern, for example)

veal more detail—proceeding from top tobottom—more concerns become relevant.The strata hierarchy will thus mirror theclassification of concerns shown in Table 1.As one concern (distribution, for example)is elaborated in one stratum, it raises theneed for a dependent concern (such as secu-rity) at a lower level. As a result, concernsare separated from each other until a certainlevel of detail (that is, the stratum in whichthey are first introduced), from which theyspread into aspects and other dependentconcerns as the architecture unfolds into acertain design (typically a decompositioninto pure components or objects).

A stratified architecture therefore pro-vides two invaluable pieces of informationabout a concern:

■ The abstraction level at which a concernis first introduced (top-down view)

■ The degree of influence a concern hason the overall system structure (bottom-up view)

The latter explains why choosing a cer-tain implementation technology, such as aparticular middleware solution, can affecthigher-level system structures. In fact, thesebottom-up concern implications often makeit hard to match a single interface to a par-ticular middleware solution, and then sim-ply swap it for a competing implementationtechnology.

Note also that a stratified architecture rei-fies interactions into components (see Figure3). In other words, stratification refines aconcern associated with an interaction intocomponents. High-level interaction attrib-utes, such as secure data transmission, willeventually be described in the form of com-ponents (encryption interfaces and so on).

Abstractions as aspect anchorsBecause concerns are irrelevant until the

developer requires a certain level of detail,we can define a concern’s corresponding as-pect in terms of the system abstractions in-habiting the stratum in which the concernfirst appears.

One of the main challenges for weaver-based aspect-oriented approaches operatingat the code level3 is expressing where in thecode to apply an aspect. Developers currentlyuse declarative patterns to match locations inthe base code to determine the join points be-tween base code and aspect. The problemwith this approach is that the patterns canonly use abstractions from the implementa-tion domain—typically methods, classes, andpackages. Any higher-level system abstrac-tions must be recreated, for example by thesystematic use of naming conventions.

In a stratified architecture, you can an-chor an aspect to system abstractions at therelevant level. In general, the abstractionlevel at which a concern becomes relevantusually offers semantically richer abstrac-


Weaver-based approaches operating on code artifacts completely separate aspect code from base code. This strength, how-ever, is also a weakness: when several aspects and the base code interfere at the same join points, issues of priority, nesting,and mutual exclusion arise. All separation-of-concerns approaches that use a low-level code structure have difficulty definingjoin points in terms of higher-level system abstractions because they must recreate these abstractions from the flat code structure.Furthermore, weaver-based technologies have only just begun to define aspects based on other aspects rather than the basecode, whereas the hierarchical organization of concerns is a built-in feature of stratification.

Our architecture stratification approach currently lacks dedicated tool support, but it can benefit the development processeven if applied manually. Although manually applying stratification requires developers to explicitly work with tangled specifica-tions, this is a natural consequence of abstraction. Some aspect interferences must be dealt with manually, and the lower strataare the best place to do this effectively.

Another approach for making a framework aspect-aware is to provide aspect functionality (such as an AspectModeratorclass) within the framework.1 This requires neither an aspect nor an annotation language. Furthermore, by deferring weaving toruntime, even the dynamic addition and reconfiguration of aspects becomes possible. Unlike stratified frameworks, however, thisapproach does not provide any leverage in terms of abstraction levels and can suffer from more efficiency problems than com-pile-time weaving.

Reference1. C. Constantinides et al., “Designing an Aspect-Oriented Framework in an Object-Oriented Environment,” Proc. ACM Computing Surveys Symp. Application

Frameworks, ACM Press, New York, 2000; http://portal.acm.org/citation.cfm?doid=351936.351978.

Architecture Stratification vs. Other Aspect-Oriented Programming Approaches

tions than those in the implementation do-main. You can think of these componentsand interactions at higher strata as reifiedabstractions of the lower strata. Hence, it iseasier to attach the aspect to these abstrac-tions and let the respective refinement trans-formations distribute it to the scattered lo-cations in the low-level realization.

Organizing patterns Stratification’s ability to untangle infor-

mation is also valuable when software ar-chitecture descriptions include patterns.13

Although patterns typically address differ-ent levels of abstraction (for example, archi-tectural styles, microframeworks, and lan-guage idioms), they are usually applied in asingle, flat level of abstraction. Without fur-ther documentation, it is difficult to recon-struct why the patterns were applied andhow they are related.

A stratified architecture alleviates thisproblem by letting a user express the appli-cation of particular patterns at their naturallevels of abstraction. Thus, in a typical strat-ified architecture, patterns will be distrib-uted among the various strata according tothe concerns they address and the problemsthey solve, making it much easier to com-prehend where patterns are being used andwhy. For example, Figure 5 illustrates howusing the blackboard architecture pattern inthe top stratum leads to the use of the pub-lisher–subscriber pattern in the stratum be-low, which in turn leads to the use of thedouble-dispatch idiom in the next stratumto determine the correct action dependingon both agent and event type.

The fact that patterns and concerns aredistributed similarly across strata shouldnot be surprising because, as mentioned pre-viously, design patterns usually address spe-cific concerns such as coordination (reactorpattern), events (publisher–subscriber pat-tern), or functions (visitor pattern). Theytherefore naturally appear in the stratumthat focuses on the concern they are in-tended to address.

You can use this clarified presentation ofpattern application levels and relationshipsnot only in system construction but also todiscover pattern languages—that is, reoc-curring pattern configurations that defineeach other’s context in a dependency treestructure.

Stratified frameworks Although stratification has many advan-

tages over other strategies for modularizingand describing cross-cutting concerns, ifyou must manually create and maintainstrata and use traditional implementationtechnologies to realize the information cap-tured in a stratified architecture (essentiallyby implementing the lowest-level stratum),the approach essentially becomes a sophisti-cated but work-intensive design approach.In contrast, AOP allows separately definedaspects to be weaved automatically into anexecutable system.

Applying the architecture stratificationapproach in a framework context alleviatesthis problem. Essentially, frameworks arecollections of software development arti-facts (including executable code) that havebeen parameterized so that users can instan-tiate them into user-specific applications bydefining minimal additional (user-specific)information. Thus, if you apply architecturestratification within the context of a para-meterized, semicomplete framework, youcan exploit the effort put into the separate


Blackboard

Double dispatch

Publisher-subscriber

Figure 5. Stratifiedpatterns. Stratifiedarchitectures typically distributepatterns according to the concerns theyaddress and theproblems they solve.

description of concerns through stratifica-tion every time you instantiate the frame-work. In other words, whereas weaver tech-nologies automate the exploitation ofaspects by “weaving” them together, frame-works automate their exploitation by facili-tating their straightforward instantiation.Frameworks are usually long-lived and havevariants, so each time you instantiate theframework, the initial effort involved instratifying it is amortized.

Organizing hot spots Using architecture stratification princi-

ples to organize artifacts in a frameworkalso addresses some significant problemswith traditional framework technologies.First, the disentanglement of informationprovided by stratification is invaluable forusers needing to understand the frameworkat both the code and design levels. Becauseusers often have difficulty comprehending aframework’s extension and parameteriza-tion points, they rarely use them effectively.Stratification distributes these hot spots(points of variation) among the strata ac-cording to their natural level of abstraction,just as it distributes concerns and patterns.The strata therefore naturally clarify andexpose the framework’s extension and para-meterization points.

Parameterized interactions Stratification also lets developers para-

meterize or extend more of a framework’sproperties in an object-oriented way. Frame-

works have traditionally supported theadaptation and exchange of data types andsome pluggable or redefinable behavior, butthe interactions within the framework aretypically predefined and fixed. In a stratifiedframework, you can modify or adapt an in-teraction simply by changing the compo-nents responsible for realizing it in the stra-tum below. While this is also possible in aflat framework without abstraction levels,such frameworks lack the structure to facil-itate simple identification of the interactionrequiring the change.

Traceability Finally, stratification lets developers trace

corrective or evolutionary changes made tothe framework through the refinement trans-formations, facilitating evaluation of thechanges’ impact. For example, you can tracea change to a rather high-level system ab-straction downward along the refinementtransformations to validate its effect on themore detailed strata. Likewise, you can tracea low-level change upward to check whichhigher-level interactions will be affected.Starting from this higher strata, you can againuse the refinement transformations to navi-gate back down to the detailed strata, evalu-ating the effect of the modifications. Throughthis process, you can systematically evaluatethe system-wide impact of a local change.

A s the software industry struggles tocome to terms with the OMG’s newMDA paradigm, stratifications’

support of the MDA approach might proveto be its most important advantage. A keychallenge in effective model-driven develop-ment is the concise and modular descriptionof key architectural concerns and theirtraceable mapping to concrete executablerepresentations. Architecture stratificationprovides an ideal conceptual foundation forcreating and organizing such models.

Our current research focuses on integrat-ing the architecture stratification approachwith our work on model-driven develop-ment, particularly object-oriented metamod-eling and KobrA.6

Stratification’sability tountangle

information is also valuablewhen softwarearchitecturedescriptions

includepatterns.


About the Authors

Colin Atkinson is a professor at the University of Mannheim. His research focuses onobject and component technology and its use in the systematic development of software sys-tems. He received a BSc in mathematical physics from the University of Nottingham and anMSc and a PhD in computer science from Imperial College, London. He is a member of the IEEEand the British Computer Society. Contact him at [email protected].

Thomas Kühne is a junior professor at the Darmstadt University of Technology. His re-search interests are object technology, programming languages, software architectures, andmetamodeling. He received an MSc and a PhD from the Darmstadt University of Technology,Germany. Contact him at FG Metamodeling, TU Darmstadt, Wilhelminenstr. 7, 64283 Darm-stadt, Germany; [email protected].


AcknowledgmentsWe carried out initial conceptual work on stratifi-

cation at the University of Kaiserslautern within theGerman Special Research Project SFB 501.

References1. D. Parnas, “On the Criteria to Be Used in Decompos-

ing Systems into Modules,” Comm. ACM, vol. 15, no.12, 1972, pp. 1053–1058.

2. G. Kiczales et al., “Aspect-Oriented Programming,”Proc. European Conf. Object-Oriented Programming,Lecture Notes in Computer Science, no. 1241, Springer-Verlag, Berlin, June 1997, pp. 220–242.

3. Object Management Group (OMG), “ExecutiveOverview: Model-Driven Architecture,” www.omg.org/mda/executive_overview.htm, 2001.

4. P. Monday, J. Carey, and M. Dangler, San FranciscoComponent Framework, Addison-Wesley, Boston,1999.

5. D.F. D’Souza and A.C. Wills, Objects, Components andFrameworks with UML: The Catalysis Approach, Addi-son-Wesley, Boston, 1998.

6. C. Atkinson et al., Component-Based Product LineEng. with UML, Addison-Wesley, Boston, 2001.

7. C. Atkinson and T. Kühne, “Stratified Frameworks,”Int’l J. Computing Science and Informatics, Informat-ica, vol. 25, no. 3, 2001, pp. 393–401.

8. P. Kruchten, “The 4+1 View Model of Architecture,”IEEE Software, vol. 12, no. 6, Nov./Dec. 1995, pp.42–50.

9. J.O. Coplien, Multiparadigm Design for C++, Addison-Wesley, Boston, 1998.

10. M. Shaw and D. Garlan, Software Architecture: Per-spectives on an Emerging Discipline, Prentice Hall, Up-per Saddle River, N.J., 1996.

11. N. Wirth, “Program Development by Stepwise Refine-ment,” Comm. ACM, vol. 14, no. 4, Apr. 1971, pp.221–227.

12. C. Szyperski, Component Software: Beyond Object-Oriented Programming, Addison-Wesley, Boston, 1999.

13. M. Broy, Towards a Mathematical Concept of a Com-ponent and Its Use, tech. report I9746, Technische Uni-versität München, Munich, Germany, 1997.

14. E. Gamma et al., Design Patterns: Elements of Object-Oriented Software Architecture, Addison-Wesley,Boston, 1994.

For more on this or any other computing topic, see our Digital Library athttp://computer.org/publications/dlib.

The exploding popularity of mobile Internet access, third-generation wirelesscommunication, and wearable and handheld devices have made pervasivecomputing a reality. New mobile computing architectures, algorithms,environments, support services, hardware, and applications are coming onlinefaster than ever. To help you keep pace, the IEEE Computer Society and IEEECommunications Society are proud to announce IEEE Pervasive Computing.

This new quarterly magazine aims to advance mobile and ubiquitouscomputing by bringing together its various disciplines, including peer-reviewedarticles on

• Hardware technologies• Software infrastructure• Real-world sensing and interaction• Human–computer interaction• Security, scalability, and privacy

SUBSCRIBE NOW!

http://computer.org/pervasive

M. SatyanarayananCarnegie Mellon Univ. and Intel Research Pittsburgh

Associate EICs

IEEE PERVASIVE COMPUTING

Editor in Chief

Roy Want, Intel Research; Tim Kindberg, HP Labs; Deborah Estrin, UCLA; Gregory Abowd, GeorgiaTech.;

Nigel Davies, Lancaster University and Arizona University

aspect-oriented development with stratified...

Documents