Object Oriented System Design

by
Surendra Keshari
Assistant Professor
KIET Group of Institutions
1
Use Case Diagram

2
 Use Case Diagram
 A UML use case diagram is the primary form of system/software requirements for a
new software program under developed.
 A key concept of use case modeling is that it helps us design a system from the end
user's perspective.
 It is an effective technique for communicating system behavior in the user's terms
by specifying all externally visible system behavior.
 It only summarizes some of the relationships between use cases, actors, and
systems.
 A use case diagram help system analyst to discover the requirements of the target
system from the users perspective.
 Provides functional description of a system & its major processes.
 Provides graphic description of the users of a system & what kinds of interactions
to exact within that system.
 Displays the details of the processes that occur within the application area.
 Used to design the test cases for testing the functionality of the system.
3
 Purpose of Use Case Diagram
 Specify the context of a system

 Capture the requirements of a system

 Validate a systems architecture

 Drive implementation and generate test cases

 Developed by analysts together with domain experts

4
 Elements of a Use Case Diagram
Actor:
 Someone interacts with use case (system function).

 Named by noun.

 An actor portrays any entity (or entities) that performs certain roles in a given system.

 Actor can be users, organization and external system.

 Actors are responsible for giving input to the system.

 It is shown as a stick figure in a use case diagram depicted “outside” the system

boundary.

5
 Elements of a Use Case Diagram
Actor (cont..)
 Place an actor that initiates a use case on the left of the use case & an actor
receives the results of a use case appears on the right of the use case.
 Actor plays a role in the business

 Similar to the concept of user, but a user can play different roles

 For example: A prof. can be instructor and also researcher, plays 2 roles with two

systems
 Actor has a responsibility toward the system (inputs), and Actor has expectations

from the system (outputs).

6
 Elements of a Use Case Diagram
Actor:

7
 Elements of a Use Case Diagram:
Use Case:
 System function (process - automated or manual)

 Named by verb + Noun (or Noun Phrase).

 Each Actor must be linked to a use case, while some use cases may not be linked to

actors.
 Use case in a use case diagram is a visual representation of a distinct business

functionality in a system.
 It is a sequence of transactions performed by the system that produces a major suit

for the actor.

8
 Elements of a Use Case Diagram:
Use Case (cont…):
 A use case is shown as an ellipse in a use case diagram.

 It must have unique and textual (simple/qualified) name.

Use Case

9
 Elements of a Use Case Diagram
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.
 It defines the scope of what a system will be.
 A system cannot have infinite functionality.
 Defines the limits of the system.
 It is shown as a rectangle spanning all the use cases in the system.
 Elements of a Use Case Diagram
Communication Link: Communication Lines / 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.
 Use case diagram has communication lines or links to show communication
between its various components.
 Association
 Dependency
Include
Extend
 Use case generalization

11
 Elements of a Use Case Diagram
Dependency (Include):

 Include is used when two or more use cases share some common portion in the
flow of events.
 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.

12
 Elements of a Use Case Diagram
Dependency (Extend):

 In an extend relationship , the child use case adds to the existing functionality &
characteristics of the parent use case
 Indicates that an "Invalid Password" use case may include (subject to specified in
the extension) the behavior specified by base use case "Login Account".
 Depict with a directed arrow having a dotted line. The tip of arrowhead points to
the base use case and the child use case is connected at the base of the arrow.
 The stereotype "<<extends>>" identifies as an extend relationship

13
 Elements of a Use Case Diagram
Association:

 It is used to describe the relationships between actors & the use cases they
participate in.
 Association can be unidirectional & bidirectional.
 It indicates either that the actor initiates the use case, or receives the results of
executing a use case.
 The association is drawn as a solid line

14
 Elements of a Use Case Diagram
Use Case Generalization:

 A generalization relationship is a parent-child relationship between use cases.

15
 Use Case Diagram At Glance
❑ Use Case

16
Vehicle Sales Systems

17
Use Case Diagram for online shopping of books

18
Basic Behavioural Modeling-
Activity Diagram

19
 Activity Diagram
