Contents
Introduction
In UML, the dynamic aspects of a system can be modeled using interactions. Interactions contain messages that are exchanged between objects. A message can be an invocation of an operation or a signal. The messages may also include creation and destruction of other objects.
We can use interactions to model the flow of control within an operation, a class, a component, a use case or the system as a whole. Using interaction diagrams, we can model these flows in two ways: one is by focusing on how the messages are dispatched across time and the second is by focusing on the structural relationships between objects and then consider how the messages are passed between the objects.
Graphically a message is rendered as a directed line with the name of its operation as show below:
Interaction (Definition)
An interaction is a behavior that contains a set of messages exchanged among a set of objects within a context to accomplish a purpose. A message is specification of a communication between objects that conveys information with the expectation that the activity will succeed.
Objects and Roles
The objects that participate in an interaction are either concrete things or prototypical things. As a concrete thing, an object represents something in the real world. For example, p an instance of the class Person, might denote a particular human. Alternately, as a prototypical thing, p might represent any instance of Person.
Links
A link is a semantic connection among objects. In general, a link is an instance of association. Wherever, a class has an association with another class, there may be a link between the instances of the two classes.
Wherever there is a link between two objects, one object can send messages to another object. We can adorn the appropriate end of the link with any of the following standard stereotypes:
Messages
A message is the specification of communication among objects that conveys information with the expectation that activity will succeed. The receipt of a message instance may be considered an instance of an event.
When a message is passed, the action that results is an executable statement that forms an abstraction of a computational procedure. An action may result in a change of state. In UML, we can model several kinds of actions like:
Sequencing
When an object passes a message to another object, the receiving object might in turn send a message to another object, which might send a message to yet a different object and so on.
This stream of messages forms a sequence. So, we can define a sequence as a stream of messages. Any sequence must have a beginning. The start of every sequence is associated with some process or thread.
To model the sequence of a message, we can explicitly represent the order of the message relative to the start of the sequence by prefixing the message with a sequence number set apart by a colon separator.
Most commonly, we can specify a procedural or nested flow of control, rendering using a filled solid arrowhead. Less common but also possible, you can specify a flat flow of control, rendered using a stick arrowhead.
We will use flat sequences only when modeling interactions in the context of use cases that involve the system as a whole, together with actors outside the system.
In all other cases, we will use procedural sequences, because they represent ordinary, nested operation calls of the type we find in most programming languages.
Representation
When we model an interaction, we typically include both objects and messages. We can visualize those objects and messages involved in an interaction in two ways: by emphasizing the time ordering of messages and by emphasizing the structural organization of the objects that send and receive messages.
In UML, the first kind of representation is called a sequence diagram and the second kind of representation is called a collaboration diagram. Both sequence and collaboration diagrams are known as interaction diagrams.
Sequence diagrams and collaboration diagrams are isomorphic, meaning that we can take one and transform it into the other without loss of information. Sequence diagram lets us to model the lifeline of an object. An object’s lifeline represents the existence of the object at a particular time.
A collaboration diagram lets us to model the structural links that may exist among the objects in the interaction.
Common Modeling Techniques
Modeling a flow of control
To model a flow of control,
- Set the context for the interaction, whether it is the system as a whole, a class or an individual operation.
- Identify the objects and their initial properties which participate in the interaction.
- Identify the links between objects for communication through messages.
- In time order, specify the messages that pass from object to object. Use parameters and return values as necessary.
- To add semantics, adorn each object at every moment in time with its state and role.
Consider the following example of railway reservation system’s sequence and collaboration diagrams:
Suryateja Pericherla, at present is a Research Scholar (full-time Ph.D.) in the Dept. of Computer Science & Systems Engineering at Andhra University, Visakhapatnam. Previously worked as an Associate Professor in the Dept. of CSE at Vishnu Institute of Technology, India.
He has 11+ years of teaching experience and is an individual researcher whose research interests are Cloud Computing, Internet of Things, Computer Security, Network Security and Blockchain.
He is a member of professional societies like IEEE, ACM, CSI and ISCA. He published several research papers which are indexed by SCIE, WoS, Scopus, Springer and others.
Very soon this web page will be famous amid all blog people, due to it’s
good content