3 Software Architecture

Transcription

1 Software Architecture and Software Configuration Management Bernhard Westfechtel, Aachen Reidar Conradi, Trondheim Abstract This paper examines the relations between software architecture and software configuration management. These disciplines overlap because they are both concerned with the structure of a software system being described in terms of components and relationships. On the other hand, they differ with respect to their focus (specific support for programming-in-the-large versus general support for the management of software objects throughout the whole life cycle). Several problems and alternatives concerning the integration of both worlds are discussed. 1 Introduction Software architectures play a central role in the development and maintenance of a software system. A software architecture description defines the structure (high-level design) of a software system in terms of components and relationships. It describes the interfaces between components and serves as the blueprint of the system to be implemented. It can be used for generating implementations (complete ones or frames to be filled in by programmers), make files to drive system building, overall test plans, etc. Software configuration management (SCM) is the discipline of managing the evolution of complex software systems. To this end, an SCM system provides version and configuration control for all software objects created throughout the software life cycle. In addition, it supports system building (creation of derived objects from their sources), release management, and change control. These disciplines overlap considerably. In particular, both software architectures and software configurations describe the structure of a software system at a coarse level. Detailed address: Lehrstuhl für Informatik III, RWTH Aachen, D Aachen. Phone: , Fax: , bernhard@i3.informatik.rwth-aachen.de. This work was partially carried out during a research stay at NTNU. Support from NTNU is gratefully acknowledged. Detailed address: Norwegian University of Science and Technology (NTNU), N-7034 Trondheim, Norway. Phone: , Fax: , Reidar.Conradi@idi.ntnu.no. On the other hand, they differ with respect to their focus (specific support for programming-in-the-large versus general support to manage software objects throughout the whole life cycle). In this paper, we examine the relation between software architecture and SCM 1. Section 2 takes a brief look at the software process. Sections 3 and 4 discuss software architecture and softeware configuration management (SCM), respectively. Section 5 investigates the relation between software architecture and SCM. Finally, some conclusions are drawn in Section 6. 2 Software Process There is a great variety of software processes. We will here make some brief, general observations on the relation between software architecture and SCM. Software processes are often organized into phases which group logically related activities [12]. However, the notion of phase does not imply a strict, temporal order. Unlike the waterfall model, current software processes and in particular those for component-based development are highly incremental. Therefore, we will try to avoid the notion of phase in the following. There are many ways of decomposing the software process into phased activities, such as requirements engineering, programming-in-the-large (design), and programmingin-the-small (coding). There are also cross-phase activities, such as quality assurance and software configuration management. Figure 1 depicts a simplified view of the software process. The roles of SCM and software architecture and their mutual relation may be characterized as follows: 1 This topic is also addressed in [18], however, with different conclusions. SCM supports the management of software objects throughout the whole lifecycle. This includes requirements specifications, software designs, source code, test data, project plans, etc. That is, the software architecture descriptions is just one of the documents managed by SCM.

2 3 Software Architecture Figure 1. Software process (simplified view) SCM provides general services such as version and configuration control, that all kinds of software tools may use. In this way, the same services need not be implemented over and over again, and they are offered in an application-independent way. Software architecture is concerned with the high-level design of a software system. In contrast to SCM, design is primarily concerned with technical and creative tasks. Since the software architecture description defines the overall organization of the software system, it serves as a central document which can be used for prioritizing requirements or organizing programming and testing tasks. There is also an overlap with SCM concerning software configuration descriptions and their system models. However, the scope is software architecture is confined to programming-in-the-large. In contrast, software configurations cover the whole software lifecycle. Even though the software architecture plays a central role, it enters the scene only after requirements engineering. Therefore, an overly architecture-centered perspective would neglect the importance of requirements engineering. Particularly for incremental software processes, consistency throughout the software lifecycle has to be maintained. When the requirements are changed, the software architecture has to be modified accordingly. This requires support for traceability over the whole lifecycle, and which should be assisted by SCM. The perpetual negotiation between requirements, architectural design and available COTS products implies that the scope of architectural considerations must be widened in both ends. Although not being a new invention, the discipline of software architecture has recently attracted much attention [8]. A software architecture description outlines the organization of a software system. The creation of software architectures (in some notation) is commonly referred to as architectural design, which is a part of programming-in-thelarge. The software architecture plays a central role in the software process: It can be used to organize implementation and test activities and to structure the repository of software objects. However, this works only to a limited extent. In particular, software processes are driven by the requirements stated by the customer. The software architecture depends on the requirements definition, which is important to manage customer relationships. It also depends on the availability and assessment of COTS components, as mentioned before. A wide variety of languages have been proposed and used for describing software architectures, including module interconnection languages, architecture description languages, and object-oriented modeling languages. These languages vary considerably with respect to their underlying syntax and semantics. Module interconnection languages [13] describe software architectures in terms of modules and their export and import interfaces. Modules may be composed into subsystems. Some module interconnection languages also support version control. Object-oriented modeling languages such as e.g. the UML [1] are based on classes which are organized into inheritance hierarchies and are connected by associations. Classes may be grouped into packages, which are similar to subsystems. In addition to the static composition of a software system, OO modeling languages usually provide constructs for defining behavior, e.g., by state diagrams. Architecture description languages [14, 2, 11] deal with components rather than modules, implying a potentially coarser granularity. Components have interfaces and are related by connectors, which are often treated as first-class objects. In addition to a syntactic description, there are some languages which describe the semantics of components and connectors, e.g., by drawing upon specification languages such as CSP and Z. In general, languages for defining software architectures offer rich facilities for expressing system structure (components, dependencies, interfaces), but they are less powerful with respect to system evolution. That is, version control is beyond the scope of most of these languages (note, however, e.g. [19]). With respect to version control, we may further distinguish between revisions and variants (temporal versions and co-existing alternatives, respectively). 2

