Content • Object interaction diagrams:

IMS 5024

– Sequence diagrams – Collaboration diagrams

• • • • •

Object orientation (3)

Reality of ISD Taxonomy of ISD methods Place in ISD Evaluation of Object orientation Reading list www.monash.edu.au 2

www.monash.edu.au

Object interaction Models

Sequence diagrams

• Sequence diagrams illustrate interactions that occur between the actors and objects in the system in order to carry out the behaviour specified in the scenario (Modelling behaviour, p. 103). Arranged in time sequence. • Collaboration diagrams shows interaction organized around objects and their messages to each other (Satzinger and Orvik, 2001)

Object 1

Object 2

Create Message1() Message2() Message3() Message4()

www.monash.edu.au

www.monash.edu.au

3

4

Example of a use case description (Scenario)

Interaction in this case is

• Sue approaches the car park and can see that the full sign is off • Sue’s car arrives at the entrance to the car park • Her car’s arrival at the barrier is detected • Sue inserts her card in the card reader • The card is recognized as one that is known • Sue’s card is returned • The entrance barrier is raised • Sue drives into the car park • Her car’s departure is detected • The barrier is lowered (Britton & Doake, 2000)

• Between the actor Sue (car driver) • and objects from the classes Car Park, Valid Cards, Card Reader, Full sign, Barrier and Sensor • As we draw the sequence diagram we ask questions that is not part of requirements and is thus moving from analysis to design. ((Britton & Doake, 2000)

www.monash.edu.au

www.monash.edu.au

5

6

1

:Card reader

:CarPark :Sensor

:Valid Cards

:Barriers :Full Sign

Full sign off

Differences?

Car present Check spaces available Yes Card number

• Show exchange of information between object in the system not just actors and system • Identify gaps that needs to be filled in • Show early design decixsions

Card number Card ok Card returned Raise Car not present Lower

Decrement spaces Check spaces available Yes

(Britton & Doake , 2000) www.monash.edu.au

www.monash.edu.au

7

8

Scenario for a card that is not recognised

Collaboration diagrams

•

• Show objects (rectangles)

• • • • •

• Lines between objects (lines) • Numbered arrows show the order in which they occur

• •

www.monash.edu.au

www.monash.edu.au

9

10

Sequence diagram :CarPark

:Sensor

Sue approaches the car park and can see that the full sign is off Sue’s car arrives at the entrance to the car park Her car’s arrival at the barrier is detected Sue inserts her card in the card reader The card is not recognized as one that is known A message is displayed to say that the card has not been recognized The card is returned Sue drives away (Britton &Doake , 2000)

3: Check spaces left - yes

Collaboration diagram

:Card reader

: Car Park

:Valid Cards

:Full Sign

2: Car present

1: Full sign off

Full sign off

: Full sign

Car present

:User

Check spaces available Yes

8: Card returned 7: Card not recognized

Card number Card number

5: Card Number

Card not recognized

: Card Reader

Card not recognized

: Sensor

4: Card Number

: Valid Cards 6: Card not recognized

Card returned www.monash.edu.au (Britton & Doake , 2000) 11

www.monash.edu.au

(Britton & Doake , 2000)

12

2

Examples of expanding the models to include design issues and implementation issues

Reality of ISD (Review)

Application domain

Conceptual models

Formal Models (Britton & Doake, 2000)

Implementation domain Blum, I., 1994. A taxonomy of Software development Methods. Communications of the ACM, Vol37, No11

www.monash.edu.au

www.monash.edu.au

13

14

Reality in Application domain

Reality in Implementation domain

• Conceptual model - Descriptive model (not the same as DB conceptual model) • Response to the application domain need • Not formal ito software product • Quality, correspondence – subjective. Called validation • Need application domain experience

• Prescriptive model – establish how software product works • Unambiguous requirements for construction • Formal ito mathematics and logic • Correctness - verification • Verification is binary and objective • Formal models express criteria for product acceptance

www.monash.edu.au

www.monash.edu.au

15

16

Tension between the two:

Hard systems thinking

• Problem statement – not formal. Need a formal model to create a verifiable model

• One correct solution for a problem • Manage complexity by dividing system into elements, top down • Functional analysis (understanding and design) ex in ISD? • Assume reality is ordered and stable • Develop a representation of reality – use the representation • Danger in this?

• Requirements are subject to change www.monash.edu.au

www.monash.edu.au

17

18

3

Functional analysis of a system?

Soft systems thinking

• What do we get?

• ‘Let us conceive of this part of the world as a system’ • Interpretation of different perspectives • Many systems – not just one • The system is more than the sum of its parts • Debate of different perspectives and experiences • Methods? (participative, iterative) • Design is seen as learning – develop requirements for change • Problem? www.monash.edu.au

www.monash.edu.au

19

20

Soft systems thinking of a system

Dialectic systems thinking

• What do we get?

• Assumption – world is always changing • Reality is: Totality of related contradictions • Dialectic approach takes serious different perspectives – see them as views of the world that is dynamic and pervaded by contradiction. • Question the assumption of harmony, order and common interest www.monash.edu.au

www.monash.edu.au

21

22

What do we get when we apply dialectics?

Thinking in Object orientation

• Identify contradictions

• Hard Vs Soft ??

• Identify the dominant assumptions • Negotiations, compensations or compromise

• Perspective – Objective vs Subjective – Nature of the organisation

www.monash.edu.au

www.monash.edu.au

23

24

4

Develop a framework for a taxonomy for ISD methods

Categories

• Type of orientation:

Conceptual

Quadrant I: Developing and understanding the problem and expressing the solution

Quadrant II: Transform nonimplementation concepts into implementation concepts

Formal

Quadrant III: Represent properties to facilitate reasoning about problem and solution

Quadrant IV: Create correct implementation units

Problem oriented

– Problem oriented methods – human comprehension, document decisions – Product oriented methods – formal model of the programmed system

• Type of model: – Conceptual model – domain formalisms and some degree of formality (if only syntactically) – Formal model – criteria for correctness and acceptance www.monash.edu.au

www.monash.edu.au

25

26

Evaluation of Object oriented modelling Problem oriented Conceptual

Formal

Structured analysis Entity relationship modelling Logical construction of systems Modern structured analysis Object oriented analysis

Product oriented

Object orientation view of ISD

Product oriented Structured design Object oriented design

Objectives

Development group

PSL/PSA

Levels of abstraction

JSD VDM

Stepwise refinement Proof of correctness Data abstraction JSP Object oriented programming

Object system

Hirschheim et al see reading list

Change process

Object system

Environment

www.monash.edu.au

www.monash.edu.au

27

28

Reading for next week • Hoffer, J.A; George, J.F; Valacich, J.S. (1999). Modern Systems analysis and design. Second Edition. Addison Wesley, USA. Chapter 8 and 9. • Bansler, J. Bodker, K. (1993). A reappraisal of structured analysis: Design in an organizational context. ACM Transactions on Information Systems, Vol 11, No 2, pp. 165 193. www.monash.edu.au 29

www.monash.edu.au

5