<Product Name> - Rel #.#.#.

#
Software Design Document

aricent.com

ARICENT: Revision Number:

Copyright 2009 Aricent Inc. All Rights Reserved. No part of this document may be reproduced, stored in a retrieval system or transmitted, in any form, or by any means, electronic or otherwise, including photocopying, reprinting, or recording, for any purpose, without the express written permission of Aricent. Printed in ________ TRADEMARKS ARICENT and THE ARICENT LOGO are trademarks of Aricent Inc. in the U.S. and other countries. The use of any of these trademarks without Aricent prior written consent is strictly prohibited. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Aricent Inc. disclaims any proprietary interest in the trademarks and trade names other than its own. DISCLAIMER The information in this book is provided as is, with no warranties whatsoever, including any warranty of merchantability, fitness for any particular purpose or any warranty otherwise arising out of any proposal, specification or sample. This document is provided for informational purposes only and should not be construed as a commitment on the part of Aricent. Information in this document is subject to change without notice. REQUESTS For information or obtaining permission for use of material of this work, please submit a written request to: Corporate Marketing and Legal, Aricent on www.aricent.com DOCUMENT No.: ARICENT:

REVISION HISTORY
Revision No. Date Description of Change Author Reviewed & Approved By

Contents
CHAPTER 1:

1. INTRODUCTION ______________________________________________ 7
1.1 1.2 1.3 1.3.1 1.3.2 1.4 1.5 1.6 1.7 1.8 PURPOSE ......................................................................................................7 SCOPE ..........................................................................................................7 DEFINITIONS AND ACRONYMS .........................................................................7 Definitions .................................................................................................7 Acronyms .................................................................................................8 REFERENCES ................................................................................................8 DOCUMENT ORGANISATION............................................................................8 TYPOGRAPHICAL CONVENTIONS (OPTIONAL) ..................................................8 APPROVALS AND AUTHORIZATIONS.................................................................8 DISTRIBUTION................................................................................................9

CHAPTER 2:

2. HIGH LEVEL DESIGN

________________________________________ 11 2.1 LEVEL 0 DESIGN DESCRIPTION .....................................................................11 2.1.1 Interface Description ..............................................................................11 2.2 LEVEL X DESIGN DESCRIPTION .....................................................................12 2.2.1 Module name (level x 1) .......................................................................12 2.2.1.1 Decomposition Description ----------------------------------------------------- 12 2.2.1.1.1 Module Description ------------------------------------------------------------ 13 2.2.1.1.2 Process Description ----------------------------------------------------------- 15 2.2.1.2 Interface Description ------------------------------------------------------------- 15 2.2.1.2.1 Process Interface -------------------------------------------------------------- 15 2.2.1.3 Dependency Description -------------------------------------------------------- 15 2.2.2 Module 2 (level x-1) ................................................................................15 2.3 LEVEL (X+1) DESIGN DESCRIPTION ..............................................................15 2.4 CONTROL FLOW SCENARIO ..........................................................................15 ________________________________________ 17 ALTERNATE DESIGNS...................................................................................17 DESIGN EVALUATION REPORT ......................................................................17 DESIGN LIMITATIONS ...................................................................................17

CHAPTER 3:

3. ALTERNATE DESIGN
3.1 3.2 3.3

CHAPTER 4:

4. DETAILED DESIGN __________________________________________ 19

4.1 MODULE 1 ...................................................................................................19 4.1.1 Detailed Data Design .............................................................................19 4.1.1.1 Data Structure ABC -------------------------------------------------------------- 19 4.1.1.2 Total Data Size -------------------------------------------------------------------- 20 4.1.2 Detailed Module design ..........................................................................21 4.2 MODULE 2 ...................................................................................................22 4.2.1 Detailed Data Design .............................................................................22 4.2.2 Detailed Module Design .........................................................................22

CHAPTER 5:

5. SYSTEM ISSUES ____________________________________________ 23

5.1 5.2 5.3 5.4 PERFORMANCE ...........................................................................................23 SCALABILITY................................................................................................23 SYSTEM SIZING............................................................................................23 LOGGING.....................................................................................................23

CHAPTER 6:

6. SYSTEM MANAGEMENT DESIGN CONSIDERATIONS _____________ 25

6.1 MIB DESIGN................................................................................................25
1

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

<PRODUCT NAME> - REL #.#.#.#

