Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
Scenarios  Homepage  
SC.5 Object-Oriented Development  

  SZ.5 Objektorientierte Entwicklung

Contents  
  • SC.5.1 Sequence Description for the Activities in Submodel SD
  • SC.5.2 Cooperation with the Remaining Submodels
  • SC.5.3 Criteria for the Selection of the Scenario
  • SC.5.1 Sequence Description for the Activities in Submodel SD

    Object-orientation was predominantly known as a programming concept. By using object-oriented analysis and design methods, however, object-oriented concepts can be applied to the development process at a very early stage, and be assembled to an interconnected approach for the entire development process, from the analysis and the design to the implementation.

    The use of object-oriented concepts is favorable for the identification, generation and reuse of completed (user-level and technical) items that might be made available in libraries for all projects. These items are available as so-called "classes", they encapsulate data and functions. This way the design principles of the data encapsulation and of the abstraction can be realized. Class changes can be realized without effecting other system parts when they only refer to the internal implementation of a class and not to the external specification of that class.

    Classes and objects are items of an object-oriented architecture. They are specified both from static aspects (class and object models) and from dynamic aspects (status and interaction models). In general, classes are hierarchically combined into groups (subsystem models).

    Basically, the object-oriented procedure is identified by

    Iterative development allow the iterative assessment and improvement of preceding events. The incremental procedure allows the development of parts of the object-oriented architecture used, among others, to deliver first tangible results. In an object-oriented procedure, prototyping is primarily applied for the development of information systems in the sense of the explorative prototyping. This kind of prototyping is primarily applied to obtain information for the refinement, completion and clarification of User Requirements. In the development of technical systems, prototyping is predominantly used in the sense of the experimental prototyping.

    By applying object-oriented methods, SD activities are used to support the static and dynamic modeling of the object-oriented architecture. They are also used to collect the functional requirements and the description of the physical software design, the physical platform of the object-oriented architecture and the process structure required by the System.

    The application of modular combinable modules (classes) makes changing architecture usually easy, i. e. with less effort as this is the case in classical (not object-oriented) procedures. Using class libraries and object-oriented methods, the application of ready parts in the sense of an off-the-shelf product-oriented development strategy is made easy. Development cycles are realized faster, since, as a rule, modular object-oriented architectures can be easily modified.

    The regulations for project and configuration management and quality assurance are basically not influenced by the use of object-oriented methods, since the regulations of the V-Model are defined independent of the methods.

    Within the scope of an object-oriented procedure, User Requirements are the starting point for all other tasks/activities, they are binding for the entire system development, just as a work contract. The User Requirements in the object-oriented scenario refine the User Requirements for the overall System.

    The sequence of the SD activities in an object-oriented procedure is illustrated in Figure SC.6.

    Preliminary Remarks:

    Figure SC.5
    Figure SC.5: Sequence of SD Activities in Object-Oriented Development

    Time T 0-Start

    Initialization of the project and beginning of the tasks with regard to the content according to submodel SD.

    Time T 1-Assessment with Regard to Off-the-Shelf Products to be Used

    A preliminary system description is available as a result of activity SD1.2 - Description of Application System, it describes the core and the overall content for the system functionality. Here the System is first structured into fields whereby, from a user-level and conceptual point of view, each field represents a unit for the analysis. User requirements are described as use cases. With their functional requirements, the thus defined use cases represent a basis for finding classes and objects, for allocating functionality to classes, and for the interface design. They are also used to reach an understanding with the user himself about the User Requirements. In its overall size, the use cases specified for a System contain the application-oriented, functional requirements to the System. The object-oriented concepts of class and object modeling are used on this basis in order to be continually refined during the following processes, until they are ready for implementation. It is the essential tasks of the class and object modeling to collect the static aspects of object-oriented Systems. Dynamics and interaction within object-oriented Systems are collected, together with other object-oriented elementary methods.

    For some fields identified in activity SD1.5 - User-Level System Structure (first increment level) parts of the user-level requirements are not complete (field 1), other parts have been incompletely generated (field 2).

    The description of the functionality includes all use cases and the initial class structure based on these cases-predominantly describing the responsibilities of classes and their cooperation-as well as an initial representation of the dynamics and the interaction between the classes.

    Time T 2-Integration of Predefined User-Level Modules

    The presence and use of libraries with predefined classes is an important part in an advanced, object-oriented development.

    Using predefined classes is to

    The class library is not only to be used as a source for modules but also to support proven and possibly standardized user-level architectures. In case predefined field descriptions are already available for the application field in object-oriented form, they may be used.

    Together, the results of activities SD1.2 - Description of Application System and SD1.5 - User-Level System Structure represent the User Requirements which are available in an initial version at time T 2.

    The User Requirements must be detailed enough to reach the following goals:

    Time T 3-Design of the Technical Solution

    As a result of activity SD2.1 - Technical System Design, the fields of the first increment are described with regard to their technical realization (both in the System Architecture and in the Technical Requirements).

    The description of the System Architecture in the object-oriented field is done via class hierarchies, i. e. classes and objects defined on the basis of the User Requirements are completed by technical classes and objects and combined into an object-oriented architecture. In this connection, the user organization must be taken into consideration as an influential factor.

    Technical classes and objects can be allocated to completing fields, e. g. fields for the data and system administration, fields with mechanisms and functions for the support of the user fields or fields with resources for the software implementation.

    The technical structuring may be based on class libraries, just like user-level structuring. By taking into consideration technical solutions within the scope of the SD 1 activities, a professionally sound and sufficiently defined specification is generated for the realization of the initial increment by the contractor. The System Architecture and the Technical Requirements are completed, and all further documents and development results related to the realization are generated.

    The Technical Requirements and the System Architecture are object-oriented models that can be easily integrated as a specification for the implementation. During the implementation new-technical-objects might be created, for technical reasons, which are additionally integrated into the System Architecture and the Technical Requirements.

    After completing the realization, the first increment is made available to be used.

    Time T 4 to T N-1-Further Increments

    At the time T 4, and as a result of the repeated realization of activity SD1.2 - Description of Application System, a refined version of the preliminary system description is available. Usually, the refinements are within the scope of the overall system functions as defined at the time T 1. They represent a specification of the requirements. However, such refinements may also result in new fields.

    The user-level requirements are defined for the integral parts of the second increment. In this connection, fields that were not taken into consideration before can be described, and those that were available before can be refined. The user-level object-oriented models in particular will be updated and refined. First reactions and feedback from the use of the first increment will be taken into consideration.

    Thus, the User Requirements available in a second version represent the starting point for the refinement and completion of the System Architecture and the Technical Requirements.

    The implementor, e. g. a contractor, expands the already productive system version 1 by the newly generated parts and integrates them within the scope of the integration steps. During the integration tasks, it may be necessary to make changes for system version 1. After the realization has been completed, the second increment is made available for use.

    These steps are repeated for each increment.

    Time T N-Complete System Description

    At the time of T N, User Requirements, System Architecture, and Technical Requirements are complete and have all been submitted. After realization and making the System available for use, the entire System is in use.

    SC.5.2 Cooperation with the Remaining Submodels

    The cooperation with the other submodels corresponds with the scenario to apply the V-Model in an incremental system development.

    SC.5.3 Criteria for the Selection of Scenarios

    The following list of advantages and disadvantages of the object-oriented technology supports the decision making of the object-oriented procedure.

    Advantages:

    Disadvantages: Requirements: The mentioned advantages and disadvantages must be assessed and evaluated in every individual case. They are not applicable for all projects, but have to be assessed with regard to the user-level and Technical Requirements as well as the marginal conditions to be observed.
    Note:

    (1) It is possible that new user-level fields are added in the course of development. This can be problematic for contractual reasons.

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks