Basic Behavioral Modeling

1. Interactions: Terms and Concepts

• An interaction is a behavior that comprises a

set of messages exchanged among objects in a
set of roles within a context to accomplish a
purpose.
• A message is a specification of a Collaboration
between objects that conveys information
with the expectation that activity will ensue.
2. Use Cases and Use Case Diagram
• Only static behavior is not sufficient to model a system rather dynamic
behavior is more important than static behavior.
• In UML, there are five diagrams available to model the dynamic
nature and use case diagram is one of them.
• A use case model describes a system’s functionality from the point of
view of the different actors that interact with the system to receive
services.
• These internal and external agents are known as actors.
• A use case diagram shows the relationships among actors and use
cases within a system. Use case diagrams address the static use case
view of a system.
• Use case diagrams consists of actors, use cases and their relationships.
The diagram is used to model the system/subsystem of an application.
• A single use case diagram captures a particular functionality of a
system.
• Hence to model the entire system, a number of use case diagrams are
used.
• The purposes of use case diagrams can be said
to be as follows −
– Used to gather the requirements of a system.
– Used to get an outside view of a system.
– Identify the external and internal factors
influencing the system.
– Show the interaction among the requirements are
actors.
i. Actors
• A coherent set of roles that users of use cases play
when they interact with use cases
• Typically represents the role that a human,
hardware device or another system plays with the
system
• Actors are not part of the system
• As an actor is a class, it can be generalized
ii. Use cases
• Someone interacts with use case (system
function).
• Named by verb + Noun (or Noun Phrase).
• i.e. Do something
• Each Actor must be linked to a use case, while
some use cases may not be linked to actors.
iii. System Boundary
• The system boundary is potentially the entire
system as defined in the requirements
document.
• For large and complex systems, each module
may be the system boundary.
• The entire system can span all of these
modules depicting the overall system
boundary.
• It is optional.
Relationships:
i. Communicates Relationships
• The participation of an actor in a use case is shown
by connecting an actor to a use case by a solid link.
• Actors may be connected to use cases by
associations, indicating that the actor and the use
case communicate with one another using messages.
• In this relationship <<communicates>> keyword is
used.
ii. Extends relationship
• Extend is a directed relationship that specifies how and when the
behavior defined in usually supplementary (optional) extending use
case can be inserted into the behavior defined in the extended use
case.
• Extended use case is meaningful on its own, it is independent of
the extending use case. Extending use case typically
defines optional behavior that is not necessarily meaningful by
itself.
• The extend relationship is owned by the extending use case
• The extension takes place at one or more extension points defined
in the extended use case.
• Extend relationship is shown as a dashed line with an open
arrowhead directed from the extending use case to the extended
(base) use case.
• The arrow is labeled with the keyword «extend».
iii. Include relationship or uses relationship
• When a use case is depicted as using the functionality of
another use case, the relationship between the use cases is
named as include or uses relationship.
• A use case includes the functionality described in another
use case as a part of its business process flow.
• A uses relationship from base use case to child use case
indicates that an instance of the base use case will include
the behavior as specified in the child use case.
• An include relationship is depicted with a directed arrow
having a dotted line.
• The tip of arrowhead points to the child use case and the
parent use case connected at the base of the arrow.
• The stereotype "<<include>>" identifies the relationship as
an include relationship.
iv. Generalization Relationship
• A generalization relationship means that a
child use case inherits the behavior and
meaning of the parent use case.
• The child may add or override the behavior of
the parent.
How to Draw a Use Case Diagram?
• Use case diagrams are drawn to capture the functional
requirements of a system. After identifying the above items,
we have to use the following guidelines to draw an efficient
use case diagram
• The name of a use case is very important. The name should
be chosen in such a way so that it can identify the
functionalities performed.
• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships, as the main
purpose of the diagram is to identify the requirements.
• Use notes whenever required to clarify some important
points.
Example 1
Example 2
Example 3