A subsystem is a model element that has the semantics of a package (which may contain other model elements) and classes (which have behavior). The behavior of the subsystem is provided by the class or other subsystems it contains. Sub-Systems The subsystem implements one or more interfaces that define the behavior that the subsystem can perform.
The use of subsystems
The subsystems can be used in a variety of complementary ways to divide the system into units, which are:
Can be scheduled, Sub-Systems configured or delivered independently
Can be developed independently (as long as the interface remains the same)
Can be deployed independently on a set of distributed compute nodes
Can be changed without destroying the rest of the system
In addition, the subsystem can also:
Divide the system into units to provide limited security for critical resources
In the design of existing products or external systems
Identify subsystems from class collaboration
If the classes in a collaboration are only interacting with each other and can produce a set of well-defined results, the collaboration and its classes should be encapsulated in a subsystem.
This rule also applies to a subset of the collaboration. Any part or all of the collaboration can be encapsulated and simplified, Sub-Systems which will make the design easier to understand.
Note that if a specific collaboration (or sub-collaboration) represents an optional behavior, it should be encapsulated in a subsystem. If you can delete, upgrade, or replace some of the features, you should think that these features are independent. Note the system's user interface. If the user interface is relatively independent of the entity classes in the system (that is, both can and will be changed independently), you should create a horizontally integrated subsystem that classifies the associated user interface bounds into a subsystem and associates the associated Entity class is classified into another subsystem. If the user interface is tightly coupled to the entity class it displays (that is, one party's change triggers another change), a vertically integrated subsystem should be created: the associated boundary class and entity class are loaded into the common subsystem. Note that the protagonist will be two different characters used to separate the main character, because each protagonist may independently change their own system needs. Look for classes that are coupled with classes and have a high degree of cohesion or cohesion with each other to provide a set of services. Organize subclasses with higher degrees of coupling to separate classes along weakly bound boundaries. In some cases, classes can be divided into smaller classes to have a higher degree of cohesion, Sub-Systems thus completely eliminating weak coupling. Attention Replacement If several service levels (for example, high, medium, low availability) are specified for a particular feature, each service level is represented as a separate subsystem, and each subsystem implements the same set of interfaces. In this way, the subsystems can replace each other. Note that although a particular subsystem may have multiple instances, each instance is executed on a different node, but it is not possible to split a single instance of the subsystem between nodes. If you must split subsystem behavior between nodes, you need to divide the subsystem into smaller subsystems to make it more restrictive. Determine the functionality that must exist on each node, and create a new subsystem to "own" the functionality and then distribute the responsibilities and related elements within the subsystem accordingly.