 There are two parts of system design: the first one has been

studied in chapter 5 which is “Functional Decomposition”. It is

also called “System Structure”.
 Now in this chapter, you will study the second part of system
design. The second part of system design is called “Behavior
Modeling”. It is also called “System Behavior”.
 In other words, functional decomposition or functional modeling
allows the designer to describe the structure of complete system
in terms of its components.
 On the other hand, the behavioral model allows the designer to
describe how different components of the system will work.
 System Design = System Structure + System
Behavior
Your report (final year project or any other report) unless you have a
dedicated chapter with the name System Design which must include structure
as well as behavior

2
 In functional decomposition (chapter 5), we
were dealing with inputs, outputs, and some
transformation between them.

 But now in order to describe the behavior of

a system, the designer must understand the
following representations or notations.

 In other words, there are different ways to

represent the behavior of your system.

3
 In a digital system, the circuit diagram shows the structure of
the system.

 Now, if the digital system is a combinational one, then you can

represent the behavior with the help of TRUTH TABLE.

 Similarly, if the digital system is sequential, then you can

represent the behavior with a FINITE STATE MACHINE.

 Summary: For any system or project, you MUST describe the

structure (functional decomposition) model and behavior
model

 You have already studied the structural model in chapter 5.

 Now you will study the behavior model in this course.

4
 Human body is a system.

 If you will make a block diagram which shows different

components, then it is called system structure. Different
components in human body are eyes, ears, head, hands etc.

 You may have multiple structure diagrams for different

components. For example, structure diagram for ear, structure
diagram for eyes etc.

 Now, you have to provide a representation for each structure

diagram which is called behavior.

 Summary: system design is not completed

without structure and behavior

5
By the end of this chapter, you should:
 Have a familiarity (understanding) with the following
modeling tools for describing ECE (electrical and computer
engineering) system behavior:
 (1) state diagrams, (2) flowcharts, (3) data flow diagrams, (4) entity
relationship diagrams, and the (5) Unified Modeling Language.
 A modeling tool is the one which is used to describe the
behavior of a system or component.
 ----------------------------------------------
 Understand the intention (purpose) and expressive power
of different aforementioned models.
 Understand the domains in which the models apply.
 Be able to conduct analysis and design with the models.
 Understand what model types to choose for a given design
problem.

6
Models - what do you think of?

7
 An abstraction (simple representation) that is expressed in a standardized and
accepted language is called a model.
 It means if you want to show the model of your system, you have to show it in
a standard tool or language.
 In ECE, the standard tools or languages to represent the models are: MATLAB,
Verilog, C language,
◦ (1) state diagrams, (2) flowcharts, (3) data flow diagrams, (4) entity
relationship diagrams, and the (5) Unified Modeling Language.
 In other words, a model is a standardized
representation of a system, process, component or
object that captures its important details
(functionalities) without specifying the physical
realization.
 Engineers always model the system before actually making it.

8
 From the definition on the previous page,
you can say that:
◦ A model is always represented in a standard
language or tool so that all the other persons can
understand your model
◦ A model can be made for a complete system, or
for a particular part of the system
◦ A model only contains the important details about
the functionality
◦ A model does not provide any implementation
detail.

Copyright 2005 9
A good model should be:
(1) abstract
◦ The model should be independent of final
implementation
◦ There should be multiple ways of
implementing the design based upon it.
◦ It means that from one model, you can choose
many implementations.
◦ It means that for one model, there are several
possible implementations.

10
 (2) Be unambiguous (very much clear):

◦ A model should have a single meaning in terms of describing

the intended (required) behaviour.
◦ It means implementations can be different, but the actual
behavior is very clear and does not have any doubt.

 (3) Allow for innovation (something new):

◦ Models should encourage exploration of alternative system

implementations and behaviours.
◦ Just like a simple program in any language ( C or Java)… it
means a program is also a behavior model.
◦ You perform programming so that you can explore different
options… in other words I just play with my program and get
more and more insight about the behavior.
◦ You can say that programming is modeling, and different
languages are the programming (modeling) tools.

11
 (4) Be standardized:
◦ It provides a common language that can be
understood by all.

 (5) Provide a means for communication:

◦ A model should facilitate communication within the
design team and with nontechnical stakeholders.

 (6) Be modifiable:
