1 of 49

�UNIT-4

Behavioural Modelling:

  1. Interactions
  2. Interaction diagrams
  3. Use cases
  4. Use case Diagrams
  5. Activity Diagrams
  6. Events and signals
  7. state machines
  8. processes and Threads
  9. Time and space
  10. state chart diagrams

2 of 49

�UNIT-4

Architectural Modelling:

  1. Component
  2. Deployment
  3. Component diagrams
  4. Deployment diagrams

3 of 49

Behavioural Modelling

Interactions:

  • In UML, the dynamic aspects of a system can be modelled using interactions. Interactions contain messages that are exchanged between objects. A message can be an invocation of an operation or a signal.
  • We can use interactions to model the flow of control within an operation.
  • 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.
  • Interactive behaviour is represented in UML by two diagrams known as Sequence diagram and Collaboration diagram. The basic purpose of both the diagrams are similar.

4 of 49

Purpose of Interaction Diagrams

  • To capture the dynamic behaviour of a system.
  • To describe the message flow in the system.
  • To describe the structural organization of the objects.
  • To describe the interaction among objects.

5 of 49

�Behavioural Modelling

Use of an Interaction Diagram

  1. The sequence diagram is employed to investigate a new application.
  2. The interaction diagram explores and compares the use of the collaboration diagram sequence diagram and the timing diagram.
  3. The interaction diagram represents the interactive (dynamic) behavior of the system.
  4. The sequence diagram portrays the order of control flow from one element to the other elements inside the system, whereas the collaboration diagrams are employed to get an overview of the object architecture of the system.
  5. The interaction diagram models the system as a time-ordered sequence of a system.
  6. The interaction diagram systemizes the structure of the interactive elements

6 of 49

How to Draw an Interaction Diagram?

The purpose of interaction diagrams is to capture the dynamic aspect of a system. So to capture the dynamic aspect, we need to understand what a dynamic aspect is and how it is visualized. Dynamic aspect can be defined as the snapshot of the running system at a particular moment

Following things are to be identified clearly before drawing the interaction diagram

  • Objects taking part in the interaction.
  • Message flows among the objects.
  • The sequence in which the messages are flowing.
  • Object organization.

7 of 49

sequence diagram of ORDER MANAGEMENT SYSTEM

  • The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).
  • The following diagram shows the message sequence for SpecialOrder object and the same can be used in case of NormalOrder object. It is important to understand the time sequence of message flows. The message flow is nothing but a method call of an object.
  • The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a method of SpecialOrder object and the last call is Dispatch () which is a method of SpecialOrder object. The following diagram mainly describes the method calls from one object to another, and this is also the actual scenario when the system is running.

8 of 49

9 of 49

collaboration diagram

  • The second interaction diagram is the collaboration diagram. It shows the object organization as seen in the following diagram. In the collaboration diagram, the method call sequence is indicated by some numbering technique. The number indicates how the methods are called one after another. We have taken the same order management system to describe the collaboration diagram.
  • Method calls are similar to that of a sequence diagram. However, difference being the sequence diagram does not describe the object organization, whereas the collaboration diagram shows the object organization.
  • To choose between these two diagrams, emphasis is placed on the type of requirement. If the time sequence is important, then the sequence diagram is used. If organization is required, then collaboration diagram is used.

10 of 49

11 of 49

Where to use Intraction Diagrams:

  • Interaction diagrams are used when we want to understand the message flow and the structural organization. Message flow means the sequence of control flow from one object to another.

Interaction diagrams can be used −

  • To model the flow of control by time sequence.
  • To model the flow of control by structural organizations.
  • For forward engineering.
  • For reverse engineering.

12 of 49

Sequence Diagrams

Collaboration Diagrams

The sequence diagram are used to represent the sequence of messages that are flowing from one object to another.

The collaboration diagram are used to represent the structural organization of the system and the messages that are sent and received.

The sequence diagram is used when time sequence is main focus.

The collaboration diagram is used when object organization is main focus.

The sequence diagrams are better suited of analysis activities.

The collaboration diagrams are better suited for depicting simpler interactions of the smaller number of objects.

13 of 49

Behavioural Modelling

  • use cases :
  • A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modelling Language (UML) as an actor) and a system to achieve a goal.
  • The actor can be a human or other external system.
  • use cases are used at a higher level 
  • Use cases are a technique for capturing, modelling and specifying the requirements of a system.
  • Below is a sample use case

14 of 49

�Behavioural Modelling

Use Case Diagrams :

A use case diagram is used to represent the dynamic behaviour of a system. It encapsulates the system's functionality by incorporating use cases, actors, and their relationships.