3 Even if version control is not addressed explicitly, it may be supported implicitly. Architectural design strives for reusability, and often tries to anticipate changes in the requirements. Architectural languages therefore provide mechanisms to improve reusability and to handle anticipated evolution. These mechanisms effectively introduce different kinds of variants: Genericity. All instances of a generic (parameterized) class may be considered variants, differing with respect to the actual generic parameters (e.g., stacks of integers, booleans, etc.). Inheritance. All subclasses may be seen as variants of a common superclass, defining the common parts of their interfaces and implementations. Interfaces and realizations. For a given interface, there may be multiple realization variants or several contributing realizations. Likewise, the same realization may offer alternative interfaces, e.g. private, group, or public. This kind of version control is characterized as follows: Usually, architectural languages deal only with variants. They do not address revision control (note, however, the work reported in [19]). Variant control is performed on a semantic level. For example, all realizations of a module may be required to implement the same interface. All of these variants must be represented in the software architecture description, so that the designer may select among them. As a common example, consider a library of data structures offering different variants of sets, bags, lists, etc. However, these mechanisms alone are not sufficient to deal with architectural evolution. In particular, they do not take unplanned evolution into account. Unplanned evolution cannot be handled solely within the software architecture. In addition, we require support for evolution of the architecture as a whole (see Section 5). 4 Software configuration management SCM [16] is concerned with the management of all software objects (artifacts, documents) created throughout the software lifecycle. This includes requirements definitions, software architecture descriptions, implementations, test plans, test data, project plans, etc. These are arranged into software configurations by means of various kinds of relationships such as hierarchies and dependencies, and supplemented by version rules (see below). Software configurations cover the whole lifecycle. In particular, they go beyond programming-in-the-large. From the SCM perspective, the software architecture description has to be managed like any other document. In particular, the relationships between the requirements definition and the software architecture description have to be maintained. Generally, SCM has to support traceability over the whole lifecycle. In order to provide services applicable to a wide range of applications, SCM systems usually abstract from the contents of software objects (black boxes seen from the SCM system). Software objects are treated as raw text files or binary files. It is up to the application-specific software tools or humans to interpret the contents of software objects. Due to this abstraction, SCM systems can be applied even outside the software engineering domain. An important service provided by an SCM system is version control. Version control is offered as a general service so that applications need not take care of it by themselves. Many different version models have been proposed [3]. Commercial systems are usually based on version graphs that are organized into branches each of which consists of a sequence of revisions. To ensure consistent selections of versions over a large set of software objects, the user may define version rules. These rules are evaluated and serve as filters to establish a uni-version workspace (corresponding to a bound configuration) in which normal software tools can operate. The software tools are thus shielded from versioning, i.e., they are not aware of the versions they are working on. Thus, version control in SCM systems may be characterized as follows: It deals with arbitrary software objects. It covers both revisions and variants. Versions do not have deep semantics. In general, versions may differ in arbitrary ways. Thus, SCM may support any kind of evolution, whether planned or ad-hoc. It simply does not make any assumption about the kinds of changes performed and later recorded. To shield software tools from versioning, SCM systems establish a uni-version workspace. Even though SCM covers the whole software lifecycle, a great deal of the functionality of an SCM system is dedicated to implementation-related tasks. In addition to providing a repository for versioned source files, this includes build tools for creating derived objects such as compiled and linked programs. These build tools can be driven by make files [6] that define the dependencies between source and derived objects and the build actions such as compile and link 3

4 steps. The dependencies in the make files represent structural information relevant for the software architecture, but this is done at a low level of abstraction. Make files are often derived from source text and are therefore not usable as high-level descriptions, which architecture description languages intend to provide. System models are better suited for this purpose. A system model defines the components of a system, as well as their relationships. A system model is usually described at the level of source objects, but it may also contain rules for producing the derived objects. In the following we focus on source objects. System models can either be expressed in some system modeling language, or they can be represented by objects and relationships in the repository underlying the SCM system. In the context of this paper, it is important to distinguish between two kinds of system modeling approaches: System models dealing with design (and implementation) objects. Examples include e.g. Intercol [15], Adele [4], and PCL [17]. Systems are described in terms of modules, export and import interfaces, subsystems, etc. These system modeling approaches compete with architectural languages. Compared to these, they are less expressive with respect to system composition and consistency. On the other hand, they go beyond architectural languages with respect to version control. System models dealing with arbitrary software objects. These models are used to represent software configurations throughout the whole software lifecycle. Examples include Jasmine [10] and DSEE [9]. Such system modeling approaches are very general, i.e., they do not make any assumptions with respect to the software objects and relationships making up a software configuration. They could even be applied to hardware components. 5 Software Architecture vs. SCM Table 1 summarizes the relation between software architecture and SCM as discussed so far. In the sequel, we present seven theses to characterize this relation. Thesis 1 Architectural design vs. the whole lifecycle: Software architecture and SCM overlap since they both deal with the overall organization of a software system. However, while software architecture refers to programming-inthe-large, SCM addresses the whole software lifecycle (and can even be applied outside the software domain). This has been illustrated in Figure 1. While there is a region of overlap, there are also disjoint regions. Architectural languages provide more high-level support for system composition and consistency. On the other hand, SCM also deals with non-design objects (requirements definitions, test plans, project plans, documentations, etc.) and offers version control, which is only partly covered by software architecture. As a consequence of this observation, we confine the notion of software architecture to programming-in-the-large and do not extend it to other phases. In contrast, the term software configuration applies to all kinds of software objects and their relationships. Thesis 2 Tool integration bottom-up or top-down: The relation between software architecture and SCM can be studied under different assumptions concerning tool integration. It makes a big difference whether we assume bottom-up integration or top-down integration. Bottom-up integration means that existing tools are integrated after the fact (tool-kit approach, integration of legacy systems). Since vendors of SCM systems usually strive for reusability, they make no assumptions concerning the tools to be integrated with the SCM system. Vice versa, the vendors of application tools usually do not want to become dependent on a specific SCM system (this independence may be achieved e.g. by a virtual workspace). This is illustrated in Figure 2. Figure 2. Bottom-up integration In the case of top-down integration, new tools are designed and implemented as a whole, resulting in a tightly integrated software engineering environment [12]. Ideally, tools have a uniform user interface, use the same database, etc. In this case, there is only a single design tool, a single SCM system, etc., all being part of the overall environment. While this is a viable approach as well (for a single vendor), we assume bottom-up integration in the following because it seems to be more relevant for designers of SCM systems. Thesis 3 Different system description languages: Since there are many architectural description languages with different syntax and semantics, an SCM system system must not prescribe a specific language for describing software 4

