Download 1 Introduction

tion about details of the system and subsystems, but the main idea with dividing into subsystems is to get
better understanding of the system. This can become a issue that causes a lot of different problems.
• If the system is peculiar divided it might become an impossible task to assemble the parts into one
whole system again.
• The subsystems could be divided in such way that the same code exists at several places. Data could be
spread out on several location within the program. At the worst case these to can exist at the same time
yielding that space, speed and functionally gets to suffer.
• The whole system becomes a mess because nobody understands the whole picture. If it is not “spaghetti
code” there surely is a risk for “ravioli code”.
• The core functionality of the system gets spread out through out the whole code.
2.3 Object-Orientation does not come with the language!
Object-orientation, and the languages that claims to be object-oriented, often gets blamed when something
goes wrong due to the features that object-orientation should help dealing with. There are cases where
organisations change development languages from e.g a functional language to an object-oriented language
in hope to develop object-oriented systems that are easier to develop, maintain etc. After a while it stands
clear that the only thing that happened was that the syntaxes were exchanged, the language was different
but noting was new.
The core here is that it takes more than an object-oriented language to write an object-oriented system.
Object-orientation is not as trivial as it sometime seems, it is not just an addition to the language - it is a
new way of thinking. Further, the new way of thinking is not just about creating and finding the correct
objects, but about the whole structure of the system. Finding objects only takes the system design half-way,
the rest of the way is making the objects work together and this is where the picture often gets ugly.
The characteristics of an object-oriented language, that separates it from other types of languages, is the
notion of polymorphism and inheritance. If these two are not used in combination, the so called object-oriented program could just as well have been developed in another, non-object-oriented, development language. Object-orientation does not put a lot of nice features into the code, it only provides the means to do
so, you still have to put in every feature you want your self (neither this is as trivial as might seem?!).
2.4 New design
How many times is a new design directly understandable due to the familiarity of the constructions used?
The answer of that question for most software engineers would probably be: not many times, if any!
To better illustrate the question an example, a comparison, between a software system and an car engine is
made.
• When you are looking at a new software system, the design documents1 are examined to get the description of how the system is built up. Mostly the design does not tell what is actually wanted, so looking
into the code becomes the only solution.
• A new engine arrives for a check-up (this engine is totally new and no recognizable parts exists in it).
Together with the engine a number of books describing maintenance and the parts of the engine are
delivered. The books describe nothing of interest, so instead the engine is disassembled in order to
understand how it works!2
1. The design document contains everything above pure code level.
2. Not even a car engineer would understand a engine who’s components where totally unknown down to the smallest parts.
3