DDS Template

8/22/2019 DDS Template

1/27

Detailed Design Specification

2006, 2010, 2012 Actian Corporation

Project NameClick here to enter name

Author Click here and enter name(s)

Last Saved Date June 4, 2012

Revision

Template Revision 2.0

162090111.doc


2/27

Responsibility List

Note: The Responsibility List reflects those required to review and provide feedback

for the document. Signoff by those listed is required prior to the beginning of the

development phase.

Additional reviewers

162090111.doc

Page2 of 27

Assigned To Action Responsibility Signature

Owner Engineer/Architect

Peer Review Development Manager

Chris Rogers

Jonathan Rosen

Peer Review QA Manager

Test Review QA Engineer

Alex Hanshaw Peer Review Sustaining Engineering Manager

Sustainability Review Sustaining Engineering

Engineer

Pam Fowler Peer Review Level 1 Support Manager

Ahmed Ezzat Peer Review Chief Architect

Elaine Grieco

Lee Howard

Peer Review Technical Writer

Peer Review Services

Peer Review Services


3/27

Note: The additional reviewers list reflects other people that should be copied on the

document and invited to review meetings, but feedback from them is not required for

the document to be approved. Managers of other engineering groups are copied for

comment on how it affects their product or product area. The manager for your own

engineering area is included in first table and can be removed from here.

SQL Language Review

162090111.doc

Page3 of 27


Karl Schendel Information DBMS

Teresa King Information Gateways

Teresa King Information Connectivity

Joe Kronk Information OpenROAD

Roger Whitcomb Information Tools

Emma McGrattan InformationUsability


4/27

Note: The SQL language review table lists people that should be sent an initial draft

copy of this document if you answered yes to any questions in section 2.2. If you did

not answer yes to any of those questions you may delete this table.

162090111.doc

Page4 of 27


Ian Kirkham Language Review DBMS

Teresa King Language Review Gateways

Teresa King Language Review Connectivity

Joe Kronk Language Review OpenROAD

Alex Hanshaw Language Review Supportability and

Backward

Compatibility


5/27

Change History:

Revision Date Last Revision By Description of Change

30-Nov-2007 Steve Ball Template: Fixed up instructions to be more Ingres

product range specific and added sections specific to

Ingres/OpenROAD

3-Dec-2007 Steve Ball Template: Add tech writing changes and examples

section

4-Dec-2007 Steve Ball Template: changes based on feedback

1-May-08 Christine Normile Template: changes based on working meeting Punta

Cana, DR, Development Summit 2008

22-May-08 Christine Normile Template: removed confidential markings

21-Aug-2008 Steve Ball Template: Add language review elements

4-Apr-2009 Steve Ball Template: Added section on catalog changes

13-Aug-2010 Chris Clark Template: Fixed typos, footer now includes file name.

24-May-2012 Chris Clark Template: Company name change, default reviewers

updated

4-Jun-2012 Chris Clark Template: Facility reviewers updated, updated,

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

to change which text is bold. Uploaded to

http://community.actian.com/wiki/Image:DDS-

Template.doc

162090111.doc

Page5 of 27
http://community.actian.com/wiki/Image:DDS-Template.dochttp://community.actian.com/wiki/Image:DDS-Template.dochttp://community.actian.com/wiki/Image:DDS-Template.dochttp://community.actian.com/wiki/Image:DDS-Template.doc


6/27

TABLE OF CONTENTS

1 INTRODUCTION.........................................................................10

1.1 SCOPEANDSUMMARY.................................................................................10

1.2 DEFINITIONS, ACRONYMSAND ABBREVIATIONS................................................10

1.3 REFERENCES.............................................................................................10

1.4 NOTEWORTHY ISSUES.................................................................................10

2 ARCHITECTURE OVERVIEW.........................................................12

2.1 HIGHLEVELDESCRIPTION.............................................................................12

2.2 SQL LANGUAGECHANGES...........................................................................12

2.3 IMPLICATIONSFOR GCA..............................................................................13

2.4 CONNECTIONPARAMETERS...........................................................................13

2.5 LANGUAGE, UNICODEANDINTERNATIONALIZATION ISSUES .................................13

2.6 IMPLICATIONSFORINGRES/STAR....................................................................13

2.7 IMPLICATIONSFORDBATOOLS......................................................................14

2.8 NEWIMA/MIBOBJECTS.................................................................................14

2.9 NEWTRACEPOINTS.....................................................................................14

