Basic Computer System Design

System Design II: Behavior Models

Muhammad Tariq Mahmood

tariq@koreatech.ac.kr
School of Computer Science and Engineering

At Sony, we assume all products of our competitors will have basically the same technology, price, performance, and features. Design is the one thing that
differentiates one product from another in the marketplace (--Norio Ohgo, Chairman and CEO, Sony)

Note: These notes are prepared from the following resources.

I (main text) Design for Electrical and Computer Engineers by Ralph Ford, Chris Coulston (McGraw-Hill Education 2008)
I Wiegers, Karl, and Joy Beatty. Software requirements. 3rd Edition, Pearson Education, 2013.
I Kendall, Kenneth E., and Julie E. Kendall. Systems analysis and design. Pearson Education, 2019 10Ed.
I https : //www .uml − diagrams.org/
I https : //www .uml.org/

1 / 25
 Contents

I Be familiar with the following modeling tools for

1 Models describing system behavior: state diagrams,
2 State diagrams flowcharts, data flow diagrams, entity relationship
3 Flowcharts diagrams, and the Unified Modeling Language.
4 Data Flow Diagrams I Understand the intention and expressive power of
the different models.
5 Entity Relationship Diagrams
I Understand the domains in which the models
apply.
I Be able to conduct analysis and design with the
models.
I Understand what model types to choose for a
Learning Objectives given design problem

2 / 25
 Models
Models
I The top-down design process starts with an abstraction of the system to be built. This initial design is
called an abstraction because it captures the essential characteristics of the system without specifying the
underlying physical realization.

I An abstraction that is expressed in a standardized and accepted language is called a model.

I A model is a standardized representation of a system, process, or object that captures its essential details
without specifying the physical realization.

I A modeling language does not have to be formed from letters and words (often the words are graphical
symbols). A model should meet the following properties
1. Be abstract : This means that the model should be independent of final implementation and that there should be
multiple ways of implementing the design based upon it.

2. Be unambiguous: A model should have a single clear meaning in terms of describing the intended behavior.

3. Allow for innovation: Models should encourage exploration of alternative system implementations and behaviors.

4. Be standardized: Standardization provides a common language that can be understood by all. Designers should
be wary of developing their own models that are ill-defined and not commonly understood.

3 / 25
 Models (cont...)
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.

7. Remove unnecessary details and emphasize 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.

8. Break the overall problem into sub-problems: Most problems are too complex to be handled directly and must be
decomposed into subsystems. This produces the design hierarchy.

9. Substitute a sequence of actions by a single action: This allows understanding of the overall larger behavior,
which can then be examined at other levels. This supports the ability to break a design into sub-problems.

10. Assist in verification: A model should aid in demonstrating that the design meets the engineering requirements.

11. Assist in validation: Validation 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.

I In order to meet these properties, most models have an object type, which is capable of encapsulating the
actual components used to construct the target system.

I In order to capture the dependence of objects on one another, models typically have a relationship type.
4 / 25
 Models (cont...)

Types of Design Models

5 / 25
Models (cont...)

6 / 25
Models (cont...)

7 / 25
 State diagrams
State diagrams
I State diagrams describe the behavior of systems with memory. A system with memory is able to modify its
response to inputs based on the state of the system.
I The state of a system represents the net effect of all previous inputs to the system. The state characterizes
the history of previous inputs, it is often synonymous with the word memory.
I A state corresponds to an operating mode of a system, and inputs are associated with transitions between
states.

I A state diagram is a drawing that consists of states to a destination state.

and transition arcs, as shown in Figure
I Each state is represented as a rectangle with rounded
edges with the name of the state written inside.
I There are special circle symbols for both initial and
final states.
Figure 1: Symbols used in state diagrams
I Transitions are drawn as arrows from a source state

8 / 25
 State diagrams (cont...)
I Consider a vending machine that accepts nickels and
dimes and dispenses a piece of candy when 25 cents
has been deposited.
I This vending machine can be modeled by a state
diagram because the response of the machine to a
coin depends on how much money has been
deposited so far.
I The initialization/reset state is labeled $0.00, while
the action of the machine (dispense or not dispense
candy) is associated with the states
I The only state that dispenses candy is $0.25.

I There are three types of transitions shown in this

state diagram
Figure 2: A state diagram for a simple vending machine

9 / 25
 State diagrams (cont...)
I More Examples

10 / 25
 Flowcharts

Flowcharts
I The intention of a flowchart is to visually describe a process or algorithm, including its steps and control.
I Flowcharts are often scoffed at as being old-fashioned and overly simple
I Since flowcharts have been around for a long time, they are easily recognized and understood.
I The names of the starting and ending steps of a flowchart are represented by ovals known as terminators.
I Individual processing steps are written inside rectangles, while a process step that is elaborated by another
flowchart is drawn as a rectangle with double sides.
I Elaborated processes allow the representation of hierarchy in the design.
I Certain points in a flowchart can lead to alternative destinations as represented by a decision or conditional
symbol (diamond).
I The condition that determines the next step is written inside the diamond and the possible values of the
condition are written on the arcs leaving the conditional step.

11 / 25
 Flowcharts (cont...)
I Basic flowchart symbols

12 / 25
Flowcharts (cont...)

13 / 25
Flowcharts (cont...)

14 / 25
Flowcharts (cont...)

15 / 25
 Flowcharts (cont...)
I Consider an embedded computer system that monitors the light level of its environment as described by the
flowchart in Figure

Figure 3: A flowchart for an embedded system

