2.6.3. structuring sds

46
2.6.3. Structuring SDs Normally a use case scenario is too long and complex to fit on a single (A4 sized?) SD. We need to structure SDs and decompose them into sub-SDs called by SD references.

Upload: kayo

Post on 24-Feb-2016

36 views

Category:

Documents


0 download

DESCRIPTION

2.6.3. Structuring SDs. Normally a use case scenario is too long and complex to fit on a single (A4 sized?) SD. We need to structure SDs and decompose them into sub-SDs called by SD references. A reference is a pointer to another SD. References may not be circular or recursive . - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 2.6.3. Structuring SDs

2.6.3. Structuring SDsNormally a use case scenario is too long andcomplex to fit on a single (A4 sized?) SD.

We need to structure SDs and decompose them into

sub-SDs called by

SD references.

Page 2: 2.6.3. Structuring SDs

A reference is a pointer to another SD.

References may not be circular or recursive.

Page 3: 2.6.3. Structuring SDs

Let us give a typical example. A simple dataexchange between two systems can be dividedinto 3 phases:

• set-up communication/initialize• exchange data• close-down communication

We can specify the use case “successful dataexchange” as follows.

Page 4: 2.6.3. Structuring SDs

BA

Initialize

Exchange

Shutdown

SD Successful_Data_Exchange

ref

ref

ref

Page 5: 2.6.3. Structuring SDs

The symbol

denotes a sub-SD called name. Thus everySD has a symbolic name also. The keywordref stand for reference.

Then for the above example, we might have:

<name>ref

Page 6: 2.6.3. Structuring SDs

BA A B

“ready_to_send”

“ready_to_receive”

“finished”

“shutdown”

SD Initialize SD Shutdown

Notice these are “handshakes” between A and B.

We will specify the SD “Exchange” later.

Page 7: 2.6.3. Structuring SDs

Note that a sub-SD does not synchronizetimelines.

i.e. either of A or B is free to leave sub-SDExchange without the other leavingsimultaneously.

Here’s another example to clarify the point.

Page 8: 2.6.3. Structuring SDs

BA A B

“hello”

SD Unsynchronised_Ref SD Sub-1

“goodbye”

Sub-1

“what?”

ref

Page 9: 2.6.3. Structuring SDs

Possible executions are either:1. hello2. what3. goodbye (A leaves Sub-1 late)or1. hello2. goodbye (A leaves Sub-1 early)3. what?

Page 10: 2.6.3. Structuring SDs

User System

“username”

“password?”

SD normal_log_in

“my_password”

Precondition: Power is on, operating system is

active, log-in menu is visible.

Postcondition: Power is on, operating system isactive, user is logged in under own profile, user’s

desktop is visible, log-in menu is not visible.

Page 11: 2.6.3. Structuring SDs

We introduce SD interaction operators

• alt : alternative choice of sections• par : parallel execution of several sections• loop : iterative execution of a section• opt : optional section that could be omitted• (exc : exception section to handle errors.)

Page 12: 2.6.3. Structuring SDs

Interaction Operator alt

An operator (possibly with a Boolean guard)used to define two or more alternatives, at most one of which will be taken.

Below, users u1 and u2 compete for thePrinter p.Either u2 wins (top) or u1 wins (bottom)

Page 13: 2.6.3. Structuring SDs

u1 : User u2 : User p : Printer

SD Alternatives

“print_1”

“print_2”

alt “accept_2”

“accept_1”

Page 14: 2.6.3. Structuring SDs

The only possible executions or traces for SDAlternatives are either :1. print_12. print_23. accept_2or1. print_12. print_23. accept_1

Page 15: 2.6.3. Structuring SDs

Interaction Operator par

An operator used to define two or more sections, all of which will be executed simultaneously

Compare par with alt!

Below, u1 and u2 both request aprint job in parallel and both are accepted.

Page 16: 2.6.3. Structuring SDs

u1:User u2:User p:Printer

SD Parallel

par“accept_1”

“print_1”

“print_2”“accept_2”

Page 17: 2.6.3. Structuring SDs

This time there are 6 possible executions . These represent all possible interleavings of the two subsections of par.

1. print_1 1. print_1 1. print_2 1.print_12. print_2 2. accept_1 2. accept_2 2.print_23. accept_1 3. print_2 3. print_1 3.accept_24. accept_2 4. accept_2 4. accept_1 4.accept_1

1. print_2 1. print_22. print_1 2. print_13. accept_1 3. accept_24. accept_2 4. accept_1

Page 18: 2.6.3. Structuring SDs

Interaction Operator loop

An operator (possibly with a Boolean guard, noguard = [true]) used to define a section thatmay be iterated finitely or infinitely many times.

Guard evaluated on each iteration. As well asBoolean guards we can bound the number of iterations.

Page 19: 2.6.3. Structuring SDs

Keywords :(1) loop <m, n>, loop at least m times and at most n

times, for fixed integer constants m, n.(2) loop <m, inf>, loop finitely often, but at least m

times. ( *not* infinitely often).(3) loop <inf, inf> loop at least infinitely

many times.(4) loop <n> = loop <n, n> .(5) loop = loop <1, inf> .(6) [ while <Boolean expression> ]

Page 20: 2.6.3. Structuring SDs

Important note: The parameters m, n are fixed constants, they are not variables which can be changed.

In the following example, the user polls aprinter until the printer becomes ready. When it becomes ready the printer prints the file.

Page 21: 2.6.3. Structuring SDs

Loop <0, inf>

alt “ready?”

“busy”

“ready?”

“ready?”

“yes”

“print(file)”

“printing”

u:User p:Printer

Page 22: 2.6.3. Structuring SDs

Interaction Operator Opt