6.1.1 Standard MIB .........................................................................................25 6.1.2 Proprietary MIB ......................................................................................25 6.2 CONFIGURATION AND CONTROL ....................................................................26 6.2.1 Overview ................................................................................................26 6.2.2 Start-up ...................................................................................................26 6.2.3 Shutdown ...............................................................................................26 6.2.4 Creation of < Table name > New Entries ...............................................26 6.2.5 Deletion of < Table name > Entries .......................................................26 6.3 ERROR HANDLING .......................................................................................26 6.3.1 System Errors.........................................................................................26 6.3.2 Interface Errors.......................................................................................26 6.3.3 Protocol Errors .......................................................................................26 6.4 RESOURCE REQUIREMENTS .........................................................................27 YOUR OPINION MATTERS__________ ERROR! BOOKMARK NOT DEFINED. REVISION HISTORY ____________________________________________ 29

ARICENT: ARICENT CONFIDENTIAL

Figures

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

Tables

Table 1-1: Definitions Used in this Document ............................................................................................... 7 Table 1-2: Acronyms Used in this Document ................................................................................................ 8 Table 1-3: Approvals and Authorizations ...................................................................................................... 8 Table 1-4: Distribution.................................................................................................................................... 9 Table 4-1: Field Description Table ............................................................................................................... 20 Table 4-2: Total Data Size ........................................................................................................................... 20

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

Chapter

1
1.Introduction 1.1 Purpose
Specify the purpose of the software and the document Specify the intended audience.

1.2 Scope
Identify the software by name. Explain what the software product(s) will and will not do (either directly or by reference to another software document). Describe the application of the product (either directly or by reference to another software document).

1.3 Definitions and Acronyms

Provide the definitions of all terms, acronyms and abbreviations required to properly understand the SDD. List them in the alphabetical order. Sample given below.

1.3.1 Definitions
Table 1-1: Definitions Used in this Document

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

<PRODUCT NAME> - REL #.#.#.#

<IP> <ISO>

OSI ISIS for IP and Dual Environments, RFC 1195, Dec 1990. Intermediate System to Intermediate system Intra-Domain Routing Information Exchange Protocol, ISO/IEC 10589:1992 (E)

1.3.2 Acronyms
Table 1-2: Acronyms Used in this Document
Acronym ATM ISDN PSTN SS7 Explanation Asynchronous Transfer Mode Integrated Services Digital Network Public Switched Telephone Network CCSS7 Common Channel Switching System 7

1.4 References
List all the documents referenced elsewhere in the document

1.5 Document Organisation

Explain how the Software Design Document is organized. Specify the purpose of each section.

1.6 Typographical Conventions (Optional)

Specify any conventions used in the document.

1.7 Approvals and Authorizations

Table 1-3: Approvals and Authorizations

ARICENT: ARICENT CONFIDENTIAL

CHAPTER 1: INTRODUCTION

Designation Approved by Authorized by Quality Co-ordinator Engineering Manager

Name <Name> <Name>

Date <dd/mm/yyyy> <dd/mm/yyyy>

1.8 Distribution
Table 1-4: Distribution
Copy No. 1 2 3 4 Holders Designation Engineering Manager Project Co-ordinator Quality Co-ordinator Team members Issue Date <dd/mm/yyyy> <dd/mm/yyyy> <dd/mm/yyyy> <dd/mm/yyyy>

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

Chapter

2
2.High Level Design 2.1 Level 0 Design Description

2.1.1 Interface Description

User Client Interface TFTP server Client interacts with the TFTP server through the client interface. Client generates the request to read\write a file. Server processes the client request(update\retrive file), then generates an appropriate response for the client.

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

11

<PRODUCT NAME> - REL #.#.#.#

2.2 Level 1 Design Description

2.2.1 Module name (level 0)

Client interface

2.2.1.1

Decomposition Description

12

ARICENT: ARICENT CONFIDENTIAL

CHAPTER 2: HIGH LEVEL DESIGN

Client interface forwards the user request in a format that can be processed by the server. Client interface receives the servers response.

2.2.1.1.1 Module Description

Client Interface User sends a request to read from a file(download data).The client interface receives the request and generates a read request packet(RRQ). Server in response sends the data(DATA n) of the file. The client interface on receiving the data further sends acknowledgment(ACK n) corresponding to the data block received. This continues until the server is done reading the file. (Should we write the case where ack is not received(error cases)??) (Should I include the frame formation by client interface??or should that be in low level??) Data Description In our case, the data elements will be same for both level 1 and level 2 DFD.Because the frame sent by the client interface will be forwarded(without any changes) to the tftp request handler..

1. 2. 3. 4. 5.