Purpose of Use Case Diagrams

  • It gathers the system's needs.
  • It depicts the external view of the system.
  • It recognizes the internal as well as external factors that influence the system.
  • It represents the interaction between the actors.

15 of 49

�Behavioural Modelling

How to draw a Use Case diagram

  • A pertinent and meaningful name should be assigned to the actor or a use case of a system.
  • The communication of an actor with a use case must be defined in an understandable way.
  • The most significant interactions should be represented among the multiple no of interactions between the use case and actors.

16 of 49

  • Following is a sample use case diagram representing the order management system. Hence, if we look into the diagram then we will find three use cases (Order, SpecialOrder, and NormalOrder) and one actor which is the customer.
  • The SpecialOrder and NormalOrder use cases are extended from Order use case. Hence, they have extended relationship. Another important point is to identify the system boundary, which is shown in the picture. The actor Customer lies outside the system as it is an external user of the system.

17 of 49

18 of 49

�Example of Use case Diagram

Both View Recommended Item and Add to Wish List include the Customer Authentication use case, as they necessitate authenticated customers, and simultaneously item can be added to the shopping cart without any user authentication.

19 of 49

�Example of Use case Diagram

The Checkout use case also includes the following use cases, as shown below. It requires an authenticated Web Customer, which can be done by login page, user authentication cookie ("Remember me"), or Single Sign-On (SSO). SSO needs an external identity provider's participation, while Web site authentication service is utilized in all these use cases..

20 of 49

�Use Case Diagram

some important tips that are to be kept in mind while drawing a use case diagram:

  • A simple and complete use case diagram should be articulated.
  • A use case diagram should represent the most significant interaction among the multiple interactions.
  • At least one module of a system should be represented by the use case diagram.
  • If the use case diagram is large and more complex, then it should be drawn more generalized.

21 of 49

�Activity Diagrams

The activity diagram is used to demonstrate the flow of control within the system rather than the implementation.

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions or operations that are applied to model the behavioural diagram.

Components of an Activity Diagram

Activities

The categorization of behaviour into one or more actions is termed as an activity.

22 of 49

�Activity Diagrams

Swim lane: The swim lane is used to cluster all the related activities in one column or one row. It can be either vertical or horizontal. It used to add modularity to the activity diagram.

Forks: Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one inward edge and several outward edges.

Join Nodes: Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the inward edges as it synchronizes the flow of input across one single output (outward) edge.

23 of 49

�Activity Diagrams

Notation of an Activity diagram

Initial State: It depicts the initial stage or beginning of the set of actions.

Final State: It is the stage where all the control flows and object flows end.

Decision Box: It makes sure that the control flow or object flow will follow only one path.

Action Box: It represents the set of actions that are to be performed

24 of 49

�Activity Diagrams

Example of an Activity Diagram:

An activity diagram showing the business flow activity of order processing.

25 of 49

An activity diagram can be used to portray business processes and workflows.

  • An activity diagram is utilized for the followings:
  • To graphically model the workflow in an easier and understandable way.
  • To model the execution flow among several activities.
  • To model comprehensive information of a function or an algorithm employed within the system.
  • To model the business process and its workflow.
  • To envision the dynamic aspect of a system.
  • To generate the top-level flowcharts for representing the workflow of an application.
  • To represent a high-level view of a distributed or an object-oriented system.

26 of 49

�Events and Signals

 Events and Signals: These are use in state chart diagram.

  • Events represent important occurrences that have a time (the time when the event happened) and space (where the event happened) 
  • Events can be of two types -synchronous or asynchronous 
  • In a synchronous event the sender waits for an action from the receiver on the event. For example, pressing a button on the mouse, a phone call, etc. 
  • There is no waiting in an asynchronous event. For example, sending an e-mail, letter, delivery of newspaper, etc.

27 of 49

�Events and Signals

Events

28 of 49

Call Event :

  • a call event represents the dispatch of an operation
  • a call event is a synchronous event

29 of 49

Signals

  • Signals refer to the objects that are dispatched asynchronously by one object and then received by another 
  • Exceptions and e-mails are an example of internal signals 
  • They may have instances, generalization relationships, attributes and operations 

30 of 49

�State Machines

State machines :

Notation of a State Machine Diagram

Initial state: It defines the initial state (beginning) of a system, and it is represented by a black filled circle.

Final state: It represents the final state (end) of a system. It is denoted by a filled circle present within a circle.

Decision box: It is of diamond shape that represents the decisions to be made on the basis of an evaluated guard.

State box: It depicts the conditions or circumstances of a particular object of a class at a specific point of time.

A rectangle with round corners is used to represent the state box.