2.10 CATALOGALTERATIONS.............................................................................14

2.11 IMPLICATIONFOR GATEWAYS......................................................................14

2.12 IMPLICATIONSFORDATABASEDRIVERS..........................................................15

2.13 IMPLICATIONSFOROPENROAD.....................................................................15

2.14 DESIGN LIMITATIONSAND ASSUMPTIONS......................................................15

2.15 PLATFORM SPECIFIC ISSUES.......................................................................15

162090111.doc

Page6 of 27


7/27

2.16 PRODUCTINTERACTION.............................................................................16

2.17 PATENT INFORMATION...............................................................................16

3 EXTERNAL SPECIFICATION.........................................................17

3.1 USERPERSPECTIVE.....................................................................................17

3.2 INSTALLATIONAND ADMINISTRATION PERSPECTIVE............................................17

3.3 MIGRATION ISSUES.....................................................................................17

3.4 SECURITY IMPACT.......................................................................................17

4 INTERNAL SPECIFICATION..........................................................19

4.1 ESTIMATEDTASKSAND EFFORT....................................................................19

4.2 PROGRAMMING..........................................................................................20

4.3 COMPATIBILITYLIBRARYINTERFACECHANGES...................................................20

4.4 INTERFACE ...............................................................................................20

4.5 BUILDIMPLICATIONS....................................................................................21

4.6 UI RESOURCE/PROPERTIES FILES..................................................................21

4.7 BITMAP RESOURCES...................................................................................21

4.8 ICON FILES...............................................................................................22

4.9 PICCOLOCHANGENUMBERS..........................................................................22

5 IMPACT AND DOCUMENTATION SUMMARY..................................23

5.1 PRODUCT/COMPONENT IMPACTS...................................................................23

5.2 DOCUMENTATION.......................................................................................23

6 QUALITY ISSUES........................................................................24

6.1 UNIT TESTING SUMMARY.............................................................................24

162090111.doc

Page7 of 27


8/27

6.2 HANDOFFQAIMPACT....................................................................................24

6.3 TESTING RECOMMENDATIONS.......................................................................24

6.4 REGRESSION RISKASSESSMENT....................................................................24

7 PACKAGING AND INSTALLATION IMPACT.....................................26

8 SUPPORT IMPACT......................................................................27

8.1 EXAMPLESANDTESTS.................................................................................27

162090111.doc

Page8 of 27


9/27

PREFACE

This document describes external functional specifications as well as design

specifications for one feature of a release project. There will be many Detailed

Design Specifications (DDS) for each project, one for each major feature

described in the Software Requirements Specification (SRS) or project wiki page.

The SRS or the wiki page is the master document for the entire project.

This is intended to be a living document. The product development cycle is a

dynamic process in which our understanding of the project and its criteria for

success are refined over time. It is therefore expected that the completed

Detailed Design Specification will undergo many revisions during the course of a

project as requirements; resources and constraints evolve. The engineer would

not be expected to complete all sections in the initial draft; some sections are

designed so that they can only be completed one the project is coded. *note that

you are expected to continue updating this document until the release

project is handed over to SE*

The Development Manager is responsible for the contents of this document.

Deliverables that must be completed prior to releasing this document are at least

one of:

Software Requirements Specification

Wiki page on the engineering web describing the components of the project

All template instructions can be identified by theirgray italic type. This information

may be removed after completing the necessary project information.

Ant information detailed in this document should not be repeated in the wiki page

for this feature unless there is a compelling reason to do otherwise one of the

copies of the information may become out-of-date. If you need to, refer to the

DDS on the wiki page.

162090111.doc

Page9 of 27


10/27

1 INTRODUCTION

1.1 SCOPE AND SUMMARY

Explain what the feature is expected to do; notes on the drivers for this feature

(such as partner or customer requirements) should be placed in here.

Click here to begin typing

1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Provide the definitions of terms, acronyms and abbreviations required to

interpret this document. For consistency, use the format in the examples below:

Detailed Design Specification: (DDS) A representation of a software system or

component of a system created to facilitate analysis, planning, implementation

and decision-making. The DDS is used as the primary medium for

communicating software design information.

Click here to add additional definitions

1.3 REFERENCES

Provide a list of documents referenced elsewhere in this document and/or

other documents that were used during research or may help the reader

understand the feature.

Identify each document by title, report number (if applicable), date and

publishing organization.

If possible, specify the sources from which the references can be obtained

Click here to begin typing.

1.4 NOTEWORTHY ISSUES