RRQ WRQ DATA ACK ERROR

(Read Request)/ WRQ(Write request) :

This message type is used to read/write data from/to the server once a connection is established between the server and a client. The format of these messages is given below.
-----------------------------------------------| Opcode | Filename | 0 | Mode | 0 | ------------------------------------------------

The opcode field(2 bytes) differentiates between a RRQ and a WRQ in that it is 1 for RRQ and 2 for WRQ. Filename is a variable sized string which is the name of the file. Mode defines the transfer mode used by TFTP. In general there are two types of modes i)
SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

(for an ASCII file)

13

<PRODUCT NAME> - REL #.#.#.#

ii)

octet (for binary file)

DATA message :

It is used by either of the client or server to send blocks of data.

---------------------------------| Opcode | Block # | Data | ----------------------------------

Its 2 byte opcode field has a value 3. The Block number(2 bytes) is used for sequencing purpose. The data block must be 512 bytes for all DATA messages except the last block which indicates the end of file.

ACK message :

In a communication process knowing the stats of the no of data blocks received correctly is important, which can be done by giving an ACKnowledgment to the server by the client process. It is in whole 4 bytes long. It has 2 bytes for opcode whose value is 4 for ACK message. It also has 2 bytes for Block number which tells the number of blocks received. If in case the ACK is after a WRQ(sent by server to indicate that it is ready for data retrieval from client) then the block no is 0.

ERROR Message :

When a faulty communication occurs that is the connection is not formed or the filename specified does not exist, then the program needs to declare about the problem. This is done by giving an ERROR message by either the client or server. It can be considered as a negative ACK. ----------------------------------------| Opcode | ErrorCode | ErrMsg | 0 | -----------------------------------------

The opcode value is 5 in this case. The errorcode fields define the type of error which stores an integer value between 0 -4 , each integer having a particular error message associated to it.

14

ARICENT: ARICENT CONFIDENTIAL

CHAPTER 2: HIGH LEVEL DESIGN

2.2.1.1.2 Process Description

Server can support multiple users simultaneously. Here we are creating new process to serve each user individually.

2.2.1.2

Interface Description
Should I copy paste the data description as it is??

2.2.1.2.1 Process Interface

Again repetition of process description??

2.2.1.3

Dependency Description
The Dependency Description is represented by Structure Charts, which are used in design to show how software is decomposed into modules. Derive the Structure Charts from DFD of this level. This will capture the dependency information.

2.2.2 Module 2 (level x-1)

This is the module identified in the previous level x-1, if this undergoes further decompositions. All the subsections mentioned above, if applicable.

2.3 Level (x+1) Design Description

If any modules identified (as the result of decomposition) above further level decompositions. This level will be applicable (All the subsections mentioned above, if applicable).

2.4 Control Flow Scenario

Add the control flow from the earlier dfd doc(vishu).

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

15

Chapter

3
3.Alternate Design 3.1 Alternate Designs
<Document the alternate design approaches with Scope, Requirements, Advantages, and Disadvantages for each alternative and conclusion >

3.2 Design Evaluation Report

Following are the contents of the formal evaluation report Identification of Alternatives Criteria for identifying alternatives Expected Functionality and Key constraints List of alternatives Evaluation Criteria Priority to categories and individual criteria Evaluation method Evaluation results (Plug Matrix, any other methodology specified comparison)

Final Recommendation and any potential risk with the selection

3.3 Design Limitations

<List any design limitations>
SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL 17

<PRODUCT NAME> - REL #.#.#.#

18

ARICENT: ARICENT CONFIDENTIAL

Chapter

4
4.Detailed Design
Describe the detailed design in terms of pseudocode & PDL Give the detailed design information for data and modules identified in above sections List down the modules identified after Level 1 DFD

4.1 Module 1
4.1.1 Detailed Data Design
List down all the data elements in that module like constants & its values, data structures, its description of fields, and size of fields, global variables and their sizes, and also macros. As a summary also list down a table that indicates the memory requirement of the application. This table should contain the name of the Data, its size in bytes, the number of instances that will be used by the application. Two sample tables one for individual data structure and the other for the total memory requirement are illustrated below:

4.1.1.1

Data Structure ABC

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

19

<PRODUCT NAME> - REL #.#.#.#

Table 4-1: Field Description Table

Field Name IP address Field Description The destination network IP address. IP address is stored as 4 byte integral value. The return value of library call inet_aton() is stored in this field. If required please specify if the data is represented in little or big endian format. Upper 32 bits of the next hop MAC address Lower 16 bits of the next hop MAC address Something Padding bytes Size (bytes) 4

