1 CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 07: Object Interaction and Specifying Operations

2 Object Interaction

3 Object Interaction – Communication Diagrams & Interaction Overview Diagrams Timing Diagrams Based on Chapter 9 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (3 rd Edition), McGraw Hill, 2005.

4 In This Lecture You Will Learn:  Object Interaction and Collaboration  CRC Cards communication diagram  how to model object interaction using an interaction communication diagram. overview diagrams  how to model interactions using interaction overview diagrams; sequence diagram  how to model interaction using an interaction sequence diagram;  how to use timing diagrams.

5 Object Interaction & Collaboration  Message Passing  Objects communicate by sending messages  When an object sends a message to another object, an operation is invoked in the receiving object  The aim of modelling object interaction is to determine the most appropriate scheme of message passing between objects to support a particular user requirement

6 Object Interaction & Collaboration  Appropriate distribution of object responsibility improves software modularity  Each class tends not to be unduly complex, and as a result is easier to develop, to test and to maintain.  Each class is relatively small and self-contained, and as a result has a much greater potential for reuse.  The system is more resilient to changes in its requirements  A modular system is easier  to be maintained and upgraded  to achieve high reliability  to be implemented in small, manageable increments

Nov-157

8 CRC Cards  Class–Responsibility–Collaboration (CRC) cards help to model interaction between objects  Brainstorm the classes  Allocate each class to a team members  For each use case, role play the interaction to distribute responsibilities among classes: each object identifies the object that he/she thinks is most appropriate to take on a needed responsibility for collaboration each object should be as lazy as possible, refusing to take on any responsibility unless persuaded by its fellow objects

9 CRC Cards Class Name: CollaborationsResponsibilities Responsibilities of a class are listed in this section. Collaborations with other classes are listed here, together with a brief description of the purpose of the collaboration.

Nov-1510 CRC Cards

11 Dynamic Analysis with UML  Communication Diagrams  Sequence Diagrams  Interaction Overview Diagrams  Timing Diagrams In UML 1.x, communication diagrams are called collaboration diagrams. In UML 1.x, interaction overview diagrams and timing diagrams do not exist.

12 Communication Diagrams same information as sequence diagrams  Hold the same information as sequence diagrams.  Show links between objects that participate in the collaboration.  No time dimension  No time dimension, sequence is captured with sequence numbers.  Sequence numbers are written in a nested style  Sequence numbers are written in a nested style (for example, 3.1 and 3.1.1) to indicate the nesting of control within the interaction that is being modelled.

13 Communication Diagrams  Notations  Message order is captured with sequence numbers, which are written in a nested style (for example, 3.1 and 3.1.1) to indicate the nesting of control within the interaction that is being modelled. :CampaignanAdvert:Advert getCost currentAdvertCost = anAdvert.getCost()

14 Message Labels Type of messageSyntax example Simple message.4: addNewAdvert Nested call with return value. The return value is placed in the variable name : name = getName Conditional message. This message is only sent if the condition [balance > 0] is true. 5 [balance > 0]: debit(amount) Iteration4.1 *[For all adverts]: getCost

Nov-1515

16 Sequence Diagrams  Purpose  A sequence diagram shows an interaction between objects arranged in a time sequence.  Sequence diagrams can be drawn at different levels of detail and to meet different purposes at several stages in the development life cycle.  Sequence diagrams are typically used to represent the detailed object interaction that occurs for one use case or for one operation.

17 Sequence Diagrams  Notations  Objects (or subsystems or other connectable objects) involved in interaction appear horizontally across the page and are represented by lifelines.  The execution or activation of an operation is shown by a rectangle on the relevant lifeline.

18 Sequence Diagrams  Notations  Messages are usually shown by a solid horizontal arrow. A synchronous message or procedural call is shown with a full arrowhead, causes the invoking operation to suspend execution until the focus of control has been returned to it. It is optional to show reply messages (with dashed arrows) because it can be assumed that control is returned to the originating object at the end of the activation in a destination object (except for asynchronous messages). A reflexive message that an object sends to itself is shown by a message arrow that starts and finishes at the same object lifeline.

19 Sequence Diagrams  Combined Fragments  Sequence Vertical dimension shows time.  Iteration (looping) is shown by a combined fragment rectangle with the interaction operator ‘loop’. The loop combined fragment only executes if the guard condition in the interaction constraint evaluates as true.  Selection (branching) is shown by a combined fragment rectangle with the interaction operator ‘alt’ (a short form of alternatives). The alt combined fragment has two (or more) compartments known as operands. Each operand corresponds to one of the alternatives in the combined fragment and each operand should have an interaction constraint to indicate under what conditions it executes.

