ArchJava - Connecting Software Architecture to Implementation, By J. Aldrich, C. Chambers and D. Notkin

8/4/2019 ArchJava - Connecting Software Architecture to Implementation, By J. Aldrich, C. Chambers and D. Notkin

1/11

ArchJava:Connect ing Sof tware Archi tecture to Implementat ion

J o n a t h a n A ld r ic h C r a ig C h a m b e r s D a v id N o t k inDepartment of Computer Science and EngineeringUniversity of W ashingtonBox 35235 0Seattle, W A 981 95-23 50 USA+1 206 616-1846

{ jonal , chamb ers , notk in} @ cs .w ash ington .ed uA b s t r a c tSoftware architecture describes the structure of a system, enablingmore effective design, program unders tanding, and formalanalysis. However, existing approaches decouple implementationcode from architecture, allowing inconsistencies, causingconfusion, violating architectural properties, and inhib itingsoftware evolution. ArchJava is an extension to Java thatseamlessly unifies software architecture with implementation,ensuring that the implementation conforms to architecturalconstraints. A case study applying Arch Java to a circuit-designapplication suggests that ArchJava can express architecturalstructure effectively within an implementation, and that it can aidin program understanding and software evolution.1 . I n t r o d u c t i o nSoftware architecture [GS93,PW92] is the organization of asoftware system as a collection of components, connect ionsbetween the components, and constraints on how the componentsinteract. Descr ibing architecture in a formal architecturedescription language (ADL) [MT00] can aid in the specificationand analysis of high-level designs. Software architecture can alsofacilitate the implementation and evolution of large softwaresystems. For example, a system's architecture can show whichcomponents a module may interact with, help identify thecomponents involved in a change, and describe system invariantsthat should be respected during software evolution.Existing ADLs, however, are loosely coupled to implementationlanguages, causing problems in the analysis, implementation,unders tanding, and evolution of software systems. Some ADLs[SDK+95,LV95] connec t components that are implemented in aseparate language. However, these languages do not guaranteethat the implementation code obeys architectural constraints.Instead, they require developers to follow style guidelines thatprohibit common programming idioms such as data shanng.Architectures described with more abstract ADLs[AG97,MQR95] must be implemented in an entirely different

Permission o make digital or hard copies of all or part of this work forpersonal or classroomuse is granted without fee provided hat copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the fu ll citation on the first page. To c o p yotherwise, or republish, to post on servers or to redistribute to fists,requires prior specificpermissionand/ora fee.ICSE'02, May 19-25, 2002, Orlando,Florida, USA.Copyright 2002 ACM 1-58113-472-X/02/0005...$5.00.

language. Thus, it may be difficult to trace architectural featuresto the implementation, and the impl ementation may becomeinconsistent with the architecture as the program evolves. Insummary, while architectural analysis in existing ADLs mayreveal important architectural properties, these properties are notguaranteed to hold in the implementation.In order to enab le architectural reason ing about animplementation, the implementation must obey a consistencyproperty called communica t ion in tegr i ty [MQR95,LV95]. Asystem has communication integrity if implementationcomponents only communicate directly with the components theyare connected to i n the architecture.This paper presents ArchJava, a small, backwards-compatibleextens ion to Java that integrates software architecturespecifications smoothly into Java implementation code. Ourdesign makes two novel contributions:

ArchJava seamlessly unifies architectural structure andimplementation in one language, allowing flexibleimplementation techniques, ensuring traceability betweenarchitecture and code, and supporting the co-evolut ion ofarchitecture and implementation. Arch Java guarantees commtmication integrity between anarchitecture and its implementation, even in the presence ofadvanced architectural features like run time componen tcreation and connection.

To help evalua te our approach, we applied ArchJava to Aphyds, amoderate-size circuit design application. Using an informalarchitecture diagram hand-drawn by the developer as our guide,we reengineered Aphyds to make this architecture explicit in theimplementation code. The result ing architecture revealedinconsistency and complexity in the corrlmunication betweencomponents, and made it easier to refactor the program to clarifythat communication. Our experience suggests that the resultingprogram may be easier to underst and and evolve than the originalprogram.The rest of this paper is organized as follows. After the nextsection's d iscussion of previous work, section 3 introduces theArchJava language. Section 4 describes our experience applyi ngArchJava to Aphyds, and we conclude by discuss ing future work.2 . P r e v i o u s W o r kA r c h i t e c t u r e D e s c r i p t i o n L a n g u a g e s . A number of architecturedescription languages (ADLs) have been defined to describe,model , check, and implement software architectures [MT00].

187


2/11

Many of these languages support sophisticated analysis andreasoning. For example, Wright [AG97] allows architects tospecify temporal communication protocols and check propertiessuch as deadlock freedom. SADL [MQR95] formalizesarchitectures in terms of theories, shows how generic refinementoperations can be proved correct, and describes a number offlexible refinement patterns. Rapide [LV95] supports event-basedbehavioral specification and simulation of reactive architectures.ArchJava's architectural specifications are probably most similarto those of Darwin [MK96], an ADL designed to supportdynamically changing distributed architectures.While Wright and SADL are pure design languages, other ADLshave supported implementation in a number of ways. Uni Con 'stools [SDK+95] generate code to connec t componentsimplemented in other languages, while C2 [MOR96] providesruntime libraries in C++ and Java that connect componentstogether. Rapide architectures can be given implementat ions inan executable sub-language or in languages such as C++ or Ada.More recently, the component-oriented programming languagesComponentJ [SC00] and ACOEL [Sre02] extend a Java-like baselanguage to explicitly support component composition.However, existing ADLs cannot enforce communication ntegrity.Instead, system implementers must follow s ty le gu ide l ines thatensure communication integrity. For example, the Rapidelanguage manual suggests that components should onlycommunicate with other components through their own interfaces,and interfaces should not include references to mutable types.These guidelines are not enforced automatically and areincompatible with common programming idioms such as sharedmutab le data structures.Module Intereo nneeti on Languages. Module interconnectionlanguages (MILs) support system composition from separatemodules [PN86]. Jiazzi [MFH01] is a component infrastructurefor Java, and a similar system, Knit, supports component-basedprogramming in C. These tools are derived from research in toadvanced module systems, exemplified by MzSc beme's Units[FF98] and ML's functors. ADLs differ from MILs in that theformer make c o n n e c t o r s explicit in order to describe d a t a a n dc o n t r o l f l o w between components, while the latter focus ondescribing the u s e s relationship between modules [MT00].Existing MILs cannot be used to describe dynamic architectures,where component object instances are created and linked togetherat run time.Furthermore, MILs provide encapsulation by biding names, whichis insufficient to guarantee comrnnnication integrity in general.For example, first-class functions or objects can be passed fromone module to another, and later used to communicate in waysthat are not directly described in the MIL description. Thus, inthese systems, programmers must fol low a careful methodology toensure that each module communicates only with the modules towhich it is connected in the architecture.CASE tools. A number of computer-aided software engineer ingtools allow programmers to define a software architecture in adesign language such as UML, ROOM, or SDL, and fill in thearchitecture with code in the same language or in C++ or Java.While these tools have powerful capabilities, they either do notenforce communication integrity or enforce it i n a restrictedlanguage that is only applicable to certain domains. For example,the SDL embedded system language prohibits sharing objects

between components. This restriction ensures communicationintegrity, but it also makes the language awkward for general-purpose programming. Many UML tools such as Rational RoseRealTime or I-Logix Rhapsody, in contrast, allow methodimplementations to be specified in a language like C++ or Java.This supports a great deal of flexibi lity, but since the C++ or Javacode may communicate arbitrarily with other system components,there is no guarantee of communication integrity in theimplementation code.O t h e r tools. Tools such as Reflexion Models [MNS01] havebeen developed to show an engineer where an implementation isand is not consistent with an architectural view of a softwaresystem. Similar systems include Virtual Software Classifications[MW99] and Gestalt [SSW96]. Unlike ArchJava, these systemsdescribe architectural components in terms of source code, notrun-time component object instances, and the architecturaldescriptions must be updated separately as the code evolves.Compo nent Infr astru cture s. Component-based infrastructuressuch as COM, CORBA, and Java Beans provide sophisticatedservices such as naming, transactions and distribution forcomponent-based applications. While these infrastructures do notinclude mechanisms for explicitly describing softwarearchitecture, the Arabica environment [RN00] supports C2architectures bui lt from off the shelf Java Beans components.This system shows how software architecture can be expressed i nthe context of component infrastructures, but verifyingcommunication integrity of a Java Beans implementation s left tofuture work.3 . T h e A r c h J a v a L a n g u a g eArchJava is intended to investigate the benefits and drawbacks ofa relatively unexplored part of the ADL design space. Ourapproach extends a practical implemen tation language toincorporate architectural features and enforce communicationintegrity. Key benefits we hope to realize with this approachinclude better program understanding, reliable architecturalreasoning about code, keeping architecture and code consistent asthey evolve, and encouraging more developers to take advantageof software architecture. ArchJava's design also has somelimitations, discussed below in section 3.6.A prototype compiler for ArchJava is publicly available fordownload at the ArchJava web site [Arc02]. Although inArchJava the source code is the canonical representation of thearchitecture, visual representations are also important forconveying architectural structure. Parts of this paper use hand-drawn diagrams to communicate architecture; however, we havealso constructed a simple visualization tool that generatesarchitectural diagrams automatically from ArchJava source code.In addition, we intend to provide an archj avadoc tool thatwould automatically construct graphical and textual web-baseddocumentation for ArchJava architectures.To allow programmers to describe software architecture, ArchJavaadds new language constructs to support c o m p o n e n t s ,connec t ions , and por ts . The rest of this section describes byexample how to use these constructs to express softwarearchitectures. Throughout the discussion, we show how theconstructs work together to enforce communication integrityReports on the ArchJava web site [Arc02] provide more