I The algorithmic process of the flowchart is easy and intuitive to understand. The system reads the current
light value, stores it into an array, and then computes an average.
16 / 25
 Flowcharts (cont...)

I Flowcharts are an intuitive way to describe algorithmic processes. Limiting the complexity of a flowchart to
between 10 and 20 steps enables the sequence of actions to be quickly comprehended while eliminating
unnecessary details.
I Flowcharts are not able to represent the structure of data being manipulated and they are not particularly
good at representing concurrent processes.

17 / 25
 Data Flow Diagrams

Data Flow Diagrams

I The intention of a data flow diagram (DFD) is to model the processing and flow of data inside a system. It
is a function-oriented approach that is similar to functional decomposition

I The processes inside a DFD accept data inputs, transform them in some way, and produce output data.

I A DFD is often used for the analysis of information systems due to its data emphasis, but can be broadly
applied to electrical and computer systems.

I It differs from functional decomposition in that functional decomposition is often closer to the
implementation of the design, whereas the DFD models the system from a data point of view.

I A DFD is fundamentally different from a flowchart in that it does not encapsulate control and sequencing
information, but allows multiple processes fuming concurrently.

18 / 25
 Data Flow Diagrams (cont...)

I There are four symbols, shown in Figure

Figure 4: Data flow diagram symbols

1. Processes : A rectangle with rounded corners that describes a useful task or function. They perform a
transformation on the data.
2. Data flows: An arrow representing a data relationship between two processes.
3. Data stores: An open rectangle representing a data repository.
4. Interfaces: A square describing external agents or entities that use the system. They are also referred to as
sources and sinks.

19 / 25
 Data Flow Diagrams (cont...)

I DFD Process
1. Like the general design process, DFDs are successively refined from the top down.
2. That is, there is a single top level (or Level 0) DFD describing the entire system and the interfaces and data
stores that it interacts with.
3. The rules for constructing a DFD are fairly intuitive. A process must have at least one input and one output.
4. The refinement of a process at level N must have the same inputs and outputs as the process at level N 1.
5. Data must be transformed in some way by a process. This process of refinement continues until a satisfactory
level of detail is reached.

I Example:Video Browsing System Video databases are typically very large; because of their size, it is usually
cumbersome to preview videos and extract important information. A solution to this problem is to apply
image analysis techniques to identify shots (continuous scenes without a break) in a video and store both
the location of the shot boundaries in the video and key frames that summarize each shot. The collection of
key frames is known as a storyboard. The storyboards are stored in an annotation database that is much
smaller in size than the original video database. Typically the user of a video browsing system has the ability
to preview the storyboard and select shots from it to view.

20 / 25
 Data Flow Diagrams (cont...)
I DFD Video Browsing System

• Videos in the database are processed to extract shot

boundaries and key frames, which are stored in the
annotation database.

• The user can submit requests to view a storyboard,

which is retrieved from the annotation database.

• When a shot is selected from the storyboard, the user

can preview the original shot, which is retrieved from
the video database.

• Specific information on the data flows is defined in a

formal language known as a data dictionary

Figure 5: Data flow diagram symbols

21 / 25
 Data Flow Diagrams (cont...)
• There can be concurrent processes represented in a DFD. In the video browsing example, multiple people can
use the system simultaneously, and there is no implied sequencing between when the shot boundary detection
process is run and the storyboards are previewed.
• This information is listed in something known as an event table.

I Types of Events 5. Associated with each event is a trigger, the cause of

the event. Each event has a process that is
1. An event is an occurrence at a specific time and associated with it.
place that needs to be remembered. Events can be
classified into temporal, external, and state. 6. Associated with each event is a source, the entity
responsible for triggering it.
2. A temporal event is one that happens because the
system has reached some critical time.
3. An external event occurs outside the system
boundary by a system user, in this case requesting
either a storyboard or a video preview.
4. A state event is the result of something changing
within the system Figure 6: Event table for the video browsing system

22 / 25
 Entity Relationship Diagrams
Entity Relationship Diagrams
I A database is a system that stores and retrieves data, and it is modeled by an entity relationship diagram
(ERD).

I The intention of an ERD is to catalog a set of related objects (entities), their attributes, and the
relationships between them.

I The entities and their relationships are real, distinct things that have characteristics that need to be
captured.

I The design of a database starts by describing the entities, their attributes, and the relationship between
entities in an ERD.
I The three elements used in the ERD modeling language are:
1. Entities : They are generally in the form of tangible objects, roles played, organizational units, devices, and
locations. An instance is the manifestation of a particular entity. For example, an entity could be Student while
an instance would be Kristen.
2. Relationships: They are descriptors for the relationships between entities.
3. Attributes: They are features that are used to differentiate between instances of the entities.

23 / 25
 Entity Relationship Diagrams (cont...)

I Example: An ERD describing academic scheduling at a college

• store data about three entities: Students, Courses, and Departments.
• The process of building an ERD starts by determining the relationships between entities. (entity relationship
matrix )
• Relationships are bidirectional because they have two participating entities.

Figure 7: Event table for the video browsing system

24 / 25
 Entity Relationship Diagrams (cont...)
I The relationships are identified by the
diamond-shaped symbols; the entities are denoted by
the rectangles with their name at the top.

I The cardinality ratio is labeled on the links between

the relationships and entities. Another piece of
information shown in the ERD is the attributes
associated with each entity.

I An attribute is a feature or characteristic of an

entity that needs to be remembered.

I There are many different types of attributes;

however, the most important are key attributes

Figure 8: ERD for the college database system

I The ERD allows for an easy interpretation of the relationships between entities as well as their attributes.

25 / 25