20 Sequence Diagrams  Notations  Object creation is shown with the construction message (dashed arrow) going to the object symbol.  Object destruction is indicated by a large X on the lifeline on the destruction point.

Sequence Diagrams Nov-1521

22 Interaction Overview Diagrams  Variants of activity diagrams  Focuses on the flow of control in an interaction  Nodes in the diagram may be interactions or interaction occurrences  Interaction needs to be broken down into its key elements.

23 Interaction Overview Diagrams  An alternative version of the sequence diagram Add a new advert to a campaign if within budget is shown on the next slide and is used to develop an interaction overview diagram

24 :Client :Campaign :Advert getName listCampaigns ref :CampaignManager alt [else] sd Add a new advert to a campaign if within budget List client campaigns [totalCost <= budget] ref Create advert Create request ref Get campaign budget addCostedAdvert

25 Interaction Fragment Used :Campaign :Advert getCost sd Get campaign budget loop getOverheads checkCampaignBudget :CampaignManager [For all campaign’s adverts]

26 Interaction Fragment Used :Campaign :Advert Advert newAd:Advert sd Create advert

27 Interaction Fragment Used :Campaign :Advert newRequest:Request Request sd Create request

28 ref Get campaign budget [totalCost <= budget] ref Create advert Create request ref :Campaign :CampaignManager addCostedAdvert sd Add costed advert [totalCost > budget] sd Add a new advert to a campaign if within budget :Client :Campaign getName listCampaigns getCampaignDetails :CampaignManager sd List Campaigns for Client loop [For all client’s campaigns] Decision Interaction occurrence In-line sequence diagram Initial node Final node

29 Timing Diagrams  A new feature in UML 2.0  Show how time constraints affect interactions between lifelines  The sequence diagram Car enters car park is the basis for the subsequent timing diagram

30 Timing Diagrams :TicketMachine :Barrier after:WeightSensor sd Car enters car park raiseBarrier lowerBarrier before:WeightSensor activate Raised Lowered Active deactivate Blocked barrierLowered Inactive ticketRequested

31 Timing Diagrams sd Car enters car park lifelines :Barrier, :TicketMachine :Barrier :TicketMachine Lowered Raised Inactive Active Blocked t {t..t+3s} Timing Constraint raiseBarrier barrierLowered Diagram has two instances, one for each lifeline Sloped line represents duration of state change Message from one lifeline to another

32 Model Consistency  Timing diagrams must be consistent with the relevant sequence diagrams and state machines.

33 Summary In this lecture you have learned about:  how to model object interaction using an interaction communication diagram.  how to model interactions using interaction overview diagrams;  how to model interaction using an interaction sequence diagram;  how to use timing diagrams.

34 Specifying Operations

35 OBJECTIVES To understand :  why operations need to be specified  The difference between algorithmic and non – algorithmic methods  How to interpret different ways of specifying operations  How to specify operations using one method.

36 In this chapter you will learn :  How to use : - Decision Tables - Pre and post-condition pairs - Structured English - Activity Diagrams - Object Constraint Language

37 Why we specify operations  From analysis perspective : - Ensure user needs are understood  From design perspective : - Guide programmer to an appropriate implementation (i.e. method)  From test perspective : - verify that the method does what was originally intended

38 Types of Operation and Their effects  Operations with side-effects may: - Create or destroy object instances - Set attribute values - Form or break links with other objects - Carry out calculations - Send messages or events to other objects - Any combination of these  Operations without side-effects are pure queries - Request data but do not change anything

39 Services Among Objects  When objects collaborate one object typically provides a service to another  Examples : - A client object might ask a campaign - Structured English - Activity Diagrams - Object Constraint Language

40 Contracts: an approach to defining services  A service can be defined as a contract between the participating objects  Contracts focus on inputs and outputs  Intervening process is seen as a black box  Irrelevant details are hidden  This emphasizes service delivery, and ignores implementation

41 Contract-Style Operation Specification :  Intent or purpose of the operation  Operation signature, including return type  Description of the logic  Other operations called  Events transmitted to other objects  Any attributes set  Response to exceptions (e.g. an invalid parameter)  Non-functional requirements

42 Types of Logic Specification  Logic description is probably the most important element.  Two main categories:  Algorithmic types are white box – they focus on how the operation might work  Non-algorithmic types are black box – they focus on what the operation should achieve.

43 Non-Algorithmic Techniques  Appropriate where correct result matters more than method to arrive at it  Decision tree: complex decisions, multiple criteria and steps (not described further here)  Decision table: similar applications to decision tree  Pre- and Post-condition pairs: suitable where precise logic is unimportant or uncertain

44 Example Decision Table Conditions and actionsRule 1Rule 2 Rule 3 Conditions Is budget likely to be overspent? NYY Is overspend likely to exceed 2%?-NY Actions No actionX Send letter XX Set up meeting X

