1. Software Design Processes and Management
Chapter Two in Fox’s Introduction to Software Engineering Design

2. Software Design Process
A Process is a set of related and (sequenced) tasks that transforms a set of input to a set of output.
Outputs
Inputs
Design
Process
requirements
specifications
sequence of tasks
design
specifications
Is this diagram very clear? What does the rectangle, arrow, or the circle mean?
What about the coloring and the lables?

3. Talking About Design (indirectly)
We will describe:
Notations used to describe design activities
Design activities
Sequence of processing
Information (data) involved in the processing
Pointing out general design techniques:
Abstraction (& modeling)
Refinement (decomposition)

4. UML’s Activity Diagram
We use UML’s Activity Diagram to “model” the activities (sequence of tasks) in a system
main components (& its functionality)
relationship (interactions) among components
Activities (eventually decomposed down to functional actions, which are “atomic” in nature)
Activity Diagrams also depict the “Flow” of
Control
Data (information)

5. UML’s Activity Diagram
Software Design Process itself may be depicted or “modeled” with UML’s Activity Diagram since a Design Process is composed of:
Activities or Tasks
Represented as action nodes
(rounded rectangles)
Flow (of control & data)
Represented as edges (arrows)
Activity 1
Activity 2
Activity 3
Activity 4

6. Activity Diagrams and Activity Graphs
Activity Diagrams model processes as an activity graph.
An activity graph has:
Activity nodes or action nodes that represent actions or objects, and
Activity edges that represent control or data flows
Initial node used to start execution; represented by a small filled circle with only a single outgoing edge
Activity final node shows the end of execution; represented by a small filled circle within another circle; edges can only enter an activity final node
Action nodes are represented by rounded rectangles
Activity edges are represented by solid arrows with unfilled arrow heads

7. UML’s Activity Diagram
This Activity Diagram depicts a “virtual machine” behavior of the process where there are tokens which run through the edges.
An action node begins Its execution when the tokens from all its incoming edges arrive (implied synchronization)
2) When an action node begins execution it consumes all these tokens.
3) After a task is completed, the action node sends a token out on each of its outgoing edges.
Token in
initial Node
Read
Req. Doc.
analyze
Requirements
prioritize
Requirements
Review
Requirements
Token in
Final Node

8. Decision and Merge Nodes
Besides the activity nodes and the edges, we need a mechanism to depict alternative flow based on some decision.
Decision node
Guard [in brackets]
Merge node
Why do
we need
A merge
node
here ?
Req. Spec. Review
1) a decision node has a single
entry edge, but multiple edges
leaving it
2) a guard labels the “condition”
(Boolean)that controls the flow through the edge (path)
3) a merge node has multiple
entering edges but one exit edge
Write
Req. spec.
Review
Req. spec.
[non-concur]
[concur]
A) If a token is available on any of
the merge entering edges, it is passed to
the leaving node.
B) If a token is available on the decision node’s entering edge, a decision is made and a token is passed to the edge with the guard that depicts the decision
Approve
Req. Spec.
Activity Symbol

9. Fork and Join in Control Flow (Explicit Synchronization)
When a token is available on
the incoming edge of a FORK
Node (thick line), the token is
duplicated and posted on all the
outgoing edges of FORK starting
Concurrent threads of execution
Note : this is a bit like the Petri net
Read
Req. Doc.
analyze
Requirements
prioritize
Requirements
Review
Requirements
When tokens are available on
ALL the incoming edges of a JOIN
Node (thick line), a token is placed
on the outgoing edge, synchronizing
Concurrent threads of execution
Also: Read page 39 of your text on “flow final node”

10. Data tokens and Data flow
Data may flow through an Activity Diagram. Data and objects are shown as object nodes (a rectangular figure):
Alternatively, Data flows shown by object nodes may be represented in the form of input pin and output pin:
Write
Req. spec.
Written Spec.
Spec.
for review
Req. Doc
[reviewed]
state of
data
Review
Req. spec.
reviewed spec.
[non-concur]
[concur]
concurred Spec.
Approve
Req. Spec.
Req. Doc
[approved]

11. What about the input & output of the process?
process name
Data name and data type
Activity Parameters
Req. Spec. Review Process
reqNotes: Docs
apprReqSpec : Docs
What about the input & output of the process?
reqNotes
- A process consumes inputs
and produces outputs.
- The inputs and outputs of a process may be represented
as “parameters” to and from
the process.
- These parameters, in form of
data or object nodes, are placed
on the boundary of the activity
symbol
Write
Req. spec.
Written Spec.
Spec.
for review
Review
Req. spec.
reviewed spec.
[non-concur]
[concur]
concurred Spec.
Note that we have listed the
parameters at the upper left
corner of the Activity Symbol
apprReqSpec
Approve
Req. Spec.
approved Spec.
Why are there no initial or final nodes in this diagram?

