Object-Orientation Wolfgang Emmerich

1

© Wolfgang Emmerich, 1999

Outline Problem of software system complexity ■ Approaching a solution ■

• Human limitations • Underlying principles

Development of the object-oriented approach ■ Assessment of object-orientation ■

© Wolfgang Emmerich, 1999

2

1

Software System Complexity “Consisting of or comprehending various parts united or connected together; formed by a combination of different elements” ■ Any sizeable system: ■

• developed by a team in a lengthy process, • impossible for individual to comprehend fully, • difficult to document and test, • potentially inconsistent or incomplete, • subject to change. ■

But : Software engineering cannot yet provide fundamental laws to explain © Wolfgang Emmerich, 1999 phenomena and approaches

3

Reasons for Complexity Grady Booch’s four reasons for complexity of software-intensive systems: 1 Nature of the problem domain ■

• requirements, • decay of systems

2 Complexity of process • management problems, • need for simplicity

© Wolfgang Emmerich, 1999

4

2

Reasons for Complexity (continued) 3 Dangerous potential for flexibility of software • “Software is flexible and expressive and thus encourages highly demanding requirements, which in turn lead to complex implementations which are difficult to assess”

4 Characterising behaviour of systems • “The task of the software development team is to engineer the illusion of simplicity” © Wolfgang Emmerich, 1999

5

Systems and Subsystems “An organised or connected group of objects; a whole composed of parts in orderly arrangement according to some scheme or plan” ■ System: ■

• • • •

boundary environment character emergent property

Systems: interconnected subsystems ■ Potential for inconsistency and © Wolfgang Emmerich, 1999 incongruity ■

6

3

Attributes of Complex Systems ■

Booch’s five attributes of a complex system: • Hierarchical and interacting subsystems • Arbitrary determination of primitive components • Stronger intra-component than intercomponent links • Combine and arrange examples of a few kinds of subsystems • Evolution from simple to complex working systems © Wolfgang Emmerich, 1999

7

Simplifying Complex Systems Usefulness of abstractions common to similar activities, e.g. driving different kinds of motor vehicle ■ Multiple orthogonal hierarchies e.g. structure and control system ■ Prominent hierarchies in objectorientation ■

• “class structure” • “object structure” ■

e. g. engine types, engine in a specific car © Wolfgang Emmerich, 1999

8

4

Class vs. Object Structure Objects

D1

C1

C3

D3

D2

C2

D4

C4

C5

D5

D6

C7 D7

C6

ss Cla

es

D8

© Wolfgang Emmerich, 1999

9

Approaching a Solution ■

Hampered by human limitations: • dealing with complexities • memory • communications

■

Principles that will provide basis for development: • Abstraction • Hierarchy • Decomposition © Wolfgang Emmerich, 1999

10

5

Abstraction & Hierarchy Concepts of fundamental importance ■ Abstraction: assists people’s understanding ■

• grouping, • generalising, • ‘chunking’

of information or ideas. ■ Hierarchy: • Recognition of higher and lower orders, • Accumulation of attributes at higher level, • Association of fewer attributes with lower © Wolfgang Emmerich, 1999 level and greater n mber

11

Decomposition Handling complexity on the principle of ‘divide and conquer’ ■ Two forms of decomposition: ■

• process-oriented: according to steps / functions • object-oriented: according to behaviour of autonomous objects ■

Both valid, but current claims for superiority of OO • stronger framework • reuse of common abstractions change • resilient © Wolfgang Emmerich,under 1999

12

6

A function/data composition Transaction

Get transaction Open

Passbook Open

Checking Open

Withdraw

Passbook Withdraw

Bonus Open

Checking Withdraw

Bonus Withdraw

Deposit

Passbook Deposit

Bonus Deposit

Checking Deposit

13

© Wolfgang Emmerich, 1999

An object-oriented Decomposition Open Deposit Withdraw Account ihs

ihs

Other object(s)

ihs

Passbook Account

© Wolfgang Emmerich, 1999

ihs

Checking Account

Bonus Account

14

7

Adding a new Market Account

Transaction

