2.6.3. Structuring SDs

1. 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.

2. A reference is a pointer to another SD. References may not be circular or recursive.

3. Let us give a typical example. A simple data exchange between two systems can be divided into 3 phases: • set-up communication/initialize • exchange data • close-down communication We can specify the use case “successful data exchange” as follows.

4. SD Successful_ Data_Exchange A B ref Initialize ref Exchange ref Shutdown

5. ref <name> The symbol denotes a sub-SD called name. Thus every SD has a symbolic name also. The keyword refstand for reference. Then for the above example, we might have:

6. SD Shutdown SD Initialize A B A B “ready_to_send” “finished” “shutdown” “ready_to_receive” Notice these are “handshakes” between A and B. We will specify the SD “Exchange” later.

7. Note that a sub-SD does not synchronize timelines. i.e. either of A or B is free to leave sub-SD Exchange without the other leaving simultaneously. Here’s another example to clarify the point.

8. SD Sub-1 SD Unsynchronised_Ref A B A B ref “hello” Sub-1 “goodbye” “what?”

9. Possible executions are either: • hello • what • goodbye (A leaves Sub-1 late) or • hello • goodbye (A leaves Sub-1 early) • what?

10. SD normal_log_in User System Precondition: Power is on, operating system is active, log-in menu is visible. “username” “password?” “my_password” Postcondition: Power is on, operating system is active, user is logged in under own profile, user’s desktop is visible, log-in menu is not visible.

11. 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.)

12. 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 the Printer p. Either u2 wins (top) or u1 wins (bottom)

13. SD Alternatives u1 : User u2 : User p : Printer “print_1” “print_2” alt “accept_2” “accept_1”

14. The only possible executions or traces for SD Alternatives are either : • print_1 • print_2 • accept_2 or • print_1 • print_2 • accept_1

15. 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 a print job in parallel and both are accepted.

16. SD Parallel u1:User u2:User p:Printer par “print_1” “accept_1” “print_2” “accept_2”

17. 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_1 2. print_2 2. accept_1 2. accept_2 2.print_2 3. accept_1 3. print_2 3. print_1 3.accept_2 4. accept_2 4. accept_2 4. accept_1 4.accept_1 1. print_2 1. print_2 2. print_1 2. print_1 3. accept_1 3. accept_2 4. accept_2 4. accept_1

18. Interaction Operator loop An operator (possibly with a Boolean guard, no guard = [true]) used to define a section that may be iterated finitely or infinitely many times. Guard evaluated on each iteration. As well as Boolean guards we can bound the number of iterations.

19. Keywords : • loop <m, n>, loop at least m times and at most n times, for fixed integer constants m, n. • loop <m, inf>, loop finitely often, but at least m times. ( *not* infinitely often). • loop <inf, inf> loop at least infinitely many times. (4) loop <n> = loop <n, n> . (5) loop = loop <1, inf> . (6) [ while <Boolean expression> ]

20. Important note: The parameters m, n are fixed constants, they are not variables which can be changed. In the following example, the user polls a printer until the printer becomes ready. When it becomes ready the printer prints the file.

21. u:User p:Printer Loop <0, inf> alt “ready?” “busy” “ready?” “ready?” “yes” “print(file)” “printing”

22. 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 next send.

23. a:A b:B “send” opt “received” “ok” [ t < maxdelay ] “send”

24. 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 (??)

25. 3. Object Models 3.1. Introduction Object 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.

26. 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.

27. A simple UML class diagram usually contains mainly 2 kinds of information: • The attributes and methods of a class, perhaps with visibility constraints, typing information and initialisation values. • The relations between classes, mainly: (a) is_a and, (b) has_a.

28. 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.

29. UML class name Employee <<abstract>> UML attributes • identity : String • status : int • - pay : float UML methods + fire() : void + promote( increment : int ) : void UML visibility Optionally can add code as a comment UML Stereotypes include: <<abstract>>, <<singleton>> and <<interface>>

30. Visibility - : private +: public #: protected ~: package A class attribute has the general format <name> [ : <type> ] [ = <initialisation value> ] where the information in brackets [ …] is optional.

31. A class method has the general format: <name> [ ( <parameters> )][ : <type> ] a parameter has the format: <Pname> [ : <type> ][ = default value > ]

32. UML 2.0 allows C++ style grouping public a(): int b(): void private c():void UML 2.0 allows properties {readOnly}, {ordered},{bag}, {sequence}, {composite}, {union} e.g. area : int {readOnly}

33. 3.2.2. Inheritance Information After individual classes have been identified by analysis as Nouns we try to identify inheritance relationships, e.g. subtype relation employee  office manager employee  office worker

34. This will help us to: • re-use code • clarify definitions • is every xreally 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.

35. A UML inheritance hierarchy Class_B Class_A Class_C Class_D Class_E Class_F

36. 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 or may not join up)

37. 3.2.3. Discriminators It can be useful to explain the criterion which determines inheritance and the subclasses. Inheritance is a relation, and all relations can have names which help us understand them. Can regard as a meta-class = class of classes. For example …

38. Figure Dimension 1_dim 2_dim 3_dim Dimension is an annotation on the inheritance arrow. Line

39. 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. ..

40. Book Chapter Section

41. This relation is often called the has_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 so this relation differs from inheritance.

42. Semantically, composition is very similar to extending a class by an attribute, e.g. Book Chapter_1 : Chapter The differences are rather subtle, e.g. does every book have exactly one chapter? No? … How many?

43. 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?

44. UML distinguishes this variation with another type of aggregation arrow, e.g. Polygon Line Point Name text : String x, y : int

45. A polygon and a line both have some points, which they can share with other polygons and lines. (e.g. by pointers). Every polygon and line also has a name which should be unique and therefore unshared. In practice, the name might also be implemented by pointers, so we must check the implementation really doesn’t share!

46. Notice that unshared has_a is a special case of shared has_a ( the number of objects we share with just happens to be one ) Thus it is often said that composition is a special kind of aggregation. When in doubt about sharing we can use aggregation, can fill in diamond later!