Tự học lập trình assembly - Chương 4: Sơ đồ tương tác
Web application should be registered by Facebook to have an application ID (client_id) and secret (client_secret). When request to some protected Facebook resources is received, web browser ("user agent") is redirected to Facebook's authorization server with application ID and the URL the user should be redirected back to after the authorization process.
User receives back Request for Permission form. If the user authorizes the application to get his/her data, Facebook authorization server redirects back to the URI that was specified before together with authorization code ("verification string"). The authorization code can be exchanged by web application for an OAuth access token.
46 trang |
Chia sẻ: nguyenlam99 | Lượt xem: 1101 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Tự học lập trình assembly - Chương 4: Sơ đồ tương tác, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Chương 4 : Sơ đồ tương tácGV : TS. Trương Quốc ĐịnhSequence Diagrams*Interaction DiagramsA series of diagrams describing the dynamic behavior of an object-oriented system.A set of messages exchanged among a set of objects within a context to accomplish a purpose.Often used to model the way a use case is realized through a sequence of messages between objects.Sequence Diagrams*Interaction Diagrams (Cont.)The purpose of Interaction diagrams is to:Model interactions between objectsAssist in understanding how a system (a use case) actually worksVerify that a use case description can be supported by the existing classesIdentify responsibilities/operations and assign them to classesSequence Diagrams*Interaction Diagrams (Cont.)UML Collaboration DiagramsEmphasizes structural relations between objectsSequence DiagramThe subject of this tutorialSequence Diagrams*A First Look at Sequence DiagramsIllustrates how objects interacts with each other.Emphasizes time ordering of messages.Can model simple sequential flow, branching, iteration, recursion and concurrency.Sequence Diagrams*ObjectObject naming:syntax: [instanceName][:className]Name classes consistently with your class diagram (same classes).Include instance names when objects are referred to in messages or when several objects of the same type exist in the diagram.The Life-Line represents the object’s life during the interactionLifelines are drawn as a box with a dashed line descending from the center of the bottom edge. The lifeline's name is placed inside the box.myBirthday:DateSequence Diagrams*MessagesAn interaction between two objects is performed as a message sent from one object to another (simple operation call, Signaling, ) If object obj1 sends a message to another object obj2 some link must exist between those two objectsSequence Diagrams*Messages (Cont.)A message is represented by an arrow between the life lines of two objects.Self calls are also allowedThe time required by the receiver object to process the message is denoted by an activation-box.A message is labeled at minimum with the message name.Arguments and control information (conditions, iteration) may be included.Sequence Diagrams*Return ValuesOptionally indicated using a dashed arrow with a label indicating the return value.Don’t model a return value when it is obvious what is being returned, e.g. getTotal()Prefer modeling return values as part of a method invocation, e.g. ok = isValid() Model a return value when you need to refer to it elsewhere, e.g. as a parameter passed in another message.Sequence Diagrams*Synchronous MessagesNested flow of control, typically implemented as an operation call.The routine that handles the message is completed before the caller resumes execution.:A:BdoYouUnderstand()Caller Blockedreturn (optional)yesSequence Diagrams*Asynchronous MessagesIf a caller sends an asynchronous message, it can continue processing and doesn’t have to wait for a response.We can see asynchronous calls in multithreaded applications and in message-oriented middleware. Asynchrony gives better responsiveness and reduces the temporal coupling but is harder to debug. Sequence Diagrams*Object DestructionAn object may destroy another object via a > message.An object may destroy itself.Avoid modeling object destruction unless memory management is critical.:A:B>Found MessageA found message is a message where the receiving event occurrence is known, but there is no (known) sending event occurrence. We interpret this to be because the origin of the message is outside the scope of the description. This may for example be noise or other activity that we do not want to describe in detail.Lost MessageA lost message is a message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret this to be because the message never reached its destination.Self MessageA message defines a particular communication between Lifelines of an Interaction.Self message is a kind of message that represents the invocation of message of the same lifeline.Recursive MessageA message defines a particular communication between Lifelines of an Interaction.Recursive message is a kind of message that represents the invocation of message of the same lifeline. It's target points to an activation on top of the activation where the message was invoked from.Object state and ConstraintSequence diagrams can show how an object changes state overtime. We do this by placing the object state on the lifeline at the appropriate point. This allows we to see very clearly which events give rise to state changes.Object state and Constraint (cont.)Object state and Constraint (cont.)The message acceptPayment() causes a state transition on the :Order object from state unpaid to paid. The message deliver( ) sent from the :DeliveryManager object to the :Order object causes a state transition in :Order from state paid to delivered.The timing constraint says that there must be 28 days or less between time A and time B. Time A marks the point at which the :Order object undergoes transition into the state paid, and time B marks the point at which the :Order object undergoes transition into the state delivered.Combined FragmentCombined fragment is an interaction fragment which defines a combination (expression) of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands. Through the use of combined fragments the user will be able to describe a number of traces in a compact and concise manner.Combined Fragment (Cont.)Interaction operator could be one of:alt - alternativesopt - optionloop - iterationbreak - breakpar - parallelstrict - strict sequencingseq - weak sequencingcritical - critical regionignore - ignoreconsider - considerassert - assertionneg - negativeAlternativesThe interaction operator alt means that the combined fragment represents a choice or alternatives of behavior. At most one of the operands will be chosen. The chosen operand must have an explicit or implicit guard expression that evaluates to true at this point in the interaction.An implicit true guard is implied if the operand has no guard.An operand guarded by else means a guard that is the negation of the disjunction of all other guards. If none of the operands has a guard that evaluates to true, none of the operands are executed and the remainder of the enclosing interaction fragment is executed. Alternatives (Cont.)OptionThe interaction operator opt means that the combined fragment represents a choice of behavior where either the (sole) operand happens or nothing happens. An option is semantically equivalent to an alternative combined fragment where there is one operand with non-empty content and the second operand is empty.LoopThe interaction operator loop means that the combined fragment represents a loop. The loop operand will be repeated a number of times. The loop construct represents a recursive application of the seq operator where the loop operand is sequenced after the result of earlier iterations.Loop could be controlled by either or both iteration bounds and a guard. Loop operand could have iteration bounds which may include a lower and an upper number of iterations of the loop. Textual syntax of the loop is:loop-operand ::= loop [ '(' min-int [ ',' max-int ] ')' ]min-int ::= non-negative-integermax-int ::= positive-integer | '*' Loop (Cont.)If loop has no bounds specified, it means potentially infinite loop with zero as lower bound and infinite upper bound. Loop (Cont.)If only min-int is specified, it means that upper bound is equal to the lower bound, and loop will be executed exactly the specified number of times. Loop (Cont.)If max-int is specified, it should be greater than or equal to min-int. Loop will iterate minimum the min-int number of times and at most the max-int number of times.Besides iteration bounds loop could also have an interaction constraint - a Boolean expression in square brackets.UML tries to shuffle the simplest form of for loop and while loop : "after the minimum number of iterations have executed and the Boolean expression is false the loop will terminate". This is clarified as "the loop will only continue if that specification evaluates to true during execution regardless of the minimum number of iterations specified in the loop." Loop (Cont.)BreakThe interaction operator break represents a breaking or exceptional scenario that is performed instead of the remainder of the enclosing interaction fragment.A break operator with a guard is chosen when the guard is true. In this case the rest of the directly enclosing interaction fragment is ignored. When the guard of the break operand is false, the break operand is ignored and the rest of the enclosing interaction fragment proceeds. Break (Cont.)ParallelThe interaction operator par defines potentially parallel execution of behaviors of the operands of the combined fragment. Different operands can be interleaved in any way as long as the ordering imposed by each operand is preserved.Set of traces of the parallel operator describes all the possible ways or combinations that occurrence specifications of the operands may be interleaved without changing the order within each operand. Parallel (Cont.)Search Google, Bing and Ask in any order, possibly parallel. Strict SequencingThe interaction operator strict requires a strict sequencing (order) of the operands on the first level within the combined fragment. Weak SequencingThe interaction operator seq means that the combined fragment represents a weak sequencing between the behaviors of the operands.Weak sequencing is defined by the set of traces with these properties:The ordering of occurrence specifications within each of the operands is maintained.Occurrence specifications on different lifelines from different operands may come in any order.Occurrence specifications on the same lifeline from different operands are ordered such that an occurrence specification of the first operand comes before that of the second operand.Weak Sequencing (Cont.)Critical RegionThe interaction operator critical defines that the combined fragment represents a critical region. A critical region is a region with traces that cannot be interleaved by other occurrence specifications (on the lifelines covered by the region). This means that the region is treated atomically by the enclosing fragment and can't be interleaved, e.g. by parallel operator. IgnoreUML defines its meaning as "there are some message types that are not shown within this combined fragment. These message types can be considered insignificant and are implicitly ignored if they appear in a corresponding execution. Alternatively, one can understand ignore to mean that the message types that are ignored can appear anywhere in the traces." The list of ignored messages follows the operand enclosed in a pair of curly braces "{" and "}". Ignore operation is typically combined with other operations such as "assert ignore {m, s}." ConsiderThe interaction operator consider defines which messages should be considered within this combined fragment, meaning that any other message will be ignored.The list of considered messages follows the operand enclosed in a pair of curly braces "{" and "}". Consider operation is typically combined with other operations such as "assert consider {m, s}." AssertionThe interaction operator assert means that the combined fragment represents the assertion that the sequences of the assert operand are the only valid continuations (must be satisfied by a correct design of the system). All other continuations result in an invalid trace. Commit() message should occur at this point, following with evaluation of state invariant. NegativeThe interaction operator neg describes combined fragment of traces that are defined to be negative (invalid). Negative traces are the traces which occur when the system has failed. All interaction fragments that are different from the negative are considered positive, meaning that they describe traces that are valid and should be possible.Should we receive back timeout message, it means the system has failed. Interaction UseInteraction use is an interaction fragment which allows to use (or call) another interaction. Large and complex sequence diagrams could be simplified with interaction uses. Interaction use works as:Copy the contents of the referred interaction to where this interaction needs to be used,Substitute formal parameters with arguments,The interaction use is shown as a combined fragment with operator ref. Interaction use (Cont.)The syntax of the interaction use of the ref operator is:interaction-use ::= [ attribute-name '=' ] [ collaboration-use '.' ] interaction-name [ io-arguments ] [ ':' return-value ]io-arguments ::= '(' io-argument [ ',' io-argument ]* ')'io-argument ::= in-argument | 'out' out-argumentThe attribute-name refers to an attribute of one of the lifelines in the interaction that will receive interaction result. Note, that this restricts results of interactions to be assigned only to attributes.The collaboration-use is an identification of collaboration use that binds lifelines of a collaboration. The interaction name is in that case within that collaboration.The io-arguments is list of in and/or out arguments of the interaction. Interaction use (Cont.)Use Login interaction to authenticate user and assign result back to the user attribute of Site Controller. Example 1 - Facebook User Authentication in a Web ApplicationWeb application should be registered by Facebook to have an application ID (client_id) and secret (client_secret). When request to some protected Facebook resources is received, web browser ("user agent") is redirected to Facebook's authorization server with application ID and the URL the user should be redirected back to after the authorization process.User receives back Request for Permission form. If the user authorizes the application to get his/her data, Facebook authorization server redirects back to the URI that was specified before together with authorization code ("verification string"). The authorization code can be exchanged by web application for an OAuth access token. Example 1 - Facebook User Authentication in a Web Application
Các file đính kèm theo tài liệu này:
- uml_chuong4_4099.ppt