An expression, possibly with a Boolean guard, [ <Boolean expression> ]

(no guard is the same as [true]) used to define an optional section which may or may not be executed (non -deterministic).

In the next example, A sends to B and may or may not get confirmation in time t< maxdelay before the nextsend.

Page 23: 2.6.3. Structuring SDs

opt “received”

“ok”

“send”

“send”

a:A b:B

[ t < maxdelay ]

Page 24: 2.6.3. Structuring SDs

Other Interaction Operators

neg – traces which are defined to be impossible

region – a critical region, i.e. traces cannot be interleaved by other events.

assert – all traces that involve the assertion being false are impossible (??)

Page 25: 2.6.3. Structuring SDs

3. Object Models3.1. IntroductionObject models capture the static structure of a system, either by capturing:• the class architecture, or• the static object structure at some time

instant.

Both are represented graphically.

Page 26: 2.6.3. Structuring SDs

3.2. Class diagrams

Class architectures lead to UML class diagrams which show:

• the template structure of a class, • inheritance relations between classes,• other relations between classes.

Page 27: 2.6.3. Structuring SDs

A simple UML class diagram usually contains mainly 2 kinds of information:

(1) The attributes and methods of a class,perhaps with visibility constraints, typing information and initialisation values.

(2) The relations between classes, mainly:(a) is_a and, (b) has_a.

Page 28: 2.6.3. Structuring SDs

3.2.1. Class Attributes

A class definition provides a template for creating objects. This information includes:• a class name,• names and types of attributes,• names and types of methods,• initialization values at object creation time,• visibility attributes of members.

Page 29: 2.6.3. Structuring SDs

Employee <<abstract>>- identity : String- status : int- pay : float

+ fire() : void+ promote( increment : int ): void

UML Stereotypes include: <<abstract>>, <<singleton>>and <<interface>>

Optionally can add code as a comment

UML class name

UML attributes

UML methods

UML visibility

Page 30: 2.6.3. Structuring SDs

Visibility - : private+: public#: protected~: package

A class attribute has the general format<name> [ : <type> ] [ = <initialisation value> ]where the information in brackets [ …]is optional.

Page 31: 2.6.3. Structuring SDs

A class method has the general format:

<name> [ ( <parameters> )][ : <type> ]

a parameter has the format:

<Pname> [ : <type> ][ = default value > ]

Page 32: 2.6.3. Structuring SDs

UML 2.0 allows C++ style groupingpublic a(): int

b(): voidprivate c():void

UML 2.0 allows properties{readOnly}, {ordered},{bag}, {sequence},{composite}, {union}e.g.

area : int {readOnly}

Page 33: 2.6.3. Structuring SDs

3.2.2. Inheritance Information

After individual classes have been identifiedby analysis as

Nounswe try to identify inheritance relationships,

e.g. subtype relation employee office manageremployee office

worker

Page 34: 2.6.3. Structuring SDs

This will help us to:• re-use code• clarify definitions

– is every x really a y ?– what’s the difference between x and y ?

• understand the structure of the domain• spot incomplete models ( x ??? z ) • See Liskov Substitution Principle in

Section 20.

Page 35: 2.6.3. Structuring SDs

Class_A Class_B

Class_C Class_D

Class_E Class_F

A UML inheritance hierarchy

Page 36: 2.6.3. Structuring SDs

class_C and class_D inherit from class_A.

class_C also inherits from class_B(multiple inheritance, C++ but not Java)

Also class_E and class_F inherit from Class_C. (So inheritance arrows may ormay not join up)

Page 37: 2.6.3. Structuring SDs

3.2.3. DiscriminatorsIt can be useful to explain the criterion whichdetermines inheritance and the subclasses.

Inheritance is a relation, and all relations can havenames which help us understand them.

Can regard as a meta-class = class of classes.

For example …

Page 38: 2.6.3. Structuring SDs

Figure

2_dim 3_dim1_dim

Line

Dimension

Dimension is an annotation onthe inheritance arrow.

Page 39: 2.6.3. Structuring SDs

3.2.4. Aggregation

Aggregation is an anti-symmetric and transitive relation between two classes:• a container class• a component class.

The simplest example is class composition,where one class is contained in another, e.g. ..

Page 40: 2.6.3. Structuring SDs

Book

Chapter

Section

Page 41: 2.6.3. Structuring SDs

This relation is often called thehas_a relation

e.g. each Book object has_a chapter object,each Chapter object has_a Section object.

A chapter is not a special kind of book, and sothis relation differs from inheritance.

Page 42: 2.6.3. Structuring SDs

Semantically, composition is very similarto extending a class by an attribute, e.g.

Book

Chapter_1 : Chapter

The differences are rather subtle, e.g. doesevery book have exactly one chapter?No? … How many?

Page 43: 2.6.3. Structuring SDs

The has_a relationship is rather subtle.

The existence of pointers allows Shared objects.

If a Chapter object has_a Section object, can any other Chapter object have the same section?

Page 44: 2.6.3. Structuring SDs

UML distinguishes this variation with anothertype of aggregation arrow, e.g.

Polygon Line

Point Namex, y : int text : String

Page 45: 2.6.3. Structuring SDs

A polygon and a line both have some points,which they can share with other polygons andlines. (e.g. by pointers).

Every polygon and line also has a namewhich should be unique and thereforeunshared.

In practice, the name might also beimplemented by pointers, so we must checkthe implementation really doesn’t share!

Page 46: 2.6.3. Structuring SDs

Notice that unshared has_a is a special case of shared has_a ( the number of objects weshare with just happens to be one )

Thus it is often said that composition is aspecial kind of aggregation.

When in doubt about sharing we can use aggregation, can fill in diamond later!