ACM SIGSOFT Engineering Notes vol 26 no 1 January 2001 Page 78

Workshop on Multi-Dimensional Separation of Concerns in

Peri Tarr, William Harrison, Harold Ossher (IBM T. I. Watson Research Center, USA) Anthony Finkelstein (University College London, UK) Bashar Nuseibeh (Imperial College, UK) Dewayne Perry (University of Texas at Austin, USA)

Workshop Web site: http://www.research.ibm.com/hyperspace/workshops/icse2000 ABSTRACT cem may promote some goals and activities, while impeding oth- Separation of concerns has been central to software engineering ers; thus, any criterion for decomposition will be appropriate fm for decades, yet its many advantages are still not fully realized. A some contexts, but not for all. Further, multiple kinds of concerns key reason is that traditional modularization mechanisms do not may be relevant simultaneously, and they may overlap and inter- allow simultaneous decomposition according to multiple kinds of act, as features and classes do. Thus, different concerns and (overlapping and interacting) concerns. This workshop was in- modularizations are needed for different purposes: sometimes by tended to bring together researchers working on more advanced class, sometimes by feature, sometimes by viewpoint, or aspect, moclularization mechanisms, and practitioners who have experi- role, variant, or other criterion. enced the need for them, as a step towards a common understand- These considerations imply that developers must be able to iden- ing of the issues, problems and research challenges. tify, encapsulate, modularize, and wanipulate multiple dimensions Keywords of concern simultaneously, and to introduce new concerns and Separation of concerns, decomposition, composition dimensions at any point during the software lifecycle, without suf- fering the effects of invasive modification and rearchitecture. Even 1 SEPARATION OF CONCERNS modern languages and methodologies, however, suffer from a Separation of concerns [ 17] is at the core of software engineering, problem we have termed the "tyranny of the dominant decomposi- and has been for decades. In its most general form, it refers to the tion" [18]: they permit the separation and encapsulation of only ability to identify, encapsulate, and manipulate only those parts of one kind of concern at a time. software that are relevant to a particular concept, goal, or purpose. Concerns are the primary motivation for organizing and decom- Software started out being represented on linear media, and despite posing software into manageable and comprehensible parts. advances in many fields, such as graphics and vi~laliT.~tiOIl, hy- pertext and other linked structures, and databases, it is still mostly Many different kinds, or dimensions, of concerns may be relevant treated as such. Progrants are typically linear sequences of char- to different developers in different roles, or at different stages of acters, and modnles are collections of contiguous characters. This the software lifecycle. For example, the prevalent kind of concern linear structure implies that a body of software can be decomposed in object-oriented programming is data or class; each concern in in only one way, just as a typical document is divided into sections this dimension is a data type defined and encapsulated by a class. and subsections in only one way. This one decomposition is domi- Features [19], like printing persistence, and display capabilities, nant, and often excludes any other form of decomposition. are also common concerns, as are non-functional concerns, like concurrency control and distribution, roles [1], viewpoints [13], Examples of tyrant decompositions are classes (in object-oriented variants, and configurations. Separation of concerns involves de- languages), functions (in functional languages), and roles (in rule- composition of software according to one or more dimensions of based systems). It is, therefore, impossible to encapsulate and ma- concerlL nipnlate, for example, features in the object-oriented paradigm, or objects in rule-based systems. Thus, it is impossible to obtain the "Clean" separation of concerns has been hypothesized to reduce benefits of different decomposition dimensions throughout the software cemplexity and improve comprehensibility; promote software lffecycle. Developers of an artifact are forced to commit traceability within and across artifacts and throughout the lifecy- to one, dominant dimension early in the development of that arti- cle; limit the impact of change, facilitating evolution and non- fact, and changing this decision can have catastrophic conse- invasive adaptation and customization; facilitate reuse; and sim- quences for the existing artifact. What is more, artifact languages plify component integration. often constrain the choice of dolnina~t dimension (e.g., it must be 2 THE TYRANNY OF THE DOMINANT class in object-oriented software), and different artifacts, such as DECOMPOSITION requirements and design documents, might therefore be forced to These goals, while laudable and important, have not yet been use different decompositions, obscuring the relationships between achieved in practice. This is because the set of relevant concerns them. varies over time and is context-sensitive--different development We believe that the tyranny of the dominant decomposition is the activities, stages of the software lffecycle, developers, and roles single most significant cause of the failure, to date, to achieve often involve concerns of dramatically different kinds. One con- many of the expected benefits of separation of concerns. ACM SIGSOFT Software Engineering Notes vol 26 no 1 January 2001 Page 79