12. When to Use Activity Diagram?
Activity diagrams can document dynamic models of any process.
May be used to depict the design (especially a description of a set of actions) at either
High level (architectural and intermediate model) or
Low level (pseudo code level)
depicting:
Activity
Control flow
Data and data flow
(See page 45 of your text)
Also, note that an action node in an activity diagram may itself be expanded into
an activity diagram giving us the capability of further refinement

13. Some Guidelines to Activity Diagrams
Use Activity Diagram to “model” the dynamic (or flow) process.
Draw the flow control from left to right and from top to bottom.
Name activity nodes with verb phrases.
Name data nodes and data pins with noun phrases.
Use the guard and labels on every output edge of a condition node.
Use data flow, and not both control and data flow, whenever data flow alone can suffice.
Make sure that all flows entering a node can provide tokens concurrently, so that no deadlock can occur or use merge nodes.
Noted: the condition node and the merge node syntax, diamond, being the same,
is NOT appealing ---- room for improvement

14. “High Level” Software Design Process using Activity Diagram (Example)
Needs & Wants: Doc
Design Document: Doc
Needs &
Wants
Product Design Analysis
Product Design “Resolution”
SRS
Engineering Design Analysis
Engineering Design Resolution
Design
Document

15. General Engineering Design Technique
2 main steps:
Analysis of problem : Breaking Down, Understanding and clearly Defining
the Problem
Design the solution : Finding the Solution(s) to the (Sub-)Problem(s)
and Constructing the overall solution
Understand the problem and clearly defining it. (very important)
Develop possible solution(s)
Evaluate the potential solutions
If there is a “best” selection, choose it; otherwise iterate through step 2 again.
Finalize and document the chosen solution

16. Software Engineering Design (in Activity Diagram)
SRS : Doc
Design Document: Doc
Note:
1. Analysis is
understanding
the SRS
SRS
Engineering Design Analysis
clear Problem
Statements
Generate Possible Solutions
Note:
1. Generate
more than 1
solution
2. Process is
iterative
Candidate
Solutions
Evaluate Candidate Solutions
Select Solution
[else-no solution]
[selected solution]
Selected
Solution
Design
Document
finalize/document the Solution

17. Two Levels of Software Engineering Design
Software Engineering Design (levels):
Architectural Level
Detailed Level
The previous Activity Diagram is “repeated” for each of the 2 levels, with different inputs and outputs.
SRS (analyzed) is the input for Architectural Design Level
Selected architectural design specification is the output for this level
Architectural design specification combined with SRS is the input to the Detail Design level
Detailed Design analysis analyzes the architectural design specification
Detailed design document is the output for Detail Design level
Recall:
- “Analysis” : breakdown, understand and further define
- “Design” : propose solution alternatives; choose the solution; refine it; define it
Redraw the previous activity diagram to depict the 2-level engineering design.

18. Software Design Management
Designing Software is an activity that resembles a project in itself.
Operations (regular recurring work payroll, monthly finance, etc.)
** Project (one time effort that starts and achieves specific goal)
Design Activities needs to be managed as a project with:
Planning
Organizing
Staffing
Tracking (monitoring)
Leadership-ing (adjusting and redirecting)
Management of any project is very “iterative” between tracking and leading.
But the process may also feedback to planning and re-adjust the plan

19. Managing Design Work
Managing any project depends a lot on how the work is decomposed – Design may be viewed as:
Product Design
Product Design Analysis:
Understanding the overall customer problem
Understanding the details of customers’ needs and wants
Product Design Resolution:
Reviewing, clarifying and prioritizing the overall problems and details
Defining, documenting,& agreeing on the problem and details in SRS document
Engineering Design
Engineering Design Analysis:
Study and analyze the SRS
Engineering Architectural Resolution:
Generating and documenting a high level architectural design document
Engineering Detailed Design Resolution:
Generating and documenting a detailed designed document
Management Activities with this view of Design - WBS:
Planning the following:
Estimating of time needed
Estimating resources needed
Putting together a schedule
Assessing risks
Organizing the project
Team structure
Authority structure
Tracking (monitoring)
Schedule
Design outputs-quality
Leading (adjusting)
Providing direction & support
This is the Work Breakdown Structure (WBS)