Workshop on the Modeling and Analysis of Concerns in (MACS 2005)

Martin P. Robillard McGill University, Montréal, Canada [email protected]

Abstract This report is a summary of the Workshop on the Modeling and Workshop Organization Analysis of Concerns in Software (MACS 2005) held at the 27th We solicited short papers describing ongoing work, new ideas, or International Conference on (ICSE 2005). recent experience within the scope of the workshop. Each sub- The main goal of the workshop was to bring together researchers mission was reviewed by the organizers and by members of the and practitioners with interest in techniques for modeling and ana- program committee. We selected papers for presentation at the lyzing the realization of concerns in software systems to support workshop based on relevance to the workshop themes and poten- software development and evolution. The workshop consisted of tial to generate interesting discussions. In total we selected three an interactive combination of presentations and discussions. The papers for extended presentations and 13 papers for short interac- presentations and discussions were based on a collection of 16 tive presentations. The abstract of each paper appears in the short papers covering a wide range of approaches. printed edition of Software Engineering Notes, and the full text of each paper appears in the on-line edition. Keywords: Separation of concerns, software modeling, software analysis. Organization Committee Theme and Goals Martin Robillard, McGill University, Canada Peri Tarr, IBM T.J. Watson Research Center, USA Most , implementation, and modification activities are organized, explicitly or implicitly, around the idea of concerns. Program Committee Concerns that arise during software engineering activities typically Siobhán Clarke, Trinity College, Ireland include features, non-functional requirements, low-level mecha- Yvonne Coady, University of Victoria, Canada nism (e.g., caching), and many other concepts. Programming lan- David Coppit, The College of William and Mary, USA guage-supported constructs like modules, classes, and aspects William Griswold, University of California, San Diego, USA enable the encapsulation of certain concerns. Unfortunately, be- Rainer Koschke, University of Bremen, Germany cause of the limitations of programming languages, structural deg- Juri Memmert, JPM Design, Germany radation due to repeated changes, and the continual emergence of Gail Murphy, University of British Columbia, Canada new issues, the realization of concerns is often scattered and tan- Harold Ossher, IBM T.J. Watson Research Center, USA gled through the logical decomposition of numerous artifacts (re- Arie van Deursen, CWI and Delft University, The Netherlands quirements, design diagrams, source code, etc.). Studies and experience have shown that the scattering and tangling of con- Workshop Web Site cerns increases the difficulty of evolving software in a correct and http://www.cs.mcgill.ca/~martin/macs2005 cost-effective manner. The goal of the MACS 2005 workshop was to bring together re- Summary of the Presentations1 searchers and practitioners with interest in techniques for model- The workshop was divided in four sessions. Each session was ing and analyzing the realization of concerns in software systems intended to explore a specific theme and compare and contrast to support software development and evolution, and to explore the different approaches associated with or exemplifying the theme. potential for integration and interoperability in concern analysis and modeling techniques. Specific themes for the workshop in- Concern Modeling cluded: The first session grouped the presentation of different concern • Concern modeling and representation environments modeling approaches and focused on exploring the costs and • Automated and interactive concern location approaches benefits of modeling concerns at different levels of abstractions. • Concern mining techniques Just-In-Time Concern Modeling. Martin P. Robillard and Gail C. • Concern visualization and reverse engineering techniques and Murphy. After the workshop introduction, Martin Robillard briefly tools described the concept of just-in-time concern modeling and its • Advanced analysis and design techniques for separation of support in the FEAT tool. Just-in-time concern modeling refers to concerns the idea of modeling concerns only when developers first encoun- • Code transformation and refactoring techniques for separation ter them as part of a program modification task. of concerns 1 Some of the text in this section is edited from material (talks, papers, notes) provided by the workshop participants. Significant portions are indicated in quotes. Concern Modeling in the Concern Manipulation Environment. to be evolved along different dimensions”, enabling developers to William Harrison, Harold Ossher, Stanley Sutton Jr., Peri Tarr. choose the most appropriate dimension for a given task. Stan Sutton presented a brief tour of the Concern Modeling Envi- ronment (CME) and of the different perspectives on concern mod- Concern Mining eling offered by CME. The third session focused on the presentation and discussion of approaches to elicit or locate concerns in existing artifacts. A Model of Software Plans. Robert R. Painter, David Coppit. In the first extended presentation of the workshop, David Coppit Using Language Clues to Discover Crosscutting Concerns. David presented the idea of mitigating scattered concerns through soft- Shepherd, Tom Tourwé, Lori Pollock. For the third extended pres- ware plans. Software plans are an “approach for dealing with entation of the workshop, David Shepherd described an approach fine-grained concern tangling.” The editor-based approach sup- to automatically identify scattered concerns based on an analysis ports a document model that explicitly represents concerns in of the natural language clues found in source code. The proposed source code and dependencies between blocks of code. approach uses the technique of lexical chaining to locate sets of semantically related terms and their location in source code. Such Mapping Concern Space to : A Connector- sets have the potential to denote scattered concerns. Based Approach. Jing Liu, Robyn R. Lutz, Jeffrey Thompson. Jing Liu described an approach to model concerns in the architectural Locating Crosscutting Concerns in the Formal Specification of design, and illustrated the idea with a case study of a cardiac defi- Distributed Reactive Systems. José J. Pazos-Arias, Jorge García- brillator product line. Duque, Martín López-Nores, Bélén Barragáns-Martínez. José Pazos-Arias presented an approach for the “semi-automatic identi- Separating Architectural Concerns to Ease Program Understand- fication of crosscutting concerns at the requirements level.” The ing. Vladimir Jakobac, Nenad Medvidovic, Alexander Egyed. approach is intended to improve the incremental process of pro- Alex Egyed described and illustrated concern modeling at the ar- ducing specifications for a distributed system. chitectural level using the ARTISAn program understanding framework. Separation of Concerns in Software Product Line Engineering. Mazen Saleh and Hassan Gomaa. Mazen Saleh described an ap- Visualization and Transformation proach and tool supporting the separation of concerns in the con- The second session grouped presentations on the topics of concern text of software product lines. The approach supports “automatic visualization and concern modeling for the purpose of program customization of target applications” based on a feature model transformation. The goal of the session was to explore the trade- expressed through a feature description language. offs involved in obtaining intended modularity through visualiza- An Exploration of How Comments are Used for Marking Related tion versus transformation. Code Fragments. Annie T.T. Ying, James L. Wright, Steven ActiveAspect: Presenting Crosscutting Structure. Wesley Coelho, Abrams. Annie Ying reported on an empirical study of comments Gail C. Murphy. In the second extended presentation of the work- in source code. The main observation of the study is that “pro- shop, Wesley Coelho described a technique for presenting cross- grammers mark related code fragments by comments” that either cutting structure and a tool, ActiveAspect, that supports the reference related code explicitly or that are similar to other com- technique. With ActiveAspect, “crosscutting structure can be pre- ments located near related code. The conclusion of the study sup- sented in a diagram view without excessive complexity using a ports the intuition that comments contain valuable clues that can combination of user interaction and automated abstraction tech- be used to identify and understand scattered concerns. niques.” Concern Analysis Concern Management for Constructing Model Compilers. Nao- The final session of the workshop focused on concern analysis yasu Ubayashi, Tetsuo Tamai. Naoyasu Ubayashi described As- techniques. pectM, a designed for the management of modeling-level aspects. AspectM improves the separation of con- An Approach to Aspect Refactoring Based on Crosscutting Con- cerns pertaining to model transformations in model-driven archi- cern Types. Marius Marin, Leon Moonen, Arie van Deursen. tecture-based development. Marius Marin “argued for the importance of organizing generic crosscutting concerns by distinctive properties”. He proposed the A Model-Driven Approach to Enforce Crosscutting Assertion idea of categorizing crosscutting concerns into types. This ap- Checking. Jing Zhang, Jeff Gray, Yuehua Lin. Jeff Gray outlined proach has the potential to help reason about applicable refactor- a “two-level aspect weaving approach to enforce contracts over ings than can applied to the crosscutting concerns to improve their different abstraction levels.” The approach illustrated some of the modularity. challenges of weaving assertion-checking code into high-level domain models. Separation of Concerns for Evolving Systems: A Stability-Driven Approach. Haitham S. Hamza. Haitham Hamza proposed an Pattern Transformation for Two-Dimensional Separation of Con- analysis for early separation and modeling of concerns intended to cerns. Xiaoqing Wu, Barrett R. Bryant, Jeff Gray, Marjan Mernik. maximize the stability of a design to reduce the likelihood that Xiaoqing Wu described an approach for two-dimensional separa- scattered concerns will emerge. The approach relies on software tion of concerns allowing developers to transform code back and stability models and formal concept analysis. forth between an object-oriented implementation of the Inheri- tance design pattern and an aspect-oriented implementation of the Concern Patterns and Analysis. Juri Memmert. Juri Memmert Visitor design pattern. This approach allows “the same software showed that patterns can be found in the realization of concerns across different software engineering artifacts produced in differ- The third session focused on concern mining techniques. With ent phases of the software life-cycle, and how such patterns can be two presentations on the analysis of comments and identifiers indicative of problems, such as ripple change effects, that will found in source code, the participants realized the importance of impact the development process. natural language clues for the automatic detection of scattered concerns. As a corollary, the importance of heuristics for auto- mated concern mining approaches was also noted. One open issue Summary of the Discussions emerging from the discussions in the third session is how to bridge In each session the interactions centered on the clarification and the gap between the approximate concern models produced by discussion of the different approaches presented. In the final ses- automated or interactive concern location techniques and the for- sion a general discussion took place where the participants fo- mal models used for code transformation. cused on defining the term “concern” in the context of software engineering and on synthesizing the workshop. The final session on concern analysis emphasized the need to clearly understand the nature of scattered concerns and the poten- Defining Concerns for Software Engineering tial benefits that can be derived from concern models, including The participants first agreed that the notion of a concern in soft- early diagnosis of structural problems in a software system and ware engineering is a very general one and that it changes based support for refactoring. on the context in which concerns are considered. Nevertheless, a consensus was rapidly reached in support of the observation that Conclusion there are two perspectives to the notion of a concern. First, a con- The workshop brought together over 25 researchers and practitio- cern is a conceptual area of interest or focus for a stakeholder of a ners with interest in techniques for modeling and analyzing the software project (e.g., a developer). This definition is necessarily realization of concerns in software systems to support software vague as it pertains to notions in people’s mind, which may be development and evolution. Sixteen presentations described on- approximate and incomplete. In the second perspective, the term going work covering an impressive range of approaches that span “concern” also refers to the concrete manifestation of conceptual multiple phases of the software life-cycle (requirements, design, concerns (e.g., in source code, design diagrams, or other artifacts). and implementation), and operate at different levels of abstraction After converging on a definition of a concern as a conceptual area (from architectural design to source code). In addition to the of interest and its manifestation in a software project, the discus- ideas, techniques, and tools described, many of the presentations sion focused on the issue of mapping or representing a concern’s reported on case studies illustrating the different types of concerns manifestation. In other words, how does one reliably associate a that arise during the life of a software project. Taken together, the conceptual concern with its concrete manifestation? Many ap- projects presented and discussed at the workshop form a window proaches can be used to achieve this goal, including a number of on an active field of research at the intersection of many of the approaches presented at the workshop. While there is currently no traditional sub-disciplines of software engineering. The workshop consensus on the best way to meet this goal, there was neverthe- resulted in a better understanding of the area of concern modeling less agreement on the importance of the question for the purpose and analysis and of the open issues in this area. The specific out- of modeling and analyzing concerns in software. come of the workshop includes a definition of the term “concern” in the context of software engineering, 16 papers describing prom- Synthesis of the Workshop ising concern modeling and analysis techniques, and a record of During the first session the different presentations illustrated the open issues for the research community. need for techniques to help developers model concerns at different levels of abstraction, from source code to architectural design. One opinion expressed by a number of participants is that con- cerns in the code should be reflected in higher-level artifacts. This observation opened a discussion on traceability and on the poten- tial for concern modeling techniques to facilitate traceability be- tween different artifacts of the software development process. The presentations of the second session led to a brief debate on the respective goals of concern visualization and transformation tech- niques. Simply put, the question is as follows: given a concern whose realization is scattered, should we use a visualization tech- nique to view and modify it as a single entity, or should we physi- cally transform the code to encapsulate the concern in a single module? There is no clear answer, and the general consensus was that visualization and transformation approaches are complemen- tary. For example, a visualization approach can be used to under- stand transformed code, and a transformation approach can be used to refactor a concern into its own module based on an analy- sis performed with a visualization technique.