J. David SzwarcbergMSCS Candidate

Graduate College of Union University

Domain Engineering and Software Reuse

What is software reuse?

Reuse is simply using an asset previously built in a new context.

An asset is a valuable, high quality software work product (such as code, designs, architectures, interfaces, tests), documents, tools, processes and compiled knowledge (guidelines, models, formulas,…).

-Software Reuse by I. Jacobson

What is an asset?

What is Domain Engineering?

“A process by which information used in developing software systems is identified, captured, and organized with the purpose of making it reusable when creating new systems.”

-Rubén Prieto-Díaz

Domain Engineering Objectives

•Make all of the information concerned with making a reuse decision easy to obtain.

•To derive common architectures, generic models or specialized languages that substantially leverage the software development process in a specific problem area.

Definition of a Domain

• An area organized around classes of systems or parts of systems

Examples: Classes of Systemsairline reservation systemsinventory management systemsmedical record systems

Parts of Systemsdatabase systemsGUI Librariesmath Libraries

Aspects of a Domain

•A domain encompasses the knowledge of a particular area of interest.

•The stakeholders or customers have requirements that specify the domain boundaries.

•The domain includes the knowledge used in building software systems or subsets of those systems in that area.

The Domain Engineering Process

• Domain Analysis

• Domain Design

• Domain Implementation

Domain Analysis

• Defining a set of reusable requirements for the systems in the domain

Domain Design

• Establishing a common architecture for the systems in the domain

Domain Implementation

• Implementing the reusable assets, e.g. reusable components, domain-specific languages, generators, and a reuse infrastructure

Why?

• Quality

•Productivity

•Cost Savings

Domain Analysis

• "the process of identifying, collecting, organizing, and representing the relevant information in a domain, based upon the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within a domain”.

K. Czarnecki

Domain Analysis Process

• Planning and Scoping

• Modeling

• Evaluation

Domain AnalysisPlanning and Scoping

• Select a Domain

• Domain Description

• Data Source Identification

• Inventory Preparation

Domain AnalysisPlanning and Scoping

•Select a Domain

Perform business analysis and risk analysis in order to determine which domain meets the business objectives of the organization

Domain AnalysisPlanning and Scoping

•Domain Description

Define the boundary and the contents of the domain

Domain AnalysisPlanning and Scoping

•Data Source Identification

Identify the sources of domain knowledge

Domain AnalysisPlanning and Scoping

•Inventory Preparation

Create inventory of data sources

Domain AnalysisDomain Modeling

•Data Collection

•Data Analysis

•Taxonomic Classification

Domain AnalysisDomain Modeling

•Data Collection

Gather all knowledge available from sources identified in the data identification stage

Domain AnalysisDomain Modeling

•Data Analysis

Analyze the variabilities of the domain

Modularize the system

Model the entities, and relationships of the domain

Domain AnalysisDomain Modeling

•Taxonomic Classification

Group all relevant data

Create a vocabulary for the domain model

Create the abstract layer for the domain

Domain AnalysisDomain Evaluation

•Evaluation

Check the domain model(s) for accuracy and completeness

Domain Analysis Implementations

•Feature Oriented Domain Analysis (FODA)K. Kang, S. Cohen, J. Hess, W. Nowak, and S. PetersonSoftware Engineering Institute (SEI) 1990

•Organization Domain Modeling (ODM) M. SimosSoftware Technology for Adaptable Reliable Systems (STARS)DARPA Funded Research 1996

•Domain Analysis and Design Process (DADP). Defense Information System Agency (DISA) 90’s

Domain Design

•Implement the domain model in a way that enables systematic reuse.

•Define the interfaces between different systems

•Add additional specifications such as performance, storage, fault tolerance, and reusability

Domain Implementation

•Identify reusable components

•Create reusable assets

•Create a library or repository of reusable assets

•Maintain and update the repository

Component Types

•Domain independentGeneral in scopeCan be used across domains

•Domain specificLess general in scopeUsed more in its particular domain

