UNIT V HIGH LEVEL DESIGN

Data Flows and States :

What is Data Flow?
 Data moves through different processes in an application.
 Example: A customer order flows through:
o Order Creation
o Order Assembly
o Shipping
o Billing (invoice sent to customer)

What is a State?
 A state describes the condition or phase of the data.
 For example, a customer order goes through states like:
o Created
o Assembled
 o Shipped
o Billed
Relation Between Data Flow & States
 Each process in data flow often corresponds to a state.
 The movement of data across processes represents a change in state.
Dynamic State Transitions
 State transitions can change based on events.
 Example:
o If an order is in Billed state and payment is not received in 30 days:
 Send second invoice
 Move to Late state
Diagrams Used
 Data Flow Diagrams (DFDs):
o Show how data moves through processes.
 State Transition Diagrams:
o Use rounded rectangles for states.
o Use arrows and labels to show events triggering transitions.
Importance
 Helps developers:
o Understand system behavior
o See how data and processes interact
o Handle exceptions and alternate flows
 Training :
When to Start Thinking About Training?
 Even before final design, it’s good to start planning training.
 System details may change, but training goals and methods can be outlined
early.
Types of Training Methods
 Instructor-led courses
 Printed manuals
 Instructional videos
 Online documentation
 Consider Different Learning Styles
 Users learn in different ways, so offer multiple training options:
o Mix and match methods.
o Allow users to choose what suits them best.
Hands-On Training is Effective
 Supervised hands-on practice is highly effective.
 It prepares users by letting them interact with the actual system.
Document Training Needs Early
 During high-level design, document:
o What types of training will be required.
o What kind of content trainers can begin preparing now.
 Full training content will be created as system details are finalized.
Why It's Important
 Proper training ensures smooth user adoption.
 Reduces confusion, errors, and improves productivity after system
deployment.
UML DIAGRAMS:
UML (Unified Modeling Language) :
What is UML?
 Not a single language — it's a collection of diagram types.
 Used to visually model software systems.
Who Defines UML?
 Defined by the Object Management Group (OMG).
 o An international non-profit setting modeling standards.
o Official site: www.uml.org
UML 2.0 Diagram Categories (Total 14 Diagrams)
A. Structure Diagrams – Focus on static parts of the system
1. Class Diagram – shows classes and their relationships
2. Component Diagram – represents software components and dependencies
3. Composite Structure Diagram – internal structure of a class
4. Deployment Diagram – shows physical deployment of software
5. Object Diagram – snapshots of instances of classes
6. Package Diagram – organizes system into packages
7. Profile Diagram – defines custom stereotypes and constraints
B. Behavior Diagrams – Focus on dynamic behavior of the system
8. Activity Diagram – shows workflows and activities
9. State Machine Diagram – shows states and transitions of an object
10.Use Case Diagram – represents system functions from user's perspective
C. Interaction Diagrams – Special kind of behavior diagram focused on
interactions
11.Communication Diagram – shows interactions between objects
12.Interaction Overview Diagram – combines activity and sequence behavior
13.Sequence Diagram – shows object interaction in time sequence
14.Timing Diagram – shows object behavior over time
Practical Use
 Focus on most common diagrams:
Class, Use Case, Activity, Sequence, and State Machine diagrams
  These help model different views of a system like structure, behavior,
interaction.
Why UML Matters
 Helps visualize, specify, construct, and document software systems.
 Aids communication among team members.
Structure Diagrams:
What Are Structure Diagrams?
 Describe static parts of a system (classes, components, packages, etc.)
 Focus on what exists in the system, not how it behaves.
Objects and Classes (Basics)
 A class defines a type; an object is an instance of that type.
 Example:
o Student class → defines Name, Grade, HomeRoom
o Rufus T. Firefly → a Student object with values
Types of UML Structure Diagrams:

Diagram Type Purpose

Shows classes, attributes, methods, and

Class Diagram
relationships

Component Diagram How components are assembled into larger systems

Composite Structure
Internal structure of classes and interactions
Diagram

Shows how software artifacts are deployed on

Deployment Diagram
hardware
Diagram Type Purpose

Object Diagram Snapshot of object instances and their relationships

Package Diagram Shows package organization and dependencies

Profile Diagram Used to define custom UML extensions

Class Diagram – The Most Basic UML Structure Diagram:

Representation
 A class diagram represents a class using a rectangle with 3 sections:
1. Class Name – at the top, centered, and in bold
2. Properties/Attributes
3. Methods/Operations
Example: Student Class:

 DoAssignment() is a method that defines a behavior for the Student

object.
Additional Details in Class Diagrams
 Data types of properties and method parameters are typically shown.
 You can include visibility symbols before members (see Table 6.2):
Symbol Visibility Meaning

+ Public Visible to all

Visible only within the

- Private
class

Visible to class and its

# Protected
subclasses

Visible within the same

~ Package
package only

Why It Matters
 Class diagrams are fundamental to understanding the structure of object-
oriented systems.
 Helps in planning and documenting classes, properties, behaviors, and
