Subsystem Architecture Design

From EUDP
Revision as of 11:35, 15 September 2009 by Klaus (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

What

Subsystem Architecture Diagram

How

The dish

Subsystem Architecture Diagram

Ingredients

Process

First consider the basic subsystem model. Would it suit the system-to-be? If it is not possible to confirm the basic model's immediate use, consider how the model should be extended. Ask yourself questions like: Are there other systems that the system-to-be should interact with? Should the function subsystem be split into two or more subsystems each reflecting delimited functionality? Are there special system interfaces that are contained within this project?

As for all other activities in the process, subsystem modelling is iterative. During his considerations the developer may have to go back to for instance the class analysis to rethink the class diagram due to new inspiration.

Having a introductory subsystem model ready after the initial considerations, it is time to model the internal parts of the subsystems.

The Class Diagram from the Class Analysis is typically put into the Model Subsystem because the Class Diagram is a mathematical or logical model of the world the system-to-be should control or administer. It is in the model we represent data and states captured from the "real" world.

The Functions should be assembled into classes where the functions in each class have a natural relationship with one another.

From the Use Case Analysis, Interface Analysis and System Dynamics Analysis we can extract the classes which belong in the Interface Subsystem.

Finally, the System Subsystem should be modelled. Typically, classes in the model may need a counterpart that represents an interface to the world outside the system.

The resulting Design Subsystem Diagram is a diagram showing the general subsystem architecture including classes.

How - in details.

We can divide a system into at least four Subsystems: Interface Subsystem (User Interface and Interface to other Systems), Function Subsystem, Model Subsystem and Technical System Interface Subsystem. The four basic Subsystems can be extended or limited depending on the nature of the system-to-be. The four Subsystems are only a basic architecture model. While modelling the architecture new Subsystems may arise and others may disappear.

Basic Subsystems Architecture.gif

Basic Subsystems Architecture

Example of an extended Subsystem Architecture Design.gif

Example of an extended Subsystem Architecture Design

The Subsystems can contain other Subsystems or they can be split into separate Subsystems. For an overview the simple Subsystem diagram only containing the basic Subsystems should be shown. For a more detailed view show either the Subsystems as separate Subsystems or show them as Subsystems within the basic Subsystem.

Example of embedded Subsystems.gif

Example of embedded Subsystems

The Model Subsystem

The Model Subsystem has the responsibility of handling the data in the system. The Model is a mirror of the Problem Domain. The model reflects the data (information)outside the system, hence the Analysis Class Diagram is the basis for the Model Subsystem.

The Functions Subsystem

The responsibilities of the Functions Subsystem are to offer functions at the disposal of the interfaces. The functions dispose a structured access to data in the model. From the Function Analysis a list of functions are available. Group the functions into function classes. The classes should contain functions that have relation to one another.

The System Subsystem

The responsibility of the System Subsystem is to provide access to basic systems such as hardware interfaces to the analog world. Other Subsystems on this level can be packages providing access to databases or network. Do not model in Subsystems detail that are provided by for instance the operating system, i.e. only Subsystems that we have to develop or in other way have to put some effort in to make it available should be in the design model.

The Interface Subsystem

The Interface Subsystems responsibility is to handle interfaces to the world outside the system, i.e. user interfaces or interfaces to other systems. Typically, the different interfaces are divided into several Subsystems. Consequently, if for instance there is a user interface and an interface to a host, you would model two Subsystems as shown in the example above. The candidates to put into the Interface Subsystems are found in the Interface Analysis.

Why

Definition: Subsystems are basic functional units of a program which allow for rapid development. They usually have simple interfaces which allow the programmer to do powerful things without having to worry about the complexities of implementing the component's functionality.

In EUDP we expand the subsystem concept to cover hardware and mechanical parts as well as software for which the subsystems traditionally has been defined as seen in the definition above.

For subsystem architecture modelling the main goal is to assign responsibilities into well defined parts of the system - the subsystems. We perform this activity to reduce complexities. By reducing complexities first of all we obtain a well-arranged system that the developer can oversee and consequently develop efficiently and with less bugs. Secondly a well-arranged layout and an effective implementation will lead to a well performing system.

Example

Subsystem Architecture Design.gif

The subsystem diagram shown above is the subsystem architecture for the heating system.


Used In

The subsystem design is used in the development process.

Architecture Dynamics may interest you.