Systems And Subsystems

Let us suppose that all the activities in a farm need to be automated. A software system will be developed to cover the activities such as accounting, sales, inventory, and so on.

All relevant farm activities will be presented in a system. [BRJ99] defines a system as "a set of elements organized to accomplish a purpose and described by a set of models, possible from different viewpoints." A system possibly may be decomposed into a set of subsystems and should represent only the most relevant elements of the domain under study. The UML symbol for a system is shown in Figure 3-11.

Figure 3-11. The UML symbol for a system.

[BRJ99] defines a subsystem as "a grouping of elements of which some constitute a specification of the behavior offered by other contained elements." A subsystem may contain classes, interfaces, components and other subsystems. A subsystem is a combination of a package and a class. As packages, subsystems have semantics that allow them to contain other model elements. Like classes, subsystems realize or implement a set of interfaces that give them behavior. The behavior of a subsystem is provided by classes and other subsystems included in the subsystem. The UML symbol for a subsystem is a combination of symbols of package and interface as shown in Figure 3-12.

Figure 3-12. Example of UML symbol of a subsystem.

Figure 3-12. Example of UML symbol of a subsystem.

In Figure 3-12, the Accounting subsystem represents an implementation of operations defined in the interface Accountinglnterface. Accounting, as part of activities in a farm, is quite independent. It collaborates intensively with other subsystems as it keeps track of all the expenses that occur in the farm. Accounting subsystem receives data from other subsystems and provides different financial reports.

When representing a particular problem domain as a system, decisions have to be made on how the system will be divided into subsystems and what classes will be included in each of the subsystems. Issues, such as the kind of behavior each subsystem should encapsulate and its size, are to be discussed and solved. Subsystems should be nearly independent with a well-defined purpose. They will be interacting with each other to provide the functionalities required by the system. Each subsystem encapsulates specific behavior and the behavior of the entire system will be provided by the set of created subsystems. Different levels of abstractions can produce different kinds of subsystems. A subsystem at one level of abstraction can be a system in another level of abstraction. In other words, a subsystem is only a composing part of a bigger and complex system. Encapsulation and modularity are the two principles of object-orientation that need to be considered during the phase of system analysis.

A subsystem should not expose any of its composing parts. No class in a subsystem should be visible outside the subsystem. No element outside the subsystem should have direct dependency on elements inside the subsystem. A subsystem should depend only on the interfaces of other model elements and other model elements will depend only on the set of interfaces of a subsystem. This way, a subsystem can be replaced by another one provided they implement the same set of interfaces.

As previously mentioned, the behavior of a subsystem is defined by the set of interfaces the subsystem implements. Subsystem's behavior will be provided only by classes or modeling elements that are included into the subsystem. There should not be any reference to any class outside the subsystem.

Figure 3-13 shows an example of decomposition of a farm system into subsystems. Accounting subsystem will include all the classes needed to carry out accounting responsibilities. The responsibilities of the subsystem are defined in the interface IAccounting. The subsystem Production includes all the classes representing operations occurring in a farm. The responsibilities of this subsystem are defined in the interface IProduction. The same way, the subsystem Research&Development will include all the classes defined to represent entities related to the research and development process. The responsibilities of this subsystem are defined in the interface IResearch&Development.

IResearch&D evelopment

IResearch&D evelopment

«subsystem» Production


Figure 3-13. Decomposition of a system into subsystems.

There are some similarities between the concept of subsystem and the one of component. They both encapsulate a partial behavior of a bigger system and are designed to dialog with others to provide the functionality required by the system. Their behavior is defined by a set of interfaces for which they provide a polymorphic implementation. They both provide substitutable behavior; both can be replaced by other component/subsystems provided they realize the same set of interfaces. They are constructed using the same object-oriented principles: Encapsulation and modularity.

The difference between a component and a subsystem is the time they are used in the software construction process. A subsystem is a design concept; it is an abstraction used in the design process to present part of a complex system. A component is a physical entity; it is an implementation tool that represents part of a bigger real system. Components are implementation realizations of subsystems. As an example, during the phases of analysis and design of a farm management system, all the functionalities related to accounting will be grouped in the subsystem Accounting. The collaboration with other subsystems will be defined as a set of interfaces for the subsystem. Then, functionalities of the subsystem will be translated into code and therefore the Accounting component is obtained ready to be deployed.

0 0

Post a comment