Detailed Design Specification

2006, 2010, 2012 Actian Corporation

Project Name

Click here to enter name

Author Click here and enter name(s) Last Saved Date June 4, 2012 Revision Template Revision 2.0

162090111.doc

Responsibility List Assigned To Action Owner Peer Review Peer Review Responsibility Engineer/Architect Development Manager QA Manager Signature

Chris Rogers Jonathan Rosen

Test Review Alex Hanshaw Peer Review Sustainability Review Pam Fowler Ahmed Ezzat Elaine Grieco Lee Howard Peer Review Peer Review Peer Review Peer Review Peer Review

QA Engineer Sustaining Engineering Manager Sustaining Engineering Engineer Level 1 Support Manager Chief Architect Technical Writer

Services Services

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
Page 2 of 27

Assigned To Karl Schendel Teresa King Teresa King Joe Kronk Roger Whitcomb Emma McGrattan

Action Information Information Information Information Information Information

Responsibility DBMS Gateways Connectivity OpenROAD Tools Usability

Signature

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
Page 3 of 27

Assigned To Ian Kirkham Teresa King Teresa King Joe Kronk Alex Hanshaw

Action Language Review Language Review Language Review Language Review Language Review

Responsibility DBMS Gateways Connectivity OpenROAD Supportability and Backward Compatibility

Signature

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
Page 4 of 27

Change History:

Revision Date 30-Nov-2007

Last Revision By Steve Ball

Description of Change Template: Fixed up instructions to be more Ingres product range specific and added sections specific to Ingres/OpenROAD Template: Add tech writing changes and examples section Template: changes based on feedback Template: changes based on working meeting Punta Cana, DR, Development Summit 2008 Template: removed confidential markings Template: Add language review elements Template: Added section on catalog changes Template: Fixed typos, footer now includes file name. Template: Company name change, default reviewers updated Template: Facility reviewers updated, updated, DEFINITIONS, ACRONYMS AND ABBREVIATIONS to change which text is bold. Uploaded to http://community.actian.com/wiki/Image:DDSTemplate.doc

3-Dec-2007 4-Dec-2007 1-May-08 22-May-08 21-Aug-2008 4-Apr-2009 13-Aug-2010 24-May-2012 4-Jun-2012

Steve Ball Steve Ball Christine Normile Christine Normile Steve Ball Steve Ball Chris Clark Chris Clark Chris Clark

162090111.doc
Page 5 of 27

TABLE OF CONTENTS 1 INTRODUCTION.........................................................................10 1.1 SCOPE AND SUMMARY.................................................................................10 1.2 DEFINITIONS, ACRONYMS AND ABBREVIATIONS................................................10 1.3 REFERENCES............................................................................................. 10 1.4 NOTEWORTHY ISSUES................................................................................. 10 2 ARCHITECTURE OVERVIEW.........................................................12 2.1 HIGH LEVEL DESCRIPTION.............................................................................12 2.2 SQL LANGUAGE CHANGES...........................................................................12 2.3 IMPLICATIONS FOR GCA..............................................................................13 2.4 CONNECTION PARAMETERS...........................................................................13 2.5 LANGUAGE, UNICODE AND INTERNATIONALIZATION ISSUES .................................13 2.6 IMPLICATIONS FOR INGRES/STAR....................................................................13 2.7 IMPLICATIONS FOR DBA TOOLS......................................................................14 2.8 NEW IMA/MIB OBJECTS.................................................................................14 2.9 NEW TRACE POINTS..................................................................................... 14 2.10 CATALOG ALTERATIONS............................................................................. 14 2.11 IMPLICATION FOR GATEWAYS......................................................................14 2.12 IMPLICATIONS FOR DATABASE DRIVERS..........................................................15 2.13 IMPLICATIONS FOR OPENROAD.....................................................................15 2.14 DESIGN LIMITATIONS AND ASSUMPTIONS......................................................15 2.15 PLATFORM SPECIFIC ISSUES.......................................................................15
162090111.doc
Page 6 of 27

2.16 PRODUCT INTERACTION............................................................................. 16 2.17 PATENT INFORMATION...............................................................................16 3 EXTERNAL SPECIFICATION.........................................................17 3.1 USER PERSPECTIVE..................................................................................... 17 3.2 INSTALLATION AND ADMINISTRATION PERSPECTIVE............................................17 3.3 MIGRATION ISSUES..................................................................................... 17 3.4 SECURITY IMPACT....................................................................................... 17 4 INTERNAL SPECIFICATION..........................................................19 4.1 ESTIMATED TASKS AND EFFORT....................................................................19 4.2 PROGRAMMING.......................................................................................... 20 4.3 COMPATIBILITY LIBRARY INTERFACE CHANGES...................................................20 4.4 INTERFACE ............................................................................................... 20 4.5 BUILD IMPLICATIONS....................................................................................21 4.6 UI RESOURCE/PROPERTIES FILES..................................................................21 4.7 BITMAP RESOURCES................................................................................... 21 4.8 ICON FILES............................................................................................... 22 4.9 PICCOLO CHANGE NUMBERS..........................................................................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
Page 7 of 27

