Objective

The system family statement is the first introduction to the system family. It serves two main purposes:

• To concisely express the goals for the system development.
• To serve as a top level introduction to the system family.

System family statement outline

Executive summary

This should be a very brief summary with focus on the key issues. It may well be written in a style directly suitable for market purposes. Stake holders in the domain should immediately recognise and accept the description.

How it relates to the domain

Briefly about the domain (with reference to domain descriptions) and what needs in the domain the system family addresses. Which actors in the domain will be supported, and what other stake holders may benefit.

How it relates to the environment

Describe the system context with emphasis on the system boundary and the system environment Explain who are the users, operators and other systems that may connect to the system.

What services it provides

A summary of the main functionality with a list of all the main services, their purpose, and how they are performed.

Interfaces

A brief description of the interfaces with emphasis on user interfaces.

Other properties

Give a brief account of the general properties and the non-functional properties provided. Emphasise positioning properties. If maintenance properties are important they should be mentioned.

Variability and evolution

Consider flexibility for change, variability and other issues related to market adaptation in space and time.

Technology issues

If technological principles used or other design aspects are important at this stage, they should be mentioned.

System family statement notations

The family statement will be expressed in prose, supplemented by figures.

Family statement relationships

With domain

The statement is likely to refer to the domain descriptions, but it may also use terminology from the domain. Therefore the domain given terminology used shall have entries in the domain dictionary.

Within family

The statement is likely to use some system family specific terminology. Such terminology shall be defined in the system family dictionary.

Harmonising system family statement

With domain

Be sure to use a terminology which is consistent with the domain terminology.

Every domain term used should be defined in the domain dictionary.

With family

Every family specific term should be defined in the family dictionary.

For every service mentioned there shall be a corresponding entry in the Specifications.

Summary of static family statement rules

t.b.d.

Developing system family statements

What

It is assumed that the creative work which actually determines what the system is is going to be is performed in other activities, mainly in the system Study activities and Specification activities. The task here is simply to express what has been decided. The form shall be suitable for a broad audience within the company (not only developers) and possibly for external use. It will be used for internal decision making and control.

Actors

The system family statement should be written jointly by market persons and developers. Management should be involved in approving it.

Making system family statement

The activity may be subdivided according to the topics of a system family statement:

Evolving system family statement

The system family Statement should be written in such a way that it can be kept as stable as possible. Nevertheless, some evolution is likely to occur either because the Statement needs improvement or because new features are added to the systems in the family.

How to proceed depends on the nature of the change.

Objective

To define system family specific terminology in order to:

• improve precision and efficiency in the process;
• facilitate training of new people;
• facilitate reading system documentation.

System family dictionary content

The general format is:

<term><explanation>[example][synonyms]

The family dictionary is related to the domain dictionary. The two dictionaries may physically be different parts of the same dictionary.

System family dictionary relationships

Relationships system family dictionary - domain

The domain given terminology used in families shall be the same as in the domain dictionary.

Harmonising system family dictionary - domain

Ensure that the general domain terminology is applied in the families. family dictionaries should refer to the domain dictionary for all domain given terminology and avoid redundant definitions (which may develop into inconsistent definitions).

Relationships system family dictionary - rest of family

For entries in the dictionary that correspond to concepts that will be represented directly by types (classes), it may be a good idea (if this is known) to use the same name on the type as the designation of the concepts.

Harmonising system family dictionary - rest of family

Ensure that the relationships with the other family descriptions are maintained. See System family dictionary relationships.

Summary of static system family dictionary rules

• Represent each essential system family phenomena and concept by an entry in the dictionary.
• Keep the dictionary updated throughout the development. If desired classify the entries as coming from analysis or design, domain, environment or system. This may help in updating the dictionary and also to answer questions like "Is this phenomenon covered by the domain of the system?" or "Is this type of entity handled by the system?"

Developing system family dictionary

What

In general, the dictionary comes from the other family descriptions, as its purpose is to define the terminology used there. Thus, the dictionary is developed more as a spin-off from making the other descriptions, than as an independent activity.

When object models and property models are developed, the dictionary should cover all the objects/types, associations and properties represented in those models.

Actors

The dictionary is most likely made by the developers.

Making system family dictionary

The family dictionary is made for the first time as part of the first requirements analysis, see: Making requirements.

The first family dictionary comes from the System family statement, the System studies and the System family statement. By studying the nouns in the System family statement we can make the initial dictionary. But the dictionary shall contain more than the nouns, it shall also include services or functions and associations which may be visible in the domain Statement as verbs. It shall include every term used in the system specifications. Note that domain terminology is not to be covered.

editorial

1. should the dictionary be organised in some way? e.g. according to the domain statement categories, according to the kind of entity (concept, property, entity, relationship, service)

2. should the dictionary contain references to object models and property models?

Evolving system family dictionary

The dictionary is evolved as part of the evolution of family descriptions. Whenever existing terms are modified or new terms are introduced in any of the other family descriptions, the family dictionary should follow up.

Summary of dynamic system family dictionary rules

• Develop the dictionary in parallel with other family descriptions.
• Use the dictionary actively as a source of terminology when making the other descriptions.
• Do not add new terms to any model without checking that there is no appropriate term in the dictionary already.
• Analyse each entry checking that it is precisely and unambiguously defined. Look for similarities among entries. Avoid to use the same term for different things, and to use different terms for the same thing. If necessary define synonyms explicitly. Clarify relationships between related entries, e.g. subtype relationships.

What

Implementations are detailed and precise descriptions of the hardware and the software that a concrete system is made of. They define the physical construction of systems in a family. The software part will be expressed in programming languages such as C++ or Pascal, while the hardware part will be expressed in a mixture of hardware description languages such as circuit diagrams, cabinet layout diagrams and VHDL. Software plays a dual role. Firstly, as a description to be read and understood outside the system, and secondly as an exact prescription of behaviour to be interpreted inside the system.

Figure 20 illustrates some aspects of implementations. Note that the code generated from application frameworks will interface with code coming from different sources. To produce a concrete system these various parts of code must be linked together and loaded on the the hardware.

Figure 20: Software implementation

Open figure

Architecture models contain information that may be used to direct the transformation from application frameworks into implementation code and the building of a concrete system.

Automatic code generation

State-of-the-art tools allow the application framework software to be automatically derived. The code which is generated for the application framework must be adapted somehow to the software environment (operating system, input-output, middleware). Here the vendors of code generators use two different strategies. One is to adapt the code generator so the generated code fits the platform. Another is to adapt the generated code to fit different platforms by means of interface modules and/or macros.

Once the platform and the code generation strategy is defined, it is possible to rely on automatic code generation for those parts of applications and frameworks where SDL is used.

Objectives

Once the architecture is defined, much can be gained if the remaining development effort can concentrate on application evolution. That will be possible only if there is a well defined method, supported by automatic tools, for derivation of implementations.

What

The method needs to consider several issues:

• Automatic code generation. How to produce implementation code that fits into the application software environment? How to handle incremental or piecewise generation?
• Hand generated code. What are the rules that hand generated code shall follow?
• Integration of automatically generated code with hand generated code, foreign code and support code.

How the code shall be divided into modules for ease of generation and handling?

Method for system instantiation

Objectives

The purpose is to enable cost effective production of system instances that:

• satisfy customer requirements;
• supports future evolution and maintenance.

What

This method should define the procedures and the tools that shall be used to generate system instances. Problems to solve are:

• how to specify configurations at the various abstraction levels: application, framework, platform;
• how to generate or produce the various parts;
• how to compose the parts into a system;

how to load and initialise the software.