❏ Activity diagram is another important behavioral diagram in UML diagram to describe
dynamic aspects of the system.
❏ Activity diagram is essentially an advanced version of flow chart that modeling the flow from
one activity to another activity.
❏ Activity Diagrams consist of activities, states and transitions between activities and states.
❏ Activity Diagrams describe
-how activities are coordinated to provide a service
-the events needed to achieve some operation
-how the events in a single use case relate to one another
-how a collection of use cases coordinate to create a workflow for an organization
20
 Activity Diagram
• Activity diagrams are used for
o documenting existing process
o analyzing new Process Concepts
o finding reengineering opportunities.

• The diagrams describe the state of activities by showing the sequence of activities performed.
o they can show activities that are conditional or parallel.
• Activity Diagrams should not take the place of interaction diagrams and state diagrams.

• Activity diagrams do not give detail about how objects behave or how objects collaborate.

21
 Activity Diagram Concepts
• An activity is trigged by one or more events and activity may result in one or more events
that may trigger other activity or processes.
• Events start from start symbol and end with finish marker having activities in between
connected by events.
The activity diagram represents the decisions, iterations and parallel/random behavior of the
processing.
• They capture actions performed.
• They stress on work performed in operations (methods).

22
 Activity Diagram at Glance
Activity:

23
 Activity Diagrams Elements
• Activities and Actions
• Transitions and Activity Edges
• Tokens and Activity Nodes
• Control Nodes
-Initial and Final Nodes
-Forks and Joins
-Decision and Merge Points
• States
• Swimlanes

24
 Activity Diagram Notations
Activity

Is used to represent a set of actions

Action

A task to be performed

Control Flow

Shows the sequence of execution

Object Flow

Show the flow of an object from one activity (or action) to another activity (or action).

25
 Activity Diagram Notations
Initial Node

Portrays the beginning of a set of actions or activities

Activity Final Node

Stop all control flows and object flows in an activity (or action)

Object Node

Represent an object that is connected to a set of Object Flows

Decision Node

Represent a test condition to ensure that the control flow or object flow only goes down one path

26
 Activity Diagram Notations
Merge Node

Bring back together different decision paths that were created using a decision-node.

Fork Node

Split behavior into a set of parallel or concurrent flows of activities (or actions)

Join Node

Bring back together a set of parallel or concurrent flows of activities (or actions).

Swimlane and Partition

• A partition in activity diagram by means of dashed line, called swim lane. This swim lane may be horizontal or vertical
• A way to group activities performed by the same actor on an activity diagram or to group activities in a single thread

27
 Activity Diagram Example:
Given the problem description related to the workflow for processing an order, let's model the description in visual representation using an
activity diagram:

Process Order - Problem Description

Once the order is received, the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the

billing.

On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the

Regular Delivery activity is performed.

Finally the parallel activities combine to close the order.

28
 Activity Diagram Example:
Process Order:

29
 How to construct Activity Diagrams
1. Finding system Actors, Classes and use cases
2. Identifying key scenarios of system use cases
3. Combining the scenarios to produce comprehensive workflows described using
activity diagrams
4. Where significant object behavior is triggered by a workflow, adding object flows to
the diagrams
5. Where workflows cross technology boundaries, using swimlanes to map the activities
6. Refining complicated high level activities similarly, nested activity diagrams

30
Action States

31
Activity States

32
Transitions

33
Branching

34
Forking and Joining

35
Swimlanes and Partition

36
Object Flow

37
 Events and Signals
• "Things that happen" are called events, and each one represents the specification of a
significant occurrence that has a location in time and space.
• Events may be synchronous or asynchronous, so modeling events is wrapped up in the
modelling of processes and threads.
• In the UML, each thing that happens is modeled as an event.
• A signal represents a named object that is dispatched (thrown) asynchronously by one
object and then received (caught) by another.

38
 Call Events
• Just as a signal event represents the occurrence of a signal, a call event represents the
dispatch of an operation.
• In both cases, the event may trigger a state transition in a state machine.
• Whereas a signal is an asynchronous event, a call event is, in general, synchronous.

39
 Time and Change Events
• A time event is an event that represents the passage of time.

40
 Processes and Threads
• In the UML, you model each independent flow of control as an active
object that represents a process or thread that can initiate control
activity.
• A process is a heavyweight flow that can execute concurrently with
other processes.
• A thread is a lightweight flow that can execute concurrently with
other threads within the same process. at represents the passage of
time.

