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

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,
• incremental development,
• prototyping and
• use of object-oriented methods.

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:

• In order to abstract from special object-oriented methods a procedure valid for all object-oriented methods-as far as possible-is shown.
• Object-orientation is a general concept that can basically be applied for all parts (user-level and technical) of a system. The scenario shows a case where mostly object-oriented concepts are used and where only negligible "conventional" parts exist.1
• The object-oriented supplements are written in italics.

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

Time T 0-Start

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

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

Using predefined classes is to

• speed up the development activities by decreasing the development efforts,
• increase the quality by the integration of "matured" classes,
• base user-level and technically oriented design tasks on available modules in order to come up with more cost-effective solutions,
• promote future developments by evolutionary further development of class libraries as side effects of the system development's spin off.

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:

• All relevant user-level fields should be named and their functions separated from each other.(1)
• The cooperation of fields must be clearly defined for all project members.
• The environment in which the (field-related) system levels are to be developed as well as the overall functionality to be covered in the final version must be clearly defined. To do so, milestones (possibly as baselines with time and function scope) have to be set.

Time T 3-Design of the Technical Solution

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

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

SC.5.2 Cooperation with the Remaining Submodels

SC.5.3 Criteria for the Selection of Scenarios

Advantages:

• Object-oriented methods for the determination of User Requirements, prototyping, and iterative procedures enable the intensive, step-by-step integration of the user in the appropriation. Thus the accompanying validation is already possible during the development stage.
• System with object-oriented development are less sensible with regard to changes as "systems with structured development".
• Systems with object-oriented development can be more easily maintained than "systems with structured development".
• The expressive power of the object-oriented programming languages can be utilized.

• Systems with object-oriented development are subject to various performance risks. These risks may have different causes, starting with the interconnection of classes that are positioned deeply in the inheritance grid, up to the dynamic structure and the deletion of objects. This must be particularly observed in connection with very time-critical real-time systems.
• When setting up the contract, it is necessary to take into consideration changing and incomplete requirements.

• Qualified, OO methodically trained staff,
• OO tools for the methodological (case tools) and technical realization (compiler for OO languages),
• an appropriately organized environment,
• efficient configuration and modification management,
• requirement control in all development cycles,
• risk management at the beginning of each development cycle,
• appropriate and efficient quality assurance measures, both for requirements and loadable and assessable HW/SW system parts,

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

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