5 software architecture SCM coverage programming-in-the-large (high-level design whole lifecycle software objects components, modules, classes,... all kinds of software objects relationships inheritance, import, port connections,... all kinds of relationships semantic level high (syntactic or semantic consistency) fairly low granularity overall organization, but also detailed interface descriptions overall organization (software objects as black boxes) versions variants variants and revisions version selection usually hard-wired rule-based Table 1. Comparison of software architecture and SCM architectures. In contrast, the software architecture description has to be handled like any other document. Some SCM systems offer a module interconnection language to describe software architectures. However, using such a language enforces a specific way of modeling software architectures. Given the wide variety of architectural languages, we must conclude that architecture modeling is application-specific. Thus, a system modeling language offered by an SCM system should be considered as a poor man s architecture description language. That is, the user can adopt that language as an option in the absence of a full-fledged architecture description language. This lesson has been learned e.g. in Adele. Adele I [4] offered a predefined module interconnection language derived from Intercol [15]. This made it difficult to model non-design objects, and it forced the user to adopt the predefined language for programming-in-the-large. For example, even a simple textual document was required to have an interface and a body. In Adele II [5], there is a predefined system model that the user may or may not use. In addition, the user may define any desired system model for organizing software objects. Thesis 4 Unavoidable redundancy in system descriptions: Under the constraints of bottom-up integration, there is no hope to unify software architectures and software configurations in the sense that only a single, integrated description needs to be maintained. A certain amount of redundancy is therefore inevitable. In [18], it is (correctly) argued that multiple descriptions of the software architectures result in redundancy and increased modeling support. However, the vision of an integrated approach assumes top-down integration. That is, a new system is built where the notions of software architecture and software configuration are unified from the beginning. A user of such a system would have to commit to this conceptual world. Mostly, however, there are constraints concerning the notations and tools used throughout the software lifecycle. For example, if a company adopts UML, there is not a free choice of the basic architectural language any more. Thus, a system giving unified, but built-in support for software architectures and software configurations will not qualify for being used in that company. In short: Redundancy is bad, but we must live with it. To cope with redundancy, tools are required which extract the overall organization of a software system from the software architecture into a (part of) a software configuration model. Vice versa, we may propagate the structural information contained in a software configuration model into a software architecture description. In general, incremental tools are required which perform transformations in both directions and assist in keeping software architectures and software configurations consistent with each other. Note the analogy with trying to keep architectural descriptions, UML diagrams, make files, program code, documentation, test data etc. etc. consistent with each other. The world is simply not consistent or unified! Thesis 5 Planned evolution is easy: Architectural design deals with architectural evolution at a semantic level. In particular, variants can be represented within the software architecture description (as realization variants, subclasses, or instances of generic modules). In this way, planned evolution may be taken care of. That is, to some extent version control is supported within the software architecture description. Architectural design attempts to ensure that software architectures are reusable, and that they remain stable even under changing requirements. For example, we may define a neutral file system interface which can be mapped onto different actual file systems, confining platform changes to a single spot in the architecture. Or we may build up class hierarchies which may be extended with subclasses on demand, e.g., when a new variant of some data structure is offered to client programmers. However, reusable components are discovered, not planned ahead (Ralph Johnson in [7]). For instance, how to design stable and functional class hierarchies in the first attempt? 5

6 Thesis 6 Unplanned evolution is hard: SCM offers general version control services for all kinds of applications. These address not only variants, but also revisions. Version control is performed at a fairly low semantic level. The SCM system deals with versioning of the architecture, covering in particular unplanned evolution. Thus, software architecture descriptions are placed under version control, like all other software objects. If a software architecture description is composed of multiple software objects (the usual case), configuration control is also required. Version control provided by an SCM system can be used e.g. to handle change requests that imply architectural restructuring, to maintain competing architectural variants for the purpose of comparison and evaluation, to handle concurrent changes (e.g., fixes in an old release while the new release is being developed on the main branch), etc. Thesis 7 Evolution at different abstraction levels: Altogether, the evolution of software architectures has to be dealt with at two levels: structured version control within the architecture (planned changes) and unstructured version control of the architecture (unplanned changes). These two levels complement each other and cannot be unified easily. We may further characterize the two levels as follows: At the architectural level, we may deal with semantic changes and planned evolution. Interfaces, inheritance, genericity, etc. have a well-defined meaning. Therefore, evolution cannot be delegated to an SCM system which treats software objects as black boxes. In addition, we may have to use multiple variants simultaneously, while the user of an SCM system has to pre-select one version to work on. At the SCM level, we handle global changes of any kind (in particular, unplanned evolution). Handling these changes at the architectural level would defeat the very purpose of an SCM system: to relieve software tools from tasks which can be taken care of by general services. For example, version and configuration control would have to be rebuilt in an architectural design tool. Moreover, there would be no way of keeping track of global changes throughout the software lifecycle. Such version control on different levels is quite common. Consider e.g. C program files with conditional compilation statements placed under version control tools such as SCCS or RCS. 6 Conclusion In this paper we have examined the relation between software architecture and SCM. One of our main conclusions is that architectural design should be left to the architects. That is, an SCM system should provide general support for software configurations of arbitrary software objects, but it should not compete with architectural description languages. Similarly, architectural designs should be placed under version control like other software objects. If the software architecture is distributed over multiple documents, a configuration of these architecture documents constitutes a part of the overall software configuration covering the whole lifecycle. On the other hand, we should confine the scope of software architecture as well. Since the software architecture plays a central role in the software process, the vision of an architecture-centered process is quite tempting. In such a process, the software architecture is used as a skeleton for organizing software objects. Users employ the software architecture as the central structure for requirements negotiation, browsing, generation of implementation frames and test plans, etc. However, the total software process can only be partially covered this way, especially for incremental development models. We may rather argue that a software process should be requirements-centered (or user-centered). That is, requirements coming from the user should drive the process. Likewise, we have to consider the functionality, availability and risks of reusable COTS modules with possibly unknown internal structure as part of architectural design and associated requirements negotiation. Thus many non-design objects and relationships must be considered in the architecture phase. Likewise, a SCM system has to manage software objects created in all lifecycle phases, and it also should support traceability from the initial or negotiated requirements to the finally delivered code. References [1] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison Wesley, Reading, Massachusetts, [2] P. C. Clements. A survey of architecture description languages. In Eigth International Workshop on Software Specification and Design, Mar [3] R. Conradi and B. Westfechtel. Version models for software configuration management. ACM Computing Surveys, 30(2): , June [4] J. Estublier. A configuration manager: The Adele data base of programs. In Proc. Workshop on Software Engineering Environments for Programming-in-the-Large, pages , Harwichport, Massachusetts, June

7 [5] J. Estublier and R. Casallas. The Adele configuration manager. In W. F. Tichy, editor, Configuration Management, volume 2 of Trends in Software, pages John Wiley & Sons, New York, [6] S. I. Feldman. Make A program for maintaining computer programs. Software Practice and Experience, 9(4): , Apr [7] E. Gamma, R. Johnson, R. Helm, and J. Vlissides. Design Patterns Elements of Reusable Object-Oriented Software. Addison Wesley. 416 p, [8] D. Garlan and M. Shaw. An introduction to software architecture. In V. Ambriola and G. Tortora, editors, Advances in Software Engineering and Knowledge Engineering. World Scientific, Singapore, [9] D. B. Leblang and G. D. McLean. Configuration management for large-scale software development efforts. In Proc. Workshop on Software Engineering Environments for Programming-in-the-Large, pages , Harwichport, Massachusetts, June [10] K. Marzullo and D. Wiebe. Jasmine: A software system modelling facility. In Proc. ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, ACM SIGPLAN Notices 22(1), pages , Palo Alto, California, Dec [11] N. Medvidovic and R. Taylor. A framework for classifying and comparing architecture description languages. In Proc. 6th European Software Engineering Conference, LNCS 1301, pages Springer Verlag, Sept [12] M. Nagl, editor. Building Tightly-Integrated Software Development Environments: The IPSEN Approach. LNCS Springer Verlag, Berlin, Germany, [13] R. Prieto-Diaz and J. Neighbors. Module interconnection languages. Journal of Systems and Software, 6(4): , Nov [14] M. Shaw and D. Garlan. Formulations and formalisms in software architecture. In J. van Leeuwen, editor, Computer Science Today Recent Trends and Developments, LNCS 1000, pages Springer Verlag, Heidelberg, [15] W. F. Tichy. Software development control based on module interconnection. In Proc. IEEE 4th International Conference on Software Engineering, pages 29 41, Pittsburgh, PA, Sept IEEE Computer Society Press. [16] W. F. Tichy. Tools for software configuration management. In J. F. H. Winkler, editor, Proc. International Workshop on Software Version and Configuration Control, pages 1 20, Grassau, Germany, Teubner Verlag. [17] E. Tryggeseth, B. Gulla, and R. Conradi. Modelling systems with variability using the PROTEUS configuration language. In J. Estublier, editor, Software Configuration Management: Selected Papers SCM-4 and SCM-5, LNCS 1005, pages , Seattle, Washington, Apr Springer Verlag. [18] A. van der Hoek, D. Heimbigner, and A. L. Wolf. Software architecture, configuration management, and configuration distributed systems: A menage a trois. Technical Report CU-CS , University of Boulder, Colorado, Jan [19] A. van der Hoek, D. Heimbigner, and A. L. Wolf. Capturing architectural configurability: Variants, options, and evolution. Technical Report CU-CS , University of Boulder, Colorado, Dec