188


3/11

p u b l i c c o m p o n e n t c l a s s P a r s e r {p u b l i c p o r t i n {

p r o v i d e s v o i d s e t I n f o ( T o k e n s y m b o l ,S y m T a b E n t r y e ) ;

r e q u i r e s T o k e n n e x t T o k e n ()t h r o w s S c a n E x c e p t i o n ;}

p u b l i c p o r t o u t {p r o v i d e s S y m T a b E n t r y g e t I n f o ( T o k e n t ) ;r e q u i r e s v o i d c o m p i l e ( A S T a s t) ;}

v o i d p a r s e ( S t r i n g f i l e ) {T o k e n t o k = i n . n e x t T o k e n () ;A S T a s t = p a r s e F i l e ( t o k ) ;o u t . c o m p i l e ( a st ) ;}

A S T p a r s e F i l e ( T o k e n l o o k a h e a d ) { . . . }v o i d s e t I n f o ( T o k e n t , S y m T a b E n t r y e ) { . . .}S y m T a b E n t r y g e t I n f o ( T o k e n t ) { . .. }

}F i g u r e 1 . A p ar s er c o m p o n e n t i n A r c h J a v a. T h e P a r s e rc o m p o n e n t c l a s s u s e s t w o p o r t s t o c o m m u n i c a t e w i t h o t h e rc o m p o n e n t s i n a c o m p i l e r . T h e p a r s er ' s i n p o r t d e c l a r es ar e q u i r e d m e t h o d t h a t r e q u e s ts a t o k e n f r o m t h e l e x ic a la n a l y z e r , a n d a p r o v i d e d m e t h o d t h a t i n i t i a l iz e s t ok e n s i n t h es y m b o l t a b l e. T h e out port requires a m e t h o d t h a t c o m p i l e sa n A S T t o o b j e c t c o d e , a n d p r o v i d e s a m e t h o d t h a t l o o k s u pt o k e n s i n t h e s y m b o l t a b l e.information, including the complete language semantics and aformal proof of communication integrity in the core of ArchJava.3.1 . Components and PortsA component is a special kind of object that communicates withother components in a structured way. Components are instancesof component classes, such as the Pa rs er in Figure 1.A component can only communicate with other components at itslevel in the architecture through explicitly declared ports--regularmethod calls between components are not allowed. A portrepresents a logical communication channel between a compon entand one or more components that it is connected to.Ports declare three sets of methods, specified using ther e q u i r e s , p r o v i d e s , a n d b r o a d c a s t s keywords. Ap r o v i d e d m e t h o d i s i m p l e m e n t e d b y t h e c o m p o n e n t a n d i sa v a i la b l e t o b e c a l l e d b y o t h e r c o m p o n e n t s c o n n e c t e d t o t h i s p o rt .Conversely, each required method is provided by some othercomponent connected to this port. A component can invoke oneof its required methods by sending a message to the port thatdefines the required method. For example, the p ar s e methodcalls ne xt To ke n on the parser's in port. Broadcast methodsare just like required methods, except that they can be connectedto any number of implementations and must return vo i d .The goal of this port design is to specify both the servicesimplemented by a component and the services a component needsto do its job. Required interfaces make dependencies explicit,reducing coupling between components and promotingunderstanding of components in isolation. Ports also make iteasier to reason about a compon ent's communication patterns.

C o m p i l e rl scanner parser ~ codegen ]

