|4.37 Elementary Method "Subsystem Modeling" (SSM)|
The method is applied for the object-oriented system development. The objective of the method is to structure a system in a set of logical subsystems in order to handle the complexity during analysis, generation, maintenance and modification of the system. This structure can be realized in several levels.
In the first substructure of the system into subsystems (domains), each subsystem should represent an independent unit with individual subjects. Each subsystem of the first structure should already represent a unit for the analysis from a conceptional, professional point of view. Depending on the later role in the completed system, systems can be classified into user subsystems, service subsystems with mechanisms and functions to support user subsystems, in architecture subsystems, with generic functions for the data administration and for the system administration, and in implementation subsystems with resources for the software implementation like programming languages and operating systems (compare /Shlaer, Mellor, 1992/, Chap. 7). Subsystems can be further substructured. In these substructures, the task-oriented connection of classes is playing an important role (compare /Shlaer, Mellor, 1992/, chap. 8)(1) .
Means of Representation
Shlaer/Mellor use diagram types that also allow the representation of relationships between subsystems. These are the "Domain Charts", "Subsystem Relationship Models", "Subsystem Communication Models" and "Subsystem Access Models" /Shlaer, Mellor, 1992/(2) .
The subsystem modeling should always be used when a logical system structure is required because of the complexity. A first structure/classification should take place as early as possible during the analysis by applying the above described criteria. In the following iterative development steps the subsystems have to be adjusted, supplemented and completed, if required.
|4.1||SD1.2 - Description of Application System||
In order to use predefined modules (areas/fields), a first system structure into professional areas or fields can be realized with the help of this method.
The method covers subproduct User Requirements.Preliminary System Description from the point of view of the professional system structure.
|4.2||SD1.5 - User-Level System Structure||
With the help of this method a system structure into professional fields/areas can be realized or improved.
The method covers User Requirements.Organizational Embedding from the point of view of the organizational system structure.
|4.3||SD2.1 - Technical System Design||
With the help of this method the system can be structured into segments and/or SW/HW Units by applying method COM - Class/Object Modeling as well. This must be adjusted with a professional structure of the system. Static interface models (cf. method COM) can be specified for the interfaces between the defined architecture elements.
The two methods cover subproducts System Architecture.Solution Proposals and System Architecture.Technical System Structure with regard to the system, they cover subproduct Technical Requirements.Technical Requirements for the Interfaces with regard to the system, and they also cover subproduct "Interface Overview.System-Internal Interfaces from the point of view of the static structure.
|4.4||SD2.5 - Interface Description||
With the help of this method the interfaces of the system and the defined architecture elements can be modeled or improved by applying the method COM - Class/Object Modeling.
The two methods cover subproduct Interface Description.Description of the interfaces from the point of view of the static structure.
|4.5||SD4.1 - SW Architecture Design||
With the help of this method the structure of the SW Unit into static architecture elements can be realized in combination with method COM - Class/Object Modeling. Static interface models (compare method COM) can be specified for the interfaces between the defined architecture elements.
The two methods cover subproducts SW Architecture.Solution Proposals, SW Architecture.Modularization/Database Design, and SW Architecture.Interfaces, and subsystem Interface Overview.System-Internal Interfaces from the point of view of the static structure.
|No.||Interface||Observation||Information in Annex 1|
|5.1||SSM-COM||The system has to be structured into segments, HW/SW Units, SW Components and SW modules in combined application with methods COM and SSM, according to the V-Model. The external interfaces of the architecture elements have to be specified.|
|5.2||SSM-MODIAG||The professional system structure with the help of method SSM has to be adjusted with the physical structure realized with method MODIAG.|
(2) In Booch (/Booch, 1994/), subsystems are represented by a symbol for "Class Categories" into "Class Diagrams" and by a symbol for "Class Subsystems" into "Module Diagrams". In the Unified Modeling Language (UML) /Booch, 1997/, the subsystem modeling can be realized with the help of packages.
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster