Purpose and Focus of Document

The purpose of this document is to collect, analyze, and define high-level needs and features of the NCICB caCORE SDK Release 4.1. This document focuses on the functionalities proposed by the SDK stakeholders and target users in order to make it a better product. The use-case and supplementary specifications document will detail how the framework will fulfill these needs.

Vision and Dependencies

Vision or Problem Statement

The objective of this release of the caCORE SDK 4.1 is to provide features that have been requested and deemed high priority by users in the caBIG community.

This release will addresss the following:

• Modeling: caCORE will be enhanced to support additional modeling constructs such as abstract classes and marker interfaces.
• HL7 Support: For HL7 Support, the caCORE SDK will be working along with the caGrid and other Core development teams to identify realistic use cases for HL7 Support and construct a prototype that will be utilized to elicit feedback from the caBIG community.  A determination will [[sentence not complete in current document]].
• caGrid Integration: The goals for better integration between caCORE SDK and caGrid are centered around ease of maintainability as new versions are developed and usability for users wanting to turn an SDK generated system into a grid service.
• Iterative Development Support: The need for supporting iterative development mainly comes from users who customize, extend, or customize and extend the artifacts generated by the caCORE SDK. Currently, the caCORE SDK generates new artifacts for a system every time it is run.  Often times, the model that users provide as input into the SDK changes during the lifecycle of the project thus requiring them to rerun the model through the SDK to generate updated artifacts. If developers have made customizations to the SDK generated artifacts, they have to manually and tediously identify what has changed and subsequently merge their customizations into the newly created SDK generated artifacts. For the 4.1 release, the caCORE SDK will at the minimum provide users with information concerning what has changed between newly created and previously generated artifacts generated by the SDK.

A number of high priority defects will be fixed as part of the 4.1 release as well. 

Product Dependencies

This release is dependent on the caCORE components or products documented on the dependencies wiki page (example for caCORE 3.2).