p u b l i c c o m p o n e n t c l a s s C o m p i l e r {p r i v a t e f i n a l S c a n n e r s c a n n e r . . . . ;p r i v a t e f i n a l P a rs e r p a r s e r . . . . ;p r i v a t e f i n a l C o d e G e n c o d e g e n . . . . ;c o n n e c t s c a n n e r . o u t , p a r s e r . i n ;c o n n e c t p a r s e r o u t , c o d e g e n . i n ;p u b l i c s t a t i c v o i d m a i n ( S t r i n g a r g s [ ] ) {

n e w C o m p i l e r ( . o m p i l e ( a r g s );}p u b l i c v o i d c o m p i l e ( S t r i n g a r t s [] ) {

/ / f o r e a c h f i l e i n a r t s d o : . p a r s e r p a r s e ( f i l e ) ; . . .}}

F i g u r e 2 . A g r a p h i c a l c o m p i l e r a r c h it e c t u r e a n d i t s A r c h J a v ar e p re s en t a ti o n . T h e C o m p i l e r c o m p o n e n t c la s s c o n t a in st h re e s u b c o m p o n e n t s - - a S c a n n e r , a P a r s e r , a n d aC o d e G e n . T h i s c o m p i l e r a r c h i t ec t u r e f o ll o w s t h e w e l l - k n o w np i p e li n e c o m p i l e r d e s i gn [ G S 9 3 ]. T h e s c a n n e r , p a r s e r , a n dc o d e g e n c o m p o n e n t s a re c o n n e c te d i n a l in e a r s e q u en c e , w i t ht h e o u t p o r t o f o n e c o m p o n e n t c o n n e c t e d t o t h e i n p o r t o f t h en e x t c o m p o n e n t .ArchJava supports design with ab s t ra ct components and ports,which allow an architect to specify and typecheck an ArchJavaarchitecture before beginning program implementation.3.2 . Component Composit ionIn ArchJava, hierarchical software architecture is expressed withcomposite components, which are made up of a number ofsubcomponents connected together. A subcomponent ~ is acomponent instance nested within another component. Singletonsubcomponents are typically declared with f i n a l fields ofcomponent type. Figure 2 shows how a compi ler' s architecturecan be expressed in ArchJava. The example shows that the parsercommunicates with the scanner using one protocol, and with thecode generator using another. The architecture also implies thatthe scanner does not communicate directly with the codegenerator. A primary goal of ArchJava is to ease programunderstanding tasks by supporting this kind of reasoning aboutprogram structure.C o n n e c t i o n s . The symmetric connect rimitive connects twoor more ports together, binding each required method to aprovided method with the same name and signature. Thearguments to connect may be a component's own ports, or thoseof subcomponents in fi n al fields. Connection consistencychecks are performed to ensure that each required method isbound to a unique provided method.Provided methods can be implemented by forwarding invocationsto subcomponents or to the required methods of another port. The

1 Note: the term subcomponent indicates composition, whereasthe term component subclass would indicate inheritance.

189


4/11

d e t a i l e d s e m a n t i c s o f m e t h o d f o r w a r d i n g a n d b r o a d c a s t m e t h o d sa r e g i v e n i n t h e l a n g u a g e r e f e r e n c e m a n u a l o n t h e A r c h J a v a w e bs i t e [ A r c 0 2 ] . A l t e r n a t i v e c o n n e c t i o n s e m a n t i c s , s u c h a sa s y n c h r o n o u s c o m m u n i c a t i o n , c a n b e i m p l e m e n t e d i n A r c h J a v ab y w r i t i n g c u s t o m " s m a r t c o n n e c t o r " c o m p o n e n t s t h a t t a k e t h ep l a c e o f o r d i n a r y c o n n e c t i o n s i n t h e a r c h i t e c t u re .3 . 3. C o mm u n i c a t i o n In t e g r it yT h e c o m p i l e r a r c h it e c t u r e i n F i g u r e 2 s h o w s t h a t w h i l e t h e p a r s e rc o m m u n i c a t e s w i t h t h e s c a n n e r a n d c o d e g e n e r a t o r , t h e s c a n n e ra n d c o d e g e n e r a t o r d o n o t d i r e c t l y c o m m u n i c a t e w i t h e a c h o t h e r .I f t h e d i a g r a m i n F i g u r e 2 r e p r e s e n t e d a n a b s t r a c t a r c h i t e c t u r e t ob e i m p l e m e n t e d i n J a v a c o d e , i t m i g h t b e d i f f i c u l t t o v e r i f y t h ec o r r e c t n e s s o f t h i s r e a s o n i n g i n t h e i m p l e m e n t a t i o n . F o r e x a m p l e ,i f th e s c a n n e r o b t a i n e d a r e f e r e n c e t o t h e c o d e g e n e r a t o r , i t c o u l di n v o k e a n y o f t h e c o d e g e n e r a t o r ' s m e t h o d s , v i o l a t i n g t h ei n t u i t io n c o m m u n i c a t e d b y t h e a r c h i te c t u r e . I n c o n t r as t ,p r o g r a m m e r s c a n h a v e c o n f i d e n c e t h a t a n A r c h a v a a r c h i t e c t u r ea c c u r a t e l y r e p r e s e n t s c o m m u n i c a t i o n b e t w e e n c o m p o n e n t s ,b e c a u s e t h e l a n g u a g e s e m a n t i c s e n f o r c e c o m m u n i c a t i o n i n t e g r i ty .C o m m u n i c a t i o n i n t e g r i t y i n A r c h J a v a m e a n s t h a t c o m p o n e n t s i na n a r c h i t e c t u r e c a n o n l y c a l l e a c h o t h e r ' s m e t h o d s a l o n g d e c l a r e dc o n n e c t i o n s b e t w e e n p o r ts . E a c h c o m p o n e n t i n t h e a r c h i t e c t u r ec a n u s e i t s p o r t s t o c o m m u n i c a t e w i t h t h e c o m p o n e n t s t o w h i c h i ti s c o n n e c t e d . H o w e v e r , a c o m p o n e n t m a y n o t d i r e c t l y i n v o k e t h em e t h o d s o f c o m p o n e n t s o t h e r t h a n i t s o w n s u b c o m p o n e n ts ,b e c a u s e t h i s c o m m u n i c a t i o n m a y n o t b e d e c l a r e d i n t h ea r c h i t e c t u r e - - a v i o la t i o n o f c o m m u n i c a t i o n i n te g r it y . W ed e s c r i b e h o w c o m m u n i c a t i o n i n t e g r i ty i s e n f o r c e d i n s e c t io n 3 . 5 .3 . 4 . D y n a m i c A r c h i t e c t u r e sT h e c o n s t r u c t s d e s c r i b e d a b o v e e x p r e s s a r c h i t e c t u r e a s a s t a t i ch i e r a r c h y o f i n t e r a c t in g c o m p o n e n t i n s t a n c e s, w h i c h i s s u f f i c ie n tf o r a l a r g e c l a s s o f s y s t em s . H o w e v e r , s o m e s y s t e m a r c h i te c t u r e sr e q u i r e c r e a t i n g a n d c o n n e c t i n g t o g e t h e r a d y n a m i c a l l yd e t e r m i n ed n u m b e r o f c o m p o n e n t s.D y n a m i c C o m p o n e n t C r e a t io n . C o m p o n e n t s c a n b ed y n a m i c a l l y i n s t a n t ia t e d u s i n g t h e s a m e n e w s y n t a x u s e d t o c r e a t eo r d i n a r y o b j e c t s . F o r e x a m p l e , F i g u r e 2 s h o w s t h e c o m p i l e r ' sm a i n m e t h o d , w h i c h c r e a te s a C o m p i l e r c o m p o n e n t a n d c a l lsi ts c o m p i l e m e t h o d . A t c r e a ti o n t im e , e a c h c o m p o n e n t r e co r d st h e c o m p o n e n t i n s t a n c e t h a t c r e a t e d i t a s i t s p a r e n t c o m p o n e n t .F o r c o m p o n e n t s l i k e C o m p i 1 e r t h a t a r e i n s t a n t ia t e d o u t s i d e t h es c o p e o f a n y c o m p o n e n t i n s t a nc e , t h e p a r e nt c o m p o n e n t i s n u l l .C o m m u n i c a t i o n i n t e g r i t y p l a c e s r e s t r i c t i o n s o n t h e w a y s i n w h i c hc o m p o n e n t i n s t a nc e s c a n b e u s e d. B e c a u s e o n l y a c o m p o n e n t ' sp a r e n t c a n i n v o k e i t s m e t h o d s d i r e c t l y , i t i s e s s e n t i a l t h a t t y p e dr e f e r e n c e s t o s u b c o m p o n e n t s d o n o t e s c a p e t h e s c o p e o f th e i rp a r e n t c o m p o n e n t . T h i s r e q u i r e m e n t i s e n f o r c e d b y p r o h i b i t i n gc o m p o n e n t t y p e s i n t h e p o r t s a n d p u b l i c in t e r f a c e s o f c o m p o n e n t s ,a n d p r o h i b i t i n g o r d i n a r y c l a s s e s f r o m d e c l a r i n g a r r a y s o r f i e ld s o fc o m p o n e n t t y p e . S i n c e a c o m p o n e n t i n s t a n c e c a n s t il l b e f r e e l yp a s s ed b e t w e e n c o m p o n e n t s as a n e x p r e s s io n o f t y p e O b j e c t , aComponentCastException i s t h r o w n i f a n e x p r e s s i o n i sd o w n c a s t t o a c o m p o n e n t t y p e o u t s i d e t h e s c o p e o f it s p a r e n tc o m p o n e n t i n s t a n c e .C o n n e c t E x p r e s s i o n s . D y n a m i c a l l y c r e a te d c o m p o n e n t s c a n b ec o n n e c t e d t o g e t h e r a t r u n t i m e u s i n g a connec t express ion . F o ri n s t a n c e , F i g u r e 3 s h o w s a w e b s e r v e r a r c h i t e c t u r e w h e r e a

r e R o u t e rserve W o r k e r

p u b l i c c o m p o n e n t c l a s s W e b S e r v e r {p r i v a t e f i n a l R o u t e r r = n e w R o u t e r ( ) ;c o n n e c t r . r e q u e s t , c r e a t e ;c o n n e c t p a t t e r n R o u t e r . w o r k e r s , W o r k e r . s e r v e ;p r i v a t e p o r t c r e a t e {

p r o v i d e s r . w o r k e r s r e q u e s t W o r k e r ( ) {f i n a l W o r k e r n e w W o r k e r = n e w W o r k e r ( ) ;r . w o r k e r s c o n n e c t i o n

= c o n n e c t ( r . w o r k e r s , n e w W o r k e r . s e r v e ) ;r e t u r n c o n n e c t i o n ;}}

p u b l i c v o i d r u n ( ) { r . l i s t e n ( ) ; }

p u b l i c c o m p o n e n t c l a s s R o u t e r {p u b l i c p o r t i n t e r f a c e w o r k e r s {

r e q u i r e s v o i d h t t p R e q u e s t ( I n p u t S t r e a m i n,O u t p u t S t r e a m o u t)}p u b l i c p o r t r e q u e s t {

r e q u i r e s t h i s . w o r k e r s r e q u e s t W o r k e r ( ) ;}p u b l i c v o i d l i s t en ( ) {

S e r v e r S o c k e t s e r v e r = n e w S e r v e r S o c k e t ( 8 0 ) ;w h i l e ( t r u e) {

S o c k e t s o c k = s e r v e r . a c c e p t ( ) ;t h i s . w or k e r s c o n n = r e q u e s t . r e q u e s t W o r k e rc o n n . h t t p R e q u e s t ( o c k . g e t I n p u t S t r e a m ( ,

s o c k . g e t O u t p u t S t r e a m ()) ;}} }p u b l i c c o m p o n e n t c l a s s W o r k e r e x t e n d s T h r e a d {

p u b l i c p o r t s e r v e {p r o v i d e s v o i d h t t p R e q u e s t ( I n p u t S t r e a m i n,O u t p u t S t r e a m o u t)

t h i s . i n = i n ; t h i s . o u t = o u t ; s t a r t ( ) ;}}p u b l i c v o i d r u n () {

F i l e f = g e t R e q u e s t e d F i l e ( i n ) ;s e n d H e a d e r s ( o u t ) ;c o p y F i l e ( f , o u t ) ;}

/ / m o r e m e t h o d & d at a d e c l a r a t i o n s . . .}

F i g u r e 3 . A w e b s e r v e r a r c h i t e c t u r e . T h e R o u t e rs u b c o m p o n e n t a c c e p t s H T T P r e q u e s t s a n d p a s se s t h e m o n t o as e t o f W o r k e r c o m p o n e n t s t h a t r e s p o n d . W h e n a r e q u e s tc o m e s i n , t h e R o u t e r r e q u e s t s a n e w w o r k e r c o n n e c t i o n o n i t sr e q u e s t p o r t. T h e W e b S e r v e r t h e n c r e a t e s a n e w w o r k e ra n d c o n n e c t s i t t o t h e R o u t e r . T h e R o u t e r a s s i g n s r e q u e s t st o W o r k e r s t h r o u g h i ts w o r k e r s p o rt .R o u t e r c o m p o n e n t r e c ei v e s i n c o m i n g H ' I T P r e q u e s ts an d pa s s e st h e m t h r o ug h c o n n e c t i o n s t o W o r k e r c o m p o n e n t s t h at s e r v e t h er eq u es t. T h e r e q u e s t W o r k e r m e t h o d o f t h e w e b s e rv e rd y n a m i c a ll y c r e at e s a W o r k e r c o m p o n e n t a n d t h e n c o n n ec t s it ss e r v e p o rt t o t h e w o r k e r s p o rt o n t h e R o u t e r .

19 0


5/11

Communication integrity requires each component to explicitlydocument the kinds of architectural interactions that are permittedbetween its subcomponents. A connec t ion pa t tern is used todescribe a set of connections that can be instantiated at run timeusing connect expressions. For example, co nn ec t pa tt er nR o u t e r . w o r k e r s , W o r k e r . s e r v e describes a set ofconnections between the R o u t e r subcom ponent and dynamicallycreated W o r k e r subcomponents.Each connect expression must match a connection patterndeclared in the enclosing component. A connect expressionmatches a connection pattern if the connected ports are identicaland each connected component instance is an instance of the typespecified in the pattern. The connect expression in the web serverexample matches the corresponding connection pattern becausethe r and new Wo rk er components in the connect expressionhave static types Ro ut er and Wo rk er , as declared in thepattern.Port Interfaces. Often a single component participates in severalconnections using the same conceptual protocol. For example,the Ro u t er component in the web server comrmmicates withseveral Worker components, each through a differentconnection. A por t in ter face describes a port that can beinstantiated several times to communicate through differentconnections.Each port interface defines a type that includes all of the requiredmethods in that port. A port interface type combines a port'srequired interface with an instance expression that indicateswhich component instance the port belongs to. For example, inthe Ro ut er component, the type th is . wo rk er s refers to aninstance of the wo rk er s port of the current Ro ut er component.Similarly, in the We bS er ve r, the type r. wo rk er s refers to aninstance of the wo rk er s port of the r subcomponent. Portinterface types can be used in method signatures such asre qu es tW or ke r and in local variable declarations such asco nn in the li st en method. In ArchJava, the required methodsof a port can only be called by the component instance the portbelongs to. Therefore, required methods can only be invoked onexpressions of port interface type when the instance expression isth is , as shown by the call to ht tp Re qu es t withinR o u t e r . l i s t e n .Port interfaces are instantiated by connect expressions. A connectexpression returns a connection object that represents theconnection. This connection object implements the portinterfaces of all the connected ports. Thus; in Figure 3, theconnection object c o n n e c t i o n implements the interfacesn e w W o r k e r , s e r v e and r . w o r k e r s , and can therefore beassigned to a variable of either type.Provided methods can obtain the connection object through whichthey were invoked using the s e n d e r keyword. The detailedsemantics of s e n d e r and other language features are covered inthe ArchJava language reference available on the ArchJava website [Arc02].Removing Components and Connect ions . Just as Java does notprovide a way to explicitly delete objects, ArchJava does notprovide a way to explicitly remove components and connections.Instead, components are garbage-collected when they are nolonger reachable through direct references or connections. Forexample, in Figure 3, a Worker component will be garbage

collected when the reference to the original worker(newWorker) and the references to its connections(c on ne ct io n and eonn) go out of scope, and the thread withinWorker finishes execution.3 .5 . E n f o r c i n g C o m m u n i c a t i o n I n t eg r i tyAn ArchJava architecture shows all of the control-flow pathsbetween sibling components in a subsystem. Thus,communication integrity requires that all inter-component methodcalls in ArchJava must follow architectural connections, exceptmethod calls from a component to its children.There are two ways in which communication integrity could beviolated, corresponding to the two kinds of method calls inArchJava: direct method calls, and method calls through ports.Below, we describe intuitively how communication integrity isenforced in each of these cases. This intuition correspondsclosely to the actual proof of communication integrity in a formalversion of ArchJava [Arc02], which we o mit for space reasons.Direct Method Calls. A direc t componen t me thod ca l l is amethod call that dispatches to a component instance. The send ingc o m p o n e n t of the method call is the receiver of the most recentcomponent method on the stack.Communication integrity in Arch Java requires that all directcomponent method calls made from a sending component instanceC are to C itself, or to an immediate subcomponent of C. InArchJava, the only way to directly invoke a component method isto call a method on an expression of component type. ArchJavaenforces communication integrity by ensuring the invariant thatall of the component-typed expressions in the scope of acomponent instance C refer to C itself or to an immediatesubcomponent o f C.In our formal system, we prove this invariant by induction overprogram execution, with a case analysis of component typeintroductions. The invariant is true in the base case of componentcreation, because a component's parent is by definition thecomponent that created it. Component types can only be readfrom or written to fields of the current component t hi s , so theyare guaranteed to be children of t h i s by the inductionhypothesis. Similarly, component types cannot be passed directlybetween components. The final case is casts to component type;but in ArchJava, component casts dynamically check that the castexpression's parent component is the current component this,ensuring that the invariant continues to hold.Metho d Calls throu gh Ports. A connection pattern in acomponent instance C allows method calls between immediatesubcomponents of C through the connected ports. The ArchJavacompiler uses a two-part test to verify that all method callsthrough ports conform to a connection pattern. First, it checksthat every connect expression in a component C matches aconnect pattern declared in C; the invariant described aboveensures that the connected component instances aresubcomponents of C. Second, the compiler uses port interfacetypes to verify that each connectio n object can only be used by thecomponent instances it connects. In ArchJava's type system, onlythe component instance named in the port interface type ispermitted to make calls through the connection object thatimplements that port interface type. Thus, ArchJava's type systemprohibits method calls that wo uld violate architectural constraints.

191


6/11

3 .6 . L i m i t a t i o n s o f A r c h J a v aThere are currently several limitations to the ArchJava approach.Our technique is presently only applicable to programs written ina single language and running on a single JVM, although theconcepts should extend to any statically typed language.Architectures in Arch ava are more concrete than architectures inADLs such as Wright, restricting the ways in which a givenarchitecture can be implemented--for example, inter-componentconnections must be implemented with method calls. Also,because of our focus on ensuring communication integrity, we donot yet support other types of architectural reasoning, such a sreasoning about connection protocols, architectural styles, orcomponent multiplicity.ArchJava's definition of cornmtmication integrity supportsreasoning about communication through method calls betweencomponents. Components can also communicate through shareddata or the runtime system. Because existing ways to controlcommunication through shared data involve significantrestrictions on programming style, we chose not to adopt thesemechanisms. Future work includes developing ways to reasonabout communicat ion through shared data while preservingexpressiveness. Meanwhi le, our experience (described below)suggests that rigorous reasoning about architectural control flowcan aid in program understanding and evolution, even in thepresence of shared data structures.4 . E v a l u a t i o nIn order to determine whether the ArchJava language meets itsdesign goals, we undertook a case study to answer the followingexperimental questions: Can ArchJava express the architecture of a real program ofsignificant complexity? How difficult is it to reengineer a Java program in order toexpress its architecture explicitly in ArchJava? Does expressing a progra m's architecture in ArchJava help

or hinder software evolution?4 . 1 . M e t h o d o l o g yOur approach to answering these questions was to translate a Javaprogram into ArchJava, using the conceptual architectureprovided by the program's developer as a guide. In addition to adirect answer to the first two questions for the chosen programand programmer, we hoped to gain some insight into the thirdquestion. Other goals included learning about the conceptualarchitecture of Java programs, gain ing practical experience usingArchJava, and refining ArchJava's language design. In theprocess of our case study, we formed hypotheses for futureresearch, outlined in italics below.We looked for Java programs that would be at least 10,000 linesof code--large enough that a developer would have difficultykeeping it all in his or her head, and thus might benefit from anexplicit software architecture. To avoid biasing our study towardarchitectures easily expressible in ArchJava, we chose a programand architecture conceived and developed by a third party. Ourchoice for this case study was the Aphyds program described inthe next subsection.The study' s subject (one of us, hereafter "we") was a graduatestudent with five year's experience of system programming inJava. Although the subject was the developer of the ArchJava

compiler, he was unfamiliar with Aphyds and had little experiencewriting user interfaces in Java. Thus, the study reflects thecommon reality of a programmer asked to evolve an unfamiliarsystem.We reengineered Aphyds to express the conceptual architecturedescribed by the developer. After browsing the code to determinewhich classes corresponded to the components in the developer'sconceptua l architecture, we converted these classes into ArchJavacomponent classes. The resulting architecture was fine r grainedthan the devel oper 's conceptual architecture, so we grouped thecomponent classes into higher-level components.In order to gain insight into ArchJava's support for softwareevolution tasks, we performed three experiments. First, weanalyzed the inter -component communication patterns in Aphyds,describing and categorizing each different message. Next, werefactored the architecture to simplify and regularize these inter-component communication patterns. Finally, we removed adefect from both the original source code and the ArchJavaversion of Aphyds.The next three subsections describe the reengineer ing process, thesoftware evolution experiments, and how our experience affectedthe ArchJava language design.4 .2 . R e e n g i n e e r i n g A p h y d sAphyds, for --Academic Physical Design System, i s a pedagogicalcircuit layout application written by an electrical engineeringprofessor for one of his classes. Students are given the programwith several key algorithms omitted, and are asked to code thealgorithms as assignments. The developer is an experiencedprogrammer with a Ph.D. in computer science, but had no Javabackground prior to writing Aphyds. The application code is12,101 lines long, as measured by the Unix wc (word count)program, not c ounting the Java and Symantec libraries used.Figure 4 shows the developer's drawing of the conceptualarchitecture of Aphyds. According to the developer, thisabstraction allows him to evolve the system even though the codebase is too large to hold in his head at once.Validating Aphyds ' Architecture. We expected that thisarchitecture would be generally accurate, although it might leaveout some details. The developer concurred, saying that all of thelinks in the architecture are present, but may be subtle to find.Furthermore, the division between UI and functional classes is animportant conceptual device for him, but he told us that thisdivision would not necessarily be obvious from looking at thecode.We decided to test this hypothesis by using the Reflexion Modeltechnique [MNS01] to compare the connections in thedeveloper's conceptual diagram with actual communicationpatterns between classes in the source code. To each of thedeveloper's conceptual components, we assigned one or moreimplementation classes. We ignored library classes as well asdata structures shared by the whole application. We compared thecall graph computed by a simple tool to the arrows in thedeveloper's diagram, reversing the direction of his dataflowarrows to reflect control flow in the opposite direction.Overall, the architecture was a good overview of communicati onin Aphyds. However, the study revealed several minor missingcommunicat ion paths in the architecture. For example, although

192


7/11

F i g u r e 4 . T h e d e v e lo p e r ' s d r a w i n g o f A p h y d s ' s a r c h i t ec t u r e .T h e a r c h i t e c tu r e f o l l o w s t h e M o d e l - V i e w d e s i g n p a t t e r n , w i t ht h e u s e r i n t e r f a c e a b o v e t h e l i n e i n t h e m i d d l e o f th e d i a g r a ma n d t h e c i r c u i t d a t a b a s e a n d c o m p u t a t i o n a l c o d e b e l o w . T h eu s e r i n t e r f a c e c o n s i s t s o f t h e C i r c u i t V i e w e r w i n d o w a n ds e v e r a l s u b s i d i a r y w i n d o w s . B e l o w t h e li n e a r e a c i r c u i td a t a b as e o f N o d e a n d N e t o b j ec t s a n d a s e t o f c o m p u t a ti o n a lm o d u l e s t h a t a c t o n t h e c i r c u i t d a t a b a s e . T h e u n l a b e l e da r r o w s r e p r e s e n t d a t a f l o w , w h i l e t h e a r r o w s l a b e l e d c a l lr e p r e s e n t c o n t r o l f l o w .most calls in the application go from the user interface into themodel, we found two callbacks going the opposite direction. Wealso discovered that the communication paths between theCi rc ui tV ie we r and the other viewer objects were actually bi-directional.Moreover, this architecture is also incomplete in some importantrespects. It does not describe the multiplicit y or temporallifetimes of components. It is at a high leve l of granularity, aseach user interface component represents between 2 and 7 objects.Several complex and messy multi-object communicationprotocols, dealing with diverse issues, are represented with singlelines in the architecture.Although the developer's conceptual architecture was informaland flawed in certain respects, this is a realistic example ofcommon practice today. Many developers do not define a formaland precise architecture, but instead communicate the structure oftheir applications through informal diagrams. One of themotivations for ArchJava is to provide an easy way for developersto gain the benefits of a formal architecture, by embedding it inthe code that they write. Our experience with the conceptualarchitecture of Aphyds is summarized by our first hypothesis,which corroborates findings in the Reflexion Model work[MNS01].

Hypothesis 1: Developers have a conceptual model of theirarchitecture that is mostly accurate, but this model may be asimplification of reality, and it is often not explicit in the code.R e e n g i n e e r i n g P r o c e s s . We decided to design a staticarchitecture that follows the developer's drawing as closely aspossible. Therefore, we proposed an Ap hy ds component toencapsulate the whole application. The Ap hy ds componentwould contain the UI components, and would connect them to anA p h y d s M o d e l component, which would contain asubcomponent for each unit in the lower half of the developer'sdiagram. We decided that the No de and Ne t objects in thecircuit database would remain shared between components; itwould have been extremely unnatural to restrict them to within theC i r c u i t component.Hypothesis 2: Programming languages that prohibit sharingdata between components are too inflexible to express the naturalarchitecture fo r many programs.We proceeded to reengineer Aphyds to take advantage of thearchitectural features of ArchJava. Our technique was to chooseone class at a time from the architectural diagram, and turn it intoa component class. We started with the C i r c u i t class, as thisforms the central part of the architectural diagram. We expectedthat this process would primarily consist of converting instancevariables into ports or subcomponents, invok ing methods on portsinstead of instance variables, and connecting the portsappropriately in the architecture.The structure of the Aphyds implementation made this task moredifficult. We initially believed that the architectural drawingrepresented a set of objects whose membership didn't change overthe course of program execution. This was in fact true of the userinterface, but the circuit database and computational componentswere re-created each time they were read from a file or executed.There were a number of methods that set instance variables in theuser interface to point to these components; however, many ofthese methods also had side effects such as refreshing the screen.We decided to convert the system into a static architecture withcomponents that persisted for the entire execution o f the program.Our rationale was that this architecture would be simpler to reasonabout than a dynamically changing architecture. Therefore, wetransformed Aphyds to re-initialize old circuit data structuresinstead of creating new data structures each time the circuit wasloaded. We also separated out the refresh logic from the instance-variable setting messages, so that the architectural connectionscould be set up at startup time, but the display would still workproperly throughout program execution. This reengine enngprocess introduced a number of subtle bugs, partly because we didnot recognize the dual nature of these messages until partwaythrough the study.Hypothesis 3: Describing an existing progr am's architecture withArchJava may involve significant restructuring if the desiredarchitecture does not match the implementation wel lR e e n g i n e e r i n g C o s t . Due to the complexity of separating out theC i r c u i t component and our initial unfamiliarity with theapplication, this first reengineefing step took a sign ificant amountof tim e-- abo ut 91/2 programmer hours, including t ime to fixseveral injected defects.

193


8/11

p u b l i c c o m p o n e n t c l a s s A p h y d s {// user i n t e r f a c e c o m p o n e n t sf i n a l F l o o r p l a n V i e w e r f l o o r p l a n . . . . ;f i n a l C h a n n e l R o u t e V i e w e r c h a n n e l R o u t e . . . . ;f i n a l P l a c e R o u t e V i e w e r p l a c e R o u t e . . . . ;f i n al C i r c u i t V i e w e r v i e w e r . . . . ;// w i n d o w e v e n t c o m m u n i c a t i o np r i v a t e p o r t w i n d o w { ... };c o n n e c t w i n d o w , c h a n n e l R o u t e . w i n d o w ,

v i e w e r . w i n d o w , p l a c e R o u t e . w i n d o w ,f l o o r p l a n . w i n d o w ;

// command protocolc o n n e c t v i e w e r . c o m ma n d , p l a c e R o u t e . c o m m an d ,

c h a n n e l R o u t e . c o m m a n d , f l o o r p l a n . c o m m a n d ;// m o d e l c o m p o n e n t sf i n a l A p h y d s M o d e l m o d e l . . . . ;// p r o t o c o l s f o r c o m m u n i c a t i o n with the m o d e lc o n n e c t v i e w e r . c i r c u i t , p l a c e R o u t e . c i r c u i t ,

m o d e l . c i r c u i t ;c o n n e c t v i e w e r . p a r t i t i o n , m o d e l . p a r t i t i o n ;c o n n e c t f l o o r p l a n . f l o o r p l a n , m o d e l . f l o o r p l a n ;c o n n e c t p l a c e R o u t e . pl a c e , v i e w e r . p la c e ,

m o d e l . p l a c e ;c o n n e c t p l a c e R o u t e .r o u t e r , v i e w e r . p la c e ,m o d e l . r o u t e r ;

c o n n e c t c h a n n e l R o u t e . c ha n n e l , m o d e l . c h a n n e l s ;// the program's starting pointp u b l i c s t a t i c v o i d m a i n ( S t r i n g a r g s [ ] ) {

n e w A p h y d s ( . u n ( ;}p u b l i c v o i d r u n ( ) { v i e w e r . s e t V i s i b l e ( t r u e ) ; }}

p u b l i c c o m p o n e n t c l a s s A p h y d s M o d e l {f i n a l C i r c u i t c i r c u i t D a t a . . . . ;f i n a l P a r t i t i o n e r p a r t i t i o n e r . . . . ;f i n a l F l o o r p l a n n e r f l o o r p l a n n e r . . . . ;f i n a l P l a c e r p l a c e r . . . . ;f i n a l G l o b a l R o u t e r g l o b a l R o u t e r . . . . ;f i n a l C h a n n e l R o u t e r c h a n n e l R o u t e r . . . . ;p u b l i c p o r t p l a c e { . .. }p u b l i c p o r t p a r t i t i o n { . .. }p u b l i c p o r t f l o o r p l a n { . .. }p u b l i c p o r t c i r c u i t { . .. }p u b l i c p o r t r o u t e r { . .. }p u b l i c p o r t c h a n n e l s { ... }c o n n e c t c i r c u i t, p a r t i t i o n e r . c i r c u i t ,

f l o o r p l a n n e r . c i r c u i t , p l a c e r . c i r c u i t ,g l o b a l R o u t e r . c i r c u i t , c i r c u i t D a t a . m a i n ,c h a n n e l R o u t e r . c i r c u i t ;

c o n n e c t p l a c e , g l o b a l R o u t e r . p l a c e ,p l a c e r . p l a c e ;

c o n n e c t p a r t i t i o n , p a r t i t i o n e r . p a r t i t i o n ;c o n n e c t f l o o r p l a n , f l o o r p l a n n e r . f l o o r p l a n ;c o n n e c t r o u t e r, g l o b a l R o u t e r . r o u t e r ;c o n n e c t c h a n n el s , c h a n n e l R o u t e r . c h a n n e l s ;}

F i g u r e 5 . A r c h J a v a c o d e f o r t h e Aphyds a n d AphydsModelc o m p o n e n t s . T h e r e a r e su b c o m p o n e n t d e c l a ra t i o n s f o r e a c he l e m e n t i n t h e u s e r i n t e r f a c e , a s w e l l a s a m o d e l c o m p o n e n tt h a t c o n t a in s t h e c o m p u t a t i o n a l c o d e . C o n n e c t d e c l a r a t io n ss h o w c o m m u n i c a t i o n pa t t e r n s b e t w e e n c o m p o n e n t s .

Aphyds

F l o o r p l a n D i a < l a c ~ ou t ~ann e lRou t eV i ewe rI A p h y d sM o d e l

F i g u r e 6 . A v i s u a l i z a t io n o f t h e A p h y d s a r c h it e c t u r e ,a u t o m a t i c a l l y d e r i v e d f r o m t h e A r c h J a v a s o u r ce c o d e . B o x e sr e p r e s e n t s u b c o m p o n e n t s , a n d a r r o w s r e p r e s e n t i n t e r -c o m p o n e n t c o n t r o l f l o w . T h e o v a l d e n o t e s t h e w i n d o w p o r t ,u s e d f o r w i n d o w m a n a g e m e n t m e s s a g e s l i k e sc r e e n r e f r es h .T h e c i r c u i t d a t a b a s e a n d c o m p u t a t i o n a l c od e i n t h ed e v e l o p e r ' s d i a g r a m h a v e b e e n i s o l a t e d in t h e AphydsModelc o m p o n e n t .O n e o f t h e r e a s o n s t h i s t a s k m a y h a v e b e e n d i f fi c u l t i s t ha t i t w a sdo n e i n a s i ng le la r ge step , i nvo lv i ng s i gn i f i c a nt a ppl i c a t i o nrestructuring. A n important refactoring p rincip le i s to test apr o gr a m r epea ted ly w hi le ma ki ng i nc r ementa l c ha nges , r a thertha n ma ki ng a la r ge c ha n ge a l l a t o nc e [ FB B +99] . I f w e ha d f ir s ttr a nsf o rmed the c o d e i n to a n eq ui va lent J a va pr o gra m w i th a s ta t i cs tr u ct u re , a n d o n l y t h e n c o n v e r t e d C i r c u i t i n t o a c o m p o n e n tc la s s , w e mi ght ha ve been a b le to detec t a nd r epa i r i n j ec teddef ec t s ea r l ier a nd a t a sm a l ler c o s t .H yp o t h es i s 4 : Re fa c t o r i n g a n a p p l i ca t i o n t o ex p o se i t sa rch i t ec t u re i s d o n e m o s t e f f i c ien t l y i n sm a l l i n crem en t s .W e f o un d suppor t f o r th i s hypo thes i s w hen tr a ns fo r mi ng ther e m a i n i n g c l a s s e s i n t o c o m p o n e n t s . T h e s e s m a l l e r t a s k s w e n tq u i c k l y , t a k i n g b e t w e e n 3 0 a n d 9 0 m i n u t e s e a c h . W e s p e n t a t o t alo f 3 0 h o u r s w or k i n g o n A p h y d s - - 1 5 h o u r s c on v e r t in g t he m o d e li n to c o mpo nent s , 8* /2 ho ur s c o nver t i ng the user i n ter f a c e i n toc o mp o nen ts , a nd 6 * /2 ho ur s r efa c tor ing the r e su l t i ng a r c h i tec tur e( a s desc r i bed be lo w ) . T hi s w o r ks o u t to a ppr o xi ma te ly 21 /2 ho ur so f w o r k p e r K L O C . T h e cu r re n t c o d e i s 1 2 6 5 2 l i n e s l o n g - - o n l y551 l i nes lo nge r tha n the o r i g i na l a ppl i c a t i o n , sugges t i ng tha t thea dded a r c h i tec ture c o de w a s la r ge ly o f f se t by s i m pl i f i c a t i o ns tothe a ppl i c a t i o n c o de .H yp o t h e s i s 5 : Ap p l i ca t i o n s ca n b e t ra n s l a t ed i n t o Arch J a v a w i t ha m o d es t a m o u n t o f e f fo r t, a n d w i t h o u t ex cess i ve co d e b l o a t .Fur ther s tudy i s needed to va l i da te th i s hypo thes i s o n la r gerpr o gr a ms , a nd to deter mi ne ho w the a mo unt o f t i me spent i ntr ans lat i on va r i es w i th the s i ze o f the a pp l i c a t i o n a nd the extent o farchitectural refactoring required.F i n a l A r c h i t e c t u r e . F i g u r e 5 s h o w s t h e A r c hJ a va c o d e t h atexpr esses the a r c hi tec tur e o f Ap hyds . Co mpa r ed to thedevelo per ' s c o nc eptua l a r c h i tec tur e , o ur f i na l Ar c hJavaa r c hi tec ture desc r i bes a lmo s t i dent i c a l c o m mu ni c a t i o n pa t ter nsw i th i n the c i r c u i t da ta ba se a nd b etw een the user i n ter f a c e a nd thed a ta b as e . T h e m u l t i - w a y c o m m u n i c a t i o n b e t w e e n w i n d o w s t h atw a s mi s s i n g f r o m the o r i g i na l a rc h itectur e bu t w a s pr esent i n thep ro gr am h a s b e e n c o n s o l id a t e d in t o t h e w i n d o w p or t o f A p h y d s .

1 94


9/11

Figure 6 shows a visualization of the current Aphyds architecture,generated automatically from the ArchJava code. The developerof Aphyds examined an earlier version of this diagram, and saidthat it captures his conceptual architecture well, including theseparation between the user interface and the circuit database.The ArchJava architecture has a number of advantages comparedto the original, conceptual architecture. ArchJava architecturesare guaranteed to be complete, listing all method callcommunication between components. The ArchJava architectureis guaranteed to stay up-to-date as the code evolves with changingrequirements, and a visualization can be generated automatically.Finally, it is easy to zoom in on an ArchJava architecture to lookat the interior structure of a component, determine what methodsare in each port, or examine how the methods are implemented.A l t e r n a t i v e A r c h i t e ct u r a l Choices. In our study, we tried toimplement the deve loper 's conceptual architecture as directly aspossible in ArchJava. However, an architect could haveexpressed any of several alternative Aphyds architectures usingArchJava. For example, we could have factored the architectureby functionality, combining each user interface window with thelogic that computes the information the window displays.Alternatively, we could have followed the original source codemore closely, creat ing and connect ing the model elements ondemand as circuits and windows are opened. ArchJava is flexibleenough to express these architectures, if the software architectdeems them more appropriate.4 .3 . S o f t w a r e E v o l u t i o n i n A r c h J a v aIn order to gain insight into using Arch Java for software evolutiontasks, we examined three concrete problems identified by thedeveloper: understanding communication within the program,refactodng the program to clean up its architecture, and fixingdefects related to display updates.Prog ram Understa nding. When we asked the developer if therewere any problems with the current structure of Aphyds, he saidthat communication between the main structures was awkward,especially with respect to change propagation messages. He saidthat tiffs problem makes it difficult to add new features to thesystem. This problem had a number of sources: the user interfacewas partly automatically generated, the developer was new to Javawhen he started to write the program, and the program grewgradually over time as features were added.Our experience while reengineefing Aphyds corroborated thedeveloper' s assertions. Using ad-hoc methods to manual ly tracemethod executions was ineffective, because different methodswith similar names often did different things, and each methodtypical ly depended on the operation of several others. In theoriginal program, the communication patterns were obscureenough that it was hard to analyze and criticize them.After we initially converted Aphyds to ArchJava, it became clearthat the p rogram's communication structure remained inconsistentand unnecessarily complex. Some of these problems had beenintroduced while refactonng Aphyds to express the architecture,while some were left over from the original source code.However, i n the modified program, the port descriptions madecommunication patterns explicit, and so the communicat ionproblems became obvious simply by looking at the methodsdefined in the ports.

Hypo thesis 6: Expressing software architecture in Ar chJ a v ahighlights refactoring opportunit ies by making communicationprotocols explicit.We decided to systematically analyze the communication patternsto find opportunities for refactoring. For each category ofmessages, we examined the source code to ident ify the messages'purpose, tile message implementers , the message invokers, and theinvocation trigger conditions.ArchJava's language constructs and its guarantee ofcommunication integrity eased this communication analysis.Simply scanning the required and provided methods in each portshowed which methods are invoked by and which areimplemented by each component. Ports also narrowed our focusto the subset of a component' s methods that are involved in inter-component communication. The name of a port also gave a clueabout the purpose of the port's methods. Connections showedwhich other component instances might implement a givencompone nt's required methods.Automated tools could have gathered some of this connectivi tyinformation from the original Java program. However, these toolswould require sophisticated alias analysis to support the level ofreasoning about component instances that is provided byArchJava's communication integrity. Furthermore, ArchJavamakes this connectivity explicit at the source code level, and anarchitect can use ports and connect ions to express design intent ina way that tools cannot duplicate.Hypothesis 7: Using separate ports and connections todist inguish di f ferent protocols and describing protocols withsepara te prov ided and requ ired por t in terfaces may ease programunderstanding tasks.R e f a c t o r i n g A r c h i t e c t u r a l C o m m u n i c a t i o n . Thecommunication analysis yielded a number of refactoringopportunities. For example, the window refresh logic had beenidentified by the developer as troublesome in the originalapplication. We found that there were several different refreshmethods, each of which affected a subset of the windows. Werefactored these into one refresh method that accepted a list ofwindows to refresh, and modi fied the method call sites to refreshonly the windows affected by the surrounding code.We found another refactoring opportunity in the data invalidationcode. When a new circuit is loaded into the program, datacomputed about the old circuit must be invalidated. Originally,this was done from many different places in the user interfacecode, using different message protocols. First, we refactored theinvalidation methods to give them consistent names andsemantics, and then we simplified the user interface code bymoving the invalidation logic from the user interface into themodel.After this refactoring step, communication in Aphyds wasconsiderably easier to understand. Refactoring eliminated anumber of methods and even entire categories of communication.The communicat ion categories in the user interface that remainedafter refactoring include menu update, window refresh, andopen~close/show window messages. Between the user interfaceand the model, our communication categories were user interfacecallback, command, data query, data update, and validi ty checkmessages.

195


10/11

We could have refactored the program to make these messagecategories explicit by defining separate ports and connections foreach category. In the end, we chose not to do this because theuser's conceptual architecture divided up communicationaccording to the computational task, rather than the type ofmessage.Architectural Refactoring during Translation. Whilereengineedng Aphyds to express the deve loper 's architecture, wefound that ArchJava's communication integrity rules forced us torefactor problematic code. For example, classChannelRouteDialog enabled a menu item as follows:g e t D i s p l a y e r ( . e t V i e w e r (

h a n n e l R o u t e r M e n u I t e m . s e t E n a b l e d ( b ) ;This code traverses a series of object links before calling a methodon the final object. It violates a design principle known as theLaw of Demeter [LH89], which states, "objects should onl y talkto their immediate neighbors in a system." Code like this makes aprogram fragile, because this line may break if any object in thesequence of links is changed.In ArchJava, this code violates communication integrity, becauseit makes a method call across architectural boundaries. Therefore,during our reengineering, we were forced to refactor this code tocall a required method on a local port, which was connectedthrough the architecture to the code that enables the menu item.Hypothesis 8: Communication integrity in ArchJava encourageslocal communication and helps to reduce coupling betweencomponents.Fix ing Defects. Aphyds' developer said that there were subtledefects in the window update code. To investigate how ArchJavaaffects the defect-fixing process, we identif ied and removed adefect that was present both in the original Aphyds code and inthe ArchJava version. The defect occurred whenever the userchanged the location of one element in a routed circuit. Theprogram did not re-compute the routing data, and so the routingdisplay was left in an inconsistent state.This was a relatively trivial defect, and the solution was the samein both versions: we added a call to the doGlobalRoutingfunction from the code that moved the circuit element. Werepaired the defect in the ArchJava version firs t The repairinvolved adding a ro u t er port to the component that moves thecircuit element, calling do Gl ob al Ro ut in g on that port, andconnecting the port to the model i n the architecture.Fixing the bug in the original Java version was conceptuallysimpler, since we di dn't have to create or link up the extra port.To our surprise, however, the operation actually turned out to bemore complex and took longer, because it was difficult to figureout how to get a reference to the Gl ob al Ro u t er object. Thefollowing code shows the complex chain of objects we had totraverse to fix this bug:g e t D i s p l a y e r ( . l a c e r o u t e d i a l o g l . p l a c e R o u t e D i s p l a ye r l . g e t C i r c u i t G l o b a l R o u t e r ( . o G l o b a l R o u t i n g ( ;This defect-fixing example is extremely simple and may notgeneralize to more complex defects. The comparison above isconfounded by many factors, including the order i n which thedefects were repaired, the confusing user interface source code inthe original program, and our familiarity with the two versions ofthe source code. However, it illustrates the potential of software

architecture to ease software evolution tasks by making structuremore explicit.Hypothesis 9: An explicit software architecture makes it easier toidentify and evolve the components involved in a change.4 . 4. E f f e c t o n t h e A r c h J a v a L a n g u a g eWhile reeng ineering the Aphyds architecture, we discovered amajor shortcoming in the ArchJava language design. To preservea strong notion o f communication integrity, Arch.lava's designassumes that control flow originates in components. Componentscan invoke the methods of objects, but since objects cannot storereferences to components in their instance fields, they can onlyinvoke methods on components that are passed as arguments tothe current ly executing method. This creates a signi ficantproblem for framework libraries such as the swing library usedin Aphyds, because these libraries are not written usingcomponent classes, yet often they must invoke componentmethods. This made it impossible to express any meaningfularchitecture for Aphyds, since all of the applicati on's control flowis dri ven by the user interface.Initially, we decided to extend the language by allowing portdeclarations within objects, and permitting components to makeconnections between objects and their own subcomponents. Thishad the crucial advantage of allowing us to work incrementally,transforming one class at a time into a component class byconnecting its ports to ports of the surrounding objects. In ourreengineering process, we made the database classes intocomponent classes, and init ially left the user interface classes asthey were, adding ports for communication channels that led tothe database. However, the thorniest architectural problems inAphyds were in the user interface interactions, and since wedidn't make the user interface classes into components, ourarchitecture didn 't help with these problems at all.In order for ArchJava to aid our reasoning about communicationwithin the user interface, we decided to also allow componentclasses to extend regular classes and interfaces, so that legacylibraries could invoke the inherited methods of componentsthrough references to the appropriate superclass. The inher itedmethods of these components can then be invoked arbitrarilythrough their inherited interfaces, threatening comrnnnicationintegrity. However, the new methods introduced in thesecomponents can only be called through declared connections inthe architecture. These are the methods that express theapplication logic that we felt was essential to capture and reasonabout with software architecture. This solution allowed us toconvey the architecture of the user interface much moreeffectively, and was responsible for a disproportionate amount ofthe software engineering benefits we observed.To support these new language features, we designed three modesof operation for the ArchJava compiler. A strict mode prohibitsall of these extensions, and rigidly enforces communicationintegrity. This mode could be used with future ArchJava user-interface libraries, modeled after the architecture-centric userinterface paradigms explored by the C2 project [MOR+96]. Anevolution mode allows ports to be defined in regular classes,enabling an architecture specification to be added incrementally oa legacy code base such as Aphyds. Final ly, a legacy mode allowscomponent classes to inher it from ordinary classes and interfaces(with warnings that can be turned off). This mode also permits

196


11/11

i n n e r c l a s s e s w i t h i n c o m p o n e n t s , w h i c h a r e i m p o r t a n t f o r s m o o t hi n t e r o p e r a t io n w i t h t h e s w i n g l i b r a ry .O u r e x p e r i e n c e w i t h A p h y d s a l s o m o t i v a t e d t h e d e s i g n o fb r o a d c a s t m e t h o d s , a n d s u g g e s t e d o t h e r u s a b i l i t y i m p r o v e m e n t s .4.5. Case Study SummaryW e w e r e a b l e t o c a p t u r e t h e c o n c e p t u a l a r c h i t e c t u r e o f A p h y d se f f e c t i v e l y i n A r c h a v a w i t h a s m a l l a m o u n t o f e f f o r t r e l a t i v e t ot h e s i ze o f th e p r o g r a m . T h e l a n g u a g e m a d e t h e a r c h it e c t u r ee x p l i c i t , a n d e x p r e s s i n g c o m m u n i c a t i o n p r o t o c o l s t h r o u g h p o r t sh e l p e d t o c l e a n u p c o m m u n i c a t i o n in t h e p r o g r a m . T h e A r c h a v ac o m p i l e r h e l p e d u s i n t h e r e s t r u c t u r i n g t a s k b y e n f o r c i n gc o m m u n i c a t i o n i n t e g r i t y : i t w o u l d n ' t l e t u s f o r g e t a n yc o m m u n i c a t i o n b a c k d o o r s b e tw e e n c o m p o n e n t s .5 . C o n c l u s i o n a n d F u t u r e W o r kA r c h J a v a a l l o w s p r o g r a m m e r s t o e x p r e s s a r c h i t e c t u r a l s t r u c t u r ea n d t h e n s e a m l e s s l y f i l l i n t h e i m p l e m e n t a t i o n w i t h J a v a c o d e . A te v e r y s t a g e o f t h e s o f t w a r e l i f e c y c l e , A r c h a v a e n f o r c e sc o m m u n i c a t i o n i n t e g r i t y , e n s u r i n g t h a t t h e i m p l e m e n t a t i o nconform s to the spec i f ied a rch i tec tu re . A case s tudy sugges ts tha tA r c h J a v a c a n b e a p p l i e d t o m o d e r a t e s i z e d J a v a p r o g r a m s w i t hre la t ive ly l i t t le e f fo r t , resu l t ing in a p rogram s t ruc tu re tha t m o rec l o s e l y m a t c h e s t h e d e s i g n e r ' s c o n c e p t u a l a rc h i t e ct u r e . T h u s ,A r c h a v a h e l p s t o p r o m o t e e f f e c t i v e a r c h i t e ct u r e - b a s e d d es i g n ,i m p l e m e n t a t i o n , p r o g r a m u n d e r s t a n d i n g , a n d e v o l u t i o n .I n f u t u r e w o r k , w e i n t e n d t o g a t h e r e x p e r i e n c e f ro m o u t s i d e u s e r so f A r c hJ a v a , a n d p e r f o r m f u r t h e r c a s e s t u d i e s t o s e e i f t h el a n g u a g e c a n b e s u c c e s s f u l l y a p p l i e d t o p r o g r a m s l a r g e r t h a n1 0 0 ,0 0 0 l i n e s o f c o d e . W e w i l l a l s o i n v e s t i g a te e x te n d i n g t h el a n g u a g e d e s i g n t o e n a b l e m o r e a d v a n c e d a r c h i t e c t u r al r e a so n i n g ,i n c l u d i n g t e m p o r a l o r d e r i n g c o n s t r a i n t s o n c o m p o n e n t m e t h o di n v o c a t i o n s a n d c o n s t r a i n t s o n d a t a s h a r i n g b e t w e e n c o m p o n e n t s .6 . A c k n o w l e d g e m e n t sW e w o u l d l i k e to t h a n k V i b h a S a z a w a l , T o d d M i l l s t e i n , V a s s i l yL i t v i n o v , M a t t h a i P h i l i p o s e , a n d t h e a n o n y m o u s r e v i e w e r s f o rt h e i r c o m m e n t s a n d s u g g e s ti o n s . W e a l s o th a n k S c o t t H a u c k f o rh i s t i m e a n d th e A p h y d s p r o g r a m . T h i s w o r k w a s s u p p o r t e d i np a r t b y N S F g r a n t C C R - 9 9 7 0 9 8 6, N S F Y o u n g I n v e s t i g a t o r A w a r dC C R - 9 4 5 7 7 6, a n d g i f t s fr o m S u n M i c r o s y s t e m s a n d I B M .7 . R e f e r e n c e s[ A G 9 7 ] R o b e r t A l l e n a n d D a v i d G a r l a n . A F o r m a l B a s i s f o rA r c h i t e c t u r a l C o n n e c t i o n . A C M T r a n s a c t i o n s o n S o f t w a r e

Engine er ing and Metho dolog y , 6(3), Ju ly 1997 .[ A r c 0 2 ] J o n a th a n A l d r i c h , C r a ig C h a m b e r s , a n d D a v i d N o t k i n .Arch Java web s i te . h t tp : /]www .arch java .o rg /[ F B B + 9 9 ] M a r t i n F o w l e r , K e n t B e c k , J o h n B r a n t , W i l l i a m

O p d y k e , a n d D o n R o b e r t s . R e f a c t o n n g : I m p r o v i n g t h eD e s i g n o f E x i s t i n g C o d e . A d d i s o n - W e s l e y , 1 99 9.[FF98] M. F la t t and M. Fe l le isen . Uni ts : Cool m o dules fo r HOT

l a n g u a g e s . P r o c . P r o g r a m m i n g L a n g u a g e D e s i g n an dIm plem enta t ion , Montrea l , Canada , June 1998 .[ G S 9 3 ] D a v i d G a r la n a n d M a r y S h a w . A n I n t r o d u c t i o n t o

S o f t w a r e A r c h it e c t u r e. I n A d v a n c e s i n S o f t w a r e E n g i n e e r in ga n d K n o w l e d g e E n g i n e e r i n g , I ( A m b r i o l a V , T o r t o r a G ,E d s . ) W o r l d S c i e n t i f ic P u b l i s h i n g C o m p a n y , 1 9 93 .

[ L H 89 ] K a r l L i e b e r h e r r a n d I a n H o l l a n d . A s s u r i n g G o o d S t y l e f o rO b j e c t - O r i e n t e d P r o g ra m s . I E E E S o f t w a r e , S e p t 1 9 8 9.[ L V9 5 ] D a v i d C . L u c k h a m a n d J a m e s V e r a . A n E v e n t B a s e dA r c h i t e c t u r e D e f i n i ti o n L a n g u a g e . I E E E T r a n s. S o f t w a r e

Engineer ing 21(9) , Sep tem ber 1995 .[ M F H 0 1 ] S e a n M c D i r m i d , M a t t h e w F l a t t a n d W i l s o n C . H s i e h .J i a zz i : N e w - A g e C o m p o n e n t s f o r O l d - F a s h i o n e d J a va . P r o c .

O b j e c t O r i e n t e d P r o g r a m m i n g S y s t e m s , L a n g u a g e s, a n dA p p l i c a t i o n s , T a m p a , F L , O c t o b e r 2 0 0 1 .[ M K 9 6] J e f f M a g e e a n d J e f f K ra m e r . D y n a m i c S t r u c t u re i nS o f t w a r e A r c h i te c t u r e s . P r o c . F o u n d a t i o n s o f S o f t w a r eEngineer ing , San Franc isco , CA, October 1996 .[MNS01] Gai l C . Murphy , D av id Notk in , and Kevin J . Su l l ivan .S o f t w a r e R e f l e x i o n M o d e l s : B r i d g i n g t h e G a p B e t w e e n

D e s i g n a n d I m p l e m e n t a t i o n . I E E E T r a n s . S o f t w a r eEngine er ing , 27(4) , Apr i l 2001 .

[ M O R + 9 6] N e n a d M e d v i d o v i c , P e y m a n O r e i z y , J a s o n E .R o b b i n s , a n d R i c h a r d N . T a y l o r . U s in g O b j e c t - O r i e n t e dT y p i n g t o S u p p o r t A r c h i t e c t u r a l D e s i g n i n t h e C 2 S t y l e.P r o c . F o u n d a t i o n s o f S o f t w a r e E n g i n e e r i n g , S a n F r a n c i s c o ,CA, October 1996 .[ M Q R 9 5 ] M a r k M o f i c o n i , X i a o l e i Q i a n , a n d R o b e r t A .R i e m e n s c h n e i d e r . C o r r e c t A r c h i t e c t u r e R e f i n em e n t . I E E ETrans . So f tware Eng ineer ing , 21 (4) , Apr i l 1995.

[ M T 0 0] N e n a d M e d v i d o v i c a n d R i c h a r d N . T a y l o r . AC l a s s i f i c a ti o n a n d C o m p a r i s o n F r a m e w o r k f o r S o f t w a r eA r c h i t e c t u r e D e s c r i p t i o n L a n g u a g e s . I E E E T r a n s. S o f t w a r eEngine er ing , 26(1), January 2000 .

[ M W 9 9 ] K i m M e n s a n d R o e l W u y t s . D e c l a r a t i v e l y C o d i f y i n gS o f t w a r e A r c h i t e c t u r e s u s i n g V i r t u a l S o f t w a r eC l a s s i f ic a t i o n s . P r o c . T e c h n o l o g y o f O b j e c t - O r i e n t e dL a n g u a g e s a n d S y s t e m s E u r o p e , N a n c y , F r a n c e , J u n e 1 9 99 .[ P N 86 ] R u b e n P r i e t o - D i a z a n d J a m e s N e i g h b o r s . M o d u l e

I n t e r c o n n e c t io n L a n g u a g e s . J o u r n a l o f S y s t e m s a n d S o f t w a r e6(4), Ap ril 1986.[ P W 9 2 ] D e w a y n e E . P e r r y a n d A l e x a n d e r L . W o l f . F o u n d a t i o n sf o r t h e S t u d y o f S o f t w a r e A r c h i t e c t u re . P / C M S I G S O F TSof tware Engin eer ing Notes , 17 :40--52 , October 1992 .[ R N 0 0 ] D a v i d S . R o s e n b l u m a n d R e m a N a t a r a j a n . S u p p o r t i n gA r c h i t e c t u r a l C o n c e r n s i n C o m p o n e n t - I n t e r o p e r a b i l i t y

S tandards . IEE Proce ed ings -Sof tw are 147(6), 2000 .[ S C 0 0 ] J o ~ o C . S e c o a n d L u i s C a i r e s . A B a s i c M o d e l o f T y p e d

C o m p o n e n t s . P r o c . E u r o p e a n C o n f e r e n c e o n O b j e c t-O r i e n t e d P r o g r a m m i n g , C a n n e s , F r a n c e 2 0 0 0 .[ S D K + 9 5] M a r y S h a w , R o b D e L i n e , D a n i e l V. K l e i n , T h e o d o r eL . R o s s , D a v i d M . Y o u n g , a n d G r e g o r y Z e l e s n ik .

A b s t r a c t i o n s fo r S o f t w a r e A r c h i t e c t u r e a n d T o o l s t o S u p p o r tThem . IE EE Trans . So f tware Engineer ing , 21(4), Apr i l 1995 .[ S r e0 2 ] V u g r a n a m C . S r e e d h a r. M i x i n ' U p C o m p o n e n t s . P r o c .I n t e r n a t io n a l C o n f e r e n c e o n S o f t w a r e E n g i n e e r i n g , O r l a n d o ,F L , M a y 2 0 0 2 .[ S S W 9 6 ] R o b e r t W . S c h w a n k e , V e r o n i k a A . S t ra c k , a n d T h o m a sW e r t h m a n n - A u z i n g e r . I n d u s t r i a l s o f t w a r e a r c h i t e ct u r e w i t hG e s t al t . P r o c . I n t e r n a ti o n a l W o r k s h o p o n S o f t w a r eSpec i f ic a t ion and Des ign , Paderbo rn , Germ any , March 1996.

19 7

Documents

ArchJava - Connecting Software Architecture to Implementation, By J. Aldrich, C. Chambers and D. Notkin