accessibility.
Relationships in Class Diagrams:
➤ Association
 Shows a connection between classes.
 Example: Student is taking Course
Multiplicity Indicators:
EXAMPLE:

Inheritance in Class Diagrams

 A child class inherits properties/methods from a parent class.
 Shown with a hollow arrowhead pointing from child to parent.
 Example:
HonorsStudent → inherits from Student
Best Practices
 Split large diagrams into multiple ones for clarity.
o One for inheritance
o One for associations
Behavior Diagrams:
What Are Behavior Diagrams?
 Used to model the dynamic behavior of a system.
 UML defines three primary types:

Diagram Type Purpose

Activity Diagram Represents workflows and logic flow

Use Case Diagram Shows system functions from user’s view

State Machine
Models states and transitions of objects
Diagram

Activity Diagrams
  Show step-by-step workflows, often with decisions, loops, and parallel
activities.
 Use arrows to indicate flow direction.
Example: Cookie Baking Workflow
 Start ➝ Branch into 3 parallel activities:
o Start oven
o Mix dry ingredients
o Mix wet ingredients
 After all 3 complete ➝ Join at second bar, then:
o Combine ingredients
o Check batter consistency (loop until right):
 If too sticky ➝ Add flour ➝ Recheck
o Roll out cookies
o Wait for oven, then bake for 8 minutes
 Decision Point:
o If not done, bake 1 more minute (loop)
o If done, reach stop state (black circled dot)
Why Use Activity Diagrams?
 Great for modeling business processes, system logic, and parallel tasks
 Easy to understand for both technical and non-technical users
 Use Case Diagram:
What Is a Use Case Diagram?
 Describes how users (actors) interact with the system's functionality (use
cases).
 Focuses on system behavior from a user’s perspective.
Key Elements:

Element Representation Description

A person, system, or device that

Actor Stick figure
interacts with the system

A specific task or function

Use Case Ellipse
performed by the system

Connects actor to use case

Association Line
(indicates interaction)
Relationships in Use Case Diagrams:

Relationship
Syntax Description
Type

One use case requires another

Include <<include>>
(mandatory subtask)

One use case optionally adds

Extend <<extend>>
behavior to another

 Arrows used with these are usually dashed.

 You may annotate the condition under which the <<extend>> occurs.
Example: Online Shopping Use Case
Actors
  Customer
 Search Engine
Use Cases
 Search site for products
o <<include>> → Find matching products (by Search Engine)
o <<extend>> → Buy products (optional)
 <<include>> → Log on to site (required before buying)

Why Use Case Diagrams Matter

 Help define system scope and requirements
 Clarify who does what and when
 Useful for both developers and clients/users
 State Machine Diagram:
What Is a State Machine Diagram?
 Describes the sequence of states an object goes through in response to
events.
 Used to model object behavior over time.
Diagram Elements:

Element Representation Description

State Rounded rectangle A condition or situation an object is in

Shows how object moves from one state

Transition Arrow
to another

Start state Solid black circle The beginning point of the diagram

Black circle inside a

End state The final state of the object’s life cycle
ring

Trigger/Condition Label on the arrow Event that causes a transition

Example: Reading a Floating-Point Number

Starting point
 Machine starts and waits for input: a digit, +, or –
Transitions

Input Next State

Digit before
+ or –
decimal

Digit or
Digit
decimal

Digit after
Decimal (.)
decimal

Remain in
Digit again
current state

Move to
Enter Stopping
state
 If an invalid character is entered at any point → error handling occurs (not
modeled in this example, but mentioned)
When Does the Diagram Stop?
 User presses Enter key in either:
o Digit or decimal state (e.g., for whole numbers like 37)
o Digit after decimal state (e.g., 37.5)
Why State Machine Diagrams Are Useful
 Help visualize how an object responds to events over time
 Ideal for modeling:
o UI screens and navigation
o Login/logout flows
o Protocol state changes
o Input validation (like this number reader)
Interaction Diagrams:
What Are Interaction Diagrams?
 A subset of behavior diagrams
 Focus on how objects interact with each other through messages over time
Types of Interaction Diagrams:

Diagram Type Purpose

Shows the time-ordered interaction between objects

Sequence Diagram
using vertical lifelines and horizontal messages

Communication Focuses on object relationships and message flow

Diagram without strict time order

Emphasizes object state changes and timing constraints

Timing Diagram
across a time axis

Interaction Overview Combines features of activity and sequence diagrams,

Diagram useful for complex workflows
Quick Overview of Each Diagram Sequence Diagram
 Vertical lines: Lifelines (objects)
 Horizontal arrows: Messages
  Time flows top to bottom
 Good for showing call sequences, message flow, and interactions
Communication Diagram
 Nodes = Objects
 Arrows = Messages (numbered to show order)
 Focus is on structure and flow, not timing
Timing Diagram
 X-axis = Time
 Y-axis = State changes of lifelines
 Ideal for real-time systems and scenarios involving precise timing
Interaction Overview Diagram
 Like a flowchart of interactions
 Combines activity diagram layout with sequence diagram detail
 Shows how multiple interactions are coordinated

 Help understand how different parts of a system collaborate

 Useful for modeling use cases, UI actions, method calls, and real-time