3 MULTI-DIMENSIONAL SEPARATION OF medularization mechanisms provided by modern languages, and CONCERNS corresponding approaches to composition. We use the te~m multi-dimensional separation of concerns to de- Don Batory, "Refinements and Separation of Concerns" (invited note separation of concerns involving: presentation). • Multiple, arbitrary dimensions of concern. Today's notions of encapsulation are very restricted- a module • Separation along these dimensions simultaneously', i.e., a devel- or component contain~ only source code. What we really need is oper is not forced to choose a small number (usually one) of for modules or component to encaps~d_ate not only source code that dominant dimensions of concern according to which to decom- will be installed when the component is used, but also encaps~l~e pose a system at the expense of others. corresponding changes to documentmi_'on, formal properties, and performance properties -- i.e., changes to the central concerns of • The ability to handle new concerns, and new dimensions of con- software development. The general abstraction that encompasses cern, dynamically, as they arise throughout the software lifecy- this broad notion of encapsulation is called a "refinement". cie. Concerns that span artifacts and stages of the software life- cycle are especially interesting, and challenging. Franz Achermann, "Language Support for Feature Mixing" • Overlapping and interacting concerns; it is appealing to think of Object oriented languages cannot express certain composition ab- many concerns as independent or "orthogonal," but they rarely stractions due to restricted abstraction power. A number of ap- are in practice. It is essential to be able m support interacting proaches, like SOP or AOP overcome this restriction, thus giving concerns, while still achieving useful separation. the programmer more possibilities to get a higher degree of sepa- ration of concenL We propose forms, extensible mappings f~m • Concern-hased integratiox~ Separation of concerns is clearly of labels to values, as vehicle to implement and reason about compo- limited use if the concerns that have been separated cannot be sition abstractions. Forms unify a variety of concepts such as inter- integrated; as Jackson notes, "having divided to conquer, we faces, environments, and contexts. We are prototyping a composi- must reunite to rule" [3 ]. tion language where forms are the only and ubiquitous first class Full support for multi-cfimensional separation of concerns opens value. Using forms, it is possible compose soRware artifacts fo- the door to on-demand remodularizat~on, allowing a developer to cusing on a single concern and thus achieve a high degree of sepa- choose at any time the best modularization, based on any or all of ration of concertL We befieve that using forms it also possible to the concerns, for the development task at hand. Mnlti-dimensional compare and reason about the different composition mechanisms separation of concerns thus represents a set of very ambitious proposed. goals, applying to any software development language or para- digra. Lodewijk Bergmans, "Composing Software from Multiple Con- cerns: A Model and Composition Anomalies" A good deal of research has been done within the last decade or so Constructing software from components is considered to be a key on "advanced" approaches to separation of concerns requiremem for managing the complexity of software. Separation [1,2,3,4,5,6,7,8,9,10,12,13,14,15,16,18,20,21]. Considerable re- of concerns makes only sense ff the realizations of these concerns search is still required, however, before any approach fully can be composed together effectively into a working program. achieves the goals stated above. We believe that it is necessary to Various publications have shown that composability of software is achieve them in order to overcome the problems associated with far from trivial and fails when components express complex be- the tyranny of the dominant decomposition and to re~liT¢ the havior such as constraints, synchronization and history- potential of separation of concerns. sensitiveness. We believe that to ad-dress the composability prob- 4 THE WORKSHOP lems, we need to understand and define the situations where com- This workshop was intended to bring together researchers inter- position fails. To this aim, in this paper we (a) introduce a general ested in pushing the frontier in this important and burgeoning area, model of multi-dimensional concern composition, and (b) define and practitioners who have experienced problems related to inade- so-called composition anomalies. quate separation of concerns that can help to guide their research. Mark Chu-Carroll, "Software Configuration Management as a Twenty-five position papers were accepted to the workshop, all Mechanism for MDSOC" available at the workshop Web site [20]. The workshop consisted Real software rarely conforms to one single view of the program of five sessions, organized around some of the key themes that structure; instead, software is sufficiently complex that the strut- emerged from the position papers. Most sessions were introduced tare of the program is best understood as a collection of orthogonal by brief prese~_atJons, and continued with general discussion. divisions of the program into components. However, most soft- The rest of this section outlines the sessions of the workshop and, ware tools only recognize the decomposition of the program into where appropriate, the presentations that introduced then~ The source files, forcing the programmer to adopt one primary program abstracts have been extracted verbatim from the position papers. de-composition which is well-suited to some tasks and poorly suited to others. Software tools can overcome this weakness by Introduction: Setting the Stage allowing programmers to trangform their view of the program to a A brief overview of common concepts and terminology, and moti- structure which is more appropriate for the task they need to per- vation for multi-dimensional separation of concerns was presented forr~ We propose that a software configuration management by Peri Tarr. The foils axe available at the workshop Web site [20]. (SCM) system, which stores the source code for the project, can Models of Decomposition and Composition perform this task. By providing the SCM system with the capabil- Fundamental to multi-dimensional separation of concerns are ap- ity to generate orthogonal program organizations through compo- proaches to decomposing software that go beyond the standard sitions of pro-gram fragments, the SCM system can support or- ACM SIGSOFT Software Engineering Notes vol 26 no 1 January 2001 Page 80 thogonal decompositions of the program without performing any Bill Griswold, "Aspect Browser: Tool Support for Managing Dis- automatic alteration of the source code. persed Aspects." Although modularization, if used properly, separates the concerns Real-Life Dimensions of Concern of primary design decisions, it often fails to cost-effectively sepa- The primary motivation behind multi-dimensional separation of rate lower-order design decisions. These lower-order decisions concerns is that there are many different kinds of concerns that may cross-cut the primary module structure. Changes to these come up during the software lifecycle, all of which should be rec- cross-cutting design decisions tend to be more costly since they are ognized and at least some of which should be separated. This ses- dispersed throughout the system and tangled with the primary de- sion began with small discussion groups, each focusing on a par- sign decisions and each other. When the code relating to a par- ticular phase of the lffecycle, followed by general discussion. The ticular change is not localized to a module, an information- purpose of the session was to raise important dimensions of con- transparent allows a programmer to use available cern that ann up durin_g each phase, and to discuss their relation- software tools to economically identify and quickly view the re- ships, and the extent to which they span lifecycle phases and inter- lated code, easing the change. That is, the "si~_amre" of the act with concerns arising in other phases. changing design decision can be used to approximate the benefits Dimensions of Concern in Product Lines and Software Archi- of locality, in particular providing a way to quickly view and com- tecture pare the elements of the cross-cutting aspect without distraction Product lines have particularly strong separation of concerns re- from inessential details. This signature is one or more shared char- quirements. In addition to separating components, they must also acteristics of the code to be changed, such as the use of particular separate variants, often involving multiple components, from one variables, data structures, language features, or system resources. another and from the base. Separation of concerns is also one of Since the intrinsic characteristics of a design decision can be inci- the themes of . Care is taken to separate com- dentally shared by unrelated code, it is helpful if the programmer ponents from interactions, and a key distinguishing feature of dif- has adopted distinguishing conventions such as stylized naming of ferent architectural styles is what kinds of concerns they separate, identifiers. and how. This session explored the implications of multi- Anthony Finkelstein: "Consistency Management of Distributed dimensional separation of concerns for these important areas. Documents using XML and Related Technologies" Joachim Bayer, "Towards Engineering Product Lines using Con- In this talk I will describe an approach to managing consistency of cerns '" distributed documents. I will give an account of a toolkit which Separation of concerns is accepted as introducing numerous bene- demonstrates the approach. The toolkit supports the management fits into software development and maintenance. In this position of consistency of documents with Intemet-scale distribution. It paper, we argue for a method that introduces separation of con- takes advantage of XML (eXtensible Markup Language) and re- cerns into product line software engineering. The method covers lated technologies. The talk will include a brief discussion of the the complete product line life cycle and integrates the different base technologies, a discussion of related work and a demonstra- concerns expressed at the different product line life cycle stages. tion. The approach and the toolkit will be described in the context of a typical application in the area of software engineering. Juha Savolainen, "Improving Product-Line Development with SOP" REFERENCES It has been demonstrated the product lines have introduced large 1. Mehmet Aksit, Lodewijk Bersmans, and S. Vural. "An Object- improvements to quality, time to market and overall productivity. Oriented Language-Database Integration Model: The Composition Filters Approach." Proceedings of ECOOP'92, Lecture Notes in However, creating a successful product line is a highly complex Computer Science #615, 1992. and difficult task. There are still many technological barriers to overcome in effective product line development. The current in- 2. E.P. Andersen and T. Reenskaug. "System Design by Composing dustrial practice employs patterns, idioms and components to han- Structures of Interacting Objects." Proceedings of the European Con- die complexity, but shortcomings in current object-oriented lan- ference on Object-OrientedProgramming (ECOOP), 1992. guages limit the effectiveness of product line development. Sub- 3. Elisa L.A. Baniassad and Gaff C. Murphy. "Conceptual Modules ject-oriented programming and more recently multi-dimensional Querying for Software Reengineefing." In Proceedings of the Inter- separation of concerns promise improved support for product line national Conference on Software Engineering (ICSE 20), April 1998. development. Ideally, a product line can be composed of slices of 4. Don Batory, Gang Chen, Eric Robertsen, and Tao Wang; Design an overall system that provide low coupling among components, Wizards and Visual Progral~rning Environments for GenVoca Gen- good separation of unrelated concerns and improved understand- erators, IEEE Transactions on Software Engineering, May 2000, ability of the system slxucture. In this paper we describe our expe- 441-452. riences on applying subject-oriented programming to product line 5. Don Batory, Clay Johnson, Bob MacDonald, and Dale von Heeder, development. "Achieving Extensibility Through Product-Lines and Domain- Tools and Visualization Specific Languages: A Case Study", International Conference on Identification of and encapsulation according to multiple dimen- Software Reuse, Vienna, AusU-/a,2000. sions of concern simultaneously introduces the need for tools that 6. Kz'zysztofCzamecki and Ulrich W. Eisenecker. Generaffve Pro- perform a variety of functions, including to find, display, identify, gramming: Methods, Tools, and Applications. Addison-Wesley, extract, analyze, separate and compose concerns. It also opens up Reading, MA, June 2000. rich possibilities for visualizing software in flexible ways based on 7. D. D'Souza and A. C. Wills, Objects, Components, and Frameworks different dimensions of concern at different times, not constrained with UA~L:The Catalysis Approach. Addison-Wesley, 1998. by any dominant decomposition. ACM SIGSOFT Software Engineering Notes vol 26 no 1 January 2001 Page 81

