Effective Software Architecture Design: From Global Analysis to UML Descriptions

Robert L. Nord Daniel J. Paulish Dilip Soni Siemens Corporate Research 755 College Road East Princeton, NJ 08540 rnord, dpaulish, dsoni@scr.siemens.com Abstract
It is now generally accepted that separating software architecture into multiple views can help in reducing complexity and in making sound decisions about design trade-offs. Our four views are based on current practice; they are loosely coupled, and address different engineering concerns [1]. This tutorial will teach you how global analysis can improve your design, and how to use UML to describe these views. You will learn: (1) the purpose of having separate software architecture views, (2) the difference between using UML for software architecture and the use of UML for designing OO implementations, (3) how to apply global analysis to analyze factors that influence the architecture and to develop strategies that guide the design, (4) the importance of designing for anticipated change to produce more maintainable architectures, and (5) how to incorporate software architecture design in your software process. This tutorial is aimed at experienced software engineers, architects, and technical managers. It is assumed that participants know the basic UML diagrams. Experience in developing models and software design is helpful.

Christine Hofmeister Lehigh University 19 Memorial Drive West Bethlehem, PA 18015 crh@eecs.lehigh.edu
The purpose of global analysis is to analyze the factors that influence the architecture and to develop strategies for accommodating these factors in the architecture design. Organizational factors such as schedule and budget apply only to the product you are currently designing. Other organizational factors such as organizational attitudes, culture, development site(s) location, and software development process can impact every product developed by your organization. Technological factors limit your design choices by the hardware, software, architecture technology, and standards that are currently available. But technology changes over time and products must adapt, so your architecture should be designed with flexibility in mind. Product factors include features of your product as well as qualities like performance, dependability, security, and cost. These factors may be different in future versions of the product, so your architecture should be designed to support the changes you can reasonably expect. By applying the approach described in this tutorial, we believe that architects can better understand and choose from alternative software architecture designs. You will learn how to document the most influential architectural factors using factor tables, then develop strategies for designing the architecture using issue cards. Design strategies determine the priorities of the architecture and help identify potential risks associated with the implementation of the software system. You will learn the role of global analysis in software architecture design and how to use it to plan for future changes to the product.

1. Global Analysis: Developing Software Architecture Design Strategies

One of the few known certainties when embarking upon the design of a new software system architecture is that the design and its implementation will likely change over time as market requirements, technologies, hardware, and business factors change [3]. Some of these influencing factors impact the entire system, and some directly contradict other factors. In order to avoid major potential rework, these factors must be addressed from the beginning of high-level design. This tutorial shows how the technique of global analysis helps in designing architectures that meet the requirements and tolerate anticipated change.

2. Effective Use of UML for Software Architecture Design

The design strategies documented during global analysis guide the design of the architecture. Although we initially used boxes-and-lines notation to document the four views, we recognized that using a standardized, well-understood notation would be far better. We chose UML because it supports most of what we need to describe [2].

Proceedings of the 23rd International Conference on Software Engineering (ICSE01) 0270-5257/01 $10.00 2001 IEEE

One of our concerns in choosing UML was that it emerged from object-oriented design, so it is most commonly used for high-level and detailed design. This means that some of our architecture concepts are not directly supported by existing UML elements. It also means that our use of UML could create more confusion about the distinction between software architecture and other design activities. But the benefits to be gained by using a standard notation outweigh these concerns. Our use of the UML graphical notation is completely consistent with the current UML standard. We use existing elements and semantics when the fit is close enough, and use our own stereotypes when there is no close match. The conceptual view describes the architecture in terms of domain elements. Here the architect designs the functional features of the system. For example, one common goal is to organize the architecture so that functional features can be added, removed, or modified. This is important for evolution, for supporting a product line, and for reuse across generations of a product. For the conceptual view, we represent components, ports, and connectors as stereotyped classes. Decomposition is shown with nesting (association), and bindings are shown with association. We use: UML Class Diagrams for showing the static configuration. ROOM protocol declarations for showing the protocols that ports adhere to. UML Sequence Diagrams for showing a particular sequence of interactions among a group of components. The module view describes the decomposition of the software and its organization into layers. An important consideration here is limiting the impact of a change in external software or hardware. Another consideration is the focusing of software engineers expertise, in order to increase implementation efficiency. In the module view, we represent modules with a stereotyped class, and subsystems and layers with stereotyped packages. Decomposition is shown by nesting (association), and the use-dependency is a UML dependency. We use: tables for describing the mapping between the conceptual and module views. UML Class Diagrams for showing subsystem and module decomposition. UML Class Diagrams for showing use-dependencies between modules. UML Class Diagrams for showing use-dependencies among layers and the assignment of modules to layers. The execution view is the run-time view of the system: it is the mapping of modules to run-time entities, defining the communication among them, and assigning them to

physical resources. Resource usage and performance are key concerns in the execution view. Decisions such as whether to use a link library or a shared library, or whether to use threads or processes are made here, although these decisions may feed back to the module view and require changes there. For the execution view, we represent the run-time entities as stereotyped classes, and the communication paths as associations. Module containment is shown by nesting (association). We use: UML Class Diagrams for showing the execution configuration. UML Deployment Diagrams for showing how the execution configuration is mapped to hardware. UML Sequence Diagrams for showing the dynamic behavior of a configuration, or the transition between configurations. UML State or Sequence Diagrams for showing the protocol of a communication path. The code view captures how modules and interfaces in the module view are mapped to source files, and how runtime entities in the execution view are mapped to executable files. The partitioning of these files and how they are organized into directories affect the buildability of a system, and become increasingly important when supporting multiple versions or product lines. For the code view, we represent the source and binary components as stereotyped components. Libraries, executables, and code groups are existing UML elements. The generate, import, compile, and link relationships are shown as stereotyped dependencies. We use: UML trace dependency or tables to describe the mapping between elements in the module view and source components. UML instantiation dependency or tables to describe the mapping between run-time entities and executables. UML Component Diagrams or tables for describing the components in the code architecture view, their organization, and their dependencies.

3. References
[1] Christine Hofmeister, Robert Nord, Dilip Soni. Applied Software Architecture. Reading, MA:Addison-Wesley, 2000. [2] Christine Hofmeister, Robert L. Nord, Dilip Soni. "Describing Software Architecture with UML," In Proceedings of the TC2 First Working IFIP Conference on Software Architecture (WICSA1), San Anotonio, Texas, February 22-24, 1999. Kluwer Academic Publishers. [3] Robert L. Nord, Christine Hofmeister, Dilip Soni. "Preparing for Change in the Architecture Design of Large Software Systems," Position paper at the TC2 First Working IFIP Conference on Software Architecture (WICSA1), San Antonio, Texas, February 22-24, 1999.

Proceedings of the 23rd International Conference on Software Engineering (ICSE01) 0270-5257/01 $10.00 2001 IEEE