# Presentation: 501672

## SEEDS Reuse Study

**Software Reuse Framework:****Structure and Content Recommendations**
**Draft**

**Notes:**
This work expands the original concept of a reference architecture as a mechanism to enable software reuse
These recommendations are intended to server only as a starting point for further development by the reuse working groups

## Overview

**Purpose**
- Prepare for SEEDS working group efforts to enable and incentivize software reuse
- Define a framework of supporting mechanisms for software reuse
- Broaden the investigation of reference architectures to consider other factors important to software reuse
**Contents**
- Reuse study goals and objectives (summary)
- Community input and study recommendations (summary)
- Candidate elements of a reuse framework
- Implementation concepts for selected framework elements
- Next steps

## Overall Goals & Objectives

**SEEDS Goals & Objectives**
- Reduce the cost of supporting future missions, science, & applications
- Reduce the effort needed for data systems developers to build ESE data systems
- Increase the ability to acquire needed systems and services from small, established, efficient teams of experts
- Ensure effective competition in the acquisition of needed systems and services
- Eliminate unnecessary redundant development & maintenance efforts
- Increase flexibility & responsiveness to future missions, science, & applications
- Reduce the effort needed for data systems maintainers to incorporate proven components and enhancements that meet end user needs
- Enable needed capabilities to be acquired quickly in incremental chunks
- Increase effective & accountable community participation
- Reduce the effort needed for science and application teams to offer ESE data services
- Increase common understanding of the responsibilities associated with providing a given capability or service
**SEEDS Reuse Goal**
- Enable reuse of existing ESE software assets to achieve SEEDS goals

## Review of Community Recommendations

**Reuse**
- ESE should work to enable software reuse
- Use “improved clone & own” approach for mission critical systems
- Use “open source software” approach for mission success systems
- ESE should not pursue “product line” approach
- Unlikely to realize theoretical benefits across a large and diverse enterprise like ESE
**Reference Architecture**
- ESE should develop reference architecture to help enable reuse
- Coarse-grained (subsystem level, not software module level)
- Notional (high-level descriptions not specific service details)
- Concrete details in a limited set of functional areas
- ESE should not develop a fine-grained, specific reference architecture
- Unlikely to realize theoretical benefits to component-level reuse and software interoperability
- Too costly to develop and too constraining for use by the science community

*Source: SEEDS Formulation Team Draft Recommendations Report, Section 6: Reuse and Reference Architectures*

## Reuse Framework Overview

**What is a reuse framework?**
- A structure for organizing the elements of a software reuse initiative
- A place to share information and tools that can be used to enable software reuse
- An evolving set of content related to software reuse
**Why a reuse framework?**
- Expands original concept of using a reference architecture to enable reuse
- Adds other critical enabling mechanisms
- Organizes the material from various SEEDS reuse activities so they can be shared effectively for use across the ESE community

## Context: Keeping a Reuse Framework in Perspective

**A reuse framework could be the primary output of the reuse support/enablement activity**
**The reuse working groups (not the SEEDS program office) are responsible for developing and populating the reuse framework**

## Community Perspective: Many Barriers to Software Reuse

**Policy, Process, and Cultural Issues**
- Intellectual property policies restrict code sharing
- Policy/cultural restrictions against open source development
- Contractual restrictions on access to vendor’s source code
- “NIH” tendencies
- Cultural emphasis on invention over reuse
- Organizational biases to use certain software
- Cumbersome code release processes
**Knowledge & Skill Issues**
- Lack of knowledge about existing/available software
- Lack of needed skills to understand/incorporate existing assets
- Mismatch of programming language with team skills/preferences
- Lack of experience with reuse in a development team
**Technical Issues**
- Poor fit of an existing subsystem  with the intended application
- Lack of modularity
- Unwillingness to accept some product limitations
- Inconsistent coding and documentation conventions
- Lack of test cases
- Implementation dependencies (e.g., specific technologies or COTS products)

**Tool & Infrastructure Issues**
- No asset repository
- No reuse infrastructure
- Lack of a forum for advertising/marketing components
- Lack of contributions to an asset base
**Funding and Resource Alignment Issues**
- Mission-oriented funding not conducive to investing effort needed to make software reusable
- Lack of funds or desire to document and support assets
- Lack of access to experts familiar with an asset
- No schedule/funds/policy requirement to make contributions to an asset base
**Risk & Uncertainty Issues**
- Perceived technical risk
- Inability to assume some risk in development
- Liability concerns
- Security concerns
- Uncertainty in payoff of reusability investment
- Hesitation to share because SW was not designed/documented to be shared