45 Algorithmic Techniques  Suitable where users understand the procedure for arriving at a result  Can be constructed top-down, to handle arbitrarily complex functionality  Examples: - Structured English - Activity Diagrams

46 Structured English :  Commonly used, easy to learn  Three types of control structure, derived from structured programming: - Sequences of instructions - Selection of alternative instructions (or groups of instructions) - Iteration (repetition) of instructions (or groups of instructions)

47 Sequence in Structured English  Each instruction executed in turn, one after another get client contact name sale cost = item cost * ( 1 - discount rate ) calculate total bonus description = new description

48 Selection in Structured English  One or other alternative course is followed, depending on result of a test : if client contact is ‘ A ’ set discount rate to 5% else set discount rate to 2% end if

49 Iteration in Structured English  Instruction or block of instructions is repeated - can be a set number of repeats - or until some test is satisfied, for example do while there are more staff in the list calculate staff bonus store bonus amount end do

50 Activity diagram  Are part of UML notation set  Can be used for operation logic specification, among many other uses  Are easy to learn and understand  Have the immediacy of graphical notation  Bear some resemblance to old-fashioned flowchart technique

51 Simple activity diagram Link to CreativeStaff Create new StaffGrade Link to previous StaffGrade Set previous StaffGrade gradeFinishDate Figure 10.2 an activity diagram show the main steps for the operation

52 Activity diagram with selection Check approval for grade change [approved by Director] [not approved by Director] Print approval request Link to CreativeStaff Create new StaffGrade Link to previous StaffGrade Set previous StaffGrade gradeFinishDate Figure 10.3 A more complex activity diagram

53 Calculate bonus [bonus > £250] Add to list [more StaffMembers] Format list [no more StaffMembers] Add to ‘star’ list Create warning letter [bonus < £25] [bonus >= £25 AND bonus <= £250] Activity Diagram with Selection and Iteration Figure 10.4 activity diagram

54 Activity diagram for creativestaff. calculatebonus() Find oldest Campaign Worked on Get campaign Bonus level Get next campaign Average Campaign Bonus level Set bonus to Grade minimum

55 Activity diagram for the use case check campaign budget. Get client Show campaign Get Advert cost Calculate Overheads [no more Adverts] [correct Campaign] [incorrect Campaign] [more Adverts] Figure 10.6 activity diagram for the use case check campaign budget

56 Object Constraint Language  Most OCL statements consist of: - Context, Property and Operation Context - Defines domain within which expression is valid - Instance of a type, e.g. object in class diagram - Link (association instance) may be a context  A property of that instance - Often an attribute, association-end or query operation

57 Object Constraint Language  OCL operation is applied to the property  Operations include - Arithmetical operators *, +, - and / - Set operators such as size, isEmpty and select - Type operators such as oclIsTypeOf

58 OCL expressionInterpretation Person self.gender In the context of a specific person, the value of the property ‘gender’ of that person—i.e. a person’s gender. Person self.savings >= 500 The property ‘savings’ of the person under consideration must be greater than or equal to 500. Person self.husband-> notEmpty implies self.husband.gender = male If the set ‘husband’ associated with a person is not empty, then the value of the property ‘gender’ of the husband must be male. Boldface denotes OCL keyword, but has no semantic import. Company self.CEO->size <= 1 The size of the set of the property ‘CEO’ of a company must be less than or equal to 1. That is, a company cannot have more than 1 Chief Executive Officer. Company self.employee->select (age < 60) The set of employees of a company whose age is less than 60.

59 OCL Used for Pre and post - conditions context CreativeStaff::changeGrade (grade:Grade, gradeChangeDate:Date) pre: grade oclIsTypeOf(Grade) gradeChangeDate >= today post: self.staffGrade[grade]->exists self.staffGrade[previous]->notEmpty self.staffGrade.gradeStartDate = gradeChangeDate self.staffGrade.previous.gradeFinishDate = gradeChangeDate

60 Summary In this lecture you have learned about:  The role of operation specifications  What is meant by “Contracts”  Algorithmic and non-algorithmic techniques, and how they differ  How to use: - Decision Tables, Pre- and Post-condition Pairs, Structured English, Activity Diagrams and Object Constraint Language

61 References : Bennett, McRobb and Farmer (2002)  Yourdon (1989) covers Structured English and Pre- and Post-conditions well  Senn (1989) is good on Decision Tables  Larman (1998) takes a contract-based approach to O-O analysis and design, with examples taken to Java code (For full bibliographic details, see Bennett, McRobb and Farmer)

62CSE323 Systems Analysis and Design 62 Nov-15 Next Lecture System Architecture