31 of 49

�Events and Signals

state machine

It may be sent as the action of a state transition in a state machine or the sending of a message in an interaction   

Signals are modelled as stereotyped classes and the relationship between an operation and the events by using a dependency relationship, stereotyped as send.

32 of 49

�Events and Signals

Sending and Receiving Events 

For Synchronous Events: 

  • Sending or receiving is similar to call event 
  • The sender and the receiver are in a meeting (the sender sends the signal and wait for a response from the receiver) for the duration of the operation 
  • When an object calls an operation, the sender sends the operation and then waits for the receiver.

For Asynchronous Events: 

  • Sending or receiving is similar to signal event 
  • The sender and receiver do not meet, i.e., the sender sends the signal but does not wait for a response from the receiver 
  • When an object sends a signal, the sender sends the signal and then continues along its flow of control, without waiting for any return from the receiver 

33 of 49

�Events and Signals

 Signals and Active Classes

34 of 49

�State Machines

State machines :

The state machine diagram is also called the State chart or State Transition diagram, underwent by an object within the system which shows the order of states

It captures the software system's behaviour. It models the behaviour of a class, a subsystem, a package, and a complete system.

Following are the types of a state machine diagram

1. Behavioural state machineThe behavioural state machine diagram records the behaviour of an object within the system. It depicts an implementation of a particular entity. It models the behaviour of the system.

2. Protocol state machineIt captures the behaviour of the protocol. The protocol state machine depicts the change in the state of the protocol and parallel changes within the system. But it does not portray the implementation of a particular component.

35 of 49

�State Machines

Following are the steps while drawing a state machine diagram:

  • A unique and understandable name should be assigned to the state transition that describes the behaviour of the system.
  • Out of multiple objects, only the essential objects are implemented.
  • A proper name should be given to the events and the transitions.

State machine diagram is used for:

  • For modeling the object states of a system.
  • For modeling the reactive system as it consists of reactive objects.
  • For pinpointing the events responsible for state transitions.
  • For implementing forward and reverse engineering.

36 of 49

�State Machines

Example of a State Machine Diagram

37 of 49

�State Machines

State Machine Vs Flow Chart

38 of 49

�Processes and Threads

Processes and Threads :

Processes

A process is an active program i.e. a program that is under execution. A process is a heavyweight flow that can execute concurrently with other processes. 

NEW: A new process is being created.

READY: A process is ready and waiting to be allocated to a processor.

RUNNING: The program is being executed.

WAITING: Waiting for some event to happen or occur.

TERMINATED: Execution finished.

39 of 49

�Processes and Threads

Threads :

A thread is the subset of a process and is also known as the lightweight process. A process can have more than one thread, and these threads are managed independently by the scheduler.

40 of 49

�Processes and Threads

Processes and Threads :

Types of Threads

There are two types of threads, which are:

1. User Level Thread

As the name suggests, the user-level threads are only managed by users, and the kernel does not have its information.

These are faster, easy to create and manage.

2. Kernel-Level Thread

The kernel-level threads are handled by the Operating system and managed by its kernel. These threads are slower than user-level threads because context information is managed by the kernel. To create and implement a kernel-level thread, we need to make a system call.

41 of 49

Architectural Modelling: ��Component�Deployment�Component diagrams �Deployment diagrams

42 of 49

Component Diagram

  • A component diagram is used to break down a large object-oriented system into the smaller components, so as to make them more manageable.
  • It visualizes the relationships as well as the organization between the components present in the system. 
  • Component diagrams can describe software systems that are implemented in any programming language or style.

Benefits

  • Imagine the system’s physical structure.
  • Pay attention to the system’s components and how they relate.
  • Emphasize the service behavior as it relates to the interface.

43 of 49

Component diagram notations

44 of 49

Example of a Component Diagram�online shopping:

45 of 49

Deployment diagrams

The deployment diagram visualizes the physical hardware on which the software will be deployed.

Purpose of Deployment Diagram

  • The main purpose of the deployment diagram is to represent how software is installed on the hardware component.
  • It depicts in what manner a software interacts with hardware to perform its execution.
  • To represent the hardware components on which the software components are installed.
  • To describe the processing of nodes at the runtime.

46 of 49

Symbol and notation of Deployment diagram�

  • The deployment diagram consist of the following notations:
  • A component
  • An artifact
  • An interface
  • A node

47 of 49

Deployment diagram of ATM

48 of 49

Role during the administrative process, it involves the following parameters:

  • High performance
  • Scalability
  • Maintainability
  • Portability
  • Easily understandable

49 of 49

END OF UNIT-IV

Thank

you

Department of Information Technology

49