[Provide additional explanation as applicable. For example, "The EVS vocabulary systems are used by the Java client to retrieve and validate concept information for naming and defining meanings." 

Stakeholder, Technical and User Descriptions

Stakeholder Summary

Technical Environment

This product uses the following technical components which have been derived from the current NCICB Technology Stack.

• Client Interface
  • Internet Explorer 6.0 and above
  • Mozilla v. 1.5.0.3 and above
• Application Server
  • Apache Tomcat 5.5.9
  • Jboss 4.0.5
• Database Server
  • Oracle 9i
  • MySQL 4.1.19
• Operating System
  • Windows 2000, XP
  • Unix (Sun Solaris)
• Portable ANSI-SQL compliant relational schemas
• Java 1.5

Summary of Key Stakeholder or User Needs

The following subsections provide a description of key requirements to address the solution as perceived by the stakeholders and users.

Stakeholder and User Requirements

[High level bulleted list of the requirements; "See below" if all items are GForge entries.] (You may use this section to describe high level features which have more than one corresponding item in the In-Scope Requirements and Enhancements, for example, Improve user interfaces for the caAdapter mapping tools.)

Current Solution to Meeting Needs

The current 4.0 release of the caCORE SDK was released in late 2007. The 4.0 version can be downloaded at the caCORE SDK download site. The caCORE SDK 4.0 version will be supported by the caCORE SDK development team during the version 4.1 development lifecycle.

Proposed Solution to Meeting Needs

The "In-Scope Requirements and Enhancements" section describes the requirements that will be incorporated within the scope of the 4.1 release. The 41 development project will be performed utilizing portions of the Unified Process with a focus on iterative development and releasing dot or beta versions of the software prior to the final release to meet high priority customer needs.

During the duration of the 4.1 development lifecycle the requirements of future construction iterations will be evaluated near the end of the current iteration under development. The caCORE SDK project manager along with the NCICB Product Manager will review already proposed requirements listed in the "In-Scope Non-Functional Requirements" section along with the requirements listed in the "Bugs", "Feature Requests", and "Suggestions" Trackers made to the caCORE project via the caCORE SDK Gforge Web Site (http://gforge.nci.nih.gov/tracker/?group_id=148), the NCICB Core product listservs, or face to face meetings with projects planning to use or already using the caCORE SDK.  If an iteration's requirements change as a result of the review mentioned above, the following is expected to occur:

1. This scope document will be updated to reflect the correct scope for the iteration being modified.
2. The project schedule must be adjusted to reflect the resources and time needed to perform the work for the updated requirements.

In-Scope Requirements and Enhancements

In-Scope Functional Requirements (Enhancements or New Features) Iteration 1 Approved

This section describes the functional requirements for version 4.1 by iteration. As stated earlier, the overall 4.1 scope can be adjusted as each iteration comes to completion.  Details are provided below for scope items whose iterations have been approved. For additional detail, click on the hyperlinks provided in the requirement header fields which will take you to the Gforge Tracker item for the requirement. The Gforge Tracker is the source of truth for the requirement which actually may contain links to use cases or a requirements specification document.

Each new enhancement, modification or new feature is described in detail below. Please note that only hyperlinks are provided for existing defects that are included in a particular release.

Modeling

GF#2958 Abstract Class Support

In general, full abstract base classes are classes either explicitly declared to be abstract, or contain abstract (unimplemented) methods. Except for the instantiation capability, they have the same capabilities as a concrete class or type.

Starting with SDK v4.1, users must be able to designate a class as abstract in their EA or ArgoUML models by checking the "abstract" checkbox modifier in the class properties dialog or pane.  Concrete class(es) will need to "extend" the abstract class by using a "Generalization" link between the abstract and concrete class(es).  The source of a given "Generalization" link should be the concrete sub-class; the target should be the abstract class.

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=2958&atid=774

Estimated level of effort: [LOE]

GF#2958 Marker Interfaces
 
In SDK 4.1, users must be able to create marker interfaces (with no behavior, or methods) in their models. To indicate that a given class implements a marker interface, create a dependency link between the class and interface. The source should be the class, the target should be the interface. The dependency link should have a "realize" stereotype.

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=2958&atid=774

Estimated level of effort: [LOE]

GF#11539 Implicit Inheritance

The requirement implies that for a given class, if there is no corresponding table, then in that case the table should be present for the subclass. While generating Java classes, we ignore the O/R mapping fact and we do not do anything about it. While generating O/R mapping files, the base class should be ignored and the attributes and associations of the base class should be mapped inside the subclass mapping which has a corresponding table.

The limitation of this approach is that the base class is not searchable by Hibernate as it is not mapped in O/R mapping file.

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=11539&atid=774

HL7 Support

GF#12410 HL7 Prototype

HL7 is a widely accepted standard for exchanging clinical trials information. HL7 data types are building blocks for HL7 messages and caCORE SDK currently does not support these data types. The users of the caCORE SDK should be allowed to use the HL7 data types and map them to the database. Allowing users to use the HL7 data types in UML model would enable them to 1) use the same data types across all the layers of application and 2) quickly build the HL7 message from the information model.
 
As part of the development effort, an initial prototype is required to be built which demonstrates code generation from a model which uses HL7 data types and allows users to search on the generated system. Once the prototype is reviewed and accepted, SDK can build support for remaining HL7 types across all tiers of SDK.

https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=12410&group_id=148&atid=774\\

In-Scope Functional Bug Fixes Iteration 1 Approved

Each bug fix included in this release is described in detail below.

GF#8951 GetHTML query syntax does not support slashes in the criteria

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=8951&atid=730

GF#9392 Uppercase association names generate error in WS

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=9392&atid=774

GF#11189 Search Object drop down is not populated with the correct classnames

https://gforge.nci.nih.gov/tracker/?group_id=148&atid=730&func=detail&aid=11189

GF#9639 Pagination does not work

https://gforge.nci.nih.gov/tracker/?group_id=148&atid=730&func=detail&aid=9639

GF#4150 WS does not handle inheritance properly

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=4150&atid=730 

In-Scope Functional Requirements (Enhancements or New Features) Iteration 2 Approved

Writeable APIs

GF#13288  Writeable API in Java Client

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=13288&atid=774