◦ A model should make design modifications relatively
easy. So that’s why it is recommended that
whenever you start implementation, its better to
make a model first.

12
 Remove unnecessary details & show important features:
◦ The intent is to simplify the design for ease of understanding.
◦ The most highly detailed information is typically identified in the
detailed design.
 Break system into sub-problems:
◦ This produces the design hierarchy.
 Substitute sequence of actions by a single action:
◦ This supports the ability to break a design into subproblems.
 Assist in verification:
◦ A model should aid in demonstrating that the design meets the
engineering requirements .
 Assist in validation:
◦ It is the process of demonstrating that the needs of the user are being
met and the right system is being designed .
◦ The model should facilitate discussion with all stakeholders to ensure it
meets everyone's expectations.

13
 If the output of your system is just
depending on the inputs, u just need a
simple truth table. On the left hand side, u
right your inputs and on the left hand side u
just write the outputs.
 But if the output of your system depends on

the input PLUS the internal state of the

system, u can NOT use a simple truth
table… In this case u need to use a state
diagram or finite state machine.

14
 Difference between design and
implementation
 Job of engineer: design or implementation ?

◦ Design
 Modeling is: design or implementation ???
◦ Design

15
16
 As an example, consider a vending machine
that accepts nickels and dimes and dispenses a
piece of candy when 25 cents has been
deposited. This machine can be modelled by a
state diagram because the response of the
machine to a coin depends on how much
money has been deposited so far.
◦ Module: Vending Machine Control Unit
◦ Inputs:
 Nickel: Signals that a nickel has been deposited.
 Dime: Signals that a dime has been deposited.
 Outputs
 Reset: Signals the FSM to return to the initial/reset state.
 Vend: Signal to dispense candy.

17
 Initial/Reset:
$0.00

nickel

$0.05 dime

nickel

dime $0.10

nickel

$0.15 dime

nickel

dime $0.20

nickel dime

>=$0.25

18
Copyright 2005 19
20
 The intention (purpose) of a flowchart is to
visually describe a process or algorithm,
including its steps and control.

General Elaborated
Terminator Decision
Process Process

General Displayed
Stored Data Direct Data
Data Data

21
 Compute
Sample Store sample Display yes
light Key-
Start light value in Wait 1ms average End
sample press?
strength array value
average

no

 Can you figure out the operation of the

system by looking at this?
 That is why the flowchart is elegant and
not so lowly.

22
Requirements (loosely)
 Must roam randomly around facility
 Detect intruders by recognizing sound
 Set-off an alarm if detects noise, transmit
position, and wait.
 Must regularly conduct a self-test to determine if
it is working properly.
Design Details
 Has the three ultrasonic sensors and can
measure distance to objects to the left, forward,
and right.
 Has a microphone that it uses to monitor sounds.

Problem: Develop a Flow Chart of its operation

23
Intention is ??? To model the processing and
flow of data inside a system.
How it is different from other behavior
models (representations)
 DFDs can have levels, just like the

functional

Process Data Flow Data Store Interface

24
 It differs from functional decomposition is
that that functional decomposition is often
closer to implementation of the design,
whereas DFD models the system from a
data point of view.
 It differs from flow chart in that it does not

encapsulate control and sequencing

information.

Copyright 2005 25
 Video User
Database

Shot
Shot Browse
Storyboard Shot Preview
Video Boundary Request
Request
Detection

Storyboard
Key
Boundaries Preview
Frames

Annotation Boundaries
Database Key
Frames

Video Shot Preview

26
 Event Trigger Process Source

Annotate New Video Shot System

Video Arrival Boundary

Detection
View Browse Storyboard User
Storybo Request Preview
ard
View Shot Shot Shot User
Preview Preview
Request

27
 Intention of an ERD is

 Entities =

 Relationships =

 Attributes =

28
29
 Student Course Department

Student

Course

Departme
nt

Copyright 2005 30
 Student
SSN
Name M takes /
Date of birth has
Age
GPA
Major M
M
M
Course
Number
majors in/ Department requires /
enrolls Credits is prereq
Instructor M
1 M Available Seats

Department
Name 1 offers /
Chair offered by
#of students

31
 For object-oriented software design.
 Value in applying it to ECE Systems.
 Has 6 different views of systems
(unified!).
 Only an overview is provided here.

32