The software architecture separates the overall structure of the system, in terms of subsystems and their interfaces, from the internal details of the individual subsystems. A software architecture is structured into subsystems, in which each subsystem should be relatively independent of other subsystems. This chapter presents an overview of software architecture, which is also referred to as a high- level design. The concepts of software architecture and multiple views of a software architecture were first introduced in Chapter 1. The concepts of design patterns, components, and interfaces were introduced in Chapter 4.

In this chapter, Section 12.1 describes the concepts of software architecture and component-based software architecture. Section 12.2 then describes how having multiple views of a software architecture helps with both its design and understanding. Section 12.3 introduces the concept of software architectural patterns as a basis for developing software architectures, whereas Section 12.4 describes how to document such patterns. Section 12.5 describes the concept of software components and interfaces. Finally, Section 12.6 provides an overview of designing software architectures, as described in Chapters 14 through 20.

SOFTWARE ARCHITECTURE AND COMPONENT-BASED SOFTWARE ARCHITECTURE

A software architecture is defined by Bass, Clements, and Kazman (2003) as follows:

State-dependent dynamic interaction modeling deals with situations in which object interactions are state-dependent. State-dependent interactions involve at least one state-dependent control object that, by executing a statechart (as described in Chapter 10), provides the overall control and sequencing of its interactions with other objects.

Chapter 9 describes basic dynamic interaction modeling, which is stateless and, hence, does not involve any state-dependent interactions. During object structuring, the objects that participate in the realization of a use case are determined. If at least one of the objects is a state-dependent control object, then the interaction is defined as state-dependent and the term state-dependent dynamic interaction modeling should be used, as described in this chapter. State-dependent dynamic interaction modeling is a strategy to help determine how objects interact with each other in dynamic interactions involving at least one state-dependent control object. In more complex interactions, it is possible to have more than one state-dependent control object. Each state-dependent control object is defined by means of a statechart.

Section 11.1 describes the steps in state-dependent dynamic interaction modeling. Section 11.2 describes how to model interaction scenarios on interaction (both communication and sequence) diagrams and statecharts. Section 11.3 gives a detailed example of state-dependent dynamic interaction modeling from the Banking System.

This chapter describes how the COMET/UML software modeling and design method is applied to the design of a client/server software architecture (see Chapter 15): a Banking System. In addition, the design of the ATM Client is an example of concurrent software design (see Chapter 18), and the design of the Banking Service is an example of sequential object-oriented software design (see Chapter 14).

The problem description is given in Section 21.1. Section 21.2 describes the use case model for the Banking System. Section 21.3 describes the static model, covering static modeling of both the system context and entity classes. Section 21.4 describes how to structure the system into objects. Section 21.5 describes dynamic modeling, in which interaction diagrams are developed for each of the use cases. Section 21.6 describes the ATM statechart. Sections 21.7 through 21.14 describe the design model for the Banking System.

PROBLEM DESCRIPTION

A bank has several automated teller machines (ATMs) that are geographically distributed and connected via a wide area network to a central server. Each ATM machine has a card reader, a cash dispenser, a keyboard/display, and a receipt printer. By using the ATM machine, a customer can withdraw cash from either a checking or savings account, query the balance of an account, or transfer funds from one account to another. A transaction is initiated when a customer inserts an ATM card into the card reader.

Software quality attributes (Bass, Clements, and Kazman 2003) refer to the nonfunctional requirements of software, which can have a profound effect on the quality of a software product. Many of these attributes can be addressed and evaluated at the time the software architecture is developed. Software quality attributes include maintainability, modifiability, testability, traceability, scalability, reusability, performance, availability, and security. An introduction to software quality attributes is given in Section 4.6. This section describes each of these attributes and discusses how they are supported by the COMET design method.

Some software quality attributes are also system quality attributes because they need both the hardware and software to achieve high quality. Examples of these quality attributes are performance, availability, and security. Other software quality attributes are purely software in nature because they rely entirely on the quality of the software. Examples of these quality attributes are maintainability, modifiability, testability, and traceability.

MAINTAINABILITY