Since the DDS is an evolving representation of the design (a "living document"),

this section is used to keep track of issues that arise during the project life cycle

and items that need special attention. If you add a FIX_ME or comment similar

162090111.doc

Page10 of 27


11/27

to need to do something about blah here to the code, you should note theissue here.


162090111.doc

Page11 of 27


12/27

2 ARCHITECTURE OVERVIEW

2.1 HIGH LEVEL DESCRIPTION

Describe the overall architecture. Architectural design may be represented in

many forms, including text, graphical description, pseudo-code representation or

combination.


2.2 SQL LANGUAGE CHANGESAre there any changes in this feature that alter the SQL language in any way?

Did you add syntax to the Ingres SQL language? Did you remove syntax from

the Ingres SQL language? Did you add any new data-types or functions to SQL?

Did you make any other changes that affect the SQL language?

NOTE: If you answered yes to any of the questions above you must send the

initial draft of the DDS for language review to the people designated in the SQL

Language Review table at the start of this document and fill out all of the

following sub-sections. If there are no language changes you may delete all

these sub-sections


2.2.1Language changes to Ingres/Star

Will the language changes be implemented in Ingres/star? If not why not?


2.2.2Language Changes to ABF

Will the language changes be implemented in ABF? If not why not?


2.2.3Language Changes to Database Procedures

Will the language changes be implemented or be functional inside database

procedures? If not why not?

162090111.doc

Page12 of 27


13/27


2.2.4Language Changes to Embedded SQL pre-compilers

Will the language changes be implemented in the embedded SQL Pre-

compilers? If not why not?


2.2.5Effects on dynamic SQL

Will the language changes work in dynamic SQL? If not why not?


2.3 IMPLICATIONS FOR GCA

Is there anything about this feature (including language or data-type changes)

that will require a new GCA message type or have any other affect on GCA?


2.4 CONNECTION PARAMETERS

Does this feature require, use, or add any new DBMS connection parameters?


2.5 LANGUAGE, UNICODE AND INTERNATIONALIZATION ISSUES

Is there anything about this feature that causes it to have unique characteristics

or testing requirements when implemented for the international market and

support for international or multi-byte character sets including Unicode (UTF16 or

UTF8)?


2.6 IMPLICATIONS FOR INGRES/STAR

Does this feature have any implication for Ingres/Star? If so what are they?

162090111.doc

Page13 of 27


14/27


2.7 IMPLICATIONS FOR DBA TOOLS

Does the feature have any implications for the DBA tools such as copydb,

auditdb, rollforwarddb, verifydb? Would a new verifydb option be useful?


2.8 NEW IMA/MIB OBJECTS

Did you add any IMA objects as part of this feature? Are there any that would be

useful that perhaps you didnt add because of lack of time?


2.9 NEW TRACE POINTS

Trace points should be avoided in favor of IMA objects. If you added any trace

points detail them here with an explanation of why it was not suitable for an IMA

object.


2.10 CATALOG ALTERATIONS

Does the feature add or alter the Ingres catalogs, either DBMS catalogs, front-

end catalogs, or iidbdb catalogs? If so, fill in the details here and be sure to

update the document containing the catalog spec, which can be found here:

http://community.ingres.com/wiki/Ingres_Catalogs


2.11 IMPLICATION FOR GATEWAYS

Does this feature have any implications for the Ingres gateways? Do any SQLlanguage changes need to be considered for implementation in gateway

products?


162090111.doc

Page14 of 27
http://community.ingres.com/wiki/Ingres_Catalogshttp://community.ingres.com/wiki/Ingres_Catalogs


15/27

2.12 IMPLICATIONS FOR DATABASE DRIVERS

Does this feature have any implications for any of the database drivers such as

ODBC, JDBC, Python, PHP, Ruby, etc? Do any SQL language changes need to

be considered for implementation in these drivers?


2.13 IMPLICATIONS FOR OPENROAD

Does this feature have any implications for OpenROAD? De sure to mention any

changes to ADF that are necessary to implement this feature, they often impact

OpenROAD. Do any SQL language changes need to be considered for

implementation in OpenROAD


2.14 DESIGN LIMITATIONS AND ASSUMPTIONS

This section should list current limitations and assumptions made in the design.


2.14.1 Dependencies

Does this feature depend on any external functionality (such as an XML parser,

or some other similar piece of code that does not belong to Ingres)? Does this

feature depend on another feature that will be, or has been coded in this release

of the product? Describe the dependency.


