Object-Oriented Software Development with UML - UNU-IIST ...

More documents

Recommendations

Info

156 Modelling Behaviour in State DiagramsProductsProductCatalog1 1..*Described-bySales::SalesLineItem*1ProductSpecificationdescriptionpriceupc0..1Records-sale-ofØCore::Store1DescribesStocks*1 *Item1Figure 9.26: Products packageState TransitionsIn general, detecting (receiving) an event can cause an object to move from one state to another. Such¾a move is called a state transition.A state transition is a relationship between two states that indicates that when a event occurs, the¾object changes from the prior state to the subsequent state.¾The behaviors of an object is described in terms of it state transitions.Examples of State Transitions1. When the event “off hook” occurs, the state transition from state Ä Ñ Á†Æ to state À¥ÒÈTÄÿ Æ is taken place.2. If event “load” occurs when the CD is in ÑÏ ÀòQÆ ÏBÙ Ó•ÆÅ state, the state transition from ÑÏ À§òQÆ ÏÙ Ó•ÆDÅ toÑ§Ï ÀòQÆ Ï ÛcÁÐ ÂÆ Ñis taken place.UML Notation for State DiagramA UML state diagram illustrates the interesting events and states of an object, and the behaviour of¾an object in reaction to an event.State transitions are shown as arrows, labelled with their events.¾States are shown in rounded rectangles.¾the instance is created.¾It is common to include an initial pseudo-state which automatically transitions to another state whenReport No. 259, July 2002UNU/IIST, P.O. Box 3058, Macau
Modelling Behaviour in State Diagrams 157PaymentsØPaymentamountCore::StoreAuthorizes-payment-of1 1..*CkeckServiceContract1merchantIDCashPayment *Credit CheckPaysPayment payment1amountTendered* *** Authorized-by *Logged-in1AccountsReceivableEstablishescredit-for1CreditCardexpiryDatenumberSales::CustomerAuthorizationServiceaddressnamephoneNumberCkeckAuthorizationServiceCreditAuthorizationServiceAuthorized-by*Establishesidentity-for*BankCardAuthorizationTransaction::numberPaymentAuthorizationReply11 IdentifiesFigure 9.27: Payments packageThis is shown in Figure 9.29Example: CD Player Figure 9.30 gives a state diagram for the CD player.A final state represents the state reached when an object is destroyed, or stops reacting to events.GuardsFor the CD player, it is not correct that the player always goes into playing state when the play button¾is pressed – even without a CD in the drawer.It should do so only when there is a CD in the drawer. More precisely:¾– When the event ‘play’ occurs, the player goes into the ÁiÀ§ÍBÄLÅ æstate if there is a CD in thedrawer.Î– When the event ‘play’ occurs, they play goes to Ñ§Ï ÀòQÆ Ï ÛcÁÐ ÂÆ Ñstate if there is no CD in thedrawer.This indicates the need of a conditional guard – or boolean test for a state transition.¾A guarded state transition can be taken only when the guard is true.¾Examples of Guarded TransitionsDiagrams in Figure 9.31 show the UML notation for guarded transitions.ActionsReport No. 259, July 2002UNU/IIST, P.O. Box 3058, Macau
Page 1 and 2:
UNU/IISTInternational Institute for
Page 3 and 4:
UNU/IISTInternational Institute for
Page 5 and 6:
ContentsiContents1 Introduction 11.
Page 7:
Contentsiii8.3 Questions . . . . .
Page 11 and 12:
Chapter 1IntroductionTopics for Cha
Page 13 and 14:
Introduction to Software Engineerin
Page 15 and 16:
Chapter 2Software Development Proce
Page 17 and 18:
Software Development Process 7Devel
Page 19 and 20:
Software Development Process 9There
Page 21 and 22:
Evolutionary Development 11Requirem
Page 23 and 24:
¦§¤Questions 13Source of errorEf
Page 25 and 26:
Chapter 3Introduction to OO Develop
Page 27 and 28:
Mastering Complex Systems 17The pro
Page 29 and 30:
Mastering Complex Systems 19roots a
Page 31 and 32:
Mastering Complex Systems 215. A co
Page 33 and 34:
The Rest of The course 23Main funct
Page 35 and 36:
Questions 253. Fred is a Dodge deal
Page 37 and 38:
Chapter 4Requirement Capture and An
Page 39 and 40:
Understanding requirements 29Use ca
Page 41 and 42:
Understanding requirements 31Ref #
Page 43 and 44:
Use Cases: Describing Processes 334
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Use Cases: Describing Processes 41B
Page 53 and 54:
Use Cases: Describing Processes 43C
Page 55 and 56:
Questions 45How can you, as a requi
Page 57 and 58:
Chapter 5Requirement Capture and An
Page 59 and 60:
Conceptual Model - Concepts and Cla
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Conceptual Model - Associations 55*
Page 67 and 68:
Conceptual Model - Associations 57b
Page 69 and 70:
Conceptual Model - Associations 59A
Page 71 and 72:
Conceptual Model - Associations 61B
Page 73 and 74:
Conceptual Model-Attributes 63uses:
Page 75 and 76:
Conceptual Model-Attributes 65Keep
Page 77 and 78:
Conceptual Model-Attributes 67Desig
Page 79 and 80:
Steps to Create a Conceptual Model
Page 81 and 82:
Recording Terms in the Glossary 71R
Page 83 and 84:
Questions 73Term Category CommentsB
Page 85 and 86:
Questions 7513. Consider the follow
Page 87 and 88:
Chapter 6System Behaviour: System S
Page 89 and 90:
System Sequence Diagram 79Make Phon
Page 91 and 92:
System Sequence Diagram 81Buy Items
Page 93 and 94:
Contracts for System Operations 83d
Page 95 and 96:
Contracts for System Operations 856
Page 97 and 98:
Contracts for System Operations 87R
Page 99 and 100:
Chapter 7Design Phase: Collaboratio
Page 101 and 102:
Collaboration Diagrams 91this reque
Page 103 and 104:
Collaboration Diagrams 93msg1():POS
Page 105 and 106:
Collaboration Diagrams 95msg1()1a:[
Page 107 and 108:
Creating Collaboration Diagrams 977
Page 109 and 110:
Creating Collaboration Diagrams 99T
Page 111 and 112:
Page 113 and 114:
Page 115 and 116: Creating Collaboration Diagrams 105
Page 121 and 122: Creating a new ¿-ÀÁ†ÆDÂ;Ã]
Page 135 and 136: Questions 125(a) an object Ù recei
Page 137 and 138: Chapter 8Implementing a DesignTopic
Page 139 and 140: Mapping a Design to Code 1298.2.1 D
Page 141 and 142: Mapping a Design to Code 1318.2.3 D
Page 143 and 144: Mapping a Design to Code 133public
Page 145 and 146: Chapter 9Advanced Modelling Concept
Page 147 and 148: Iterative Development Process 137De
Page 149 and 150: Iterative Development Process 139Al
Page 151 and 152: Generalisation 1410..1CashPaymentSa
Page 153 and 154: Generalisation 143of the supertype
Page 155 and 156: Figure 9.9: Justifying the subtypes
Page 157 and 158: More about Associations 147Payment*
Page 159 and 160: More about Associations 149Storeadd
Page 161 and 162: Packages: Organizing Elements 151A
Page 163 and 164: Modelling Behaviour in State Diagra
Page 165: Modelling Behaviour in State Diagra
Page 173 and 174: Chapter 10Summing UpTopics of Chapt
Page 175 and 176: Summing Up 165Conceptual ModelsCate
Page 177 and 178: ¢¢¢¢¢Chapter 11Coursework11.1
Page 179: Bvis Car Hire Company: The Problem
show all

Object-Oriented Software Development with UML - UNU-IIST ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?