Try & Try U Will Be Success

TRY & TRY U WILL BE SUCCESS

SOODAM QUESTION

SANJAY HIRANI

Semester: 3rd

Branch:MCA

UNIT-7 BEHAVIORAL MODELING

Interaction Modeling

The interaction model describes how objects interact to produce useful results. Interactions can be modeled at different levels of abstraction.

At high level, Use Case diagrams describe how a system interacts with outside actors. Each use case represents a piece of funtionality that a system provides to its users. Use cases are helpful for capturing informal requirements.

Sequence diagrams provide more detail and show the messages exchanged among a set of objects over time. Messages include both asynchoronous signals and procedure calls. Sequence diagrams are good for showing the behavior sequences seen by users of a system.

1.  Use Case Diagram

A use case diagram is a high-level view of all the use cases within a system and the actors that interact with them. A system involves a set of usecases and a set of actors.

The Use Case diagram notation has some elements. Those Use Case Diagram elements and their icons are

1.  Actors:

An actor is a direct external user of a system- an object or set of objects that communicates directly with the system. Each actor represents those objects that behave in a particular way toward the system. Actors can be persons, devices and other systems – anything that interacts directly with the system. For eg, for a travel agency system, actors are traveler, agent and airline. For computer database system, actors are user and administrator. An actor has a single well defined purpose.

A “stickman” icon denotes an actor, withe the name being placed below or adjacent to the icon.

2.  Use Cases:

A use case is a piece of functionality that a system can provide by interacting with actors. It is a sequence of actions that an actor performs on a system and the response generated. Each use case represents a slice of the functionality the system provides. The set of use cases shows the complete functionality of the system at some level of detail.

Each use case involves one or more actors as well as the system itself. It involves a sequence of messages among the system and its actors. Some use cases have a fixed sequence of messages. Error conditions are also part of a use case.

A name within an ecllipse denotes a use case.

3.  System Boundary:

The system boundary contains the use cases for a system with the actors listed on the outside. It is represented by a rectangle. The name of the system may be written near a side of the rectangle.

4.  Association:

An association specifies a semantic relationship that can occur between acotrs and use cases. It is represented by a solid line. Thus, Solid lines connect use cases to participating actors.

5.  Include Relationship:

The include relationship incorporates one use case within another use case. It implies that the included behavior is a necessary part of a system.

An include relationship is represented by a dashed arrow from the source use case to the target use case. The keyword <include> is written on the arrow.

6.  Extend relationship:

The extend relationship is like an include relationship looked at from the opposite direction. It implies that the included behavior is not necessary part of a system i.e. a system without the added behavior, would be meaningful.

An extend relationship is represented by a dashed arrow from the target use case to the source use case. The keyword <extend> is written on the arrow.

7.  Generalization:

A parent use case represents a general behavior sequence. Child use cases specialize the parent by inserting additional steps or by refining steps. Generalization is represented by an arrow with its tail on the child use case and a triangular arrowhead on the parent use case.

A parent use case may be abstract or concrete. Use cases can also exhibit polymorphism, i.e. a child use case can freely substitute for a parent use case.

2.  Sequence Diagram:

Ø  The sequence diagram is used primarily to show the interactions between objects that occur in the sequential order by sending and receiving the messages among them. One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement. Use cases are often refined into one or more sequence diagrams.

Ø  Each actor as well as the system is represented by a vertical line called a lifeline and each message by a horizontal arrow from the sender to the receiver.

Ø  Sequence diagram can show large-scale interactions, such as the entire session with any system. Also, it can show the exception condition within the use case.

Ø  In most systems, there are an unlimited number of scenarios of usecases, so it is not possible to show them all. However, we can elaborate some usecases which can cover the basic kinds of behavior with sequence diagrams.

Basics

Ø  The main purpose of a sequence diagram is to define sequences that result in some desired outcome. Sequence diagrams will communicate what messages are sent between a system's objects as well as the order in which they occur.

Ø  The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to.

Ø  The sequence diagram notation has some elements. Those Sequence Diagram elements and their icons are

1)  Lifelines

When drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled. Lifelines are drawn as a box with a dashed line descending from the center of the bottom edge (Figure 3). The lifeline's name is placed inside the box.

Figure: An example of the Student class used in a lifeline whose instance name is freshman.

In the above Figure, the lifeline represents an instance of the class Student, whose instance name is freshman. Note that, here, the lifeline name is underlined. Lifeline can be used to represent an anonymous or unnamed instance. When modeling an unnamed instance on a sequence diagram, the lifeline's name follows the same pattern as a named instance; but instead of providing an instance name, that portion of the lifeline's name is left blank.

2)  Messages

The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.

To show an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead. The message/method name is placed above the arrowed line. The message that is being sent to the receiving object represents an operation/method that the receiving object's class implements.

Besides just showing message calls on the sequence diagram, the sequence diagram includes return messages. These return messages are optional; a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation.

When modeling a sequence diagram, there will be times that an object will need to send a message to itself. Modeling an object, sending a message to itself can be useful in some cases. To draw an object calling itself, you draw a message as you would normally, but instead of connecting it to another object, you connect the message back to the object itself.

Figure 4: An example of messages being sent between objects

Login(username,password)

Login(“Abc”,”def”)

Appropriate msg

3)  Passive and Active Objects:

In common, all the objects are not constantly active. Most objects are passive and do not have their own threads of control. A passive object is not activated until it has been called. Once the execution of an operation/method completes and control returns to the calling object, the passive object becomes inactive.

The UML shows the period of time for an objecyt’s execution as a thin rectangle. This is called activation or focus of control. An activation shows the time period during which a call of a method is being processes, including the time when the called method has invoked another operation.

Compute

commission()

service level (customer)

level

calculate commission(level, transaction)

commission

commission

4)  Guards

In sequence diagrams, guard is a condition that must be met for a message to be sent to the object. A guard could only be assigned to a single message. To draw a guard on a sequence diagram, you place the guard element above the message line being guarded and in front of the message name.

Figure: A segment of a UML 1.x sequence diagram in which the addStudent message has a guard.

In the above Figure, the guard is the text "[pastDueBalance = 0]." By having the guard on this message, the addStudent message will only be sent if the accounts receivable system returns a past due balance of zero.

5)  Combined fragments (alternatives, options, and loops)

A combined fragment is used to group sets of messages together to show conditional flow in a sequence diagram.

a.  Alternatives

Alternatives are used to give choice between two or more message sequences. Only one guard conditions attached to different alternative operands can be true at the same time.

An alternative combination fragment element is drawn using a frame. The word "alt" is placed inside the frame's namebox. The larger rectangle is then divided into what UML 2 calls operands. Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline. If an operand's guard equates to "true," then that operand is the operand to follow.

Figure: A sequence diagram fragment that contains an alternative combination fragment.

WithDraw(101,2000)

Balance

Debit(101,2000)

Return cash/receipt Amt debited

[else]

Not enough balance

Not enough balance

As an example to show how an alternative combination fragment is read, Figure shows the sequence starting at the top, with the bank object getting the check's amount and the account's balance. At this point in the sequence the alternative combination fragment takes over. Because of the guard "[balance >= amount]," if the account's balance is greater than or equal to the amount, then the sequence continues with the bank object sending the addDebitTransaction and storePhotoOfCheck messages to the account object. However, if the balance is not greater than or equal to the amount, then the sequence proceeds with the bank object sending the addInsuffientFundFee and noteReturnedCheck message to the account object and the returnCheck message to itself. The second sequence is called when the balance is not greater than or equal to the amount because of the "[else]" guard. In alternative combination fragments, the "[else]" guard is not required; and if an operand does not have an explicit guard on it, then the "[else]" guard is to be assumed.

Alternative combination fragments are not limited to simple "if then else" tests. There can be as many alternative paths as are needed. If more alternatives are needed, all you must do is add an operand to the rectangle with that sequence's guard and messages.

B)  Option

The option combination fragment is used to model a sequence that, given a certain condition, will occur; otherwise, the sequence does not occur. An option is used to model a simple "if then" statement.

The option combination fragment notation is similar to the alternation combination fragment, except that it only has one operand and there never can be an "else" guard. To draw an option combination you draw a frame. The text "opt" is placed inside the frame's namebox, and in the frame's content area the option's guard is placed towards the top left corner on top of a lifeline. Then the option's sequence of messages is placed in the remainder of the frame's content area. These elements are illustrated in the Figure below.
Figure 9: A sequence diagram fragment that includes an option combination fragment.

getPastDueBal(Sid)

passDueBal

[past due bal=0]

addStudent(Sid)

s student added

Reading an option combination fragment is easy. Figure uses an option combination fragment because more messages need to be sent if the student's past due balance is equal to zero. According to the sequence diagram in Figure, if a student's past due balance equals zero, then the addStudent, getCostOfClass, and chargeForClass messages are sent. If the student's past due balance does not equal zero, then the sequence skips sending any of the messages in the option combination fragment.

The example Figure sequence diagram fragment includes a guard for the option.

3  Activity Diagram:

·  The purpose of the activity diagram is to model the procedural flow of actions that are part of a larger activity. Although UML sequence diagrams can protray the same information as activity diagrams, activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram typically shows only one flow of an activity. Also, activity diagrams focuses on operations rather than objects.

·  An activity diagram is like a traditional flowchart that shows the flow of control from step to step. But, an activity diagram can show both sequential and concurrent flow of control.