2.15 PLATFORM SPECIFIC ISSUES

Is there anything about this feature that causes it to have unique characteristicsor testing requirements when implemented on a specific platform? Are there any

platform limitations to this feature, or is it intended to run only on one platform?

Will the feature need to re-coded for other platforms (e.g. CL additions or re-

architecture)


162090111.doc

Page15 of 27


16/27

2.16 PRODUCT INTERACTION

Does this feature cause any changes in the way that Ingres products interact

with each-other other than already detailed in the above sections? Are there

certain products that will/will no work with this feature (this is more relevant to

tools such as VDBA and new middle-ware servers)?

2.17 PATENT INFORMATION

If there is any technology being developed for this feature that could be

considered for a patent, note the information here.


162090111.doc

Page16 of 27


17/27

3 EXTERNAL SPECIFICATION

3.1 USER PERSPECTIVE

In this section, the focus is on the tasks that a user will perform with this feature.

Describe what the feature does and how it works form a user perspective.

Focus on how it is used to perform the function described in the high level

description.

Provide screen shots if appropriate


3.2 INSTALLATION AND ADMINISTRATION PERSPECTIVE

Include any special installation and setup tasks, system parameters or other

preparations that are necessary prior to use. Describe the steps needed to

setup and get the component going and any ongoing administration that will

need to be performed if relevant. List all configuration parameters that apply to

this feature here.


3.3 MIGRATION ISSUES

Describe any special steps required to migrate from existing versions

Ingres/OpenROAD to this version that arise because of this feature. Does this

feature have any new catalogs or other implications for upgradedb?

Is the component going to be backward compatible?

Can this version co-exist with an older version?


3.4 SECURITY IMPACT

Does anything about the function need securing? Could it do any damage?

Could it cause the display of sensitive information?

Does the implementation methodology do anything that produces a potential

security exposure, such as run as root or Ingres (if this is an application)?

162090111.doc

Page17 of 27


18/27


162090111.doc

Page18 of 27


19/27

4 INTERNAL SPECIFICATION

4.1 ESTIMATED TASKS AND EFFORT

Estimate the engineering effort to code and test the component ready for hand

over to QA and Technical Writing. If it is a large function, break it up into smaller

function points and estimate each one. For large projects, filling out the table

below and should help but is not required. Estimates should be effort to code

complete; that is engineering effort assuming 100% of an engineers time is

used, which will not normally be equal to elapsed time for the project. Estimates

should include time to:

Code the feature and all of the error checking required for the feature

(error checking may be up to 50% of the code in the DBMS)

Test your code and make corrections

Write and post an integration plan (or more than one for large projects)

Run HandoffQA for each proposed submission and check the results

As a guide, an experienced engineer who already knows the code will normally

write and sanity test about 100 lines of code per day; engineers with less

experience or those that are new to the code will write less. Factor about 20% ofthe time it took to code for final testing and fixes. Look at existing modules to

help make an estimate of the number of lines of code required. Tasks should

normally be submitted as they are sane and complete, so the formula might be

something like:

Time for task = (no_of_lines / 100) + 2 days for IP and HandoffQA

Total time = Sum (time for all tasks) + 20% for overall testing and fixes


Task Effort

(person-

days)

Assigned to Done

(yes/no)

Tested

(yes/no)

Description of task

TOTAL Total days - - -

162090111.doc

Page19 of 27


20/27

4.2 PROGRAMMING

List programs and modules written, changed or deleted. Initially this will be a

first pass estimate of what needs to be changed, it will likely change during the

course if the project. The version of this document at code complete will contain

the modules or programs that actually changed.


4.2.1Module 1Provide a short description of what the module does and how it changed if it

was altered.


4.3 COMPATIBILITY LIBRARY INTERFACE CHANGES

Describe any changes made to the compatibility library interface. Any changes

described here should be copied to CL platform reviewers for approval before

changes are made, and the CL spec should be updated to reflect the new

interface. Current platform reviewers are:

Darren Horler VMS

Viktoriya Driker - Windows

Bob Bonchik, Alex Hanshaw UNIX

Alex Hanshaw - Linux


4.4 INTERFACE

How do other components that are external to the design interact with thiscomponent? Describe methods and rules of interaction.

Communication protocols; is GCA affected? Other?

Changes of facility call interfaces in the DBMS (e.g. is dmf_call changed?)

162090111.doc

Page20 of 27


21/27

Changes to the interface of non static functions