Maintainability is the extent to which software is capable of being changed after deployment. Software may need to be modified for the following reasons:

• Fix remaining errors. These are errors that were not detected during testing of the software prior to deployment.

• Address performance issues. Performance problems may not become apparent until after the software application has been deployed and is operational in the field.

• Changes in software requirements. The biggest reason for software change is changes in software requirements.

The Online Shopping System case study is a highly distributed World Wide Web–based system that provides services for purchasing items such as books or clothes. The solution uses a service-oriented architecture with multiple services; coordinator objects are used to facilitate the integration of the services. In addition, object brokers are used to provide service registration, brokering, and discovery. Services include a catalog service, an inventory service, a customer account service, a delivery order service, an email service, and a credit card authorization service.

The problem is described in Section 22.1. Section 22.2 describes the use case model for the Online Shopping System. Section 22.3 describes the static model, which includes the system context model that depicts the boundary between the system and the external environment. This section also describes the use of broker technology in this system before going on to describe static modeling of the entity classes. Section 22.4 describes how to structure the system into objects. Section 22.5 describes dynamic modeling, in which communication diagrams are developed for each of the use cases. Section 22.6 describes the design model for the system, which is designed as a layered architecture based on the Layers of Abstraction pattern consisting of services and components.

PROBLEM DESCRIPTION

In the Web-based Online Shopping System, customers can request to purchase one or more items from the supplier. The customer provides personal details, such as address and credit card information. This information is stored in a customer account.

The requirements of a system describe what the user expects from the system – in other words, what the system will do for the user. When defining the requirements of a system, the system should be viewed as a black box, so that only the external characteristics of the system are considered. Both functional and nonfunctional requirements need to be considered. Requirements modeling consists of requirements analysis and requirements specification.

Use case modeling is an approach for describing the functional requirements of the system, as described in this chapter. The system's data requirements in terms of the information that needs to be stored by the system are determined using static modeling, as described in Chapter 7. The inputs to the system and the outputs from the system are described initially in the use case models and then specified in more detail during static modeling.

This chapter gives an overview of software requirements analysis and specification in Section 6.1. It then goes on to describe the use case approach to defining functional requirements, as well as how to extend use cases to describe nonfunctional requirements. This chapter describes the concepts of actors and use cases, and then goes on to describe use case relationships, in particular, the include and extend relationships. Section 6.2 gives an overview of use case modeling followed by an example of a simple use case. Section 6.3 then describes actors and their role in use case modeling.

A software product line (SPL) consists of a family of software systems that have some common functionality and some variable functionality (Clements and Northop 2002; Parnas 1979; Weiss and Lai 1999). Software product line engineering involves developing the requirements, architecture, and component implementations for a family of systems, from which products (family members) are derived and configured. The problems of developing individual software systems are scaled upwards when developing SPLs because of the increased complexity due to variability management.

As with single systems, a better understanding of a SPL can be obtained by considering the multiple views, such as requirements models, static models, and dynamic models of the product line. A graphical modeling language such as UML helps in developing, understanding, and communicating the different views. A key view in the multiple views of a SPL is the feature modeling view. The feature model is crucial for managing variability and product derivation because it describes the product line requirements in terms of commonality and variability, and defines the product line dependencies. Furthermore, it is desirable to have a development approach that promotes software evolution, such that original development and subsequent maintenance are both treated using feature-driven evolution.

This chapter gives an overview of designing SPL architectures using the Product Line UML-based Software) engineering (PLUS) method. PLUS builds on the COMET method by considering the added dimension of variability in each of the modeling views. Designing SPLs is covered in considerable detail in the author's book on this topic (Gomaa 2005a).

The Automated Guided Vehicle (AGV) System case study is an example of a real-time system. Taken in conjunction with the other systems with which it interfaces, the Supervisory System and the Display System, it is also an example of a distributed system of systems. The Supervisory System and the Display System are existing systems to which the AGV System must interface.