*Source: SEEDS Public Workshops*
*Note: all these barriers can be addressed by a reuse framework or framework contents.*

## Project Perspective: Reuse Decisions Require Practical Information

**Developers and program managers need pragmatic answers when making reuse decisions**
- What types of subsystems are needed?
- What is available?
- Which are relevant to my class/scale of data system?
- Which ones fit together?
- Which are easily reused/adapted?
- Which are best supported?

## Reuse Framework Elements: Deriving Needs by Addressing Barriers & Questions

**What should a reuse framework contain?**

| Barrier | What a Reuse Framework Can Provide |
| --- | --- |
| Policy, Process, and Cultural Issues | Reuse-friendly reference policies, data rights, & licenses
Reuse promotional information |
| Knowledge & Skill Issues | Reusable asset catalog
Contacts, discussion forums, & community support mechanisms
Reference architecture (terminology & definitions)
Porting tools
Education/training material |
| Technical Issues | Asset assessments
Consensus functional requirements
Reusability guidelines
Coding & documentation conventions & templates
Reusable test cases |
| Tool & Infrastructure Issues | Reusable asset catalog
Open source / community source foundry
Promotional channels (e-mail subscriptions?)
Contribution incentives |
| Funding and Resource Alignment Issues | Reuse enhancement, publication, & support funds
Cross-project support mechanisms
Asset harvesting tools |
| Risk & Uncertainty Issues | Reusability assessment & assurance tools
Reuse promotional information
Asset security assessment tools |

**Notes:**
This matrix is derived from prior community input.  It needs to be made comprehensive and complete.
Why was lack of compatibility/interoperability not raised as a barrier?

## Reuse Framework Elements: Deriving Needs by Addressing Barriers & Questions (cont’d)

**What should a reuse framework contain?**

| System Developer Question | What a Reuse Framework Can Provide |
| --- | --- |
| What types of subsystems are needed? | Reference architecture |
| What is available? | Reusable asset catalog
Community contacts & forums |
| Which subsystems provide the functions I need? | Consensus functional requirements |
| Which are relevant to my class/scale of data system? | Architectural patterns w/ performance characteristics |
| Which subsystems work together? | Architectural patterns that work together
Consensus interface requirements
Reusable test cases |
| Which subsystems are easily reused/adapted? | Architectural/design quality metrics
Component developer contacts & forums
Reusability assessment tools |

## Reuse Framework Elements: Deriving Needs by Reuse Lifecycle Phase

**Build: ensure reusability of new assets**
- Reusability guidelines & recommendations
- Reference architectures
**Harvest: identify reusable assets**
- Reusability assessment tools
- Security assessment tools
- Asset catalog (store)
**Reuse: employ reusable assets**
- Asset catalog (search/browse)
- Developer contacts and forums

## Candidate Reuse Framework Elements (Summary)

**Reusable assets**
- ESE asset catalog (code, test cases, development artifacts)
- Links to other catalogs & repositories
- Document templates & samples
**Reuse support tools**
- Reusability & security assessment tools
- Component cataloging tools (for federated catalogs)
- Software porting tools
- Open/community source foundry
**Reference library**
- Reference architectures & arch. patterns
- Reference policies (data rights & SW licensing)
- Consensus functional requirements
- Reusability guidelines & recommendations
- Quality metrics
- Best practices & lessons-learned
- Developer contacts & forums
- Coding/framework conventions/templates
**News & information**
- Reuse-related news & events
- Featured components & top downloads
- Reuse promotional information & training docs
**Program resources/funding sources**
- Reuse projects
- Reuse incentives
- Outreach & education
- Support & enablement
- Policy change

*SEEDS Reuse Initiatives*
*(Process)*

*Reference Policies*

*Reference Licenses*

*Reference Architecture*

*Reuse Support Tools*

*Reference Information*

*Reuse Incentive List*

*Reusable Assets*

*Contacts*

*The reuse framework provides a structure for capturing and sharing the results of SEEDS reuse initiatives.*

*Asset Catalog*

*Reference Library & Tool Catalog*

**Notes:**
This slide combines the previous three into a comprehensive list of candidate elements
This needs to be refined...we are mixing the framework with the content.  But, so does IBM:
ESS provides a toolkit for architects. It consists of a way of describing architecture assets, based on IBM's new standard,2 and a method for reusing these assets; architecture content in the form of business process patterns and technical reference models; and a tool that organizes the content. 

## Candidate Reuse Framework Elements: Notional Web Presentation

**Reuse enablement relies on sharing information**
**A reuse framework can be partially represented as an information sharing portal**

## Candidate Reuse Framework Elements

**Implementation Concepts for****Selected Candidate Reuse Framework Elements**

