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. DevelopmentA 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 1st draft HLD, but mandatory for final HLD)7. Miscellanea 7.1 Conformance with standardsIf 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 systemsMust 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 ExpandabilityIf 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 SecurityMost 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 IssuesThere 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.

GlossaryList 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 DIAGRAMSA 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.015 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.ArchitectureThe 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 DiagramsProcessing 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.ProcessesThis section describes the activities required of the SC program.

3.1.1.User InterfaceThe 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. processingThe 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.ComputingThe 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 differently with the scalar and matrix operations. The same is shown in the fig. 2.

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

Figure 6 - Data Flow Diagram 2 - for Computing Process

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

3.1.2.1. ParsingThe 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. processingThe 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. outputsThe abstract syntax tree message contains the code in the form of a tree. (An example is provided in Appendix B.)

3.1.2.2. TraversingTraversing 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. outputs3.1.2.3. Scalar Computation

3.1.2.3.1. inputs3.1.2.3.2. processing3.1.2.3.3. outputs

3.1.2.4. Matrix Computation3.1.2.4.1. inputs3.1.2.4.2. processing3.1.2.4.3. outputs

3.1.2.5. Integrating Results3.1.2.5.1. inputs3.1.2.5.2. processing3.1.2.5.3. outputs

4.Data Dictionary

Rajika Tandon, Dept. of EECS, Syracuse University, NY 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 BNFGrammar 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 / rowmatrix: [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: NAPurpose & 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_SeqSTART WITH 1INCREMENT 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: NAPurpose & 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