The problem is described in Section 24.1. Section 24.2 describes the use case model for the AGV System. Section 24.3 describes the static model, which includes the system context model that depicts the boundary between the system and the external environment. Section 24.4 describes the object structuring for the AGV System. Section 24.5 describes dynamic state machine modeling, and Section 24.6 describes dynamic interaction modeling in which communication diagrams are developed for each of the use cases. Section 24.7 describes the design model for the AGV System, which involves the design of a component-based real-time software architecture.

PROBLEM DESCRIPTION

An AGV System has the following characteristics:

A computer-based AGV can move along a track in the factory in a clockwise direction, and start and stop at factory stations. The AGV has the following characteristics:

1. A motor, which is commanded to Start Moving and Stop Moving. The motor sends Started and Stopped responses.

2. An arrival sensor to detect when the AGV has arrived at a station, e.g., arrived at station x. If this is the destination station, the AGV should stop. If it is not the destination station, the AGV should continue moving past the station.

3. […]

Finite state machines are used for modeling the control and sequencing view of a system or object. Many systems, such as real-time systems, are highly state-dependent; that is, their actions depend not only on their inputs but also on what has previously happened in the system. Notations used to define finite state machines are the state transition diagram, statechart, and state transition table. In highly state-dependent systems, these notations can help greatly by providing insight into understanding the complexity of these systems.

In the UML notation, a state transition diagram is referred to as a state machine diagram. The UML state machine diagram notation is based on Harel's statechart notation (Harel 1988; Harel and Politi 1998). In this book, the terms statechart and state machine diagram are used interchangeably. We refer to a traditional state transition diagram, which is not hierarchical, as a flat statechart and use the term hierarchical statechart to refer to the concept of hierarchical state decomposition. A brief overview of the statechart notation is given in Chapter 2 (Section 2.6).

This chapter starts by considering the characteristics of flat statecharts and then describes hierarchical statecharts. To show the benefits of hierarchical statecharts, this chapter starts with the simplest form of flat statechart and gradually shows how it can be improved upon to achieve the full modeling power of hierarchical statecharts. Several examples are given throughout the chapter from two case studies, the Automated Teller Machine and Microwave Oven finite state machines.

A software life cycle is a phased approach to developing software, with specific deliverables and milestones within each phase. A software life cycle model is an abstraction of the software development process, which is convenient to use for planning purposes. This chapter takes a software life cycle perspective on software development. Different software life cycle models (also referred to as software process models), including the spiral model and the Unified Software Development Process, are briefly described and compared. The roles of design verification and validation and of software testing are discussed.

SOFTWARE LIFE CYCLE MODELS

The waterfall model was the earliest software life cycle model to be widely used. This section starts with an overview of the waterfall model. It then outlines alternative software life cycle models that have since been developed to overcome some of the limitations of the waterfall model. These are the throwaway prototyping life cycle model, the incremental development life cycle model (also referred to as evolutionary prototyping), the spiral model, and the Unified Software Development Process.

Waterfall Life Cycle Model

Since the 1960s, the cost of developing software has grown steadily and the cost of developing and purchasing hardware has rapidly decreased. Furthermore, software now typically costs eighty percent of a total project's budget, whereas in the early days of software development, the hardware was by far the largest project cost (Boehm 2006).

Overview of the Organization

Crown Management Systems limited (Crown) was established in 1982 to provide software solutions to the hospitality industry.

The company has developed several generations of software products of which InnMaster, InnTrader, and InnTouch are the most current. These products have been designed to provide a business solution to multiple retailers in the hospitality sector.

Crown's services have been developed over the years so that a full turnkey solution can be offered to new clients, in conjunction with its business partners, including systems, hardware, services, support, and maintenance.

Crown's services also include the provision of outsourcing services. For example, it runs and manages Head Office IT systems for a number of clients. Crown also provides site deployment and training outsourcing for larger clients with hundreds of sites.

