View metadata, citation and similar papers at core.ac.uk brought to you by CORE

provided by Infoscience - École polytechnique fédérale de Lausanne

On The Role of Multi-Dimensional Separation of Concerns in Software Architecture Position Paper for the OOPSLA’2000 Workshop on Advanced Separation of Concerns Mohamed Mancona Kandé and Alfred Strohmeier Swiss Federal Institute of Technology Lausanne Software Engineering Laboratory, CH-1015 Lausanne, Switzerland Email: {mohamed.kande, alfred.strohmeier}@epfl.ch

ABSTRACT what characteristics of a software system should be In this paper we study the need for multidimensional specified by an ADL [4,5]. Likewise, there are still many separation of concerns in architecture representations, controversies about the definition of software architecture, including architecture-centered software development. We which continue to complicate the emergence of established present a case study of a simple video surveillance system, architectural practices and their controlled evolution [6]. describe its software architecture using an ADL called The second category consists of problems that are specific Wright, and we discuss the pragmatics and problems in the to the current trends in software architecture research and use of ADLs in general, compared to a concern-based practice. These often result in certain restrictions of the approach to software architecture description. expressive power of software architecture, e.g., in the Our position is that current ADLs provide architectural inability of integrating existing ADLs with other software abstractions that need to be extended to achieve the major development artifacts [7]. goals of software architecture. Furthermore, in order to Both categories of problems mentioned above are somehow cover all concerns of importance in a software architecture related to the limitations of current architectural abstraction description, software architects must be able to separate mechanisms (including software architecture various dimensions of concern and consider the system methodologies, notations and tools [2,3,4,5,8,9,10]) to from multiple perspectives simultaneously. support simultaneous separation of concerns at multiple levels of abstraction. We believe that an architect, to be Keywords: Multidimensional separation of concerns, able to provide a software architecture description that software architecture, software architecture description, reflects all architecturally significant aspects of a system, ADL, architectural viewpoints, architectural views, requires an appropriate use of the notion of concern spaces. multidimensional separation of concerns. 1 INTRODUCTION Multidimensional separation of concerns is a new field in In the last ten years, software architecture has turned out to need of attention in software engineering research and be a significant area of research and practice in software practice that was first introduced by Tarr and colleagues. engineering. Representing architectures in an unambiguous These authors hypothesized that major difficulties relative and explicit way has been characterized as a critical issue in to the improvement of software reuse, comprehensibility, the design and construction of any complex software component integration and high impact of change in system [1]. The major goals of software architecture consist software systems are due to a deficiency of separation of of providing blueprints for constructing software-intensive concerns. In addition, they argued that in spite of the systems, helping stakeholders to understand, manage and presence of mechanisms to attain separation of concerns in analyze fundamental system properties, as well as all modern software formalisms, software artifacts still providing means that allow stakeholders to communicate continue to exhibit properties associated with poor and reason about such system properties. These are separation of overlapping concerns [11]. The initial work in admirable goals; however, despite important industrial and this recent area is mainly focused on providing a support research activities in the area of software architecture, there for multidimensional separation of concerns in are still many problems that remain considerable barriers to programming languages and environments [12,13]. the achievement of the objectives of software architecture. We have started studying the notion of multidimensional These barriers involve two categories of problems. The first separation of concerns in the context of software category consists of problems that are related to the architecture and examining how we can take advantage of immaturity of software architecture in general. This the separation of overlapping concerns in both software category is typically characterized by some strong architectural descriptions and architecture-centered divergences in the field: there is still little agreement on software development. In this paper, we put emphasis on what an architecture description language (ADL) is, and discussing the role of multidimensional separation of

1 concerns in the area of software architecture. [14,15].) To demonstrate the need of multidimensional separation of Figure 1 Topology for Video Surveillance System concerns in software architecture, let us compare the Wright provides a support for separating a few dimensions architecture description we would obtain if we used a (kinds) of concern: it allows us to separate the structure typical ADL, such as Wright, to the architecture description from behavior concerns in the architecture of a software we would get if we used a concern-based approach to system and it also fosters separation between the software architecture description. computation, communication and configuration concerns.

