The architecture is a simplified model of the concrete system . Concrete systems are composed from real hardware and executable software that provide services to real users.
While abstract systems, described in application and framework models, are composed from abstract components, concrete systems are composed from physical components and software. It is the concrete system that really matters to the users, but it is the abstract systems that enable us to understand what it does and to ensure that its functionality has the desired quality.
As illustrated in Figure 53 , concrete systems consist of:
the support software, which normally is a layered structure containing operating systems, middelware for distribution support, runtime systems for the languages used (SDL), DBMS and interface support;
For every new system development, the platform is an important design issue, as it determines important properties such as cost, reliability and flexibility. It also influences the way that applications and frameworks are implemented.
The architecture is an abstraction of the concrete system that emphasises high level hardware structure and software structure. It will not go into the implementation details but focus on the implementation principles and how functional and non-functional properties are satisfied. It will often be distributed and have additional support for internal communication, as illustrated in Figure 54 .
By identifying key architectural elements, the reference model helps to structure architecture models and to guide their development. Although the model in Figure 54 is quite coarsely grained, it identifies elements that come from different domains where the driving forces behind change and evolution are quite different. Application evolution, for instance, may be due to new service requirements (market pull), while the reason for platform changes may be performance and price (technology push). Keeping such parts separate and as independent as possible, we believe, is a key to flexibility and profitability.
1. Hardware. It contains the underlying structure of physical nodes and interconnections that may be classifies as:
Application framework specific hardware. This is hardware needed for the particular application or infrastructure that the system implements. Here we find peripheral equipment, such as the panels in the AccessControl system, and other special purpose hardware.
In real-time systems a central software design issue is how to handle concurrency, timing and communication. To this end it is important that the architecture manages to model the organisation of concurrent software processes (also called tasks in some operating systems), how they communicate and how they are scheduled.
In the family area, architectures are supposed to be quite general and contain the variability needed in different system instances. As a minimum they must support the variability needed in applications.
In the software part, we find the basic operating system at the bottom, with the other parts as successive applications on top of that. We may organise this as several software frameworks on top of each other. Ideally the result is a high level software framework where all we need to do to generate a particular application is to supply the application specific code.
1. Fundamental differences in the nature of components. Physical components are rather imperfect compared to the more ideal components of abstract systems. They develop errors over time, they are subject to noise, and they need time to perform their processing tasks.
2. Accidental differences in the functioning of components. In both worlds there are concepts for concurrency, communication, sequential behaviour and data, but they are not necessarily the same.
An abstract system is not limited by processing resources. Consequently the balance between the traffic load offered to the system and its processing capacity need not be considered. One simply assumes that the system is fast enough to process the load it is offered.
The real world is vastly different on this point. Each signal transfer, and each transition of a process, will take some time and require some processing resources. Due to these differences, the focal point of implementation design is quite different from that of the functional specification. The challenge is to find implementations for the abstract (SDL) concepts that are sufficiently fast to meet the traffic load and response time requirements without destroying the validity of the abstract system models.
In the AccessControl system, for instance, the average peak load is 600 validations a minute. This means that a central computer must process each validation in less than one tenth of a second. How much less will depend on the other tasks the computer has to do and the margin one wants against overloading the system.
A related issue is to balance the processing capacity against the requirements to response times. Again the abstract (SDL) system has no problems, but the implementation may be highly pressed to meet response time requirements. One must be able to perform time critical processing, e.g. fetching input samples, process the sampled information, and respond in a feedback loop, all within a maximum time frame. Such requirements may increase the demands on processing speed beyond the speed required to handle the traffic load.
The hardware software interfaces need special consideration. It is not unusual that the larger part of a computers capacity is spent doing input-output. Much can therefore be achieved by carefully designing the input-output interface.
A special class of time constraints originates from channels assuming time dependent synchronization. This means that the receiver has to be fast enough to catch all relevant signal information at the speed it is passed over the channel.
Since SDL descriptions clearly specify the external and internal interactions needed to perform given functions, they provide an excellent basis for estimating the processing capacity needed to meet load and timing requirements.
Abstract systems may suffer from specification errors, but the abstract world does not suffer from physical errors. It is simply assumed that processes and channels always operate according to their specification. It is not assumed that processes will stop from time to time, or that channels will distort the content of signals. But in the real world such things happen. From time to time errors will manifest themselves as faults in the operation of channels and processes.
In addition to the logical errors introduced in the implementation, we will have to cope with physical errors. Hardware errors, physical damage, and noise are caused by physical phenomena entirely outside the realm of abstract systems.
The effect of errors and noise will often need to be handled explicitly in the abstract system models, however. One must consider what may happen, how it can be detected and how the damages may be limited. If one active object fails, for instance, how should the environment react? One must consider what an object should do if it never gets a response to a request, or if it gets an erroneous response. What should be the reaction to a channel going down? What if an object starts to produce crazy signals? What if a signal is sent to a non-existing receiver?
Physically separate processes and channels may fail independently of each other. Channels covering long physical distances are subject to more noise and errors than channels implemented in software within one computer.
An SDL description does not tell anything about the physical distance covered by a channel. In reality, however, there may (or may not) be large physical distances. This means that transmission equipment and protocols are needed to implement the channel reliably. Thus physical distance may introduce new functions needed to support the implementation of channels.
In the AccessControl system we can expect AccessPoints to be distributed physically and to be far away from the central unit. Thus there will be a need for communication protocols on the channels between them.
A positive effect of physical separation is that errors are isolated. Errors in one unit need not affect the other units in the system, provided that erroneous information is not propagated into them. Thus, physical separation may improve the error handling. But there is no free lunch. Errors need to be detected and isolated to allow the operational parts to continue operation with the error present. Proper handling of this aspect can be quite complex, and will normally require additional functionality in the abstract models. This is one of the issues that we seek to isolate in the infrastructure.
All resources in a real system are finite. There may be a maximum number of processes the operating system can handle, or a maximum number of buffers for sending messages. The word length is restricted, and the memory space too. Even primitive data like integers are finite.
SDL, on the other hand, has an unbounded queue in the input port of each process, and allows infinite data to be specified. Hence the designer must find ways to implement potentially infinite SDL systems using finite resources. One way is to restrict the use of SDL such that all values are certain to be bounded. Another is to deal with resource limitations in the implementation, preferably in a manner transparent to the SDL level. In cases where transparency cannot be achieved, one must either accept deviation from the SDL semantics, or explicitly handle the limitations in the SDL system.
The model of concurrency used in SDL assumes that processes behave independently and asynchronously. There is no relative ordering of operations in different processes except the ordering implied by the sending and reception of signals.
A "natural" implementation is therefore to map each SDL process to a separate physical object. This is not always cost-effective. An alternative approach is to implement many processes in software sharing the same computer hardware. The implications of this are twofold:
The two communication forms are dual in the sense that one form may be used to implement the other. Consider the need to communicate a continuous value: the most direct implementation is to use a communication medium that will transmit the value continuously, such as a shared variable in software, or an electrical connection in hardware. But one may alternatively use a sequential medium, such as a message queue, to transmit a sequence of symbols representing the sequence of changes (events) in the continuous value. This will introduce overhead to reconstruct the continuous value.
Both forms may be used in abstract as well as in concrete systems, but it is not always the case that the same form is used. Therefore it may be necessary to make the necessary adaptations in the implementation.
Input from a keypad may serve as an example. The output signal from each button is basically a continuous "1" when pushed, and a continuous "0" when not pushed. But the system needs to know the sequence of key strokes, and not the instant values. Thus the value changes (events) need to be detected and converted to symbols representing complete key strokes. Event detection like this is often needed at the interfaces of a real-time system. It may either be performed in software or in hardware.
Visual signals on a display screen are another example. The user wants information presented as continuous values, and not as messages flickering across the screen. Hence the event oriented SDL signal has to be converted to a continuous value on the screen.
Channels crossing the hardware-software boundary need special attention. An atomic channel, represented by a line in SDL/GR, may turn out to be a mixture of physical lines, electronic equipment and software in the real system. The communication and synchronization primitives used in hardware will often differ from those used in software.
To sum up: we cannot expect to find SDL-type signals at all interfaces, and must therefore be prepared to adapt and convert. Conversion from one form to another will be necessary. This is often a time critical task needing careful optimization.
The act of aligning the operations of different concurrent processes in relation to each other is generally called synchronization. Synchronization is necessary not only to achieve correctness in communication, but also to control the access to shared resources in the physical system.
Consider two SDL processes that communicate. The sending process may send a signal at any time because it will be buffered in the input port of the receiving process. The receiving process may then consume the signal at a later time.
This is a buffered communication scheme in which the sender may produce infinitely many signals without waiting for the receiver to consume them. It is often referred to as asynchronous communication.
Asynchronous communication may be contrasted with so-called synchronous communication, in which the sending operation and the consuming operation occur at the same time. In this case there is no buffer between the processes.
Synchronisation may be further classified into time dependent synchronization, in which the operations are not explicitly synchronized, and time independent synchronization, which depends on an explicit synchronization of operations (some kind of semaphore). In time dependent synchronisation the correctness of an interaction depends on the relative timing of operations. This is a frequent source of so-called hard real-time requirements. It is quite common in communication channels (e.g. Asynchronous Transfer Mode, ATM).
One will often find mechanisms that differ from the SDL mechanisms at the physical interfaces to the system. It is quite typical to find time dependent synchronization on physical channels. This implies that time critical event monitoring and event generation will be necessary.
A designer will be faced on one hand by the synchronization primitives available in the real system, and on the other hand by the synchronization implied by the SDL specification. Additional functionality will often be needed to glue the various forms together.
SDL data is based on the notion of abstract data types where operations may be defined by means of axioms. An implementation will normally need concrete data types where the operations are defined operationally. Therefore, the designer may need to transform the abstract data types of SDL into more concrete data types suitable for implementation.
Architecture models are intended to answer how a system is (going to be/has been) realised. Their focus is on the concrete system construction in terms of hardware and software components, and how it implements the abstract systems defined in the application framework. While the application framework has focus on functional properties and behaviour, the architecture has focus on non-functional properties and physical structures. The purposes of architecture models are:
In the architecture object models, the hardware and software architectures will be defined to a level of detail from which implementation is well defined. They should be organised into a generic platform specific part and a framework specific part which is adaptable to different applications.
The architecture contains variability that needs to be bound in system instances. In fact, configuration of system instances may take place at the architecture level, if suitable tool support is available.
The architecture models are organised into a specification part, and a design part, as illustrated in Figure 55 .
Together the application, the framework and the architecture complement each other to form a complete documentation. As long as the framework and the architecture is stable, only the application need to be supplied for each new system.
Note that the architecture serves as our (only) entry point to a complete description of a given concrete system. By following the relationships "upwards" to the framework we find models of the abstract functionality it provides, and by following the relations "down" towards the Implementation we find all the implementation detail.
It is recommended to define a Method for framework code generation (automatic and manual), and a Method for system instantiation which define the procedures and tools for configuration and building of system instances. (The configuration and building of system instances shall be as easy as possible.)
The architecture property models describe non-functional properties and the architecture object models describe hardware structure, software structure and relationships.
Non-functional properties are more physical in nature than the functional properties . They express features of a concrete system that are not modelled by a corresponding abstract system, typically features related to performance, error handling, power consumption and physical construction. See Architecture non-functional properties for details.
Hardware models describe the hardware on a high level. Here we find a description of the overall hardware structure as well as the types of hardware components used to compose the structure. Hardware models shall identify at least all physical nodes needed to implement the abstract system. Whenever possible and practical one should make a hardware framework that separates between:
These are models of the software. Here we describe the overall structure in terms of processes, procedures and data as well as the component types used in the structure. Whenever possible and practical one should make software frameworks that separates between:
Implementation relations are used to describe which parts of the application frameworks that are implemented-by the various physical nodes and software nodes , and where detailed hardware descriptions and source code can be found.
Object models will be used to express the hardware and the software models. In the old SISU methodology two special diagram types were used for this. As it seems, the forthcoming UML will contain notations intended for similar purposes. If they prove adequate, they will be adopted by TIMe.
While the application specifications describe abstract system properties related to the system behaviour ( functional properties ) the architecture specification describe concrete system properties ( non-functional properties ) related to the physical construction. Application specifications serve several purposes:
1. Before the architecture is designed it serves to specify required properties that the concrete system shall satisfy. Such requirements are sometimes called design constraints, because they constrain the possible design space.
Specifications apply to the physical architecture as a whole as well as to each type of component in it. Hardware components and software components are normally characterised by different properties. (Power consumption, for instance, is a hardware property, while code size is a software property.) As for other specifications, the main thing is to describe properties that are important for the external use of the system. Consequently the context model is most important, but internal aspects may also be relevant.
Specification object models will not always be needed, and may be omitted when they follow from the non-functional requirements in an obvious way. However, object models are good at describing objects and relationships, and should be included whenever that kind of information is important.
2. Software specifications; that may possibly be split into a layered structure according to the Architecture reference model .
Note that variability is important. Try to express variability both in the number of components and in their types. One should for instance specify what range of platforms that shall be supported, and the maximum number of computers the system may contain.
User and customer related properties are important for the user (or the customer/owner) while Company internal properties are more important for the company itself (see also Dimensions of the property concept ):
Non-functional properties are expressed in a mixture of text, figures and mathematics. The precise form varies between different kinds of properties. Non-functional properties are to be associated with the object models.
Architecture design determines critical architectural issues such as physical distribution, communication schemes, support software and physical interfaces. Some of these may subsequently be reflected in the Framework model in order to describe the complete system behaviour.
The external relationships are presented in Figure 56 .
Nodes in the architecture will implement components of the framework. It is recommended that the framework structure is similar to the structure of the architecture so that there is a one-to-one correspondence between the two structures (at a suitable aggregation level).
Normally the framework is harmonised to reflect the architecture, while the architecture need not take the framework into account, see Relationships framework - architecture .
The architecture is an abstraction of the concrete system intended to give overview and promote understanding of its construction. It should cover all parts of the implementation so it can be trusted as a faithful representation of it. At the same time it should not go into details that are better described using hardware description languages and programming languages. Such detail shall be found in implementation descriptions that are referenced from the architecture.
When the architecture has been designed, the architecture specification shall be harmonised. It shall be correct with respect to the actually provided properties, and it shall cover every property of importance for external assessment and use. Properties not needed for that purpose should be removed even if they were included in the initial specification.
The architecture models serve several purposes, see Architecture models , and should be structured to fulfil as many of those as possible. In addition the Architecture reference model should be used to make a layered structure that facilitates evolution.
Architecture development results in an implementation architecture that will behave as defined in the Application models and satisfy the non-functional properties. It will also define a method for (automatic) generation of application implementation code and for configuration and building of system instances.
Concrete system design involves specialists in electronics, mechanics and software design. Such specialists tend to have a limited ability to perform high level system design. As this is very important in architectural design, an interdisciplinary team is required unless people with sufficiently broad system design experience are available. The team should not be biased towards a particular technology, but be able to perform tradeoffs wherever the solution is open. Such openness in design solutions is often essential in order to achieve innovation.
Users are normally not much concerned about architecture. But for the customer and the manufacturer it matters quite a deal. Not the least because it determines lifetime cost, the ability to evolve and the ability to interoperate with other systems.
This activity is only performed when the implementation mapping is undefined or needs to be changed. This occurs during the initial development of a system family and during maintenance, when changes in the Platform are needed e.g. because of changes in the support software.
In an initial development, architecture design will come before framework/infrastructure design. During normal application evolution, the generic architecture will stay the same, and system evolution can take place mainly at the application level.
Inputs to this activity are the same as for Developing architecture models as a whole, see Figure 57 . There are two main sources of inputs: the market (represented by users and other domain stake holders) and the company itself (represented by product owners, production departments and service responsibles). Technology (that is what technology and solutions are feasible today) may be considered a third source.
This activity makes an incremental evolution of the architecture so that it satisfies a new specification increment. It involves the same basic activities as making architectures for the first time, only that the existing architecture is taken into account. At this stage of development an application framework may exist.
See Software design for further details.