Since 1997 Crown has been involved in a European Union (EU) project intended to investigate the benefits of using automated testing tools in software development and testing. The project, sponsored by the EU as part of the European Software Systems Initiative (27), uses the IBM Rational Functional Testing tool (13) with the objective of quantifying the amount of time and effort that can be saved during the testing phase of the software development process. The IBM Rational product was selected over other competitive products due to its wide platform support (including Crown's platforms of choice including Delphi and SQL Server), its reputation as a world leader in software development and testing, and the broad range of functionality and integration offered, above and beyond that of its competitors.

Introduction

This appendix contains a test summary report template, which may be copied and used as the basis of a test summary report for a particular test phase. The purpose of a test summary report is to summarize the result of a particular testing phase and to provide the basis for subsequent improvement of the testing process. An electronic version of the template can be obtained using the following link: http://www.cambridge.org/9780521148016.

As described in Chapter 4 (The Management and Planning of Testing), each testing project must generate a test summary report as one of the documents produced at the conclusion of any given testing phase.

Where text appears within the body of this template in angle brackets (< >), this denotes a place marker, which must be replaced with the appropriate information for a particular testing phase.

Text that appears in italic is provided for information only (such as illustrative examples) and should not appear in the final test summary report.

The principal approach to be used in writing a test summary report is to try to produce a succinct document. Make best use of the supporting information presented in this book (such as the other relevant templates), as well as pertinent material from the appropriate testing phase chapters.

Where the template provided in this appendix does not precisely match the requirements of a particular testing project, the test team leader should obtain an electronic copy of this template and modify it as required.

Overview

The purpose of regression testing is to ensure that the application under test (AUT) still functions correctly following modification or extension of the system (e.g., user enhancements or upgrades). Typically, the new modifications or extensions will be tested to verify that they meet their requirements, after which a series of tests will be run to verify that the existing functionality still meets its requirements.

Regression testing is not strictly speaking a testing phase, but it is a testing technique that can be used with any of the testing phases described in the previous chapters. For example, if a test team were conducting a system test of a new release of the AUT, the test analyst would need to design a number of tests to verify the correctness of the new or modified functionality. In addition to the new tests, the test analyst would select (perhaps from the appropriate reuse pack – see Appendix I) a number of the tests from the previous system test(s) of the AUT in order to determine if any defects had been introduced into the AUT during the implementation of the new functionality.

This section of the book provides a number of real-world examples of organizations that are involved in testing and who have implemented their own testing processes in collaboration with the author. The organizations are:

• The British Library

• Reuters Product Acceptance Group

• Crown Quality Assurance Group

• The Wine Society

• Automatic Data Processing (ADP) Limited

• Confirmit

These case studies are provided to allow the reader to gain some insight into how they might adapt the classic view of the testing process to more closely match their own specific testing requirements. This will be particularly valuable for those readers who have been given the responsibility of setting up a testing process within their own organizations.

Each case study is presented in a standard manner, which follows the order of the testing process material presented in Part 1 of this book. For each case study, the following sections are provided:

• Overview of the organization – providing general information about the organization and the nature of its business

• Characteristics of the testing requirement – describing the particular testing requirements and challenges faced by the organization

• The management and planning of testing – a discussion of how the organization arranges its testing activities and how it plans and manages the testing process

• Roles and responsibilities – describing the testing roles supported by the organization and reviewing their specific responsibilities

• […]

Introduction

This appendix contains a template for a test specification document, guidance on its use, and where appropriate, examples of the typical contents of such a document. This template may be used as the basis of a test specification document for a particular test phase.

An electronic version of this template can be downloaded from the following link: http://www.cambridge.org/9780521148016 (or, assuming the role has been implemented, a copy can be obtained from the testing manager or equivalent role).

As described in Chapter 4 (The Management and Planning of Testing), each testing project must generate a test specification as one of the documents produced prior to commencement of testing activities.

Where text appears within the body of the template in angle brackets (< >), this denotes a place marker, which must be replaced with the appropriate information for a particular testing phase.

Text appearing in italic is provided for information only (such as illustrative examples) and should not appear in the final test specification document.

Where references to “Appendices” appear within this appendix, these refer to other appendices in this book. The term “Annex” is used to refer to supplementary sections within this template.

The principal approach to be used in writing a test specification document is to keep it brief and simple. Make best use of the supporting information presented in this book (such as other relevant template appendices), as well as pertinent material from the appropriate testing phase chapters.