1

Tony Busker

a.l.j.busker@hro.nl

Object Oriented Software Development 1

2

Ervaring: 25 jaar ervaring in (technische) software ontwikkeling in de grafische industrie (productieautomatisering, beveiliging, publishing, ...)

Rollen: architect, senior system ontwerper, coach, consultant, projectleider, ...

Ervaring

3

Agenda

The capsizing of the warship Vasa

Object-Oriented topics

Objects and Classes

Concept Mapping

The Golden Hammer

4

The ‘Vasa’ disaster (1) - bouw

The armament of 64 guns of 24 pounds made the Vasa the most

powerful ship of her time

In 1625, the Swedish King Gustavus ordered the Dutch shipwright Hendrick Hybertsz to build a large warship. The Vasa, a 64-gun warship was built in Stockholm and launched in 1628. The dimensions of the ship were 47,7 × 11,2 × 4,8 m.

5

The ‘Vasa’ disaster (2) - capsizing

The Vasa is infamous, however, because it sank on

its maiden voyage without ever leaving the harbor

The Vasa fired his salute...

6

The Vasa was recovered almost completely intact 333 years later.

The Vasa (3) - recovery

7

The ‘Vasa’ disaster (4) restoration

After 30 years of restoration, the entire ship is now on display in

Stockholm.

Examples of the extravagant decoration of the Vasa

8

The ‘Vasa’ disaster (5) lessons learned

No documented user requirements

Difficulties in dealing with changing requirements

Don’t know how to say ‘no’ to a customer

Inadequate testing procedure

Too much attention for details

Unexpected longer lifecycle of the product

A model of the Vasa

9

Why is software difficult to handle?

Difficult and complex to construct

Impossible for the individual developer to comprehend all the subtleties of its design

Future users and customers have a hard time fully accurately specifying system requirements

Difficult to manage ‘drifting’ requirements

10

The illusion of simplicity

Problemdomain

Solutiondomain

11

Large software systems generally exceeds the human intellectual capacity

Complexity

Traditional and ad hoc software designmethodologies do not minimize complexity

We are forced to consider more disciplined ways to master complexity

12

Object Orientation is a technology that enables us to implement good software

practices

Data Hiding Modelling

Major characteristics of Object Technology

From Chaos to Classes

13

Object-oriented topics

Complexity Information hiding Hierarchy Decomposition What is a class? What is an object ?

14

Why is software often complex?

Complexity of the problem domain, and therefore, to manage the system requirements

Difficulty of managing the development process

The flexibility that is possible through software

The problems associated with the characterizing the behaviour of discrete systems

15

How to deal with complexity (1)

First step in attacking unrestrained complexity

Discover the relevant abstractions in the problem domain

16

Information Hiding principle

Encapsulate details by providing barriers among different abstractions

17

How to deal with complexity (2)

Second step in attacking unrestrained complexity

Discover the important hierarchies in the problem domain

18

‘Part Of’ Hierarchy

Most complex systems can be decomposed into a hierarchy of parts

aircraft

engine wing tail

compressor combustor turbine

blade shaft

19

‘Is a’ Hierarchy

Most systems can also be decomposed into a series of hierarchies that emphasize the relationships between internal system components

engine

jet propeller rocket

ramjet turbofan

Pratt & Whitney General Electric

20

How to deal with complexity (3)

Third step in attacking unrestrained complexity

Decomposition into a collection of objects that cooperate to achieve some desired functionality

21

Procedural decomposition

Breaking down the problem into a large number of communicating procedures

Rapid increase of complexity

P1

P3

P2

P4

P5P6

D1D2

P7

22

Object-Oriented decomposition

Breaking down the problem into a number of objects that communicate through well-defined interfaces

Slow increase of complexity

O1

O3O4

O2

23

Formal Definition of An Object

An object has state, behavior and identity; the structure and behavior of similar objects are defined in their common class

Formal Definition of An Object

An object has state, behavior and identity; the structure and behavior of similar objects are defined in their common class

Objects are tangible, unique entities that exhibit some well-defined behavior

What is an object ?

24

What is a class?

A class represents a set of objects that share a common structure and a common behavior

25

The problem domain

The solution domain

Where are the objects coming from?

26

Concept Maps

Software engineers

Domain expertsFuture users

Simple & effective medium toexpress ideas and share concepts

ManagersSystem Architects

27

Simple and attractive means of finding the key concepts andthe relationships between them.

Verification of requirements

Understanding the domain

Finding candidate (sub)components & classes, and the relationships between them

Relations between key concepts

28

What is a concept?

A concept is an idea or notion we have of the problem domainA concept is an idea or notion we have of the problem domain

Each concept has a label

The concept ‘car’ is a label which is usedto represent an object which has four wheels, an engine and a steering wheel.

29

Different kind of concepts

Concreet

ongrijpbaar

Event Rol

autoproject

database update lezer

30

Meaningful relationships

A proposition consists of two or moreconcepts which are linked togetherA proposition consists of two or moreconcepts which are linked together

‘A reader is interested in a journal’

‘A division consists of departments’

‘The project has a project leader’

‘A car is a vehicle’

31

Concepts and Links

Simple concepts and links:

reader

journal

is interested in

carproject

has a

projectleader

vehicle

is a

Concepts correspond to nounsLinks correspond to verbsConcepts correspond to nounsLinks correspond to verbs

32

projects

ICT

systemdesigner

professionals

Vitatron DA+

have

such as

works for

such as

development team

realized by

is part of

supports

takes part in

consists of

Invoking several concepts

33

A concept map is like a roadmap.It shows some of the routes that connectconcepts in order to give a meaningfulrepresentation of the domain

A concept map is like a roadmap.It shows some of the routes that connectconcepts in order to give a meaningfulrepresentation of the domain

Gives focus on the essence of a problem

Helps in validation of requirements

Prevents ‘analysis paralysis’

Common ground for understanding among stakeholders

Domain representation

35

Levels of AbstractionHint 1: Create a glossary, especially

covering ambiguous terms

Hint 2: Choosing good names for links and concepts right from the start is very important!

Hint 3: Use different colors or variable thickness of ovals to indicate the level of abstraction

Hint 4: For ease of survey, use ‘nested’ concept maps for complex problem domains

Concept hierarchy

Supporting concepts

Specific concepts

Key concepts

36

Front-end to OO Development

Three types of links : projection links (‘get’, ‘display’, ‘move’) abstraction links (‘is a’, ‘can be’, ‘such as’) partitioning links (‘consists of’, ‘has’, ‘is part of’)

Concepts are (potential) classes or componentsLinks describes the relationship between them

37

The Basis of the Object Model

Concept map

Concepts

Projection links

Abstraction links

Partitioning links

Object model

Components, Objects, Events

Object Operations

Inheritance Relationships

Aggregation Relationships

44

Anti-Patterns: Golden Hammer

The Golden Hammer anti-pattern (also known as ‘Head-in-the-sand’) occurs when a developer uses favorite software concepts or tools obsessively.

When your only tool is a hammer, everything else is a nail!

45

Anti-Patterns: Golden Hammer

The Golden Hammer may result in the misapplication of a favored tool or concept.

Anecdotal evidence: ‘Our database is our architecture’

46

Anti-Patterns: Golden Hammer

A common variation of Golden Hammer occurs when designers learn a single design methodology or a few design patterns and apply them excessively to all phases of software analysis, design and implementation.

Expand your horizon!