MAC address High MAC address Low XYZ PAD

4 4 2 2

4.1.1.2

Total Data Size

Table 4-2: Total Data Size

Data Name DataStruct xyz1 DataStruct xyz2 GlobalVar gvar1 GlobalVar gvar2 StaticVar svar1 Dynamic Memory Requirement DataStruct dynDS1 DataStruct dynDS2 GRAND TOTAL

Size (bytes) 64 4 100 2 4

# of instances 1 10 1 5 1

Total Size (bytes) 64 40 100 10 4

Static Memory Requirement

8 24

200* 15

1600 360 2178

* The maximum number of instances that will be allocated at runtime

20

ARICENT: ARICENT CONFIDENTIAL

CHAPTER 4: DETAILED DESIGN

4.1.2 Detailed Module design

The detailed module design is described in module description. The module description contains prototype, purpose, prerequisites, description, inputs, outputs, returns, list of called by modules & called modules and also processing of the module is defined by pseudocode.

<NOTE: Standardized tables are available in this template. Please go to Insert Autotext/ 1. Body text for Column table, field description table or function table which use body text style 2. Code for data structure table, which uses the code style for text.

The template for the module/function description:

Prototype

<Function prototype>

Purpose/ Description Prerequisites Input(s)

<Purpose of the module> <Processing of the module> <Pre-requisites applicable to this module or this module is called in-sequence with other modules (This is applicable, if required)> <Input parameters passed to this module. If required specify whether the input is little or big endian in format> < If the function takes buffer/memory block as one of the arguments and frees the buffer/memory block, mention the cases when the buffer/memory block will be freed. [Ex: This function frees pBuf in SUCCESS is returned. The buffer is not freed when FAILURE is returned.]>

Output(s)

<Output parameters produced by this module. If required specify whether the input is little or big endian in format >

Return Value(s) Called By Calls

<Return values of this module. If required specify whether the input is little or big endian in format > <List of modules calling this module> This will be used to calculate stack buildup. <List of Modules called by, this module>

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

21

<PRODUCT NAME> - REL #.#.#.#

4.2 Module 2
4.2.1 Detailed Data Design 4.2.2 Detailed Module Design

22

ARICENT: ARICENT CONFIDENTIAL

Chapter

5
5.System Issues 5.1 Performance
If applicable, mention the level of performance as per this design.

5.2 Scalability
If applicable, mention the level of scalability.

5.3 System sizing

If applicable, mention the system-sizing parameters.

5.4 Logging
Introduce design information on logging.

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

23

Chapter

6
6.System Management Design Considerations 6.1 MIB Design
6.1.1 Standard MIB
Mention the level of conformance ie., whether all scalar variables and tables in standard MIB are supported. Note: it is not required to mention the complete MIB.

6.1.2 Proprietary MIB

Mention the description of the new MIB. Note: there is no need to mention the complete MIB.

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

25

<PRODUCT NAME> - REL #.#.#.#

6.2 Configuration and control

6.2.1 Overview
Aricent XXX is designed to be fully configurable and....

6.2.2 Start-up
Describes the steps associated with bringing up a protocol

6.2.3 Shutdown
Describes the steps associated with bringing down a protocol...

6.2.4 Creation of < Table name > New Entries

Steps involved in creating table entries and its effects (necessary for crucial tables only like iftable etc.) The title of this section can change as appropriate.

6.2.5 Deletion of < Table name > Entries

The template for the module/function description: Effect of deleting a table entry. The title of this section can change as appropriate.

6.3 Error Handling

6.3.1 System Errors
Describes how errors like memory allocation failure, task spawn failures are handled.

6.3.2 Interface Errors

Describes the error codes that will be generated to external entities.

6.3.3 Protocol Errors

26

ARICENT: ARICENT CONFIDENTIAL

CHAPTER 6: SYSTEM MANAGEMENT DESIGN CONSIDERATIONS

Describes how situations, which are not addressed in the specs, are handled (this may not be applicable to all protocols).

6.4 Resource Requirements1

In this section memory requirement & other OS resources (queues, semaphores) required should be specified.

Note: (For products division, these details are given in a separate document on request by customer. But during product design, this section must be filled. In the documents that will be sent to customer, these can be moved to another document).
SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL 27

Revision History
Rev 2.0 Date of Issue 18-Sep-07 Author Anjana Gangadharan Approver QG/SEPG Scope Supersedes FS DP081

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

29