Get transaction Open

Passbook Open

Withdraw

Checking Open

Passbook Withdraw

Bonus Open

Market Open

Passbook Deposit

Checking Withdraw

Market Withdraw

Deposit

Checking Deposit

Bonus Withdraw

Bonus Deposit Market Deposit

15

© Wolfgang Emmerich, 1999

Adding a new Market Account Open Deposit Withdraw Account ihs

ihs

Other object(s)

ihs ihs

Passbook Account

Checking Account

Bonus Account

Market Account

© Wolfgang Emmerich, 1999

16

8

Model of OO Development

Dynamic Model Static Model Class structure Logical Object structure Class structure Model Object structure Class structure Object structure Module architecture Physical Process architecture Model

17

© Wolfgang Emmerich, 1999

History of Object-Orientation Time

DCOM CORBA

Java

UML COM OOAD

1990 Eiffel

DCE C++ 1980

Sun ONC

1970 Distributed Systems © Wolfgang Emmerich, 1999

Smalltalk

Information Hiding Simula-67 Programming Languages Software Engineering 18

9

Structured Methods SSADM (Cutts 1987), SA (de Marco 1978), SADT (Ross 1977). ■ Existing structure methods treat separately : ■

• functions (behaviour) and • data (information held) ■

Problems: • Difficulties with maintenance (because need knowledge of data storage) • Division of knowledge (whereby “what” is transformed into “how”)

Wolfgang Emmerich, 1999 of ■ ©Instability

functions

19

Object-Oriented Methods ■

Better able to cope with change Item Object from application Long-lived information structures Passive object’s attribute Sequence of behavior Interface with outside world Functionality

Freq. Of Changes Low Low Medium Medium High High

OO focuses analysis on problem domain ■ Promotes reuse ■ Continuity of representation ■

© Wolfgang Emmerich, 1999

20

10

Suggested object-oriented Methods Coad & Yourdon (91) for OOA ■ Booch (94) also for OOA ■ Jackson (83) for system design ■ Jacobson (92) OOSE ■ Approach of this course based on Jacobson because employs ‘use cases’ throughout ■

• essential user role • focus on domain • integration in process ■

All likely to be superseded by ‘retreads’ employing the UML

© Wolfgang Emmerich, 1999

21

Drawbacks of OO ■

Large scale reuse not yet achieved

■

Few available reusable libraries

■

Managing reusable libraries is a problem

■

Extensive retraining before pervasive

© Wolfgang Emmerich, 1999

22

11

Summary Functional decomposition

Complex Real-world System

Abstraction Hierarchy Decomposition

Complex Software System

OBJECT ORIENTATION

© Wolfgang Emmerich, 1999

23

Object-Orientation (Cont’d) Wolfgang Emmerich

© Wolfgang Emmerich, 1999

24

12

Lecture Overview ■

Basic principles of object-orientation • • • • •

■

objects classes of object encapsulation inheritance polymorphism

Object-orientation vs. structured methods

© Wolfgang Emmerich, 1999

25

What’s object-orientation all about ? ■

Principles and techniques for system modelling which: • aim to produce a model of a system • provide notations and methods

■

Advantages for software development: • reduces the ‘semantic gap’ between reality and models • makes system understanding easier • allows local modification to models © Wolfgang Emmerich, 1999

26

13

An Object ■

An object is: "An abstraction of something in a problem domain, reflecting the capabilities of a system to keep information about it, interact with it, or both” (Coad & Yourdon 91)

■

"An entity able to save a state (information) and which offers a number of operations (behaviour) to either examine or affect this state" (Jacobson ©92) Wolfgang Emmerich, 1999

27

Objects & Abstraction "An abstraction denotes the essential characteristics of ■ an object that distinguish it from all other kinds of objects ■ and thus provide crisply defied conceptual boundaries, ■ relative to perspective of viewer © Wolfgang Emmerich, 1999 " (B h 94) ■

28

14

Sample Objects ■ ■

From a “Food Manufacturing Company” Passive objects : • one individual sack of lentils • invoice 63501 sent to A Farm, Lincolnshire

