This chapter gives a thorough description of the different models in the system design activity and some guidelines on how to create these models. A recommendation on consistency rules that are relevant for the models in this activity as well as for the consistency between models from previous activities and this activity, is also included.
The chapter requires that you are at least reasonable familiar with SDL.
One of the most important issues of software development, if not the most important of all, is to define the architecture of the system. Define how the system is built up of smaller parts that in turn may be composed of even smaller parts until each part is manageable by itself. The architecture is proposed in the system analysis architecture but the precise definition of this structure is the major task of the system design activity.
The components of a system may have several different important functions to fulfill:
The major inputs to the system design activity are the analysis object model and the analysis use case model produced in the system analysis activity. The system design is the process that based on these inputs define in detail how the system is decomposed into components and to define the interfaces between the different parts. This is illustrated in Figure 44 that also shows the three major artifacts developed in the system design; the design module structure, the architecture definition and the design use case model. In addition to these formalized descriptions there is often a need to specify non-functional aspects of the components in a textual design documentation.
Figure 44 : Inputs and outputs of the System Design activity
|
|
The architecture is in the system design formalized primarily using SDL. In SDL the major structuring concept is the block and the notation is the block diagram. Seen from an object-oriented point of view a block is a container of objects. The block can either be directly described by the objects that it contains or it is decomposed into lower level blocks. The block structuring mechanism is discussed more in Architecture Definition.
Where the logical architecture defines the decomposition of logical functionality the design module structure defines the decomposition into work items. It defines the different modules the design teams can start working on and also provides a mapping from the logical architecture to design modules. In SDL the design modules are usually SDL packages. The design module structure also takes a slightly broader perspective of the system to be built and describes how existing frameworks, tools and components are incorporated into the development structure.
The deployment description is a way to describe the physical distribution structure of the SDL system. It is also the place where the implementation strategy for different parts of the system can be described.
There should be a simple (if possible one-to-one) mapping between the top levels of the architecture definition and some of the modules in the design module structure. The benefit gained from a simple mapping is that the design modules define the possibilities to divide the work on different development teams and the logical blocks comprise well-defined sets of functionality and responsibilities. If they do not map to each other there is an obvious risk for complex interfaces between the development teams.
As always when a system is decomposed into smaller parts one very important issue is how the interface between the parts are defined. In particular if the components are used as division of work load and designed by different development teams the interface definition is the means to communicate between the different groups and a common understanding of the interface is crucial. There are two aspects of the interface:
Both aspects are important and the definition of them is a vital part of the system design activity.
In SOMT the major concepts used to define the static interface are the SDL concepts signals and remote procedures, and the dynamic aspect is a continued usage of use cases. However, since there very often is a need to design parts of a system using other techniques than SDL or to use existing modules, other interface definitions techniques like CORBA/IDL are also used in SOMT.
The major tasks to be performed in system design in an SDL based project can thus essentially be summarized as the following:
There is, as we will see in Object Design, a close relation between the system design activity and the object design activity in the sense that the object design activity is concerned with the representation and behavior of the objects and the system design deals with the distribution of the objects into blocks and defining the communication paths between the objects.
The rest of this chapter will discuss the system design activity. SDL will frequently be used to define the architecture and interfaces and examples of SDL diagrams will be used throughout the chapter. A complete presentation of the SDL language is however outside the scope of this document. For more information, please consult either the Z.100 standard itself [7], or a text book about SDL like [11].
When using SDL to design a system the architecture of the system is defined by the block diagrams. They define how the system is decomposed into blocks and how these blocks either form the leaves of the block hierarchy or are further decomposed into smaller blocks. Essentially this block structure is a formalization of the logical architecture from the system analysis.
As an example, consider once again the access control system. The system controls the doors of a building to unlock the doors when an authorized user wants to enter or exit the building. The task in system design is to define how to structure this system. One natural choice is a distributed structure where the control of each door is localized close to the door and a central controller keeps all common information about authorized users, cards and codes. Furthermore one special block is responsible for the handling of an operator panel. A logical architecture that described this was illustrated in Figure 38 in System Analysis. The SDL diagram that shows a beginning of a formalization of this architecture is depicted in Figure 45.
Figure 45 :
The architecture of the Access Control system defined
by an (incomplete) SDL system diagram
|
|
In this diagram we can see the blocks CentralC, Door and OperatorC that are instances of the block types CentralCtrl, DoorCtrl and OperatorCtrl. CentralC contains the common information base about cards, codes etc. that are registered in the system. Door is the block responsible for the control of each door and OperatorC handles the operator communication. The diagram also shows how the blocks communicate using the channels DoorCh and OperatorCh. Note that there are five doors in the building in this case and that this is shown by defining Door to be a block instance set. The types DoorCtrl, CentralCtrl and OperatorCtrl are assumed to be defined in the packages BasicOperation and OperatorMan that are referenced in the USE clause in the top of the diagram.
The purpose of the design module structure is to show the actual components the application will be built from. The module structure should depict the actual source code modules etc. that the application will contain. A number of different aspects must be taken into account when defining the module structure:
Especially the reuse of existing architectural frameworks is very common and very beneficial. Most applications are not built from scratch, they are rather extensions/modifications of old applications and the design module structure is the place to show how this is done.
One notation that can be used in SOMT to describe the design module structure is object model instance diagrams, where the instances represent the different modules. Where relevant, the attribute field can be used to show what components of the logical architecture are contained in the modules. As an example consider a typical SDL application running on a small microprocessor where a proprietary real-time operating system is used. A possible module structure is shown in Figure 46.
Figure 46 :
The module structure of the Access Control system using
an in-house real time operating system
|
|
In this example the top-level of the application is described in the SDL system AccessAppl which is defined using the types defined in the packages BasicOperation and OperatorMan, both of which uses common types defined in the UtilityTypes package. The application will run on the already existing real time operating system MyRTOS. To make the C code generated from the SDL system run on MyRTOS a C code module Adaptation is used that defines the necessary interfaces.
In this example it is very likely that some of the modules will be developed within the project (the AccessAppl and the modules it uses) while others are already existing (like the real time operating system) and some can be taken from previous projects and be modified to fit the current project (like the Adaptation module).
The most important aspect of the module structure is that it forms the basis for dividing the work load on different development teams. This is in many cases the major reason to decompose the system into design modules. However, another reason may be the issue of reuse.
The design for reuse can in this context be viewed as an activity that defines the design module structure based on other premises than the architecture as discussed so far in this chapter. Consider for example the access control system decomposed as in Figure 45, where the system is divided into three different parts according to essentially the physical distribution that is needed in the application. There may in this example exist concepts that can be used in more than one of the subsystems. Examples may include knowledge about some passive data structure, like the concept of a card, but also entire functionalities like the concept of time seen as a clock functionality.
The identification of these type of components is also a task of the system design. It is particularly important if the different subsystems are to be designed by different design teams. It is also important to identify common components to avoid duplicate work and lower the complexity of the individual subsystems.
The concept that is used to describe the different modules is the package. A package is essentially a container of SDL types, this may range from system types and block types over process types down to signals and data types. When a package is used by an SDL system the types defined in the package can be referenced from within the SDL system. For example, in the access control system we may decide that we need a package UtilityTypes (as in Figure 46) that defines the common data types needed in the different subsystems.
Another issue that needs to be handled in the system design is to analyze the consequences of the requirements on different configurations of the system. Are there any optional parts or functionality? In many cases the optional parts are captured by different modules in the system structure, but sometimes, like if there would be an optional requirements on a synchronized clock in all parts of the access control system, it is distributed over the different blocks in the system. If this is the case a package is the most useful concept to use to encapsulate the optional feature.
The discussion so far has been about reuse within one development project focused on one specific application. There is however also the issue of reuse outside the local project. When using an object-oriented approach to the analysis and design the objects tend to be fairly general and applicable in more than one project. If the objects in a particular part of the system are defined as types in a package this will form a good foundation for reusing the objects in future projects. This implies that there may be a reason to use a package structure that is different from the block structure of the system. The package structure reflects the decomposition into packages as defined by the possibility for reuse while the block structure defines the current system structure.
The purpose of the deployment description is to define the physical distribution of the application and also define the practical details on how to build the different parts.
The specific objectives for a deployment description might vary during different activities: during design we are more concerned on describing on how to verify or validate the design, i.e. how to simulate the design in different ways, while in later activities it is desired to specify the final application build process for the application structure. It is therefor possible to have several deployment descriptions for one system.
There is a textual format for defining a deployment description -- for more information, see Build Scripts.
Example of a textual deployment description, i.e. build script:
set-kernel SCTAAPPLCLENV set-env-header on program UserPart component system AccessControl / block LocalStation make-template-file UserMake.tpm generate-micro-c program CentralPart component system AccessControl / block CentralUnit make-template-file CentralMake.tpm generate-advanced-c
SDL offers two major means to define the interfaces of a block:
When signals are used to define the interface to a block they define the communication items that can be sent to and from the block. A signal can represent a service to be carried and it contains all relevant data that is associated with the request. A useful way to structure the signals if one particular interface contains many signals is to define signal lists that group together related signals. Consider the CentralCtrl block above. This block has two interfaces, one to the Door blocks and one to the OperatorCtrl block. The interface to the Door blocks can in SDL be defined as in Figure 47.
Figure 47 : An interface definition using signals
|
|
When using signals to define the interface of a block we do not put any constraints on the execution strategies in the respective blocks, we only define the data that is transported. However, in some cases, especially when using a client-server based architecture, it is more convenient to define the interface using remote procedures instead of signals. As an example consider once more the CentralCtrl block. The major responsibility of this block is to store the cards with their associated code. Some possible operations on this data is to check weather a particular card is registered and what the code for a particular card is. A remote procedure definition of these operations is depicted in Figure 48.
Figure 48 : An interface definition using remote procedures
|
|
In addition to the signals/remote procedures that are used to define the interfaces in SDL there is of course also a need to define the data types that are visible in the interface. This issue is to a large extent the same as the issue of mapping passive objects to SDL data types. This is treated in more detail in section Mapping a Passive Object.
When mapping object model concepts to SDL there are two aspects that need to be taken care of:
In SOMT this implies that an analysis object is seen to have two different descriptions in the design model, one description of the interface and one description of the object itself. In the system design the focus is on the interface definition so we will save the mapping from object models to SDL object definitions until the next chapter ( Object Design). However, defining the relation between the object model concepts and the interfaces between the components of the system is a very relevant issue for this section.
Since the basic mechanism in SOMT to go from analysis to design is using the Paste-As mechanism (see Implinks and the Paste As Concept) this is of course also used when defining the interfaces. As seen in the previous section interface definitions in SDL are defined using signals and/or remote procedure calls. Consequently this is what is produced when mapping a class to an SDL Interface.
As an example consider the DisplayInterface objects in Figure 49 that has one operation each.
Figure 49 : The DisplayInterface objects
|
|
When mapping these objects to SDL interface definitions we get in the first case the signal interface definition in Figure 50 (with the signal Display) and in the second case the remote procedure definition in Figure 51 (with a definition of the remote procedure Display2).
In SDL the natural way is to express interfaces by asynchronous signals, therefore this mapping has been chosen to be the default. (It can also be explicitly denoted with the word async within brackets, after the operation name.) If synchronous interface is preferred, this can be denoted by the word sync. This is an extension of the original class diagram notation.
Figure 50 : The signal interface from the DisplayInterface object in Figure 49
|
|
Figure 51 : The remote procedure interface given by the DisplayInterface2 object in Figure 49
|
|
It is of course also possible to have a mixed signal/remote procedure interface. In this case some of the operations are asynchronous and thus mapped to signals while other are synchronous and thus mapped to remote procedure definitions.
The static interface definition alone is not enough to define how the blocks are supposed to cooperate to meet the requirements on the system. In the requirements and system analysis, use cases were used to describe the requirements on the system. This is continued in the system design to define the dynamic interface between the blocks in the system. Essentially the idea is to take each one of the use cases found in the system analysis and formalize this to a sufficient degree of detail that is consistent with the level of detail that is found in the static interface definitions. The degree of detail must be precise enough to make the design use cases act as detailed test specifications.
A benefit with the design use cases is the structured way in which they are constructed. It is easy to verify that all requirements as expressed by the requirements use cases and refined in the analysis use cases are handled by the design use cases and this gives a formal link between the requirements and the structure of the system that implements it.
In a development environment where the different blocks are developed by different teams they also form a necessary common definition of the responsibilities of their respective blocks and how their blocks are to together fulfill the requirements on the system.
From a practical perspective this puts some requirements on the notation used to describe the design use cases:
There are two levels of testing of interest for the design use case model:
Module testing is intended to test one specific part of the system and should check that this particular part of the system fulfills its requirements. The system testing is intended to test the integration of the different parts and check that they together fulfil the requirements on the total system.
The design use case models should form the basis for both kinds of testing.
Another aspect of testing is when in the development project it is performed. One of the benefits of SDL is that it is possible to test already on the design model, essentially testing against a simulation of the SDL system. In addition there is of course also a need to test the implementation in the target environment, but if the logics of the application already has been tested during design then the focus of the target testing can be on target integration issues and the risk for logical errors in the design is reasonably small. The design level testing is further discussed in Design Testing.
In SOMT two different alternative notations are used:
MSCs can be used in a way that is precise and formal enough and can automatically be checked against SDL design models. A benefit is that it is used also in requirements analysis and system analysis and is intuitive and easy to understand also for non-experts. Notice however that there is a difference between the analysis use cases and the design use cases. The fairly abstract messages exchanged between the instances in the analysis use cases must in the design use cases be refined to the level of the static interface definitions, this may include specifying parameter values that where left out and even replacing one message with a sequence of message exchanges. It may also often be necessary to have more than one design use case for each analysis use case, for example to handle a situation where the analysis use case has left out a parameter and there is a need to test more than one combination of parameters.
Consider again the access control system with a decomposition according to Figure 45 where the system is divided into a DoorCtrl, a CentralCtrl and an OperatorCtrl block. If we take the Enter building use case as defined on requirements level by an MSC in Figure 25 and refined to the analysis use case in Figure 32 in System Analysis. When further refining this to a design use case we get an MSC as shown in Figure 52 where some of the messages have been refined.
Note that an MSC describes both the requirements on the separate parts of the system and the requirements on the whole system. This implies that the same MSC can be used to define both module and system tests.
Figure 52 : The Enter building use case distributed over an architecture
|
|
It is easy to see that the strategy outlined above is extendable to allow a decomposition of a system into not only one level of blocks, but into a hierarchy of blocks. For each new level of decomposition all use cases that involve the decomposed block are taken as input to the validation of the new decomposition. The block that was decomposed is replaced by the new blocks and new versions of the use cases are created.
TTCN is another notation that is suitable for formalizing use cases on the design level. The benefit of TTCN is that it is a special purpose language for test description including:
TTCN is also an established notation for test description so there is good tool support for executing TTCN test cases on target platforms.
The drawback is that it has not a particularly intuitive syntax, making it more difficult for non-experts to maintain, create and review TTCN test suites.
If TTCN is used to define both system and module testing each analysis use case will result in several TTCN test cases, one for each part of the system and then one for the entire system. As an example consider Example 11, that shows a test case testing the requirements from the Enter_Building use case on a DoorCtrl, and Example 12, that shows a test case testing the requirements from the Enter_Building use case on the entire AccessControl system.
1 UsrPCO?Card Card1
2 UsrPCO?Display Enter_Code
3 UsrPCO!Digit Digit1
4 UsrPCO!Digit Digit1
5 UsrPCO!Digit Digit1
6 UsrPCO!Digit Digit1
7 CentralPCO!Validate Validate_1
8 CentralPCO?Accept AcceptOK
9 DoorPCO!Unlock Unlock!
10 UserPCO!Display Please_Enter
11 DoorPCO?Open Open1
12 DoorPCO?Close Close1
13 DoorPCO!Lock Lock1
14 UserPCO!Display Enter_Card P
1 UsrPCO?Card Card1
2 UsrPCO?Display Enter_Code
3 UsrPCO!Digit Digit1
4 UsrPCO!Digit Digit1
5 UsrPCO!Digit Digit1
6 UsrPCO!Digit Digit1
7 DoorPCO!Unlock Unlock!
8 UserPCO!Display Please_Enter
9 DoorPCO?Open Open1
10 DoorPCO?Close Close1
11 DoorPCO!Lock Lock1
12 UserPCO!Display Enter_Card P
The choice between MSC and TTCN as design use case notation is very much influenced by application and development organization aspects:
The SDL architecture definition and the design use cases form a specification of the static and dynamic aspect of the components from a functional viewpoint. In many cases there is a need to extend this with more information that is not suitable to express in SDL or as use cases. An example may be a system that requires a user interface with windows, menus etc. or a system with specific requirements on reliability or response times for some or all of the components.
To give the possibility to express this type of specifications and also to allow other types of design or project documentation in an environment that is mainly SOMT and SDL oriented, the SOMT method gives a possibility to include textual documents in the system design documentation.
System design is reduced to design of a component when CORBA is used, because only components of a larger distributed system are considered. Each of these components can then in turn be viewed as an entire system, particularly if each component is eventually designed using its own design notation. In order to use a component in a distributed system, the entry end exit points of a component must be used in a standardized manner in order to make it possible to connect several components, i.e., an interface must be created for each component.
In SOMT, ordinary design notation is performed using SDL, but when CORBA is used, the system design should be carried out using IDL.
|
Note: CORBA and IDL support in SDT is only available on UNIX. |
In SDL, the major means to define an interface are through signals and remote procedures, as is described in Static Interface Definitions Using SDL. In CORBA, on the other hand, each component contains several objects which are interfaced through the IDL specification that is created, which means that an object-oriented view is automatically enforced when describing interfaces using IDL.
The basic IDL concept is an interface, which describes an object by providing the attributes and operations that are available on the object in a way that is very similar to the definition of an object model or C++ class. Several such interfaces can then be structured into a module, which corresponds roughly to a C++ namespace. Other components in a distributed system are allowed to use the objects defined in an IDL specification as if they were actually defined within themselves. An example of an IDL specification is shown in Example 13.
module Bank {
typedef status boolean;
interface BankAccount {
readonly attribute double balance;
oneway void Insert (in double amount);
status Withdraw (in double amount,
outdouble newBalance);
};
interface Cashier {
status CreateAccount (out Account ref);
status CloseAccount (in Account ref);
};
};
The example describes a bank component that contains two kinds of objects: bank accounts and cashiers. A client component cannot create bank accounts arbitrarily, but must ask a cashier to do this. A reference to the created bank account is then returned to the client, who is then able to use the bank account through the operations that are defined for it; money can either be inserted or withdrawn, and it is also possible to check the balance of the account.
The interface definition does only describe the available objects, operations, and attributes, while the question about how they are implemented is left open. The design of an interface is therefore separated from the design of the objects themselves, and a client cannot use other objects than the ones defined in the interface.
An IDL specification can be created during the system design by considering the results from the system analysis. The analysis object model contains objects that are likely candidates to become IDL interfaces, while the preliminary architecture model contains information about the structure of a component.
The only object model entity that makes sense to map to IDL--aside from ordinary text--is an object model class, which can be mapped to either an IDL module or an IDL interface. When the copy/paste as-mechanism is used an implink is automatically created between the copied entity and the pasted entity. Classes are mirrored almost exactly in an IDL specification. Classes containing attributes and operations are most likely IDL interfaces, while empty object model classes can be either IDL modules or IDL interfaces. Consider for example the class BankAccount that is shown Figure 53.
Figure 53 : An object model class
|
|
The class might have been taken from the analysis object model, and corresponds to the IDL interface that is shown in Example 14.
// interface BankAccount
interface BankAccount {
attribute double balance;
oneway void Insert (double amount);
status Withdraw (double amount,
double newBalance);
};
It is not possible to express all information that is needed in the IDL specification by simply mapping a class like this. For example, some type definitions or constants may have to be added, and it is not possible to denote whether the operation parameters in a class are in-, out-, or inout-parameters. Such additions have to be made manually in the IDL specification.
When an IDL module or an IDL interface is pasted from the object model, the implink that is created must be associated with a comment preceding the actual pasted entity in order not to disrupt the syntax of the IDL specification.
Inheritance is another important aspect that can be expressed when mapping object model classes to IDL interfaces. This also covers multiple inheritance. An example of one object model class inheriting another is shown in Figure 54.
Figure 54 : A simple inheritance example
|
|
If the class BankAccount is mapped to an IDL interface the result would be as is depicted in Example 15.
// interface BankAccount
interface BankAccount: Account{
oneway void Insert (double amount);
status Withdraw (double amount,
double newBalance);
};
If a class is part of another class, for example through aggregation, the container class is likely a module in IDL. The components of a container class may in turn be other container classes. Consider for example the class Bank shown in Figure 55.
Figure 55 : An object model class aggregation hierarchy
|
|
That class would be mapped to a module in IDL, as is shown in Example 16.
// module Bank
module Bank {
};
Note that the module is empty because no internal structure of the module has yet been made by mapping the BankAccount and Cashier classes in the object model diagram. When the aggregation hierarchy is inspected, it can be assumed that the IDL interface BankAccount that was created above should be part of the newly created IDL module Bank. It is difficult to express this when the mapping is performed in this order. Instead, aggregation hierarchies should often be mapped first, so that when an IDL interface is created, it can be placed directly in the module where it belongs, if any.
This section gives a number of examples of consistency checks that can be made on the models produced in the system design.
The system design is an activity in which the architecture of the system to be built is defined in SDL. Use cases from the analysis are refined to a granularity that will be sufficient for describing the behavior of the subsystems in the architecture. These use cases should be a source for module and system testing in later activities.