New error codes or error conditions that will be logged or propagated up the

stack to other functions. Has the error handling for those functions been

updated?


4.5 BUILD IMPLICATIONS

Does this feature require any special jam rules? Did it require any changes in

jam MANIFEST files? Any new build targets? Any other build alterations?

4.6 UI RESOURCE/PROPERTIES FILES

This section is largely relevant to GUI applications like OpenROAD and can be

removed for DBMS features.

Provide the names of the files required by the UI and Messages

File Name Byte Count Word Count Format Comments

4.7 BITMAP RESOURCES



Provide the bitmap resources.

File Comments

162090111.doc

Page21 of 27


22/27

4.8 ICON FILES



Provide the icon files used.

File Comments

Release note

System

requirements

4.9 PICCOLO CHANGE NUMBERS

Provide piccolo change numbers for changes made for this feature. This will be

filled in after the fact and should include change numbers for propagations of the

same change to other branches if appropriate

Change Number Submitted to (code-

branch)

Submission date

main

162090111.doc

Page22 of 27


23/27

5 IMPACT AND DOCUMENTATION SUMMARY

The estimates in this section are approximate and are intended to give other

groups such as Technical Writing, Services, Support and QA an idea of the

impact this change will have.

5.1 PRODUCT/COMPONENT IMPACTS

5.1.1Entities

List the tools, commands, reports and messages that are impacted by thedevelopment of the module/function. Use the table below to summarize these

changes; you can refer to other sections for details.

Entity New Modified Comments

Tool

Commands

Messages

Help Modules

5.2 DOCUMENTATION

List the existing end-user documentation that is affected by modules changes,

and how it is affected. Be as specific and thorough as possible.

MANUAL CHANGES NEEDED Estimated

# of Pages

Installation Guide

Database Administrator Guide

System Administrator Guide

Connectivity Guide

SQL Reference Guide

Command Reference Guide

Migration Guide

162090111.doc

Page23 of 27


24/27

6 QUALITY ISSUES

Look at the component from the QA point of view. Suggest any special tests

that will stress the component. Think how to make the component NOT work

and what special tests should be performed on this component. This is a

guideline to the QA testing procedures.

6.1 UNIT TESTING SUMMARY

Testing individual functions or subroutines in isolation is called unit testing. Unit

testing in some cases requires the developer to use stubs and drivers. Describe

the unit testing you did in these sections. Attach all unit tests to the wiki page for

this feature so that they are available to QA.

6.1.1Unit Testing Description

List and unit testing planned or done.


6.2 HANDOFFQA IMPACT

In this section you should document expected or observed diffs in HandofQAcaused by the feature as well as other things that impact HandoffQA; should any

new tests be added to HandoffQA for this feature to prevent regression?

6.3 TESTING RECOMMENDATIONS

Suggest other additional function tests that are necessary. Special test

requirements, for example: the security levels, hardware or software

configurations,code page and multiple code pages, multi-system issues. Note

anything that cannot be tested in a lab and which might require field tests. What

can go wrong? How are these situations dealt with?


6.4 REGRESSION RISK ASSESSMENT

What would be the implications of failure in the component? Is the code

complex? What is the potential for destabilizing existing functions?

162090111.doc

Page24 of 27


25/27

What other areas of the product/component interact with this module?


6.4.1Backward Compatibility Issues

Is there anything that should be tested for backward compatibility? Does this

feature affect how a down-rev client connects the current version of the DBMS?

Did the GCA protocol level change? Is upgradedb required?


162090111.doc

Page25 of 27


26/27

7 PACKAGING AND INSTALLATION IMPACT

Indicate any special packaging or installation requirements. Detail what the

packaging and installation requirements, if any, will be. Detail any new files that

are required, remember they should be added to the manifest, you are

responsible for doing this as part of the project.


162090111.doc

Page26 of 27


27/27

8 SUPPORT IMPACT

Detail any diagnostics or trace facilities built in to the component including new

IMA objects, trace points, or other build time or run-time diagnostics. Note

anything that could be made into a good supportability tool. Note components

that are:

Difficult to diagnose (for example: no tracing facility, dependent on specific

timing)

Difficult to service

Include workarounds where appropriate.


8.1 EXAMPLES AND TESTS

Detail any example or test code that you wrote during the development of the

feature that may be useful to help support, QA, or customers to understand the

feature or useful to QA for testing. Attach all example and test code or details to

the wiki page for this feature

162090111.doc

Page 27 of 27

Documents

DDS Template