■

Active objects : • lorry "M235 BCM" • van "N683 CNM"

■

Human agents : • Richard Green • David Brown (Executive) • Hill, D (Truck driver)

■

Structure objects : • Marketing Department © Wolfgang Emmerich, 1999

29

Attributes and Associations Any object has both attributes and associations ■ Attributes characteristic features or properties name / value pairs ■ Association any kind of link or connection between one object and one or a set of other objects ■ Characteristics private to an object best represented as attributes ■

© Wolfgang Emmerich, 1999

30

15

Associations are Relationships Two essential oppositions : ■ aggregation vs reference relationships ■

• aggregation relationships where connection creates composite objects from simple objects • reference relationships where connection only refers to another object ■

static vs dynamic relationships • static relationships, where coupling of objects is stored over a long period of time, • dynamic relationships, which are established by operations 31

© Wolfgang Emmerich, 1999

Viewpoint of Association View and purpose affect definition of assoc. ■ Partition or division: Association indicating new objects created by splitting other objects apart , e.g. A book ‘consists of’ or ‘can be divided into’: title page, introduction, chapters, conclusion, index ■ Aggregation or amalgamation: Association indicating new objects created by adding other objects together 32 Covers, ©e.g Wolfgang Emmerich, 1999binding, and end papers are ■

16

Structure and Behaviour of an Object ■

Gordon, Junior Librarian, as object Attributes

M

Operations

Name: Gordon Position: Junior Librarian Age: 25 Salary: 12,000 ......

T W T F

Loan out books Rename position Amend salary

Relations

t

ble

isor

en pm ui Eq

et a Tim

v Super

33

© Wolfgang Emmerich, 1999

Behaviour and Structure ■

Example in a Food Company One packet of herbal tea Attributes

Operations

Price: 2.95 Weight: 1kg ..........

Is Stored Is Sold Is Delivered

Relations

Decide policies Attend meetings Manage Board meetings

Marketing Department

Lorry M235 BCN

Driver Hill, D Trailor SSFG12

Operations

Age: 45 Sex: Male

Managing Director

Order: 57891 Delivery: Supplier: A Farm 57891A

Reg: M235 BCN Weight: 7.5 tons Fuel level: 40 litres

Attributes

Relations

Relations

Attributes

Richard Green

Operations Deliveries Goods Repeat Until End Go To Destination Unload Goods EndRepeat Refuel....

© Wolfgang Emmerich, 1999

Attributes

Operations

Staff: 50 people Location: High St

Market All Products Choose New Products Determine Market Niches

Relations Marketing Director Marketing Team

34

17

Object Identity Separate objects each have a unique object identity Attributes

Operations

Attributes

Operations

Name: Gordon Position: Junior Librarian Age: 25 Salary: 12,000

Loan out books

Name: Gordon Position: Junior Librarian Age: 25 Salary: 12,000 ......

Loan out books

Rename position Amend salary ......

Relations

nt

rv i sor Su pe

e ipm

r so vi

Equ

t en pm ui Eq ble

et a Tim

r pe Su

Rename position Amend salary

ble

Relations

Tim et a

■

35

© Wolfgang Emmerich, 1999

Dynamics of Objects ■

Dynamics are generated through stimuli or messages passing between objects • Receipt of a stimulus cause operation by (or in) the receiving object • Receipt of a stimulus can trigger sending of another stimulus to other objects 2 3 4 1

© Wolfgang Emmerich, 1999

36

18

Encapsulation “Behaviour and information are encapsulated in objects” (Jacobson 1992) ■ “Encapsulation is the process of compartmentalising the elements of an abstraction that constitute its structure and behaviour” (Booch 1995) ■

• Only the 'interface' of an object is 'visible' to other objects • Need, and can, only know operations on an object, not how they work nor about other characteristics • Necessary prerequisite for information hiding37

© Wolfgang Emmerich, 1999

Encapsulation (cont’d) ■

Encapsulation and abstraction are complementary concepts • Abstraction focuses on the observable characteristics and behaviour of the object • Encapsulation focuses on the representation derived from these characteristics