41
Basic Behavioural Modeling-State
Diagram

42
 State Diagram
❏ A state diagram consists of states, transitions, events, and activities.
❏ State diagrams use to illustrate the dynamic view of a system.
❏ They are especially important in modeling the behavior of an interface, class, or
collaboration.
❏ State diagrams emphasize the event-ordered behavior of an object, which is especially useful
in modeling reactive systems.
❏ A dynamic model that shows the different states through which a single object passes during
its life in response to events, along with its responses and actions

43
 Terms and Concept
❏ A state machine is a behavior that specifies the sequences of states an object goes through during its

lifetime in response to events, together with its responses to those events.

❏ A state is a condition or situation during the life of an object during which it satisfies some condition,

performs some activity, or waits for some event.

❏ An event is the specification of a significant occurrence that has a location in time and space.

44
 Terms and Concept

❏ A transition is a relationship between two states indicating that an object in the first state will perform

certain actions and enter the second state when a specified event occurs and specified conditions are

satisfied. Activity is an ongoing non-atomic execution within a state machine.

❏ An action is an executable atomic computation that results in a change in the state of the model or the

return of a value.

45
Sample State Diagram for Patient Class

46
 State Diagram at Glance
State Diagram:

47
 State Diagram vs Activity
❏ Activity Diagrams are reducible to State Machines with some additional notations that the vertices
represent the carrying out of an activity and the edges represent the transition on the completion of one
collection of activities to the commencement of a new collection of activities.
❏ Activity Diagrams capture high-level activities aspects. In particular, it is possible to represent
concurrency and coordination in Activity Diagrams.
❏ In State Machines the vertices represent states of an object in a class and edges represent occurrences of
events. The additional notations capture how activities are coordinated.

48
 State Diagram Example
❏ ATM Example:

49
Vending Machine Example

50
Seminar

51
Concurrent States for a Printer in the On State

52
Nested States

53
 Developing State charts
Review class diagram and select classes that require statecharts
For each selected class in group, brainstorm to list all status conditions you can identify
Begin building statechart fragments by identifying transitions that cause object to leave
identifying state
Sequence these state-transition combinations in correct order
Review paths and look for independent, concurrent paths
Look for additional transitions
Take every pairwise combination of states and look for valid transition between states
Expand each transition with the appropriate message event, guard-condition, and action-
expression
Review and test each statechart

54
Basic Behavioural Modeling-Timing
Diagram

55
 Timing Diagram
❏ Real time systems are, by their very name, time-critical systems.

❏ Events may happen at regular or irregular times; the response to an event must happen at

predictable absolute times or at predictable times relative to the event itself.

56
 Timing Diagram
❏ Timing diagrams are UML interaction diagrams used to show interactions when a primary

purpose of the diagram is to reason about time.

time axis.
❏ Timing Diagrams describe behavior of both individual classifiers and interactions of

classifiers, focusing attention on time of occurrence of events causing changes in the

message, duration constraint, timing ruler.

57
58
 State Timeline Representation
❏ Changes from one state to another are represented by a change in the level of the lifeline. For the period of
time when the object is a given state, the timeline runs parallel to that state. A change in state appears as a
vertical change from one level to another. The cause of the change, as is the case in a state or sequence
diagram, is the receipt of a message, an event that causes a change, a condition within the system, or even
just the passage of time.

59
 Value lifeline Representation
The figure below shows an alternative notation of UML Timing diagram. It shows the state of the object
between two horizontal lines that cross with each other each time the state changes.

60
 Basic Concept
Lifeline
❏ A lifeline in a Timing diagram forms a rectangular space within the content area of a frame.

❏ Lifeline is a named element which represents an individual participant in the interaction. It is

typically aligned horizontally to read from left to right.

❏ Multiple lifelines may be stacked within the same frame to model the interaction between

them.

61
 Basic Concept
State Timeline in Timing Diagram
A state or condition timeline represents the set of valid states and time. The states are stacked on
the left margin of the lifeline from top to bottom.

62
 Basic Concept
Multiple Compartments
It is possible to stack several life lines of different objects in the same timing diagram. One life line above the
other. Messages sent from one object to another can be depicted using simple arrows. The start and the end
points of each arrow indicate when each message was sent and when it was received.

