Introduction

Traditional approaches to defining the targets for testing activities tend to be built on a model of the software as a hierarchy of bits of increasing scale & complexity. For example units forming components forming sub-systems forming systems. Alternatively classes forming sub-systems forming systems.

This approach initially came from single threaded procedural programming systems where one function or procedure calls a number of others and so can be thought of as a higher level assembly - it is closer to doing useful work. With the idea of modularisation this model evolved with higher level assemblies now being collections of functions or procedures sharing data. Even at this point the basic model was starting to suffer from attempting to address an additional less concrete dimension -modularisation as well as a calling hierachy.

This hierarchical model does not provide an adequate tool for systematically defining targets given the complexity of modern software systems. Within a system there are interactions between bits in many domains - implementation inheritance, direct synchronous calling, direct asynchronous calling, indirect interactions via events, message passing and services provided by databases and middleware. Each of these dimensions has a network of interactions which generally do not map onto a hierarchical structure.

An alternative tool is required to allow systematic identification and defining of targets - the approach taken is built on the concept of Service Delivering Assemblies existing within the software.

Service Delivering Assemblies(SDA)

Service Delivering Assemblies provide a coherent service to a user / client or to a community of users / clients. Typically the service will either be provided to entities outside the system - from the system point of view it is an external service - or to other software entities within the system - an internal service. However In some cases the service may be provided to support the interaction of both external entities and internal entities. These arrangements are illustrated below.

Identifying & Defining SDAs

For the purpose of illustrating this process we will use an example of a system. The system is a diary system. To use the diary system a person must have a user account registered in the system. To enable this there is a user account management functionality and it is this that will be used to illustrate Service Delivering Assemblies.

The management of user accounts is done by a supervisor operating the system through an account management window. There is client side logic software that control and drives the operation of this user interface. The client side logic interacts with application server logic that enforces rules about account creation. The application server logic interacts with a database server to maintain a permanent record of user accounts.

Informally there are a number of Service Delivering Assemblies that can be identified from this:

• The overall systems account management service as used by the supervisor including the user interface.
• The operation of all the account management rules contained in the client side logic / application server logic / database. This assembly still provides a service to the supervisor we are just choosing to exclude the operation of the GUI. Focusing on this as an SDA may be attractive for a number of reasons including:
  • Ensuring more effective and disciplined analysis / testing as a result of separating the rules controlling account changes from the detail of the operation of the GUI.
  • Ease of automated testing.
  • Evaluating responses to malfunctions in the GUI itself.
• The rules allocated to the application server logic / database. In this case the direct user / client is the client software with the supervisor being an indirect user. This could be an appropriate SDA because:
  • It serves various types of client, for example local workstation clients or virtual clients operating via a web server.
  • Concurrent usage becomes an issue at this point as the service deals with multiple client connections.
  • The client software is not going to be available in time or is subject to constant change.

Bounding the SDA

The scope of an SDA is defined by two things:

• Details of the services provided by the SDA.
• The interfaces through which the SDA provides access to these services.

Once these are defined the SDA consists of the software involved in delivering the specified services inside the specified interfaces. The SDA boundary identifies both the software involved and the behaviour of that software that is of interest.

The Core SDA Software

The core service specific elements of each of the example SDAs are shown in the diagrams below. The filled circles denote the concrete interface points that bound the SDA. The service behaviour is judged as the responses to specific external use at the points as seen in outputs from the SDA at these points. The clear circles denote the interfaces of the direct and indirect uses / clients. It is these clients that determine patterns of usage and that the SDA must interact.

Overall Account Management Service Provided By the System

Account Management Functionality Excluding GUI

Server Hosted Account Management Service

The diagrams show the boundaries and core software of the SDA. The boundaries are defined by the concrete interfaces. The interfaces are the points at which the SDA interacts with the outside world where the interaction forms part of a service interaction with a client / user. The core software is the software that has behaviours / features provided specifically to implement the service.

The Full Service Delivering Assembly

The Service Delivery Assembly is not restricted to the core software. The full SDA is considered to be all of the software that executes within the SDA boundary and all of the services used whether provided as part of the system, operating system or some other source. In the extreme case this could include the use of external servers used as part of delivering the service - for example credit card validation as part of order processing. Simplistically the full SDA is consists of everything that the operation of the service depends on.

In any complex system this will be a vast amount of software and in reality the process does not involve explicitly identifying all of the software. Rather key support software / services are identified. Generally the core software interacts with these directly and they provide non trivial functionality or have complex usage protocols.

The diagram below illustrates key support software associated with one of the example SDAs from above. This expanded SDA example will be used as the basis for subsequent illustrations.

Using Service Delivering Assemblies

Generally an SDA is a useful SDA if it is used in the definition of some assurance activity. The reverse of this is that if it is not possible to create an SDA as the basis of some envisaged assurance activity then the activity itself may be flawed and lacking in coherence.

The concept of the SDA aims to be applicable at all scales within a software system.  Examples of using SDAs include:

• At the lowest level focusing on a numeric function that takes a data set and returns a numeric value derived from it. It provides a service - the analysis of the data, it has an interface - its runtime call interface. The SDA consists of all software that operates to deliver the analysis once the function is called. At this level the SDA can be used as the basis for defining 'Unit level' assurance and testing activities.
• Focusing assurance on a class. The service is the class behaviour and the interface the methods provided to access the class. The SDA consists of the class any inherited implementation and all the software that is invoked.
• A focus on the infrastructure providing client application layer to server application layer communication. The interfaces are the APIs used by client and server application layer software, the service is the communication management and data transfer provided between them. The SDA encompasses all of the software involved in this.

Used as the basis of Assurance Targets SDAs can clearly identify any scope of software / behaviour as the focus of a testing activity. The definitions provide a common approach and format that can cover all of the more common types of definition such as 'unit', 'component', 'module' and 'sub-system' and at the same time provide a more definitive clearer method of communicating exactly what is included and what is not.