■

Encapsulation requires : • explicit division between abstractions • clear separation of their concerns

© Wolfgang Emmerich, 1999

38

19

Classes of Objects Classes represent groups of objects which have the same behaviour and information structures. ■ Class is a kind of type, an ADT (but with data), or an 'entity' (but with methods) ■ Classes are the same in analysis and design ■ “A class represents a template for several objects ...Objects of the same class have the same definition both for their 39 ©operations Wolfgang Emmerich, 1999 and for their information ■

Sample Classes ■

From a Food Company Product Attributes Price Weight .......

Employee Operations Is Created Is Sold Is Delivered

Attributes Age Weight Sex

Relations

Relations

Order Delivery Supplier

Role

Truck Attributes Registration No. Weight Fuel

Relations Driver Trailor

Operations Joins Company Leaves Company Reviewed Promoted Demoted

Department Operations Deliveries Goods Repeat Until End Go To Destination Unload Goods EndRepeat Refuel....

© Wolfgang Emmerich, 1999

Attributes

Operations

Personnel Number Location ........

Hire new staff Dismiss new staff

Relations Director Marketing Team ..........

40

20

Objects are Instances of Classes ■

■

■

Every object is an instance of a single class A class defines the possible behaviours and the information structure of all its object instances. Different instances may have their operations activated in different ways and in different sequences; hence they may be in different states.

Truck M235 BCN Attributes

Operations

Reg: M235 BCN Weight: 7.5 tons Fuel level: 40 litres

Deliveries Goods Repeat Until End Go To Destination Unload Goods EndRepeat Refuel....

Relations Driver: Hill, D Trailor: SSFG12

41

© Wolfgang Emmerich, 1999

Instantiation of objects ■

Instantiation of a class generates an object, an instance of its class

Truck Attributes

■

Instantiation demands a specific create operation in every class

© Wolfgang Emmerich, 1999

Registration No. Weight Fuel

Relations Driver Trailor

Operations Create (Truck) Deliveries Goods Refuel

Delete (Truck)

42

21

Inheritance Inheritence: a relationship between different classes with common characteristics ■ “If class B inherits class A, then both the operations and information structure in class A will become part of class B” (Jacobsen 92) Clerical Worker ■ Major benefits are simpler, clearer classes, at higher levels of abstraction ■

Warehouse Admin

Office Admin 43

© Wolfgang Emmerich, 1999

Generalisation & Specialisation Generalisation - Creation of an 'ancestor' ■ Specialisation - Creation of a 'descendant' ■

Employee

Is_a Managing Director

Clerical Worker

Warehouse Admin

© Wolfgang Emmerich, 1999

Office Admin

44

22

Multiple Inheritance ■

One class inherits from two or more existing classesAdmitted Person

CourseLeader

Student

Teaching Assistant

Allows more complex class structures, but understood ■ ©less Wolfgangeasily Emmerich, 1999 ■

45

Multiple Inheritance & Ambiguities ■

Name clashes :

■

Incorrect repeated inheritance (..A..)

(..A..)

(..A..)

(..A..) ? ?

© Wolfgang Emmerich, 1999

46

23

Polymorphism System behaviour is defined by the dynamic behaviour of instances of classes ■ “Polymorphism means that the sender of a stimulus does not need to know the receiving instance's class. The receiving instance can belong to an arbitary class” (Jacobsen 1992) ■ Polymorphism enables different instances of different classes to be associated ■ A receiving instance interprets stimuli 47 to its own class ©according Wolfgang Emmerich, 1999 ■

Structured Methods SSADM (Cutts 1987), SA (de Marco 1978), SADT (Ross 1977). ■ Existing structured methods treat separately ■

• functions (behaviour) and • data (information held) ■

Problems: • Difficulties with maintenance (because need knowledge of data storage) • Division of knowledge (whereby “what” is transformed into “how”)

Wolfgang Emmerich, 1999 of ■ ©Instability

functions

48

24

Object-Oriented Methods ■

Better able to cope with change Item Object from application Long-lived information structures Passive object’s attribute Sequence of behavior Interface with outside world Functionality