GF#13287 Enhance Hibernate mapping file generator

[]https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=13287&group_id=148&atid=774

GF#13289 Security in the writeable API

https://gforge.nci.nih.gov/tracker/index.php?func=detail 

GF#13658 Provide the ability to inject data validation into the Writeable APIs

https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=13658&group_id=148&atid=774 

In-Scope Functional Requirements (Enhancements or New Features) Iteration 3 Approved

Defects

GF#13443 Could not obtain DAO for: as

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=13443&atid=774https://gforge.nci.nih.gov/tracker/?group_id=148&atid=774&func=detail&aid=13367

GF#13868 Nested queries no longer possible with REST-API

https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=13868&group_id=148&atid=774

GF#13134 Invalid classname

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=13134&atid=774

GF#8637 JSP Utils error handling

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=8637&atid=774

GF#8638 Several UI issues in Internet Explorer

https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=8638&group_id=148&atid=774

GF#15102 Attribute level security

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=15102&atid=774

GF#13367 equals() and hashcode() methods

https://gforge.nci.nih.gov/tracker/?group_id=148&atid=774&func=detail&aid=13367

GF#12987 Nested Searches

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=12987&atid=774

caGRID Integration 

 GF#15119 SDK Grid Authentication

Implement an Authentication manager in SDK which can take grid proxy as input. The manager should retrieve user Id from the proxy and then get user account information from CSM so that it can be used for authorization purpose. Implementation of this feature may need a bug fix/upgrade of the grid grouper. Also, the Introduce generated data service plugin may need to be upgraded to support this new functionality out of the box.https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=15119&atid=774

GF#15122 SDK Grid Authentication

Integrate CQL in SDK service layer such that if user intends to pass grid CQL to SDK then they can do so. As part of this effort CQL and CQL2HQL need to be converted into separate projects. SDK and Grid projects can download the required JARs either manually or using IVY.

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=15122&atid=774 

GF#15118 Proxy Framework and XML serialization integration in Grid Service

SDK provides Castor mapping files that are capable of serializing objects and its associations till one level. The Introduce generated data service currently overrides this implementation which causes LazyInitializationExceptions for certain users. Moving forward, a common framework needs to be agreed upon and implemented in respective systems.

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=15118&atid=804 

GME Namespace

GF#12415 GME Namespace Cross Cutting Support Development

https://gforge.nci.nih.gov/tracker/index.php?func=detail&aid=12415&group_id=148&atid=774

GF#12414 XSD Import Statements

Unnecessary import statements are present in the XSDs which can be reduced to only the classes that are used in the XSD

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=12414&atid=774 

GF#6137 Permissible Values

Generate permissible values as enums in the Schema

https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=6137&atid=774 

In-Scope Non-Functional Requirements

None

In-Scope General Support Activities

The caCORE SDK team will reserve 45% of 1 FTE to provide support, integration help and training to the user community.

Out of Scope Requirements and Enhancements

The following sections describe items that have been identified as requirements for the caCORE SDK that may be addressed in the caCORE 4.1 release. For readability, the potential requirements will be provided in the "feature request" and "suggestions" trackers on the caCORE SDK Gforge web site.

Out of Scope Functional Requirements (Enhancements or New Features)

Items that are out of scope were evaluated as part of the initial scoping activities for this release, and subsequently not included in the final approved scope. These items are also documented in the cumulative backlog of requirements found on the product GForge site.

GF#12402   Freestyle Search

 https://gforge.nci.nih.gov/tracker/?func=detail&group_id=148&aid=12402&atid=804

GF#12401   Installer UI

https://gforge.nci.nih.gov/tracker/?group_id=148&atid=774&func=detail&aid=12401

Out of Scope Functional Bug Fixes if Applicable

None

Out of Scope Non-Functional Requirements

Perform BDA Refactoring for the SDK

The SDK team will work with the Automated Build and Deploy team to implement continuous integration and automated deployment for the caCORE SDK.

Out of Scope General Support Activities

None

Document History and Project Information

Revisions Prior to this Wiki Document 

Revisions to this Wiki Document