8. Martin L. C,-riss. "hnplement~g Product-Line Features with Compo- nent Reuse," Proceedings 6 m International Conference on Software Reuse, Vierma, Austria, June 2000. 9. W. Harrison and H. Ossher. Subject-orientedprogramming (a cri- tique of pure objects). In Proceedings of the Conference on Object- Editor's Filler Oriented Programming: Systems, Languages, and Applications, pages 411--428, September 1993. ACM. Space to fill! 10. I.M. Holland. Specif~g reusable components using contracts. In O. L. Madsen, editor, ECOOP '92: European Coherence on Object- Oriented Programming, pages 287-308, Utrecht, June/July 1992. Springer-Verlag. LNCS 615. Not like the top of my desk :-) 1 I. M. Jackson. Some complexitiesin computer-based systems and their implicationsfor system development. In Proceedings of the Interna- tional Conference on Computer Systems and Software Engineering, .... or my hard drive. pages 34d 851, 1990. 12. Gregor Kiczalcs, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Mare Loingtier, John Irwin. "Aspoet- I suppose I should say a few words Oriented Programming." In proceedings of the European Conference about FSE-8 in San Diego on Object-Oriented Programming (ECOOP), Finland. Springer- Verlag LNCS 1241. June 1997. 13. Karl Lieberhc~, Adapave Object-Oriented Software: The Demeter ... the only ones that come to Method with Propagation Patterns. PWS Publishing Company, Boston, 1996. mind are 14. Mira Mczim, "PIROL: A Case Study for Multidemansional Separa- tion of Concerns in SoRwaxe Engineering Environments." In Pro- ceedings of the Conference on Object-Oriented Programming: Sys- "very nice." tems, Languages, and Applications (OOPSLA), pages 188-207, Oc- tober 2000. 15. Mira M~ni and Karl Lieberherr. "Adaptive Plug-and-Play Compo- Of course there were the miss -~ nents for Evolutionary Software Development." In Proceedings of ing (I mean mis-placed) boxes the Conference on Object-Oriented Programming: Systems, Lan- guages, and Applications (OOPSLA), October 1998. of tutorials and proceedings, but 16. Bashar Nuseibeh, JeffKramer, and Anthony Finkelstein. "A Frame- John Knight and David Rosen- work for Expressing the Rehtionships Between Multiple Views in Requirements Specifications." In Transactions on Software Engi- blum should be congratulated for neering, vol. 20, no. 10, pages 260-773, October 1994. putting together a fine conference. 17. David L. Pamas. "On the Criteria To Be Used in Decomposing Sys- tems into Modules." Communications of the ACM, vol. 15, no. 12, December 1972. John and David couldn't have 18. Peri Tan-, Harold Ossher, William Harrison, and Stanley M. Sutton, Jr. '~ Degrees of Separation: Multi-Dimensional Separation of Con- done it without the help of Debra cerns." In Proceedings of the 21 ~ International Conference on Soft- Brodbeck and Peggy Reed. ware Engineering, pages 107-119, May 1999. 19. C. 1L Turner, A. Fuggetta, L. LavazT~aand A. L. Wolf. Feature Engi- neering. In Proceedings of the 9th International Workshop on Soft- And thanks to everyone who at- ware Specification and Design, 162-164, April, 1998. tended. 20. M. VanHilst and D. Notkin. Using roles components to implement collaboration-based designs. In Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applica- tions, pages 359-369, October 1996. ACM. Next year FSE will be in Vienna 21. Robert J. Walker, Elisa L.A. Baniassad, and Gall C. Murphy. "An with ESEC in September... a Initial Assessment of Aspect-oriented Programmin__g." In Proceed- ings of the International Conference on SoRware Engineering (ICSE lovely city if you have not been 21), May 1999. there before, if I do say so myself! 22. Workshop Web site: http://www.research.ibm.com/h~ce/work- shopdicse2000