Freq. Of Changes Low Low Medium Medium High High

OO focuses analysis on problem domain ■ Promotes reuse ■ Continuity of representation ■

© Wolfgang Emmerich, 1999

49

Suggested object-oriented Methods Coad & Yourdon (91) for OOA ■ Booch (94) also for OOA ■ Jackson (83) for system design ■ Jacobson (92) OOSE ■ Approach of this course based on Jacobson because employs ‘use cases’ throughout ■

• essential user role • focus on domain • integration in process ■

All likely to be superseeded by ‘retreads’ employing the UML

© Wolfgang Emmerich, 1999

50

25

Drawbacks of OO ■

Large scale reuse not yet achieved

■

Few available reusable libraries

■

Managing reusable libraries is a problem

■

Extensive retraining before pervasive

51

© Wolfgang Emmerich, 1999

Summary ■

Basic concepts: • object: entity combining essential characteristics abstracted from a domain • class: expression of objects’ common characteristics • encapsulation: combination of attributes & operations in a single self-contained object • inheritance: relationship between super-class and sub-class defining levels of commonality • polymorphism: facility allowing stimuli to ignore class of receiving object © Wolfgang Emmerich, 1999

52

26

Summary (Cont’d) ■

Application of concepts enables: • object identification • object modelling • behaviour modelling

© Wolfgang Emmerich, 1999

53

D50: Advances in Software Engineering Requirements Model Wolfgang Emmerich

© Wolfgang Emmerich, 1999

54

27

Lecture Overview ■

■ ■

Object-Oriented Software Engineering (OOSE) from Jacobson et al. The basics of ‘a use case driven approach’ Development of a Requirements Model: • • • •

■

actors use cases interface descriptions problem domain objects

Relevant notations from the UML (Unified Modeling Language) © Wolfgang Emmerich, 1999

55

OOSE Background Originated in Sweden ■ "Object-Oriented Software Engineering A Use Case Driven Approach" by Ivar Jacobson, Magnus Christerson, Patrik Jonsson & Gunnar Overgaard, AddisonWesley , 1992 ■ Pragmatic method based on experience ■ Popular and successful ■ Complete method ■

© Wolfgang Emmerich, 1999

56

28

What comprises a Method? ■

Method described via • syntax (how it looks) • semantics (what it means) • pragmatics (heuristics, rules of thumb for use)

57

© Wolfgang Emmerich, 1999

System Dev. as Building Models ■

3 stages and 5 models ANALYSIS

Requirements Model: captures functional requirements from user perspective

CONSTRUCTION

Design Model: impose implementation constraints on analysis model

Analysis Model: maintainable with logical structure; implementationindependent

TESTING

Test Model: documentation and test results

Implementation Model: system code written from the design model

Seamless, incremental transition between stages and models, iterations possible

© Wolfgang Emmerich, 1999

58

29

Analysis Stage ■

Primary objectives • to determine what the system must do • to embed the software system in its environment

■

Two concerns • to get the right thing • to get the thing right (now and for future)

■

Products

requirements

• Requirements Model • Analysis Model

customer

interfaces use case model domain object model Requirements Model

© Wolfgang Emmerich, 1999

59

Producing A Requirements Model ■

Inputs 1 Derive possible use cases 2 Discriminate between possible use cases 3 Generate use case desciptions 4 Identify associations between use cases 5 Refine & complete use cases & use case model 6 Describe and test user interfaces 7 Describe system interfaces 8 Identification of problem domain objects 9 Check incorporation of requirements

Outputs ■ ©Notations Wolfgang Emmerich, 1999 ■

60

30

Requirements Model: Input & Output ■

Inputs : • User requirements specifications [multi media] • Documentation of existing systems, practices etc. that are to be followed [text, graphic] • Exchanges between developers and users and specifiers [m m]

■

Outputs : • use case model [graphic] • concise descriptions of use cases [text] • user interface descriptions [text ... prototypes] • system interfaces [protocols] © Wolfgang Emmerich, 1999 • problem domain object list (names attrib )