63
 Basic Concept
Timeline and Constraints
• We can use the length of a timeline to indicate how long the object remains in a particular state by reading it
from left to right. To associate time measurements, you show tick marks online the bottom part of the frame.
• The example below shows that the Login event is received three time units after the start of the sequence. To
show relative times, you can mark a specific instance in time using a variable name. The figure marks the time
the send Mail event is received as time

64
 Timing Diagram Example (User Experience Website Latency)
• An example of timing diagram which shows some duration constraints for a fabricated website to evaluate
how long web user should wait to see something rendered on his/her display.
• After web user enters web page URL, the URL should be resolved to some IP address. DNS resolution can
add some tangible waiting time to the response latency as perceived by user. Latency delays related to DNS
resolution could range from 1 ms (local DNS cache) to several seconds.
• With simple Model–View–Control (MVC) implementation, Java servlet gets control and requests some data
from "model". Communication with data sources usually takes some discernible time. After data is received
and processed, servlet forwards request processing to JSP ("view"). Buffered HTTP response is sent back to
the browser.
• Web browser takes some time to process HTTP response and HTML page to start rendering the page view to
the web client.

65
66
Interaction and Package Diagram

67
 Interaction Diagram
❏ UML Interaction Overview Diagrams provide a high level of abstraction an interaction
model.
❏ It is a variant of the Activity Diagram where the nodes are the interactions or interaction
occurrences.
❏ The Interaction Overview Diagram focuses on the overview of the flow of control of the
interactions which can also show the flow of activity between diagrams.
❏ In other words, you can link up the "real" diagrams and achieve high degree navigability
between diagrams inside an Interaction Overview Diagram.

68
 Interaction Diagram at Glance
Notation:

69
 Interaction Diagram Example
Access Control System

70
 Package Diagram
❏ Package diagram, a kind of structural diagram, shows the arrangement and organization of
model elements in middle to large scale project.
❏ Package diagram can show both structure and dependencies between sub-systems or
modules, showing different views of a system.

71
 Purpose of Package Diagram
Package diagrams are used to structure high level system elements. Packages are used for

organizing large system which contains diagrams, documents and other key deliverables.

❏ Package Diagram can be used to simplify complex class diagrams, it can group classes into

packages.

❏ A package is a collection of logically related UML elements.

❏ Packages are depicted as file folders and can be used on any of the UML diagrams.

72
 Package Diagram at Glance
Notations:

73
 Package Diagram Example
Order Processing System

74
Architectural Modeling: Component
& Deployment Diagram

75
 Component Diagram

❏ Component Diagrams Component diagrams are used in modeling the physical aspects of

object-oriented systems.

❏ A component diagram shows the organization and dependencies among a set of components.

❏ Component diagrams are used to model the static implementation view of a system.

❏ Component diagrams are essentially class diagrams that focus on a system’s components.

❏ Graphically, a Component diagram is a collection of vertices and arcs.

76
 Component Diagram

❏ Component diagrams are used for visualizing, specifying, and documenting component

based systems and also for constructing executable systems through forward and reverse

engineering.

❏ Component diagrams commonly contain Components, Interfaces and Dependency,

generalization, association, and realization relationships.

❏ It may also contain notes and constraints.

77
 Component Diagram at Glance
Notations:

78
 Component Diagram Example
Order System

79
 Deployment Diagram
❏ A UML deployment diagram is a diagram that shows the configuration of run time

processing nodes and the components that live on them.

❏ Deployment diagrams is a kind of structure diagram used in modeling the physical aspects

of an object-oriented system.

❏ They are often be used to model the static deployment view of a system (topology of the

hardware).

80
 Purpose of Deployment Diagram
❏ They show the structure of the run-time system

❏ They capture the hardware that will be used to implement the system and the links between

different items of hardware.

❏ They model physical hardware elements and the communication paths between them

❏ They can be used to plan the architecture of a system.

❏ They are also useful for Document the deployment of software components or nodes

81
 Deployment Diagram at Glance
Notations:

82
 Deployment Diagram Example
The working of
HTML5 video player
in the browser

83
Thank
You 84