## Candidate Reuse Framework Elements:Reusable Asset Catalog/Repository

**Description**
- Catalog of reusable software assets
- Includes asset repository only as needed to ensure access
- Identifies asset owner, capabilities, characteristics, type, contact person, systems where used, etc.
**Rationale**
- Helps developers find reusable assets
**Candidate catalog items**
- Subsystem-level software components
- Reusable software development artifacts
- Reusable templates

**Notes:**
Many possibilities for an Enterprise-level catalog
Service directory (yellow pages, UDDI registry)
Application software directory (Tucows)
Community code foundry (SourceForge) 
Artifact library (ECS Library)
Retail catalog (www.egghead.com)
Topic map (Yahoo/Google directory)
Controlled code repository (ClearCase)
Working group should identify needs and solutions

## Candidate Reuse Framework Elements:Reuse Support Tools: Open Source Foundry

**Description**
- Provides a set of Web-based services to support open source or community source development
- Supports individual projects and collections of projects
- Services include software dissemination, software configuration management, bug reporting, task management, etc.
**Rationale**
- ESE community does not currently have a focal point for open source development
- OSS foundries encourage software to be *developed* as open source, not just *licensed* as open source
- Availability of an OSS foundry can make an open source approach more attractive to developers
**Candidate foundry software**
- SourceForge

## Candidate Reuse Framework Elements: Reference Library: Data Rights Guidance

**Description**
- Provides guidance for those writing contracts and grants to ensure that appropriate data rights are included to enable reuse
**Rationale**
- Current contract and language doesn’t generally preclude reuse, but also doesn’t best ensure that reuse is enabled
**Candidate targets for specific data rights**
- Critical infrastructure software data rights
- Appropriate for mission-critical software including flight segment through L0
- Community resource software data rights
- Appropriate for mission-success software including L1-L4 data product generation
- Commercial potential software data rights
- Appropriate for components best reused through commercial distribution

**Notes:**
Purpose of clauses needs to consider that some software developers are more interested in intellectual credit than monetary credit for their work

## Candidate Reuse Framework Elements: Reference Library: Architecture Patterns 

**Description**
- A small number (less than 10) of generic, ESE domain-specific architectures that capture the essential architectural characteristics of the variety of systems used by data service providers
- Identifies applicable environment and solution characteristics, including functional components (at the subsystem level), services provided, and unique architectural features
- Developed and evolved through relatively informal processes since they are not controlled or used like enterprise architectures
**Rationale**
- Patterns can be reused
- Provide proven design solutions for problems in different contexts
- High benefit/cost ratio relative to code reuse
- Patterns can be used to classify or identify reusable components
- Provide proven implementations matching a given design pattern
- Helps developers find components that fit their needs
- Promotes reusability for newly developed software
**Candidate patterns**
- One for each class of data service provider identified by the Levels of Service study
- One for each community: mission-critical (production emphasis) and mission success (analysis emphasis)

**Reusable Subsystem Catalog/Library**

*Context*

*Problem*

*S1*

**Pattern Catalog/Library**

*Pattern P1*
*Examples:*
*S1, S3*

## Candidate Reuse Framework Elements: Reference Library: Architecture Patterns (cont’d)

**Architecture patterns should include multiple views of the architecture**
- A high-level definition of components and data flows
- A list of categorized system services

- ...The Producer establishes a **Submission Agreement** with the OAIS, which identifies the SIPs to be submitted and may span any length of time for this submission.*  ...*

## Candidate Reuse Framework Elements: Reference Library: Architecture Patterns (cont’d)

**Example Pattern: Publish & Subscribe**
- Applicability/Context
- A component uses data provided by another component
- Information consumer components are not known ahead of time
- The number of data consumers is relatively small
- Problem
- Need a way to restore consistency when data are changed
- Solution
- Allow components to subscribe to changes in the data source (publisher)
- When changes are made, the publisher propagates them to the subscriber
- Structure:
- Publisher (data) Subscriber(s)
- Implementation guidelines
- Subscriptions should be stored in a linked list
- Variants
- Gatekeeper: separate process handles notifications and data distribution
- Event channel: events are published to a topical channel which others can subscribe to
- Known Uses
- News service subscriptions
- MS Office (“copy/past link”)
- Consequences
- Subscribers can be added dynamically without any change in the publisher
- Subscribers may be disrupted by frequent or unexpected updates

***ESE architecture patterns might be similar in structure but higher level and  more comprehensive***

## Next Steps

## Next Steps

**Determine if a software reuse framework is needed to help enable software reuse within NASA’s ESE**
**Identify the most important elements of the framework**
**Establish and begin populating the framework**