Previous Next Methods Allocation  
4.37 Elementary Method "Subsystem Modeling" (SSM)  

  4.37 Elementarmethode "Subsystemmodellierung" (SSM)

Contents  
  • 1 Identification/Definition of the Method
  • 2 Brief Characteristic of the Method
  • 3 Limits of the Methods Application
  • 4 Specification of the Methods Allocation
  • 5 Interfaces
  • 6 Further Literature
  • 7 Functional Tool Requirements
  • Links to the V-Model Mailinglist

    • 1 Identification/Definition of the Method

    /Shlaer, Mellor, 1992/ Object Lifecycles - Modeling the World in States

    2 Brief Characteristic of the Method

    Objective and Purpose

    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) .

    Operational Sequence

    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.

    3 Limits of the Methods Application

    - not applicable -

    4 Specification of the Methods Allocation

    No. Activity Description
    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.

    5 Interfaces

    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.  

    6 Further Literature

    /Booch, 1994/ Object-Oriented Analysis and Design with Applications
    /Booch, 1997/ Unified Modeling Language, Version 1.0
    /Rumbaugh, 91/,
    /Rumbaugh, 95a/,
    /Starr, 1996/

    7 Functional Tool Requirements

    SSD23 - Supporting Subsystem Modeling

    Links to the V-Model Mailinglist

    Mail 0200 - Re: Methodenzuordnung fuer UML (200)
    Notes:

    (1) Another approach for the subsystem modeling can be found in Booch and Rumbaugh (/Booch, 1994/, /Rumbaugh, 91/, /Booch, 1997/, /Rumbaugh, 95a/). In this approach, a set of already found classes and objects is to be structured into groups, the subsystems, with their relations. Building groups may be realized both from logical and merely organizational aspects. If groups have been found they can be completed and updated in the iterative development process.

    (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.

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster