SC.5 Object-Oriented Development
SZ.5 Objektorientierte Entwicklung
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.
- 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.
- 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
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.
- 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
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.
The cooperation with the other submodels corresponds with the scenario to apply the V-Model in an incremental system development.
The following list of advantages and disadvantages of the object-oriented technology supports the decision making of the object-oriented procedure.
- 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.
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.
- 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.