Design at the system level. Part 2. Detailed architecture

In the first part of the tutorial, I got the architecture of an access control system. The achieved result already has practical benefits, but not sufficient, since now the architecture does not take into account the formats and data types and the nature of the components. In this part of the tutorial, I will show how to design data streams in a system and work with components of various nature.

Component Interfaces

Let’s look at the system from the first part again. We see that the components are connected by arrows. These connections are still abstract and represent simple information connections. However, we can slightly reduce the level of abstraction. Consider the component output Dbhandler.

This component has an AccessStatus exit. Let’s try to describe it. So, AccessStatus is a link containing access status information. Access may either be granted or not granted. That is, it is an explicit Boolean variable! Let’s indicate the type of this output. To do this in System Composer, you must first create the appropriate interface:

And then we indicate that the created interface is assigned to the AccessStatus port:

This operation must be carried out on all the necessary ports. We can summarize and deduce the following statement:

By creating interfaces and assigning them to ports, we give developers who will implement the system precise instructions about what data the developed components will use and what data is required at the output.

Another advantage of System Composer is its ability to view data flow using custom architecture views, Architecture views. We can filter our architecture according to certain criteria. Take the previously created interface as an example. Create an AccessStatus Dataflow View.

First click Modeling -> Architecture Views. And then create a filter:

Here the name of the view is set, and a filter is created: select all components that have an interface with the name Accessstatus. After clicking the Apply button, we get the following picture:

Thus, the use of such representations is useful for development, since you can quickly find the necessary components or errors in the project or data stream.

Heterogeneous component management

It would be possible to stop at what has been achieved, because at the moment we have a beautiful system architecture that helps in the implementation. However, there is a very big problem – the system consists of iron, that is, physical components, and of software. What does this mean? This means that the system is heterogeneous and we need to somehow reflect this heterogeneity. System Composer has special features – these are profiles and stereotypes. For ease of understanding, a stereotype is an abstract description of a class of components with properties, and a profile is a collection of stereotypes. A simple example – let’s say we have a stereotype that describes a microcontroller. Any microcontroller has common properties – core, TDP, supply voltage, frequency, etc. It is these properties that should be reflected in the stereotype.

Create a profile and the necessary stereotypes:

For example, I created the stereotype of GenericComponent. Here’s what it looks like:

Several settings are important here:

  1. Applies To – what the stereotype applies to – the component, interface, port or connection (yes, the connections themselves, these arrows, can also be described using the stereotype)
  2. Base Stereotype is the parent stereotype. Stereotypes inherit the properties of parent stereotypes
  3. Property table – custom properties are set here. For example, my property is called Workload, that is, labor costs for implementation

2 other stereotypes are based on this stereotype. HardwareComponent – for iron, and SoftwareComponentfor software.

After we created the profile and stereotypes, we import them into the architecture and can begin to scatter it over its elements:

As a result, I got this picture:

For clarity, I made the following presentation:

Let’s look at the mechanism of inheriting the properties of components in action. Select the DoorLock component and look at its properties:

The Workload property was inherited from the GenericComponent, but the Cost property is specific to the HardwareComponent stereotype.

To summarize this part:

Detailed architecture allows a more complete description of the system being developed and to avoid inconsistencies in interfaces and interaction of components. The use of stereotypes for detail helps to understand the nature of components and get a more complete picture of the system being developed.

In the next part of the tutorial, I will talk about integrating System Composer with MATLAB, Simulink and the requirements management tool, Simulink Requierements.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *