ITEC 3010

Design

1
2
3
 The Structure Chart
• Structure chart
– A hierarchical diagram showing the relationships
between the modules of a computer program
– The objective of structured design is to create a top-
down decomposition of the functions to be performed
by a given program in a system – use a structure chart
to show this
– E.g. shows functions and sub functions (such as
Calculate base amount, Calculate overtime amount
etc.)
– Uses rectangles to represent each such module (the
basic component of a structure chart
– Higher-level modules are “control” modules that
control flow of execution (call lower level modules
which are the “worker bee” modules that contain 4
program logic)
5
 Structure Chart characteristics

• Structure chart is based on the idea of modular

programming (and top-down programming)
– Breaking a complex problem down into smaller
modules
– Modules are well formed with high internal
cohesiveness and minimum data coupling
– Vertical lines connecting the modules indicate calling
structure
– Little arrows next to the lines show the data passed
between modules (inputs and outputs)
• Data couples: individual items that are passed between
modules
• Program call: the transfer of control from a module to a
subordinate module to perform a requested service (can be
implemented as e.g. a function or procedure call) 6
 Structure Chart Symbols

• Rectangles represent modules

– Can represent a function (e.g. C), a procedure (e.g. Pascal), a
paragraph (e.g. COBOL) , subroutine (e.g. FORTRAN) etc.
– Rectangle with double bars represents a module used several
places (optional)
• Little arrows with open circles represent data couples
• Little arrows with closed circles represent control couple
flag (e.g. end of file flag)
• Curved arrows immediately below a boss module
represents iteration (looping)
• Darkened diamond represents a conditional call to lower
modules
7
8
9
 Notes on Structure Chart

• Each module should do a very specific function

• Module at top of the tree is the boss module
– Function is to call modules on level below, pass
information to them
• Middle level modules control the modules below
– Call them and pass data
• At the very bottom, the leaves contain the actual
algorithms to carry out the program functions
• Call of modules is left to right across the tree

10
 Developing a Structure Chart

• Transaction analysis
– The development of a structure chart based on a DFD
that describes the processing for several types of
transactions
– Uses as input the system flow chart and the event table
to develop the top level of the tree in a structure chart
• Transform analysis
– The development of a structure chart based on a DFD
that describes the input-process-output data flow
– Used to develop the subtrees in a structure chart – one
for each event in the program
11
 Transaction Analysis
• First step is to identify the major programs
– Can do it by looking at the system flow chart and
identifying the major programs
• For a subsystem or program we want to make a
structure chart for, we can look at the DFD Level
0 to identify the major processes
– See next slide, shows event-partitioned DFD for the
order-entry subsystem for RMO example, showing 5
major processes
– These major processes will become the modules in the
resulting high level structure chart (see slide after that)
• Sub-System DFD is also a good source
12
13
14
 Transform Analysis

• Based on the idea that computer program

“transforms” input data into output data
• Structure charts developed with transform analysis
usually have 3 main subtrees
– Input subtree to get data
– A calculate subtree to perform logic
– An output subtree to write the results
• Can create it rearranging elements from
– DFD fragment for an event (e.g. “create new order”)
– The detailed DFD for that event
• E.g. see next two slides for “create new order”
DFD fragment, and its corresponding detailed 15
DFD
16
17
Steps for creating the structure chart from the DFD

1. Identify the primary information flow

2. Find the process that represents the most
fundamental change from an input stream to an
output stream – the central transform
• Afferent data flow: the incoming data flow in a
sequential set of process bubbles
• Efferent data flow: the outgoing data flow from a
sequential set of process bubbles
• Central transform: the central processing bubbles in a
transform analysis type of data flow

18
 Steps continued

In our example, the record (build) order process is the

central process

3.Redraw the data flow diagram (DFD) with

– The inputs to the left
– The central transform process in the middle
– The outputs to the right
– The parent process (top level – e.g. “Create new order”)
above the central transform process (e.g. “Build order”)
– See next slide
19
Record
Order

20
 Steps continued

4. Generate the first-draft structure chart including

data couples (directly from our rearranged DFD
on the previous slide)

• See next slide

21
Record
Order

22
 Steps continued

5. Add other modules as necessary to

– Get input data via the user-interface screens
– Read and write to the data stores
– Write output data or reports

• These are lower level modules (utility modules)

• Also add data couples
• See next slide

23
Record
Order

24
 Final Steps

6. Using structured English or decision table

documentation, add any other required
intermediate relationships (e.g. looping and
decision symbols)
7. Make the final refinements to the structure chart
based on quality control concepts (to be discussed)

25
 Combining the top-level structure chart with
the chart developed by transaction analysis
• Basically “glue” the diagram we made (high-level)
using transaction analysis on top of the more
detailed diagram (for lower-processing) we just
made using transform analysis
• See next slide

26
27
 Evaluating the Quality of a Structure Chart

• Module coupling
– The manner in which modules relate to each other
• Desirable to have loosely coupled modules
– have modules as independent as possible
– Module does not need to know who invoked it
– Best coupling is through simple data coupling
• The module is called and a specific set of data items is passed
• Module function performs its function and returns the output

28
 Evaluating Structure Charts (continued)
• Cohesion
– Refers to the degree to which all of the code within a
module contributes to implementing one well-defined
task
• Desirable to have modules with high cohesion
implementing a single function
– Modules that implement a single task tend to have
relatively low coupling because all of their internal
code acts on the same data item(s)
– Modules with poor cohesion tend to have high coupling
because loosely related tasks are typically performed on
different data items across modules
– A flag passed down the structure chart is an indicator
of poor cohesion
29
30
 Designing the Application Architecture:
The Object-Oriented Approach
• Object-oriented design models provide the bridge
between the object-oriented analysis models and
the object-oriented programs
• Object-oriented programs
– Basic concept: the program consists of a set of
program objects that cooperate to accomplish a result
– Objects work together by sending messages
– Example: in a graphical user interface (GUI) windows
and menus are objects. If you click on a window object
a message is sent to display itself (e.g. window, a menu
bar etc.)
31
 Differences between object oriented and
traditional approaches
• In traditional computer environments there is
some sort of central control
– E.g. a mainframe computer may be connected to
thousands of terminals and controls them centrally
– No terminal does work unless directed to by the
mainframe
• In object-oriented environment
– Analogy to a network of nodes, where each node can
send messages to another independently, but all still
work together, not centrally controlled (no one may be
in charge)
32
 Overview

• Programmers use models to code the system

• Two most important models are design class
diagrams and interaction diagrams (sequence
diagrams and collaboration diagrams)
• Class diagrams are developed for domain, view,
and data access layers
• Interaction diagrams extend system sequence
diagrams

33
 Object-Oriented Design – The Bridge
Between Analysis and Programming
• Bridge between user’s requirements and new system’s
programming
• Object-oriented design is the process by which detailed
object-oriented models are built
• Programmers use the design to write code and test new
system
• User-interface, network, controls, security, and
database requires design tasks and models

34
 Overview of Object-Oriented Programs

• Set of objects that cooperate to accomplish result

• Object contains program logic and necessary
attributes in a single unit
• Objects send each other messages and collaborate
to support functions of main program
• OO system designer provides detail for
programmers
– Design class diagrams, interaction diagrams, (some)
statechart diagrams

35
Simplified Design Class for
Student Class

36
 Object-Oriented Design
Processes and Models
• Diagrams developed during analysis
– Use case diagrams, use case descriptions and activity
diagrams, domain model class diagrams, and system
sequence diagrams
• Diagrams developed during design
– Design class diagrams – set of object-oriented classes
needed for programming, navigation between classes,
attribute names and properties and method names and
properties
– Interaction diagrams, package diagrams
37
Design Models with Their
Respective Input Models

38
 Iterative Process of OO Design
• Create preliminary design class diagrams model
• Develop interaction diagrams for each use case or
scenario (realization of use cases)
• Return to design class diagram
– Develop method names based on the design of
interaction diagrams
– Update navigation visibility and attributes
• Partition design class diagram into related
functions using package diagrams (subsystems or
layers)

39
 Design Class Symbols
• UML does not distinguish between design class
notation and domain model notation

• Domain modeling shows users’ work environment

• Design class specifically defines software classes

• UML uses stereotype notation to categorize a

model element by its characteristics

40
Standard Stereotypes Found
in Design Models

41
 Standard Design Classes
• Entity – design identifier for problem domain class
– Persistent class – exists after system is shut down
• Boundary – designed to live on system’s
automation boundary
– User interface and windows classes
• Control – mediates between boundary and entity
classes, between the view layer and domain layer
• Data access – retrieve from and send data to
database

42
 Design Class Notation
• Name – class name and stereotype information
• Attributes – visibility (private or public), attribute
name, type-expression, initial-value, property
• Method signature – information needed to invoke
(or call) the method
– Method visibility, method name, type-expression
(return parameter), method parameter list (incoming
arguments)
– Overloaded method – method with same name but
two or more different parameter lists

43
Internal Symbols Used to
Define a Design Class

44
Student Class Examples for the
Domain Diagram and the Design
Class Diagram

45
 Some Fundamental Design
Principles
• Encapsulation – each object is a self-contained unit
that includes data and methods that access data
• Object reuse – designers often reuse same classes
for windows components
• Information hiding – data associated with object is
not visible to outside world
• Navigation visibility – object is able to view and
interact with another object

46
Navigation Visibility Between
Customer and Order

47
 Coupling and Cohesion
• Coupling – qualitative measure of how closely
classes in a design class diagram are linked
– Number of navigation arrows on design class
diagram
– Low: system is easier to understand and maintain
• Cohesion – qualitative measure of consistency
of functions within a single class
– Separation of responsibility – divide low cohesive
class into several highly cohesive classes

48
 Developing the First-Cut
Design Class Diagram
• Extend domain model class diagram:
– Elaborate attributes with type and initial value
information
– Add navigation visibility arrows
• Detailed design proceeds, use case by use case:
– Interaction diagrams implement navigation
– Navigation arrows are updated to be consistent
– Method signatures are added to each class
49
RMO Domain Model Class Diagram

50
First-cut RMO Design Class Diagram

51
Interaction Diagrams – Realizing
Use Case and Defining Methods
“Use Case Realization”
• Realization of use case done through
interaction diagram development

• Determine what objects collaborate by sending

messages to each other to carry out use case

• Sequence diagrams and collaboration diagrams

represent results of design decision

52
Partial Design Class Diagram for the Look Up Item
Availability Use Case

53
 Use Case Controller
• System sequence diagram (SSD) shows input
messages from external actors within use
case
• Only indicates that messages go to system
• Use case controller classes are designed as
collection point for incoming messages
• Use case controller acts as intermediary
between outside world and internal system

54
 Designing with Sequence
Diagrams
• Sequence diagrams used to explain object
interactions and document design decisions
• Documents inputs to and outputs from system
for single use case or scenario
• Captures interactions between system and
external world as represented by actors
• Inputs are messages from actor to system
• Outputs are return messages showing data
55
 First-Cut Sequence Diagram
• Start with elements from SSD
• Replace :System object with use case controller
• Add other objects to be included in use case
– Select input message from the use case
– Add all objects that must collaborate
• Determine other messages to be sent
– Which object is source and destination of each
message?

56
 SSD for Cancel an Order

Figure 12-4 57
 First Cut
Design
Class
Diagram
for Cancel
an Order

Figure 12-5 58
 Potential Objects for Cancel an
Order

Figure 12-6 59
 First Cut Sequence Diagram
for Cancel an Order

Figure 12-7 60
Guidelines for Sequence Diagram
Development for Use Case
“Use Case Realization”
• Take each input message and determine
internal messages that result from that input
– For that message, determine its objective
– Needed information, class destination, class source,
and objects created as a result
– Double check for all required classes
• Flesh out components for each message
– Iteration, guard-condition, passed parameters, return
values 61
 SSD for Create new phone order

Figure 12-8 62
 First cut
DCD for
Create
new phone
order

Figure 12-9 63
 Sequence Diagram for First Input
Message

Figure 12-10 64
 Sequence Diagram for First and Second Input
Messages

Figure 12-10 65
 Complete
Sequence
Diagram

Figure 12-11 66
 Package Diagrams – Structuring
the Major Components
• High-level diagram in UML to associate classes
of related groups
• Identifies major components of a system and
dependencies
• Determines final program partitions for each layer
– View, domain, data access
• Can divide system into subsystem and show
nesting within packages

67
Partial Design of a Three-Layer Package
Diagram for RMO

68
RMO Subsystem Packages

69