STRATEGIC VERSUS TACTICAL DESIGN
Amnon H. Eden Department of Computer Science, University of Essex, United Kingdom and Center For Inquiry International, Amherst, NY
Abstract. We seek to distinguish Strategic design deci- For the most part, tactical design aims to overcome short- sions (e.g., to adopt a programming paradigm, architec- comings of the programming language, paradigm or the tural style, CBSE standard or application framework) operating environment. Tactical statements include lower- from tactical design decisions (e.g. to use a design pat- level abstractions, such as design patterns, refactorings tern, refactoring or programming idiom). This distinction and programming idioms, and they are often described in is important since strategic statements carry far-reaching terms of specific mechanisms of the programming lan- implications over the implementation and therefore must guage, such as specific objects and procedures. be made early in the development process, whereas tacti- cal statements have localized effect and must be deferred Architectural vs. detailed design to a latter stage in the process. The distinction between strategic vs. tactical may bene- We formulate the Locality criterion, a well-defined fit from examining definitions of software architecture. and language-independent criterion which divides all Kazman states that “Architecture, or architectural design, design statements in two abstraction classes. We apply is design at a higher level of abstraction.” [ 16] Perry and our criterion to a broad range of statements and demon- Wolf write in the seminal paper on the foundations for strate that strategic statements are non-local and that software architecture: “Architecture is concerned with the tactical design statements are local. We also demonstrate selection of architectural elements, their interaction, and that assumptions leading to architectural mismatch are the constraints on those elements and their interactions… non-local. Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and 1 Introduction procedures, and the data types needed to support the ar- chitecture and to satisfy the requirements.” [ 19] Thus, it Strategic design decisions determine the primary be- may be argued that the distinction between strategic vs. havioural and structural properties of the system under tactical corresponds to the distinction made between ar- development. Strategic decisions include the choice of chitectural vs. detailed design. programming paradigm, architectural style, application While the concept of architectural design is generally framework, component-based software engineering understood, there is however no common agreement on its (CBSE) standard and global design principles, depending precise boundaries. Compare for instance the Publisher- on the application domain. Strategic design decisions ad- Subscriber [ 1] architectural pattern with the Observer dress general, system-wide concerns and set up the con- design pattern [ 10]: Although both patterns evidently de- text to the entire implementation. Implementations rarely scribe the same class of implementations, the first was conform to more than one strategic statement and attempt- classified as “architectural pattern” while the other as a ing to combine components that assume different design “design pattern”. strategies may result in architectural mismatch [ 11]. Be- In [ 7] we present the Locality criterion (revised in [ 6]), cause they carry the most consequential implications, stra- which divides design statements into two abstraction tegic decisions must be considered early in the develop- classes: local statements (designated [ ) vs. non-local ment process and established explicitly before any other statements (designated ] [ ). In [ 6] we also formulate the design decisions are made. Intension/Locality Hypothesis which, inter alia, argues In contrast, tactical design decisions have limited (“lo- the following: cal”) effect on the software under development and there- ♦ Architectural statements are non-local fore can (and should) be taken much later in the process. ♦ Design statements are local Overview But the results we provide also have practical implica- tions: The Locality criterion distinguishes between the In this paper, we expand the Intension/Locality Hy- subjects of the Architecture vs. the Design documents, pothesis in favour of a broader claim: We argue that the which most large software development projects require. Locality criterion, defined and illustrated in Section 2 Our analysis leads to the conclusion that architectural below, distinguishes between any strategic design deci- mismatch (Section 4 ) can be minimized if we observe that sion from any tactical design decisions. interoperability is predicated upon the consistency be- To demonstrate this argument, we examine in Section tween non-local assumptions made by the components we 3 a broad range of design statements and demonstrate that attempt to combine. In Figure 10 we detail how the Local- strategic statements are in ] [ and that tactical state- ity criterion contributes to the understanding of three of ments are in [ . the “four necessary aspects of a long-term solution” to the We also argue that the locality criterion can aid us in problem of architectural mismatch. the understanding the reasons for architectural mismatch. Architectural mismatch [ 11] has been defined as the class of interoperability problems arising from conflicting as- 2 Abstraction classes sumptions a component makes about the structure and behaviour of the application in which it is intended to In [ 6] we establish a common reference ontology operate. We argue that the class of assumptions leading to which allows us to compare statements about the software architectural mismatch is a subclass of ] [ . In Section 4 , design in formal, semi-formal and informal languages, we examine the causes of architectural mismatch and specified either in a textual or in a visual form. Stated in demonstrate that these are non-local statements. simple terms of entities and relations, this vocabulary will In Section 5 we summarize the arguments presented in allow us to examine a range of strategic and tactical de- this article and draw conclusions therefrom. sign statements and to determine their abstraction class. In this section, we recap on this vocabulary, define the local- Intended contributions ity criterion and illustrate its application. In lack of space, we omit the formal definitions, most of which can be Our theory has both conceptual and practical implica- found in [ 6]. tions. First and foremost, we see significant interest in providing a well-organized structure to software design, one which is not unlike complexity classes in computa- 2.1 Im plem entations and their tional complexity. We are unaware of any other rigorous sem antics framework that provides a similarly uniform, panoramic Which notion of program semantics best suits our dis- view on design statements, and believe that the distinction cussion? Eden and Hirshfeld [ 5] provide abstract seman- between L and NL is a first step in this direction. This tics for programs in the form of first-order, finite struc- distinction is designed to capture the intuitive notion of tures in mathematical logic [ 1]. By this approach, each non-locality using a coherent, concise and well-defined implementation is implicitly accompanied by a mathe- criterion. matical structure that consists of a universe of entities We provide a common reference ontology for the dis- (such as `i^pp or `ljmlkbkq) and relations (such as cussion in abstraction classes of design statements. Since Fkebofq or FkJlarib). A straightforward representation the Locality criterion is a semantic rather than syntactic to the vocabulary of entities and relation can be formu- criterion, we can apply it to a broad range of design state- lated using the notion of a structure. Formally, we define ments articulated in variety formal, semi-formal and in- as a finite collection of (ground) entities formal, textual and visual languages, including (but not design model and (ground) relations between the entities. Figure 2 illus- restricted to) first- and high-order predicate calculus (PC), trates a design model, ~KfiÄ, which represents the ab- context-free languages, Z [ 4] and LePUS. This allows us stract semantic of the C++ program in Figure 1. to compare a broad spectrum of phenomena which other- A design model can also be viewed as a relational da- wise may seem incommensurable. In this sense, our theory tabase, consisting of a tabular representation for each rela- departs from existing literature. tion. By this metaphor, ~KfiÄ can be viewed as a minia- Finally, the Locality criterion explains why tools sup- ture database with three tables: The table @i^pp has one porting non-local design statements must examine the column with the entries Object, Nil1 and Nil2. The entire implementation. For example, compilers enforcing two-column tables Fkebofq and Jbj_bop have one entry Information Hiding (Statement (3)) must inspect the entire each, &Nil1)Object'. implementation to ensure that private members are not accessed by any part of the implementation. class Object { /* ... */ }; Informally, a statement is local if and only if, once it is satisfied by some part of the program, it cannot be vio- class Nil1: public Object { lated by "expanding" the program. vector
The Locality criterion originally appeared in [7]. The 2 Let m- designate the C++ program that includes the criterion was revised in [ 6]. The difference between the classes Nil1 and Object (excluding class Nil2) and versions is very subtle and does not affect our discussion. the relation Fkebofq. Clearly, m- satisfies Statement Below, we give the revised version and refer to it simply (1). as the Locality criterion: 3 Let m designate the C++ program that results from add-
ing class Nil2 to m-. Clearly, m is an expansion to m-, The Locality Criterion. A statement h is local if and but m does not satisfy Statement (1). only if it is preserved under expansion. A more formal proof is detailed in [ 6]. [ We designate the class of local design statements , Exam ple: local statem ent non-local design statements ] [ . We term each class of statements as abstraction class. (1) The “intent” of the Recursive Composite design pat- tern [ 10] is to “Compose[s] objects into tree structures to represent part-whole hierarchies”. Essentially, the tech- (1) The term “class” in this context is taken from Zermelo- nique described involves two “participants”: Fraenkel’s set-theoretic vocabulary, designating an extension of a property. We also discuss object-oriented and class-based programming languages, in which context the term “class” re- fers to the grammatical construct which defines the structure and behaviour of instances (also objects). These notions of “class” must not be confused. (2) NIHCL: A class library for C++ from the US National Insti- tutes of Health (NIH). ♦ An abstract `ljmlkbkq class, which declares the in- their form. In a confusing reality of multiple notations, we terface for objects in the composition and for accessing hope that a semantic criterion is more informative than and managing its child components; syntactic characterizations. The bewildering variety of ♦ A concrete `ljmlpfqb class, which stores “children” notations and languages of the examples given in Section objects and defines behaviour related to managing chil- 3 were deliberately chosen to demonstrate this quality. dren. We use mathematical logic to ensure that the argu- ments we make are valid and to promote accuracy and Below, we formulate this description in the PC: clarity. In this paper, we avoided unnecessarily obfuscated „ @i^pp&`ljmlkbkq'∞ %/& or elaborate discussion and adhere to the informal argu- @i^pp&`ljmlpfqb'∞ mentation. Rigorous arguments and complete proofs can be found in [ 6]. Fkebofq&`ljmlpfqb)`ljmlkbkq'∞ More importantly, “proving” our hypothesis is a daunt- Jbj_bop&`ljmlpfqb)`ljmlkbkq'„ ing task: The technical specifications of programming Statement (2) is local. Let us sketch an informal argu- paradigms, application frameworks and CBSE standards ment to this claim in the context of the C++ programming are much more elaborate than the simplified formulas we language: quote and therefore rarely lend themselves to set-theoretic analysis. Also, the terms strategic and tactical are not 1 The universe of discourse consists of (object-oriented) rigorously defined, and neither is almost any of the tech- class definitions in the C++ programming language and nical terms we analyze (such as architectural style and the inheritance relations between them. design pattern). Consequently, our hypothesis cannot be 2 Let m- be the C++ program illustrated in Figure 1. To “proved” but merely corroborated (or contradicted) em- show that m- satisfies Statement (2), replace the free pirically. But most difficult is to justify the inductive leap variable `ljmlkbkq with the entity Object, and the we attempt to perform: What right do we have to general- variable `ljmlpfqb with the entity Nil1. ize a finite set of corroborating evidence into a sweeping 3 Clearly, this assignment remains true in any expansion hypothesis? to m-. Hence, Statement (2) is preserved under expan- The credence of every scientific thesis is predicated sion. upon fine-combing the class of phenomena it is concerned Although the argument given above is made for C++ with. But the subject matter of our hypothesis, the class of implementations of the Recursive Composite, note that a design statements and their interpretations, is very broad, similar argument can be made about implementations in intricate and largely undefined. It cannot be covered in other programming languages any one paper. Instead, we demonstrate how to determine the abstraction class of any design statement that can be 2.3 Caveat expressed in the vocabulary we define. We hope that this vocabulary is sufficiently general and that the insight it The application of mathematical logic and model the- provides is sufficiently useful to merit further interest. ory to statements about software design raises several problems. First, most design statements are specified in- 2.4 Discussion formally, and therefore the vocabulary we require (spe- cifically, the language of structures and expansions) is not Can we express the Locality criterion syntactically? An rigidly defined. We partially overcome this problem by alternative to the semantic approach we presented could “borrowing” the formulations of design statements when- operate within the confines of one specification language, ever such formulations appeared in literature. When for- thereby allowing the formulation of the criterion by syn- mal definitions could not be found, informal statements in tactic terms. Turner [ 24], for example, describes a core natural language were formulated using the classical PC. theory of specifications which is comprehensive enough to But as we also demonstrate in [ 6], the Locality criterion express all the statements that we are interested in. This can be equally applied to informal statements, as long as it rich formal theory will eventually shed light on the practi- has a definite meaning within the vocabulary defined. cal use of specification languages in discussing programs, The next problem we faced was that even the sporadic including Z, VDM and LePUS. In particular, his ap- formulations of design statements were made in a plethora proach rigorously represents the features of the languages of specification languages. How can we compare state- used in dealing with programs and provides means for ments made in Z with statements in a context-free lan- investigating the logical implications of these features. guage? We overcome this problem by phrasing a criterion This approach, however, remains to be examined. that is based on the meaning of statements rather than on 3 Case studies tempting to compile the combined program will lead to a compilation error. This demonstrates why tools that en- In this section, we examine a range of design state- force non-local rules must examine the entire implementa- ments and demonstrate that strategic statements are non- tion. In this example, the compiler must ensure that the local and that tactical statements are local. access privileges are respected by all parts of the program. This result also demonstrates the actual implications of 3.1 Strategic design non-locality.
Program m ing paradigm s Global design principles The choice of a programming paradigm can easily be Design principles are “global” design decisions that recognized as strategic: It determines the principal ab- potentially affect every module of the program. For ex- stractions underlying the implementation (e.g., objects, ample, the design principle of a Universal Base Class procedures, or functions) and the primary mechanisms (Statement (1)), can reflect a design decision made in a that the programming language offers to support them. particular context, for example, in stating that the inheri- The definition of a programming paradigm goes be- tance tree of the NIHCL C++ class library has a single yond the scope of this paper. Consider for example the root. This principle is clearly strategic since it implies that principle of Information Hiding, which is supported by all objects (also instances) will exhibit the set of proper- access restrictions in modular and in object-oriented pro- ties defined in the root class. gramming. In the C++, Java™ and Eiffel programming Universal Base Class also describes the structure of languages, the principle is supported by a mechanism any program in some programming language. For exam- which renders a ‘private’ member accessible only to a ple, any class declaration written in Java™, Smalltalk or privileged part of the program and inaccessible to the rest. Eiffel inherits (by definition) from class Object. In Sec- This rule can be formulated in the PC as follows: tion 2 .2 we showed that Universal Base class is non-local. `)j)u„í %0& Architectural styles Jbj_bo&j)`'∞Mofs^qb&j'∞>``bpp&u)j'ÿ Architectural styles [ 19][ 12] (also architectural pat- Mr_if`&j'±Jbj_bo&u)j'±Cofbka&u)j'„ terns [ 22]) have emerged as common means for specifying To demonstrate that Statement (3) is non-local, we the design principles underlying the global organization of show a program that satisfies it, illustrated in Figure 3, complex systems. Architectural styles are concerned with and then expand this program into one that violates the inter-process communication protocols, physical distribu- statement, such as by adding the class Intruder illus- tion of modules and components, calling conventions, trated in Figure 4. security concerns, global control structures and perform- Since the C++ compiler enforces Statement (3), at- ance goals. Clearly, architectural styles are design state- ments at the highest level of abstraction and characteristi- cally strategic. template
Stack
♦ FkJlarib&mk(.*jh(.' Figure 6. EJB statements (adapted from [ 17]). ♦ FkJlarib&mk(/*jh(/' ♦ Fkslhb&mk(.*mk(/' Application fram eworks This would constitute a proper expansion because it J Johnson describes an application framework as “a re- does not modify any existing module or procedure in ff. Clearly, the expanded structure violates the constraints usable, ‘semi-complete’ application that can be special- imposed by the style. Thus, Implicit Invocation is not pre- ized to produce custom applications.” Application frame- served under expansion. QED work usually provide substantial parts of the overall ap- Consider also the Layered Architecture style. Garlan plication – most often extensive resources and the infra- and Shaw [ 12] state that “A layered system is organized structure for the implementation. The choice of frame- hierarchically, each layer providing service to the layer work usually affects the control structure (i.e., due to the above it and serving as a client to the layer below.” In [ 7] principle of inverted control), the choice of programming we prove that a formulation of this statement in the PC is language, and most often the gross organization of the non-local. application. We conclude that the choice to use an appli- Finally, consider the Pipes and Filters architectural cation framework is clearly a strategic design decision. style, described in [ 12] as follows: “In a pipes and filters For example, Microsoft Foundation Classes (MFC) style each component has a set of inputs and a set of out- is an application framework that supports the use of puts. A component reads streams of data on its inputs and graphical user interface in Windows environments. Figure produces streams of data on its outputs.” As we prove in 7 depicts the interaction protocol between Microsoft [ 7] with regard to a formulation of this statement in a vis- Foundation Classes and user-defined classes. In [ 6] we ual, context-free language, it is non-local. prove that this description is non-local.
Com ponent-based software engineering If users subclass CWnd, in all the subclasses, there must be at least one public method which directly or indirectly calls one of CBSE industrial standards determine components in- the three methods CWnd::Create, CWnd::CreateEx1, or teraction, integration, customization, calling and usage CWnd::CreateEx2. Furthermore, outside the subclasses, conventions [ 23]. Depending on the standard, CBSE con- there must be the invocation of at least one of the methods. ventions allow the interoperability of binaries across process, machine, operating system and programming Figure 7. MFC interaction protocol (adapted from [ 13]). language boundaries. Each CBSE standard sets up the context to all the components in the implementation. Evi- dently, the choice of a CBSE standard is a strategic design 3.2 Tactical design decision. Each CBSE standard consists of a complex constella- Design patterns tion of constraints. An detailed discussion in the technical In parallel with the emergence of architectural styles, specifications of any CBSE standards is beyond the scope design patterns were introduced as a vocabulary capturing of this paper. Instead, we discuss segments from the de- best practices in software design. The seminal “Gang of scription of two of these standards. Four” catalogue [ 10] defines design patterns as “descrip- Microsoft’s Component Object Model (COM) re- tions of communicating objects and classes that are cus- quires each component to implement the interface tomized to solve a general design problem in a particular IUnknown. This statement is a slight variation on a spe- context”. Unlike specifications of architectural styles, cial case of Universal Base Class (Statement (1)), which is individual objects and minute implementation detail are non-local by the same proof given in Section 2 .2. common elements in specifications of design patterns. For Consider also the description of a “bean” class in En- this reason, Monroe et. al argue that design patterns “have terprise JavaBeans™ depicted in Figure 6. In [ 6] we applicability at lower levels of design” [ 18] compared to LePUS formulate this statement in and prove that it is architectural styles. Similarly, Coplien refers in the same non-local. issue of IEEE Software to the solutions that design pat- terns specify as “microarchitectures”, echoing the view Y@I>PPZ„ %1&„ that design patterns manifest design decisions of lower XJBQELAZ„ abstraction level than architectural styles. In conclusion, XPFDK>QROBZ„ the decision to adopt a design pattern is tactical. In Section 2 .2 we showed that a formulation of the >KV„7„@I>PP„°JBQELA„ Publisher-Subscriber [ 20] (called Observer in [ 10]) de- Jbj_bo„7„>KV„à@I>PP„ sign pattern is local. Below, we demonstrate the same with Fkslhb„„7„JBQELA„àJBQELA„ regard to two other design patterns. ù7„PFDK>QROBè@I>PP„ JBQELA The Factory Method design pattern [ 10] describes ´ „ three kinds of higher-order entities (“participants” in the Strategy catalogue’s terminology), which can be represented as higher-order variables as follows: `lkqbuq)„pqo^qbdv„7„@I>PP„ „ @lk`obqbPqo^qbdfbp„7„:„@I>PP„ 1. A set of “product” classes, Molar`qp„ 2. A set of “factory” classes, C^`qlofbp„ ^idlofqej„7„PFD„ 3. A set of “factory” methods, C^`qlov*Jbqelap @lkqbuqFkqboc^`b„7„:„PFDK>QROB„ The pattern also specifies the relations among these en- &`lkqbuq)pqo^qbdv'ßJbj_bo„ tities (“collaborations”) as follows: „ `ß@lk`obqbPqo^qbdfbp„í 4. The set C^`qlov*Jbqelap has the following proper- &`)pqo^qbdv'ßFkebofq) „ ties: `ß@lk`obqbPqo^qbdfbp„í a. All the methods jßC^`qlov*Jbqelap are of the same “type”. "pß@lkqbuqFkqboc^`b„í b. Each factory method jßC^`qlov*Jbqelap is de- &^idlofqejù`)pù@lkqbuq'ßFkslhb„ fined in a different class in cßC^`qlofbp. c. Each factory method jßC^`qlov*Jbqelap is re- More generally, it is easy to see why design patterns sponsible for “producing” instances from exactly are local. Each design pattern can be specified as a state- one class mßMolar`qp. More precisely, we say that ment that assigns roles to bounded collections of ‘partici- the relation Molar`bp is a bijection relation be- pants (classes, objects and/or methods). Thus, any expan- tween the sets C^`qlov*Jbqelap and Molar`qp. sion to an implementation that satisfies the specification In [ 7] we prove that a formulation of the factory incorporates the same a collection of participants that also method in LePUS is local. This proof demonstrates that satisfies the same statement. once a collection of factories, factory methods and prod- ucts that satisfies the statement is present in an implemen- Program m ing idiom s tation, it will also be present in any expansion thereof. Bushcmann et. al describe programming idioms as The intent of the Strategy design pattern [ 10] is to “low-level patterns” [ 2]. Programming idioms usually “define a family of algorithms, encapsulate each one, and specify a technique for overcoming a particular shortcom- make them interchangeable.” [ 12] The design pattern de- ing of implementation language, most often a mechanism scribes a collection of “concrete strategy” classes and a that is directly supported by some other programming family of “algorithm” methods defined therein. The inter- language. Therefore we conclude that the decision to use a face of a “context” class provides the algorithms with the programming idiom is tactical. necessary data. We may formulate the Strategy design The Counted Pointer idiom [ 2] (originally termed pattern using the Z schema depicted in Statement (4). Reference Counting by Stroustrup), summarized in Figure Note that, unlike in classical interpretation for Z schemas, 8, describes a technique designed to overcome the ab- Statement (4) should be interpreted as an existential for- sence of a “garbage collection” in C++. In [ 6] we prove mula on the variables `lkqbuq, pqo^qbdv, that this statement is local. @lk`obqbPqo^qbdfbp, ^idlofqej and @lkqbuq* Fkqboc^`b. In [ 6] we prove that Statement (4) is local. Essentially, we show that once a collection of strategies and algo- rithms is present in an implementation, it will also be pre- sent in any expansion thereof. 1. The constructors and destructors of the Body class should be 3.3 The Singleton anom aly private. 2. The Handle class should be a “friend” of the Body class. In absence of a formal criterion, the distinction be- 3. The body class should have a reference counter. tween design patterns and architectural styles is open for 4. The Handle class should have a data member pointing to the interpretation. We argue that design patterns are tactical, Handle object. hence local, whereas architectural styles are strategic, 5. The Handle class’ copy constructor and assignment operator hence non-local. So far, we have only demonstrated lim- should increase the reference counter, and the destructor de- crease it. ited evidence to our hypothesis. Our investigation of the 6. The Handle class should implement the arrow operator. remaining patterns in the “Gang of Four” catalogue [ 10], 7. The Handle’s constructors must initialize the reference of design patterns in other collections [ 15][ 21] and of counter with the number 1. additional architectural styles [ 12], however, resulted in only one exception to our hypothesis: the Singleton pat- Figure 8. Counted Pointer programming idiom (adapted from). tern. The intent of the Singleton design pattern [ 10] is to Refactoring “Ensure a class only has one instance, and provide a global point of access to it.” This statement is obviously Fowler defines refactoring as the process of “changing non-local (see proof in [ 6]). a software system in such a way that it does not alter the There are two possible explanations to this anomaly: external behavior of the system.” [ 9] An indication that (1) that design patterns can be non-local, and our hypothe- the overall effect of refactoring is local is given in the sis is wrong; (2) that the Singleton should be considered catalogue: “[Refactorings]… take a bad design and re- an architectural pattern/style. work it into well-designed code. … Yet the cumulative When deciding which explanation applies, we ask: Is it effect of these small changes can radically affect the de- a strategic decision to adopt the Singleton pattern? In il- sign.” Each refactoring has a small-scale effect and there- lustrating the applicability of the Singleton pattern, fore the decision to apply one must be characterized as Gamma et. al describe resources (printer spooler, file sys- tactical. tem and window manager) that are central to the success- Fowler’s catalogue consists of a large number of refac- ful operation of the overall system. The pattern is used to toring. Some refactorings introduce a design pattern, such make these resources available to every element of the as Replace Type Code With Class (Strategy [ 10]), Re- implementation. The term “global” used in the pattern’s place Conditional With Polymorphism (State [ 10]) and definition suggests that the singleton instance is designed Replace Constructor with Factory Method (Factory to provide services to clients from the entire scope of the Method [ 10]). Other refactorings introduce a variable, a implementation. These evidence suggest that the decision method or a new class; it is trivial to show that the state- on using the Singleton pattern is indeed strategic. ment describing the effect of these changes is local. The same catalogue also describes 4 “big refactor- ings”. Below, we demonstrate that one of them is local. 4 Architectural m ism atch The proof for the other three refactorings will become obvious from this example. “Many would argue that future breakthroughs in soft- Tease Apart Inheritance [ 9] replaces one (“tangled”) ware productivity will depend on our ability to combine class hierarchy with another (“untangled”). In its general existing pieces of software to produce new applications”. form, the refactoring suggests that one set of classes is [ 11] Despite progress made since these words were writ- replaced by two sets of classes. Thus, a statement describ- ten (in particular progress made in CBSE technologies), ing this refactoring shall take the form of a well-formed component integration and reuse have remained the pana- cea of software engineering. formula in the PC, r&e.)e/)e0', where e.)e/„ and e0 are the only variables in the statement ranging over sets of In their seminal paper on architectural mismatch [ 11], class and r describes their relations. To show that this Garlan et. al examine in detail the problems encountered statement is preserved under expansion, consider any im- during their attempt to construct a working system (“Ae- plementation m„ that satisfies it, including three sets of sop”) from existing modules (“components”), such as classes h1, h2 and h3 such that r&h1)h2)h3'. Clearly, excessive code size, poor performance and error-prone any expansion to m will incorporate the sets h1, h2 and h3 construction process. In the analysis of these problems, and will not affect their relations. Hence r&h1)h2)h3' the authors define architectural mismatch as the class of will remain true in any expansion of m and r is local. interoperability problems arising from conflicting assump- tions that modules make about the application in which 1. For example, the Softbench Broadcast Message Server ex- Definition: Architectural Mismatch. Let h designate a pected all of the components to have a graphical user inter- design statement assumed by component m. Let n desig- face …. nate an expansion of m. If ~mÄsatisfies h but ~nÄ does not 2. packages made assumptions … about the data that would be communicated over the connectors. … Softbench, on the then we say that m, n mismatch on h. other hand, assumes that … all data to be communicated … is represented as ASCII strings. [However,] the main kind of It is easy to prove that any assumption leading to ar- data manipulated by our tools was database and C++ object ] [ pointers. chitectural mismatch (in this formulation) is in . For- 3. OBST … assumed that all of the tools would be completely mally: independent of each other. This assumption meant that there would be no direct interactions between tools. Theorem. If m, n mismatch on h then h is in ] [ . 4. … the Mach Interface Generator assumed that the rest of the code was a flat collection of C procedures, and that its speci- fication described the signature of all of these procedures. The proof to this theorem follows immediately from the Locality criterion. Figure 9. Assumptions leading to architectural mismatch In Figure 10 we demonstrate how the Locality criterion (adapted from [ 11]). contributes to the understanding of three of the “four nec- essary aspects of a long-term solution” (to the problem of they are intended to operate. Clearly, the prevention of architectural mismatch). architectural mismatch is a strategic design concern. Garlan et. al describe the particulars of several of the assumptions leading to architectural mismatch. Figure 9 5 Conclusions gives a summary of some of these assumptions. The authors do not provide a formal definition to archi- We compared strategic with tactical design decisions tectural mismatch. Nonetheless, our examination of the and demonstrated that they can be distinguished using the assumptions leading to problems they describe (such as Locality criterion. Specifically, we demonstrated that se- the statements in Figure 9) lead us to the conclusion that lected examples of programming paradigms, architectural architectural mismatch may be defined in the language of styles, CBSE standards, design principles and application structures and expansions as follows: frameworks are non-local and that design patterns, refac- torings and programming idioms are local. From the examination of assumptions leading to archi- 1. “Make architectural assumptions Make non-local assump- tectural mismatch we conclude that they can be formu- explicit.” tions explicit. lated as non-local statements. We also demonstrated that components will become more portable if they minimize 2. “Construct large pieces of soft- Minimize the number of ware using orthogonal components. non-local assumptions. the number of non-local assumptions they make about the As Parnas has long argued [Par72], Ideally, each module applications in which they intend to operate. each module should hide certain should only make local design assumptions. Unfortunately, assumptions. Future directions the architectural design assumptions of most systems are spread through- Further analysis may refine the abstraction classes out the constituent modules. Ideally ] [ and [ (3). Also of interested would be the investi- one would like to be able to tinker gation of the abstraction class of metaprogramming state- with the architectural assumptions of a reused system by substituting dif- ments, that is, of statements in a programming language ferent modules for the ones already that operate over programs. there.” Another open question is whether the class of assump- tions leading to architectural mismatch is precisely ] [ . 4. “Develop sources of architectural Design rules for compo- Put differently, the question is whether, for a given non- design guidance. … We need to find sition: Whenever non- local design statement h, any implementation that satisfies ways codify and disseminate princi- local assumptions are ples and rules for composition of made, either ensure that h can be expanded to violate h. software.” they are compatible or Finally, it is of interest to explore a syntactic reformu- else relinquish the at- lation of the Locality criterion within the confines of a tempt to combine the specific specification language, as delineated in our dis- components. cussion in Section 2 .4. Figure 10. Solutions to architectural mismatch (left, adapted from [ 11]) rephrased using non-locality (right). (3) In [ 6] we refine [ using the Intension criterion. [16] R. Kazman. "A New Approach to Designing and Analyz- References ing Object-Oriented Software Architecture." Guest talk, [1] J. Barwise (ed.) Handbook of Mathematical Logic. Am- Conference On Object-Oriented Programming Systems, sterdam, The Netherlands: North-Holland Publishing Languages and Applications – OOPSLA, Denver, CO, Co., 1977. Nov. 1—5, 1999. [2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, [17] V. Matena, M. Hapner. Enterprise JavaBeans™ Specifi- M. Stal. Pattern-Oriented Software Architecture – A Sys- cation, v1.1, 1999. Palo Alto, CA: Sun Microsystems. tem of Patterns. New York, NY: Wiley and Sons, 1996. [18] R.T. Monroe, A. Kompanek, R. Melton, D. Garlan. “Ar- [3] J.O. Coplien. “Idioms and Patterns as Architectural Lit- chitectural Styles, Design Patterns, and Objects.” IEEE erature.” IEEE Software, Vol. 14, No. 1 (Jan. 1997), pp. Software, Vol. 14, No. 1 (Jan. 1997), pp. 43—52. 36—42. [19] D.E. Perry, A.L. Wolf. “Foundation for the Study of [4] J. Derrick, E. Boiten. Refinement in Z and Object-Z: Software Architecture.” ACM SIGSOFT Software Engi- Foundations and Advanced Applications. Berlin: neering Notes Vol. 17, No. 4 (Oct. 1992), pp. 40—52. Springer-Verlag, 2001. [20] W. Pree. Design Patterns for Object-Oriented Software [5] A.H. Eden, Y. Hirshfeld. "Principles in Formal Specifica- Development. New York, NY: ACM Press, 1995. tion of Object Oriented Architectures." Proceedings of [21] D. C. Schmidt, M. Stal, H. Rohnert, F. Buschmann. Pat- the 2001 conference of the Centre for Advanced Studies tern-Oriented Software Architecture: Patterns for Con- on Collaborative research – CASCON, Nov. 5—8, 2001, current and Networked Objects. Wiley & Sons, 2000. Toronto, Canada. [22] M. Shaw. “Some Patterns for Software Architectures.” In [6] A.H. Eden, R. Kazman, Y. Hirshfeld. “Abstraction Strata J. Vlissides, J.C. Coplien, N.L. Kerth (eds.) Pattern Lan- in Software Design.” Technical report CSM-411, De- guages of Program Design 2. Addison-Wesley, 1996. partment of Computer Science, University of Essex, June [23] C. Szyperski. Component Software: Beyond Object- 2004. Oriented Programming, 2nd Edition. Reading, MA: Ad- [7] A.H. Eden, R. Kazman. “Architecture, Design, Imple- dison-Wesley Professional. mentation.” Proceedings of the 23rd International Con- [24] R. Turner. “The Foundations of Specification I”. Techni- ference on Software Engineering — ICSE, May 3—10, cal report CSM-396, Department of Computer Science, 2003, Portland, OR. University of Essex, 2004. [8] M. Fayad, D.C. Schmidt. "Object-Oriented Application Frameworks". Guest editorial, Communications of the ACM, Vol. 40, No. 10 (Oct. 1997). [9] M. Fowler. Refactoring: Improving the Design of Exist- ing Code. Reading, MA: Addison-Wesley, 2003. [10] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object Oriented Soft- ware. Reading, MA: Addison-Wesley, 1994. [11] D. Garlan, R. Allen, J. Ockerbloom. “Architectural Mis- match or Why It’s Hard to Build Software From Existing Parts.” Proceedings of the Seventeenth International Conference on Software Engineering – ICSE’95, Seattle, WA, Apr. 1995. [12] D. Garlan, M. Shaw. "An Introduction to Software Archi- tecture." In V. Ambriola, G. Tortora, eds., Advances in Software Engineering and Knowledge Engineering 1993, Vol. 2, pp. 1—39. New Jersey: World Scientific Publish- ing Company. [13] D. Hou, H. J. Hoover. “Towards Specifying Constraints for Object-Oriented frameworks.” Proceedings of the 2001 conference of the Centre for Advanced Studies on Collaborative research – CASCON, Nov. 5—8, 2001, Toronto, Canada. [14] R. Johnson, B. Foote. “Designing Reusable Classes.” Journal of Object-Oriented Programming, Vol. 1, No. 5, Jun./Jul. 1988, pp. 22—35. [15] R. Johnson, B. Woolf. "Typed Object". In: R. Martin, D. Riehle, F. Buschmann (eds.) Pattern Languages of Pro- gram Design 3. Reading, MA: Addison-Wesley, 1997.