HIGH LEVEL DESIGN DOCUMENT TEMPLATE

COVER PAGE

Table of Contents

1. ARCHITECTURE..............................................ERROR: REFERENCE SOURCE NOT FOUND

(you can include your artchitecture/context-diagram here)

2. REFERENCE DOCUMENTS...........................ERROR: REFERENCE SOURCE NOT FOUND

2.1. SRS..................................................................ERROR: REFERENCE SOURCE NOT FOUND
2.2. REUSABLE SOFTWARE.............................ERROR: REFERENCE SOURCE NOT FOUND
3. DATA FLOW DIAGRAMS................................ERROR: REFERENCE SOURCE NOT FOUND
(Give your dfds- (include input, processing, output, and class diagram here)
3.1. USER INTERFACE ......................................ERROR: REFERENCE SOURCE NOT FOUND
(Subheadings, CDE & DEF shows you have a 2nd level DFD ( not mandatory to have as it
depends upon your design, and details you want to provide))
3.1.1. CDE ................................................................ERROR: REFERENCE SOURCE NOT FOUND
3.1.2. DEF..................................................................ERROR: REFERENCE SOURCE NOT FOUND
3.2. COMPUTATION...........................................ERROR: REFERENCE SOURCE NOT FOUND
3.2.1. PARSING........................................................ERROR: REFERENCE SOURCE NOT FOUND
3.2.2. TRAVERSING................................................ERROR: REFERENCE SOURCE NOT FOUND
3.2.3. WPQ................................................................ERROR: REFERENCE SOURCE NOT FOUND
(and so on… you need not write the word "class", I wrote so that you can
understand.)

4. CLASS DIAGRAMS..........................................ERROR: REFERENCE SOURCE NOT FOUND

(Give your class diagram here)

4.1. USER INTERFACE PROCESSING............ERROR: REFERENCE SOURCE NOT FOUND

4.1.1. INPUT PROCESSING CLASS....................ERROR: REFERENCE SOURCE NOT FOUND
4.1.2. OUTPUT PROCESSING CLASS................ERROR: REFERENCE SOURCE NOT FOUND
3.2. COMPUTATION...........................................ERROR: REFERENCE SOURCE NOT FOUND
4.2.1. PARSING........................................................ERROR: REFERENCE SOURCE NOT FOUND
4.2.1.1. TOKENIZER CLASS....................................ERROR: REFERENCE SOURCE NOT FOUND

Rajika Tandon, Dept. of EECS, Syracuse University, NY 1

4.2.1.2. AST CLASS....................................................ERROR: REFERENCE SOURCE NOT FOUND
4.3. TRAVERSING................................................ERROR: REFERENCE SOURCE NOT FOUND
(and so on… you need not write the word "class", I wrote so that you can
understand.)

5. DATABASE DESIGN....................................ERROR: REFERENCE SOURCE NOT FOUND

(those requiring database in their projects)
( refer to Appendix B for details on what is required in this section)

6. DEVELOPMENT..........................................ERROR: REFERENCE SOURCE NOT FOUND

7. MISCELLANEA............................................ERROR: REFERENCE SOURCE NOT FOUND
8. DATA DICTIONARY....................................ERROR: REFERENCE SOURCE NOT FOUND
9. NOTES............................................................ERROR: REFERENCE SOURCE NOT FOUND
GLOSSARY..................................................................ERROR: REFERENCE SOURCE NOT FOUND
APPENDIX...................................................................................................................................................20

List of Figures

1. CONTEXT DIAGRAM......................................ERROR: REFERENCE SOURCE NOT FOUND

…………
…………

IMPORTANT:

* “Notes” section contains revisions and any additional comments that did not fit anywhere else
in the document. This section is required esp. when writing the newer versions of HLD, since
you might change/add something to the 1st draft HLD.

* You are not required to include the Data Dictionary (e.g. on pg. 13) in your first draft, but you
must include this in your final HLDs. Data Dictionary summarizes all the information flowing
into and out of the various processes shown in your DFDs.

* “Miscellanea” is optional for 1st draft HLD, but mandatory for final HLD.

* If you have doubts about what expected diagrams are, or how to explain them in your HLDs:
– Refer to the example given later in this document for understanding of DFDs
– Refer to the “Software_Design.ppt” (in the study material folder) for understanding of the
class diagrams

[The Data flow diagrams have been moved to the High level design document.
Actually there are two types of specifications in the industrial software projects – A
and B level. As per the Professor’s concern, since you are making SRS (more of the
A-level specification), you should not include DFDs in the SRS, since they tend to

Rajika Tandon, Dept. of EECS, Syracuse University, NY 2

sometimes give more of implementation details in B-spec. But these have been
moved to the HLD. So please check the revised grading sheets.]

Rajika Tandon, Dept. of EECS, Syracuse University, NY 3

 FOR YOUR UNDERSTANDING:
6. Development
A common technique is to manually prepare a data file that will be used as
the input to some module until the UI is mature enough to supply real data.

The design should describe the necessary resources - number of developers,

their required skills, the hardware, environment and development tools
required for the development process. It should also say when and for how
long each resource would be needed. This is the place to include
development time estimates.

(Miscellanea is optional for 1 st draft HLD, but mandatory for final

HLD)
7. Miscellanea
7.1 Conformance with standards
If you are following any standards, then this section must contain the lists of
both the standards the system should conform to and the references as to
where these standards may be obtained.

For e.g.: One team mentioned that the licensing is under GNU/GPL. Another
team is following Apple standards, etc.

7.2 Interoperability with other systems

Must contain the list of the external systems that the new system should
interact with in addition to a description of the way in which it should do so.
For e.g.: Few teams mentioned that their product will be compatible with
many Operating Systems/Network providers/Web browsers, etc.

7.3 Expandability
If applicable, this section should explain how a third party would be able to
extend the system. This may be done by writing plug-ins or scripts, or by
writing some instructions in a configuration file, though you are not at all
required to write such plug-ins etc.

For e.g.: One team mentioned that their product will be compatible with
Microsoft Outlook, etc.

Rajika Tandon, Dept. of EECS, Syracuse University, NY 4

7.4 Security
Most software systems today face one or more security threats: spoofing,
identity theft, password stealing, eavesdropping, sniffing, spamming, data
theft, web site defacing, denial of service attacks, password breaking, fraud,
forgery, hacking, viruses, worms, trojans - just to name a few.

This section should describe the security threats you foresee and intend to
deal with. It should specify your assumptions regarding the environment
(whether the computer is behind a firewall, who has physical access to it,
etc.) and the means you plan to employ in order to protect the system
(authentication, data encryption, input validation, internal sanity checks),
etc.

For e.g.: One team mentioned that they are going to use an authentication
key to make sure that only signed users can access the system.

7.5 Open Issues

There are always some issues left open. Sometimes information needed for
making certain design decisions is not available in time or even at all.
Sometimes decisions are delayed for a more convenient time. This section
should list all the open issues in the design, and, if possible, point out what is
required in order to resolve each one.

For e.g.: One team is still not sure about what the complexity of their system
would be. They want to test the performance of the system and
feasibility of implementing the proposed system.

Glossary
List all the technical terms, concepts and acronyms that appear in the
document or that are relevant to it, for the sake of the uninformed reader.
The explanation of each term/concept/acronym should not exceed 4 lines.
People will thank you for not having to spend hours on looking up unfamiliar
terminology.

9. Notes

Revisions:
3.1.1.1 original
……… (like xyz was there in SRS draft 1, provide section
numbering as well)

3.1.1.2.2 revised
…….... (now you modified xyz to wxy, provide section numbering
as well)
Rajika Tandon, Dept. of EECS, Syracuse University, NY 5
 Or in original you can up with a concept ‘X’. Now you dropped the
idea of doing so. Report that and possibly explain why you
dropped that.
Similar is the case for adding some requirements.

Rajika Tandon, Dept. of EECS, Syracuse University, NY 6

CONTEXT DIAGRAMS
A context diagram shows how the processing, you’ll carry out, interacts with its environment.
- Each rectangle represents some source of information used by your program or
some sink of information provided by your program. Your program does not provide
these sources and sinks.
- The central oval represents all the processing you are obligated to develop.
- Each line represents information required for your processing to succeed (inputs) or
information your processing will generate (outputs).
The information flows shown on the context diagram must match exactly the inputs and
outputs on your top level Data Flow Diagram (DFD), described next.
(For example of a context diagram, refer to fig. 1)

DATA FLOW DIAGRAM DIAGRAMS

 A data flow diagram represents processing requirements of a program and the
information flows necessary to sustain them.
– All processing represented by the context diagram is decomposed into a set of a
few (perhaps three or four) process bubbles which are labeled and numbered.
– The information necessary to sustain each process and generated by each process
are shown as input and output data flows.
– Inputs from the environment and outputs to the environment are shown exactly as
they appear in the context diagram.
– When the inputs and outputs exactly match the context diagram we say that the
data flow diagram is balanced.
– If each of the processes represents approximately the same amount of
requirements detail we say that the diagram is properly leveled.

• Data Flow Diagrams (DFDs) are used during the analysis of requirements for complex
systems. Each bubble represents a specific process which has been allocated tasks and
requirements, so that all of the program’s obligations are partitioned among the processes
shown on the top level DFD.
• Each data flow represents information necessary to sustain a process or generated by a
process.
• Note that Data Flow Diagrams are not officially part of the UML.

Rajika Tandon, Dept. of EECS, Syracuse University, NY 7

 A general data flow diagram

(The above material - context and data flow diagrams are taken from Dr. Fawcett’s notes
posted on his web,
http://www.ecs.syr.edu/faculty/fawcett/handouts/webpages/FawcettHome.htm)

Rajika Tandon, Dept. of EECS, Syracuse University, NY 8

EXAMPLE:

Small Calculator
(SC)
version 1.0
15 October, 2009
Rajika Tandon

NOTE:
This document is incomplete; it only gives architecture and data
flow diagrams. Don’t get confused by the numbering I have used.
These start from 1 just for the ease of understanding. However,
you should follow include it before class diagrams. Also note that
the processes defined below are just to give you an idea of DFDs.
They might not be detailed or complete.

1. Architecture
The SC program accepts input as text which is then parsed and computed.
The result of computation is then displayed to the user.

The project follows a two-layered architecture, described as follows:

(i) Presentation Layer: provides a user interface which is responsible for

accepting the input and displaying the output.

(ii) Business Layer: forms the processing unit of the project. This layer is
responsible for parsing the input text and executing all the operations
involved in the input. The operations can be:
 scalar-scalar addition,
 scalar-scalar multiplication,
 matrix-matrix addition,

Rajika Tandon, Dept. of EECS, Syracuse University, NY 9

  matrix-matrix multiplication, and
 printing of variables involved

The input text needs to be based on the grammar specified in the

Architectural Concept Document.

Figure 1: SC Context Diagram (0 Level DFD)

Parsing involves syntactic analysis of the input text, where input’s

grammatical structure is determined by the formal grammar specified. This
grammar shall be written in extended Bacus-Naur Form (BNF) which
is a formal way of describing structured text. Thus, the input text is checked
for a valid syntax, and is then represented by a tree structure, known as
“abstract syntax tree”. (Refer to Appendix A and B for the understanding of
extended-BNF representation of the grammar required for the SC project.)

Processing performed by SC program is divided into the following major

components:
 providing formal grammar to support variables and constants, as well
as, matrix multiplication and addition, and, scalar multiplication and
addition. This involves support for matrix or scalar variables’ input and
printing.
 validating the input as per the grammar.
 execution of the matrix operations involved in the input, in parallel.
 storing the computed values of the variables in a data structure, and
displaying the same to the user.

2. Reference Documents (You will also mention your First Draft

here)

2.1. Customer A-Specification

Customer A level Specification Version 1.0, Monday, 21 Sept.
2009

Rajika Tandon, Dept. of EECS, Syracuse University, NY 10

 2.2 Architectural Concept Document
Architectural Concept Document Version 1.0, Tuesday, 29 Sept.,
2009

2.3 Reusable Software

ANTLR – ver. 3, September 20, 2009

3. Data Flow Diagrams

Processing for the SC program is divided into two major processes:
- user interface (UI), which takes commands and code from the user in the
form of input text, and displays the output, and
- computing, processes the code received from the user and give back
results and errors encountered if any, back to the UI.

Each of these processes is responsible for a set of requirements, described in

this section.

Figure 2 - Data Flow Diagram 1

Rajika Tandon, Dept. of EECS, Syracuse University, NY 11

 3.1. Processes
This section describes the activities required of the SC program.

3.1.1. User Interface

The user interface is responsible for accepting the input from the user and returning the output.

3.1.1.1. inputs
 The clicked commands can be one of the following: start a new
code analysis or run code command.
 Input text will contain (one or a combination of):
scalar, matrix, scalar-scalar addition/multiplication expression,

matrix-matrix addition/ multiplication expression, and print

statements.

3.1.1.2. processing
The parsing process shall include an editable multi-line text area for
storage of code use and a read-only multi-line text a the output
text.

The user interface shall also allow the user to submit a command to
begin execution, that when issued, begins the interpretation of the
code in the editable multi-line text area.

Also, the user interface shall allow a command to initiate a new

calculation session, which will clear all the inputs/outputs shown
currently being shown to the user.

3.1.1.3. outputs
 The code message contains the SC code that needs to be
interpreted.
 The output text message contains the error messages and
results to be displayed to the user.

3.1.2. Computing
The computing process is responsible for the actual processing of the
code. It generates an abstract syntax tree after parsing the input code,
which is then traversed and executed together. This process deals

Rajika Tandon, Dept. of EECS, Syracuse University, NY 12

 differently with the scalar and matrix operations. The same is shown in
the fig. 2.

Rajika Tandon, Dept. of EECS, Syracuse University, NY 13

 Figure 6 - Data Flow Diagram 2 - for Computing Process

3.1.2.1. Parsing
The code received from the UI is analyzed syntactically. An AST
(abstract syntax tree) is generated and is sent for further
processing. If there are errors in the syntax, an error is reported.

3.1.2.1.1. inputs
 The code message contains the SC code to be interpreted in
the syntax documented in Appendix A.

3.1.2.1.2. processing
The parsing process shall create an abstract syntax tree based
on the code message supplied. If the code message is not in the
format documented in Appendix A, the process shall emit an
error message.

3.1.2.1.3. outputs
The abstract syntax tree message contains the code in the
form of a tree. (An example is provided in Appendix B.)

3.1.2.2. Traversing
Traversing process will visit the nodes of the abstract syntax tree
and simultaneously interpret the operations need to be carried out.
It will identify the operations, scalar or matrix, and send the data it
extracted from the tree, to the scalar and matrix computation
processes.

3.1.2.2.1. inputs
 Abstract syntax tree will be the input to the traversing
process.

3.1.2.2.2. processing

Rajika Tandon, Dept. of EECS, Syracuse University, NY 14

 3.1.2.2.3. outputs
3.1.2.3. Scalar Computation
3.1.2.3.1. inputs
3.1.2.3.2. processing
3.1.2.3.3. outputs

3.1.2.4. Matrix Computation

3.1.2.4.1. inputs
3.1.2.4.2. processing
3.1.2.4.3. outputs

3.1.2.5. Integrating Results

3.1.2.5.1. inputs
3.1.2.5.2. processing
3.1.2.5.3. outputs

4.Data Dictionary
Message Name Interpretation DFD
input text contains the input given by the user DFD1
files produced by the external process "Antlr3 Program" based on
lexer and parser files the grammar file DFD1

errors (process 2) message describing syntax/semantic/program execution error DFD1

computed values of the input variables issued by a print
results command DFD1
errors (process 2.1) message describing syntax DFD1
scalar data scalar variables/values/operation/expression given as input DFD2
Rajika Tandon,
matrix data Dept. of EECS, Syracuse University, NY
matrix variables/values/operation/expression given as input DFD2 15
 Figure 8 - Data Dictionary

(This data dictionary is incomplete, it reports all the inputs to and

outputs from every process on all the DFDs, excluding redundancies.
Refer to glossary for exact definition of DD).

You are not required to include the DD in your first draft, but you must
include this in your final HLDs.
APPENDIX A - Examples of BNF
Grammar written in extended BNF, to be used in the SC project, is as follows:

A1. SCALAR

Examples
a = 2;
a = 2 + 3;
a = 2 + 3 * 4 + 6;
a = 4 * 6;
a = 2 + 4 * 6 + 18 * 7 + … (any no. of ‘+’ or ‘*’ operations)

scalar declaration/assignment
scalar=NUM;

scalar operation (addition/multiplication)

scalar=expr;

where,

ALPHA : (‘a’..’z’ | ‘A’..’Z’)

DIGIT : (‘0’..’9’)
LDIGIT: (‘1’..’9’)
scalar: (ALPHA+)(DIGIT*)
NUM: (LDIGIT)DIGIT* | ‘0’

op : + | *
expr: scalar | NUM | expr op expr

‘|’ denotes OR

A2. MATRIX

Examples
k[] = [1,2,3,4 / 5,6,7,8 / 9,10,11,12]; (while defining a matrix)
Rajika Tandon, Dept. of EECS, Syracuse University, NY 16
 This matrix will be equivalent to:
k = { {1,2,3,4}, {5,6,7,8}, {9,10,11,12} }
r[] = [90,56,-1,34 ];
This matrix will be equivalent to:
r = { {90}, {56}, {-1}, {34} }
c = k * r;
c = r + k;
c = r * k + r + k;
c = r + k ……………… (any no. of ‘+’ or ‘*’ operations)

matrix declaration/assignment
matname=matrix;

matrix addition/multiplication
matname=expression;

where,

matname: scalar[]
ALPHA : (‘a’..’z’ | ‘A’..’Z’)
DIGIT : (‘0’..’9’)
LDIGIT: (‘1’..’9’)
scalar: (ALPHA+)(DIGIT*)
NUM: (LDIGIT)DIGIT* | ‘0’

op : + | *
expression: matname | expression op expression

matcomma :
matcomma : ,
row: NUM | row matcomma NUM / row
matrix: [row]

‘|’ denotes OR

Rajika Tandon, Dept. of EECS, Syracuse University, NY 17

APPENDIX B - Examples of AST

B1. SCALAR

Example of the Abstract Syntax Tree for the following scalar expression:

a = 4 * 6;

Figure B1 - Abstract Syntax Tree for scalar operation

Example of the Abstract Syntax Tree for the following matrix expression:

Rajika Tandon, Dept. of EECS, Syracuse University, NY 18

 matrix: c = k + r;

Figure B2 - Abstract Syntax Tree for matrix operations

Rajika Tandon, Dept. of EECS, Syracuse University, NY 19

GLOSSARY

ANTLR : ANother Tool for Language Recognition, is a language tool

that provides a framework for constructing recognizers,
interpreters, compilers, and translators from grammatical
descriptions containing actions in a variety of target
language.

AST : Abstract Syntax Tree is a tree representation of the abstract

(simplified) syntactic structure of source code written in a
certain programming language.

BNF : Bacus-Naur Form, a formal grammar for expressing context-

free grammars. It is a formal way of describing structured
text.

Lexer : Programs performing lexical analysis, process of converting a

sequence of characters into a sequence of tokens, are called
lexical analyzers or lexers.

Parser : Programs that perform parsing, or, more formally, syntactic

analysis which is the process of analyzing a text, made of a
sequence of tokens (for example, words), to determine its
grammatical structure with respect to a given (more or less)
formal grammar.

SC : Small Calculator

DD : Data Dictionary - provides a quick reference of every input

and output on every DFD.

Rajika Tandon, Dept. of EECS, Syracuse University, NY 20

APPENDIX B

The database might not only contain tables, but also sequences, abstract data types, etc. These are known
as objects in database. Hence, you need to provide the object type, purpose and data fields inside the
object. For example:

Chunk of Entity-Relationship Diagram depicting city and state entities with a

relationship that a state can have many cities.

4.1 State
………………
..…………….

4.2 City
Object Type: Table
Name: City
Primary Key: cityID
Foreign key: cityStateAbbr
Related Tables: State
Purpose & Description: This table stores the city information
associated with a city id. It is created to contain city name and state
name (for which it is linked to state table). The cityID is uniquely
identifies each row/tuple inserted into the city table. This table
provides information about the city to which an employee or a
customer belongs to.

Rajika Tandon, Dept. of EECS, Syracuse University, NY 21

 Table contents:
cityID INTEGER Not Null Primary key,
cityName Varchar(50) Not Null,
cityStateAbbr Char(2) Not Null DEFAULT 'NY' Foreign Key
VERSION, DURING ACTUAL IMPLEMENTATION TIME NEXT
SEMESTER (Not in your HLD)

 Object Type: Table

Name: City
Created by: Rajika Tandon
Date: 02-29-2009
Primary Key: cityID
Foreign key: cityStateAbbr
Related Tables: State
Modified by/date: NA
Purpose & Description: Purpose & Description: This table stores the
city information associated with a city id. It is created to contain city name
and state name (for which it is linked to state table). The cityID is uniquely
identifies each row/tuple inserted into the city table. This table provides
information about the city to which an employee or a customer belongs to.
Script:
/* For storing the city information */
CREATE TABLE City
(
cityID INTEGER NOT NULL,
cityName VARCHAR(50) NOT NULL,
cityStateAbbr CHAR(2) NOT NULL,
CONSTRAINT cityPK PRIMARY KEY(cityID),
CONSTRAINT cityStateFK FOREIGN KEY(cityStateAbbr) REFERENCES
State(stateAbbr)
);

 Object Type: Sequence

Name: City_Seq
Created by: Rajika Tandon

Rajika Tandon, Dept. of EECS, Syracuse University, NY 22

 Date: 02-29-2009
Related Tables: City
Modified by/date: NA
Purpose & Description: This sequence is used to generate the city id,
starting from 1, as and when a new city is added. This sequence
automatically increments by 1 and gets stored in the cityID field, when a
new tuple is inserted into the city table.
Script:
/* To generate cityID */
CREATE SEQUENCE City_Seq
START WITH 1
INCREMENT BY 1;

Screenshots:

Rajika Tandon, Dept. of EECS, Syracuse University, NY 23

 Object Type: Table
Name: State
Created By: Rajika Tandon
Date: 02-29-2009
Primary Key: stateAbbr
Modified by/date: NA
Purpose & Description: This table stores the state information (50 states
of USA). The stateAbbr can be referenced to when the state info is
necessary. For atomic items, this table is created. The stateAbbrID is used
to store state name to which an employee or a customer belongs to.
Script:
/* For storing the state information */
CREATE TABLE State
(
stateAbbr CHAR(2) NOT NULL,
stateName VARCHAR(50) NOT NULL,
CONSTRAINT statePK PRIMARY KEY(stateAbbr)
);

/* StateAbbr can have only the following values */

ALTER TABLE State ADD CONSTRAINT stateCheck
CHECK (stateAbbr IN

Rajika Tandon, Dept. of EECS, Syracuse University, NY 24

 ('AL', 'AK', 'AZ', 'AR', 'CA', 'CO', 'CT', 'DE', 'DC', 'FL', 'GA', 'HI', 'ID', 'IL', 'IN',
'IA', 'KS', 'KY', 'LA', 'ME', 'MD', 'MA', 'MI', 'MN', 'MS', 'MO', 'MT', 'NE', 'NV',
'NH', 'NJ', 'NM', 'NY', 'NC', 'ND', 'OH', 'OK', 'OR', 'PA', 'RI', 'SC', 'SD', 'TN', 'TX',
'UT', 'VT', 'VA', 'WA', 'WV', 'WI', 'WY')
);

Screenshots:

Rajika Tandon, Dept. of EECS, Syracuse University, NY 25

Rajika Tandon, Dept. of EECS, Syracuse University, NY 26
Rajika Tandon, Dept. of EECS, Syracuse University, NY 27