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