6.2 HANDOFFQA IMPACT....................................................................................24 6.3 TESTING RECOMMENDATIONS.......................................................................24 6.4 REGRESSION RISK ASSESSMENT....................................................................24 7 PACKAGING AND INSTALLATION IMPACT.....................................26 8 SUPPORT IMPACT......................................................................27 8.1 EXAMPLES AND TESTS.................................................................................27

162090111.doc
Page 8 of 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 their gray 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
Page 9 of 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
Page 10 of 27

to need to do something about blah here to the code, you should note the issue here. Click here to begin typing

162090111.doc
Page 11 of 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. Click here to begin typing

2.2 SQL LANGUAGE CHANGES

Are 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 Click here to begin typing

2.2.1Language changes to Ingres/Star

Will the language changes be implemented in Ingres/star? If not why not? Click here to begin typing

2.2.2Language Changes to ABF

Will the language changes be implemented in ABF? If not why not? Click here to begin typing

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
Page 12 of 27

Click here to begin typing

2.2.4Language Changes to Embedded SQL pre-compilers

Will the language changes be implemented in the embedded SQL Precompilers? If not why not? Click here to begin typing

2.2.5Effects on dynamic SQL

Will the language changes work in dynamic SQL? If not why not? Click here to begin typing

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? Click here to begin typing

2.4 CONNECTION PARAMETERS

Does this feature require, use, or add any new DBMS connection parameters? Click here to begin typing

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)? Click here to begin typing

2.6 IMPLICATIONS FOR INGRES/STAR

Does this feature have any implication for Ingres/Star? If so what are they?
162090111.doc
Page 13 of 27

Click here to begin typing

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? Click here to begin typing

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? Click here to begin typing

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. Click here to begin typing

2.10 CATALOG ALTERATIONS

Does the feature add or alter the Ingres catalogs, either DBMS catalogs, frontend 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 Click here to begin typing

2.11 IMPLICATION FOR GATEWAYS

Does this feature have any implications for the Ingres gateways? Do any SQL language changes need to be considered for implementation in gateway products? Click here to begin typing

162090111.doc
Page 14 of 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? Click here to begin typing

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 Click here to begin typing

2.14 DESIGN LIMITATIONS AND ASSUMPTIONS

This section should list current limitations and assumptions made in the design. Click here to begin typing

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. Click here to begin typing

2.15 PLATFORM SPECIFIC ISSUES

Is there anything about this feature that causes it to have unique characteristics or 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 rearchitecture) Click here to begin typing
162090111.doc
Page 15 of 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. Click here to begin typing

162090111.doc
Page 16 of 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

Click here to begin typing

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. Click here to begin typing

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?

Click here to begin typing

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
Page 17 of 27

Click here to begin typing

162090111.doc
Page 18 of 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% of the 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 Click here to begin typing

Task
Description of task

Effort (persondays)
Total days

Assigned to

Done (yes/no)

Tested (yes/no)

TOTAL

162090111.doc
Page 19 of 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. Click here to begin typing

4.2.1Module 1
Provide a short description of what the module does and how it changed if it was altered. Click here to begin typing

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 Click here to begin typing

4.4 INTERFACE
How do other components that are external to the design interact with this component? 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
Page 20 of 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?

Click here to begin typing

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

This section is largely relevant to GUI applications like OpenROAD and can be removed for DBMS features. Provide the bitmap resources. File Comments

162090111.doc
Page 21 of 27

4.8 ICON FILES

This section is largely relevant to GUI applications like OpenROAD and can be removed for DBMS features. 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 (codebranch) main

Submission date

162090111.doc
Page 22 of 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 the development of the module/function. Use the table below to summarize these changes; you can refer to other sections for details. Entity Tool Commands Messages Help Modules New Modified Comments

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 Installation Guide Database Administrator Guide System Administrator Guide Connectivity Guide SQL Reference Guide Command Reference Guide Migration Guide CHANGES NEEDED Estimated # of Pages

162090111.doc
Page 23 of 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. Click here to begin typing

6.2 HANDOFFQA IMPACT

In this section you should document expected or observed diffs in HandofQA caused 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? Click here to begin typing

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
Page 24 of 27

What other areas of the product/component interact with this module? Click here to begin typing

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? Click here to begin typing

162090111.doc
Page 25 of 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.

Click here to begin typing

162090111.doc
Page 26 of 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. Click here to begin typing

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