2 AN ADL-BASED APPROACH TO SOFTWARE Structure of the System Architecture ARCHITECTURE DESCRIPTION In Wright the structure of a system architecture is In this section, we briefly introduce an example of represented as an arrangement of a set of typed components architecture description using Wright [10]. We present the and connectors that work together. Components represent Wright architectural modeling constructs and notations by abstractions for independent computational entities or illustrating the case study of a simple Video Surveillance system-level storage units. Connectors abstractly represent System (VSS) [7]. As shown in Figure 1, VSS consists of a interactions among components. Defining the structure of set of video cameras that interact with a control station over the system architecture using Wright consists in describing a communication platform. The example illustrates two architectural styles or families of systems and declaring the kinds of software architecture constructs: the component configuration. types of the system and their interconnection described by a Figure 2 shows a static Wright specification of the VSS, connector type. which consists essentially of two parts: the first one The CameraDevice component type abstracts a set of represents the declaration of the architectural style geographically distributed video cameras, whereas the (SimpleVideoSurveillanceSystem), while the second VideoControlStation component type abstracts the part of the one declares the configuration (SimpleSCSystem). The system that remotely controls the cameras and continuously Style introduces component and connector types, and receives the video streams. The connector type, constraints. The structure of each Component specification VSConnector, is an abstraction for the communication consists of a Port (p) and a Computation part. The Connector platform. It consists of two kinds of elements: a pair of specification consists of two Roles (source and sink) and a connection points and the protocol of interactions between Glue. Ports and roles describe elements of components and these connection points. Each connection point represents connector interfaces, respectively. These can be considered an interface to the connector a component can use. In order as Wright implementations of connection points in both to be able to participate in a communication mediated by a components and connectors. The computation describes the connector, a component must implement this interface. The entire behavior of the components, while the glue specifies implementation might be in software or in hardware. the comprehensive behavior of connectors. Conceptually, connection points can be seen as interface The configuration requires an instantiated style. Thus, it elements for both component and connector types. We use uses instances of the component and connector types that in Figure 1 two circles (white and black) to graphically are defined in the style, to attach their ports to roles. In the represent the interfaces with the camera device and the example, the SimpleSCSystem configuration shows how video control station. Indeed, these are two connection both ports (p) of the component type instances vcs and cd points, conjugates of one another. As in previous work, to are attached to the connector type instance connector. represent a component type in the topology of VSS, we use These attachments mean that the port p of the component one of the UML extension mechanisms to define the vcs (instance of VideoControlStation) fills the role of type «archComponent» stereotype, which has the properties of sink belonging to connector. At the same, the port p of both a UML Class and a UML Package. The connector type is represented by a stereotype of Collaboration that the component cd (instance of CameraDevice) fills the role contains a connector icon, shown by the black and white of type source that belongs to connector. linked circles, at the upper right in the oval. The dashed Behavior of the System Architecture line between the connection points is a UML binding that, The Wright specification of the architectural behavior of in this case, conceptually represents the attachment of two the VSS describes a set of significant events that are connection points. (For further details on UML, see processed by components, and the sequences in which these events occur. To describe the behavior of components

Connection Points Conceptual Attachment and connector types, Wright allows us to specify a process for each of the following elements: port, role, computation «archComponent» «archComponent» and glue. CameraDevice VSConnector VideoControlStation Style SimpleVideoSurveillanceSystem Component VideoControlStation Port p = videostreamrequest → ready → p П § (source and sink) are kept simple and identical to those of Computation = streamCompute → p.videostreamrequest → the ports. This makes it easier to see how instances of both → p.ready Computation П § component types can attach their ports to these roles to be Component CameraDevice interconnected in the configuration. Port p = videostreamrequest → ready → p§ Computation = videostreamrequest → p.streamCompute → The Glue process specifies the interaction protocols p.ready → Computation § between the roles of a connector. In our example, the Connector VSConnector VideoControlStation initiates an event to request video source.videostreamrequest Role sink = videostreamrequest → ready → sink П § streams ( ) that must be sent Role source = videostreamrequest → ready → source П § as source.videostreamrequest to the CameraDevice, and Glue = source.videostreamrequest → the response (source.ready) of the CameraDevice must be sink.videostreamrequest → Glue source.ready → sink.ready → Glue sent back as sink.ready to VideoControlStation. § So Wright proposes notations for abstractly and formally Constraints representing software architectures and exposing properties ∃!s∈ Component, for analysis by promoting the independence of connectors ∀ c ∈ Component : TypeCameraDevice (s) ∧ and components and by increasing the flexibility to TypeVideoControlStation (c) ⇒ connected(c,s) compose and reuse both connectors and components. EndStyle Current ADLs, including Wright, have provided a solid Configuration SimpleSCSystem Style SimpleVideoSurveillanceSystem foundation on which one can explore some architectural Instances vcs : VideoControlStation; abstractions that define various dimensions of concern in cd : CameraDevice; connector : VSConnector software architecture. However, through the pursuit of such Attachments vcs.p as connector.sink; a foundation of software architecture, we have begun to cd.p as connector.source EndConfiguration discover some inflexibility encountered by studying comparisons between existing ADLs [3,4,5]. Figure 2 Static Wright Specification for Video Surveillance Thus, ADLs allow architects to decompose systems along System only a few dimensions of concerns. According to P. Tarr Note that the Wright notation for behavioral description and her colleagues, these are dominant dimensions of indicates the direction of interactions by explicitly concern. For instance, as the Wright notion of architecture distinguishing initiated events (overlined) from observed description is essentially centered on the representation of events (not overlined). To make the editing work easier, we architectural styles, we can consider styles to be the replaced these overbars by underlines in Figure 2. “dominant” dimension of concern in Wright-based software architectures. The computation process specifies how to handle events arriving on any port of a component and how to send events through the ports. The VideoControlStation 3 A CONCERN-BASED APPROACH TO requests some video streams over and over again (by SOFTWARE ARCHITECTURE DESCRIPTION sending the p.videostreamrequest events) through the Throughout this position paper, we take the premise that port p and waits for a response (p.ready) on the same port providing an architectural approach to large-scale software p; or it terminates successfully (§). In this particular case, development is the right way of proceeding. However, as the VideoControlStation decides by itself whether it we discussed earlier, describing software architecture along makes another request or terminates. This way of taking a only a restricted number of dimensions of concern is decision by itself is referred to as an internal choice and important, but often not enough. While restricting denoted by the П symbol. In contrast, an external choice has dimensions of concern facilitates the job of software been used in the computation specification of the architects, it makes it very difficult to express, analyze and CameraDevice. This means that the computation process of reason about key structures of software architecture. In CameraDevice is expected to reply to each request, and is particular, this is the case when we admit that: not allowed to terminate in advance. Software architecture is an abstract but fundamental The process p assigned to the VideoControlStation port, “thing” that represents a bridge between requirements, defines the way this component interacts with its program code and runtime execution environment. environment using this port. This is a local interaction The description of the structure or all the structures that protocol, which covers the same behavioral pattern as constitute such a bridge is what we referred to as software defined in the computation process mentioned above, architecture description all through this work. These except the internal part (specified by streamCompute structures involve numerous kinds of concerns that often event). need to be further refined, encapsulated, manipulated and In this example, the specifications of both role processes implemented at other stages in the software life cycle. To describe the software architecture of complex systems, conventions that guide a projection of concern space onto software architects are concerned with the identification, individual architectural views along some specific representation, composition, decomposition and analysis of dimensions. The notations of a viewpoint describe the multiple structures. Thus, to foster the description of language elements that are needed for appropriately software architectures, we have started the ConcernBASE representing all the concerns of the software architect from (Concern-Based and Architecture-centered Software the perspective defined by that viewpoint. Engineering) project. ConcernBASE is a software engineering approach that complements the abstraction Architectural Concern Spaces mechanisms found in current ADLs, allows for A concern space defines rules for representing dimensions simultaneous separation of overlapping concerns in of concern in certain architectural views. It describes a software architecture description and provides a support for pattern or template from which to develop individual views architecture-centered software development. Seen as an by establishing the purposes and audience for each view architectural approach, ConcernBASE allows us to and by providing techniques to create and analyze each of consider the software architecture of a system as an abstract the views. Each architectural concern space defines a set of thing and to decompose it into a set of concern spaces, each concerns relative to a particular perspective and of which has multiple architectural dimensions. encapsulates ideas, notions, elements, properties or other things that are architecturally significant and cut across ConcernBASE is built around three basic abstractions: multiple dimensions. architectural viewpoints, architectural concern spaces and architectural views. Thus, a concern space provides a mechanism for multidimensional separation of concerns, by mean of which The relationships between these three basic elements are various dimensions can be represented in an architectural illustrated in Figure 3. Figure 3 presents two architectural view simultaneously. A concern space allows us to create, viewpoints (the Structural Viewpoint and Architecture Analysis depict and analyze one or more architectural views at the Viewpoint) and their corresponding concern spaces named same time and it specifies how to integrate and manage Structural Concern Space and Architecture Analysis Concern those architectural views. Space.

Structural Structural Static View Viewpoint Concern Space Configuration View

Architecture Behavioral Analysis View Architecture Concern Analysis Space System under Viewpoint development

Figure 2: Relationship between Architectural Viewpoints, Basically, an architectural concern can be an idea, notion, Concern Spaces and Views element, property, or any artifact that is of importance to the software architects and which can be classified Architectural Viewpoints according to various dimensions. Architectural concerns An architectural viewpoint defines a particular perspective involve things like data, computation, signal, message, of software architecture that establishes rules and notations communication, synchronization, connector role, etc. In for identifying architectural concerns, grouping these contrast, an architectural dimension is a set of architectural concerns into architectural dimensions and organizing the concerns that can be used to describe a specific aspect of dimensions into one or more concern spaces. The rules software architecture. Each architectural dimension has determine the manner in which concerns are represented in structure and can be considered as a linguistic type that the concern space. Rules are expressed by means of a describes a way of looking at a set of different architectural notation that involves techniques for depicting elements on a particular architectural view. Rules also describe the elements. Examples of architectural dimensions are point for future research work. The concepts described in components, connectors, configurations, etc. the previous section need to be customized and detailed for We proposed in [7], a UML profile for software specific methodologies, projects and organizations. We see architecture description that supports the modeling of these two main fields that need to be clearly considered in dimensions by combining certain architectural concerns. ConcernBASE: For instance, we demonstrated that the component • Conceptual framework issues: characteristics of dimension could be used to encapsulate and combine the architectural abstractions, notation and tools that following four architectural concerns: computation, data, influence composition and decomposition mechanisms signal and messages. and their combination. • Methodological issues: characteristics of the Architectural Views integration of architectural descriptions with other An architectural view is a specific way of presenting a software development artifacts. software architecture description that illustrates some architectural concerns from a particular perspective. Since architectural views are incomplete architecture descriptions REFERENCES that reflect only a subset of a concern space, they 1. Garlan, D.: Software Architecture: A Roadmap. In The Future of Software Engineering; Anthony Finkelstein (Ed). systematically suppress all details of implementation, 22nd International Conference on Software Engineering, algorithm, and low-level data representation. An ICSE 2000; University of Limerick, Ireland, 4-11 June 2000. architectural view is needed to represent one or more 2. Shaw, M., Garlan, D.: Software Architecture - Perspectives architectural dimensions. Therefore, it is a suitable on an Emerging Discipline. Prentice-Hall, New Jersey modularization mechanism that allows us to encapsulate (1996). any kind of software artifact of importance at architecture 3. Bass, L., Clements, P., Kazman, R.: Software Architecture in level. Architectural views can be overlapped, when they Practice. Addison-Wesley (1998). 4. Garlan, D., Monroe, R. T. and Wile, D.: ACME: An represent overlapping dimensions. ConcernBASE also Architecture Description Interchange Lan-guage. allows architectural views to be nested according to the Proceedings of CASCON '97 (1997). rules defined in the concern space. In this case, each nested 5. Medvidovic, N. and Taylor, R. N.: A Classification and view will be considered as a refinement of the outer view. Comparison Framework for Software Architecture This allows developers, for instance, to further manipulate, Description Languages. IEEE Transactions on Software refine and implement various dimensions of concern that Engineering, Vol. 26, No.1, January 2000. 6. IEEE Architecture Working Group: Draft Recommended are represented in a particular architectural view. Practice for Architectural Description (Version 5, October Although it is outside the scope of this paper, the approach 1999). presented here could also be used to cover other phases of 7. Kandé, Mohamed M. and Strohmeier, A.: Towards a UML the software life cycle. Profile for Software Architecture Descriptions. To be published in the UML'2000 Conf. Proc., Stuart Kent and In addition the provision of explicit notations for each of Andy Evans (Eds.), LNCS (2000). the three basic abstractions, ConcernBASE allows us to 8. Kruchten, P. B: The 4+1 view model of architecture. IEEE combine these abstractions to provide some flexible and Software, 12(6):42-50, (1995). 9. ISO/IEC 10746-1/2/3. Reference Model for Open Distributed concern-based mechanisms for the decomposing and Processing – Part 1: Overview/Part2: Foundations/Part3: composing of software architectural structures using any Archictecture. ISO/IEC (1995). modeling language. In our work, we choose to use an 10. Allen, R. J.: A Formal Approach to Software Architecture. extension of the standard UML. Ph.D. Thesis, Carnegie Mellon Univer-sity, School of Computer Science, available as TR# CMU-CS-97-144, May 4 CONCLUSION (1997). 11. Tarr, P., Ossher, H., Harrison, W. and Sutton, S.M. Jr.: "N In this paper, we have discussed the limitations of existing Degrees of Separation: Multi-Dimensional Separation of ADLs relative to the simultaneous separation of concerns. Concerns." Proceedings of the International Conference on We feel that using multidimensional separation of concerns Software Engineering - ICSE'99 (May 1999). in software architecture facilitates the representation of 12. Ossher, H. and Tarr, P.: Multi-Dimensional Separation of software architectures and provides the ability to expose the Concerns using Hyperspaces. IBM Research Report 21452 dimensions along which substantial system properties are (April 1999). expected to evolve, to be understood, represented, 13. Ossher, H. and Tarr, P.: Multi-Dimensional Separation of Concerns and The Hyperspace Approach. In Proceedings of managed, reused and analyzed. Our contribution to the Symposium on Software Architectures and Component supporting multidimensional separation of concerns in Technology: The State of the Art in Software Development. software architecture results in the ConcernBASE Kluwer (2000). (To appear.) approach. This general approach serves as an initial starting 14. Rumbaugh, J., et al.: The Unified Language Modeling Reference Manual. Addison-Wesley (1999). 15. The Unified Modeling Language Specification. Object Management Group (On-line at http://www.omg.org), Framingham, Mas.