How can I get better with OOP

4. Object-oriented software development

After the brief excursion into the general principles of program development, we now want to turn to object-oriented software engineering (often also abbreviated as OOSE). There are also many popes in object-oriented application development whose methods are supposed to lead to the goal. Here we want to take a closer look at the method of Coad and Yourdon. In principle, all object-oriented methods are quite similar. A distinction is usually made between object-oriented analysis and object-oriented design, whereby the design always has to take place after the analysis. As a rule of thumb, the
  • "What"
    (What is the problem?)
and in design that
  • "How"
    (How can the system be programmed on the respective hardware platform with the programming language available?)
is defined.

The results of these two phases are usually put on paper in graphic form. a great advantage of the Coad and Yourdon method is that the same notation is used for analysis and design.

Many points discussed earlier, such as

  • Formation of completed modules
  • Avoidance of side effects under the modules
are given directly by the object-oriented programming and the restrictions of the object-oriented compilers.

4.1. Object Oriented Analysis (OOA)

According to the approach of Coad and Yourdon, proceed according to the following scheme:
  • Identify objects
  • Identify relationships
  • Identify subjects
  • Identify attributes
  • Identify services (= methods)

4.1.1. Identify objects

As a rule, one can proceed here in such a way that one reads the specifications of the software carefully and turns the nouns into objects. To find objects you have to search for:
  • existing structures
  • other systems
    e.g .: aircraft in an air transport system
  • devices
    e.g .: thermostat in a heating system
  • historical events
    e.g .: incident in a nuclear reactor control system
  • The role of people in the system
    E.g. car owner, clerk in a car registration system
  • organizational units
    e.g .: state in a vehicle registration system

4.1.2. Identify relationships

A distinction is made between the following structures:
  • Classification structures
  • Collection structures
The classification structures (in German: Gen-Spec-Structures) are nothing other than the class hierarchies known from C ++. The whole-part structures represent the whole and its parts and have (yet?) No equivalent in any object-oriented programming language.


4.1.3. Identify subjects

As described in 3, humans are only able to see 4 to 7 things at the same time. This is why it is often necessary in large programs to combine several objects into one subject. If the combination of up to 7 objects still results in more than 7 subjects, the process must be repeated and the subjects combined into super subjects until fewer than 7 subjects remain.

4.1.4. Identify attributes

With the attributes one has to consider which values ​​or states or other properties have to be saved in the object. Objects with one attribute usually make no sense. It is better to assign this attribute to another object and to abandon this object. Sometimes it may also be necessary to change the object structures due to the attributes.


4.1.5. Identify services (= methods)

When defining the services, one must first consider which states the objects can assume. Each state transition corresponds to a method (of a service).


There are also necessary services:

  • create an object
  • Setting of attributes
  • Deleting attributes or objects
  • Computing attributes
  • Monitoring (monitor function)
Likewise, every communication link between objects means that one object calls another's method. So here, too, additional methods can arise.

4.2. Object Oriented Design (OOD)

The object-oriented analysis, where the software is defined from the user's point of view, is followed by the object-oriented design. In this phase the software-technical concept is determined.

Nothing else happens here than that the result of the OOA is improved and expanded to include objects that are specifically necessary for the target environment. The OOD is divided into four steps:

  • Design of the application area
    z. B: Reuse of existing classes, adapting the type of inheritance, tuning measures
  • User interface design
    Adding special services, attributes and classes
  • Design of the processes
    Viewing parallel processes separately simplifies design and implementation
  • Data management design
    Data design, adding additional services and / or classes

4.3. notation

For the OOSE, Coad and Yourdon use an extended entity relationship model that is well known from database development. You use the relationships "has" (collective structure) and "is son of" (classification structure).

For example, it could look like this:

It is also easy to imagine combining the 3 objects tractor, cable winch and Hannomag 44A as a subject back unit in a larger program system.

[Back | Table of Contents | Next | Make comments | View notes]