events
Sequence Diagram:
What Is a Sequence Diagram?
 Models object interactions in a specific scenario, focusing on the order
(sequence) of messages exchanged.
 Excellent for visualizing communication flow during an event or use case.
Key Components:
 Element Representation Description

An object/class or user
Rectangle (object) or
Participant interacting in the
stick figure (actor)
scenario

Vertical dashed line Shows the life of the

Lifeline below each object during
participant interaction

Represents when the

Execution Narrow rectangle on object is doing
(Activation) lifeline something (method is
active)

Synchronous Message that waits for

Solid arrowhead
Message a response

Asynchronous Message that does not

Open arrowhead
Message wait for a reply

Dashed arrow with Sent in response to a

Return Message
open arrowhead message call
Example: Buying a Movie Ticket
Participants:
 Customer
 Clerk
 Movie (class)
Interaction Steps (Simplified Flow):
1. Customer requests a movie ➝ Clerk
2. Clerk queries availability ➝ Movie
3. Movie replies asynchronously (e.g., true/false)
 4. If available, Clerk ➝ Movie: Select seat
5. Movie ➝ Customer: Pick seat (customer still waiting — overlapping
execution)
6. After seat selection:
o Movie ➝ Clerk: Send ticket
o Clerk prints and hands it to Customer
📝 Note: The diagram emphasizes message flow and order, not internal logic.
4. Execution Details
 Overlapping execution: When a participant is already involved in
one action but gets another task (e.g., customer choosing a seat).
 Lifelines + activations help trace who is "active" at what time.

Why Use Sequence Diagrams?

 Visualize interactions clearly
 Understand timing and message flow
 Helps in designing methods, APIs, and object interactions
Communication Diagram:
What Is a Communication Diagram?
 Type of interaction diagram that models how objects collaborate to perform
a behavior.
 Focuses on which objects communicate, not precisely when.
Key Differences from Sequence Diagram:

Feature Sequence Diagram Communication Diagram

Focus Order of messages Structure of object communication

Free-form layout (object placement

Layout Vertical time axis
varies)

Arrows (top to Numbered messages (e.g., 1, 1.1,

Message Order
bottom) 1.2)

Return
Clearly shown Not clearly shown
Messages
Components of a Communication Diagram:

Element Description

Objects Shown as named rectangles

Links Lines between objects showing a relationship

Numbered arrows along the links showing

Messages
communication
Element Description

Message
Indicated by numbers like 1, 1.1, 1.2
Sequence
Example: Buying a Movie Ticket (Same as Sequence Diagram):
Message Flow:
1: Customer → Clerk: Request ticket
1.1: Clerk → Movie: Check availability
1.2: Clerk → Movie: Select seat
1.2.1: Movie → Customer: Pick seat
1.2.2: Movie → Clerk: Send ticket
1.3: Clerk → Customer: Print and give ticket

Key Notes
 Best for understanding which objects are involved and how they are
connected.
 Not suitable for representing:
o Return messages
o Exact timing or overlapping actions
Why Use Communication Diagrams?
 Great for object-oriented design
 Helps understand inter-object relationships
 Easier to draw and grasp collaboration structure
Timing Diagram:
What Is a Timing Diagram?
 A behavior diagram that shows how objects change state over time
 Emphasizes timing constraints, duration, and state changes
Visual Style
 Looks like a sideways sequence diagram
o Time flows left to right
o Object lifelines are laid out vertically
 Often used to analyze real-time or time-sensitive systems
Components of a Timing Diagram

Element Description

Lifeline/Object Each participant shown in a horizontal row

State Timeline Shows how the object’s state evolves over time

Message Arrows (Optional) Show interactions between lifelines

Indicate exact times of state changes or message

Time Markers
exchanges
Advanced Timing Diagrams
 Can include multiple participants
 Show stacked lifelines with arrows between them
 Useful for analyzing:
o Embedded systems
o Hardware-level timing
o Communication protocols
Why Use a Timing Diagram?
 Helps you:
o Visualize when state transitions occur
o Understand how long each state lasts
o Model precise behavior over time
 Ideal for:
o Performance-critical scenarios
o Synchronization analysis
Interaction Overview Diagram:
What Is an Interaction Overview Diagram?
 A hybrid diagram that combines:
o The layout of an activity diagram
o With interaction diagrams (like sequence, communication, or timing
diagrams) embedded as frames
 Shows control flow between interactions
Key Features:

Feature Description

Activity-style Uses activity diagram nodes (initial node, decision node,

flow etc.)

Interaction Nodes can contain detailed diagrams like sequence or

 Feature Description

frames communication diagrams

Supports You can even nest other interaction overview diagrams

nesting inside frames

Shows process Ideal for high-level overviews with links to detailed

flow interactions
Why Use Interaction Overview Diagrams?
 Best for:
o Complex processes involving multiple interactions
o Structuring large workflows that can't be explained in a single
diagram
 Helps in organizing modular, layered behavior visually

Think of It Like:

“A storyboard where each scene (frame) is another detailed diagram.”