•Product specificSpecialized componentOnly applicable to a certain product line

Domain Engineering Process

K. Czarnecki

Process Implementation

•Procuring, establishing, recognizing, and coordinating the assets of the infrastructure.

•Tangible assetsFunding Personnel Existing software

•Intangible assetsRationalizationPolitics Motivation

Managing Reuse

•Process needs to be maintained

•Requires a well defined structure

Factors Affecting Reuse Management

•Size of companyUpfront costs

•Size of development team(s)Need support

•Product diversitySize the team(s) accordingly

Management Structures

•Pool Producer ModelUsually 2 to 3 teams

Each team has a manager and several producers

Manager and producers have reuse based incentives and metrics

Management Structures

Level 3Manager

Level 2Manager A

Level 2Manager B

Project AManager

Project BManager

Project AManager

Project BManager

Project ATeam

Project ATeam

Project BTeam

Project BTeam

Pool Producers

Pool Producer Organizational Structure [MMYA02]

Domain Engineering Metrics

•Quantifying the level of demand of the assets in the repository

•The efficiency of the repository

•Usefulness of the assets in the domain.

Domain Engineering Metrics

•The number of accesses to the repository

•The number of retrievals from the repository

•The ratio of repository assets that have been extracted from the repository over some time to the number of components in the repository

Pros / Cons

•Pros•Cost Savings•Quality•Development Time

•Cons •Large overhead in the beginning•Poor planning risk•Poor execution risk

Examples of Reuse Libraries

•Comprehensive Approach to Reusable Defense Software (CARDS)

•The Defense Software Repository System (DSRS)

•The Asset Source for Software Engineering Technology (ASSET)

Examples of Reuse LibrariesCARDS

•CARDS was developed by NASA and USAF for Department of Defense

•Common specification for reusable objects for the Department of Defense and related organizations.

•Designed to handle specific libraries, ex:•Reuse library framework (RLF), •Command Center Library (CCL)•Portable Reusable Integrated Software Modules (PRISM) Distributed Library (PDL).

Examples of Reuse Libraries DSRS

•Reuse library management system

•Distributed repository shared by several defense organizations including the Defense Information Systems Agency (DISA), the Army Reuse Center (ARC), the Defense Logistics Agency, and the Marine Corps Software Reuse Branch.

•Created to enable a system of reusable assets to promote reuse amongst the U.S. Department of Defense information management systems.

Examples of Reuse Libraries ASSET

•Funded by the Defense Advanced Research Projects Agency (DARPA)

•On-line repository of reusable software assets •Taken over by the Science Applications International Corporation (SAIC) in 1995

•A commercial venture that offered web enabled public access to software components

Current Initiatives

•Georgia Technology Authority (GTA)

•Hewlett Packard

•Salion

Current Initiatives Georgia Technology Authority (GTA)

•In 2002 outlined a long-term plan to institutionalize software reuse for the State of Georgia.

•Blends in ideas from several reuse and domain engineering efforts. •Vision statement: “The vision of the state of Georgia's Software Reuse Initiative is to drive Georgia's software community from its current 'reinvent the software' cycle to a process-driven, domain-specific, architecture-centric, library-based way of constructing software.”

Current Initiatives Hewlett Packard

•HP’s printer division, 2000 •Developing firmware for the entire printer product line •Development teams dispersed geographically around the world

•Initiated a software reuse cooperative

•Results: a 3X improvement in time to market, with a 4X reduction in overall team size, and a 25X reduction in typical defect densities. •Approach yielded a 70% increase in the amount of code shared across participating printer product lines.”

Current Initiatives Salion

•Enterprise software development company •Creating a new product line in 2002•The product line was going to have to be flexible to suit minor variations for different customers needs. •Achieved 90-day time-to-market intervals for seven new commercial products in its software product line •“The total effort to implement these new product variants ranges from 5% to 10% of the effort required for the baseline product (i.e., factor of 10 to 20 productivity improvement).”

QnA