61

Requirements Model: Notations ■

Notations introduced : • use case diagram (system box, ellipses, names, actor icons, actor/case links, and associations) • association (, ) • use case descriptions

© Wolfgang Emmerich, 1999

62

31

Requirements Example Multi-purpose recycling machine

Recycle Machine Receipt

Cans Bottles

Machine must: - receive & check items for customers, - print out receipt for items received, - print total received items for operator, - change system information, - signal alarm when problems arise.

Crates

63

© Wolfgang Emmerich, 1999

Actors ■

An actor is: • anything external to the system, human or otherwise • a user type or category

A user doing something is an occurrence of such a type ■ A single user can instantiate several different actor types ■ Actors come in two kinds: ■

• primary actors, using system regularly • secondary actors, enabling primary actors © Wolfgang Emmerich, 1999

64

32

A Use Case ■

A use case • constitutes complete course of events initiated by actor • defines interaction between actor and system • is a member of the set of all use cases which

■

Use cases together define all existing ways of using the system actor instantiated as user © Wolfgang Emmerich, 1999

initiates

use case

instantiated as initiates

scenario

65

Example Use Case ■

Returning items is started by Customer when she wants to return cans, bottles or crates. With each item that the Customer places in the recycling machine, the system will increase the received number of items from Customer as well as the daily total of this particular type. When Customer has deposited all her items, she will press a receipt button to get a receipt on which returned items have been printed, as well as the total return sum. © Wolfgang Emmerich, 1999

66

33

Use Case Model ■

A use case model • presents a collection of use cases • characterise behaviour of whole system, plus external actors Recycling Machine

Customer

Returning item

Generate report

Change item information

Operator

© Wolfgang Emmerich, 1999

67

Identifying Use Cases Consider situation, ■ Identify actors, ■ Read specification, ■ Identify main tasks, ■ Identify system information, ■ Identify outside changes, ■ Check information for actors, ■ Draft initial use cases [text] ■ Identify system boundary, ■ Draft initial use case model [graphic] ■

© Wolfgang Emmerich, 1999

68

34

When is a Use Case .... ? ■

Discrimination between possible use cases • Estimate frequency of use, • Examine degree of difference between cases • Distinguish between 'basic' and 'alternative' courses of events • Create new use cases where necessary

© Wolfgang Emmerich, 1999

69

Elaborated Example BASIC - When the Customer returns a deposit item, it is measured by the system. The measurements are used to determine what kind of can, bottle or crate has be deposited. If accepted, the Customer total is incremented, as is the daily total for that specific item type. ALTERNATIVE - If the item is not accepted, 'NOT VALID' is highlighted on the panel. BASIC - When Customer presses the receipt button, the printer prints the date. The customer total is calculated and the following information printed on the receipt for each item type: name, number returned, deposit value, total for this type. Finally the sum that the Customer should receive is printed on the receipt. © Wolfgang Emmerich, 1999

70

35

User Interface Descriptions Describe user interfaces ■ Test on potential users, if necessary using ■ simulations or prototypes ■ ■

Operator’s interface Change bottle data Type: Size: Value:

© Wolfgang Emmerich, 1999

71

Problem Domain Objects Object in specification have direct counterpart in the application environment ■ System knowledge obligatory ■ Refinement in stages : ■

• • • • • •

Object noun → Logical attributes → Static associations → Inheritance → Dynamic associations → Operations

© Wolfgang Emmerich, 1999

72

36

Object Examples Object name type Deposit item Can Bottle Crate Receipt Customer panel Operator panel

Attribute characteristic/information : name: string, total: integer, value: Euro width: cm, height: cm width: cm, height: cm, bottom: cm width: cm, height: cm, lenght: cm total cans: int, total bottles: int, ... receipt button: button bottle data: cm, ...

73

© Wolfgang Emmerich, 1999

Summary System development as model building ■ Requirements model “to get the right thing” ■ System use in context via the use case model ■ User interface descriptions ■ Problem domain objects as prelude to class diagram ■

© Wolfgang Emmerich, 1999

74

37